דווח על תקיפת מניעת שירות מבוזרתDDoS הגדולה בהיסטוריה
מאת:
מערכת Telecom News, 4.3.18, 19:47
מתקפה זו, שכוונה כנגד שרתי אתר,Github הגיעה לרוחב פס של כ-1.35Tb. כיצד מתבצעת "הגברה" של מתקפת מניעת שירות מבוזרת? מהו שרתMemcached ? מה עושים? עדכון בתחתית הכתבה.
מהי מתקפת מניעת שירות מבוזרת?
מתקפת מניעת שירות מבוזרת
Distributed Denial of Service Attack - DDoS היא תקיפה למטרת מניעת שירות, שמבוצעת בד"כ בו-זמנית ממספר רב של מחשבים וציוד קצה ברשת האינטרנט. את התקיפה מארגן התוקף באמצעות שרתי שו"ב המנהלים מספר גדול של בוטים (מחשבים או ציוד קצה, שהותקפו בעבר ונשתלה בהם תוכנה לביצוע תקיפות מסוימות עפ"י פקודה).
באמצעות הפעלת בוטנט
)אוסף הבוטים) זה, ניתן לייצר תקיפות ברוחב פס גבוה מאד.
עד לתקיפה הנוכחית, התקיפה בעלת רוחב הפס הגבוה ביותר הייתה של
1.2Tb כנגד חברת
DYN ספקית תשתיות ה-
DNSב-2016. אז בוצעה התקיפה באמצעות הבוטנט
MIRAI.
כיצד מתבצעת "הגברה"(Amplification) של מתקפת מניעת שירות מבוזרת?
כדי להגביר את אפקט התקיפה הנ"ל, תוקפים נוהגים לבצעה באופן אסימטרי, תוך ניצול תכונות מסוימות של פרוטוקולי רשת מוכרים.
התקיפה תתבצע לרוב באמצעות פרוטוקול
,UDP שקל מאד לייצר עבורו תעבורה מכתובת
IP מזויפת (
(Spoofed.
התוקף שולח פניה קצרה לשרת פגיע, תוך שהוא מזייף את כתובת המקור של הפניה. כך, שתצביע על השרת או האתר
המותקף. השרת הפגיע מגיב לפניה ומייצר תגובה, גדולה פי כמה מאורך הפניה המקורית, לשרת המותקף. ביצוע תקיפה כזו ממספר מחשבים בו זמנית, משבש את רוחב הפס של האתר או השרת המותקף, בתלות ביחס ההגברה.
יחס ההגברה הוא היחס בין אורך הפניה המקורית של התוקף, לבין אורך התגובה של השרת הפגיע. יחסי ההגברה המקובלים בתקיפות מסוג זה יכולים להגיע ליחס של 1:10000.
בתקיפה הנוכחית יחס ההגברה עלול להגיע ל-
1:51200. כלומר, כדי לייצר תקיפה של כ-
500Gb מספיק שהתוקף ייצר תעבורה של כ-
10Mb.
מהו שרת ?Memcached
שרת
Memcached ה
וא שרת, שמטרתו להאיץ פעולות גישה לבסיסי נתונים. בדרך כלל יותקן שרת כזה בין שרת
WEB לבין בסיסי נתונים שבשימושו. השרת יאגור בזיכרון תשובות לפניות לבסיס הנתונים ויספק אותן במידה שתידרשנה שוב, ובכך יחסוך פניות לבסיס הנתונים ויאפשר זמן תגובה מהיר יותר.
השרת אינו מתוכנן ולא נועד לגישה ישירה מרשת האינטרנט, ולכן גם אינו מוגן מפני ניצול לרעה של גישה אליו מרשת זו. בתקיפה הנוכחית התוקפים מצאו שרתים מסוג זה, שהיו חשופים לפניות מהרשת וניצלו זאת למימוש התקיפה
.
אתר
SHODAN מדווח, שנכון לזמן זה, קיימים כ-125,000 שרתים מסוג
Memcached הנגישים בפורט
UDP/11211 מרשת האינטרנט.
פרטי האירוע הנוכחי
בתקיפה הנוכחית הותקף אתר
Github ברוחב פס שהגיע עד
1.35Tb. עפ"י הדיווחים, האתר התאושש מהתקיפה לאחר כ-10 דקות בלבד, תוך סיוע מחברת
Akamai לסינון התעבורה העוינת שהופנתה כלפיו.
דרכי התמודדות
משתמשים ארגוניים:
ניתן לבדוק אם שרת
Memcached מסוים פגיע לתקיפת הגברה זו, באמצעות הפקודה הבאה בשורת הפקודה של לינוקס:
echo -en "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n" | nc -q1 –u <target>
אם יש שרת מסוג
,Memcachedיש לוודא, שאינו נגיש ישירות מרשת האינטרנט, ושרק שרתים ועמדות, שהורשו לכך, מתוך הרשת הארגונית, רשאים לפנות אל השרת בפורט
.UDP/11211
ניתן לשקול לחסום כלל התעבורה הנכנסת והיוצאת מהרשת הארגונית בפורט
UDP/11211 , אם לא עושים שימוש בפורט זה למטרה כלשהי, שאינה תעבורת
Memcached .
לחילופין, ניתן לשקול הגדרת
Rate Limit על תעבורה זו.
מומלץ לשקול ולבחון במערכות עדכון גרסת השרת לגרסה 1.5.6, שמנטרלת השימוש בפרוטוקול
UDP כברירת מחדל. ניתן לנטרל תמיכה ב
UDP-גם בגרסאות קודמות של השרת.
אם השרת, שפונה לשרת ה-
,MEMCACHED יושב על אותה תשתית שרת, ניתן להגדיר בהגדרות השרת קישור השירות המאזין לתעבורה לכתובת השרת עצמו, כלומר
.(Localhost) 127.0.0.1
ראוי לבדוק במערכות את האפשרות להוסיף הזדהות מסוג
SASL authenticationבהגדרות השרת.
ספקיות אינטרנט:
לטווח קצר: לשקול לחסום תעבורה בפורט בפורט
UDP/11211 או לחילופין, פקטות בפורט זה בעלות אורך של 1428 תווים -
length 1428 עפ"י דיווח זהו אורך הפקטה בה נעשה שימוש במתקפה זו. אפשרות נוספת היא להגביל את קצב התעבורה של פורט זה ברשתות.
לטווח ארוך: לבחון האפשרות ליישם
Ingress Filtering בתשתיות באמצעות מימוש
(RFC 2827) - BCP 38 והרחבה שלו בשם
- BCP 84 - (3704
(RFC.
מימוש תקן זה יסייע למנוע שימוש בתשתיות למתקפות הכוללות זיוף של כתובות המקור של התעבורה.
עדכון 7.3.18, 15:45: דווחמ על תקיפה ברוחב פס רחב יותר של
1.7Tb, שכוונה נגד לקוח של חברת Arbor ונגד ספקית אמריקאית. מעריכים, שניתן לרכוש מתקפות אלו בתור שירות DDos-as-a-Sevice. במסרת התקיפה שולבה דרישה לשתלום כופר במטבע הקריפטוגרפי Monero.
