आइए आपको एक अच्छी कहानी बताते हैं कि कैसे "तीसरे पक्षों" ने हमारे ग्राहकों के काम में हस्तक्षेप करने की कोशिश की, और इस समस्या का समाधान कैसे किया गया।
यह सब कब प्रारंभ हुआ
यह सब महीने के आखिरी दिन, 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
इसका मतलब यह है कि समस्या स्पष्ट रूप से बुनियादी ढांचे के संचालन में किसी समस्या के कारण नहीं, बल्कि किसी और चीज़ के कारण है। हो सकता है कि सभी उपयोगकर्ताओं को दूरस्थ डेस्कटॉप लाइसेंसिंग में समस्या आ रही हो? हो सकता है कि किसी प्रकार का मैलवेयर उनके सिस्टम में घुसने में कामयाब रहा हो, और आज यह सक्रिय हो गया हो, जैसा कि कुछ साल पहले हुआ था एक्सडेटा и पेट्या?
जब हम इसे सुलझा रहे थे, हमें कई और ग्राहकों और भागीदारों से इसी तरह के अनुरोध प्राप्त हुए।
इन मशीनों पर वास्तव में क्या होता है?
इवेंट लॉग पासवर्ड का अनुमान लगाने के प्रयासों के बारे में संदेशों से भरे हुए हैं:
आमतौर पर, ऐसे प्रयास सभी सर्वरों पर पंजीकृत होते हैं जहां रिमोट एक्सेस सेवा के लिए मानक पोर्ट (3389) का उपयोग किया जाता है और हर जगह से एक्सेस की अनुमति होती है। इंटरनेट ऐसे बॉट्स से भरा है जो लगातार सभी उपलब्ध कनेक्शन बिंदुओं को स्कैन करते हैं और पासवर्ड का अनुमान लगाने की कोशिश करते हैं (यही कारण है कि हम "123" के बजाय जटिल पासवर्ड का उपयोग करने की दृढ़ता से सलाह देते हैं)। हालाँकि, उस दिन इन प्रयासों की तीव्रता बहुत अधिक थी।
मुझे क्या करना चाहिए
क्या आप अनुशंसा करते हैं कि ग्राहक बड़ी संख्या में अंतिम उपयोगकर्ताओं के लिए एक अलग पोर्ट पर स्विच करने के लिए सेटिंग्स बदलने में बहुत समय व्यतीत करें? यह अच्छा विचार नहीं है, ग्राहक खुश नहीं होंगे। केवल वीपीएन के माध्यम से पहुंच की अनुमति देने की अनुशंसा करें? जल्दबाजी और घबराहट में, उन लोगों के लिए आईपीएसईसी कनेक्शन बढ़ाना जिनके पास नहीं हैं - शायद ऐसी खुशी ग्राहकों पर भी मुस्कुराती नहीं है। हालाँकि, मुझे कहना होगा, यह किसी भी मामले में एक ईश्वरीय बात है, हम हमेशा सर्वर को एक निजी नेटवर्क में छिपाने की सलाह देते हैं और सेटिंग्स में मदद करने के लिए तैयार हैं, और जो लोग इसे स्वयं समझना पसंद करते हैं, हम निर्देश साझा करते हैं साइट-टू-साइट या रोड मोड-वॉरियर में हमारे क्लाउड में IPSec/L2TP स्थापित करने के लिए, और यदि कोई अपने स्वयं के विंडोज सर्वर पर वीपीएन सेवा स्थापित करना चाहता है, तो वे कैसे सेट अप करें, इसके बारे में सुझाव साझा करने के लिए हमेशा तैयार हैं। मानक आरएएस या ओपनवीपीएन। लेकिन, इससे कोई फर्क नहीं पड़ता कि हम कितने शांत थे, यह ग्राहकों के बीच शैक्षिक कार्य करने का सबसे अच्छा समय नहीं था, क्योंकि हमें उपयोगकर्ताओं के लिए न्यूनतम तनाव के साथ समस्या को जल्द से जल्द ठीक करने की आवश्यकता थी।
हमने जो समाधान लागू किया वह इस प्रकार था. हमने पोर्ट 3389 पर एक टीसीपी कनेक्शन स्थापित करने के सभी प्रयासों की निगरानी करने और 150 सेकंड के भीतर, हमारे नेटवर्क पर 16 से अधिक विभिन्न सर्वरों के साथ कनेक्शन स्थापित करने का प्रयास करने वाले पते का चयन करने के लिए इस तरह से ट्रैफ़िक पास करने का विश्लेषण स्थापित किया है। - ये हमले के स्रोत हैं (बेशक, यदि किसी ग्राहक या भागीदार को एक ही स्रोत से इतने सारे सर्वर के साथ कनेक्शन स्थापित करने की वास्तविक आवश्यकता है, तो आप हमेशा ऐसे स्रोतों को "श्वेत सूची" में जोड़ सकते हैं। इसके अलावा, यदि इन 150 सेकंड के लिए एक क्लास सी नेटवर्क में 32 से अधिक पते की पहचान की जाती है, तो पूरे नेटवर्क को ब्लॉक करना समझ में आता है। ब्लॉकिंग 3 दिनों के लिए सेट की गई है, और यदि इस दौरान किसी दिए गए स्रोत से कोई हमला नहीं किया गया है, यह स्रोत स्वचालित रूप से "काली सूची" से हटा दिया जाता है। अवरुद्ध स्रोतों की सूची हर 300 सेकंड में अपडेट की जाती है।
यह सूची इस पते पर उपलब्ध है: , आप इसके आधार पर अपना एसीएल बना सकते हैं।
हम ऐसी प्रणाली के स्रोत कोड को साझा करने के लिए तैयार हैं; इसमें कुछ भी अधिक जटिल नहीं है (ये सचमुच कुछ घंटों में संकलित कई सरल स्क्रिप्ट हैं), और साथ ही इसे अनुकूलित किया जा सकता है और उपयोग नहीं किया जा सकता है केवल ऐसे हमले से बचाने के लिए, बल्कि नेटवर्क को स्कैन करने के किसी भी प्रयास का पता लगाने और उसे अवरुद्ध करने के लिए भी:
इसके अलावा, हमने मॉनिटरिंग सिस्टम की सेटिंग्स में कुछ बदलाव किए हैं, जो अब आरडीपी कनेक्शन स्थापित करने के प्रयास में हमारे क्लाउड में वर्चुअल सर्वर के नियंत्रण समूह की प्रतिक्रिया पर अधिक बारीकी से नज़र रखता है: यदि प्रतिक्रिया किसी के भीतर नहीं होती है दूसरा, यह ध्यान देने का एक कारण है।
समाधान काफी प्रभावी साबित हुआ: ग्राहकों और भागीदारों और निगरानी प्रणाली दोनों की ओर से अब कोई शिकायत नहीं है। नए पते और संपूर्ण नेटवर्क नियमित रूप से ब्लैकलिस्ट में जोड़े जाते हैं, जो इंगित करता है कि हमला जारी है, लेकिन अब हमारे ग्राहकों के काम को प्रभावित नहीं करता है।
अकेले क्षेत्र में एक योद्धा नहीं है
आज हमें पता चला कि अन्य ऑपरेटरों को भी ऐसी ही समस्या का सामना करना पड़ा है। किसी को अभी भी विश्वास है कि Microsoft ने रिमोट एक्सेस सेवा के कोड में कुछ बदलाव किए हैं (यदि आपको याद हो, तो हमें पहले दिन भी यही संदेह था, लेकिन हमने बहुत जल्दी इस संस्करण को अस्वीकार कर दिया) और शीघ्र समाधान खोजने के लिए हर संभव प्रयास करने का वादा किया है . कुछ लोग समस्या को अनदेखा कर देते हैं और ग्राहकों को स्वयं अपनी सुरक्षा करने की सलाह देते हैं (कनेक्शन पोर्ट बदलें, सर्वर को निजी नेटवर्क में छुपाएं, इत्यादि)। और पहले ही दिन, हमने न केवल इस समस्या का समाधान किया, बल्कि अधिक वैश्विक खतरे का पता लगाने वाली प्रणाली के लिए कुछ आधार भी तैयार किया, जिसे हम विकसित करने की योजना बना रहे हैं।
ग्राहकों और साझेदारों को विशेष धन्यवाद, जो चुप नहीं रहे और नदी के किनारे बैठकर इस इंतजार में नहीं बैठे कि एक दिन दुश्मन की लाश नदी में तैर जाएगी, बल्कि तुरंत समस्या की ओर हमारा ध्यान आकर्षित किया, जिससे हमें इसे खत्म करने का मौका मिला। यह उसी दिन.
स्रोत: www.habr.com