ADC - התרופה ללב דולף...

1. הדברים הידועים.

בשבוע שעבר התגלה באג במודול OpenSSL שאחראי על הצפנת SSL וTLS. מודול OpenSSL קיים ברב מערכות בפעלה של שרתי אינטרנט ורכיבים שעובדים עם הצפנות הללו. הפגיעות כתוצאה מהבאג קיבלה שם Heartbleed מכיין שהבאג מאפשר לקרוא את הזיכרון הפעיל של מערכות שמוגנות על ידי גרסאות של מערכת ההצפנה, אם אותה מערכת כוללת את התקלה הזו. 

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

למען הסר ספק, להלן הגרסאות הפגיעות:

• 1.0.1 עד 1.0.1f כולל
• 1.0.2 בטא

כל גרסת OpenSSL אחרת לא פגיעה לheartbleed. בנוסף, ב7 לאפריל יצאה גרסה 1.0.1g אשר מתקנת את הבאג.

מתחקיר שערכתי, הופתעתי לגלות כי הרבה שרתי ווב (ואני לא מדבר כרגע על הגדולים כמו גוגל,$M, פייסבוק וכו׳) בעולם עדיין רצים עם גרסה 0.9.8y שהיא הגרסה הכי ״מפוצ׳פצ׳ת״ של 0.9.8, או עם 1.0.0 (שרתי RHEL 6.4 בעיקר). זה כנראה נובע מיציבות השרת וממורכבות של שדרוגים במערכות גודולות ומורכבות. השרתים הפגיעים היו לרב שירותי ענן למינהם. הסיבה לכך כנראה קשורה לזה שרב שירותי הענן קמו בשנתיים אחרונות ובהקמתם השתמשו בשרתים חדשים יחסית (למשל RHEL 6.5 הפגיע).

2. איך מתגוננים מצד צרכן התוכן ?

בקצרה, אין כלכך מה לעשות בצד של הקליינט, אלה לחכות עד שהבאג יטופל בצד השרת (ע״י מפעיל של אותו שרת). אם מדובר באתר שגישה אליו מצריכה הזדהות, אני ממליץ להחליף ססמה בהקדם, to be on the safe side.

3. איך מגינים על שרתים (הדרך הארוכה)

טיפול בבעיה מסוג כזה מצריכה שינויים בשרתי הייצור. משמעות מעשית של תיקן בעיית Heartbleed היא התקנת גרסה מתוקנת של OpenSSL בשרת, ופעולה שכזאת מעלה בד״כ חששות (ובצדק!) למנהלים התפעולים של השרת, כגון יציבותה של הגרסה החדשה, תקלות משביתות בזמן שדרוג של הגרסה, בעיות באינטגרציה עם מודולים קיימים, בעיות של חסימות false positives ברכיבי אבטחת מידע ועוד. כל אחת מהבעיות האלה יכולה לגרום להפסד כסף ע״י הפסקת שירות לפרקי זמן שונים.

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

4. איך מתגוננים על שרתים (הדרך הקצרה)

השימוש בבקרי אספקת יישומים (Application Delivery Controllers – ADC) מבטל את הצורך בכל השלבים שתיארתי בסעיף הקודם, מאחר והבקרים בד״כ משתמשים במודולי הצפנה משלהם. בנוסף ישנם יצרנים, כמו למשל F5, אשר משלבים במוצרי ADC יכולות של Web Application Firewall – WAF שמאפשר איתור וחסימה של התקפה ע״י ניצול של באג Heartbleed )וכמובן, כל התקפת אפליקציה אחרת(. בכך הADC נותן אפשרות להמשיך ולרוץ עם שרת פגיע בייצור מבלי לבצע בו שיניים כלשהם. זה נותן ״אוויר״ לשילוב של תיקון לפגיעות בתוך לוח זמני תחזוקה רגילים בארגון.

יש כאלו שיגידו ״מה קצר בדרך הזאת ?״ - נכון, התקנה של ADC לקחת זמן (וכסף). אבל אני יכול להבטיח לכם שזה לא הבאג האחרון בשרתים, וגם לא ההתקפה האחרונה שמנצלת פגיעות כלשהי בשרת. לתווך ארוך, הADCים מצדיקים את ההשקעה, מאחר וחוץ מהיבט הבטחתי הם כמובן עושים את דברים שלהם יודע כגון בקרת עומסים, ssl offload, התמודדות עם התקפות DDoS וכו׳. מנסיוני, זאת לא הפעם הראשונה שADC מוכיחים את יעילותם בהתמודדות מול פגיעויות בשרתים ואני משוכנע שגם לא האחרונה.

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

אם אתם מעוניינים בעוד מידע על הנושא, אני וקולגות שלי בטלדור ישמחו לדבר איתכם על זה.

קובי ט

kobit@taldor.co.il

www.taldor.co.il

מכללת טרביצקי| פרק שני - DAF

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

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

מה זה מסד/בסיס נתונים ?

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

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

מהי חומת האש של מסד נתונים ?

חומות אש של מסד הנתונים (DAF - Database Firewalls) הן סוג של חומות אש אפליקטיביות העוקבות אחר מסדי נתונים כדי לזהות ולהגן מפני התקפות ספציפיות למסדי נתונים אשר בעיקר מבקשים לגשת למידע רגיש המאוחסן במאגרי המידע. DAF מאפשר גם לפקח ולבקר את כל הגישה לבסיס נתונים באמצעות היומנים. DAF יכול ליצור דוחות תאימות ספציפיים לתקנות, כגון PCI, SOX ועוד.

DAF הוא בדרך כלל שרת (אפליינס) או תוכנה מוקשחים שיכולים להיות מותקים גם באינליין מול שרת מסד הנתונים (ממש לפני ששרת מסד הנתונים או בקרבת הנתב/פיירוול רשתי כאשר הוא מגן על מסדי נתונים במספר רב של שרתים). בחלק ממוצרי DAF נותן להתקין אייג׳נט על שרתי מסד נתונים עצמם, כדי לפקח על אירועי מסד נתונים המקומיים. צורת התקנה נוספת היא בעזרת שיכפול תעבורה במתג וביצוע סניפינג ע״י DAF. בתצורה זאת ניתן לחסום עבירות ע״י שליחת פאקטת TCP Reset.

איך DAF עוזר בהגנה על איומים והתקפות ?

בדרך כלל, DAF כולל סט של חוקי audit המוגדרים מראש וניתנים להתאמה אישית, והם יכולים לזהות התקפות מסד נתונים המבוססים על דפוסי תקריות / איומים שנקראים 'חתימה'. לכן, הDAF משווה שאילתות SQL אל מול החתימות אללו, המתעדכנים בתדירות גבוהה על ידי היצרנים כדי לזהות התקפות ידועות במסד הנתונים (משימות רבות בתוך מסד נתונים מבוצעות כסדרה של שאילתות SQL).

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

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

הזרקת SQL וBuffer Overflow הם הסוגים נפוצים של התקפות על מסד נתונים וDAFים יכולים לחסום התקפות כאלה. לפעמים, פרטי גישה גנובים עלולים לגרום לנסיונות פריצה למסד נתונים, אבל מאחר וDAF מנטר את הפעילות החשודה כל הזמן, הוא יזהה ניסיונות כאלה.

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

ההמלצות ליישום מוצלח של הגנה על מסד נתונים:

• השתדלו לתת לעובדים ומשתמשים הרשאות גישה שונות למסד נתונים (קריאה בלבד לעומת הוספה / מחיקה רשומות, לדוגמא).
• ניתן למחוק חשבונות שאינם בשימוש ומומלץ להימע משימוש בחשבונות משותפים בגישה למסדי נתונים.
• מומלץ להצפין תוכן רגיש לפני אחסונו בתוך מסד נתונים
• מומלץ לנטר או להגביל גישה של משתמשים עם הרשאות גבוהות (לרוב DBA) לאיזורים רגישים של מסד נתונים (למשל משכורות העובדים).
• ניתן להפעיל הזדהות מרחוק (LDAP או RADIUS) למשתמשים במסד נתונים וכך המשתמשים הללו יקבלו רמת הרשאות בהתאם לשיוכם לקבוצות מדיניות בשרתי ההזדהות.

סקירה קצרה של מוצרי DAF

אני מקווה שבעתיד אני אבצע סקירות יותר מעמיקות למוצרים. אבל כרגע זה יהיה קצר.

• Imperva SecureSphere DAS

בעיניי זה אחד המוצרים הכי טובים והכי ותיקים בשוק. המוצר תומך ברוב מסדי נתונים הקיימים היום בשוק וניתן להתקינו בכל מצב עבודה אפשרי (כולל התקנת אייג׳נט). המוצר מורכב משרת ניהול (MX) ושרת אכיפה אחד או יותר (GW). המוצר מגיע עם סטים של חוקים לצרכים ביצוע auditים, סקרים והכנות לביקורות מסוגים שונים. מבחינת יכולות אכיפה ומדיניות זהו אחד המוצרים הכי גמישים לניהול ותפעול.ניתן לקבל את המוצר באפליינס או כמכונה וירטואלית

• GreenSQL

שחקן ישראלי צעיר ורענן בתחום. למעשה קיימים שני מוצרים – אחד קוד-פתוח חינמי והשני - מסחרי עם יותר יכולות ותמיכה טכנית (מעולה, יש לומר). ניתן לקבל את המוצר כהתקנת של תוכנה בלבד (שרת וירטאלי). המוצר מגן על מסדי נתונים של חברת מיקרופט,PostgreSQL,MySQL וmariaDB. למוצר יש יכולות מיוחדות כגון ביצוע caching וmasking לשאילתות SQL. היום מדובר במוצר בשל והתקנתו ותפעולו קלים יחסית.

• (Sentrigo Hedgehog (McAfee

מוצר של חברת סנטריגו (שנמכרה למקאפי ב-2011) מגן על מסדי נתונים כגון Oracle,MSSQL וsybase. הDAF הזה כולל קליינט שמותקן על שרתי מסד נתונים וקונסולת ניהול שמתקשרת עם הקליינטים. הקליינט מתריע לשרת הניהול במקרה של עבירה וזה מציג אותה למנהל.

• Fortinet FortiDB

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

אי שוויון לכולם

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

אני ממליץ בחום לראות את הסרט (שודר ביס דוקו). תנסו בvod או אצל הדוד מאמריקה.

מכללת טרביצקי| פרק ראשון - 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 הידוע למי שעבד אי פעם עם ציודי פורטינט.ניתן לקבל את המוצר הן על אפליינסים פיזים לפי רמת ביצועים והן את הגרסה הוירטואלית.

מכללת טרביצקי

היום החלטתי לעשות מעשה.
לאחרונה יצא לי לדבר עם כמה אנשי networking (וגם כמה אנשי אבטחת מידע, אבל אל תגלו...) ושמתי לב שהיום כמעט אין איש שמתעסק בתחום התקשורת ולא יודע מה זה Firewall או איך הFirewall פועל. לאומת זאת לרוב, כשמתחילים לדבר על WAF, application security לאנשים אין מושג על מה אני מדבר.
אתם בוודאי תגידו ״נו, אז מה הבעיה. איש נטוורקינג לא אמור להתעסק עם ציודי אבטחה. אולי זה יתרום להרחבת אופקים אבל אין לזה שום משמעות למה שאנשי נטוורקינג עושים״ - לא נכון!
האנשים הללו (ואני מדבר גם על הטכנאי רשת שמוסיף vlan וגם על הארכיטקט שבונה רשת חדשה) מעורבים בבניית תשתית או קבלת החלטות להכנת תשתית עבור רכיבי applicaiton security. לעתים, מחסור בידע טכנולוגי גורם לקבלת החלטות שמשליכות על אופן הטמעה של מוצר application securty כזה או אחר. בהרבה מקרים התוצאה של החלטה הזאת תשפיע על יעילות המוצר ואמינותו. לא פעם ראיתי לקוחות מחליפים מוצר app securty מעולה רק בגלל שגיאות שנעשו בתכנון הסביבה ובחירת תצורה שלא מתאימה להם.
על מנת לנסות ולשנות את המצב אני מתכוון לפרסם פוסטים שמסבירים ברמה בסיסית על טכנולוגיות של application security.
אני מקווה שאני אצליח לחדש או לסדר את הדברים בראש.
אה, ואם אתם מוזמנים להעיר לי או לתת הצעות לשיפור.

הפוסט הראשון בסדרה - WAF

תהנו,

קובי.

OpIsrael - סיכום ביניים

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

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

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

קובי.