התקפת DDoS על שירותי RDP: זיהוי והילחם. ניסיון מוצלח מטוצ'ה

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

איך הכל התחיל

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

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

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

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

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

xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0

השרת מקבל חבילה זו, אך דוחה את החיבור:

xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0

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

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

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

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

איך להמשיך?

האם להמליץ ​​ללקוחות להשקיע זמן רב בשינוי הגדרות למספר עצום של משתמשי קצה לעבור ליציאה אחרת? לא רעיון טוב, הלקוחות לא יהיו מרוצים. ממליץ לאפשר גישה רק באמצעות VPN? בחיפזון ובבהלה, העלאת קשרי IPSec למי שאין להם אותם - אולי אושר כזה לא מחייך גם ללקוחות. למרות, אני חייב לומר, זה דבר אלוהים בכל מקרה, אנחנו תמיד ממליצים להסתיר את השרת ברשת פרטית ומוכנים לעזור בהגדרות, ולמי שאוהב להבין את זה בעצמו, אנו חולקים הוראות להגדרת IPSec/L2TP בענן שלנו במצב אתר לאתר או דרך -לוחם, ואם מישהו רוצה להגדיר שירות VPN בשרת Windows משלו, אנחנו תמיד מוכנים לחלוק טיפים כיצד להגדיר RAS רגיל או OpenVPN. אבל, לא משנה כמה היינו מגניבים, זה לא היה הזמן הטוב ביותר לבצע עבודה חינוכית בקרב לקוחות, מכיוון שהיינו צריכים לתקן את הבעיה במהירות האפשרית עם מינימום לחץ למשתמשים.

הפתרון שיישמנו היה כדלקמן. הקמנו ניתוח של תעבורה עוברת באופן שינטר את כל הניסיונות ליצור חיבור TCP ליציאה 3389 ולבחור מתוכו כתובות שתוך 150 שניות מנסות ליצור חיבורים עם יותר מ-16 שרתים שונים ברשת שלנו - אלו הם מקורות המתקפה (כמובן, אם לאחד מהלקוחות או השותפים יש צורך אמיתי ליצור קשרים עם כל כך הרבה שרתים מאותו מקור, אתה תמיד יכול להוסיף מקורות כאלה ל"רשימה הלבנה". יתר על כן, אם ברשת Class C אחת במשך 150 שניות אלו מזוהות יותר מ-32 כתובות, הגיוני לחסום את כל הרשת. החסימה נקבעת ל-3 ימים, ואם במהלך תקופה זו לא בוצעו התקפות ממקור נתון, מקור זה מוסר אוטומטית מהרשימה השחורה. רשימת המקורות החסומים מתעדכנת כל 300 שניות.

רשימה זו זמינה בכתובת זו: https://secure.tucha.ua/global-filter/banned/rdp_ddos, אתה יכול לבנות את ה-ACL שלך על סמך זה.

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

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

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

יש בטיחות במספרים

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

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

מקור: www.habr.com