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

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

אילו סוגים של מתקפות DDoS קיימים?

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

• מתקפות נפחיות (Volumetric)

  מציפות את הקו בכמות עצומה של תעבורה, בדרך כלל UDP. הנפוצות הן מתקפות הגברה (amplification): התוקף שולח שאילתה קטנה לשרת DNS, NTP או memcached פתוח עם כתובת מקור מזויפת, והתשובה הגדולה בהרבה נוחתת אצלכם. נמדדות בביטים לשנייה.

• מתקפות פרוטוקול

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

• מתקפות אפליקציה (L7)

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

למה עסקים ישראליים מותקפים ב-DDoS?

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

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

אילו שכבות הגנה עוצרות מתקפת DDoS?

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

מה זה הגנת DDoS ברמת הרשת?

זו מערכת אצל הספק או אצל שירות ייעודי שמזהה דפוסי מתקפה בתעבורה הנכנסת ומסננת אותם בקצה הרשת, לפני שהם מגיעים לשרת. היא רואה את כל התעבורה ליעד, יש לה קיבולת גדולה בהרבה משל שרת בודד, והיא יכולה לזרוק תעבורת הגברה ו-SYN floods בלי שהשרת ירגיש. שרתי הענן שלנו כוללים הגנת DDoS ברמת הרשת, וזה הבסיס. כשאתם בוחרים ספק, שאלו במפורש: האם הסינון פעיל תמיד או מופעל ידנית, מה קורה כשמתקפה גדולה מהקיבולת (חלק מהספקים פשוט מנתקים את ה-IP המותקף כדי להגן על שאר הלקוחות), ומי מטפל בזה באמצע הלילה.

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

איך CDN ו-WAF מגנים על אתר ממתקפת DDoS?

CDN או reverse proxy עם הגנת DDoS יושב בין הגולשים לשרת: כל הבקשות מגיעות אליו, והוא מעביר לשרת רק את מה שנראה לגיטימי. יש לו רשת מבוזרת עם קיבולת עצומה, מטמון שעונה על רוב הבקשות בלי לגעת בשרת, ו-WAF שיודע להציג אתגר JavaScript או CAPTCHA לתעבורה חשודה. זו השכבה הכי אפקטיבית נגד מתקפות L7 על אתרים.

שתי מגבלות שכדאי להכיר. הוא מגן רק על מה שעובר דרכו - בדרך כלל HTTP ו-HTTPS. ושירות אחר על אותו IP, כמו שרת דואר או SSH, נשאר חשוף. מכאן הסעיף הבא.

איך מסתירים את כתובת ה-IP של השרת?

אם התוקף יודע את כתובת ה-IP האמיתית של השרת (ה-origin), הוא תוקף אותה ישירות וה-CDN לא עוזר בכלום. כתובות דולפות דרך:

• היסטוריית DNS - אם האתר רץ פעם בלי CDN, שירותי היסטוריית DNS זוכרים את הכתובת. אחרי שעוברים ל-CDN כדאי לשקול החלפת IP.
• רשומות MX ותת-דומיינים - mail.example.co.il או ftp שמצביעים ישירות לאותו שרת. העבירו דואר לשירות נפרד.
• כותרות מיילים - מייל שנשלח מהשרת (טופס צור קשר, אישור הזמנה) עלול לכלול את ה-IP בכותרת Received. שלחו דרך שירות SMTP חיצוני.
• תעודות TLS - סורקים שמחפשים את התעודה שלכם על פני כל טווח הכתובות.

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

איך מגדירים הגבלת קצב ב-Nginx נגד DDoS?

משתמשים במודולים limit_req ו-limit_conn, שמגבילים כמה בקשות וכמה חיבורים מותרים לכל כתובת IP. זה לא יעצור בוטנט של עשרות אלפי כתובות, אבל זה עוצר בוט בודד, סקריפט אגרסיבי ומתקפות L7 קטנות - שהן רוב מה שקורה בפועל. בבלוק http:

limit_req_zone  $binary_remote_addr zone=perip:10m   rate=10r/s;
limit_req_zone  $binary_remote_addr zone=login:10m   rate=10r/m;
limit_conn_zone $binary_remote_addr zone=connperip:10m;
limit_req_status  429;
limit_conn_status 429;

client_body_timeout   10s;
client_header_timeout 10s;
keepalive_timeout     15s;
send_timeout          10s;

ובבלוק ה-server:

location / {
    limit_req  zone=perip burst=40 nodelay;
    limit_conn connperip 30;
    # ...
}

location = /wp-login.php {
    limit_req zone=login burst=5;
    # ...
}

הערכים כאן הם נקודת התחלה. עמוד אחד באתר מודרני מושך עשרות קבצים, ולכן ה-burst צריך להיות נדיב; אם המשאבים הסטטיים מוגשים מ-CDN, אפשר להדק. בדקו את הלוג אחרי ההפעלה: שורות limiting requests של גולשים אמיתיים אומרות שהגבול נמוך מדי.

בצד מערכת ההפעלה, ודאו ש-SYN cookies פעילים (ב-Ubuntu הם פעילים כברירת מחדל): sysctl net.ipv4.tcp_syncookies צריך להחזיר 1. זה מאפשר לשרת לשרוד SYN flood קטן בלי שטבלת החיבורים תתמלא.

האם fail2ban עוזר נגד DDoS?

נגד מתקפות L7 קטנות ובינוניות - כן; נגד מתקפות נפחיות - לא. fail2ban קורא את הלוג של Nginx, מזהה כתובות שחורגות שוב ושוב מהגבלת הקצב וחוסם אותן בחומת האש לזמן מוגדר. כך תוקף שנחסם ב-429 לא ממשיך לצרוך משאבים של Nginx. fail2ban מגיע עם פילטר מוכן בשם nginx-limit-req:

# /etc/fail2ban/jail.d/nginx-ddos.local
[nginx-limit-req]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/error.log
findtime = 1m
maxretry = 20
bantime  = 1h

sudo systemctl restart fail2ban
sudo fail2ban-client status nginx-limit-req

המגבלה: fail2ban מוסיף חוק iptables לכל כתובת. מול בוטנט של עשרות אלפי כתובות, הוא יתקשה לעמוד בקצב. הוא כלי טוב לרעש היומיומי, לא קו ההגנה הראשי. ההגדרות הבסיסיות שלו מופיעות בצ'קליסט אבטחת שרת לינוקס.

האם Autoscaling מחליף הגנת DDoS?

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

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

מה עושים כשהשרת תחת מתקפת DDoS?

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

1. לוודא שזו באמת מתקפה. לפעמים "מתקפה" היא קמפיין שיווקי שהצליח, cron שהשתגע או בוט סריקה של מנוע חיפוש. בדקו גרפי תעבורה, ss -s לכמות החיבורים ואת הכתובות הנפוצות בלוג: awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head.
2. לזהות את הסוג. קו מלא ושרת שכמעט לא עובד - נפחית. הרבה חיבורים במצב SYN_RECV - פרוטוקול. Nginx ו-PHP עמוסים עם בקשות לכתובות מסוימות - L7.
3. לפנות לספק מיד. במתקפה נפחית או פרוטוקול זה הצעד היחיד שבאמת משנה. תנו להם את ה-IP המותקף, שעת התחלה ומה ראיתם.
4. להדק את ה-CDN וה-WAF. במתקפת L7, הפעילו מצב הגנה מוגבר או אתגר לכל הגולשים, וחסמו את הנתיבים או המדינות שמהם מגיעה המתקפה.
5. להוריד עומס מהשרת. הדקו זמנית את הגבלת הקצב, הגישו עמוד סטטי לנתיבים כבדים, כבו זמנית חיפוש או פיצ'רים יקרים.
6. לתקשר. עדכנו לקוחות בערוץ שלא תלוי באתר (רשתות חברתיות, מייל). ודאו שמספר הטלפון לתמיכה ידוע לכולם בצוות.
7. לתעד. שעות, כתובות, נפחים, צילומי מסך של גרפים, ואם הגיעה דרישת כופר - את ההודעה. דווחו למערך הסייבר הלאומי בקו 119.
8. לסכם אחרי. מה עבד, מה לקח יותר מדי זמן, איזה IP דלף. מתקפות חוזרות לעתים קרובות, וההגנה שתוסיפו השבוע היא זו שתעבוד בפעם הבאה.

מה הצ'קליסט להגנה מפני DDoS?

• ספק עם הגנת DDoS ברמת הרשת, ותשובה ברורה למה קורה כשהמתקפה גדולה מהקיבולת.
• CDN או WAF מול האתר, ו-80/443 בשרת פתוחים רק לטווחי ה-CDN.
• כתובת ה-origin לא מופיעה ב-DNS, ב-MX או בכותרות מיילים.
• הגבלת קצב וחיבורים ב-Nginx, timeouts קצרים ו-real_ip מוגדר נכון.
• fail2ban עם nginx-limit-req, SYN cookies פעילים.
• מטמון עמודים לאתר, ותקרה ל-Autoscaling אם יש.
• תוכנית תגובה כתובה, עם טלפונים של הספק ושל מי שמחליט.

אין לכם צוות שזמין בשתיים בלילה כשמתקפה מתחילה? בענן המנוהל הניטור והתגובה לאירועים באחריות הצוות שלנו (תמיכה טכנית 24/7).