IPS ב-FortiGate: איך בונים פרופיל שחוסם SQL Injection, XSS ו-Directory Traversal — מדריך מעשי בעברית

אתם מפרסמים שרת ווב החוצה. יש Firewall Policy מסודרת שמתירה 80 ו-443 מה-WAN אל ה-DMZ, יש NAT, הכל עובד. ואז, בשלוש לפנות בוקר, מישהו שולח לשדה החיפוש שלכם מחרוזת שנראית כמו ' OR '1'='1 — והפיירוול מעביר אותה בשמחה, כי מבחינתו זו סתם תעבורת HTTP תקינה על פורט מותר. זו בדיוק הנקודה שבה מפסיקים להסתפק בכללים ומתחילים להפעיל IPS.

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

מה זה בכלל IPS, ולמה Firewall Policy לבדה לא מספיקה

כלל בפיירוול עונה על שאלה אחת: האם מקור X רשאי לדבר עם יעד Y בשירות Z. ברגע שהתשובה חיובית — החבילה עוברת, ואף אחד לא בודק מה כתוב בתוכה. מנוע ה-IPS של FortiGate נכנס בדיוק שם: הוא מבצע Deep Packet Inspection על התוכן, משווה אותו למאגר חתימות (Signature Package) שמתעדכן מ-FortiGuard, ומחליט אם לרשום, להתריע או לחסום.

• ▸SQL Injection — הזרקת פקודות SQL דרך שדות קלט כדי לשלוף או לשנות נתונים במסד הנתונים.
• ▸Cross-Site Scripting (XSS) — הזרקת סקריפט לדף שנצפה על ידי משתמשים אחרים, בדרך כלל כדי לגנוב Session Cookie.
• ▸RFI / LFI — ניצול פרמטרים כדי לגרום לשרת לטעון קובץ שלא היה אמור לטעון, לרוב כשלב לפני Web Shell.
• ▸Command Injection — הרצת פקודות מערכת הפעלה דרך קלט שלא עבר סניטציה.
• ▸Directory Traversal — יציאה מתיקיית ה-Web Root באמצעות ../../ כדי להגיע לקבצי מערכת ולקונפיגורציה.

כלל פיירוול שואל 'מי מדבר עם מי'. IPS שואל 'מה בדיוק נאמר שם'. בתקיפות ווב, כל התשובה נמצאת בשאלה השנייה.

שלב 1 — יצירת IPS Sensor חדש

נתחברים ל-GUI ונכנסים אל Security Profiles > Intrusion Prevention. שם מופיעים הפרופילים המובנים (default, protect_http_server וכדומה). אפשר להשתמש בהם, אבל בשטח כמעט תמיד עדיף פרופיל ייעודי לשרתי ווב — כי הוא מאפשר לכם לכוונן חתימות בלי לשבור מדיניות אחרת. נלחץ Create New וניתן שם ברור: Web_Attack_Protection.

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

שלב 2 — הגדרת ה-Filter: Target, Severity ו-Action

בתוך הפרופיל נלחץ Add Filter. פילטר הוא הדרך החכמה לעבוד: במקום לבחור ידנית אלפי חתימות, אתם מגדירים תנאים והמערכת מושכת אוטומטית כל חתימה מתאימה — כולל חדשות שיגיעו בעדכון הבא של FortiGuard.

• ▸Target: Server — אנחנו מגנים על שרת שמקבל תעבורה, לא על תחנות קצה. בחירת Client כאן תיצור המון רעש ותפספס בדיוק את מה שרציתם.
• ▸Severity: Critical, High, Medium — מתחת ל-Medium רוב מה שתקבלו זה סריקות רקע ורעש אינטרנט.
• ▸Action: Block לחומרות הגבוהות, ו-Monitor לחתימות שאתם עדיין לא בטוחים לגביהן.
• ▸Category / Technology: מסננים לפי Web Attack ו-HTTP כדי למקד את הפרופיל.
• ▸Log Matched Traffic: פעיל תמיד. IPS בלי לוגים הוא ניחוש מנומק.

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

config ips sensor
    edit "Web_Attack_Protection"
        config entries
            edit 1
                set severity critical high medium
                set location server
                set protocol HTTP
                set log enable
                set log-packet enable
                set action block
            next
        end
    next
end

שלב 3 — שיוך הפרופיל ל-Firewall Policy

כאן ההגדרה הופכת להגנה אמיתית. נלך אל Policy & Objects > Firewall Policy, נערוך את הכלל שמטפל בתעבורה הנכנסת אל שרת הווב (בדרך כלל WAN אל DMZ), נגלול אל Security Profiles ונדליק IPS עם הפרופיל Web_Attack_Protection. אל תשכחו להפעיל Log Allowed Traffic על הכלל עצמו.

config firewall policy
    edit 12
        set name "WAN-to-DMZ-Web"
        set utm-status enable
        set ips-sensor "Web_Attack_Protection"
        set ssl-ssh-profile "certificate-inspection"
        set logtraffic all
    next
end

נקודה שקריטי להבין: אם התעבורה מוצפנת ב-TLS ואין לכם SSL Inspection מתאים, ה-IPS רואה בעיקר מעטפת. לתקיפות HTTPS צריך Deep Inspection (או לפחות Certificate Inspection יחד עם הצפנה שמסתיימת על שרת שאתם שולטים בו). בלי זה תרגישו מוגנים ולא תהיו.

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

אחרי שהכל פעיל, הבית האמיתי שלכם הוא Log & Report > Intrusion Prevention. שם רואים שם התקיפה, Severity, Action, כתובת מקור וכתובת יעד. עבודה נכונה עם הלוגים היא ההבדל בין 'התקנו IPS' לבין 'אנחנו באמת מגנים על השרת'.

• ▸אירוע שחוזר מאותה כתובת מקור — שקלו Ban זמני או חסימה גיאוגרפית ברמת המדיניות.
• ▸חתימה שנדלקת על תעבורה לגיטימית של האפליקציה — הפכו אותה נקודתית ל-Monitor, אל תכבו את הפרופיל.
• ▸כל האירועים ב-Monitor בלבד — סימן שהפילטר הוגדר כ-Default ולא כ-Block. בדקו שוב.
• ▸אין אירועים בכלל במשך ימים על שרת שחשוף לאינטרנט — סימן חזק שהפרופיל לא באמת משויך למדיניות.

טעויות נפוצות שראינו במעבדה

• ▸בחירת Target: Client על שרת — הרבה רעש, אפס הגנה רלוונטית.
• ▸הפעלת IPS על כלל היוצא ל-WAN במקום על הכלל הנכנס אל ה-DMZ.
• ▸שכחה של עדכוני FortiGuard — חתימות מיושנות מגלות רק תקיפות של אתמול.
• ▸חסימה גורפת של Severity Low מיד ביום הראשון, ואז שעה של תלונות מהמשתמשים.
• ▸פרופיל IPS ללא לוגים, ואז אין שום דרך להוכיח שהוא עשה משהו.

מה עושים מכאן

IPS הוא רק חלק אחד מארגז הכלים של FortiGate. בקורס Firewall FortiGate שלנו אתם בונים את זה בעצמכם על מעבדה חיה: Policies ו-NAT, פרופילי UTM מלאים (IPS, AntiVirus, Web Filter, Application Control), SSL Inspection, IPsec ו-SSL VPN, VDOM, HA ואבחון תקלות עם diagnose ו-sniffer — בדיוק החומר שנשאלים עליו בראיונות ובהסמכות Fortinet NSE.