RDP सेवाओं पर DDoS का हमला: पहचानें और दूर करें। Tucha से सफल अनुभव

हम आपको एक शांत कहानी के बारे में बताएंगे कि कैसे "तीसरे पक्ष" ने हमारे ग्राहकों के काम में हस्तक्षेप करने की कोशिश की, और यह समस्या कैसे हल हुई।

यह सब कैसे शुरू हुआ

यह सब 31 अक्टूबर की सुबह से शुरू हुआ, महीने के आखिरी दिन, जब कई सख्त और जरूरी मुद्दों को बंद करने की सख्त जरूरत थी।

हमारे साझेदारों में से एक जो हमारे ग्राहकों की कई आभासी मशीनों को अपने क्लाउड में रखता है, उन्होंने बताया कि 9:10 से 9:20 बजे तक एक बार हमारे यूक्रेनी साइट पर चलने वाले कई विंडोज सर्वर ने रिमोट एक्सेस सेवा के साथ कनेक्शन स्वीकार नहीं किया। , उपयोगकर्ता अपने डेस्कटॉप तक नहीं पहुंच सके, लेकिन कुछ ही मिनटों के बाद समस्या स्वयं हल हो गई।

हमने संचार चैनलों के आंकड़े जुटाए, लेकिन ट्रैफ़िक या विफलताओं का कोई पता नहीं चला। कंप्यूटिंग संसाधनों पर भार के आँकड़ों को देखा - कोई विसंगतियाँ नहीं हैं। और वह क्या था?

फिर एक अन्य साथी, जो हमारे क्लाउड में एक और सौ सर्वर को होस्ट करता है, ने उन्हीं समस्याओं की रिपोर्ट की जो उनके कुछ ग्राहकों ने नोट की, और यह पता चला कि सामान्य रूप से सर्वर उपलब्ध हैं (वे सही तरीके से पिंग टेस्ट और अन्य अनुरोधों का जवाब देते हैं), लेकिन सेवा इन सर्वरों पर रिमोट एक्सेस या तो नए कनेक्शनों को स्वीकार करता है, फिर उन्हें अस्वीकार कर देता है, जबकि यह विभिन्न साइटों पर सर्वरों का सवाल था, जिससे ट्रैफ़िक अलग-अलग डेटा ट्रांसमिशन चैनलों से आता है।

और आइए इस ट्रैफ़िक को देखें। कनेक्शन स्थापित करने के अनुरोध के साथ एक पैकेट सर्वर पर आता है:

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 और Petya के साथ था?

जब वे इसे सुलझा रहे थे, तब उन्हें कई और ग्राहकों और भागीदारों से समान अनुरोध मिले।
और इन मशीनों पर क्या होता है?

इवेंट लॉग पासवर्ड खोजने की कोशिश करने के बारे में संदेशों से भरा है:



आमतौर पर, ऐसे प्रयासों को सभी सर्वरों पर लॉग किया जाता है, जहां रिमोट एक्सेस सेवा के लिए मानक पोर्ट (3389) का उपयोग किया जाता है और कहीं से भी एक्सेस की अनुमति है। इंटरनेट उन बॉट्स से भरा है जो लगातार सभी उपलब्ध कनेक्शन बिंदुओं को स्कैन करते हैं और एक पासवर्ड खोजने की कोशिश करते हैं (इस कारण से हम दृढ़ता से "123" के बजाय जटिल पासवर्ड का उपयोग करने की सलाह देते हैं)। हालांकि, उस दिन इन प्रयासों की तीव्रता बहुत अधिक थी।

क्या करें?

ग्राहकों को किसी अन्य पोर्ट पर स्विच करने के लिए बड़ी संख्या में अंतिम उपयोगकर्ताओं की सेटिंग्स बदलने के लिए बहुत समय समर्पित करने की सलाह देते हैं? एक अच्छा विचार नहीं है, ग्राहक खुश नहीं होंगे। केवल वीपीएन के माध्यम से पहुंच की अनुमति देने की सिफारिश? जल्दी और घबराहट में, IPSec- कनेक्शन बढ़ाने के लिए, जिनसे वे नहीं उठाए जाते हैं - शायद, इस तरह की खुशी ग्राहकों को भी नहीं मुस्कुराती है। हालाँकि, मुझे कहना होगा, यह किसी भी मामले में एक धर्मार्थ मामला है, हम हमेशा सर्वर को एक निजी नेटवर्क पर छिपाने की सलाह देते हैं और सेटिंग्स के साथ मदद करने के लिए तैयार होते हैं, और जो लोग इसे सुलझाना पसंद करते हैं, हम स्वतंत्र रूप से साइट-टू-साइट या रोड मोड में हमारे क्लाउड में IPSec / L2TP स्थापित करने के लिए निर्देश साझा करते हैं। -वारियर, और यदि कोई अपने स्वयं के विंडोज सर्वर पर वीपीएन सेवा को बढ़ाना चाहता है, तो वे हमेशा मानक आरएएस या ओपनवीपीएन बढ़ाने के लिए युक्तियों को साझा करने के लिए तैयार हैं। लेकिन कोई फर्क नहीं पड़ता कि हम कितने शांत थे, यह ग्राहकों के बीच शैक्षिक कार्य करने का सबसे अच्छा समय नहीं था, क्योंकि उपयोगकर्ताओं के लिए कम से कम तनाव के साथ समस्या को जल्द से जल्द खत्म करना आवश्यक था।

हमने जो समाधान लागू किया वह इस प्रकार था। हमने पासिंग ट्रैफिक का विश्लेषण इस तरह से किया है कि 3389 पोर्ट के लिए एक टीसीपी कनेक्शन स्थापित करने के लिए सभी प्रयासों की निगरानी करने और इसमें से पते चुनने के लिए कि 150 सेकंड के भीतर हमारे नेटवर्क पर 16 से अधिक विभिन्न सर्वरों के साथ कनेक्शन स्थापित करने का प्रयास करें - ये हमले के स्रोत हैं। बेशक, अगर क्लाइंट या पार्टनर में से किसी एक को एक ही स्रोत से इतने सारे सर्वर के साथ कनेक्शन स्थापित करने की वास्तविक आवश्यकता है, तो आप हमेशा ऐसे स्रोतों को "श्वेत सूची" में जोड़ सकते हैं, इसके अलावा, यदि इन 150 के लिए एक वर्ग सी नेटवर्क में। सेकंड, 32 से अधिक पतों का पता लगाया गया था, यह पूरे नेटवर्क को ब्लॉक करने के लिए समझ में आता है। अवरुद्ध को 3 दिनों के लिए सेट किया गया है, और यदि इस समय के दौरान इस स्रोत से कोई हमला नहीं किया गया था, तो यह स्रोत स्वचालित रूप से ब्लैकलिस्ट से हटा दिया जाता है। अवरुद्ध स्रोतों की सूची 300 सेकंड में अपडेट की जाती है।



यह सूची यहां इस पते पर उपलब्ध है: https://secure.tucha.ua/global-filter/banned/rdp_ddos , आप इसके आधार पर अपने स्वयं के ACL का निर्माण कर सकते हैं।

हम इस तरह की प्रणाली के स्रोत कोड को साझा करने के लिए तैयार हैं, कुछ भी जटिल नहीं है (ये कुछ सरल लिपियों को "घुटने पर" कुछ घंटों में सचमुच लिखा जाता है), और साथ ही इसे अनुकूलित किया जा सकता है और न केवल इस तरह के हमले से बचाने के लिए, बल्कि पहचान करने के लिए भी इस्तेमाल किया जाता है। और किसी भी नेटवर्क स्कैन प्रयासों को अवरुद्ध करना: इस लिंक का पालन करें।

इसके अलावा, हमने मॉनिटरिंग सिस्टम की सेटिंग्स में कुछ बदलाव किए, जो अब आरडीपी कनेक्शन स्थापित करने के प्रयास में हमारे क्लाउड में वर्चुअल सर्वर के नियंत्रण समूह की प्रतिक्रिया की बारीकी से निगरानी करता है: यदि प्रतिक्रिया एक सेकंड के लिए नहीं हुई, तो यह ध्यान देने का एक अवसर है।

समाधान काफी प्रभावी निकला: ग्राहकों और भागीदारों से और साथ ही निगरानी प्रणाली से कोई अधिक शिकायत नहीं है। "ब्लैक लिस्ट" में नियमित रूप से नए पते और पूरे नेटवर्क शामिल हैं, जो इंगित करता है कि हमला जारी है, लेकिन अब हमारे ग्राहकों के काम को प्रभावित नहीं करता है।

अकेले क्षेत्र में एक योद्धा नहीं है

आज हमें पता चला कि अन्य ऑपरेटरों को भी इसी तरह की समस्या का सामना करना पड़ा है। किसी को अभी भी विश्वास है कि यह माइक्रोसॉफ्ट था जिसने रिमोट एक्सेस सर्विस कोड में कुछ बदलाव किए (यदि आपको याद है, हमें पहले दिन एक ही बात पर संदेह था, लेकिन हमने इस संस्करण को बहुत जल्द ही अस्वीकार कर दिया) और इसे संभव बनाने के लिए हर संभव प्रयास करने का वादा किया जल्द ही कोई हल निकालें। कोई व्यक्ति केवल समस्या को अनदेखा करता है और ग्राहकों को खुद को बचाने के लिए सलाह देता है (कनेक्शन पोर्ट को बदलें, एक निजी नेटवर्क पर सर्वर छिपाएं, और इसी तरह)। और पहले ही दिन, हमने न केवल इस समस्या को हल किया, बल्कि एक अधिक वैश्विक खतरे का पता लगाने की प्रणाली के लिए कुछ आधार तैयार किए, जिसे हम विकसित करने की योजना बना रहे हैं।



उन ग्राहकों और भागीदारों के लिए विशेष धन्यवाद, जो चुप नहीं रहे और इस उम्मीद में नदी तट पर नहीं बैठे कि एक दिन दुश्मन की लाश उस पर तैरने लगे, और तुरंत हमारी समस्या पर ध्यान दिया, जिसने हमें उसी दिन इसे खत्म करने का मौका दिया।