उद्धारको लागि DDoS: हामी कसरी तनाव र लोड परीक्षणहरू सञ्चालन गर्छौं

Variti ले बट र DDoS आक्रमणहरू विरुद्ध सुरक्षा विकास गर्दछ, र तनाव र लोड परीक्षण पनि सञ्चालन गर्दछ। HighLoad++ 2018 सम्मेलनमा हामीले विभिन्न प्रकारका आक्रमणहरूबाट स्रोतहरू कसरी सुरक्षित गर्ने भन्ने बारेमा कुरा गर्यौं। छोटकरीमा: प्रणालीका भागहरू अलग गर्नुहोस्, क्लाउड सेवाहरू र CDN प्रयोग गर्नुहोस्, र नियमित रूपमा अद्यावधिक गर्नुहोस्। तर तपाइँ अझै पनि विशेष कम्पनीहरु बिना सुरक्षा ह्यान्डल गर्न सक्षम हुनुहुने छैन :)

पाठ पढ्नु अघि, तपाईं छोटो सारहरू पढ्न सक्नुहुन्छ सम्मेलन वेबसाइटमा.
र यदि तपाइँ पढ्न चाहनुहुन्न वा भिडियो हेर्न चाहनुहुन्छ भने, हाम्रो रिपोर्टको रेकर्डिङ तल स्पोइलर अन्तर्गत छ।

रिपोर्टको भिडियो रेकर्डिङ

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

हामी कसरी काम गरिरहेका छौं

परीक्षण गर्दा, हामी बोटनेट अनुकरण गर्छौं। हामी हाम्रा नेटवर्कहरूमा अवस्थित नभएका ग्राहकहरूसँग काम गर्ने भएकाले, सीमा वा सुरक्षा ट्रिगर भएको कारणले गर्दा परीक्षण पहिलो मिनेटमा समाप्त हुँदैन भनेर सुनिश्चित गर्न, हामी एउटा IP बाट होइन, तर हाम्रो आफ्नै सबनेटबाट लोड आपूर्ति गर्छौं। साथै, महत्त्वपूर्ण लोड सिर्जना गर्न, हामीसँग हाम्रो आफ्नै पर्याप्त शक्तिशाली परीक्षण सर्भर छ।

पोष्टुलेट गर्दछ

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

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

राम्रो वास्तुकला दिगोपन को आधार हो
स्रोतको गल्ती सहिष्णुता र आक्रमण र भारहरू सामना गर्ने क्षमतालाई डिजाइनको चरणमा, वास्तवमा, नोटबुकमा पहिलो फ्लोचार्टहरू कोर्ने चरणमा राखिएको हुनुपर्छ। किनभने यदि घातक त्रुटिहरू भित्र पसे भने, भविष्यमा तिनीहरूलाई सच्याउन सम्भव छ, तर यो धेरै गाह्रो छ।

न केवल कोड राम्रो हुनुपर्छ, तर कन्फिगरेसन पनि
धेरै मानिसहरू सोच्छन् कि एक राम्रो विकास टोली दोष-सहिष्णु सेवाको ग्यारेन्टी हो। एक राम्रो विकास टोली साँच्चै आवश्यक छ, तर त्यहाँ राम्रो सञ्चालन, राम्रो DevOps पनि हुनुपर्छ। त्यो हो, हामीलाई विशेषज्ञहरू चाहिन्छ जसले लिनक्स र नेटवर्कलाई सही रूपमा कन्फिगर गर्नेछ, nginx मा कन्फिगहरू सही रूपमा लेख्नेछ, सीमाहरू सेट गर्नेछ। अन्यथा, संसाधनले परीक्षणमा मात्र राम्रो काम गर्नेछ, र केहि बिन्दुमा सबै उत्पादनमा तोडिनेछ।

लोड र तनाव परीक्षण बीचको भिन्नता
लोड परीक्षणले तपाईंलाई प्रणाली कार्यको सीमाहरू पहिचान गर्न अनुमति दिन्छ। तनाव परीक्षण प्रणालीमा कमजोरीहरू फेला पार्ने उद्देश्य हो र यो प्रणाली तोड्न र निश्चित भागहरूको विफलताको प्रक्रियामा यसले कसरी व्यवहार गर्नेछ भनेर हेर्न प्रयोग गरिन्छ। यस अवस्थामा, तनाव परीक्षण सुरु हुनु अघि लोडको प्रकृति सामान्यतया ग्राहकलाई अज्ञात रहन्छ।

L7 आक्रमणहरूको विशिष्ट विशेषताहरू

हामी सामान्यतया L7 र L3 र 4 स्तरहरूमा लोडका प्रकारहरूलाई लोडहरूमा विभाजन गर्छौं। L7 अनुप्रयोग स्तरमा लोड हो, प्रायः यसको अर्थ HTTP मात्र हो, तर हाम्रो मतलब TCP प्रोटोकल स्तरमा कुनै पनि लोड हो।
L7 आक्रमणहरूमा केही विशिष्ट सुविधाहरू छन्। सर्वप्रथम, तिनीहरू सिधै एप्लिकेसनमा आउँछन्, अर्थात्, तिनीहरू नेटवर्क माध्यमबाट प्रतिबिम्बित हुने सम्भावना छैन। त्यस्ता आक्रमणहरूले तर्क प्रयोग गर्दछ, र यसको कारण, तिनीहरूले CPU, मेमोरी, डिस्क, डाटाबेस र अन्य स्रोतहरू धेरै कुशलतापूर्वक र थोरै ट्राफिकको साथ खपत गर्छन्।

HTTP बाढी

कुनै पनि आक्रमणको अवस्थामा, ह्यान्डल गर्न भन्दा लोड सिर्जना गर्न सजिलो छ, र L7 को मामलामा यो पनि सत्य हो। आक्रमण ट्राफिकलाई वैध ट्राफिकबाट छुट्याउन सँधै सजिलो हुँदैन, र प्राय: यो फ्रिक्वेन्सी द्वारा गर्न सकिन्छ, तर यदि सबै कुरा सही रूपमा योजना गरिएको छ भने, लगहरूबाट यो बुझ्न असम्भव छ कि आक्रमण कहाँ छ र वैध अनुरोधहरू कहाँ छन्।
पहिलो उदाहरणको रूपमा, HTTP फ्लड आक्रमणलाई विचार गर्नुहोस्। ग्राफले देखाउँछ कि त्यस्ता आक्रमणहरू सामान्यतया धेरै शक्तिशाली हुन्छन्; तलको उदाहरणमा, अनुरोधहरूको शिखर संख्या प्रति मिनेट 600 हजार नाघेको छ।

HTTP फ्लड लोड सिर्जना गर्न सजिलो तरिका हो। सामान्यतया, यसले केहि प्रकारको लोड परीक्षण उपकरण लिन्छ, जस्तै ApacheBench, र अनुरोध र लक्ष्य सेट गर्दछ। यस्तो सरल दृष्टिकोणको साथ, सर्भर क्यासिङमा चल्ने उच्च सम्भावना छ, तर यसलाई बाइपास गर्न सजिलो छ। उदाहरणका लागि, अनुरोधमा अनियमित स्ट्रिङहरू थप्दै, जसले सर्भरलाई लगातार नयाँ पृष्ठ सेवा गर्न बाध्य पार्छ।
साथै, लोड सिर्जना गर्ने प्रक्रियामा प्रयोगकर्ता-एजेन्टको बारेमा नबिर्सनुहोस्। लोकप्रिय परीक्षण उपकरणहरूको धेरै प्रयोगकर्ता-एजेन्टहरू प्रणाली प्रशासकहरूद्वारा फिल्टर गरिएका छन्, र यस अवस्थामा लोड ब्याकइन्डमा पुग्न सक्दैन। तपाईले अनुरोधमा ब्राउजरबाट कम वा कम मान्य हेडर सम्मिलित गरेर परिणामलाई उल्लेखनीय रूपमा सुधार गर्न सक्नुहुन्छ।
HTTP फ्लड आक्रमणहरू जत्तिकै सरल छन्, तिनीहरूका कमजोरीहरू पनि छन्। पहिलो, लोड सिर्जना गर्न ठूलो मात्रामा शक्ति आवश्यक छ। दोस्रो, त्यस्ता आक्रमणहरू पत्ता लगाउन धेरै सजिलो छ, विशेष गरी यदि तिनीहरू एक ठेगानाबाट आउँछन्। नतिजाको रूपमा, अनुरोधहरू तुरुन्तै प्रणाली प्रशासकहरू वा प्रदायक स्तरमा पनि फिल्टर गर्न सुरु हुन्छ।

के खोज्ने

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

कहाँ खोज्ने

जब हामी परीक्षण गर्नु अघि स्रोत स्क्यान गर्छौं, हामी पहिले साइटमा नै हेर्छौं। हामी सबै प्रकारका इनपुट फिल्डहरू, भारी फाइलहरू खोजिरहेका छौं - सामान्यतया, सबै चीजहरू जसले स्रोतको लागि समस्याहरू सिर्जना गर्न सक्छ र यसको सञ्चालनलाई ढिलो गर्न सक्छ। गुगल क्रोम र फायरफक्समा साधारण विकास उपकरणहरूले पृष्ठ प्रतिक्रिया समय देखाउँदै यहाँ मद्दत गर्दछ।
हामी सबडोमेनहरू पनि स्क्यान गर्छौं। उदाहरण को लागी, त्यहाँ एक निश्चित अनलाइन स्टोर छ, abc.com, र यसको एक subdomain.abc.com छ। सम्भवतः, यो प्राधिकरणको साथ प्रशासक प्यानल हो, तर यदि तपाइँ यसमा लोड राख्नुभयो भने, यसले मुख्य स्रोतको लागि समस्याहरू सिर्जना गर्न सक्छ।
साइटमा api.abc.com सबडोमेन हुन सक्छ। सम्भवतः, यो मोबाइल अनुप्रयोगहरूको लागि एक स्रोत हो। एप एप स्टोर वा गुगल प्लेमा फेला पार्न सकिन्छ, विशेष पहुँच बिन्दु स्थापना गर्नुहोस्, एपीआई विच्छेद गर्नुहोस् र परीक्षण खाताहरू दर्ता गर्नुहोस्। समस्या यो हो कि मानिसहरू प्रायः सोच्छन् कि प्राधिकरण द्वारा सुरक्षित गरिएको कुनै पनि सेवा आक्रमणहरूको अस्वीकार गर्न प्रतिरक्षा छ। मानिन्छ, प्राधिकरण उत्तम क्याप्चा हो, तर यो होइन। 10-20 परीक्षण खाताहरू बनाउन सजिलो छ, तर तिनीहरूलाई सिर्जना गरेर, हामी जटिल र अस्पष्ट कार्यक्षमतामा पहुँच प्राप्त गर्छौं।
स्वाभाविक रूपमा, हामी इतिहास हेर्छौं, robots.txt र WebArchive, ViewDNS, र स्रोतको पुरानो संस्करणहरू खोज्छौं। कहिलेकाहीँ यस्तो हुन्छ कि विकासकर्ताहरूले mail2.yandex.net लाई रोल आउट गरेका छन्, तर पुरानो संस्करण, mail.yandex.net, रहन्छ। यो mail.yandex.net अब समर्थित छैन, विकास स्रोतहरू यसमा आवंटित गरिएको छैन, तर यसले डाटाबेस उपभोग गर्न जारी राख्छ। तदनुसार, पुरानो संस्करण प्रयोग गरेर, तपाइँ प्रभावकारी रूपमा ब्याकइन्डका स्रोतहरू र लेआउट पछाडि रहेको सबै चीजहरू प्रयोग गर्न सक्नुहुन्छ। निस्सन्देह, यो सधैं हुँदैन, तर हामी अझै पनि यो धेरै पटक सामना गर्छौं।
स्वाभाविक रूपमा, हामी सबै अनुरोध प्यारामिटरहरू र कुकी संरचना विश्लेषण गर्छौं। तपाईं, भन्न सक्नुहुन्छ, कुकी भित्र JSON एरेमा केही मान डम्प गर्न सक्नुहुन्छ, धेरै नेस्टिङ सिर्जना गर्नुहोस् र स्रोतलाई अव्यावहारिक रूपमा लामो समयसम्म काम गर्न सक्नुहुन्छ।

खोज लोड

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

खोजी भएन भने ?

यदि त्यहाँ कुनै खोज छैन भने, यसको मतलब यो होइन कि साइटले अन्य कमजोर इनपुट क्षेत्रहरू समावेश गर्दैन। यो क्षेत्र प्राधिकरण हुन सक्छ। आजकल, विकासकर्ताहरूले लगइन डाटाबेसलाई इन्द्रेणी तालिका आक्रमणबाट जोगाउन जटिल ह्यासहरू बनाउन मन पराउँछन्। यो राम्रो छ, तर त्यस्ता ह्यासहरूले धेरै CPU स्रोतहरू खपत गर्छन्। झूटा प्राधिकरणहरूको ठूलो प्रवाहले प्रोसेसर विफलता निम्त्याउँछ, र परिणाम स्वरूप, साइटले काम गर्न रोक्छ।
टिप्पणी र प्रतिक्रियाका लागि सबै प्रकारका फारमहरूको साइटमा उपस्थिति त्यहाँ धेरै ठूला पाठहरू पठाउने वा ठूलो बाढी सिर्जना गर्ने कारण हो। कहिलेकाहीँ साइटहरूले gzip ढाँचा सहित संलग्न फाइलहरू स्वीकार गर्छन्। यस अवस्थामा, हामी 1TB फाइल लिन्छौं, यसलाई gzip प्रयोग गरेर धेरै बाइट्स वा किलोबाइटहरूमा कम्प्रेस गर्छौं र साइटमा पठाउँछौं। त्यसपछि यो अनजिप गरिएको छ र एक धेरै रोचक प्रभाव प्राप्त छ।

बाकी API

म बाँकी एपीआई जस्ता लोकप्रिय सेवाहरूमा थोरै ध्यान दिन चाहन्छु। रेस्ट एपीआई सुरक्षित गर्नु नियमित वेबसाइट भन्दा धेरै गाह्रो छ। पासवर्ड ब्रुट फोर्स र अन्य गैरकानूनी गतिविधिहरू विरुद्ध सुरक्षाको मामूली विधिहरूले पनि बाँकी API को लागि काम गर्दैन।
बाँकी एपीआई तोड्न धेरै सजिलो छ किनभने यसले सीधा डाटाबेस पहुँच गर्दछ। एकै समयमा, यस्तो सेवाको विफलताले व्यवसायको लागि धेरै गम्भीर परिणामहरू समावेश गर्दछ। तथ्य यो हो कि बाँकी एपीआई सामान्यतया मुख्य वेबसाइटको लागि मात्र होइन, तर मोबाइल अनुप्रयोग र केही आन्तरिक व्यापार स्रोतहरूको लागि पनि प्रयोग गरिन्छ। र यदि यो सबै खस्यो भने, प्रभाव एक साधारण वेबसाइट विफलता को मामला मा भन्दा धेरै बलियो छ।

भारी सामग्री लोड गर्दै

यदि हामीलाई केहि साधारण एकल-पृष्ठ अनुप्रयोग, ल्यान्डिङ पृष्ठ, वा व्यापार कार्ड वेबसाइट परीक्षण गर्न प्रस्ताव गरिएको छ जसमा जटिल कार्यक्षमता छैन, हामी भारी सामग्री खोज्छौं। उदाहरणका लागि, सर्भरले पठाउने ठूला छविहरू, बाइनरी फाइलहरू, pdf कागजातहरू - हामी यी सबै डाउनलोड गर्ने प्रयास गर्छौं। त्यस्ता परीक्षणहरूले फाइल प्रणालीलाई राम्रोसँग लोड गर्छ र च्यानलहरू बन्द गर्छ, र त्यसैले प्रभावकारी हुन्छ। त्यो हो, तपाईले सर्भर डाउन नगर्नु भए पनि, कम गतिमा ठूलो फाइल डाउनलोड गर्दै, तपाईले केवल लक्षित सर्भरको च्यानललाई बन्द गर्नुहुनेछ र त्यसपछि सेवा अस्वीकार हुनेछ।
यस्तो परीक्षणको उदाहरणले देखाउँछ कि 30 RPS को गतिमा साइटले प्रतिक्रिया दिन बन्द गर्यो वा 500th सर्भर त्रुटिहरू उत्पादन गर्यो।

सर्भरहरू सेटअप गर्न नबिर्सनुहोस्। तपाईले प्रायः फेला पार्न सक्नुहुन्छ कि एक व्यक्तिले भर्चुअल मेसिन किन्यो, त्यहाँ Apache स्थापना गर्यो, सबै कुरा पूर्वनिर्धारित रूपमा कन्फिगर गर्यो, PHP अनुप्रयोग स्थापना गर्यो, र तल तपाईले परिणाम देख्न सक्नुहुन्छ।

यहाँ भार जरामा गयो र 10 आरपीएस मात्र भयो। हामीले 5 मिनेट पर्ख्यौं र सर्भर क्र्यास भयो। यो सत्य हो कि यो पूर्ण रूपमा थाहा छैन कि उनी किन खसे, तर त्यहाँ एक धारणा छ कि उनीसँग धेरै मेमोरी थियो र त्यसैले प्रतिक्रिया दिन रोकियो।

लहर आधारित

पछिल्लो एक वा दुई वर्षमा, लहर आक्रमणहरू धेरै लोकप्रिय भएका छन्। यो तथ्यको कारण हो कि धेरै संस्थाहरूले DDoS सुरक्षाको लागि हार्डवेयरको निश्चित टुक्राहरू खरीद गर्छन्, जसले आक्रमणलाई फिल्टर गर्न सुरु गर्न तथ्याङ्कहरू जम्मा गर्न निश्चित समय चाहिन्छ। अर्थात्, तिनीहरूले पहिलो 30-40 सेकेन्डमा आक्रमणलाई फिल्टर गर्दैनन्, किनभने तिनीहरूले डेटा जम्मा गर्छन् र सिक्छन्। तदनुसार, यी 30-40 सेकेन्डमा तपाईले साइटमा यति धेरै सुरू गर्न सक्नुहुन्छ कि सबै अनुरोधहरू खाली नभएसम्म संसाधन लामो समयसम्म रहन्छ।
तलको आक्रमणको अवस्थामा, त्यहाँ 10 मिनेटको अन्तराल थियो, त्यसपछि आक्रमणको नयाँ, परिमार्जित भाग आइपुग्यो।

त्यो हो, रक्षाले सिके, फिल्टर गर्न थाल्यो, तर आक्रमणको नयाँ, पूर्णतया फरक भाग आयो, र रक्षाले फेरि सिक्न थाल्यो। वास्तवमा, फिल्टरिङले काम गर्न रोक्छ, सुरक्षा अप्रभावी हुन्छ, र साइट अनुपलब्ध हुन्छ।
तरंग आक्रमणहरू शिखरमा धेरै उच्च मानहरूद्वारा विशेषता हुन्छन्, यो L7 को मामलामा प्रति सेकेन्ड एक लाख वा एक मिलियन अनुरोधहरू पुग्न सक्छ। यदि हामी L3 र 4 को बारेमा कुरा गर्छौं भने, त्यहाँ सयौं गिगाबिट ट्राफिक हुन सक्छ, वा, तदनुसार, सयौं mpps, यदि तपाइँ प्याकेटहरूमा गणना गर्नुहुन्छ।
त्यस्ता आक्रमणहरूको समस्या सिंक्रोनाइजेसन हो। आक्रमणहरू बोटनेटबाट आउँछन् र धेरै ठूलो एक-समय स्पाइक सिर्जना गर्न उच्च स्तरको सिङ्क्रोनाइजेसन चाहिन्छ। र यो समन्वय सधैं काम गर्दैन: कहिलेकाँही आउटपुट एक प्रकारको प्याराबोलिक शिखर हो, जुन बरु दयनीय देखिन्छ।

HTTP एक्लै होइन

L7 मा HTTP को अतिरिक्त, हामी अन्य प्रोटोकलहरू शोषण गर्न चाहन्छौं। एक नियमको रूपमा, एक नियमित वेबसाइट, विशेष गरी नियमित होस्टिंग, मेल प्रोटोकलहरू र MySQL बाहिर छ। मेल प्रोटोकलहरू डाटाबेसहरू भन्दा कम लोडको विषय हुन्, तर तिनीहरू पनि धेरै कुशलतापूर्वक लोड गर्न सकिन्छ र सर्भरमा ओभरलोड गरिएको CPU सँग समाप्त हुन्छ।
हामीले 2016 SSH भेद्यताको साथ वास्तविक रूपमा सफलता पायौं। अब यो जोखिम लगभग सबैको लागि तय गरिएको छ, तर यसको मतलब यो होइन कि लोड SSH मा पेश गर्न सकिँदैन। सक्छ। त्यहाँ केवल प्राधिकरणको ठूलो भार छ, SSH ले सर्भरमा लगभग सम्पूर्ण CPU खान्छ, र त्यसपछि वेबसाइट प्रति सेकेन्ड एक वा दुई अनुरोधबाट पतन हुन्छ। तदनुसार, लगहरूमा आधारित यी एक वा दुई अनुरोधहरू वैध लोडबाट छुट्याउन सकिँदैन।
हामीले सर्भरमा खोल्ने धेरै जडानहरू पनि सान्दर्भिक रहन्छन्। पहिले, Apache यसको लागि दोषी थियो, अब nginx वास्तवमा यसको लागि दोषी छ, किनकि यो प्राय: पूर्वनिर्धारित रूपमा कन्फिगर गरिएको छ। nginx ले खुला राख्न सक्ने जडानहरूको संख्या सीमित छ, त्यसैले हामी जडानहरूको यो संख्या खोल्छौं, nginx ले अब नयाँ जडान स्वीकार गर्दैन, र परिणाम स्वरूप साइटले काम गर्दैन।
हाम्रो परीक्षण क्लस्टरमा SSL ह्यान्डशेकलाई आक्रमण गर्न पर्याप्त CPU छ। सिद्धान्तमा, अभ्यासले देखाएको रूपमा, बोटनेटहरू कहिलेकाहीं यो गर्न मन पराउँछन्। एकातिर, यो स्पष्ट छ कि तपाईं SSL बिना गर्न सक्नुहुन्न, किनभने Google परिणामहरू, श्रेणीकरण, सुरक्षा। अर्कोतर्फ, SSL मा दुर्भाग्यवश CPU मुद्दा छ।

L3 र 4

जब हामी L3 र 4 स्तरहरूमा आक्रमणको बारेमा कुरा गर्छौं, हामी सामान्यतया लिङ्क स्तरमा आक्रमणको बारेमा कुरा गर्दैछौं। SYN-बाढी आक्रमण नभएसम्म, यस्तो भार लगभग सधैं वैध एकबाट छुट्याउन सकिन्छ। सुरक्षा उपकरणहरूको लागि SYN-बाढी आक्रमणहरूको समस्या तिनीहरूको ठूलो मात्रा हो। अधिकतम L3 र 4 मान 1,5-2 Tbit/s थियो। Oracle र Google लगायत ठूला कम्पनीहरूको लागि पनि यस प्रकारको ट्राफिक प्रक्रिया गर्न धेरै गाह्रो छ।
SYN र SYN-ACK प्याकेटहरू हुन् जुन जडान स्थापना गर्दा प्रयोग गरिन्छ। तसर्थ, SYN-बाढीलाई वैध भारबाट छुट्याउन गाह्रो छ: यो जडान स्थापना गर्न आएको SYN हो वा बाढीको अंश हो भन्ने स्पष्ट छैन।

UDP - बाढी

सामान्यतया, आक्रमणकारीहरूसँग हामीसँग क्षमताहरू हुँदैनन्, त्यसैले प्रवर्धनलाई आक्रमणहरू व्यवस्थित गर्न प्रयोग गर्न सकिन्छ। त्यो हो, आक्रमणकारीले इन्टरनेट स्क्यान गर्छ र या त कमजोर वा गलत रूपमा कन्फिगर गरिएको सर्भरहरू फेला पार्छ जुन, उदाहरणका लागि, एउटा SYN प्याकेटको प्रतिक्रियामा, तीन SYN-ACKs सँग प्रतिक्रिया दिन्छ। लक्षित सर्भरको ठेगानाबाट स्रोत ठेगाना स्पूफ गरेर, एकल प्याकेटको साथ तीन पटक शक्ति बढाउन र पीडितमा ट्राफिक रिडिरेक्ट गर्न सम्भव छ।

एम्प्लीफिकेशनको साथ समस्या यो हो कि तिनीहरू पत्ता लगाउन गाह्रो छ। भर्खरका उदाहरणहरूमा कमजोर मेम्क्याचको सनसनीपूर्ण केस समावेश छ। साथै, अब त्यहाँ धेरै IoT यन्त्रहरू, IP क्यामेराहरू छन्, जुन प्राय: पूर्वनिर्धारित रूपमा कन्फिगर गरिएको छ, र पूर्वनिर्धारित रूपमा तिनीहरू गलत रूपमा कन्फिगर गरिएका छन्, त्यसैले आक्रमणकारीहरूले प्राय: त्यस्ता उपकरणहरू मार्फत आक्रमण गर्छन्।

कठिन SYN-बाढी

SYN-बाढी सम्भवतः विकासकर्ताको दृष्टिकोणबाट सबैभन्दा रोचक प्रकारको आक्रमण हो। समस्या यो हो कि प्रणाली प्रशासकहरूले प्राय: सुरक्षाको लागि IP अवरुद्ध प्रयोग गर्छन्। यसबाहेक, आईपी ब्लकिङले स्क्रिप्टहरू प्रयोग गरेर कार्य गर्ने प्रणाली प्रशासकहरूलाई मात्र असर गर्दैन, तर दुर्भाग्यवश, धेरै पैसाको लागि खरिद गरिएका केही सुरक्षा प्रणालीहरूलाई पनि असर गर्छ।
यो विधि विपत्तिमा परिणत हुन सक्छ, किनकि यदि आक्रमणकारीहरूले IP ठेगानाहरू प्रतिस्थापन गरे भने, कम्पनीले आफ्नै सबनेटलाई रोक्नेछ। जब फायरवालले आफ्नै क्लस्टरलाई रोक्छ, आउटपुट बाह्य अन्तरक्रियाहरू असफल हुनेछ र स्रोत असफल हुनेछ।
यसबाहेक, तपाईंको आफ्नै नेटवर्क ब्लक गर्न गाह्रो छैन। यदि ग्राहकको कार्यालयमा Wi-Fi नेटवर्क छ, वा यदि विभिन्न अनुगमन प्रणालीहरू प्रयोग गरेर स्रोतहरूको कार्यसम्पादन मापन गरिएको छ भने, हामी यो निगरानी प्रणाली वा ग्राहकको कार्यालयको Wi-Fi को IP ठेगाना लिन्छौं र यसलाई स्रोतको रूपमा प्रयोग गर्छौं। अन्तमा, स्रोत उपलब्ध देखिन्छ, तर लक्षित IP ठेगानाहरू अवरुद्ध छन्। यसरी, हाईलोड सम्मेलनको Wi-Fi नेटवर्क, जहाँ कम्पनीको नयाँ उत्पादन प्रस्तुत भइरहेको छ, अवरुद्ध हुन सक्छ, र यसले निश्चित व्यापार र आर्थिक लागतहरू समावेश गर्दछ।
परीक्षणको क्रममा, हामी कुनै पनि बाह्य स्रोतहरूसँग memcached मार्फत एम्प्लीफिकेशन प्रयोग गर्न सक्दैनौं, किनभने अनुमति दिइएको IP ठेगानाहरूमा मात्र ट्राफिक पठाउने सम्झौताहरू छन्। तदनुसार, हामी SYN र SYN-ACK मार्फत एम्प्लीफिकेशन प्रयोग गर्छौं, जब प्रणालीले दुई वा तीन SYN-ACK सँग एउटा SYN पठाउन प्रतिक्रिया दिन्छ, र आउटपुटमा आक्रमणलाई दुई वा तीन गुणाले गुणन गरिन्छ।

उपकरणहरू

L7 कार्यभारको लागि हामीले प्रयोग गर्ने मुख्य उपकरणहरू मध्ये एक Yandex-tank हो। विशेष गरी, प्रेतलाई बन्दुकको रूपमा प्रयोग गरिन्छ, साथै त्यहाँ कारतूसहरू उत्पन्न गर्न र परिणामहरूको विश्लेषणको लागि धेरै लिपिहरू छन्।
Tcpdump नेटवर्क ट्राफिक विश्लेषण गर्न प्रयोग गरिन्छ, र Nmap सर्भर विश्लेषण गर्न प्रयोग गरिन्छ। L3 र 4 स्तरमा लोड सिर्जना गर्न, OpenSSL र DPDK पुस्तकालयको साथ हाम्रो आफ्नै जादू प्रयोग गरिन्छ। DPDK Intel बाट एउटा पुस्तकालय हो जसले तपाईंलाई लिनक्स स्ट्याकलाई बाइपास गरेर नेटवर्क इन्टरफेससँग काम गर्न अनुमति दिन्छ, जसले गर्दा दक्षता बढ्छ। स्वाभाविक रूपमा, हामी DPDK L3 र 4 स्तरमा मात्र होइन, L7 स्तरमा पनि प्रयोग गर्छौं, किनभने यसले हामीलाई एक मेसिनबाट प्रति सेकेन्ड धेरै मिलियन अनुरोधहरूको दायरा भित्र धेरै उच्च भार प्रवाह सिर्जना गर्न अनुमति दिन्छ।
हामी केहि ट्राफिक जनरेटरहरू र विशेष उपकरणहरू पनि प्रयोग गर्छौं जुन हामीले विशेष परीक्षणहरूको लागि लेख्छौं। यदि हामीले SSH अन्तर्गतको कमजोरीलाई सम्झन्छौं भने, माथिको सेटको शोषण गर्न सकिँदैन। यदि हामीले मेल प्रोटोकलमा आक्रमण गर्छौं भने, हामी मेल उपयोगिताहरू लिन्छौं वा तिनीहरूमा लिपिहरू लेख्छौं।

निष्कर्ष

निष्कर्षको रूपमा म भन्न चाहन्छु:

• क्लासिक लोड परीक्षणको अतिरिक्त, यो तनाव परीक्षण सञ्चालन गर्न आवश्यक छ। हामीसँग एउटा वास्तविक उदाहरण छ जहाँ साझेदारको उप-ठेकेदारले मात्र लोड परीक्षण गरेको छ। यसले स्रोतले सामान्य भार सहन सक्ने देखाएको छ। तर त्यसपछि एक असामान्य भार देखा पर्‍यो, साइट आगन्तुकहरूले स्रोतलाई थोरै फरक रूपमा प्रयोग गर्न थाले, र फलस्वरूप उप-ठेकेदार ढले। तसर्थ, यदि तपाइँ पहिले नै DDoS आक्रमणहरूबाट सुरक्षित हुनुहुन्छ भने पनि कमजोरीहरू खोज्न लायक छ।
• यो अन्यबाट प्रणाली को केहि भाग अलग गर्न आवश्यक छ। यदि तपाइँसँग खोजी छ भने, तपाइँ यसलाई अलग मेसिनहरूमा सार्न आवश्यक छ, त्यो हो, डकरमा पनि होइन। किनभने यदि खोज वा प्राधिकरण असफल भयो भने, कम्तिमा केहि काम जारी रहनेछ। अनलाइन स्टोरको मामलामा, प्रयोगकर्ताहरूले क्याटलगमा उत्पादनहरू फेला पार्न, एग्रीगेटरबाट जानुहोस्, तिनीहरू पहिले नै अधिकृत छन् भने किन्नुहोस्, वा OAuth2 मार्फत अधिकृत हुनेछन्।
• सबै प्रकारका क्लाउड सेवाहरूलाई बेवास्ता नगर्नुहोस्।
• CDN नेटवर्क ढिलाइ अनुकूलन गर्न मात्र होइन, तर च्यानल थकान र स्थिर ट्राफिकमा बाढीबाट हुने आक्रमणहरू विरुद्ध सुरक्षाको माध्यमको रूपमा पनि प्रयोग गर्नुहोस्।
• यो विशेष सुरक्षा सेवाहरू प्रयोग गर्न आवश्यक छ। तपाईं च्यानल स्तरमा L3 र 4 आक्रमणहरूबाट आफूलाई बचाउन सक्नुहुन्न, किनभने तपाईंसँग सम्भवतः पर्याप्त च्यानल छैन। तपाईं L7 आक्रमणहरूबाट लड्न पनि सम्भव छैन, किनकि तिनीहरू धेरै ठूला हुन सक्छन्। साथै, साना आक्रमणहरूको खोजी अझै पनि विशेष सेवाहरू, विशेष एल्गोरिदमहरूको विशेषाधिकार हो।
• नियमित रूपमा अपडेट गर्नुहोस्। यो कर्नेलमा मात्र लागू हुँदैन, तर SSH डेमनमा पनि लागू हुन्छ, विशेष गरी यदि तपाईंले तिनीहरूलाई बाहिर खोल्नु भएको छ। सिद्धान्तमा, सबै कुरा अद्यावधिक गर्न आवश्यक छ, किनभने तपाईं आफैंमा केहि कमजोरीहरू ट्र्याक गर्न सक्षम हुन सम्भव छैन।

स्रोत: www.habr.com