SYN_RECV कनेक्शन की कम संख्या के बावजूद लॉग में "संभावित SYN बाढ़"

Question

हाल ही में हमारे पास एक अपाचे सर्वर था जो SYN बाढ़ के कारण बहुत धीरे-धीरे जवाब दे रहा था। इसके लिए समाधान tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf) को सक्षम करना था ।

यदि आप अधिक पृष्ठभूमि चाहते हैं तो मैंने इस बारे में एक प्रश्न यहां पोस्ट किया है ।

सिंक्रनाइज़ेशन को सक्षम करने के बाद, हमने निम्नलिखित संदेश को लगभग 60 सेकंड में / var / log / संदेश में देखना शुरू किया:

[84440.731929] possible SYN flooding on port 80. Sending cookies.

Vinko Vrsalovic ने मुझे सूचित किया कि इसका मतलब है कि बैकलॉग पूर्ण हो रहा है, इसलिए मैंने tcp_max_syn_backlog को 4096 तक उठाया। कुछ बिंदु पर मैंने tcp_synack_retries को 3 (5 के डिफ़ॉल्ट से नीचे) जारी करके कम किया sysctl -w net.ipv4.tcp_synack_retries=3। ऐसा करने के बाद, आवृत्ति गिरनी शुरू हो गई, संदेशों के अंतराल में लगभग 60 और 180 सेकंड के बीच अंतर था।

अगला मैंने जारी किया sysctl -w net.ipv4.tcp_max_syn_backlog=65536, लेकिन अभी भी लॉग में संदेश मिल रहा है।

इस सब के दौरान, मैं SYN_RECV राज्य में कनेक्शनों की संख्या देख रहा हूं (चलाकर watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l'), और यह लगभग 240 से अधिक नहीं जाता है, बैकलॉग के आकार की तुलना में बहुत कम है। फिर भी मेरे पास एक Red Hat सर्वर है जो लगभग 512 (इस सर्वर पर सीमा 1024 की डिफ़ॉल्ट है) पर घूमता है।

क्या कोई अन्य tcp सेटिंग्स है जो बैकलॉग के आकार को सीमित करेगा या क्या मैं गलत पेड़ को भौंक रहा हूं? netstat -tunaबैकलॉग के आकार के संबंध में SYN_RECV कनेक्शन की संख्या होनी चाहिए ?

---

अद्यतन करें

जैसा कि सबसे अच्छा मैं बता सकता हूं कि मैं यहां वैध कनेक्शन के साथ काम कर रहा हूं, netstat -tuna|wc -lलगभग 5000 के आसपास हो जाता है। मैं आज इस पर शोध कर रहा हूं और इस पोस्ट को एक last.fm कर्मचारी से पाया गया है, जो उपयोगी नहीं है।

मैंने यह भी पाया है कि tcp_max_syn_backlog का कोई प्रभाव नहीं पड़ता है जब सिंकुकीज़ सक्षम होते हैं ( इस लिंक के अनुसार )

इसलिए अगले चरण के रूप में मैंने sysctl.conf में निम्नलिखित सेट किया:

net.ipv4.tcp_syn_retries = 3
        # default=5
net.ipv4.tcp_synack_retries = 3
        # default=5
net.ipv4.tcp_max_syn_backlog = 65536
        # default=1024
net.core.wmem_max = 8388608
        # default=124928
net.core.rmem_max = 8388608
        # default=131071
net.core.somaxconn = 512
        # default = 128
net.core.optmem_max = 81920
        # default = 20480

फिर मैंने अपनी प्रतिक्रिया समय परीक्षण, sysctl -pदौड़ाया और अक्षम सिंक्युकी द्वारा सेटअप किया sysctl -w net.ipv4.tcp_syncookies=0।

ऐसा करने के बाद SYN_RECV राज्य में कनेक्शन की संख्या अभी भी 220-250 के आसपास बनी हुई थी, लेकिन कनेक्शन फिर से देरी से शुरू हो रहे थे। एक बार जब मैंने इन देरी पर ध्यान दिया तो मैंने सिंक्युकी को फिर से सक्षम किया और देरी रुक गई।

मेरा मानना ​​है कि जो मैं देख रहा था वह अभी भी प्रारंभिक स्थिति से एक सुधार था, हालांकि कुछ अनुरोधों में अभी भी देरी हो रही थी जो सिंक्यूकी सक्षम होने से बहुत खराब है। तो ऐसा लग रहा है कि मैं उनके साथ सक्षम हूं जब तक कि हम लोड से निपटने के लिए कुछ और सर्वर ऑनलाइन नहीं पा सकते। फिर भी, मुझे यकीन नहीं है कि सर्वर के बफ़र्स पूर्ण होने पर मुझे उन्हें फिर से अक्षम करने का एक वैध कारण दिखाई दे रहा है (केवल)।

लेकिन सिंक बैकलॉग SYN_RECV राज्य में केवल ~ 250 कनेक्शन के साथ भरा हुआ नहीं दिखता है! क्या यह संभव है कि SYN बाढ़ संदेश एक लाल हेरिंग है और यह syn_backlog के अलावा कुछ और है जो भर रहा है?

अगर किसी के पास कोई अन्य ट्यूनिंग विकल्प हैं, तो मैंने अभी तक कोशिश नहीं की है, मैं उन्हें बाहर की कोशिश करने में अधिक खुश हूं, लेकिन मुझे आश्चर्य है कि अगर किसी कारण से syn_backlog सेटिंग ठीक से लागू नहीं हो रही है।

Comments

संबंधित serverfault.com/questions/78820/dmesg-syn-flood-on-80-sysctl-p

— Vinko Vrsalovic

Answer 1

तो, यह एक साफ सवाल है।

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

वास्तव में, स्रोत पर एक त्वरित झांकना (tcp_ipv4.c) कर्नेल औजार कुकीज़ को कैसे लागू करता है, इसके बारे में दिलचस्प जानकारी दिखाता है। अनिवार्य रूप से, उन्हें चालू करने के बावजूद, कर्नेल व्यवहार करता है क्योंकि यह सामान्य रूप से तब तक रहेगा जब तक कि लंबित कनेक्शनों की कतार पूरी न हो जाए। यह SYN_RECV राज्य में आपके मौजूदा कनेक्शन की सूची की व्याख्या करता है।

केवल जब लंबित कनेक्शनों की कतार भरी हुई है, और एक और SYN पैकेट (कनेक्शन का प्रयास) प्राप्त हुआ है, और यह अंतिम चेतावनी संदेश के बाद से एक मिनट से अधिक समय हो गया है, क्या कर्नेल आपके द्वारा देखे गए चेतावनी संदेश भेजता है ("कुकीज़ भेज रहा है") )। चेतावनी संदेश नहीं होने पर भी SYN कुकीज़ भेजी जाती हैं; चेतावनी संदेश सिर्फ आपको एक सिर देने के लिए है कि समस्या दूर नहीं हुई है।

एक और तरीका रखो, यदि आप SYN कुकीज़ बंद कर देते हैं, तो संदेश चला जाएगा। अगर आप SYN बाढ़ में नहीं रहे हैं तो यह आपके लिए काम करने वाला है।

आपके द्वारा की गई कुछ अन्य चीजों को संबोधित करने के लिए:

• net.ipv4.tcp_synack_retries:
  • इसे बढ़ाने से आने वाले कनेक्शनों के खराब होने का कोई सकारात्मक प्रभाव नहीं होगा, और न ही सर्वर-साइड स्थिति के बजाय SYN कुकी प्राप्त करने वाले (उनके लिए कोई रिट्रीट नहीं) के लिए।
  • आने वाले स्पूफ़ किए गए कनेक्शनों के लिए, इसे बढ़ाने से आपके द्वारा नकली पते पर भेजे जाने वाले पैकेटों की संख्या बढ़ जाती है, और संभवत: उस स्पूफ किए गए समय की मात्रा आपकी कनेक्शन तालिका में रहती है (यह एक महत्वपूर्ण नकारात्मक प्रभाव हो सकता है)।
  • आने वाले कनेक्शनों की सामान्य लोड / संख्या के तहत, यह उच्चतर है कि आप पैकेट छोड़ने वाले लिंक पर कनेक्शन को जल्दी / सफलतापूर्वक पूरा करने की अधिक संभावना रखते हैं। इसे बढ़ाने के लिए कम रिटर्न मिल रहा है।
• net.ipv4.tcp_syn_retries: इसे बदलने से इनबाउंड कनेक्शन पर कोई प्रभाव नहीं पड़ सकता है (यह केवल आउटबाउंड कनेक्शन को प्रभावित करता है)

आपके द्वारा उल्लेखित अन्य चर मैंने शोध नहीं किया है, लेकिन मुझे संदेह है कि आपके प्रश्न के उत्तर यहां बहुत अधिक हैं।

यदि आपको SYN बाढ़ नहीं आ रही है और मशीन गैर-HTTP कनेक्शन (जैसे SSH) के लिए उत्तरदायी है, तो मुझे लगता है कि नेटवर्क समस्या है, और आपको इसे देखने में नेटवर्क इंजीनियर की मदद करनी चाहिए। यदि मशीन आमतौर पर तब भी अनुत्तरदायी होती है जब आप SYN बाढ़ में नहीं होते हैं, तो यह एक गंभीर लोड समस्या की तरह लगता है यदि यह टीसीपी कनेक्शन के निर्माण को प्रभावित करता है (बहुत कम स्तर और संसाधन गैर-गहन)

Comments

धन्यवाद - यह एक दिलचस्प और जानकारीपूर्ण उत्तर है। यह निश्चित रूप से SYN_RECV राज्य में कनेक्शन और कुकीज़ भेजने के बीच संबंध के बारे में मेरी क्वेरी का जवाब देता है। SSH और HTTPS सहित गैर HTTP के लिए मशीन उत्तरदायी थी, जो HTTP से बहुत कम ट्रैफ़िक प्राप्त करता है। इस प्रकार हमने तय किया है कि यातायात को कम करना ही रास्ता है।

— एलेक्स फोर्ब्स

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

— एलेक्स फोर्ब्स ने

Answer 2

मैंने उबंटू वनिरिक 11.10 की एक नई स्थापना पर ठीक वैसी ही समस्या का सामना किया है, जो एक भारी लोड वाली वेबसाइट के साथ वेबसर्वर (अपाचे 2) चला रहा है। Ubuntu Oneiric पर 11.10 सिंक डिफ़ॉल्ट रूप से सक्षम थे।

मेरे पास एक ही कर्नेल संदेश था जो वेबसर्वर पोर्ट पर एक संभावित SYN बाढ़ हमले को बताता था:

कर्नेल: [739408.882650] TCP: पोर्ट 80 पर संभावित SYN बाढ़। कुकीज़ भेजना।

उसी समय, मुझे पूरा यकीन था, कि कोई हमला नहीं हो रहा था। मुझे यह संदेश 5 मिनट के अंतराल पर मिला। यह लोड लोडिंग की तरह लग रहा था, क्योंकि एक हमलावर लोड को हर समय ऊंचा रखेगा, जबकि सर्वर रिक्वेस्ट को रिक्वेस्ट करने की कोशिश कर रहा था।

net.ipv4.tcp_max_syn_backlogपैरामीटर को ट्यून करने से कोई सुधार नहीं हुआ - संदेश उसी दर पर जारी रहे। तथ्य यह है कि SYN_RECV कनेक्शन की संख्या हमेशा कम थी (250 के तहत मेरे मामले में) एक संकेतक था, कि कुछ अन्य पैरामीटर होना चाहिए, जो इस संदेश के लिए जिम्मेदार है।

मुझे यह बग-संदेश https://bugzilla.redhat.com/show_bug.cgi?id=734991 पर मिला है, जो बताता है कि कर्नेल संदेश बग (या गलत सूचना) के परिणामस्वरूप हो सकता है। । बेशक लॉग संदेश बहुत भ्रामक है! जैसा कि यह कर्नेल पैरामीटर नहीं है जो उस स्थिति में जिम्मेदार है, लेकिन आपके एप्लिकेशन का पैरामीटर, कर्नेल को पास किया गया है।

इसलिए हमें अपने वेबसर्वर एप्लिकेशन के कॉन्फ़िगरेशन मापदंडों पर भी ध्यान देना चाहिए। अपाचे डॉक्स को पकड़ो और http://httpd.apache.org/docs/2.0/mod/mpm_common.html#listenbacklog पर जाएं

ListenBacklogपैरामीटर का डिफ़ॉल्ट मान 511 है। (यह कनेक्शन की संख्या से मेल खाता है, जिसे आपने अपने रेड हैट सर्वर पर देखा है। आपके दूसरे सर्वर में संभवतः कम संख्या कॉन्फ़िगर की गई है।)

अपाचे में आने वाले कनेक्शन के लिए बैकलॉग कतार के लिए स्वयं का कॉन्फ़िगरेशन पैरामीटर है। यदि आपके पास बहुत सारे इनकमिंग कनेक्शन हैं, और किसी भी क्षण (बस एक यादृच्छिक चीज़ के रूप में) वे लगभग एक ही समय में एक साथ पहुंचते हैं, जैसे कि वेबसर्वर उन्हें उचित तरीके से तेजी से सेवा करने में सक्षम नहीं है, तो आपका बैकलॉग होगा 511 कनेक्शन के साथ भरा हो और कर्नेल एक संभावित SYN बाढ़ हमले को बताते हुए उपरोक्त संदेश को आग लगा देगा।

इसे हल करने के लिए, मैं निम्न पंक्ति को /etc/apache2/ports.confया अन्य .conf फ़ाइलों में से एक को जोड़ता हूं , जो अपाचे द्वारा लोड किया जाएगा ( /etc/apache2/apache2.confठीक होना चाहिए):

सुनिबैकलॉग 5000

आपको net.ipv4.tcp_max_syn_backlogएक उचित मूल्य भी निर्धारित करना चाहिए । मेरी समझ में, कर्नेल अधिकतम मान को सीमित कर देगा, जिसे आप अपाचे कॉन्फ़िगरेशन में कॉन्फ़िगर करने में सक्षम होंगे। इतना रन:

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000

कॉन्फ़िगरेशन को ट्यून करने के बाद, अपनी अपाचे को पुनरारंभ करना न भूलें:

sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart )

मेरे मामले में, इस कॉन्फ़िगरेशन परिवर्तन ने कर्नेल चेतावनी को तुरंत रोक दिया। मैं अपाचे कॉन्फिगर में कम ListenBackLog मान सेट करके संदेशों को पुन: उत्पन्न करने में सक्षम हूं।

Comments

बहुत बढ़िया जवाब। यह मानते हुए कि आप जो कहते हैं वह सही है मैं इसे स्वीकार किए गए उत्तर के रूप में चिह्नित करूंगा लेकिन मैं वास्तव में इसका परीक्षण नहीं कर सकता - लोड को कम करने से समस्या हल हो गई और मेरे पास अच्छे कारणों के बिना उत्पादन सर्वर के साथ छेड़छाड़ नहीं करने की नीति है :)

— एलेक्स फोर्ब्स

मैं पुष्टि कर सकता हूं कि यह अनिवार्य रूप से काम करता है यह एक कर्नेल एंटी-डीडीओएस सुविधा है, लेकिन जब आप कह रहे हैं कि यह बहुत सारे वेब ट्रैफ़िक है तो यह आपके वैध उपयोगकर्ताओं को अवरुद्ध करता है!

— अरीब सू यासिर

Answer 3

कर्नेल 3.4.9 के साथ कुछ परीक्षणों के बाद netstat में SYN_RECV कनेक्शन की संख्या निर्भर करती है

• /proc/sys/net/core/somaxconn 2 की अगली शक्ति तक गोल (जैसे 128 -> 256)
• /proc/sys/net/ipv4/tcp_max_syn_backlogअगर 75% /proc/sys/net/ipv4/tcp_syncookiesसेट है 0या 100% /proc/sys/net/ipv4/tcp_syncookiesसेट है तो1
• ListenBackLog अपाचे में 2 की अगली शक्ति तक कॉन्फ़िगर किया गया (उदाहरण के लिए 128 -> 256)

इस पैरामीटर में से प्रत्येक का उपयोग किया जाता है। Somaxconn या ListenBackLog अपाचे को बदलने के बाद फिर से शुरू करना होगा।

और tcp_max_syn_backlog अपाचे बढ़ाने के बाद भी पुनरारंभ करना होगा।

Tcp_syncookies के बिना अपाचे अवरुद्ध हो रहा है, क्यों इस मामले में tcp_max_syn_backlog की केवल 75% सीमा अजीब है। और इस पैरामीटर को बढ़ाने से अपाचे को पुनरारंभ किए बिना SYN_RECV कनेक्शन पुराने मूल्य के 100% तक बढ़ जाता है।

Comments

और कॉल /bin/echo m >/proc/sysrq-triggerभी अक्सर पोर्ट 80 पर एक संभावित SYN बाढ़ की ओर जाता है । कुकीज़ संदेश भेजना ।

— usoft