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