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

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

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

במדריך הזה נסביר:

• מה זו מתקפת DDoS ואיך היא בנויה;
• למה גם עסקים קטנים בישראל צריכים להתייחס לנושא;
• אילו סוגי מתקפות קיימים ומה ההבדל ביניהם;
• איך מבדילים בין מתקפה לעומס רגיל;
• אילו שכבות הגנה באמת עובדות, ב-Webflow, ב-WordPress וב-Wix;
• מה עושים ברגע שהאתר קורס.

מה זו מתקפת DDoS ואיך היא עובדת

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

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

מה זה בוטנט

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

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

למה קשה כל כך לעצור אותה

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

מי תוקף ולמה זה נוגע גם לעסק קטן

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

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

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

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

שלושת הסוגים העיקריים של מתקפות

נהוג לתאר תקשורת ברשת באמצעות מודל OSI, שמחלק אותה לשבע שכבות. מתקפות DDoS מתרכזות לרוב בשלוש קבוצות, ולכל אחת נדרשת הגנה אחרת.

מתקפות נפח על רוחב הפס

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

מתקפות על הפרוטוקול

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

מתקפות על שכבת היישום

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

שלוש מתקפות שכדאי להכיר

בשנת 2000 נער בן 15 מקנדה, שכונה Mafiaboy, הפיל לזמן מה אתרים של Yahoo, eBay, Amazon ו-CNN. המקרה הזה הפך את הנושא לדיון ציבורי ראשון מסוגו.

באוקטובר 2016 בוטנט בשם Mirai, שהורכב בעיקר ממכשירי IoT, תקף את ספקית ה-DNS בשם Dyn. אתרים כמו Twitter, Netflix ו-Reddit הפכו בלתי נגישים לחלק מהמשתמשים, אף שהם עצמם לא הותקפו ישירות. הלקח: גם DNS הוא נקודת כשל.

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

איך מבדילים בין מתקפה לעומס רגיל

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

סימנים שמעידים על מתקפה:

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

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

שכבות ההגנה שבאמת עובדות

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

CDN ורשת קצה

רשת CDN מפזרת את האתר על שרתים ברחבי העולם, ולכן גם סופגת נפח תעבורה שאף שרת בודד לא היה עומד בו. ספקים כמו Cloudflare, Akamai ו-Fastly מסננים תעבורה בקצה, לפני שהיא מגיעה אליכם. כיתרון נוסף, האתר נטען מהר יותר בשגרה. ב-Cloudflare גם התוכנית החינמית כוללת הגנת DDoS בלי הגבלת נפח, ולכן לרוב האתרים זו נקודת התחלה טובה.

חומת אש ליישומים (WAF) והגבלת בקשות

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

לטפסים ולדפי התחברות אפשר להוסיף גם אתגר שקוף למשתמש, כמו Cloudflare Turnstile. אם אתם מפעילים CAPTCHA, ודאו שהוא נגיש ועומד בדרישות ת"י 5568.

הסתרת כתובת ה-IP של השרת

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

מטמון, קיבולת וגיבויים

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

כלים לפי גודל העסק

• אתרי תדמית ועסקים קטנים: Cloudflare או ההגנה המובנית בפלטפורמה לרוב מספיקות.
• חנויות ואפליקציות על ענן: AWS Shield (הגרסה הבסיסית כלולה ב-AWS ללא תוספת תשלום) ו-Google Cloud Armor.
• ארגונים ואתרים קריטיים: Akamai, Imperva או Radware הישראלית, בדרך כלל עם צוות תגובה 24/7.
• ניטור: UptimeRobot או Better Stack כדי לדעת על נפילה לפני הלקוחות, ו-Netdata או Grafana למדדי השרת.

טעויות נפוצות בהגנה

• חסימה גורפת של תעבורה מחו"ל. זה נראה פתרון פשוט, אבל הוא חוסם גם את Googlebot, סורקים של Meta, ספקי תשלום וישראלים בחו"ל. אם חוסמים לפי מדינה, הגדירו חריגים מדויקים.
• הסתמכות על תוסף בלבד. תוסף רץ על אותו שרת שמותקף. הוא יכול לחסום בוטים, אבל לא לספוג הצפה.
• בדיקת עומסים על אתר בלי תיאום. ספק האחסון עלול לזהות אותה כמתקפה ולחסום אתכם.
• אין מי שמחזיק את המפתחות. כשהאתר נופל בשבת בבוקר, צריך לדעת מי נכנס ל-DNS ול-CDN ואיפה הגישות שמורות.

מה משתנה ב-Webflow, ב-WordPress וב-Wix

Webflow ו-Wix: האחריות העיקרית על הספק

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

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

WordPress: הרבה יותר בידיים שלכם

אתר WordPress תלוי באחסון שבחרתם ובהגדרות שלכם. כדאי לבצע לפחות את הפעולות הבאות:

• לחבר את האתר לרשת CDN ולוודא שהשרת מקבל תעבורה רק ממנה;
• להפעיל מטמון דפים כדי שלא כל ביקור יפעיל PHP;
• להגביל ניסיונות כניסה ל-wp-login.php ולכבות את xmlrpc.php אם אין בו צורך;
• לעדכן ליבה, תבנית ותוספים, ולהסיר תוספים שאינם בשימוש;
• להשתמש בתוסף כמו Wordfence או Solid Security לחסימת בוטים וסריקות;
• לבחור אחסון שמספק הגנת DDoS ברמת הרשת ולא אחסון משותף עמוס.

מה עושים ברגע שהאתר תחת מתקפה

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

• מאמתים שזו מתקפה. בודקים לוגים, את לוח הבקרה של ה-CDN ואת דף הסטטוס של הספק.
• פונים לספק האחסון או ה-CDN. לעתים קרובות הם רואים את המתקפה ויכולים לסנן אותה מהר יותר מכם.
• מפעילים מצב הגנה. ב-Cloudflare זה Under Attack Mode, ואצל ספקים אחרים הגדרה דומה.
• מקשיחים את הדפים המותקפים. הגבלת קצב, אתגר לדפים הכבדים, כיבוי זמני של החיפוש או הסינון.
• עוצרים קמפיינים. אין טעם לשלם על קליקים לדף שלא נטען.
• מעדכנים לקוחות. הודעה קצרה ברשתות או בוואטסאפ העסקי, עם טלפון לפניות דחופות.
• מדווחים ומתעדים. אפשר לפנות למערך הסייבר הלאומי בטלפון 119 ולהגיש תלונה במשטרה. אל תמחקו לוגים.
• בודקים פריצה אחרי שהכול נרגע. לעתים מתקפה משמשת מסך עשן לפעולה אחרת. אם יש חשד שנחשף מידע אישי, התייעצו עם עורך דין לגבי חובת הדיווח לפי חוק הגנת הפרטיות.

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

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

איך RJL Studio עוזרת להכין את האתר מראש

אנחנו בונים, מחברים ומתחזקים אתרים על Webflow, WordPress ו-Wix, ודואגים שההגנה תהיה חלק מהתשתית ולא מחשבה מאוחרת. בתהליך אנחנו מחברים CDN, מגדירים WAF והגבלת בקשות, מסתירים את כתובת השרת, מגינים על טפסים ועל אינטגרציות עם CRM, בונים ניטור וגיבויים, וכותבים לכם תוכנית פעולה קצרה עם מי מתקשרים ומה עושים.

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

שאלות נפוצות על מתקפות DDoS

האם מתקפת DDoS גונבת מידע?

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

האם התוכנית החינמית של Cloudflare מספיקה?

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

האם מתקפה תפגע בדירוג שלי בגוגל?

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

האם אתר קטן באמת יכול להיות מטרה?

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

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

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