אובייקטים של שם דומיין שמוגדר במלואו (FQDN) מאפשרים להגדיר כללי חומת אש באמצעות שמות דומיין במקום כתובות IP ספציפיות. במאמר הזה מוסבר איך אובייקטים של FQDN ממופים לכתובות IP ואיך הם תומכים בשירותים שונים של Cloud DNS:
- מדיניות תגובה של Cloud DNS
- אזורים פרטיים מנוהלים בהיקף רשת VPC
- שמות DNS פנימיים של Compute Engine
- תחומי DNS ציבוריים
המסמך הזה מיועד לאדמינים של רשתות ולמהנדסי אבטחה שמגדירים ומנהלים כללי מדיניות של חומת אש.
כדי להשתמש באובייקטים של FQDN, ברשת של הענן הווירטואלי הפרטי (VPC) לא יכול להיות מדיניות שרת יוצא עם שרת שמות חלופי. מידע נוסף זמין במאמר בנושא סדר הרזולוציה של רשת VPC.
מיפוי של אובייקטים של FQDN לכתובות IP
Cloud Next Generation Firewall פותר מעת לעת אובייקטים של FQDN לכתובות IP. Cloud NGFW פועל לפי סדר ההחלטה של שמות ה-VPC ב-Cloud DNS ברשת ה-VPC שמכילה את יעדי כלל חומת האש.
ההתנהגות הבאה מתרחשת ב-Cloud NGFW כשמנסים לפתור כתובות IP:
תמיכה במעקב אחר CNAME. Cloud NGFW משתמש במעקב אחרי CNAME ב-Cloud DNS אם התשובה לשאילתת אובייקט FQDN היא רשומת CNAME.
כתובות ה-IP של התוכנית. Cloud NGFW משתמש בכתובות ה-IP שפוענחו כשהוא מתכנת את כללי חומת האש שמשתמשים באובייקטים של FQDN. אפשר למפות כל אובייקט FQDN ל-32 כתובות IPv4 לכל היותר ו-32 כתובות IPv6 לכל היותר.
אם תשובת ה-DNS לשאילתת אובייקט FQDN מניבה יותר מ-32 כתובות IPv4 או יותר מ-32 כתובות IPv6, Cloud NGFW מגביל את כתובות ה-IP המתוכנתות בכללי חומת האש ל-32 כתובות ה-IPv4 הראשונות ול-32 כתובות ה-IPv6 הראשונות.
התעלמות מאובייקטים של FQDN. אם Cloud NGFW לא יכול לפתור אובייקט FQDN לכתובת IP, הוא מתעלם מאובייקט ה-FQDN. במצבים הבאים, Cloud NGFW מתעלם מאובייקט FQDN:
כשמתקבלות תשובות מ-
NXDOMAIN. תשובותNXDOMAINהן תשובות מפורשות משרת שמות שמציינות שלא קיימת רשומת DNS לשאילתת אובייקט FQDN.כשאין כתובת IP בתשובה. במצב הזה, שאילתת אובייקט FQDN לא מניבה תשובה עם כתובת IP ש-Cloud NGFW יכול להשתמש בה כדי לתכנת כלל חומת אש.
כאשר שרת DNS של Cloud DNS אינו נגיש. Cloud NGFW מתעלם מאובייקטים של FQDN אם אי אפשר להגיע לשרת DNS שמספק את התשובה.
כשמתעלמים מאובייקט FQDN, Cloud NGFW מתכנת את החלקים הנותרים של כלל חומת האש, אם אפשר.
שיקולים לגבי אובייקטים של FQDN
כשמגדירים אובייקטים של FQDN, כדאי להביא בחשבון את הנקודות הבאות:
אפשר לשלב FQDN עם פרמטרים אחרים. פרטים על שילובים של פרמטרים של מקור בכללי תעבורה נכנסת זמינים במאמר מקורות לכללי תעבורה נכנסת. פרטים על שילובי פרמטרים של יעדים בכללי יציאה מופיעים במאמר יעדים בכללי יציאה.
מכיוון שאובייקטים של FQDN ממופים ומתוכנתים ככתובות IP, Cloud NGFW משתמש בהתנהגות הבאה כששני אובייקטים או יותר של FQDN ממופים לאותה כתובת IP. נניח שיש לכם את שני הכללים הבאים של חומת האש שחלים על אותו יעד:
- כלל 1: עדיפות
100, כניסה מותרת ממקור FQDNexample1.com - כלל 2: עדיפות
200, כניסה מותרת ממקור FQDNexample2.com
אם גם
example1.comוגםexample2.comמופנים לאותה כתובת IP, מנות נכנסות גם מ-example1.comוגם מ-example2.comתואמות לכלל הראשון של חומת האש, כי לכלל הזה יש עדיפות גבוהה יותר.- כלל 1: עדיפות
הנקודות הבאות חשובות לשימוש באובייקטים של FQDN:
שאילתת DNS יכולה להניב תשובות ייחודיות על סמך המיקום של הלקוח ששולח את הבקשה.
התשובות של DNS יכולות להיות מגוונות מאוד כשמערכת איזון עומסים מבוססת-DNS מעורבת.
תשובת DNS עשויה להכיל יותר מ-32 כתובות IPv4.
תשובת DNS עשויה להכיל יותר מ-32 כתובות IPv6.
במצבים שצוינו למעלה, מכיוון ש-Cloud NGFW מבצע שאילתות DNS בכל אזור שמכיל את ממשק הרשת של המכונה הווירטואלית שאליה חל כלל חומת האש, כתובות ה-IP המתוכנתות בכללי חומת האש לא מכילות את כל כתובות ה-IP האפשריות שמשויכות ל-FQDN.
רוב שמות הדומיינים של Google, כמו
googleapis.com, כפופים לאחת או יותר מהסיטואציות האלה. במקום זאת, אפשר להשתמש בכתובות IP או בקבוצות של כתובות.מומלץ להימנע משימוש באובייקטים של FQDN עם רשומות DNS
Aשערך ה-TTL שלהן הוא פחות מ-90 שניות.
פורמט של שמות דומיין
אובייקטים של FQDN חייבים להיות בפורמט FQDN סטנדרטי. הפורמט הזה מוגדר ב-RFC 1035, RFC 1123 ו-RFC 4343. Cloud NGFW דוחה אובייקטים של FQDN שכוללים שם דומיין שלא עומד בכל כללי הפורמט הבאים:
כל אובייקט FQDN חייב להיות שם דומיין עם לפחות שתי תוויות:
- כל תווית צריכה להתאים לביטוי רגולרי שכולל רק את התווים האלה:
[a-z]([-a-z0-9][a-z0-9])?.. - האורך של כל תווית חייב להיות בין תו אחד ל-63 תווים.
- צריך לשרשר את התוויות עם נקודה (.).
לכן, אובייקטים של FQDN לא תומכים בתווים כלליים לחיפוש (
*) או בשמות של דומיינים ברמה העליונה (או דומיינים בסיסיים), כמו*.example.com.ו-.org, כי הם כוללים רק תווית אחת.- כל תווית צריכה להתאים לביטוי רגולרי שכולל רק את התווים האלה:
אובייקטים של FQDN תומכים בשמות דומיין בינלאומיים (IDN). אפשר לספק IDN בפורמט Unicode או Punycode. כמה נקודות שכדאי לחשוב עליהן:
אם מציינים שם דומיין בינלאומי בפורמט Unicode, Cloud NGFW ממיר אותו לפורמט Punycode לפני העיבוד.
אתם יכולים להשתמש בכלי להמרת IDN כדי ליצור ייצוג של IDN בקידוד Punycode.
מגבלת התווים של 1-63 לכל תווית חלה על שמות דומיין בינלאומיים (IDN) אחרי המרה לפורמט Punycode.
האורך המקודד של שם דומיין שמוגדר במלואו (FQDN) לא יכול להיות יותר מ-255 בייט (אוקטט).
ב-Cloud NGFW אין תמיכה בשמות דומיין מקבילים באותו כלל של חומת אש. לדוגמה, אם שני שמות הדומיין (או ייצוגי Punycode של IDN) שונים לכל היותר בנקודה סופית (.), Cloud NGFW מחשיב אותם כשווים.
המאמרים הבאים
- רכיבים של מדיניות חומת אש
- Google Threat Intelligence לכללי מדיניות חומת אש
- קבוצות של כתובות למדיניות של חומת אש