אובייקטים של שמות דומיין שמוגדרים במלואם (FQDN) מאפשרים להגדיר כללי חומת אש באמצעות שמות דומיין במקום כתובות IP ספציפיות. במאמר הזה מוסבר איך אובייקטים של FQDN ממופים לכתובות IP ואיך הם תומכים בשירותים שונים של Cloud DNS:
- מדיניות תגובה של Cloud DNS
- אזורים פרטיים מנוהלים בהיקף רשת VPC
- שמות DNS פנימיים של Compute Engine
- תחומי DNS ציבוריים
המסמך הזה מיועד לאדמינים של רשתות ולמהנדסי אבטחה שמגדירים ומנהלים מדיניות של חומות אש.
כדי להשתמש באובייקטים של FQDN, ברשת של הענן הווירטואלי הפרטי (VPC) לא יכול להיות מדיניות שרת יוצא עם שרת שמות חלופי. מידע נוסף זמין במאמר בנושא סדר הרזולוציה של רשת VPC.
מיפוי של אובייקטים של FQDN לכתובות IP
Cloud Next Generation Firewall (Cloud NGFW) מבצע מעת לעת המרה של אובייקטים מסוג 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, כניסה מותרת משם דומיין שמוגדר במלואו (FQDN) של מקורexample2.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 לכללי מדיניות חומת אש
- קבוצות של כתובות למדיניות של חומת אש