कसरी "तेस्रो पक्षहरू" ले हाम्रा ग्राहकहरूको काममा हस्तक्षेप गर्ने प्रयास गरे, र यो समस्या कसरी समाधान भयो भन्ने बारे एउटा सुन्दर कथा बताउनुहोस्।
यो सबै कसरी सुरु भयो
यो सबै अक्टोबर 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) रिमोट पहुँच सेवाको लागि प्रयोग गरिन्छ र सबै ठाउँबाट पहुँच अनुमति दिइन्छ। इन्टरनेट बटहरूले भरिएको छ जसले लगातार सबै उपलब्ध जडान बिन्दुहरू स्क्यान गर्दछ र पासवर्ड अनुमान लगाउने प्रयास गर्दछ (यसैले हामी "१२३" को सट्टा जटिल पासवर्डहरू प्रयोग गर्न सिफारिस गर्छौं)। यद्यपि, त्यस दिन यी प्रयासहरूको तीव्रता धेरै उच्च थियो।
कसरी अगाडि बढ्ने?
सिफारिस गर्नुहोस् कि ग्राहकहरूले फरक पोर्टमा स्विच गर्न अन्तिम प्रयोगकर्ताहरूको ठूलो संख्याको लागि सेटिङहरू परिवर्तन गर्न धेरै समय खर्च गर्छन्? राम्रो विचार होइन, ग्राहकहरू खुसी हुनेछैनन्। VPN मार्फत मात्र पहुँच अनुमति दिने सिफारिस गर्नुहुन्छ? हतार र आतंकमा, IPSec जडानहरू उठाउन नपाएकाहरूका लागि - सायद यस्तो खुसीले ग्राहकहरूलाई पनि मुस्कुराउँदैन। यद्यपि, मैले भन्नै पर्छ, यो कुनै पनि अवस्थामा एक ईश्वरीय कुरा हो, हामी सधैँ निजी नेटवर्कमा सर्भर लुकाउन सिफारिस गर्छौं र सेटिङहरूमा मद्दत गर्न तयार छौं, र जो आफैंले यसलाई पत्ता लगाउन मन पराउँछन्, हामी निर्देशनहरू साझा गर्छौं। साइट-टू-साइट वा रोड मोडमा हाम्रो क्लाउडमा IPSec/L2TP सेटअप गर्नका लागि, र यदि कोही आफ्नै विन्डोज सर्भरमा VPN सेवा सेटअप गर्न चाहन्छ भने, तिनीहरू कसरी सेटअप गर्ने भन्ने बारे सुझावहरू साझा गर्न सधैं तयार छन्। मानक RAS वा OpenVPN। तर, हामी जतिसुकै चिसो भए तापनि, ग्राहकहरूका बीचमा शैक्षिक कार्य सञ्चालन गर्ने यो उत्तम समय थिएन, किनकि हामीले प्रयोगकर्ताहरूको लागि न्यूनतम तनावको साथ सकेसम्म चाँडो समस्या समाधान गर्न आवश्यक छ।
हामीले लागू गरेको समाधान निम्नानुसार थियो। हामीले पोर्ट 3389 मा TCP जडान स्थापना गर्ने सबै प्रयासहरू निगरानी गर्न र 150 सेकेन्ड भित्र हाम्रो नेटवर्कमा 16 भन्दा बढी विभिन्न सर्भरहरूसँग जडानहरू स्थापना गर्ने प्रयास गर्ने ठेगानाहरू चयन गर्ने तरिकामा ट्राफिक पास गर्ने विश्लेषण सेट अप गरेका छौं। - यी आक्रमणका स्रोतहरू हुन् ( निस्सन्देह, यदि ग्राहक वा साझेदारहरू मध्ये एकलाई एउटै स्रोतबाट धेरै सर्भरहरूसँग जडानहरू स्थापना गर्न वास्तविक आवश्यकता छ भने, तपाइँ सधैं त्यस्ता स्रोतहरूलाई "सेतो सूची" मा थप्न सक्नुहुन्छ। यदि यी 150 सेकेन्डको लागि एक कक्षा C नेटवर्कमा, 32 भन्दा बढी ठेगानाहरू पहिचान गरिएको छ भने, यसले सम्पूर्ण नेटवर्कलाई ब्लक गर्न अर्थपूर्ण हुन्छ। अवरुद्ध 3 दिनको लागि सेट गरिएको छ, र यदि यस अवधिमा दिइएको स्रोतबाट कुनै आक्रमणहरू गरिएको छैन भने, यो स्रोत स्वचालित रूपमा "कालो सूची" बाट हटाइन्छ। अवरुद्ध स्रोतहरूको सूची प्रत्येक 300 सेकेन्डमा अद्यावधिक गरिन्छ।
यो सूची यस ठेगानामा उपलब्ध छ: , तपाईं यसको आधारमा आफ्नो ACLs निर्माण गर्न सक्नुहुन्छ।
हामी यस्तो प्रणालीको स्रोत कोड साझा गर्न तयार छौं; यसमा धेरै जटिल केही छैन (यी धेरै सरल स्क्रिप्टहरू शाब्दिक रूपमा घुँडामा केही घण्टामा कम्पाइल गरिएका छन्), र एकै समयमा यसलाई अनुकूलन गर्न सकिन्छ र प्रयोग नगर्न सकिन्छ। यस्तो आक्रमणबाट बचाउन मात्र, तर नेटवर्क स्क्यान गर्ने कुनै पनि प्रयास पत्ता लगाउन र अवरुद्ध गर्न पनि:
थप रूपमा, हामीले निगरानी प्रणालीको सेटिङहरूमा केही परिवर्तनहरू गरेका छौं, जसले अब हाम्रो क्लाउडमा भर्चुअल सर्भरहरूको नियन्त्रण समूहको RDP जडान स्थापना गर्ने प्रयासको प्रतिक्रियालाई अझ नजिकबाट निगरानी गर्दछ: यदि प्रतिक्रिया एक भित्र पछ्याउँदैन। दोस्रो, यो ध्यान दिन एक कारण हो।
समाधान एकदम प्रभावकारी भयो: ग्राहक र साझेदारहरू, र अनुगमन प्रणालीबाट कुनै थप गुनासोहरू छैनन्। नयाँ ठेगानाहरू र सम्पूर्ण सञ्जालहरू नियमित रूपमा कालोसूचीमा थपिन्छन्, जसले आक्रमण जारी रहेको संकेत गर्छ, तर अब हाम्रा ग्राहकहरूको कामलाई असर गर्दैन।
संख्यामा सुरक्षा छ
आज हामीले थाहा पायौं कि अन्य अपरेटरहरूले पनि यस्तै समस्याको सामना गरेका छन्। कसैले अझै पनि विश्वास गर्दछ कि माइक्रोसफ्टले रिमोट पहुँच सेवाको कोडमा केही परिवर्तनहरू गर्यो (यदि तपाइँ सम्झनुहुन्छ भने, हामीले पहिलो दिनमा एउटै कुरालाई शंका गर्यौं, तर हामीले यो संस्करणलाई छिट्टै अस्वीकार गर्यौं) र चाँडै समाधान खोज्नको लागि सबै सम्भव गर्ने वाचा गर्दछ। । केही व्यक्तिहरूले समस्यालाई बेवास्ता गर्छन् र ग्राहकहरूलाई आफैंलाई सुरक्षित गर्न सल्लाह दिन्छन् (जडान पोर्ट परिवर्तन गर्नुहोस्, सर्भरलाई निजी नेटवर्कमा लुकाउनुहोस्, र यस्तै अन्य)। र पहिलो दिनमा, हामीले यो समस्या समाधान मात्र गरेनौं, तर थप विश्वव्यापी खतरा पत्ता लगाउने प्रणालीको लागि केही आधारहरू पनि सिर्जना गरेका छौं, जुन हामीले विकास गर्ने योजना बनाएका छौं।
एक दिन शत्रुको लाश तैरने गरी नदीको किनारमा नबस्ने र एक दिन शत्रुको लाशको पर्खाइमा नबस्ने ग्राहक र साझेदारहरूलाई विशेष धन्यवाद, तर तुरुन्तै समस्यामा हाम्रो ध्यानाकर्षण गराए, जसले हामीलाई हटाउने मौका दियो। यो एकै दिनमा।
स्रोत: www.habr.com