יתרונות האבטחה

מבוא: סיכוני אבטחה וצמצום סיכונים ב-DNS

בגלל התכנון הפתוח והמבוזר של מערכת שמות הדומיינים והשימוש בפרוטוקול פרוטוקול User Datagram (UDP), ה-DNS פגיע להתקפות מסוגים שונים. מקודדים ציבוריים או "open" מקודדי DNS חוזרים, נמצאים במיוחד בסיכון, מכיוון שהם לא מגבילים חבילות נכנסות לקבוצה של כתובות IP מורשות למקור. אנחנו חוששים בעיקר משני סוגי התקפות נפוצים:

  • מתקפות זיוף המובילות ל הרעלת מטמון DNS. יש סוגים שונים של זיוף DNS וזיוף, והם מיועדים להפנות משתמשים מאתרים לגיטימיים לאתרים זדוניים. הן כוללות התקפות קמינסקי, שבהן התוקפים שולטים בכל אזור ה-DNS.
  • התקפות מניעת שירות (DoS). התוקפים עשויים להפעיל מתקפות DDoS נגד המקודדים בעצמם, או לפתור חטיפות של מתקפות DoS במערכות אחרות. מתקפות שמשתמשות בשרתי DNS כדי להפעיל התקפות DoS על מערכות אחרות הן ניצול של רשומת DNS גדולה/גודל תגובה טוב. הן נקראים התקפות{/1}.

כל רמה של מתקפה מתוארת בהמשך.

מתקפות הרעלת מטמון

יש כמה גרסאות של מתקפות זיוף DNS שיכולות לגרום להרעלה במטמון, אבל התרחיש הכללי הוא כך:

  1. התוקף שולח מקודד יעד DNS למספר שאילתות עבור שם דומיין שידוע לו שהשרת אינו מוסמך, וסביר להניח שהוא לא נמצא במטמון של השרת.
  2. פותר הבעיות שולח בקשות לשרתי שמות אחרים (אילו כתובות ה-IP שלהם התוקף יכול גם לחזות).
  3. בינתיים, התוקף מציף את שרת הקורבן בתגובות מזויפות, שנראה כאילו הגיעו משרת השמות המואצל. התשובות מכילות רשומות שמבצעות בסופו של דבר את הדומיין המבוקש לכתובות IP שבשליטת התוקף. הם עשויים להכיל רשומות תשובות עבור השם שנפתר, או שגרוע מכך, ייתכן שהם גם יאצילו יותר סמכות לשרת שמות שבבעלות התוקף, כך שהם יקבלו שליטה על אזור שלם.
  4. אם אחת מהתשובות המזויפות תתאים לבקשה של מקודד הפתרון (למשל, לפי שם שאילתה, סוג, מזהה ויציאת מקור של מקודד), היא מתקבלת לפני תגובה משרת השמות המקורי, והמקודד מקבל את התגובה המזויפת ושומר אותה במטמון ומוחק את התגובה המקורית.
  5. שאילתות עתידיות לדומיין או לאזור שנפרצו מקבלים מענה ברזולוציות ה-DNS המזויפות מהמטמון. אם התוקף ציינו משך חיים ארוך מאוד על התגובה המזויפת, הרשומות המזויפות נשארות במטמון למשך הזמן האפשרי בלי לעבור רענון.

למבוא מצוין למתקפות קמינסקי, קראו את המאמר מדריך להמחשה בנקודת החולשה ב-DNS של Caminsky.

התקפות DoS ומגברות

מקודדי DNS כפופים לאיומים הרגילים של DoS המגינים על כל מערכת המחוברת לרשת. עם זאת, מתקפות הגברה מדאיגות במיוחד כי מקודדי DNS הם יעדים אטרקטיביים לתוקפים שמשתמשים במקודדים' יחס גדול של גודל תגובה לבקשה כדי לקבל רוחב פס נוסף. מקודדים שתומכים ב-EDNS0 (מנגנוני תוספים ל-DNS) הם נקודות חולשה במיוחד עקב גודל חבילות גדול יותר שניתן להחזיר.

בתרחיש הגברה, ההתקפה ממשיכה כך:

  1. התוקף שולח שאילתות שרת DNS קורבן באמצעות כתובת IP מזויפת של מקור. השאילתות עשויות להישלח ממערכת אחת או מרשת של מערכות זהות, שכולן משתמשות באותה כתובת IP מזויפת. השאילתות הן לרשומות שהתוקפים יודעים שהן מניבות תגובות גדולות הרבה יותר, עד כמה עשרות פעמים1 הגודל של השאילתות המקוריות (לכן השם "Amplify" מתקפת).
  2. שרת הקורבן שולח את התגובות הגדולות לכתובת ה-IP של המקור שהועברה בבקשות המזויפות, מוצף את המערכת וגורם למצב DoS.

מיטיגציות

הפתרון הסטנדרטי ברמת המערכת עבור פרצות אבטחה ב-DNS הוא DNSSEC. עם זאת, עד להטמעה אוניברסלית, מקודדי DNS פתוחים צריכים לנקוט אמצעים עצמאיים כדי לצמצם איומים ידועים. הוצעו שיטות רבות. יש לעיין במאמר IETF RFC 5452: אמצעים לשיפור הגמישות של DNS מול תשובות מזויפות לסקירה כללית של רוב השיטות. ב-Google Public DNS, יישמנו, ומומלץ להשתמש בגישות הבאות:

  • אבטחת הקוד כדי למנוע חריגות ממאגר הנתונים הזמני, במיוחד הקוד האחראי על ניתוח וסידור של הודעות DNS.
  • הקצאת יתר של משאבי מכונות להגנה מפני התקפות DoS ישירות על המקודדים עצמם. מאחר שכתובות IP הן דבר טריוויי שתוקפים יכולים לזייף, לא ניתן לחסום שאילתות על סמך כתובת IP או תת-רשת. הדרך היעילה היחידה להתמודדות עם התקפות כאלה היא פשוט לספוג את העומס.
  • הטמעה של בדיקת אימות בסיסית של חבילות תגובות ואמינות של שרתי שמות, כדי להגן מפני הרעלת מטמון פשוטה. אלו הם מנגנונים רגילים ובדיקות שיפויות. כל מנגנון של שמירה במטמון שעומד בתקנים אמור לבצע את הפעולות הבאות.
  • הוספה של אנטרופיה לבקשת הודעות תקטין את הסיכוי למתקפות מתוחכמות יותר של זיוף/זיוף. יש הרבה שיטות מומלצות להוספת אנטרופיה. בהמשך ריכזנו סקירה כללית של היתרונות, המגבלות והאתגרים בכל אחת מהשיטות האלה, ונדון באופן שבו הטמיענו אותן ב-DNS הציבורי של Google.
  • הסרת שאילתות כפולות, כדי להילחם בהסתברות של מתקפות &יום הולדת.
  • בקשות להגבלת קצב העברת הנתונים, כדי למנוע התקפות DoS ומגברות.
  • מעקב אחר השירות עבור כתובות ה-IP של הלקוח תוך שימוש ברוחב הפס הגדול ביותר ויחס הגובה-רוחב הגבוה ביותר לתגובה לבקשה.

DNSSEC

תקן DNS Security DNS (DNSSEC) מצוין בכמה RFC IE: 4033, 4034, 4035 ו-5155.

פותרי בעיות שמיישמים התקפות הרעלת מטמון DNSSEC על ידי אימות האותנטיות של התגובות שמתקבלות משרתי שמות. כל אזור DNS מכיל קבוצה של זוגות מפתחות פרטיים/ציבוריים, ולכל רשומת DNS נוצרת חתימה דיגיטלית ייחודית ומוצפןת באמצעות המפתח הפרטי. המפתח הציבורי התואם מאומת באמצעות שרשרת אמון השייכת למפתחות ששייכים לאזורי ההורה. מקודדים שתואמים ל-DNSSEC דוחים תגובות שלא מכילות את החתימות הנכונות. ב-DNSSEC בפועל לא ניתן לשבש תגובות, כי בפועל כמעט בלתי אפשרי לחתימה ללא גישה למפתחות פרטיים.

החל מינואר 2013, DNS ציבורי ב-Google תומך באופן מלא ב-DNSSEC. אנחנו מקבלים ומעבירים הודעות בפורמט DNSSEC ומאמתים את התשובות לצורך אימות תקין. אנחנו ממליצים גם למקודדים אחרים לעשות את אותו הדבר.

אנחנו גם שומרים במטמון תגובות של NSEC כפי שמפורט ב-IETF RFC 8198: שימוש אגרסיבי במטמון שמור של DNSSEC שאומת. הדבר יכול לצמצם את שאילתות ה-NXDOMAIN לשרתי שמות המטמיעים DNSSEC ולהשתמש ב-NSEC לתשובות שליליות.

אמצעי תחבורה מוצפנים בצד הלקוח

ב-Google Public DNS יש תמיכה בפרוטוקולים של העברה מוצפנת, ב-DNS ב-HTTPS וב-DNS ב-TLS (אבטחת שכבת התעבורה). הפרוטוקולים האלה מונעים פגיעות, ציתות וזיוף, וכך מחזקים מאוד את הפרטיות והאבטחה בין הלקוח ל-Google Public DNS. הם משלימים את DNSSEC כדי לספק חיפושי DNS מאומתים מקצה לקצה.

הטמעה של בדיקת תקינות בסיסית

יכול להיות שחלק מהפגיעה במטמון ה-DNS נגרמה בטעות, ולא בהכרח בטעות, כחוסר התאמה בין בקשות ותגובות (למשל, בגלל שרת שמות שלא הוגדר כראוי, באג בתוכנת ה-DNS וכו'). לכל הפחות, מקודדי DNS צריכים לבצע בדיקות כדי לאמת את האמינות והרלוונטיות של שרתי השמות&#39. אנחנו ממליצים (ומיישמים) את כל אמצעי ההגנה הבאים:

  • אל תגדירו את הסיבכה החוזרת בבקשות יוצאות, ועקבו תמיד אחר שרשראות האצלה באופן מפורש. השבתת המקדח החוזר מאפשרת לוודא שהמקודד פועל במצב &ציטוט. איטרציה ומירכאות, כדי שתוכלו לשלוח שאילתות לכל שרת שמות בשרשרת ההאצלה באופן מפורש, במקום לאפשר לשרת שמות אחר לבצע את השאילתות האלה בשמכם.
  • דחיית הודעות תגובה חשודות. בהמשך תוכלו למצוא פרטים על מה שאנחנו מחשיבים כ'& החשבונות חשודים'.
  • אין להחזיר רשומות A ללקוחות על סמך רשומות השיוך ששמורות במטמון מבקשות קודמות. לדוגמה, אם קיבלתם שאילתת לקוח עבור ns1.example.com, עליכם לפתור את הכתובת במקום לשלוח רשומת A על סמך רשומות שיוך ששמורות במטמון והוחזרו משרת שמות של .TLD

דחיית תגובות שלא עומדות בקריטריונים הנדרשים

שרת DNS הציבורי של Google דוחה את כל הפרטים הבאים:

  • תשובות שלא ניתנות לניתוח או בפורמט שגוי.
  • תגובות שבהן שדות המפתח לא תואמים לשדות התואמים בבקשה. הנתונים האלה כוללים מזהה שאילתה, כתובת IP של המקור, יציאת מקור, כתובת יעד או שם השאילתה. בסעיף RFC 5452, סעיף 3 מופיע התיאור המלא של התנהגות ה-DNS.
  • רשומות שאינן רלוונטיות לבקשה.
  • רשומות תשובות שלא ניתן לשחזר אותן בשרשרת CNAME.
  • רשומות (בתשובה, בסמכות או בקטעים נוספים) שעבורם שרת השמות אינו מהימן. אנחנו קובעים את "crediability" של שרת שמות לפי המיקום שלו בשרשרת ההאצלה עבור דומיין נתון. ה-DNS הציבורי של Google מאחסן מידע בשרשרת ההרשאות, ואנו מאמתים כל תגובה נכנסת מול המידע השמור במטמון כדי לקבוע את האמינות של שרת השמות המגיב לבקשה.

הוספת אנטרופיה לבקשות

לאחר שמקודד אכן אוכף בדיקות שיפויות בסיסיות, התוקפים צריכים להציף את פותר הבעיות בתגובות כדי שיהיה תואם למזהה השאילתה, ליציאת ה-UDP (מהבקשה), לכתובת ה-IP (לתגובה) ולשם השאילתה של הבקשה המקורית לפני שרת השמות החוקי.

למרבה הצער, לא קשה לעשות זאת, מכיוון שהשדה המזהה הייחודי, מזהה השאילתה, הוא רק באורך 16 ביט (כלומר, ל-1/65,536 נקודות כדי לתקן אותו). גם השדות האחרים מוגבלים בטווח, מה שהופך את המספר הכולל של שילובים ייחודיים למספר נמוך יחסית. בקטע RFC 5452, סעיף 7 מופיע חישוב של השילובים המשולבים.

לכן האתגר הוא להוסיף כמה שיותר תוספות לחבילת הבקשות, בפורמט הסטנדרטי של הודעת ה-DNS, כדי להקשות על תוקפים להתאים בין שילוב תקף של שדות בתקופת החלון. אנחנו ממליצים ליישם את כל השיטות המפורטות בסעיפים הבאים.

הצגנו ביקורת מעודכנת על השיטות שהוזכרו כאן בכנס DNS OARC 38 ביולי 2022. המצגת גם כוללת המלצות לאופרטורים של שרתי שמות.

יציאות מקור אקראיות

כשלב בסיסי, לעולם אין לאפשר לחבילות בקשות יוצאות להשתמש ביציאת ה-UDP ברירת מחדל 53, או להשתמש באלגוריתם צפוי להקצאת מספר יציאות (למשל, הגדלה פשוטה). כדי להקצות יציאות, יש להשתמש במגוון רחב של יציאות, מ-1024 עד 65535. לדוגמה, DNS ציבורי של Google משתמש בכ-15 ביטים, כדי לאפשר לכ-32,000 מספרי יציאה שונים.

הערה: אם השרתים שלכם פרוסים מאחורי חומות אש, מאזני עומסים או מכשירים אחרים עם תרגום כתובת רשת (NAT), המכשירים האלה עשויים לבטל את היציאות באופן אקראי בחבילות יוצאות. יש להגדיר את מכשירי NAT כדי להשבית את ביטול הסידור מחדש של היציאה.

בחירה אקראית של שרתי שמות

בחלק מהמקודדים, כששולחים בקשות לרמה הבסיסית (root), שרתי DNS או שרתי שמות אחרים, בוחרים את כתובת ה-IP של שרת השמות לפי המרחק הקצר ביותר (זמן אחזור). אנחנו ממליצים לבחור באקראי לכתובות היעד כדי להוסיף אנטרופיה לבקשות היוצאות. ב-Google Public DNS, אנחנו פשוט בוחרים שרת שמות באופן אקראי בין שרתי שמות מוגדרים לכל אזור, כדי לתת עדיפות לשרתי שמות מהירים ואמינים.

אם אתם מודאגים לגבי זמן האחזור, תוכלו להשתמש בקצב הלוך ושוב (RTT), הכולל רנדומיזציה בטווח של כתובות מתחת לסף מסוים של זמן אחזור (למשל 30 אלפיות שנייה, 300 אלפיות שנייה וכו').

קובצי cookie מסוג DNS

RFC 7873 מגדיר אפשרות של EDNS0 להוספת קובצי cookie של 64 ביט להודעות DNS. קובץ cookie לתמיכה ב-DNS כולל קובץ cookie אקראי בגודל 64 ביט, ואופציונלית (אם ידוע) קובץ cookie של שרת בבקשה. אם שרת תומך מזהה את אפשרות קובץ ה-cookie חוקית בבקשה, משקף את קובץ ה-cookie של הלקוח ואת קובץ ה-cookie הנכון בתגובה. לאחר מכן, הלקוח המאמת יכול לאמת את התגובה שהתקבלה מהשרת הצפוי על ידי אימות קובץ ה-cookie של הלקוח בתשובה.

אם שרת שמות לא תומך בקובצי cookie מסוג DNS, אפשר להשתמש בשתי האפשרויות הבאות כדי להוסיף אנטרופיה.

קביעת סדר אקראי בשמות שאילתות

לפי הסטנדרטים של DNS, שרתי שמות מטפלים בשמות עם רגישות לאותיות גדולות וקטנות. לדוגמה, השמות example.com ו-EXAMPLE.COM צריכים להיות תואמים לאותה כתובת IP2. בנוסף, כל מיעוט שרתי השמות (למעט מיעוט) יוטענו את השם בתגובה, כפי שהוא הופיע בבקשה, תוך שמירה על המקרה המקורי.

לכן, דרך נוספת להוסיף אנטרופיה לבקשות היא לשנות באופן אקראי את גודל האותיות בשמות הדומיינים בשאילתות. השיטה הזו, המכונה גם "0x20" כי ביט 0x20 משמש להגדרת האותיות באות ארה"ב-ASCII, הוצעה תחילה בטיוטה של IETF לאינטרנט שימוש בשיטה 0x20 בתוויות DNS כדי לשפר את זהות העסקה. בשיטה זו, התשובה של שרת השמות חייבת להתאים לא רק לשם השאילתה, אלא גם לכל אות במחרוזת השם. לדוגמה: wWw.eXaMpLe.CoM או WwW.ExamPLe.COm. כתוצאה מכך, ייתכן שיהיו מעט מאוד תוספות לשאילתות של הדומיינים ברמה העליונה או הדומיין הבסיסי, אבל הוא ישפיע על רוב שמות המארחים.

אחד האתגרים המשמעותיים שגילינו במהלך יישום הטכניקה הזו הוא ששרתי שמות מסוימים אינם פועלים לפי התנהגות התגובה הצפויה:

  • שרתי שמות מסוימים מגיבים ללא תלות ברישיות: הם מחזירים כהלכה את אותן תוצאות ללא קשר לאותיות רישיות בבקשה, אבל התגובה לא תואמת בדיוק לשם של הבקשה.
  • שרתי שמות אחרים מגיבים עם תלות מלאה באותיות רישיות (בהפרה של תקני ה-DNS): המערכת מטפלת בשמות מקבילים בהתאם לאותיות גדולות בבקשה, אם הם לא מגיבים בכלל או מחזירים תגובות שגויות של NXDOMAIN שתואמות לשם המדויק שמופיע בשם.
  • שרתי שמות מסוימים פועלים באופן תקין מלבד שאילתות PTR באזור arpa.

בשני הסוגים של שרתי שמות, שינוי המקרה של שם השאילתה יגרום לתוצאות לא רצויות: עבור הקבוצה הראשונה לא תהיה אפשרות ליצור הבחנה בין התגובות לבין תגובה מזויפת. עבור הקבוצה השנייה, התגובה (אם יש כזו) עשויה להיות שגויה לגמרי.

הפתרון הנוכחי שלנו לבעיה הוא להשתמש ברנדומיזציה של בקשות תמיכה רק עבור שרתי שמות, שאנחנו יודעים שהם תקינים. אנחנו מפרטים גם את תתי-הדומיין המתאימים לכל אחד מהם, על סמך ניתוח היומנים שלנו. אם נראה כי תגובה מהשרתים האלה אינה מכילה את המקרה הנכון, אנו דוחים את התגובה. שרתי השמות המופעלים מטפלים ביותר מ-70% מהתנועה היוצאת שלנו.

בהמתנה לתוויות חד-פעמיות עבור שמות של שאילתות

אם מקודד לא יכול לפענח שם באופן ישיר מהמטמון, או לא יכול להריץ שאילתות ישירות על שרת שמות מהימן, הוא חייב לעקוב אחר הפניות משרת שמות או משרת שמות TLD. ברוב המקרים, בקשות לשרתי הבסיס או שמות ה-TLD יובילו להפניה לשרת שמות אחר, במקום לניסיון לפענח את השם לכתובת IP. לכן, מומלץ לצרף תווית אקראית לשם השאילתה כדי להגדיל את התמליל של הבקשה, בלי להסתכן ביישוב שם שלא קיים. כלומר, שליחת בקשה לשרת שמות מפנה עבור שם עם קידומת תווית, כמו entriih-f10r3.www.google.com, אמורה להחזיר את אותה תוצאה כמו בקשה עבור www.google.com.

על אף שבקשות כאלה מהוות פחות מ-3% מהבקשות היוצאות, בהנחה שהתנועה הרגילה מתבצעת (כי רוב השאילתות ניתנות למענה ישירות מהמטמון או באמצעות שאילתה יחידה), מדובר בדיוק בסוגי הבקשות שתוקפים מנסים לאלץ מקודד לטפל בהן. לכן הטכניקה הזו יכולה להיות יעילה במניעת ניצול של סגנון קמינסקי.

כדי להטמיע את הטכניקה הזו, צריך להשתמש בתוויות נונז רק לבקשות שמובטחות להוביל להפניה. כלומר, תשובות שלא מכילות רשומות בקטע התשובות. עם זאת, נתקלנו בכמה אתגרים כשניסינו להגדיר את קבוצת הבקשות האלה:

  • שרתי שמות מסוימים מסוג TLD (קוד ccTLD) הם למעשה מהימנים עבור דומיינים אחרים ברמה העליונה ברמה 2 (LDLD). למרות שיש להן שתי תוויות, ה-2LDs מתנהגים בדיוק כמו דומיינים מסוג TLD, ומשום כך הם מטופלים בדרך כלל בשרתי שמות של ccTLD. לדוגמה, שרתי השמות של .uk מוסמכים גם עבור האזורים mod.uk ו-nic.uk, ולכן גם שמות המארחים הכלולים באזורים האלה, כגון www.nic.uk, www.mod.uk וכן הלאה. במילים אחרות, בקשות לשרתי שמות של ccTLD ליישוב שמות מארחים כאלה לא יובילו להפניה, אלא לתשובות ממקורות מוסמכים. צירוף תוויות נוזליות לשמות מארחים אלה יגרום לכך שלא ניתן יהיה לפענח את השמות.
  • לפעמים שרתי שמות כלליים מסוג TLD (gTLD) מחזירים תגובות לא מהימנות עבור שרתי שמות. כלומר, יש כמה שמות מארחים של שרתי שמות שחיים באזור gTLD ולא באזור של הדומיין שלהם. שרת gTLD יחזיר תשובה לא מהימנה לגבי שמות המארחים האלה באמצעות רשומת השיוך ששמורה במסד הנתונים, במקום להחזיר הפניה. לדוגמה, שרת השמות ns3.indexonlineserver.com היה בעבר באזור .COM gTLD ולא באזור indexonlineserver.com. כששלחנו בקשה לשרת gTLD עבור n3.indexonlineserver.com, קיבלנו עבורה כתובת IP במקום הפניה. עם זאת, אם הקצנו תווית חדשה, קיבלנו הפנייה ל-indexonlineserver.com, שלא הצליחה לפענח את שם המארח. לכן אנחנו לא יכולים לצרף תוויות חד-פעמיות לשרתי שמות שמחייבים רזולוציה משרת gTLD.
  • הרשויות באזורים ובשמות מארחים משתנות לאורך זמן. מצב כזה עלול לגרום לכך ששם המארח שלא נוסף מראש יהיה ניתן לתיקון אם שרשרת ההאצלה תשתנה.

כדי לתת מענה לאתגרים האלה, קבענו חריגים לשמות מארחים שאי אפשר להוסיף להם תוויות צופן. אלה שמות מארחים שעבורם שרתי שמות TLD מחזירים תגובות שאינן הפניות, לפי יומני השרת שלנו. אנחנו בודקים כל הזמן את רשימת החריגים כדי להבטיח שהיא תישאר בתוקף לאורך זמן.

הסרת שאילתות כפולות

מקודדי DNS חשופים לזינוקים ("תאריך לידה"), הם נקראים כי הם מנצלים את הפונקציה המתמטית המתמטית של &מירכאות; יום ההולדת של פרדוקס&מירכאות; שבהם הסבירות להתאמה אינה מחייבת קלט גדול. מתקפות תאריך לידה כוללות שיטפון שרת הקורבן לא רק בתגובה מזויפת, אלא גם בשאילתות ראשוניות, הסופרות את הגורם המפסיד להנפיק מספר בקשות לפתרון שם אחד. ככל שמספר הבקשות היוצאות גדול יותר, כך ההסתברות שהתוקפים יתאימו לאחת מהבקשות האלה בתגובה מזויפת: תוקף צריך רק בסדר של 300 בקשות תוך 50% כדי שההתאמה תהיה מוצלחת

כדי להגן מפני אסטרטגיית התקיפה הזו, כדאי למחוק את כל השאילתות הכפולות מ'הבאים בתור' היוצאות. לדוגמה, ב-Google Public DNS, אף פעם לא ניתן לשלוח יותר מבקשה אחת עבור אותו שם שאילתה, סוג שאילתה וכתובת IP של יעד.

שאילתות מגבילים

כדי למנוע התקפות מניעת שירות, קיימים כמה אתגרים ספציפיים למקודדים פתוחים של DNS:

  • מקודדים רקורסיביים פתוחים הם יעדים אטרקטיביים להשקת מתקפות הגברה. מדובר בשרתי אמינות בעלי אמינות גבוהה, שיכולים ליצור תגובות גדולות יותר משרת שרת שמות אופייני, במיוחד אם תוקף יכול להחדיר תגובה גדולה למטמון שלו. חשוב מאוד שמפתחים של שירותי DNS פתוחים יוכלו למנוע מהשרתים שלהם להפעיל מתקפות על מערכות אחרות.
  • לפעמים קשה לזהות מתקפות הגברה בזמן שהן מתרחשות. תוקפים יכולים לבצע מתקפה דרך אלפי מקודדים פתוחים כדי שכל פותרים יראה רק חלק קטן מנפח השאילתות הכולל. הם לא יוכלו לשלוף אותות ברורים לכך שהם נפרצו.
  • יש לחסום תנועה זדונית ללא הפרעה או העברה של שירות ה-DNS למשתמשים רגילים. DNS הוא שירות רשת חיוני, כך שהשבתת שרתים לניתוק התקפה אינה אפשרית. כמו כן, אין לסרב לשירות של כתובת IP של לקוח למשך זמן רב מדי. כדי שהמתקפה תהיה מסוגלת לחסום במהירות מתקפה מיד אחרי שהיא מתחילה, ולשחזר את כל השירותים התפעוליים ברגע שהיא מסתיימת.

הגישה הטובה ביותר לטיפול בהתקפות DoS היא להטיל הגבלה או מנגנון של הגבלת הצעת מחיר. ב-Google Public DNS יש שני סוגי בקרה על התעריפים:

  • שליטה בשיעור של בקשות יוצאות אל שרתי שמות אחרים. כדי להגן על שרתי שמות אחרים של DNS מפני מתקפות DoS שניתן להפעיל משרתי המקודדים שלנו, Google Public DNS אוכף את ההגבלות על QPS על בקשות יוצאות מכל אשכול שרתים עבור כל כתובת IP.

  • שליטה בשיעור של תגובות יוצאות ללקוחות. כדי להגן על כל מערכת אחרת מפני הגברה ומתקפות DoS (בוטים) רגילות שהופצו משרתי המקודדים שלנו, Google Public DNS מבצע שני סוגים של הגבלת קצב על שאילתות הלקוח:

    • כדי להגן מפני התקפות מסורתיות המבוססות על נפח, כל שרת מטיל מגבלות על QPS לכל לקוח ועל רוחב פס ממוצע.
    • כדי להגן מפני התקפות הגברה, שבאמצעותן מנצלים תגובות גדולות לשאילתות קטנות, כל שרת אוכף גורם הגברה ממוצע ממוצע לכל לקוח. גורם ההגברה הממוצע הוא יחס שניתן להגדרה של גודל תגובה לשאילתה, הנקבע מדפוסי תנועה היסטוריים המתועדים ביומני השרת שלנו.

    אם שאילתות DNS מכתובת IP אחת של מקור חורגות מהשיעור המקסימלי של QPS, שאילתות עוד לא יועלו. אם שאילתות DNS ב-UDP מכתובת IP אחת של מקור חורגות מהרוחב הממוצע של רוחב הפס או של ההגברה באופן עקבי (התגובה הגדולה עוברת מדי פעם), השאילתות עשויות להימחק או רק תגובה קטנה. תגובות קטנות יכולות להיות תגובת שגיאה או תגובה ריקה עם הגדרת הביט של החיתוך (כך שרוב השאילתות הלגיטימיות יישלחו שוב דרך TCP ויובילו להצלחה). לא כל המערכות והתוכניות ינסו לבצע שוב את התהליך דרך TCP, וייתכן ש-DNS דרך TCP ייחסם על ידי חומות האש בצד הלקוח. ייתכן שחלק מהאפליקציות לא יפעלו כראוי כאשר התשובות ייחתך. עם זאת, חיתוך מאפשר ללקוחות שתואמים ל-RFC לפעול כראוי ברוב המקרים.

  1. לקבלת דוגמאות ודיון טוב לגבי הבעיה באופן כללי, אפשר לעיין במאמר התקפות הגברה של DNS.↩

  2. בסעיף RFC 1034, סעיף 3.5 אומר: ↩

    חשוב לשים לב ששמות של אותיות גדולות וקטנות מותרים בשמות דומיינים, אבל אין תמיכה ברישיות. כלומר, שני שמות עם איות זהה אבל אותיות רישיות שונות נחשבים לטיפול זהה.