שאלת ראיון: חסמתם הכול ב־Check Point. אז איך הניהול עדיין עובר?

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

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

השאלה המלאה: מה ההבדל בין חוקים מפורשים לחוקים משתמעים?

החוקים שכתבתם — והחוקים שהמערכת מוסיפה

חוקים מפורשים, Explicit Rules, הם החוקים שאתם מגדירים ב־SmartConsole בתוך מדיניות הגישה: מי רשאי להגיע לאן, באילו שירותים, ומה עושים עם ההתאמה. למשל, מתירים לרשת המשתמשים גישה לשרת אפליקציה, מגבילים גישה מרשת אורחים או חוסמים תעבורה שלא אמורה להיכנס. אלה החלטות האבטחה שאתם מתרגמים ל־Rule Base.

חוקים משתמעים, Implied Rules, הם כללים מוגדרים מראש שמתווספים למדיניות בהתאם להגדרות המערכת. התיעוד הרשמי של Check Point מסביר שמדיניות Access Control כוללת כברירת מחדל חוקים כאלה לצורך התקשורת הפנימית הנדרשת בין שרת הניהול, שערי האבטחה, חברי האשכול ושרתי הלוגים. הם אינם עוד חוק עסקי שהקלדתם ידנית, אבל הם בהחלט חלק מהמדיניות שנאכפת.

חשוב לא להרחיב את ההגדרה יותר מדי: עצם קיומם של חוקים משתמעים לא אומר שכל שירות אל הפיירוול פתוח. אל תסיקו שגישה ב־SSH או HTTPS, בקשת ICMP, שאילתת DNS או תעבורת OSPF ו־BGP מותרות רק כי מדובר בשירות ניהול או תשתית. בודקים איזה כלל קיים, האם הוא פעיל, לאיזו תעבורה הוא מתאים ובאיזה מיקום הוא נבדק.

מי גובר על מי? המיקום חשוב יותר מהכינוי

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

לחצו להגדלה

אז איך שרת הניהול עדיין מגיע לפיירוול?

בתרחיש שלנו, הסבר אפשרי הוא כלל משתמע פעיל שמאפשר את תקשורת הבקרה הרלוונטית ונבדק במיקום First. כך התעבורה מתאימה לכלל לפני חוק החסימה שכתבנו. מנגנון SIC קשור לאמון ולתקשורת המאובטחת בין רכיבי Check Point; עדיין צריך לבדוק את חיבור הבקרה בפועל ואת הכלל שמאפשר אותו, ולא להפוך את ראשי התיבות האלה להסבר לכל חיבור שעובר.

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

איך רואים את החוקים המשתמעים ב־SmartConsole?

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

Security Policies
  → Access Control > Policy
  → Actions > Implied Rules

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

Menu > Global properties
  → Firewall
  → Select options and configure order
  → OK
  → Install Access Control policy

התשובה שהייתי נותן למראיין ב־30 שניות

שלוש שאלות המשך שכדאי לתרגל

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

״ומה אם חוק הניקוי אינו החוק האחרון?״ אז השם Before Last לא מתייחס אליו. הוא מתייחס לחוק המפורש האחרון, ולכן צריך להסתכל על הסדר האמיתי. במקביל, כדאי לבדוק למה יש חוקים אחרי חסימה גורפת ואם הם בכלל יכולים לקבל התאמה.

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

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

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

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

רשימת בדיקה לפני שמאשימים את הפיירוול

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

מקורות: לא נשענים רק על מה שנשמע הגיוני

ההסבר והמסלולים בממשק נבדקו מול מדריך הניהול הרשמי של Check Point R82. הדיונים בקהילת CheckMates מצורפים כהשלמה להבחנה בין מיקומי הכללים ולשיקולים במדיניות מרובת שכבות. זהו תרגול לראיון והסבר מקצועי, לא הוראה לשנות מדיניות בסביבת ייצור; לפני שינוי בודקים את התיעוד והתצורה של הגרסה שלכם.