כיצד להפעיל את מצב "Under Attack" של Cloudflare באתר תחת מתקפת DDoS?

מצב "Under Attack" של Cloudflare באתר הנמצא תחת מתקפת DDoS הוא הגדרה דחופה המסננת תנועת רובוטים על ידי הצגת אימות קצר למבקרים. על ידי בחירת האתר שלך בלוח הבקרה של Cloudflare והפעלת מצב Under Attack מתוך מחלקת האבטחה, תוכל להאט את הבקשות הכבדות ברמת HTTP/HTTPS תוך דקות ספורות, להגן על הגישה של משתמשים אמיתיים לאתר ולהפחית את העומס על השרת שלך. עם זאת, מצב זה אינו פתרון קבוע בפני עצמו; יש להשתמש בו יחד עם הגדרות פרוקסי DNS נכונות, כללי WAF, הגבלת קצב, תצורת קאש ואבטחת השרת המקורי.

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

מהו מצב "Under Attack" של Cloudflare?

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

המטרה העיקרית של מצב זה היא להפחית מתקפות ברמת שכבת היישום, כלומר בשכבת 7. לדוגמה, אם יש אלפי בקשות GET לדף הבית בשנייה, ניסי POST מרובים לדף הכניסה של וורדפרס, שאילתות יקרות לדף החיפוש או תנועת שקר לדף הסל, מצב Under Attack מספק התערבות ראשונית מהירה.

ההבחנה החשובה כאן היא: מצב Under Attack מסנן בקשות אינטרנט; עם זאת, אם כתובת ה-IP של השרת שלך היא המטרה הישירה, או אם השירותים שלך מחוץ לפרוקסי של Cloudflare חשופים, או אם המתקפה מתבצעת בשכבת 3/4, יש צורך באמצעי זהירות נוספים. לכן, חיוני לשמור על רשומות ה-DNS במצב פרוקסי דרך Cloudflare, להסתיר את כתובת ה-IP המקורית ולהחיל את אמצעי האבטחה הנכונים בצד ההוסטינג. ניתן לקשר לתכנים על בחירת תשתית בטוחה שירותי הוסטינג אתר בטוחים ו[יç-link: התקנת תעודת SSL].

סימני מתקפת DDoS: מה לבדוק לפני שמפעילים את מצב Under Attack?

לא כל האטה היא DDoS. לפעמים תוסף פגום, נעילה של מסד נתונים, משימת cron שצורכת CPU גבוה או הגדרות קאש שגויות יכולות לגרום לתוצאות דומות. לכן, לפני הפעלת מצב Under Attack, כדאי לבצע אבחון מהיר. אם השרת מתקשה להגיב, המשתמשים מקבלים שגיאות 502, 503, 504 ויש התפרצות לא רגילה של בקשות ביומנים, יש להפעיל את המצב החירומי מיידית.

סימנים טיפוסיים למתקפת DDoS

• עלייה בתנועה של 5, 10 או 50 פעמים מהרגיל בפרק זמן קצר.
• קבלת מאות בקשות לדף או לנקודת קצה אחת בשנייה.
• תנועת נתונים ממדינות שונות אך עם ערכי user-agent דומים.
• מיקוד בבקשות יקרות כמו admin, login, search, cart ב-WooCommerce, OpenCart או תוכנה מותאמת אישית.
• מילוי מגבלות CPU, RAM, PHP-FPM worker או חיבורי MySQL בשרת.
• עלייה פתאומית בשגיאות 4xx ו-5xx במסך הניתוחים של Cloudflare.
• משתמשים אמיתיים יכולים לגשת לאתר באופן לא רציף, אך תנועת רובוטים שולחת בקשות ללא הפסקה.

לדוגמה, אם אתר מסחר אלקטרוני שמקבל בדרך כלל 2,000 בקשות בדקה, שיגביר את הבקשות ל-80,000 בדקה תוך 10 דקות, ו-70% מהבקשות הולכות לדף הסל או החיפוש, זו אינדיקציה ברורה למתקפה ברמת שכבת 7. במקרה זה, יש להפעיל את מצב Under Attack ב-5 הדקות הראשונות, ולאחר מכן להוסיף כללי WAF והגבלת קצב לנקודות היעד.

מתי יש להשתמש במצב Under Attack של Cloudflare?

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

מצבים מתאימים לשימוש

• אם יש תנועת HTTP/HTTPS אינטנסיבית ולא נורמלית לאתר.
• אם משאבי השרת מתמלאים במהירות ושגיאות 502/503 גוברות.
• אם ה-WAF של Cloudflare עדיין לא הופעל עם כללים מותאמים ויש צורך במגן מהיר.
• אם תנועת הרובוטים ברורה יותר מתנועת המשתמשים האמיתיים.
• אם דפי האתר, טפסים, מסכי כניסה או נקודות קצה חיפוש הם המטרות של המתקפה.

מצבים שיש להשתמש בהם בזהירות

• אם יש תנועה רבה מאפליקציות ניידות, ספקי תשלום, webhook או API.
• אם אתה נמצא בתקופה קריטית לסריקות של רובוטי מנועי חיפוש.
• אם משתמשי עסקים שלך ניגשים דרך דפדפנים ישנים או רשתות מוגבלות.
• אם יש לך תתי דומיינים שאינם מאחוריי פרוקסי של Cloudflare.

באתרים עם תנועת API, הפעלת מצב Under Attack על כל הדומיין עלולה לגרום לכשלונות מסוימים באינטגרציות. לכן, אם אפשרי, יש לתכנן כלל WAF מותאם, רשימת הרשאות או רמת אבטחה שונה עבור תתי הדומיינים של ה-API. ניתן להמליץ על מדריך מפורט על אבטחת API מדריך לאבטחת API והגבלת קצב.

איך להפעיל את מצב Under Attack של Cloudflare? מדריך שלב אחר שלב

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

1. התחבר לחשבון Cloudflare שלך

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

2. בדוק שהרשומות DNS במצב פרוקסי

כדי שמצב Under Attack יהיה אפקטיבי, על תנועת האינטרנט לעבור דרך Cloudflare. ודא שהרשומות A, AAAA ו-CNAME במקטע ה-DNS מצביעות על ענן כתום, כלומר במצב פרוקסי. רשומות שנמצאות במצב ענן אפור, כלומר DNS בלבד, לא יעברו את שכבת האבטחה של Cloudflare. יש לבדוק במיוחד את www, הדומיין הראשי ואת תתי הדומיינים בשימוש.

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

3. הפעל את מצב Under Attack ממחלקת האבטחה

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

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

4. בדוק את חוויית המשתמש האמיתית

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

5. קבע את כתובות ה-URL שהמתקפה מכוונת אליהן

מצב Under Attack מספק מגן כללי; אך האפקטיביות האמיתית מתקבלת על ידי כללים ספציפיים למטרה. מצא את הנתיבים שמקבלים את מספר הבקשות הגבוה ביותר מתוך אירועי אבטחת Cloudflare, ניתוחי האינטרנט, יומני גישה להוסטינג ויומני יישום. לדוגמה, /wp-login.php, /xmlrpc.php, /search, /cart, /api/login או /checkout עלולים להיות תחת מתקפה.

כאשר הכתובת המכוונת מזוהה, ניתן לנקוט בפעולה לפי קריטריונים כמו מדינה, user-agent, שיטת הבקשה, URI path או ניקוד רובוטים עם כללים מותאמים ב-WAF. לדוגמה, ניתן ליישם את אתגר הניהול על IPים השולחים יותר מדי בקשות לדף הכניסה ספציפי. עבור אתרי וורדפרס, צעדי אבטחה ל-WordPress הוא קישור פנימי טבעי.

ההבדלים בין מצב Under Attack של Cloudflare לאפשרויות אבטחה אחרות של Cloudflare

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

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

הגדרות Cloudflare נוספות מומלצות במהלך המתקפה

למרות שניתן להפעיל את מצב Under Attack בלחיצת כפתור, הצלחת ההגנה מפני DDoS תלויה בהגדרות התומכות. ההמלצות הבאות הן היישומים שמוכיחים את עצמם ביותר בעבודות אמיתיות.

צור הגנה ממוקדת עם כללי WAF

WAF של Cloudflare מאפשר לך לנקוט פעולה לפי תנאים מסוימים. לדוגמה, תוכל ליישם אתגר על בקשות POST המגיעות רק לדף /wp-login.php ממדינות ספציפיות. כך תוכל לבודד את המטרה של המתקפה מבלי להכביד על כל האתר.

• פתח את דפי הניהול והכניסה רק למדינות או לטווחי IP מסוימים.
• חסום נקודות קצה שאינן בשימוש כמו XML-RPC.
• יישם אתגר ניהול על ערכי user-agent חשודים.
• הגבל לקוחות ששולחים בקשות רבות על URI path ספציפי עם הגבלת קצב.

הגדר את רמת הקאש בצורה נכונה

במהלך DDoS, אם השרת המקורי צריך להגיב לכל בקשה, המשאבים יתמלאו במהירות. קבצים סטטיים, תמונות, CSS, JavaScript ודפי קאש צריכים להינתן דרך ה-edge של Cloudflare. באתרי וורדפרס, ניתן להשתמש בתוסף קאש יחד עם כללי קאש של Cloudflare וכותרות cache-control מתאימות.

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

קבע את הספים להגבלת קצב בצורה ריאליסטית

הגבלת קצב היא מאוד אפקטיבית, במיוחד בדפי קצה יקרים. אך אם הספים נקבעים באקראי, משתמשים אמיתיים יכולים להיחסם. לדוגמה, בדף חיפוש מוצר, משתמש רגיל יכול לחפש 5-15 פעמים בדקה; חיפוש של 100 פעמים בדקה הוא לא נורמלי. בדף הכניסה, 10 ניסי כניסה לא מצליחים ב-5 דקות הם חשודים ברוב המקרים.

גישה לדוגמה: ניתן ליישם אתגר ניהול על IP ששולח יותר מ-10 בקשות ב-דקה לדף /wp-login.php, ולחסום IP ששולח יותר מ-50 בקשות ב-5 דקות. בעבור נקודות קצה של API, יש להעדיף ספים מדויקים יותר על בסיס סשן משתמש, IP, טוקן ושיטה.

הסתיר את כתובת ה-IP המקורית ומגבל את הגישה בחומת האש

אחת מהטעויות הקריטיות ביותר כאשר משתמשים ב-Cloudflare היא להשאיר את כתובת ה-IP המקורית חשופה. רשומות DNS ישנות, תתי דומיינים העובדים עם IP ישיר, שירותי אינטרנט המעורבים עם רשומות דואר או קונפיגורציות דלפו יכולות לאפשר לתוקפים לגשת לשרת מחוץ ל-Cloudflare.

ספקת גישה לפורטים 80 ו-443 רק לטווחי IP של Cloudflare מספקת הגנה חזקה. בנוסף, יש למנוע גישה לאינטרנט לפורטים של SSH, לוח בקרה, בסיס נתונים ולניהול; יש להשתמש בהגבלת IP, סיסמאות חזקות, אימות דו-שלבי ובמידת האפשר VPN. ניתן לקשר לתכנים על אבטחת הוסטינג הגדרות אבטחה ב-cPanel והגדרת חומת אש עבור VPS.

נקודות תשומת לב מיוחדות באתרי וורדפרס, WooCommerce ואתרים עסקיים

לא כל אתר אינטרנט הוא בעל מבנה תנועה דומה. אתר בלוג, חנות WooCommerce ולוח בקרה של SaaS יכולים להניב תוצאות שונות עם מצב Under Attack של Cloudflare. לכן יש לקבוע דרכי גישה קריטיות בהתאם לסוג האתר.

אתרי וורדפרס

הקבצים המכוונים ביותר בוורדפרס הם /wp-login.php ו-/xmlrpc.php. אם אינך משתמש ב-XML-RPC, חסימתו היא בדרך כלל בטוחה. ניתן לבצע הגבלות לפי מדינה או IP על לוח הבקרה. כמו כן, יש לוודא שאין התנגשויות בין תוספי אבטחה לבין כללי Cloudflare; מכיוון שיותר מדי מנגנוני אתגר בו זמנית יכולים להכניס את המשתמש למעגל אימות.

חנויות WooCommerce

ב-WooCommerce, דפי סל, תשלום וחשבון דורשים תשומת לב מיוחדת. מכיוון שדפים אלה הם דינמיים, אין להחיל קאש אגרסיבי. כאשר מצב Under Attack פעיל, יש לוודא ששירותי אספקת תשלום כמו callbacks או webhook פועלים כראוי. אם יש צורך, יש להוסיף את טווחי ה-IP של ספק התשלום לרשימת ההרשאות, או לכתוב כלל ספציפי עבור הנקודה הרלוונטית.

אתרים עסקיים ואתרים המשתמשים ב-API

פורטלים עסקיים, אינטגרציות CRM ו-API של אפליקציות ניידות עשויים לא להיות מסוגלים לטפל במסך אתגר JavaScript. במבנים כאלה, במקום להפעיל מצב Under Attack על כל הדומיין, ייתכן שיהיה נכון יותר לנהל את תת הדומיין של ה-API בנפרד. לדוגמה, כאשר www.example.com פתוח למצב Under Attack, ניתן ליישם אבטחה מבוססת טוקן, הגבלת קצב ורשימות הרשאות על api.example.com.

מה לעשות לאחר הפעלת מצב Under Attack: מדדים למעקב

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

• אירועי אבטחת Cloudflare: מציגים כמה בקשות אתגרים או חסימות כל כלל ביצע.
• קודי מצב HTTP: יש לעקוב אחרי השינויים בשגיאות 403, 429, 502, 503 ו-504.
• שימוש ב-CPU ו-RAM של השרת: צפוי ירידה לאחר מצב Under Attack.
• חיבורים ב-PHP-FPM וב-MySQL: מצביעים על שחרור ברמת שכבת היישום.
• רוחב פס ומספר בקשות: יש להשוות את היקף התנועה עם שיעור הבקשות המסוננות.
• שיעורי ההמרה של משתמשים אמיתיים: יש לבדוק שליחת טפסים, הזמנות, כניסות ושלבי תשלום.

לדוגמה, אם לאחר הפעלת מצב Under Attack מספר הבקשות הכולל נשאר זהה, אך הבקשות המגיעות לשרת פחתו ב-60%, זה מציין ש-Clooudflare סופג את העומס המשמעותי. אם עם זאת, השימוש ב-CPU של MySQL נשאר גבוה, המתקפה עשויה להפעיל שאילתה דינמית ספציפית; במקרה זה יש לבדוק את יומני היישום.

איך לכבות את מצב Under Attack לאחר שהמתקפה הסתיימה?

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

צעדים לחזרה בטוחה לנורמליות

• חכה לפחות 30-60 דקות עד שהתנועה תשוב לנורמליות.
• ודא במסך אירועי האבטחה של Cloudflare שהמספרים של אתגרים וחסימות פחתו.
• ודא שכללי WAF והגבלת קצב ממוקדים פעילים לפני כיבוי מצב Under Attack.
• העבר את רמת האבטחה לרמה מאוזנת יותר כמו גבוהה או בינונית.
• בדוק את האתר ממכשירים שונים ומעקב אחרי שיעור השגיאות 5xx.
• עקוב אחרי היומנים במשך 24 שעות כדי לבדוק אם המתקפה מתחילה מחדש.

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

טעויות נפוצות ודברים שיש להימנע מהם

בעת מתקפת DDoS יש לקבל החלטות מהירות; אך הגדרות שגויות עשויות לחסום גם משתמשים אמיתיים. הטעויות הבאות נפוצות במיוחד תחת לחץ גבוהה.

• לחשוב שמצב Under Attack יספק הגנה מבלי להגדיר את רשומות ה-DNS במצב פרוקסי.
• להשאיר את כתובת ה-IP המקורית חשופה ולא לחסום גישה לחומת אש IPים שאינם של Cloudflare.
• ליישם אתגרים על כל הדומיין מבלי לבדוק את כתובות ה-API, webhook וכתובות callback של תשלום.
• לכתוב כללי WAF חסימה רחבים מדי, מה שיכול לחסום לקוחות אמיתיים.
• ליישם קאש אגרסיבי על דפי סל, תשלום או לוח בקרה שלא אמורים להיות בקאש.
• להשאיר את המצב פתוח במשך שבועות לאחר שהמתקפה הסתיימה.
• לקבל החלטות רק על בסיס נתוני המסך של Cloudflare מבלי לבדוק את יומני השרת.

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

כיצד לתכנן הגנה עמידה יותר על תשתית Hostragons?

Cloudflare מספק שכבת הגנה חזקה; אך הצלחה בהגנה מפני DDoS אינה מסתיימת רק בצד ה-CDN. יש להתחשב בתשתית ההוסטינג, באופטימיזציה של התוכנה, בהגדרת SSL, בניהול DNS ובאסטרטגיית גיבוי יחד. עבור אתר הממוקם על Hostragons, הגישה הבסיסית צריכה להיות: Cloudflare מסנן את התנועה, תשתית ההוסטינג פוגשת רק את התנועה הנקייה, והיישום מתאמן כך שלא ייצור עומס מיותר על מסד הנתונים.

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

בפרויקטים עם תנועה גבוהה או סיכון גבוה למתקפות, עדיף לשקול אפשרויות VPS או שרת מנוהל במקום אחסון משותף סטנדרטי. כך ניתן להגדיר את חומת האש, השרת האינטרנטי, PHP-FPM, Redis, object cache והגדרות מסד הנתונים בצורה גמישה יותר. אך בכל תשתית שתיבחר, יש למקם את מצב Under Attack של Cloudflare רק ככלי חירום; הארכיטקטורה הקבועה של האבטחה חייבת להתממשק עם WAF, ניתוח יומנים ועדכונים קבועים.

רשימת בקרה מהירה: 15 הדקות הראשונות במהלך מתקפת DDoS

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

• היכנס ללוח הבקרה של Cloudflare ובחר את הדומיין הנכון.
• וודא שהרשומות ב-DNS הן בענן כתום, כלומר במצב פרוקסי.
• הפעל את מצב Under Attack.
• בדוק את דף הבית, הכניסה, סל, תשלום ונקודות קצה של API.
• ממסך אירועי האבטחה של Cloudflare, קבע את כתובות ה-URL המכוונות.
• הוסף כללי WAF או הגבלת קצב לנקודות היעד הנפגעות ביותר.
• בדוק את מצב ה-CPU, RAM, PHP-FPM ו-MySQL בשרת.
• בדוק אם יש גישה ישירה ל-IP המקורי.
• בדוק אם יש צורך ברשימות הרשאות עבור ספקי תשלום, webhook ושירותים קריטיים.
• תעד את כל הפעולות עם חותמות זמן.

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

שאלות נפוצות

האם מצב Under Attack של Cloudflare מגנה לחלוטין על האתר?

לא. מצב Under Attack של Cloudflare יעיל במיוחד להפחתת תנועת רובוטים ופעולות הצפה ברמת HTTP/HTTPS; אך אין הוא מספק הגנה מלאה בפני עצמו. יש להשתמש במקביל עם רשומות DNS במצב פרוקסי, הסתרת כתובת ה-IP המקורית, כללי WAF, הגבלת קצב, קאש והגדרות חומת אש של השרת.

האם מצב Under Attack פוגע ב-SEO?

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

כמה זמן צריך להפעיל את מצב Under Attack?

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

האם מצב Under Attack משפיע על מערכות API או תשלום?

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

האם יש צורך לנקוט באמצעי זהירות נוספים בצד ההוסטינג בעת השימוש ב-Cloudflare?

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

סיכום

מצב "Under Attack" של Cloudflare הוא כלי חירום יעיל שמספק הקלה מהירה לאתר תחת מתקפת DDoS. כאשר הוא מופעל עם הגדרת פרוקסי DNS נכונה, הוא מפחית את תנועת הרובוטים, מפחית את העומס על השרת ומגביר את הסיכוי של משתמשים אמיתיים להגיע לאתר. כדי להגיע לתוצאות הטובות ביותר, יש לתמוך במצב זה עם כללי WAF, הגבלת קצב, אופטימיזציית קאש ואבטחת חומת האש המקורית.

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