בכל פעם שמישהו נכנס לאתר שלכם, מתקבלת החלטה תוך אלפיות שנייה. האם זה מבקר אמיתי או בוט שמנסה לנצל פרצה בתוסף? האם שליחת הטופס הזו לגיטימית או ניסיון של SQL injection? חומת אש לאפליקציות ווב מקבלת החלטות כאלה כל הזמן, ורוב בעלי האתרים אף פעם לא רואים את זה קורה. אבל להבין איך ההחלטות האלה מתקבלות עוזר לכם להגדיר את ההגנות שלכם בצורה טובה יותר ולפתור בעיות במקרים הנדירים של חסימה שגויה.
בואו נחשוף איך כללי WAF באמת עובדים.
מה חומת אש לאפליקציות ווב בעצם בודקת
חומת אש לאפליקציות ווב יושבת בין התעבורה הנכנסת לבין האתר שלכם, ובודקת בקשות HTTP ו-HTTPS לפני שהן בכלל מגיעות לקוד של האפליקציה. היא בודקת הרבה יותר מסתם כתובת URL. היא בוחנת:
- כותרות הבקשה, כולל מחרוזות user-agent ומידע על referrer
- פרמטרים בשאילתה ונתוני POST
- עוגיות (cookies) ואסימוני session
- העלאות קבצים והתוכן שלהן
- תדירות ודפוסי בקשות מכתובת IP בודדת
כל אחד מהמאפיינים האלה נבדק מול קבוצת כללים לפני שהבקשה מקבלת אישור להיכנס. אם משהו נראה חשוד, חומת האש יכולה לחסום את הבקשה, לסמן אותה, או להציב אתגר כמו CAPTCHA.
שלושת סוגי הכללים העיקריים בחומת אש לאפליקציות ווב
1. כללים מבוססי חתימה (Signature-Based)
אלה הבסיס של רוב חומות האש. כלל מבוסס חתימה מחפש דפוסי תקיפה ידועים, כמו המחרוזת ' OR '1'='1, שהיא ניסיון קלאסי של SQL injection. כללים כאלה מהירים ואמינים בזיהוי התקפות מתועדות היטב, אבל הם עובדים רק מול איומים שכבר זוהו ותועדו בעבר.
כאן נכנסים לתמונה תקנים תעשייתיים. OWASP Core Rule Set (CRS) הוא קבוצת הכללים הפתוחה והנפוצה ביותר, והיא מכסה את קטגוריות OWASP Top 10 כמו התקפות injection, cross-site scripting, ו-remote file inclusion. רוב חומות האש המסחריות ואלה שמסופקות ברמת האחסון בנויות על הבסיס הזה.
2. כללים התנהגותיים ומבוססי קצב (Rate-Based)
לא לכל התקפה יש חתימה מזוהה. ניסיונות brute force להתחברות, credential stuffing, וגריפת תוכן (scraping) לרוב נראים כמו בקשות רגילות כשבודקים אותן בנפרד, אבל הדפוס חושף אותן. כלל התנהגותי יכול לומר: לחסום כל IP שפונה לכתובת /wp-login.php יותר מ-10 פעמים ב-60 שניות. כך אפשר לתפוס התקפות שלא מסתמכות בכלל על תוכן זדוני, אלא רק על נפח וחזרתיות.
3. כללי מודל אבטחה חיובי (Positive Security Model)
במקום לנסות לרשום כל דבר רע (מה שבלתי אפשרי), מודל אבטחה חיובי מגדיר בדיוק איך אמורה להיראות בקשה תקינה עבור נקודת קצה מסוימת, וחוסם כל דבר שסוטה מזה. אם טופס יצירת הקשר שלכם מקבל רק שדה שם, אימייל והודעה, כלל חיובי ידחה כל בקשה שמוסיפה שדות נוספים או סוגי נתונים לא צפויים. הגישה הזו קשה יותר להגדרה, אבל תופסת התקפות חדשות שכללים מבוססי חתימה היו מפספסים לגמרי.
איך עובד ניקוד כללים וסף אנומליה
חומות אש מודרניות כמעט אף פעם לא חוסמות על סמך התאמה של כלל בודד. במקום זאת, הן משתמשות במערכת ניקוד אנומליות. כל כלל שמתאים לבקשה מוסיף נקודות לסכום מצטבר. הפרות חמורות, כמו דפוס ברור של SQL injection, יכולות להוסיף 5 נקודות. אנומליה קטנה, כמו כותרת חסרה, יכולה להוסיף נקודה אחת.
כשהסכום חוצה סף מסוים, שבדרך כלל מוגדר כחלק מהגדרת OWASP CRS, הבקשה נחסמת. גישת הניקוד הזו מפחיתה משמעותית חסימות שגויות בהשוואה למערכת פשוטה של "התאמה אחת, חסימה מיידית", כי תעבורה לגיטימית לפעמים נתקלת בכלל קטן בלי שהיא באמת זדונית.
מאיפה מגיעות חסימות שגויות
אם אי פעם היה לכם לקוח שהתלונן שהטופס שלו נחסם למרות שהיה לגיטימי, נתקלתם בחסימה שגויה. זה בדרך כלל קורה בגלל:
- כלל רחב מדי שתופס קלט רגיל יחד עם קלט זדוני (הודעה שמכילה את המילה "select" יכולה להיראות כמו תחביר SQL)
- אפליקציה שמשתמשת בפורמטים לא שגרתיים של בקשות שלא תואמים לדפוס הצפוי
- תוסף או תבנית ששולחים נתונים בצורה שהכללים לא כווננו אליה
ניהול טוב של חומת אש משמעו סקירה קבועה של יומני חסימות וכיוונון כללים בהתאם לאפליקציה הספציפית שלכם, ולא רק השארת ההגדרות ברירת המחדל לנצח. אחסון מנוהל שמכוונן באופן פעיל את כללי ה-WAF שלו על סמך דפוסי תעבורה אמיתיים מבסיס הלקוחות שלו נוטה לתפוס פחות חסימות שגויות מקבוצת כללים גנרית שמתאימה "לכולם".
תיקון וירטואלי: חסימה לפני שאתם מספיקים לתקן
אחד השימושים המעשיים ביותר של כללי WAF הוא תיקון וירטואלי (virtual patching). כשמתגלה פרצה חדשה במערכת ניהול תוכן (CMS) פופולרית או בתוסף, בדרך כלל יש חלון זמן של ימים או שבועות עד שכל האתרים מתקינים את התיקון הרשמי. במהלך החלון הזה, חומת האש יכולה לדחוף כלל ממוקד שחוסם את דפוס הניצול הספציפי, ולקנות זמן בלי לגעת בקוד שלכם בפועל. זה שימושי במיוחד לאתרי WordPress שמריצים עשרות תוספים, שם תיקון מיידי של הכל לא תמיד מציאותי.
כללים מותאמים אישית לעומת קבוצות כללים מנוהלות
בדרך כלל יש לכם שני מסלולים להגדרת חומת אש לאפליקציות ווב:
- קבוצות כללים מנוהלות, שמתוחזקות על ידי ספק האחסון שלכם או ספק אבטחה, ומתעדכנות אוטומטית ככל שצצים איומים חדשים
- כללים מותאמים אישית, שנכתבים במיוחד לאפליקציה שלכם כדי לחסום דברים כמו גישה לנתיבי ניהול ממדינות מסוימות, או שילובי פרמטרים חריגים שייחודיים להגדרה שלכם
רוב האתרים נהנים משילוב של השניים. קבוצת כללים מנוהלת מטפלת בנוף האיומים הרחב והמשתנה כל הזמן, בעוד כללים מותאמים אישית מטפלים בפרטים הספציפיים של האפליקציה שלכם. אנחנו מנהלים כללי חומת אש ברמת השרת כחלק ממערך האבטחה שלנו, ומעדכנים אותם ככל שדפוסי תקיפה חדשים מופיעים ברחבי הרשת שלנו, כך שבעלי אתרים בודדים לא צריכים לעקוב אחרי CVEs בעצמם. אתם יכולים לראות איך זה משתלב בתמונה הרחבה יותר בעמוד סקירת ה-WAF שלנו ובעמוד חומת האש.
מה זה אומר בשבילכם
אתם לא צריכים לכתוב כללי WAF בעצמכם כדי ליהנות מהבנת האופן שבו הם פועלים. הבנת ההבדל בין זיהוי מבוסס חתימה לזיהוי התנהגותי עוזרת לכם לשאול שאלות טובות יותר כשאתם בוחנים ספק אחסון, והיא מסבירה למה חסימות שגויות מדי פעם קורות גם במערכת מכווננת היטב. אם אתם מנסים לפתור בעיה של בקשה חסומה, בדקו אם היא נתקלת במגבלת קצב, בהתאמת חתימה, או בסטייה ממודל חיובי. זה לבד יכוון אתכם לפתרון.
אם אתם רוצים את התמונה הרחבה יותר של למה חומת אש לאפליקציות ווב חשובה מלכתחילה, כיסינו את היסודות במאמר מה זו חומת אש לאפליקציות ווב, והאם באמת אתם צריכים אחת?. ואם אתם בונים את גישת האבטחה המלאה שלכם, כדאי לקרוא גם את למה הגנה רב-שכבתית על אתרים תמיד עדיפה על כלי בודד.
לסיכום
חומת אש לאפליקציות ווב היא לא קופסה שחורה שמקבלת החלטות שרירותיות. היא מריצה את התעבורה שלכם דרך בדיקות חתימה, ניתוח התנהגותי, וסף ניקוד, הכל בזמן שלוקח לדף להיטען. הבנת ההיגיון הזה עוזרת לכם לסמוך על המערכת כשהיא עובדת, ולפתור בעיות מהר במקרים הנדירים שבהם היא לא.
