SYN-बाढ़ प्रकार का पता लगाने और DDoS के खिलाफ गतिशील संरक्षण

हाय, हेब्रोसोसिटी।

आजकल मैं DDoS हमलों की प्रासंगिकता के बारे में बात नहीं करूंगा। जरा आंकड़ों पर गौर करें। मैं अक्सर गतिविधि के प्रकारों से सामना करता हूं, डीडीओएस के खिलाफ गतिशील सुरक्षा का विचार जैसे कि लिनक्स पर एसईएन-बाढ़ और फ्रीबीएसडी सर्वर उत्पन्न हुए। एसएनएमपी के माध्यम से एसवाईएन-बाढ़ निगरानी का कार्यान्वयन भी प्रस्तावित है।

वह सब कट के नीचे है।

टीसीपी विकल्प

ऑपरेटिंग सिस्टम टीसीपी प्रोटोकॉल का उपयोग कर नेटवर्क पर काम करने के लिए फाइन-ट्यून सेटिंग्स की क्षमता प्रदान करता है। UNIX पर, यह कर्नेल पैरामीटर मानों को बदलकर किया जाता है। निम्नलिखित पैरामीटर हैं जो SYN अनुरोध कतार के प्रसंस्करण को प्रभावित करते हैं। डिफ़ॉल्ट मान कोष्ठकों में दिखाए गए हैं:

• net.core.somaxconn - कनेक्शन कतार का अधिकतम मूल्य (128)
• tcp_syn_retries - सफल कनेक्शन स्थापना के लिए SYN पास करने के प्रयासों की संख्या (5)
• tcp_synack_retries - SYN भेजने के प्रयासों की संख्या, SYN अनुरोध के लिए ACK प्रतिक्रिया (5)
• tcp_keepalive_intvl - प्रत्येक रख - रखाव जाँच प्रतिसाद (75 सेकंड) के लिए कब तक प्रतीक्षा करें
• tcp_keepalive_probes - कनेक्शन खो जाने पर निर्णय लेने से पहले टीसीपी रखने वाले नमूनों की संख्या को प्रेषित किया जाना चाहिए (9)
• tcp_keepalive_time - आवृत्ति जिसके साथ टीसीपी रखने के पैकेट को कनेक्शन गतिविधि को बनाए रखने के लिए प्रेषित किया जाना चाहिए यदि यह वर्तमान में उपयोग में नहीं है (7200 सेकंड)

FreeBSD के लिए इसी तरह के विकल्प ब्लॉग पर दिए गए हैं।

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

एक बार जब मैं मापदंडों के एक गतिशील परिवर्तन के साथ उल्लिखित विचार द्वारा दौरा किया गया था। इसमें संदेह है कि क्या यह वास्तव में उपयोगी है और क्या सिस्टम बूट के स्तर पर वैधानिक रूप से मूल्य निर्धारित करना है। मैंने ब्लॉग में इस समस्या का वर्णन किया है। मुझे इस मुद्दे पर पाठकों की राय सुनकर खुशी होगी।

SYN अनुरोधों की कतार के बारे में अलग से

कतार 128 का डिफ़ॉल्ट मान एक लोड सिस्टम के लिए बहुत छोटा है, खासकर अगर यह खुद को हमला करने के लिए उधार देता है, इसलिए इसे स्वाभाविक रूप से बढ़ाया जाना चाहिए। लेकिन एक सीमा है जो इस वृद्धि को सीमित करती है।
सबसे पहले, कतार में प्रत्येक प्रविष्टि में 600 बाइट्स की रैम होती है।
दूसरे, TCP पोर्ट पर सुनने वाली प्रत्येक सेवा के लिए net.core.somaxconn लंबाई की एक अलग कतार आवंटित की जाती है।
इन विचारों के आधार पर, net.core.somaxconn के मूल्य की गणना सूत्र द्वारा की जा सकती है:
somaxconn = (MEMfree - MEMres) / 600 * एन, जहां
मेम्फ्री - वर्तमान मुफ्त रैम
मेमर्स - मेमोरी जो सिस्टम और अन्य कार्यक्रमों के लिए आरक्षित है
600 बाइट्स - कतार में प्रत्येक प्रविष्टि लेता है
एन - टीसीपी बंदरगाहों पर सुनने वाली सेवाओं की संख्या

एसएनएमपी के लिए विस्तार कार्यान्वयन

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

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

सुरक्षा परीक्षण

एक 100Mb L2 स्विच से जुड़े डेस्कटॉप और लैपटॉप पर सिस्टम का परीक्षण किया गया था। हापिंग के साथ परीक्षण किया गया।

Cacti वास्तविक समय ग्राफ पर परिणाम:



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

टिप्पणी

1. व्यस्त सर्वरों पर, कतार 0 का मान व्यावहारिक रूप से मौजूद नहीं है। यह सामान्य मोड में 0 से ~ 40 तक होता है, इसलिए थ्रेसहोल्ड का चयन करना होगा।
2. HTTP बाढ़ के दौरान SYN अनुरोधों की कतार निश्चित रूप से बढ़ेगी, इसलिए कतार के दहलीज मूल्य द्वारा एक हमले का पता लगाना पूरी तरह से सही नहीं है। यद्यपि व्यवधान भी उपयोगी नहीं है।

वेबसाइट

परिचित और कॉन्फ़िगरेशन में आसानी के लिए, मैंने साइट synflood-defender.net बनाई। इसमें मौजूदा और नियोजित सुविधाएँ, एक डाउनलोड लिंक, चरण-दर-चरण सेटअप निर्देश और एक ब्लॉग है जिसमें उपयोगी DDoS- संबंधित प्रविष्टियाँ समय-समय पर दिखाई देंगी।
हाल ही में, स्क्रिप्ट ने ब्राज़ील के एक दोस्त के सर्वर को सुरक्षित रखने में मदद की। आभार में, उन्होंने हाउ टू यूज़ पेज का पुर्तगाली अनुवाद प्रकाशित किया। तो उन हेब्रिटेकैटेली, जो पुर्तगाली में पढ़ने में अधिक सहज हैं, उन्हें असुविधा महसूस नहीं होगी;)