🌫️ ⚠️ 😮 लिनक्स के साथ vds / समर्पित सर्वर के मालिकों के लिए DDoS हमलों से निपटने के उपलब्ध तरीके 🐺 🈸 ⚛️

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

इस लेख के लिए लक्षित दर्शक प्रोग्रामर हैं जिनके पास अपने निपटान में VDS या समर्पित है।

नग्नेक्स का एक गुच्छा - अपाचे - फास्टसीगी / डब्ल्यूएसजीआई। बाधाओं

एक वेब एप्लिकेशन के एक विशिष्ट संगठन में 3 स्तर होते हैं: एक रिवर्स प्रॉक्सी सर्वर (उदाहरण के लिए नगनेक्स), अपाचे (वेब सर्वर) और किसी तरह का फास्टसीजी / wsgi / ... एप्लीकेशन। व्यवहार में, ऐसे कोई अपाचे या mod_php / mod_python का उपयोग करते समय, जब कोई समर्पित एप्लिकेशन (यह वेब सर्वर में बनाया गया है) का उपयोग न करने पर पतित मामले होते हैं, लेकिन योजना का सार नहीं बदलता है, केवल इसमें स्तरों की संख्या में परिवर्तन होता है।

एक Fcgi सर्वर कई दर्जन प्रक्रियाओं को चला सकता है जो समानांतर में आने वाले अनुरोधों को संसाधित करता है। यह मान केवल एक निश्चित सीमा तक बढ़ाया जा सकता है, जबकि प्रक्रियाओं को मेमोरी में संग्रहीत किया जाता है। एक और वृद्धि से अदला-बदली होगी। DDoS हमले या उच्च यातायात के मामले में, जब सभी मौजूदा fcgi प्रक्रियाएं पहले से ही आने वाले अनुरोधों को संसाधित करने में व्यस्त होती हैं, Apache कतारें नए आने वाले अनुरोधों को तब तक लागू करती हैं जब तक या तो fcgi प्रक्रियाओं में से एक को मुक्त नहीं कर दिया जाता है या कतार में एक टाइमआउट होता है (इस मामले में) त्रुटि 503 होती है)।

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

नग्नेक्स पर फ़िल्टरिंग ट्रैफ़िक। पार्सिंग नेग्नेक्स लॉग्स

हमारी प्रस्तावित तकनीक एक विशिष्ट मूल्य (उदाहरण के लिए, 1500 प्रति मिनट, साइट के कितने हिट वर्तमान सर्वर क्षमता पर निर्भर कर सकती है) के आधार पर साइट के लिए अनुरोधों की कुल संख्या को सीमित करने के लिए उबालती है। वह सब कुछ जो इस मूल्य से अधिक होगा, हम शुरू में nginx (limit_req_zone $ host ज़ोन = hostreqlimit: 20m rate = 1500r / m;) के साथ फ़िल्टर करेंगे।
फिर हम nginx लॉग में देखेंगे और वहां पर उन IP पतों की गणना करेंगे, जो एक निश्चित अवधि (उदाहरण के लिए, 5 मिनट में 100 से अधिक बार) के लिए निश्चित संख्या से अधिक बार फ़िल्टर किए गए थे और फ़ायरवॉल के माध्यम से इन IP पतों तक पहुंच से इनकार करते हैं।

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

हमारी पद्धति का उपयोग करने के लिए, nginx कॉन्फ़िगरेशन फ़ाइल, जब nginx अपाचे के लिए एक रिवर्स प्रॉक्सी के रूप में काम करता है, को इस तरह दिखना चाहिए:

http { limit_req_zone $host zone=hostreqlimit:20m rate=1500r/m; ... server { listen 1.2.3.4; server_name domain.ru www.domain.ru; limit_req zone=hostreqlimit burst=2500 nodelay; location / { proxy_pass http://127.0.0.1:80; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; } } }

यह कॉन्फिगर यह भी बताता है कि अपाचे लूपबैक इंटरफेस पर 127.0.0.1:80 पर सुन रहा है, और हमारे बाहरी आईपी पते (1.2.3.4) पर 80 वें पोर्ट और 12780.0.1 पर पोर्ट 8080 पर nginx।

निग्नेक्स द्वारा फ़िल्टर किए गए हिट्स को नग्नेक्स की त्रुटि में इस तरह की प्रविष्टि के बाद किया जाएगा।

 2012/01/30 17:11:48 [error] 16862#0: *247484 limiting requests, excess: 2500.200 by zone "hostreqlimit", client: 92.255.185.237, server: domain.ru, request: "GET / HTTP/1.1", host: "domain.ru", referrer: "http://www.yahoo.com/"

Error.log से सभी अवरुद्ध आईपी पतों की एक सूची प्राप्त करने के लिए, हम निम्नलिखित कर सकते हैं:

 cat error.log | awk '/hostreqlimit/ { gsub(", ", " "); print $14}' | sort | uniq -c | sort -n

लेकिन हमें याद है कि इस मामले में हम हर किसी को ब्लॉक करते हैं, जिसने हिट काउंटर के बाद प्रति मिनट 1,500 बार काउंट किया, इसलिए सभी ब्लॉक किए गए बॉट नहीं हैं। लेकिन बॉट्स को प्रतिष्ठित किया जा सकता है यदि हम तालों की संख्या पर एक सशर्त रेखा खींचते हैं। आमतौर पर, 5-15 मिनट में कई बार गुण का चयन किया जाता है। उदाहरण के लिए, हम हर 5 मिनट में बॉट्स की सूची की भरपाई करते हैं और विचार करते हैं कि सभी जो नगनेक्स को 200 से अधिक बार अवरुद्ध करते हैं वे बॉट हैं।

अब हम दो समस्याओं का सामना करते हैं:

लॉग से "अंतिम 5 मिनट" की अवधि कैसे चुनें?
केवल उन लोगों को कैसे सॉर्ट करें जिन्हें एन बार से अधिक अवरुद्ध किया गया है?

पहली समस्या पूंछ -c + OFFSET का उपयोग करके हल की गई है। यह विचार इस तथ्य पर उबलता है कि त्रुटि के कारण। समस्या के बाद, हम बाइट्स में इसके वर्तमान आकार को सहायक फ़ाइल (स्टेट -c '% s' error.log> ऑफसेट) में लिखते हैं, और अगले विश्लेषण के दौरान हम error.log को पिछली स्थिति में रिवाइंड करते हैं (पूंछ -c + $ (बिल्ली ऑफसेट))। इस प्रकार, हर 5 मिनट में लॉग का विश्लेषण शुरू करते हुए, हम केवल उस लॉग के भाग को देखेंगे जो अंतिम 5 मिनट को संदर्भित करता है।

दूसरी प्रॉब्लम एक awk script का इस्तेमाल करके हल की जाती है। नतीजतन, हमें प्राप्त होता है (THRESHOLD तालों की संख्या पर समान सीमा है, जिसके बाद संबंधित आईपी पते को हमलावर बॉट से संबंधित माना जाता है):

 touch offset; (test $(stat -c '%s' error.log) -lt $(cat offset) 2>/dev/null && echo 0 > offset) || echo 0 > offset; \ tail -c +$(cat offset) error.log | awk -v THRESHOLD=200 '/hostreqlimit/ { gsub(", ", " "); a[$14]++; } \ END { for (i in a) if (a[i]>THRESHOLD) printf "%s\n", i; }' ; stat -c '%s' error.log > offset

यह समझा जाता है कि कमांड के इस सेट को उस डायरेक्टरी में निष्पादित किया जाता है, जहाँ nginx से error.log निहित है, अर्थात् एक नियम के रूप में यह / var / log / nginx है। हम परिणामी सूची को अवरुद्ध करने के लिए फ़ायरवॉल को भेज सकते हैं (उस पर अधिक)।

प्रतिबंध के लिए नेटवर्क की सूची बनाना कितना आसान है

एक अन्य कार्य जिसका हम DDoS के साथ सामना करते हैं, हमारी साइट पर उन लोगों तक पहुँच को सीमित करना है जो संभावित आगंतुक नहीं हैं, क्योंकि बॉटनेट में दसियों हज़ार कंप्यूटर हो सकते हैं और अक्सर हर बॉट को पकड़ने की तुलना में पूरे सबनेट द्वारा अतिरिक्त IP पतों को काटना आसान होता है। अलग से।

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

यदि साइट में एक स्थापित समुदाय (कोर) है, तो हम पिछले 3-4 हफ्तों के लिए वेब सर्वर लॉग से नियमित आगंतुकों के आईपी पते की एक सूची का चयन कर सकते हैं। हालांकि नए आगंतुक हमले के दौरान साइट पर नहीं जा पाएंगे, पुराने सक्रिय उपयोगकर्ता संभवतः किसी भी हमले को नोटिस नहीं करेंगे। इसके अलावा, बॉट नियमित आगंतुकों के बीच होने की संभावना नहीं है, इसलिए यह विधि, सिद्धांत रूप में, कुछ समय के लिए हमले को रोक सकती है।

यदि साइट स्थानीय महत्व की है, तो आप स्थानीय प्रदाताओं और खोज इंजन नेटवर्क (Yandex) के नेटवर्क को छोड़कर फ़ायरवॉल पर सभी को प्रतिबंधित कर सकते हैं।

Iptables का परिचय, एक साधारण फ़ायरवॉल का एक उदाहरण है

लिनक्स पर, फ़ायरवॉल iptables पर चलता है। वास्तव में, iptables का सार यह सुनिश्चित करना है कि यातायात के प्रत्येक पैकेट को बाह्य रूप से प्राप्त किया जाए या सर्वर से भेजा जाए, नियमों का एक विशिष्ट सेट लागू किया जाता है जो इस पैकेट के भाग्य को प्रभावित कर सकता है। सबसे सरल मामले में, नियम केवल यह कहते हैं कि पैकेट को या तो प्राप्त किया जाना चाहिए (ACCEPT) या ड्रॉप (DROP)। नियमों को जंजीरों में बांटा गया है। उदाहरण के लिए, इंटरनेट से सर्वर द्वारा प्राप्त पैकेट INPUT श्रृंखला में आते हैं, जहाँ श्रृंखला के नियमों की शुरुआत से प्रत्येक पैकेट के लिए यह जाँच की जाती है कि क्या पैकेट नियम में वर्णित शर्तों के लिए उपयुक्त है और यदि यह मेल खाता है, तो यह नियम पैकेट पर लागू होता है, और यदि नहीं, तो पैकेट अगले नियम के लिए पारित कर दिया। यदि पैकेज के लिए कोई भी नियम लागू नहीं किया गया है, तो डिफ़ॉल्ट नीति पैकेज पर लागू होती है।

एक सरल उदाहरण के रूप में, हम फ़ायरवॉल नियम लिखेंगे जो केवल सर्वर से हमारे कार्यालय (आईपी पते 1.2.3.4 से) के लिए ssh कनेक्शन की अनुमति देते हैं, और बाकी सभी के लिए ssh तक पहुँच को रोकते हैं:

 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 1.2.3.4/32 -m comment --comment "our office" -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j DROP COMMIT

इन पंक्तियों को एक टेक्स्ट फ़ाइल में लिखा जा सकता है और इसका उपयोग करके फ़ायरवॉल पर डाउनलोड किया जा सकता है: iptables-restore <firewall.txt, और फ़ायरवॉल की वर्तमान स्थिति को फ़ाइल में सहेजें: iptables-save> firewall.txt।

ये नियम निम्नानुसार काम करते हैं। पहली पंक्ति - हम सभी कनेक्शनों के लिए सभी ट्रैफ़िक को अनुमति देते हैं जो पहले से ही खुले हैं (हैंडशेक पास)। दूसरी पंक्ति - हम आईपी पते 1.2.3.4 से किसी भी यातायात की अनुमति देते हैं और एक टिप्पणी के साथ चिह्नित करते हैं कि यह हमारा कार्यालय है। वास्तव में, केवल पैकेट जो एक कनेक्शन स्थापित करते हैं, यहां पहुंचते हैं, अर्थात, सिंक और एके प्रकार के पैकेट, अन्य सभी पैकेट केवल पहली पंक्ति से गुजरते हैं। तीसरी पंक्ति - हम सभी को टीसीपी के माध्यम से पोर्ट 22 से कनेक्ट करने से रोकते हैं। हमारे कार्यालय को छोड़कर सभी से ssh के माध्यम से (syn, ack) कनेक्ट करने का प्रयास यहां आता है।

दिलचस्प है, पहली पंक्ति को सुरक्षित रूप से हटाया जा सकता है। ऐसी रेखा होने का लाभ यह है कि फ़ायरवॉल में पहले से ही खुले कनेक्शनों के लिए, केवल एक नियम काम करेगा, और पहले से ही खुले कनेक्शनों के भीतर पैकेट हम प्राप्त होने वाले पैकेटों के विशाल बहुमत हैं, अर्थात्, शुरुआत में ऐसी रेखा वाला फ़ायरवॉल व्यावहारिक रूप से किसी भी अतिरिक्त देरी का परिचय नहीं देगा। सर्वर के नेटवर्क स्टैक में। माइनस - यह लाइन कॉनट्रैक मॉड्यूल को सक्रिय करती है, जो सभी स्थापित कनेक्शनों की तालिका की एक प्रति को स्मृति में रखती है। क्या अधिक महंगा है - कनेक्शन तालिका की एक प्रति या प्रत्येक पैकेट के लिए कई फ़ायरवॉल नियमों को संसाधित करने की आवश्यकता है? यह प्रत्येक सर्वर की एक व्यक्तिगत बारीकियों है। यदि फ़ायरवॉल में केवल कुछ नियम हैं, तो हमारी राय में इसके नियमों को बनाने के लिए यह अधिक सही है ताकि कनवर्टर मॉड्यूल सक्रिय न हो।

Iptables में, आप अतिरिक्त उपयोगकर्ता-परिभाषित चेन बना सकते हैं। एक अर्थ में, यह प्रोग्रामिंग भाषाओं में कॉलिंग फ़ंक्शन का एक एनालॉग जैसा दिखता है। नई श्रृंखला बनाना सरल है: iptables -N chain_name। इस तरह से बनाई गई श्रृंखलाओं का उपयोग फ़ायरवॉल को विभिन्न तार्किक ब्लॉकों में विभाजित करने के लिए किया जाता है।

डीडीओएस का मुकाबला करने के लिए अनुशंसित फ़ायरवॉल संरचना

डीडीओएस का मुकाबला करने के लिए हम जो संरचना सुझाते हैं, उसमें निम्नलिखित तार्किक ब्लॉक शामिल हैं:

हम पहले से ही स्थापित कनेक्शन पर यातायात की अनुमति देते हैं।
हम "हमारे" आईपी-पतों के लिए अनुमतियाँ पंजीकृत करते हैं।
श्वेतसूची तालिका एक अपवाद है।
DDoS टेबल वह बॉट है जिसकी हमने पहचान की थी।
फ्रेंड्स टेबल रनेट नेटवर्क है, जिसे हम एक्सेस करने की अनुमति देते हैं यदि पैकेज इस स्तर तक पहुंच गया है।
बाकी सभी लोग -j DROP हैं।

Iptables के संदर्भ में, यह इस तरह दिखता है:

 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :ddos - [0:0] :friends - [0:0] :whitelist - [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -s 1.2.3.4/32 -m comment --comment "our office" -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j DROP -A INPUT -j whitelist -A INPUT -j ddos -A INPUT -j friends -A INPUT -j DROP -A whitelist -s 222.222.222.222 -j ACCEPT -A whitelist -s 111.111.111.111 -j ACCEPT -A ddos -s 4.3.2.0/24 -j DROP -A friends -s 91.201.52.0/22 -j ACCEPT COMMIT

फिर से, दूसरी पंक्ति होने की उपयुक्तता संदिग्ध है और फ़ायरवॉल के पूर्ण आकार के आधार पर, यह अपने काम को गति दे सकता है और इसे धीमा कर सकता है।

मित्र तालिका भरें:

 for net in $(curl -s http://noc.masterhost.ru/allrunet/runet); do iptables -A friends -s $net -j ACCEPT; done

इस तरह के फ़ायरवॉल के साथ समस्या इसकी राक्षसीता है: रनेट के मामले में दोस्तों की तालिका में लगभग 5000 नियम होंगे। अधिक या कम औसत DDoS के मामले में, DDoS तालिका में अन्य 1-2 हजार रिकॉर्ड होंगे। कुल फ़ायरवॉल में 5-7 हज़ार लाइनें शामिल होंगी। इसी समय, विदेशी प्रेषकों से आने वाले सभी पैकेट, जिन्हें केवल त्याग दिया जाना चाहिए, वास्तव में सभी 5-7 हजार नियमों से गुजरेंगे जब तक कि वे अंतिम एक तक नहीं पहुंचते: -एक INPUT -j DROP। अपने आप से, इस तरह के एक फ़ायरवॉल संसाधनों की एक बड़ी राशि खा जाएगा।

Ipset - राक्षसी फ़ायरवॉल के लिए समाधान

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

 ipset -N ddos iphash

यहां, अंतिम पैरामीटर तालिका के प्रकार को इंगित करता है: नेटवर्क की सूची के लिए nethash सेट किया गया है, iphash आईपी पते के लिए है। अलग-अलग तालिका विकल्प हैं, आदमी ipset में विवरण। तदनुसार, श्वेतसूची और मित्र nethash टेबल हैं, और DDoS iphash है।
फ़ायरवॉल में बनाई गई ipset तालिका का उपयोग करने के लिए, एक नियम (फ़ायरवॉल लाइनें) पर्याप्त हैं, उदाहरण के लिए:

 -A INPUT -m set --match-set whitelist src -j ACCEPT -A INPUT -m set --match-set ddos src -j DROP

आप इस तरह से नई बनाई गई तालिका में कुछ आईपी-पता जोड़ सकते हैं:

 ipset -A ddos 1.2.3.4

इस प्रकार, ipset का उपयोग करते समय हमारा पूरा फ़ायरवॉल नीचे आता है:

 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -s 1.2.3.4/32 -m comment --comment "our office" -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j DROP -A INPUT -m set --match-set whitelist src -j ACCEPT -A INPUT -m set --match-set ddos src -j DROP -A INPUT -m set --match-set friends src -j ACCEPT -A INPUT -j DROP COMMIT

हम सेट दोस्तों में टाइप करते हैं:

 for net in $(curl -s http://noc.masterhost.ru/allrunet/runet); do ipset -A friends $net; done

हम पहले दिखाए गए कमांड से सेट ddos में भरते हैं:

 touch offset; (test $(stat -c '%s' error.log) -lt $(cat offset) 2>/dev/null && echo 0 > offset) || echo 0 > offset; \ for ip in $(tail -c +$(cat offset) error.log | awk -v THRESHOLD=300 \ '/hostreqlimit/ { gsub(", ", " "); a[$14]++; } END { for (i in a) if (a[i]>THRESHOLD) printf "%s\n", i; }' ; \ stat -c '%s' error.log > offset); do ipset -A ddos $ip; done

हम TARPIT मॉड्यूल का उपयोग करते हैं

तिरपिट नामक iptables मॉड्यूल एक तथाकथित "जाल" है। टारपिट का सिद्धांत यह है: ग्राहक हैंडशेक (टीसीपी कनेक्शन की शुरुआत) स्थापित करने की कोशिश करने के लिए एक सिंट-पैकेट भेजता है। तारपिट एक सिन / एक पैकेट के साथ प्रतिक्रिया करता है, जिसे वह तुरंत भूल जाता है। हालाँकि, वास्तव में कोई कनेक्शन नहीं खोला गया है और कोई संसाधन आवंटित नहीं किए गए हैं। जब अंतिम ACK पैकेट बॉट से आता है, तो tarpit मॉड्यूल एक पैकेट वापस भेजता है जो सर्वर पर डेटा को शून्य पर भेजने के लिए विंडो का आकार सेट करता है। उसके बाद, टारपीट द्वारा बॉट की ओर से इस कनेक्शन को बंद करने के किसी भी प्रयास को अनदेखा किया जाता है। क्लाइंट (बॉट) का मानना है कि कनेक्शन खुला है, लेकिन "अटक गया" (विंडो का आकार 0 बाइट्स है) और इस कनेक्शन को बंद करने की कोशिश करता है, लेकिन यह कुछ भी नहीं कर सकता है जब तक कि टाइमआउट समाप्त नहीं हो जाता है, और सेटिंग्स के आधार पर टाइमआउट 12-24 बजे तक होता है। मिनट।

आप एक फ़ायरवॉल में टारपीट का उपयोग इस प्रकार कर सकते हैं:

 -A INPUT -p tcp -m set --match-set ddos src -j TARPIT --tarpit -A INPUT -m set --match-set ddos src -j DROP

Xtables-addons बनाएँ

दुर्भाग्य से, ipset और tarpit मॉड्यूल आधुनिक वितरण के मानक सेट से गायब हैं। उन्हें अतिरिक्त रूप से स्थापित करने की आवश्यकता है। कमोबेश हाल ही में डेबियन और उबंटू वितरण के लिए, यह बस किया जाता है:

 apt-get install module-assistant xtables-addons-source ma ai xtables-addons

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

कोर ट्यूनिंग

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

जिन कर्नेल मापदंडों पर चर्चा की गई है, उन्हें sysctl कमांड का उपयोग करके ठीक किया गया है:

 sysctl [-w] option

-W विकल्प का मतलब है कि आप नए मान को कुछ पैरामीटर में लिखना चाहते हैं, और इसकी अनुपस्थिति का मतलब है कि आप इस पैरामीटर के वर्तमान मूल्य को पढ़ना चाहते हैं। निम्नलिखित मापदंडों को ठीक करने की सिफारिश की गई है:

 net.ipv4.tcp_syncookies=1 net.ipv4.ip_local_port_range = 1024 65535 net.core.netdev_max_backlog = 30000 net.ipv4.tcp_max_syn_backlog = 4096 net.core.somaxconn = 4096 net.core.rmem_default = 124928 net.core.rmem_max = 124928 net.core.wmem_max = 124928

Net.ipv4.tcp_syncookies पैरामीटर सिंकुकी तंत्र को सक्षम करने के लिए जिम्मेदार है; net.core.netdev_max_backlog प्रसंस्करण कतार में पैकेट की अधिकतम संख्या को निर्धारित करता है यदि इंटरफ़ेस प्राप्त करता है तो कर्नेल की तुलना में तेज़ी से पैकेट उन्हें संसाधित कर सकता है।
net.ipv4.tcp_max_syn_backlog याद रखने वाले कनेक्शन अनुरोधों की अधिकतम संख्या को परिभाषित करता है, जिसके लिए कनेक्टिंग क्लाइंट से कोई पुष्टि प्राप्त नहीं हुई है।
net.core.somaxconn एक कनेक्शन की प्रतीक्षा में खुली सॉकेट्स की अधिकतम संख्या है।
अंतिम पंक्तियाँ tcp कनेक्शन के लिए विभिन्न बफर हैं।

हमें उम्मीद है कि यह लेख VDS या समर्पित सर्वर के मालिकों के लिए उपयोगी होगा। कृपया अपनी टिप्पणियों और टिप्पणियों को छोड़ दें।

लिनक्स के साथ vds / समर्पित सर्वर के मालिकों के लिए DDoS हमलों से निपटने के उपलब्ध तरीके