מתקפת האקרים הפילה את אתר ToCode אתמול בבוקר. כך זה קרה.
הבוקר התחיל באופן שגרתי למדי: עמדתי מול כיתה בקורס פיתוח ווב ותכננתי להציג לתלמידים את חומרי הלימוד המקוונים של הקורס מאתר ToCode אך הדפדפן לא הצליח לפתוח את האתר. בהתחלה חשבתי שמדובר בבעיית תקשורת מקומית אז המשכתי לחומר הלימוד ותכננתי לבדוק את העניין לעומק בהפסקה.
1. תשע בבוקר: הפסקת קפה ראשונה
יחד עם הקפה של תשע התחלתי לנסות להכנס לשאר האתרים שלי המאוחסנים על אותו השרת וגיליתי שאף אחד מהם לא מגיב. נסיון להתחבר ב SSH לשרת נכשל ולכן החשד הבא היה שמדובר בתקלה ב Linode, ספק האחסון שלי. ממשק הניהול שלהם הראה שהשרת באוויר והכל תקין אז פתחתי פניה במערכת. עמוק בלב עדיין קיוויתי שמדובר בתקלת תקשורת מקומית ואנשים אחרים כן מצליחים להכנס לאתר.
לא עברו עשר דקות וקיבלתי תשובה לפניה בזו הלשון:
We are working on mitigating a large DDoS attack in London. There is no need to issue a reboot at this time as your Linode is still up.
במלים אחרות- אכן בעיית תקשורת אבל ממש לא מקומית.
2. מהי מתקפת DDoS
חלקנו מדמיינים האקרים כטיפוסים מאוד מתוחכמים שמצליחים בחשאי להכנס למערכות מחשב ולדלות מידע שאף אחד אחר לא יכול לגשת אליו. במתקפת DoS זה ממש לא המקרה. מתקפת מניעת שירות (או באנגלית Denial Of Service ובקיצור DoS) מבוססת על הרעיון שאם יש המון אנשים בכניסה לחנות שלכם, קונים פוטנציאליים לא יצליחו להכנס. בצורתה הקלאסית מחשב אחד שולח המון בקשות שנראות לגיטימיות לשרת, ומרוב העומס שכבת התקשורת לא מצליחה להעביר את כל הבקשות.
מתקפת DoS גם יחסית קלה למניעה: מאחר ומדובר בתוקף יחיד אפשר לחסום את כל בקשות הרשת שמגיעות מאותו מחשב באופן גורף. ממילא לגולש בודד אין את רוחב הפס של שרתים וחברות אחסון.
שדרוג המתקפה וביזורה כבר מציבים אתגר הרבה יותר גדול. הפעם מדובר בתוקף שהשתלט על מיליונים של מחשבים ברחבי העולם (באמצעות השתלת וירוסים ותוכנות שליטה). בהנתן הפקודה כל מיליוני המחשבים מתחילים לפנות לשרת הקורבן . תשתית הרשת שלא מצליחה להתמודד עם כל הבקשות מתחילה לזרוק בקשות לגיטימיות וכך אף אחד לא מצליח להכנס לאתר.
המתקפה הפעם נקראת מניעת שירות מבוזרת (או בשמה המקצועי Distributed Denial of Service ובקיצור DDoS). הפעם אין לנו דרך קלה ברמת הרשת לחסום את כל הבקשות פשוט בגלל שאי אפשר להבדיל בין גולשים אמיתיים לאותם מיליוני מחשבים שנמצאים תחת שליטת התוקף. אין גם שום פתרון ברמת התוכנה מאחר והמתקפה מתרחשת ברמת הרשת. אם יש לכם ראוטר שיודע להעביר 10 גיגה בשניה ותוקף שולח בקשות בנפח 11 גיגה בשניה, שום תוכנה שתוסיפו לא תצליח לסנן את כל הבקשות.
במקרה שלנו מתקפה מסוג זה על שרתי Linode בלונדון גרמו לאובדן תקשורת לשרתים. השרת באוויר אבל פקקי התנועה בדרך אליו גרועים בהרבה משיא הפקקים על איילון אחרי תאונה. הכביש חסום לגמרי.
3. למה שמישהו יעשה דבר כזה?
המניע העיקרי למתקפות DDoS הוא כלכלי. מספיק לאיים במתקפות מסוג זה כדי לשכנע חברות לשלם הרבה כסף לתוקף הפוטנציאלי. לפעמים צריך להוציא לפועל מתקפה או שתיים כדי להראות רצינות. מה שעצוב בסיפור הוא שכל פעם שחברה נכנעת ומשלמת התוקף משתמש בכסף כדי לקנות ציוד פריצה מתוחכם יותר ולהגדיל את כח המיקוח לקראת המתקפה הבאה.
במקרה שלנו אתר ToCode עצמו אינו יעד הסחיטה אלא ככל הנראה חברת Linode שממנה אני שוכר את השרת. כשלינוד מאבדים תקשורת כל האתרים שמאוחסנים אצלם מתנתקים גם.
4. התגוננות ממתקפות DDoS
ההתגוננות ממתקפת DDoS היא מורכבת ותלוית נסיבות. אם למשל אתם יודעים מי הגולשים שלכם אפשר לחסום באופן גורף גולשים לפי מאפיינים מסוימים, כך למשל אתרי בנקים בארץ נוהגים לחסום גישה מחו״ל בתקופות מתוחות. אבל זה לרוב לא ממש פרקטי.
אפשרות שניה היא לתחזק מראש תשתית תקשורת חזקה שיודעת לספוג מתקפות מסוג זה. כך עושים CloudFlare שמציעים פתרון הגנה ממתקפות מניעת שירות: כל המידע מנותב דרך הרשת של CloudFlare וכשיש מתקפה הרשת מספיק חזקה כדי לספוג את העומס, לעבד את המידע ולהעביר רק את הבקשות הרלוונטיות.
עבור אתר ToCode שמאוחסן על תשתית צד-שלישי שתי אפשרויות אלו פחות רלוונטיות. מה שכן מאחר והאתר מאוחסן על מכונה וירטואלית ניתן להגדיר שרת Fallback שיחליף את השרת הראשי במקרה של תקלת תקשורת או כל תקלה אחרת. אם נרכוש שרת גיבוי כזה מ Linode נוכל בלחיצת כפתור להחליף את כתובת ה IP בין השרת המרכזי לשרת הרזרבי, וכך גולשים ינותבו אוטומטית לשרת הרזרבי שיקבל את כתובת ה IP הראשית.
את השרת הרזרבי אפשר לאחסן גם מחוץ ל Linode בחברת אחסון אחרת, אבל אז לא ניתן יהיה להחליף את כתובות ה IP בלחיצת כפתור ונצטרך במקרה של נפילה לעדכן את שרתי ה DNS השונים שכתובת ה IP השתנתה. יש כלים שעושים זאת אוטומטית אך עדיין פתרון זה נחשב פחות אופטימלי מאחר ומחשבים של גולשים ״זוכרים״ רשומות DNS, כך שבמקרים מסוימים גולשים עדיין יגיעו לשרת הישן.
רוצים לשמוע עוד? FastMail לא נכנעו לאיומים, הותקפו וכתבו פוסט מאוד מעמיק על המתקפה ואפשרויות ההיערכות וההתגוננות:
https://blog.fastmail.com/2015/12/08/how-to-stop-a-ddos-attack/
וכמובן CloudFlare שמציעים שירותי הגנה ממתקפות כאלו יודעים להסביר מהי המתקפה ומה הפתרון שלהם:
https://www.cloudflare.com/ddos/