आईबी फाकरेपी 2019 - ठेठ और बहुत नहीं

"लेकिन यह उबाऊ नहीं है!" - यह हमारे सौर JSOC साइबर खतरे निगरानी केंद्र के कर्मचारियों का अनौपचारिक आदर्श वाक्य है (और मुझे कहना होगा कि 2019 पूरी तरह से इसके अनुरूप है)। नए साल की शुरुआत में, बहुत से लोग स्टॉक लेना पसंद करते हैं और नए लक्ष्य निर्धारित करते हैं, लेकिन इसके बजाय हमने कुछ "हमारे शहर की भयावहता" - 2019 के मामलों को बताने का फैसला किया, जिन्होंने अनुभवी विश्लेषकों को भी प्रभावित किया। इन कहानियों से निष्कर्ष केवल एक है: प्रौद्योगिकी विकसित होती है और विकसित होती है, और मानव आलस्य, लापरवाही और लापरवाही शाश्वत है।

अतिथि वाईफ़ाई

ग्राहकों को निगरानी से जोड़ते समय, हम सबसे पहले सबसे महत्वपूर्ण जानकारी मांगते हैं: महत्वपूर्ण खाते, डोमेन समूह, अविश्वासित खंड, सफेद पते, डीएमजेड, महत्वपूर्ण सबनेट, आदि। अविश्वसनीय सबनेट्स केवल अतिथि वाई-फाई, साथ ही ठेकेदार नेटवर्क हैं, किसी भी किसी को अनुमति देने के लिए अनुमति के साथ परीक्षण खंडों, आदि ... आमतौर पर हम देखते हैं कि ऐसे खंडों के साथ बातचीत की संभावना अनुपस्थित या गंभीरता से सीमित है, क्योंकि उन्हें नियंत्रित करना बहुत मुश्किल है, अगर असंभव नहीं है। ग्राहक के नेटवर्क पर, अतिथि नेटवर्क में प्राधिकरण पृष्ठ को छोड़कर, इस तरह की बातचीत की कोई संभावना नहीं थी। हमने टीओआर, सी एंड सी सर्वर और अन्य बुरी आत्माओं के साथ वाई-फाई से बातचीत पर प्रतिबंध लगाकर शांत किया, ताकि हम उन ऑपरेशनों के साथ बमबारी न करें जो एक संभावित ग्राहक के लिए दिलचस्प नहीं थे (हालांकि हमने सारांश रिपोर्ट के साथ इन घटनाओं पर आंकड़े एकत्र किए)। और पायलट प्रोजेक्ट की तीसरी सुबह, हमने एक विसंगति पर गौर किया: फ़ायरवॉल से घटनाओं का प्रवाह 4 गुना बढ़ गया!



वे "रुकावट" के कारण की तलाश करने लगे और, आश्चर्य के साथ, इसे अतिथि वाई-फाई के खंड में पाया। एक निश्चित मेजबान ने प्रति घंटे 4 मिलियन (!) घटनाएँ उत्पन्न कीं। और घटनाएँ काफी दिलचस्प हैं - बंदरगाह 445 पर इंटरनेट स्थान के यादृच्छिक सफेद पते पर कनेक्शन। चार लाख, कार्ल!



इस बारे में ग्राहक को सूचित करने के बाद, वे होस्ट और घटना के बारे में जानकारी के लिए इंतजार करना शुरू कर देते हैं, क्योंकि डीएचसीपी (यह प्राधिकरण सर्वर है) से कनेक्ट नहीं था। लगभग 3-4 घंटे के बाद, ग्राहक ने बताया कि होस्ट एक मोबाइल फोन है। यह कहने के लिए कि हमें आश्चर्य हुआ कि कुछ भी नहीं कहना है। एक साधारण मोबाइल फोन घटनाओं की ऐसी धारा उत्पन्न नहीं कर सकता है। उन्होंने विवरणों का पता लगाना शुरू किया, और यह पता चला कि मोबाइल फोन का इससे कोई लेना-देना नहीं था - किसी ने कवर के रूप में पंजीकृत उपकरणों में से किसी एक का उपयोग किया था। गतिविधि का वास्तविक स्रोत खोजना संभव नहीं था, और हमारे ग्राहक ने कहा कि वह इस मामले में दिलचस्पी नहीं रखते थे, इसलिए गतिविधि को कम से कम करना पड़ा। फिर भी, हमने ग्राहक के विशेषज्ञों को संभावित जोखिमों के बारे में चेतावनी दी: चूंकि गतिविधि (स्पष्ट रूप से दुर्भावनापूर्ण) उनके पते से आती है, इसलिए, उदाहरण के लिए, वे एंटी-वायरस विक्रेताओं के सी एंड सी-सर्वर की सूची में शामिल हो सकते हैं और कानून प्रवर्तन एजेंसियों से शिकायतें प्राप्त कर सकते हैं (जो जानते हैं कि यह होस्ट कौन सा बुनियादी ढांचा स्कैन करेगा। - आखिरकार, केआईआई हो सकता है, और कमजोरियों के लिए स्कैनिंग उन घटनाओं को संदर्भित करती है जिन्हें गोसोप्का को सूचित किया जाना चाहिए)। इस तरह के तर्कों के बाद, ग्राहक ने अभी भी अधिक विस्तार से समझने और हमारी सिफारिशों को पूरा करने का निर्णय लिया। और वे इस प्रकार थे:

1. 80 और 443 को छोड़कर सभी बंदरगाहों को बंद कर दें (यह सही निर्णय था, क्योंकि 445 के बाद पोर्ट 22 पर एक स्कैन के बाद)
2. हम दिए गए इंटरनेट की गति पर प्रतिबंध लगाते हैं,
3. आवेदन नियंत्रण सहित UTM चिप्स को सक्रिय करें, और टोरेंट, टीओआर ब्राउजर्स, डिटेक्ट किए गए स्कैनर और अन्य जैसी अजीब श्रेणियों को काटें,
4. समय अंतराल पर कनेक्शन की संख्या पर सीमा को चालू करें।

ग्राहक कभी भी यह पता लगाने में सक्षम नहीं था कि यह सक्रिय वाई-फाई उपयोगकर्ता कौन है, लेकिन कम से कम उन्होंने उसे ऑक्सीजन के साथ अवरुद्ध कर दिया (और, सबसे अधिक संभावना है, हमलावर अगले उपलब्ध वाई-फाई की तलाश में चला गया।

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

डिफ़ॉल्ट रूप से, या विक्रेता तोड़फोड़

सौर जेएसओसी निगरानी के पायलट कनेक्शन के समानांतर, ग्राहक ने एक नया UTM कमीशन किया। इसके लिए माइग्रेशन चरणबद्ध किया गया था: पहले ACL को सबनेट्स पर स्थानांतरित किया, फिर एप्लिकेशन पॉलिसियों को। मिठाई सबसे दिलचस्प है।

सब कुछ क्लासिक्स के अनुसार हुआ - शुक्रवार रात को। पहली लाइन ने TOR नोड्स के लिए ग्राहक के बुनियादी ढांचे से संपर्क करने में गड़बड़ी दर्ज की, जो FinCERT मेलिंग सूचियों में से एक में C & C के रूप में प्रदर्शित हुआ। चूंकि परियोजना एक पायलट थी और ग्राहक ने सभी घटनाओं को कम-आलोचनात्मकता में स्थानांतरित कर दिया था, इसलिए मेल द्वारा सूचना कार्ड के अलावा कोई घटना कार्ड प्रदान नहीं किया गया था। इसलिए, अलग-अलग मेजबानों से एक पते पर पहला ऑपरेशन, हालांकि यह निगरानी इंजीनियरों के बीच संदेह पैदा करता था, आगे नहीं बढ़ाया गया था। जब यात्राओं की संख्या तीन तक पहुँच गई, तो लोगों के होश उड़ गए और उन्होंने उस विश्लेषक को सूचित किया जिसने इस घटना को अंजाम दिया।



सबसे पहले, विश्लेषक ने ग्राहक के जिम्मेदार कर्मचारियों से संपर्क किया और गतिविधि के स्रोत की पहचान करने के लिए स्थानीय लॉग स्तर पर मेजबानों को जोड़ने का सुझाव दिया। ग्राहक के विशेषज्ञों के साथ चर्चा के समय, मेजबानों की संख्या 7. हो गई थी। स्थिति महामारी के समान थी, लेकिन मेजबानों पर एंटीवायरस काम कर रहे थे और चुप थे, नेटवर्क पर कोई सक्रिय क्रिया और मेजबान बातचीत नहीं थी।

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

शीर्षक के लेख में ध्यान आकर्षित किया गया था, जिसमें IP पता और UTM विक्रेता का नाम दिखाई दिया था। प्रकाशन के सार को संक्षेप में प्रस्तुत करने के लिए, विक्रेता ने एक आईपी पता खरीदा जो पहले टीओआर-नोड से संबंधित था, जिसे FinCERT न्यूज़लेटर पर चित्रित किया गया था। और यह केवल इतना ही नहीं है! इसके अलावा, विक्रेता ने अपने ग्राहकों के बुनियादी ढांचे से संभावित रूप से दुर्भावनापूर्ण पते के सभी संदिग्ध कॉल के पुनर्निर्देशन के लिए इस पते को डिफ़ॉल्ट बनाने का फैसला किया। यही है, एक अजीब आईपी पते के साथ किसी भी कनेक्शन को UTM द्वारा नाजायज समझा गया और इस चमत्कारी पते पर पुनर्निर्देशित किया गया।



यह निर्दिष्ट करने के बाद कि क्या एंटी-मालवेयर प्रोटेक्शन मॉड्यूल पहले से मौजूद है, और इसकी पुष्टि होने के बाद, विश्लेषक और ग्राहक के विशेषज्ञ इससे बच गए।

PSM का असफल विश्लेषण जो UTM ने पाया कि सभी 7 गतिविधियाँ झूठी सकारात्मक थीं, की पुष्टि करता है।

हमने प्रत्येक मामले के लिए सिफारिशों का वादा किया था, लेकिन यहां, शायद, हम केवल एक ही देंगे: शुक्रवार को तैनात न करें। और सभी इच्छुक और सहानुभूति रखने वालों को चेतावनी दी।

ऐतिहासिक दृष्टि से

यह लेटमोटिफ विभिन्न प्रकार के मामलों को एक साथ लाता है। उदाहरण के लिए decommissioning ले लो। अक्सर कंपनियों में प्रासंगिकता खो चुकी प्रक्रियाओं को आसानी से भुला दिया जाता है: पुराने वर्चुअल मशीन, सर्वर और नेटवर्क एक्सेस को छोड़कर, कोई भी "बुनियादी ढांचा" नहीं बनाता है। इसी समय, कोई भी इन मेजबानों पर अपडेट, एंटीवायरस और घटनाओं की निगरानी नहीं करता है, और यहां तक ​​कि व्यवस्थापक भी अक्सर सिस्टम के मालिकों को नहीं जानते हैं। इसलिए, थोड़ी देर के बाद ऐसे बुनियादी तत्व तत्व सबसे सुखद आश्चर्य नहीं पेश करते हैं। 2005 में एक गैर-अनुकूल देश के एफ़टीपी सर्वरों को पूरा करने वाले प्रोजेक्ट पर एक पर्यावरण संगठन से महत्वपूर्ण टेलीमेट्री भेजने के लिए केवल क्या खर्च होता है!

अक्सर कोई भी 10-वर्षीय सिस्टम के रखरखाव से संबंधित नहीं है, हालांकि उनका उपयोग जारी है। उदाहरण के लिए, एक पासवर्ड रीसेट पोर्टल जो प्राचीन इंजन का उपयोग करता है और उपयोगकर्ताओं की सुविधा के लिए इंटरनेट, या आरडीपी को देखता है, जिसे ठेकेदार को व्यावसायिक अनुप्रयोगों को कॉन्फ़िगर करने की आवश्यकता होती है और 5-6 वर्षों तक चिपक जाती है।

ऐसी समस्याओं का अस्तित्व आमतौर पर तब ज्ञात होता है जब:

1. होस्ट हैक कर लिया गया था, और एन्क्रिप्शन आगे जबरन वसूली के साथ हुआ (हाल ही में ऐसी कई घटनाएं हुई हैं),
2. परिधि पर एक समाधान से दूसरे में प्रवास होता है,
3. हम पायलट के पास आते हैं और परिधि पर खुले बंदरगाहों की रूपरेखा एकत्र करते हैं।

लेकिन पूरी तरह से पौराणिक परिस्थितियां भी हैं: 2013 में, कंपनी ने एक सुरंग का निर्माण किया जिसमें एक ठेकेदार अपनी वित्तीय प्रणाली की सेवा कर रहा था। अनुबंध समाप्त हो गया, लेकिन सुरंग बनी रही, क्योंकि यह कंपनी द्वारा बनाई गई थी, जिसमें से ठेकेदार ने आईटी बुनियादी ढांचे के साथ परिसर किराए पर लिया था। एक नई कंपनी ने वही जगह ली और अन्य लोगों के बुनियादी ढांचे के उपलब्ध पते पाकर आश्चर्यचकित थी। जिज्ञासा ने संभाला और फिर लाभ के लिए प्रलोभन और प्यास। उन्होंने शोर करने के लिए समकक्षों और अनुबंधों के एक डेटाबेस को फेंक दिया - प्रतियोगिता का लाभ दिलचस्प था, लेकिन पीड़ित कंपनी में किसी ने भी शोर नहीं किया। कहानी एक साल से अधिक समय तक चली (यह लॉग्स के साथ आगे ट्रेस करना संभव नहीं था), लेकिन अंत में, केक पर जांच, बर्खास्तगी और चेरी एक आपराधिक मामला है।

AWOL, या क्योंकि यह अधिक सुविधाजनक है

एक पूरे के रूप में मामला बल्कि तुच्छ है, जिसे "कार्यान्वयन पद्धति" के बारे में नहीं कहा जा सकता है।

दिए गए:

1. ग्राहक निगरानी पायलट परियोजना;
2. परिधि पर जुड़े स्रोतों, साथ ही कॉर्पोरेट और तकनीकी क्षेत्रों के बीच;
3. कार्यस्थल पर ड्यूटी पर व्यवस्थापक और बंद नेटवर्क खंड की सेवा;
4. व्यवस्थापक की तीव्र इच्छा कम काम करना, अधिक सोना और आराम से सब कुछ करना है।

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

जाँच करते समय यह पता चला कि यह हमारे पते पर बंद है। हमने सोचा था कि वह श्वेत सूची में खुला था, लेकिन दिन के दौरान हमने उस पर कोई सफल कनेक्शन नहीं देखा। अगली सुबह पहुंचकर, उन्होंने फिर से देखा कि रात भर में एक पैकेट का कार्यक्रम आ गया था। इस बार हमने स्रोत पते पर करीब से नज़र डाली और 5 घंटे से अधिक की कुल अवधि के साथ मास्को से कई सत्रों को देखा और दुनिया भर से छोटे सत्रों की एक बड़ी संख्या। फिर यह स्पष्ट हो गया कि बिंदु यह नहीं था कि पोर्ट केवल सफेद सूची से पते के लिए सुलभ था, लेकिन यह केवल रात में खोला गया - सुबह लगभग 00.00 से 06.00 बजे तक। डोमेन और एंटीवायरस से लॉग्स को खोदने के बाद (वे उस समय तक कनेक्ट हो चुके थे), हमें यह जानकर आश्चर्य हुआ कि पता ड्यूटी पर व्यवस्थापक का है, जो इस समय अंतराल के दौरान कार्यस्थल पर होना चाहिए! उनकी कार से कनेक्शन का विश्लेषण करने के बाद, हमें एक और दिलचस्प स्थिति मिली: हर रात, बंदरगाह भी खुल गया (मुझे लगता है कि बंद किए गए सेगमेंट में कौन सा अनुमान लगाना मुश्किल नहीं है)। पायलट के चौथे दिन ऐसी गतिविधि को नोटिस करना लगभग असंभव है, उस समय तक खंडों के बीच अनुमत कनेक्शन की संख्या अभी भी परिधि पर खुले बंदरगाहों से अधिक है। सुरक्षा गार्डों को स्थिति के बारे में सूचित करने के बाद, उन्होंने मेजबान को स्थानीय लॉग स्तर पर कनेक्ट किया और सुनिश्चित किया कि व्यवस्थापक चुपचाप घर से काम से भाग रहा था। जैसा कि यह पता चला, वह लगभग एक पड़ोसी घर में रहता था, और रिमोट कनेक्शन, निश्चित रूप से, बहुत अधिक प्रलोभन बन गया।

शायद अगर व्यवस्थापक ने स्थिति को रेखांकित किया, तो उसे SKDPU के माध्यम से दूर से काम करने की अनुमति दी जाएगी, बशर्ते कि दुर्घटना के समय वह 15 मिनट के भीतर काम करने में सक्षम हो जाएगा, और कोई समस्या नहीं होगी।

कुल मिलाकर

हकीकत में, सूचना सुरक्षा के लिए मुख्य खतरों में से एक जमीन पर चल रहा है। इसलिए, जोखिमों को कम से कम करें:

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