מכללת טרביצקי| פרק ראשון - WAF

במהלך השנים האחרונות, התפתחה מגמה ברורה בתוך נוף של אבטחת המידע - יישומי אינטרנט (web applications) נמצאים תחת איומי סייבר. יישומי אינטרנט ימשיכו להיות וקטור עיקרי של התקפה לתוקפים ,והמגמה אינה מראה כל סימן של היחלשות. ניתן לייחס לתוקפים יותר ויותר התקפות מסוג Cross-site scripting , הזרקת SQL , ועוד טכניקות תקיפה אחרות שמטרתן לפרוץ דרך שכבת היישומים. נקודות תורפה ביישומי אינטרנט לדברי רבים, הוא יישום גרוע או חוסר יישום של אבטחת קוד,חוסר וידוי אימות קלט, ניהול session לא מאובטח , הגדרות מערכת שנקבעו לא כסדרם ופגיעויות במערכות הפעלה של השרת. אין ספק שכתיבת קוד מאובטח היא השיטה היעילה ביותר לצמצום נקודות תורפה ביישומי אינטרנט. עם זאת, ״כתיבת קוד מאובטח״ הרבה יותר קל לומר מאשר לעשות , ובדרך כלל זה כרוך במספר סוגיות מפתח. קודם כל, אין לארגונים רבים את הצוות או התקציב נדרש לעשות ביקורות קוד מלאים כדי לתפוס שגיאות . שנית, הלחץ לספק יישומי אינטרנט במהירות יכול לגרום לשגיאות ולעודד נוהלי פיתוח פחות מאובטחים. שלישית , בעוד שמוצרים המשמשים לניתוח יישומי אינטרנט הולכים ומשתפרים,  יש עדיין חלק גדול מהעבודה שחייבת להיעשות באופן ידני, והיא רגישה לטעויות אנוש. ארגונים חייבים לדגול בגישה של ״הגנה לעומק״ באבטחת תשתיות האינטרנט שלהם והיא חייבת לכלול פידבקים ממחלקות IT שונות כמו פיתוח האינטרנט , תפעול, תשתיות ,וצוותי סייבר.

טכנולוגיה אחת שיכולה לעזור באבטחה על תשתית יישומי אינטרנט היא חומת האש של יישומי אינטרנט.חומת האש של יישומי אינטרנט (WAF – Web Application Firewall) הוא מכשיר או יישום שרת שמנטר תעבורת HTTP/HTTPS בין דפדפן של לקוח ושרת אינטרנט בשכבת אפליקציה (Layer 7). ל-WAF יש יכולת לאכוף מדיניות אבטחה המבוססת על מגוון של קריטריונים, כולל חתימות של התקפות ידועות, אכיפת חריגות בסטנדרטים של הפרוטוקול ותעבורה חריגה.

ארכיטקטורת הWAF

1. המיקום

התקנת WAF מבוסס אפליינס בדרך כלל תמוקם ישירות מאחורי חומת אש ארגונית ומול שרתי אינטרנט ארגוניים. ההתקנה לעתים קרובות נעשת בתצורה של reverse proxy. עם זאת, יש כמה פתרונות נוספים כמו חיבור לרשת במצב של ניתור בלבד (סניפר) או במצב inline . אם התקנה מבוססת רשת אינה מתאפשרת, לארגונים יש אפשרות אחרת כמו להתקין את יישומי WAF ישירות על גבי שרתי אינטרנט של הארגון ובכך לספק יכולות אכיפה דומות על ידי עיבוד תעבורה לפני שהוא מגיע לשרת האינטרנט או יישום.

2. מודל אבטחה

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

3. תצורות עבודה

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

• Reverse-proxy -מצב פרוקסי ההפוך המלא הוא נפוץ ביותר ומאפשר להנות ממספר הכי גדול של יכולות של הWAF. במצב של reverse-proxy הWAF יושב בin-line וכל תעבורת הרשת עוברת דרך WAF .WAF מפרסם את כתובות ה-IP ואת כל התעבורה הנכנסת מסיתיימת בכתובות האלה. WAF אז מייצר בקשות לשרתי הווב מטעם הדפדפן המקורי. מצב זה הוא לעתים קרובות הכרחי לתכונות רבות נוספות שWAF עשוי לספק בשל היכולת של טרמינציה של השיחה (session). החסרון של מצב reverse-proxy הוא בהגדילת זמן ההשהיה שעלול ליצור בעיות עבור יישומים פחות סלחניים. אני בכוונה לא מציין את היכולת או החוסר יכולת של ניתוק הWAF במקרה של תקלה. לדעתי, לא יעלה על הדעת לאפשר מצב ללא אכיפת WAF, בדיוק כמו שלא יתכן מצב של החלפת הFW בנתב במקרה של תקלה.
• Transparent proxy - כאשר נעשה שימש בפרוקסי שקוף, הWAF יושב בקו שבין חומת האש ושרת אינטרנט ופועל בדומה לפרוקסי הפוך אבל אין לו כתובת IP. מצב זה אינו דורש כל שינוי בתשתיות הקיימות, אך לא יכול לספק חלק מהשירותים נוספים יכול פרוקסי הפוך.
• Layer 2 Bridge – במצב הזה הWAF יושב על הקו (על הכבל הפיזי ממש) שבין חומת האש ושרתי אינטרנט ופועל בדיוק כמו מתג שכבת 2. מצב זה מספק ביצועים גבוהים ולא מצריך שינויים משמעותיים ברשת, לעומת זאת אינו מספק את השירותים המתקדמים כמו שמצבי WAF אחרים עשויים לספק.
• Network Monitor/Out-of-band/SPAN - במצב הזה, הWAF רק ״צופה״ על תעבורת רשת על ידי סניפינג מיציאת ניטור. מצב זה אידיאלי לבדיקת WAF  בסביבת בדיקות מבלי להשפיע על תעבורה. אם רוצים, הWAF עדיין יכול לחסום את התעבורה במצב זה על ידי השליחה פאקטות של TCP reset על מנת לנסות ולהפיל את התעבורה הלא רצויה.
• Host/Server based – במצב זה הWAF מותקן על שרתי אינטרנט עצמן. Host-based WAF לא מספק תכונות נוספות שעמיתיהם מבוססי רשת עשויים לספק, לעומת זאת, יש להם את היתרון בכך שהם לא מהווים נקודת כשל שWAF מבוסס רשת יוצר, עצם היותו רכיב רשתי. Host-based WAF עשוי להגדיל את העומס על שרתי אינטרנט ולכן ארגונים צריכים להיות זהירים בעת הטמעת יישומי WAF על שרתים עמוסים או שרתים רגישים.

4. יתרונות נוספים

מכשירי הWAF הם לעתים קרובות יכולים לתפקד גם כרכיבי בקרת עומסים של היישומים קיימים או כוללים תכונות נוספות כדי לשפר את האמינות וביצועים של יישומי אינטרנט. תכונות נוספות אלו יכולים לסייע ברכישת WAF כחלק משדרוג של מערך  הapplication delivery בארגונים שעדיין לא מיישמים את היכולות הללו. לא כל פתרונות WAF כוללות את היכולות הללו ואלו שכן, לעיתים תלויים בשינויי במצב עבודה או בתוספת רישוי. בדרך כלל פריסה של reverse-proxy תתמוך בכל התכונות הללו.

• Caching - הפחתת עומס על שרתי אינטרנט והגדלת ביצועים על ידי שימוש במטמון לעותקים של תוכן המבוקש באופן קבוע. בכך מקטין הWAF בקשות חוזרות ונשנות לשרתי הקצה.
• Compression - על מנת לספק תעבורת רשת יעילה יותר, נדחוס תוכן אינטרנט מסוים באופן אוטומטי על ידי הWAF, ולאחר מכן התוכן נפרש על ידי הדפדפן.
• SSL Acceleration – שימוש בהאצת SSL מבוסס חומרה בWAF מאפשר לזרז עיבוד SSL ולהפחית את העומס על שרתי קצה.
• Load Balancing – פיזור של בקשות נכנסות על פני שרתי קצה מרובים, כדי לשפר את ביצועים ואמינות.
• Connection Pooling – מעלה את היעילות בעבודה של TCP אל מול שרתי קצה בכך שהוא מאפשר מעבר של מספר רב של בקשות על באותו חיבור (session) מול שרת הקצה.

5. מוצרים ופתרונות

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

• ModSecurity 

זהו פתרון WAF חינמי מבוסס קוד-פתוח ומיועד להתקנה על שרתי ווב של Apache,IIS וNGINX.

• F5 BigIP ASM

F5 מתמחה בפתרונות Application Delivery, וASM הוא מוצר הWAF שלה. הASM יושב על פלטפורמה רובוסטית הנקראת TMOS וכוללת בתוכה מנוע proxy סופר מהיר ויכולות שליטה בתעבורה ברמה מאוד גבוהה בכל שכבות הOSI ע״י שימוש בiRuleים. הASM משלב בתוכו גם את המודל השלילי וגם את החיובי ומכיל יכולות אכיפה עדכניות ביותר כמו למשל טיפול בCSRF, בדיקת העלאת קבצים מול מנוע אנטיוירוס, XML Firewall, מנוע חתימות, חסימות מבוססי מיקום גאוגרפי ועוד. ממשק ניהול של המוצר מאוד אינטואטיבי, מהיר ונוח וכולל מנוע דוחות ולוגים מהמתקדמים בתחום.למוצר הASM יש יכולת שרידות ע״י הפעלת אשכול של מס׳ מכונות. ניתן לקבל את המוצר הן על אפליינסים פיזים לפי רמת ביצועים והן את הגרסה הוירטואלית.

• Imperva SecureSphere

כל המוצרים של אימפרווה הם מוצרי אבטחת מידע. זאת ההתמחות של החברה והיא פועלת כיום בשלוש תחומים – הגנה על אפליקציות ושרתי ווב, הגנה על מסדי נתונים והגנה על הקבצים. SecureSphere הוא פתרון הWAF של אימפרווה והוא אחד הוותיקים בתחום. ניתן להתקין את המוצר בכל תצורת רשת. המוצר בנוי מרכיב ניהול ורכיב אכיפה אחד או יותר. למוצר יש יכולת לגדול ע״י הוספת עוד ועוד רכיבי אכיפה וגם הוא משלב את שני המודלים ויכולותיו הקשורים לאבטחת המידע ואכיפה מאוד דומים לזה של F5. בנוסף יש לחברה מס׳ שיתופי פעולה מעניינים כמו למשל התקנת רכיבי אכיפה על פלטפורמת קרוסבים של חברת בלוקואט.

• Foritnet FortiWeb

פורטנט היא שחקנית יחסית חדשה בתחום הWAF עם זאת מוצר הFortiWeb מכיל את כל היכולות אבטחת מידה של המתחרים בתוספת של יכולות בסיסיות לבקרת עומסים.ממשק שלו מבוסס על הממשק הFortiOS הידוע למי שעבד אי פעם עם ציודי פורטינט.ניתן לקבל את המוצר הן על אפליינסים פיזים לפי רמת ביצועים והן את הגרסה הוירטואלית.