"तृतीय पक्षांनी" आमच्या क्लायंटच्या कामात हस्तक्षेप करण्याचा कसा प्रयत्न केला आणि ही समस्या कशी सोडवली याबद्दल एक छान गोष्ट सांगूया.
हे सर्व कसे सुरू झाले
हे सर्व 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 सेट करण्यासाठी आणि कोणाला त्यांच्या स्वतःच्या विंडोज सर्व्हरवर व्हीपीएन सेवा सेट करायची असल्यास, ते कसे सेट करावे याबद्दल टिपा सामायिक करण्यासाठी नेहमी तयार असतात. मानक RAS किंवा OpenVPN. परंतु, आम्ही कितीही थंड असलो तरीही, ग्राहकांमध्ये शैक्षणिक कार्य करण्यासाठी ही सर्वोत्तम वेळ नव्हती, कारण आम्हाला वापरकर्त्यांसाठी कमीतकमी तणावासह शक्य तितक्या लवकर समस्येचे निराकरण करण्याची आवश्यकता होती.
आम्ही लागू केलेला उपाय खालीलप्रमाणे होता. आम्ही पोर्ट 3389 वर TCP कनेक्शन स्थापित करण्याच्या सर्व प्रयत्नांवर लक्ष ठेवण्यासाठी अशा प्रकारे ट्रॅफिक पास करण्याचे विश्लेषण सेट केले आहे आणि त्यामधून 150 सेकंदांच्या आत आमच्या नेटवर्कवर 16 पेक्षा जास्त भिन्न सर्व्हरसह कनेक्शन स्थापित करण्याचा प्रयत्न करण्याचा पत्ता निवडा. - हे आक्रमणाचे स्त्रोत आहेत ( अर्थातच, जर एखाद्या क्लायंट किंवा भागीदारांना एकाच स्त्रोताच्या अनेक सर्व्हरशी कनेक्शन स्थापित करण्याची खरोखर आवश्यकता असेल, तर तुम्ही नेहमीच अशा स्त्रोतांना "व्हाइट लिस्ट" मध्ये जोडू शकता. शिवाय, जर या 150 सेकंदांसाठी एका वर्ग C नेटवर्कमध्ये, 32 पेक्षा जास्त पत्ते ओळखले गेले, तर संपूर्ण नेटवर्क अवरोधित करणे अर्थपूर्ण आहे. अवरोधित करणे 3 दिवसांसाठी सेट केले आहे, आणि या काळात दिलेल्या स्त्रोताकडून कोणतेही हल्ले केले गेले नाहीत तर, हा स्त्रोत आपोआप “ब्लॅक लिस्ट” मधून काढला जातो. ब्लॉक केलेल्या स्त्रोतांची यादी दर 300 सेकंदांनी अपडेट केली जाते.
ही यादी या पत्त्यावर उपलब्ध आहे: , तुम्ही त्यावर आधारित तुमचे ACL तयार करू शकता.
आम्ही अशा प्रणालीचा स्त्रोत कोड सामायिक करण्यास तयार आहोत; त्यात फारसे क्लिष्ट काहीही नाही (या अनेक सोप्या स्क्रिप्ट आहेत ज्या अक्षरशः गुडघ्यावर काही तासांत संकलित केल्या आहेत), आणि त्याच वेळी ते रुपांतरित केले जाऊ शकते आणि वापरले जाऊ शकत नाही. केवळ अशा हल्ल्यापासून संरक्षण करण्यासाठी, परंतु नेटवर्क स्कॅन करण्याचे कोणतेही प्रयत्न शोधणे आणि अवरोधित करणे देखील:
याव्यतिरिक्त, आम्ही मॉनिटरींग सिस्टमच्या सेटिंग्जमध्ये काही बदल केले आहेत, जे आता आमच्या क्लाउडमधील व्हर्च्युअल सर्व्हरच्या नियंत्रण गटाच्या RDP कनेक्शन स्थापित करण्याच्या प्रयत्नाच्या प्रतिक्रियेचे अधिक बारकाईने निरीक्षण करते: जर प्रतिक्रिया एका आत पाळली नाही तर दुसरे, हे लक्ष देण्याचे एक कारण आहे.
समाधान बरेच प्रभावी ठरले: क्लायंट आणि भागीदार आणि मॉनिटरिंग सिस्टमकडून यापुढे कोणत्याही तक्रारी नाहीत. नवीन पत्ते आणि संपूर्ण नेटवर्क नियमितपणे ब्लॅकलिस्टमध्ये जोडले जातात, जे सूचित करते की हल्ला सुरूच आहे, परंतु यापुढे आमच्या क्लायंटच्या कामावर परिणाम होणार नाही.
संख्येत सुरक्षितता आहे
आज आम्हाला कळले की इतर ऑपरेटरनाही अशीच समस्या आली आहे. कोणीतरी अजूनही विश्वास ठेवतो की मायक्रोसॉफ्टने रिमोट ऍक्सेस सेवेच्या कोडमध्ये काही बदल केले आहेत (जर तुम्हाला आठवत असेल, तर पहिल्या दिवशी आम्हाला त्याच गोष्टीचा संशय होता, परंतु आम्ही ही आवृत्ती फार लवकर नाकारली) आणि त्वरीत उपाय शोधण्यासाठी शक्य ते सर्व करण्याचे वचन दिले. . काही लोक फक्त समस्येकडे दुर्लक्ष करतात आणि क्लायंटला स्वतःचे संरक्षण करण्याचा सल्ला देतात (कनेक्शन पोर्ट बदला, खाजगी नेटवर्कमध्ये सर्व्हर लपवा इ.). आणि पहिल्याच दिवशी, आम्ही केवळ या समस्येचे निराकरण केले नाही, तर आम्ही विकसित करण्याची योजना आखत असलेल्या अधिक जागतिक धोका शोध प्रणालीसाठी काही आधार तयार केला.
ग्राहक आणि भागीदारांचे विशेष आभार जे गप्प बसले नाहीत आणि नदीच्या काठावर शत्रूच्या प्रेतावर एक दिवस तरंगण्याची वाट पाहत बसले नाहीत, परंतु त्वरित आमचे लक्ष या समस्येकडे वेधले, ज्यामुळे आम्हाला दूर करण्याची संधी मिळाली. त्याच दिवशी.
स्त्रोत: www.habr.com