2011-09-03 15 views
6

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

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

अगला, बी I पर क्लाइंट एप्लिकेशन के रूप में एनसी (नेटकैट) चलाता है, ए पर सर्वर अनुप्रयोग से कनेक्ट होता है, डेटा प्राप्त करना शुरू करता है, और कुछ सेकंड बाद में मैं इस कनेक्शन को बाधित करने के लिए Ctrl-C दबाता हूं।

जो मैं देखता हूं, ए पर सर्वर एप्लिकेशन लिखने में लटकता है(), इसे ईपीआईपीई या कोई अन्य त्रुटि नहीं मिली है।

मैं tcpdump का उपयोग कर टीसीपी/आईपी पैकेट का पता लगाया है, और यहाँ मैं क्या देख रहा है:

  • बी पर netcat दखल के बाद, बी ए, जो सही ढंग से कि फिन के लिए एसीके जवाब देने के लिए फिन भेज - तो , अब हम निष्पक्ष आधा खुला TCP कनेक्शन है, जो
  • अगले ठीक है, एक सामान्य एसीके और PSH, एसीके पैकेट, जो भी उम्मीद है और सही
  • साथ ग्राहक के बगल में डेटा भेजने के लिए कोशिश करता है लेकिन, बी नहीं करता है इन पैकेटों में किसी भी तरह से जवाब न दें (जबकि मुझे लगता है कि यह आरएसटी पैकेट के साथ जवाब दे क्योंकि यह पहले से बंद/गैर-मौजूदा टीसीपी कनेक्शन में पैकेट प्राप्त कर रहा है)
  • एक एसीके मिला नहीं है, इसलिए यह नया डेटा भेजने से रोकने और पुराने पैकेट फिर से भेजने शुरू (और इस बिंदु पर अगली कॉल लिखने के लिए() लटका हुआ है)

मैं भी एक पर netcat (चलाने के लिए कोशिश की है इसलिए क्लाइंट और सर्वर दोनों अनुप्रयोग एक ही भौतिक सर्वर पर चलते हैं), और इस तरह सब कुछ अपेक्षित काम करता है - Ctrl-C के साथ नेटकैट को बाधित करने के बाद सर्वर एप्लिकेशन को तुरंत EPIPE मिला। और tcpdump शो आरएसटी पैकेट अपेक्षित के रूप में भेजा गया है।

तो, इस मामले में आरएसटी नहीं भेजने का कारण क्या हो सकता है?

मैं किसी भी विशिष्ट sysctl नेटवर्क से संबंधित कॉन्फ़िगरेशन के बिना हार्डडेन जेनेटू लिनक्स, अप-टू-डेट, कर्नेल 2.6.39-कठोर-आर 8 का उपयोग कर रहा हूं।

यह ध्यान रखना महत्वपूर्ण हो सकता है कि इन सर्वरों पर महत्वपूर्ण नेटवर्क गतिविधि है, किसी भी पल में netstat -alnp द्वारा सूचीबद्ध 5000 टीसीपी कनेक्शन, और मुझे लगता है कि लगभग 1000 कनेक्शन खुलते हैं और औसत में हर सेकेंड को बंद करते हैं। यह इस तरह गिरी लॉग कुछ में देखने के लिए हमेशा की तरह है (लेकिन सर्वर अनुप्रयोग ऊपर चर्चा द्वारा प्रयोग किया जाता से पोर्ट संख्या अलग है): यह व्यवहार http://i54.tinypic.com/1zz10mx.jpg

+0

अन्य साइट पर चर्चा से: ** 1) ** नेटकैट से बाहर निकलने के बाद नेटस्टैट सर्वर सर्वर पर कनेक्शन को सूचीबद्ध नहीं करता है (जबकि मुझे लगता है कि इसे FIN_WAIT_2 स्थिति में सूचीबद्ध किया जाना चाहिए), सर्वर पर नेटस्टैट अभी भी यह दिखाता है अपेक्षित के रूप में CLOSE_WAIT स्थिति में कनेक्शन; ** 2) ** कोई सोचता है कि यह SO_LINGER की वजह से हो सकता है, लेकिन मैं असहमत हूं क्योंकि netcat SO_LINGER को मैन्युअल रूप से सक्रिय नहीं करता है और बाहर निकलने से पहले() को बंद करता है() ताकि इसे स्वचालित रूप से सक्रिय नहीं किया जाना चाहिए, साथ ही SO_LINGER को प्रभावित नहीं होना चाहिए एसीके/आरएसटी वैसे भी _incoming_ पैकेट पर जवाब। – Powerman

+0

पुराने कर्नेल की तरह दिखता है (2.6.28-कठोर-आर 9) अपेक्षा के अनुसार काम करता है - आरएसटी पैकेट भेजें। – Powerman

उत्तर

3

परिणाम है:

TCP: Possible SYN flooding on port XXXXX. Sending cookies. 
    net_ratelimit: 19 callbacks suppressed 

यहाँ कैसे टीसीपी सत्र आम तौर पर लगता है कि है

Security options ---> 
    Grsecurity ---> 
     Network Protections ---> 
     [*] TCP/UDP blackhole and LAST_ACK DoS prevention 

CONFIG_GRKERNSEC_BLACKHOLE: की मेरी कठोर कर्नेल में सक्षम सुविधा

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