सर्वर धीमा पढ़ना कमजोरियाँ

नमस्ते।
मैं आपको बताना चाहता हूं कि मैंने अपने खाली समय में क्वालिस में क्या किया था। चूंकि अंग्रेजी बोलने वाले इंटरनेट पर स्लो रीड DoS के हमले के बारे में आश्चर्यजनक रूप से बहुत शोर है , मुझे यकीन है कि मुझे यहां बहुत उपयोगी आलोचना और व्यावहारिक सुझाव मिलेंगे।

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

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

और सार यह है:

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

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

Sockstress मैन्युअल रूप से पैकेट बनाता है, अगली पुष्टि भेजने के लिए गणना करता है, ताकि सर्वर पर जारी टाइमर को रीसेट न करें, यह संक्षेप में मुश्किल है।
मेरा छात्र मेरे तरीके को व्यवहार में लाने में सक्षम है:
एक सॉकेट बनाएं, क्लाइंट पर एक अपेक्षाकृत छोटा प्राप्त बफर आकार सेट करें, उदाहरण के लिए, 100Kb तस्वीर के लिए पूरी तरह से सुसंगत और सामान्य HTTP अनुरोध भेजें। सर्वर मेमोरी से एक तस्वीर लेता है, इसे नेटवर्क पर स्थानांतरित करने के लिए कर्नेल देता है। सर्वर तस्वीर का एक टुकड़ा लेता है और इसे भेजता है, ग्राहक पहले हजार बाइट्स प्राप्त करता है, और कहता है कि रोकें, कोई जगह नहीं है। सर्वर सॉकेट को प्रदूषित करता है, यह समझने की कोशिश कर रहा है कि यह रिकॉर्डिंग के लिए कब तैयार होगा, लेकिन यह तैयार नहीं है! एक बार जब आप क्लाइंट से कुछ बाइट्स पढ़ते हैं तो बफर प्राप्त होता है ताकि टीसीपी स्टैक शून्य के अलावा कुछ और भेज सके, जिससे फायरवॉल और आईडीएस के लिए एक लाइव कनेक्शन की उपस्थिति पैदा होती है।

वह सब है। मैं आपसे पूछता हूं कि आपको ज्यादा किक नहीं करनी है, रूसी में पहला तकनीकी पद है, लेकिन मुझे यह पसंद है, मैंने वापस नहीं किया। एक विस्तृत विवरण यहां पाया जा सकता है ।
PS पिछले संस्करण के लिए, slowhttptest ने रूसी में एक विकि लिखा था, अगर कम से कम एक आत्मा को दिलचस्पी है, तो मैं इसे नए संस्करण के लिए अनुवाद करूंगा।

अपडेट:
मोडसिटी की सुरक्षा, विस्तार से दिखाएँ
ModSecurity सप्ताह के उन्नत विषय: 'धीमी गति से पढ़ें "सेवा हमले से इनकार
अपडेट 2:
शमश ने बीएसडी पर गलतियां बताईं। Svn में तय किया।