מתקפת DDoS: מה זה, איך מזהים ואיך מגינים על האתר

מה זה מתקפת DDoS

מתקפת DDoS (Distributed Denial of Service, מניעת שירות מבוזרת) היא ניסיון להשבית אתר או שירות על ידי הצפה שלו בתעבורה. המילה החשובה היא מבוזרת: התעבורה לא מגיעה ממחשב אחד, שאפשר פשוט לחסום, אלא מאלפי מכשירים בו זמנית.

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

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

הסוגים: הצפות רשת מול הצפות HTTP

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

שכבות 3 ו‑4: הצפות רשת

כאן התוקף לא מתעניין באתר עצמו, אלא בצינור שמוביל אליו:

• הצפות נפח: כמויות עצומות של חבילות, למשל UDP, שממלאות את חיבור הרשת של השרת. שיטה נפוצה היא Amplification (הגברה): התוקף שולח בקשות קטנות לשרתים פתוחים באינטרנט, כמו שרתי DNS, ומזייף את כתובת השולח, כך שהתשובות, הגדולות בהרבה, נשלחות אליכם.
• SYN Flood: ניצול של תהליך פתיחת החיבור ב‑TCP. התוקף מתחיל אינספור חיבורים ולא משלים אותם, עד שהשרת לא מסוגל לקבל חיבורים חדשים.

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

שכבה 7: הצפות HTTP

כאן הבקשות נראות כמו גלישה רגילה: בקשות HTTP תקינות לעמודי האתר. הן לא חייבות להיות רבות במיוחד, רק יקרות. התוקף מכוון לעמודים שהשרת בונה מחדש בכל פעם: חיפוש באתר, עגלה, עמוד הכניסה, xmlrpc.php בוורדפרס, או כתובות עם פרמטר אקראי (?x=83421) שעוקפות את הקאש. כל בקשה כזו מפעילה PHP ומסד נתונים, ושרת שנבנה לתנועה רגילה נכנע להן מהר.

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

מתקפה או עלייה אמיתית בתנועה?

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

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

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20
awk '{print $4}' access.log | cut -d: -f1-3 | uniq -c | tail -20

אם האתר כבר מאחורי Proxy כמו Cloudflare, ודאו שהשרת רושם את כתובת הגולש האמיתית ולא את כתובת ה‑Proxy. אחרת כל הבקשות ייראו כאילו הגיעו מכמה כתובות בודדות.

איך ההגנה עובדת

הגנה טובה בנויה משכבות, וכמעט כולה פועלת לפני השרת.

Proxy או CDN לפני השרת

שירות כמו Cloudflare עומד בין הגולשים לשרת: הגולשים מתחברים לרשת שלו, והוא מעביר לשרת רק את הבקשות שעברו סינון (הסברנו את המודל הזה במדריך על Cloudflare). הרשת שלו מפוזרת בהרבה מרכזי נתונים, עם קיבולת גדולה בהרבה מזו של כל שרת בודד. הצפות הרשת נבלעות שם, ורק בקשות HTTP ממשיכות לשרת שלכם.

הסתרת כתובת השרת

כל זה עובד רק אם התוקף לא יודע את כתובת ה‑IP האמיתית של השרת. אם הוא יודע, הוא תוקף אותה ישירות ועוקף את ה‑Proxy. לכן חומת האש של השרת מקבלת תעבורה לאתר רק מטווחי הכתובות של ה‑Proxy, ובודקים שאין רשומות DNS שמצביעות לאותו שרת בלי Proxy, כמו mail או ftp.

קאש

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

הגבלת קצב, WAF ואתגרים

• Rate Limiting (הגבלת קצב): כתובת ששולחת לעמוד מסוים יותר בקשות מהסף שהגדרתם, בפרק זמן מסוים, נחסמת או מאותגרת לזמן קצוב. מתאים במיוחד לעמוד הכניסה, לחיפוש ולטפסים.
• WAF (Web Application Firewall, חומת אש לאתרים): חוקים שבודקים את תוכן הבקשה, ומאפשרים לחסום דפוס מדויק של מתקפה: נתיב, שיטת בקשה, דפדפן מזויף או רשת מסוימת.
• Challenge (אתגר): במקום לחסום, ה‑Proxy בודק שמולו דפדפן אמיתי. גולש אנושי עובר בלי לשים לב או בלחיצה אחת, ורוב הבוטים נעצרים. מצב Under Attack Mode של Cloudflare מפעיל אתגר כזה על כל האתר.

דוגמה לחוק ב‑Cloudflare, עם הפעולה Managed Challenge, שמאתגר כל מי שפונה לעמוד הכניסה של וורדפרס:

(http.request.uri.path eq "/wp-login.php")

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

מה עושים בזמן מתקפה

1. מוודאים שזו מתקפה: בודקים בלוגים ובלוח הבקרה של ה‑Proxy מאיפה מגיעה התעבורה ולאילו עמודים, לפי הטבלה שלמעלה.
2. מעלים את רמת ההגנה: מפעילים Under Attack Mode, או אתגר רק לעמודים המותקפים. זה קונה זמן.
3. מוצאים את הדפוס וכותבים חוק מדויק: עמוד מסוים, דפדפן מזויף, רשת או מדינה שאין לכם בה לקוחות. חוק מדויק עוצר את המתקפה בלי לפגוע בגולשים.
4. מגבילים קצב בעמודים היקרים: חיפוש, כניסה, טפסים ו‑API.
5. מרחיבים את הקאש, לפחות זמנית, למשל לעמוד הבית ולעמודי הנחיתה של הקמפיין.
6. בודקים שהשרת לא נגיש ישירות: אם המתקפה ממשיכה להגיע לשרת למרות ה‑Proxy, כנראה שהכתובת שלו ידועה. חוסמים בחומת האש כל מי שאינו ה‑Proxy, ושוקלים להחליף כתובת.
7. מדברים עם ספק האחסון: הוא רואה את התעבורה ברמת הרשת, ולעיתים יכול לעזור לזהות ולחסום אותה עוד לפני השרת.

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

טעויות נפוצות

• Proxy עם כתובת חשופה: האתר מאחורי Cloudflare, אבל רשומת DNS בלי Proxy, הכותרות של מיילים שהאתר שולח או היסטוריית DNS מגלות את כתובת השרת. ההגנה קיימת רק על הנייר.
• Under Attack Mode לתמיד: אתגר בכל כניסה מעצבן גולשים, ועלול לחסום שירותים שמתחברים לאתר בלי דפדפן, כמו הודעות מחברת הסליקה, אפליקציות ושירותי ניטור. מפעילים אותו בזמן מתקפה, ומכבים אחריה.
• חסימה גורפת של מדינות: היא חוסמת גם לקוחות בחו"ל ואת הסורקים של גוגל, ולא עוצרת בוטים שנמצאים בישראל. עדיף אתגר, ורק לעמודים הרגישים.
• הגבלת קצב קשוחה מדי: בסלולר ובמשרדים, גולשים רבים יכולים לצאת לאינטרנט מאותה כתובת IP. סף נמוך מדי חוסם את כולם יחד.
• השרת לא רואה את כתובת הגולש: אם השרת לא מוגדר לקרוא את הכתובת האמיתית מהכותרת שה‑Proxy מוסיף, תוסף אבטחה בשרת עלול לחסום את כתובות ה‑Proxy, ואיתן את כל הגולשים.
• שרת חזק יותר במקום הגנה: שדרוג משאבים עוזר מול עלייה אמיתית בתנועה, אבל מול מתקפה הוא רק דוחה את הקריסה, ובענן שמתרחב אוטומטית גם מייקר את החשבון.

בשורה התחתונה

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