הצפנת שאילתות DNS: הטמעת DoH ו-DoT בארגון

הגדרת DoH: היכן שאילתות DNS יוצאות החוצה בטקסט גלוי

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

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

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

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

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

מה נותן הצפנת DNS: פרטיות, שליטה, עמידות

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

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

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

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

כלל בפרימטר סוגר זאת: DNS ישיר החוצה אסור, ומותרות רק נקודות DoH/DoT ארגוניות, ואז כל השמות נראים ביומן אחד, והמדיניות מיושמת באופן מרוכז ולא לפי העיקרון «לכל אחד כפי שהגדיר».

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

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

השוואת מצבים: DoH, DoT, רזולבר מקומי והיברידי

בחירת המצב נקבעת לא לפי רמת ה«אבטחה», אלא לפי אילו ערוצים זמינים ללקוחות, היכן נמצאים האזורים הפנימיים וכמה מהר צריך לחזור למצב תקין בעת תקלה.

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

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

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

הגדרת DoH: שלבי יישום ברשת הארגונית

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

1. ביקורת של תוכנית פתרון השמות. אוספים רשימה של רזולברים, אזורים מקומיים, רשומות סטטיות בקונפיגורציות ויישומים שכבר פונים בשאילתות מוצפנות בעקיפין למסלול הארגוני. התוצאה — מפת שאילתות עם ציון היוזם ולאן כל סגמנט פונה.
2. תכנון התוכנית. קובעים היכן נשארת נקודת יציאה אחודה ולאן מוביל המסלול החלופי. עבור מכשירים מנוהלים מתאים בדרך כלל DoT, עבור נדידה (roaming) — DoH מעל הפורט המאובטח הסטנדרטי, שכמעט כל רשתות האורחים מעבירות.
3. הגדרת הערוץ המוצפן. פרופילים ברזולברים ובלקוחות, אישורים מהימנים, אימות שם השרת, השבתת שאילתת גיבוי לא מוצפנת או כלל מפורש מתי היא מותרת.
4. סגירת העקיפה. חוסמים נקודות מוצפנות של צד שלישי בפרימטר — אחרת ניתן לעקוף את מדיניות הסינון בשינוי הגדרה אחת בדפדפן.
5. בדיקה לאחר היישום. פתרון שמות בכל הסגמנטים, ההשהיה שנוספה, התנהגות כאשר הרזולבר אינו זמין, שלמות היומנים ומתאם בין אירועים.
6. מסירה לתפעול. נוהל חידוש אישורים, התראות, הוראות חזרה לתוכנית הקודמת, הדרכת המשמרת התורנית.

קונפיגורציות, תוכניות ונהלים: מה נשאר בידיים

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

• קונפיגורציות צמתים — פרופילי עבודה של רזולברים ושערי DoH/DoT, תבניות לאתרים שונים, פרמטרי מטמון וכללי הנפקת אישורים עם חידוש אוטומטי.
• מפת הרשת — טופולוגיה עם נקודות יירוט ויציאה של שאילתות, מיעון מאזינים, מסלולים לרזולברים שמעליהם וסדר הדרדרות בעת כשל של אחד מהם.
• נוהל שינויים — מי וכיצד עורך את הקונפיגורציה, הרצת בדיקות מחייבת, חלונות עבודה, סדר החזרה לגרסה הקודמת וקריטריונים לשינוי מוצלח.
• מדיניויות גישה — אילו צוותים ושירותים פונים לצמתים, לפי אילו סימנים מובחנים לקוחות פנימיים וחיצוניים, כיצד מונפקות ומבוטלות הרשאות.
• תיעוד התשתית — תיאור רכיבים, תלויות ונקודות כשל, הוראות לפעולות שגרתיות: הוספת אתר, החלפת אישור, הוצאת צומת משירות.
• ניטור והתראות — מדדים של השהיית תשובה, שיעור כשלים ופגיעות במטמון, ספי הפעלה ורשימת אותות הדורשים התערבות של התורן.
• הליך חזרה מדורגת — כיצד להחזיר לקוחות תוך דקות לדרך הקודמת של פתרון שמות, בלי לאבד זמינות ובלי להפיץ מטמון פגום.

מקרה בוחן: העברת רשת משרדית ל-DNS מוצפן

מה היה לפני הפרויקט

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

שיעור השאילתות הלא מוצפנות עמד על 100%, וההתאוששות מכשל בפתרון שמות — עד כמה שעות בכוחה של המשמרת התורנית.

מה שינו

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

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

התוצאה

שיעור השאילתות הגלויות ירד מ-100% ל-2-3% — נותרו מכשירים ללא תמיכה בהצפנה, שהועברו לסגמנט נפרד עם גישה מוגבלת. אין אירועים מאומתים של החלפת תשובות לאחר המעבר, ושאילתה לא מוצפנת נחשבת כעת אוטומטית לעילה לבדיקה ולא לרקע.

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

במה DoH שונה מ-DoT ומתי די באחד

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

DoT עובר בערוץ מאובטח נפרד בפורט משלו: התעבורה נראית כשירות נפרד, אך לעומת זאת מאושרת באופן צפוי, מוגבלת לפי כתובות ומופיעה ביומנים כזרם עצמאי. מכאן גם הכלל המעשי לבחירת מצב ההצפנה — לפי התרחיש, ולא לפי «טוב יותר/טוב פחות».

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

התוכנית המעשית — להשבית את המצב המובנה באמצעות מדיניות ולהפנות את המכונות לצומת שלנו, שכבר מצפין את התעבורה החוצה.

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

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

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

תאימות, חזרה ובדיקה: ספקות טכניים

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

מה עושים עם אזורים פנימיים?

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

כיצד מבוצעת חזרה של שינויים?

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

האם אפשר להפעיל הצפנה חלקית?

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

כיצד לוודא שההצפנה באמת עובדת?

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

נדון במשימה: אילו נתונים נדרשים להערכה ולתוכנית

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

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

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