DDoS להצלה: כיצד אנו עורכים מבחני מתח ועומס

Variti מפתחת הגנה מפני בוטים והתקפות DDoS, וכן מבצעת בדיקות מתח ועומס. בכנס HighLoad++ 2018 דיברנו על איך לאבטח משאבים מסוגים שונים של התקפות. בקיצור: לבודד חלקים מהמערכת, להשתמש בשירותי ענן וב-CDN ולעדכן באופן קבוע. אבל עדיין לא תוכל להתמודד עם הגנה ללא חברות מיוחדות :)

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

הקלטת וידאו של הדו"ח

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

איך אנחנו עובדים

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

פוסטולציות

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

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

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

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

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

מאפיינים ייחודיים של התקפות L7

בדרך כלל אנו מחלקים סוגי עומס לעומסים ברמות L7 ו-L3&4. L7 הוא עומס ברמת האפליקציה, לרוב זה אומר רק HTTP, אבל אנחנו מתכוונים לכל עומס ברמת פרוטוקול TCP.
להתקפות L7 יש מאפיינים ייחודיים מסוימים. ראשית, הם מגיעים ישירות לאפליקציה, כלומר, אין זה סביר שהם ישתקפו באמצעי רשת. התקפות כאלה משתמשות בלוגיקה, ובשל כך הן צורכות מעבד, זיכרון, דיסק, מסד נתונים ומשאבים נוספים בצורה יעילה מאוד ועם תעבורה מועטה.

הצפה של HTTP

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

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

מה לחפש

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

איפה לחפש

כאשר אנו סורקים משאב לפני בדיקה, אנו מסתכלים תחילה, כמובן, על האתר עצמו. אנחנו מחפשים כל מיני שדות קלט, קבצים כבדים - בכלל כל מה שיכול ליצור בעיות למשאב ולהאט את פעולתו. כלי פיתוח בנאליים ב-Google Chrome ו-Firefox עוזרים כאן, המציגים את זמני התגובה של הדף.
אנחנו גם סורקים תת-דומיינים. לדוגמה, יש חנות מקוונת מסוימת, abc.com, ויש לה תת-דומיין admin.abc.com. סביר להניח שזהו פאנל ניהול עם הרשאה, אבל אם תעמיס עליו, זה יכול ליצור בעיות עבור המשאב הראשי.
ייתכן שלאתר יש תת-דומיין api.abc.com. סביר להניח שזהו משאב עבור יישומים ניידים. ניתן למצוא את האפליקציה ב-App Store או ב-Google Play, להתקין נקודת גישה מיוחדת, לנתח את ה-API ולרשום חשבונות בדיקה. הבעיה היא שלעתים קרובות אנשים חושבים שכל דבר שמוגן בהרשאה חסין מפני התקפות מניעת שירות. כביכול, אישור הוא ה-CAPTCHA הטוב ביותר, אבל הוא לא. קל ליצור 10-20 חשבונות בדיקה, אבל על ידי יצירתם, אנו מקבלים גישה לפונקציונליות מורכבת ובלתי מוסתרת.
באופן טבעי, אנו מסתכלים על ההיסטוריה, ב-robots.txt וב-WebArchive, ViewDNS, ומחפשים גרסאות ישנות של המשאב. לפעמים קורה שמפתחים הוציאו, למשל, mail2.yandex.net, אבל הגרסה הישנה, ​​mail.yandex.net, נשארה. ה-mail.yandex.net הזה כבר לא נתמך, משאבי פיתוח לא מוקצים לו, אבל הוא ממשיך לצרוך את מסד הנתונים. בהתאם, באמצעות הגרסה הישנה, ​​אתה יכול להשתמש ביעילות במשאבים של ה-backend ובכל מה שעומד מאחורי הפריסה. כמובן, זה לא תמיד קורה, אבל אנחנו עדיין נתקלים בזה לעתים קרובות למדי.
באופן טבעי, אנו מנתחים את כל פרמטרי הבקשה ואת מבנה העוגיות. אתה יכול, נגיד, לזרוק ערך מסוים לתוך מערך JSON בתוך קובץ Cookie, ליצור הרבה קינון ולגרום למשאב לעבוד במשך זמן רב באופן בלתי סביר.

עומס חיפוש

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

אם אין חיפוש?

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

מנוחת API

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

טוען תוכן כבד

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

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

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

מבוסס גל

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

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

לא HTTP לבד

בנוסף ל-HTTP ב-L7, אנחנו אוהבים לנצל פרוטוקולים אחרים. ככלל, לאתר רגיל, במיוחד אחסון רגיל, יש פרוטוקולי דואר ו-MySQL בולטים החוצה. פרוטוקולי דואר נתונים לעומס קטן יותר מאשר מסדי נתונים, אך ניתן גם לטעון אותם בצורה יעילה למדי ולסיים עם מעבד עמוס מדי בשרת.
הצלחנו למדי בשימוש בפגיעות SSH 2016. כעת פגיעות זו תוקנה עבור כמעט כולם, אך אין זה אומר שלא ניתן להגיש עומס ל-SSH. פחית. יש פשוט עומס עצום של הרשאות, SSH אוכל כמעט את כל המעבד בשרת, ואז האתר קורס מבקשה אחת או שתיים בשנייה. לפיכך, לא ניתן להבחין בין בקשה אחת או שתיים המבוססות על היומנים לבין עומס לגיטימי.
גם חיבורים רבים שאנו פותחים בשרתים נשארים רלוונטיים. בעבר, Apache היה אשם בכך, כעת nginx למעשה אשם בכך, מכיוון שלעתים קרובות הוא מוגדר כברירת מחדל. מספר החיבורים ש-nginx יכול לשמור פתוח מוגבל, אז אנחנו פותחים את מספר החיבורים הזה, nginx כבר לא מקבל חיבור חדש, וכתוצאה מכך האתר לא עובד.
לאשכול הבדיקה שלנו יש מספיק מעבד כדי לתקוף לחיצת יד של SSL. באופן עקרוני, כפי שמראה בפועל, גם רשתות בוטים אוהבות לעשות זאת. מצד אחד, ברור שאתה לא יכול בלי SSL, כי גוגל תוצאות, דירוג, אבטחה. מצד שני, ל-SSL למרבה הצער יש בעיית מעבד.

L3&4

כשאנחנו מדברים על התקפה ברמות L3&4, אנחנו בדרך כלל מדברים על התקפה ברמת הקישור. כמעט תמיד ניתן להבחין בין עומס כזה לבין עומס לגיטימי, אלא אם כן מדובר בהתקפת SYN-flood. הבעיה עם התקפות SYN-flood עבור כלי אבטחה היא הנפח הגדול שלהן. הערך המרבי של L3&4 היה 1,5-2 Tbit/s. סוג זה של תעבורה קשה מאוד לעיבוד אפילו עבור חברות גדולות, כולל אורקל וגוגל.
SYN ו-SYN-ACK הן מנות המשמשות בעת יצירת חיבור. לכן, SYN-flood קשה להבדיל מעומס לגיטימי: לא ברור אם מדובר ב-SYN שבא ליצור חיבור, או חלק ממבול.

UDP-הצפה

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

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

SYN-הצפה קשה

SYN-flood הוא כנראה סוג ההתקפה המעניין ביותר מנקודת מבטו של מפתח. הבעיה היא שמנהלי מערכת משתמשים לעתים קרובות בחסימת IP להגנה. יתרה מכך, חסימת IP משפיעה לא רק על מנהלי מערכת הפועלים באמצעות סקריפטים, אלא גם, למרבה הצער, על כמה מערכות אבטחה שנרכשות בכסף רב.
שיטה זו עלולה להפוך לאסון, מכיוון שאם תוקפים יחליפו כתובות IP, החברה תחסום רשת משנה משלה. כאשר חומת האש חוסמת אשכול משלה, הפלט ייכשל באינטראקציות חיצוניות והמשאב ייכשל.
יתר על כן, לא קשה לחסום את הרשת שלך. אם למשרד של הלקוח יש רשת Wi-Fi, או אם ביצועי המשאבים נמדדים באמצעות מערכות ניטור שונות, אז אנחנו לוקחים את כתובת ה-IP של מערכת ניטור זו או של ה-Wi-Fi במשרד של הלקוח ומשתמשים בה כמקור. בסופו של דבר, נראה שהמשאב זמין, אך כתובות ה-IP היעד חסומות. כך, רשת ה-Wi-Fi של כנס HighLoad, שבה מוצג המוצר החדש של החברה, עשויה להיחסם, והדבר כרוך בעלויות עסקיות וכלכליות מסוימות.
במהלך הבדיקה, איננו יכולים להשתמש בהגברה דרך memcached עם משאבים חיצוניים כלשהם, מכיוון שיש הסכמות לשלוח תעבורה רק לכתובות IP מותרות. בהתאם, אנו משתמשים בהגברה דרך SYN ו-SYN-ACK, כאשר המערכת מגיבה לשליחת SYN אחד עם שניים או שלושה SYN-ACK, וביציאה מתקפה מוכפלת פי שניים או שלוש.

כלי עבודה

אחד הכלים העיקריים שבהם אנו משתמשים לעומס עבודה של L7 הוא Yandex-tank. בפרט, פאנטום משמש כאקדח, בנוסף ישנם מספר סקריפטים להפקת מחסניות ולניתוח התוצאות.
Tcpdump משמש לניתוח תעבורת רשת, ו- Nmap משמש לניתוח השרת. כדי ליצור את העומס ברמת L3&4, נעשה שימוש ב-OpenSSL ומעט מהקסם שלנו עם ספריית DPDK. DPDK היא ספרייה מבית אינטל המאפשרת לך לעבוד עם ממשק הרשת עוקף את מחסנית לינוקס, ובכך להגביר את היעילות. באופן טבעי, אנו משתמשים ב-DPDK לא רק ברמת L3&4, אלא גם ברמת L7, מכיוון שהוא מאפשר לנו ליצור זרימת עומס גבוהה מאוד, בטווח של כמה מיליוני בקשות לשנייה ממכונה אחת.
אנו משתמשים גם במחוללי תנועה מסוימים ובכלים מיוחדים שאנו כותבים עבור בדיקות ספציפיות. אם אנו זוכרים את הפגיעות תחת SSH, אז לא ניתן לנצל את הסט לעיל. אם אנחנו תוקפים את פרוטוקול הדואר, אנחנו לוקחים כלי דואר או פשוט כותבים עליהם סקריפטים.

ממצאים

לסיכום אני רוצה לומר:

• בנוסף לבדיקות עומסים קלאסיות, יש צורך לבצע בדיקות מאמץ. יש לנו דוגמה אמיתית שבה קבלן משנה של שותף ביצע רק בדיקות עומס. זה הראה שהמשאב יכול לעמוד בעומס הרגיל. אבל אז הופיע עומס חריג, מבקרי האתר החלו להשתמש במשאב קצת אחרת, וכתוצאה מכך קבלן המשנה נשכב. לפיכך, כדאי לחפש נקודות תורפה גם אם אתם כבר מוגנים מפני התקפות DDoS.
• יש צורך לבודד חלקים מסוימים של המערכת מאחרים. אם יש לך חיפוש, אתה צריך להעביר אותו למכונות נפרדות, כלומר אפילו לא ל-Docker. כי אם החיפוש או ההרשאה נכשלים, לפחות משהו ימשיך לעבוד. במקרה של חנות מקוונת, המשתמשים ימשיכו למצוא מוצרים בקטלוג, לעבור מהאגרגטור, לקנות אם הם כבר מורשים או לאשר דרך OAuth2.
• אל תזניח את כל סוגי שירותי הענן.
• השתמש ב-CDN לא רק כדי לייעל את עיכובי הרשת, אלא גם כאמצעי להגנה מפני התקפות על תשישות ערוצים ופשוט הצפה לתעבורה סטטית.
• יש צורך להשתמש בשירותי הגנה מיוחדים. אינך יכול להגן על עצמך מפני התקפות L3&4 ברמת הערוץ, כי סביר להניח שפשוט אין לך ערוץ מספיק. גם לא סביר שתלחם בהתקפות L7, מכיוון שהן יכולות להיות גדולות מאוד. בנוסף, החיפוש אחר התקפות קטנות הוא עדיין זכותם של שירותים מיוחדים, אלגוריתמים מיוחדים.
• עדכן באופן קבוע. זה חל לא רק על הקרנל, אלא גם על הדמון SSH, במיוחד אם יש לך אותם פתוחים כלפי חוץ. באופן עקרוני, הכל צריך להתעדכן, כי לא סביר שתצליחו לעקוב אחר נקודות תורפה מסוימות בעצמכם.

מקור: www.habr.com