🥇 कामाच्या फेऱ्या आणणाऱ्या असुरक्षिततेपासून सावध रहा. भाग 1: FragmentSmack/SegmentSmack

सर्वांना नमस्कार! माझे नाव दिमित्री सॅमसोनोव्ह आहे, मी ओड्नोक्लास्निकी येथे प्रमुख सिस्टम प्रशासक म्हणून काम करतो. आमच्याकडे 7 हजारांहून अधिक फिजिकल सर्व्हर, आमच्या क्लाउडमध्ये 11 हजार कंटेनर आणि 200 अॅप्लिकेशन्स आहेत, जे विविध कॉन्फिगरेशनमध्ये 700 भिन्न क्लस्टर बनवतात. बहुसंख्य सर्व्हर CentOS 7 चालवतात.
14 ऑगस्ट 2018 रोजी, FragmentSmack भेद्यतेबद्दल माहिती प्रकाशित झाली
(सीव्हीई- 2018-5391) आणि SegmentSmack (सीव्हीई- 2018-5390). ही नेटवर्क अटॅक वेक्टर आणि बर्‍यापैकी उच्च स्कोअर (7.5) सह असुरक्षा आहेत, ज्यामुळे संसाधन संपुष्टात येणे (CPU) मुळे सेवा नाकारण्याची (DoS) धमकी मिळते. FragmentSmack साठी कर्नल फिक्स त्या वेळी प्रस्तावित नव्हते; शिवाय, ते असुरक्षिततेबद्दल माहितीच्या प्रकाशनापेक्षा खूप नंतर आले. SegmentSmack काढून टाकण्यासाठी, कर्नल अद्ययावत करण्याचे सुचवले होते. अद्ययावत पॅकेज त्याच दिवशी रिलीझ केले गेले, ते स्थापित करणे बाकी आहे.
नाही, आम्ही कर्नल अद्ययावत करण्याच्या विरोधात नाही! तथापि, बारकावे आहेत ...

आम्ही उत्पादनावर कर्नल कसे अपडेट करतो

सर्वसाधारणपणे, काहीही क्लिष्ट नाही:

पॅकेजेस डाउनलोड करा;
त्यांना बर्‍याच सर्व्हरवर स्थापित करा (आमचे क्लाउड होस्ट करणार्‍या सर्व्हरसह);
काहीही तुटलेले नाही याची खात्री करा;
सर्व मानक कर्नल सेटिंग्ज त्रुटींशिवाय लागू केल्याची खात्री करा;
काही दिवस थांबा;
सर्व्हर कामगिरी तपासा;
नवीन कर्नलवर नवीन सर्व्हरची तैनाती स्विच करा;
डेटा सेंटरद्वारे सर्व सर्व्हर अपडेट करा (समस्या आल्यास वापरकर्त्यांवर होणारा परिणाम कमी करण्यासाठी एका वेळी एक डेटा सेंटर);
सर्व सर्व्हर रीबूट करा.

आमच्याकडे असलेल्या कर्नलच्या सर्व शाखांसाठी पुनरावृत्ती करा. याक्षणी ते आहे:

स्टॉक सेंटोस 7 3.10 - बहुतेक नियमित सर्व्हरसाठी;
व्हॅनिला 4.19 - आमच्यासाठी एक मेघ ढग, कारण आम्हाला BFQ, BBR इ. आवश्यक आहे;
Elrepo kernel-ml 5.2 - साठी अत्यंत लोड केलेले वितरक, कारण 4.19 अस्थिर वागायचे, परंतु समान वैशिष्ट्ये आवश्यक आहेत.

तुम्ही अंदाज केला असेल की, हजारो सर्व्हर रीबूट करण्यासाठी सर्वात जास्त वेळ लागतो. सर्व असुरक्षा सर्व सर्व्हरसाठी गंभीर नसल्यामुळे, आम्ही फक्त इंटरनेटवरून थेट प्रवेशयोग्य असलेल्यांनाच रीबूट करतो. क्लाउडमध्ये, लवचिकता मर्यादित न करण्यासाठी, आम्ही नवीन कर्नलसह बाह्यरित्या प्रवेश करण्यायोग्य कंटेनर वैयक्तिक सर्व्हरशी बांधत नाही, परंतु अपवाद न करता सर्व होस्ट रीबूट करतो. सुदैवाने, तेथील प्रक्रिया नियमित सर्व्हरपेक्षा सोपी आहे. उदाहरणार्थ, रीबूट करताना स्टेटलेस कंटेनर फक्त दुसर्‍या सर्व्हरवर जाऊ शकतात.

तथापि, अद्याप बरेच काम आहे आणि यास अनेक आठवडे लागू शकतात आणि नवीन आवृत्तीमध्ये काही समस्या असल्यास, कित्येक महिन्यांपर्यंत. हल्लेखोरांना हे चांगले समजते, म्हणून त्यांना प्लॅन बी आवश्यक आहे.

FragmentSmack/SegmentSmack. वर्कअराउंड

सुदैवाने, काही असुरक्षिततेसाठी अशी योजना B अस्तित्वात आहे आणि त्याला वर्कअराउंड म्हणतात. बर्‍याचदा, हा कर्नल/अनुप्रयोग सेटिंग्जमधील बदल आहे जो संभाव्य प्रभाव कमी करू शकतो किंवा असुरक्षिततेचे शोषण पूर्णपणे काढून टाकू शकतो.

FragmentSmack/SegmentSmack च्या बाबतीत प्रस्तावित केले होते हा उपाय:

«तुम्ही net.ipv4.ipfrag_high_thresh आणि net.ipv3.ipfrag_low_thresh (आणि ipv4 net.ipv4.ipfrag_high_thresh आणि net.ipv6.ipfrag_low_thresh आणि net.ipv6.ipfrag_low_thresh साठी त्यांचे समकक्ष) मध्ये 6MB आणि 256MB ची डीफॉल्ट मूल्ये kB192 kB262144 आणि kB64 मध्ये बदलू शकता. कमी हार्डवेअर, सेटिंग्ज आणि अटींवर अवलंबून हल्ल्यादरम्यान चाचणी CPU वापरामध्ये लहान ते लक्षणीय घट दर्शवतात. तथापि, ipfrag_high_thresh=XNUMX बाइट्समुळे काही कार्यप्रदर्शन प्रभाव असू शकतो, कारण एका वेळी फक्त दोन XNUMXK तुकड्या पुन्हा जोडण्याच्या रांगेत बसू शकतात. उदाहरणार्थ, मोठ्या UDP पॅकेटसह कार्य करणारे अनुप्रयोग खंडित होण्याचा धोका आहे».

मापदंड स्वतः कर्नल दस्तऐवजीकरणात खालीलप्रमाणे वर्णन केले आहे:

ipfrag_high_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments before the kernel begins to remove incomplete fragment queues to free up resources. The kernel still accepts new fragments for defragmentation.

आमच्याकडे उत्पादन सेवांवर मोठे UDP नाहीत. LAN वर खंडित रहदारी नाही; WAN वर खंडित रहदारी आहे, परंतु लक्षणीय नाही. कोणतीही चिन्हे नाहीत - तुम्ही वर्कअराउंड रोल आउट करू शकता!

FragmentSmack/SegmentSmack. पहिले रक्त

आम्हाला आलेली पहिली समस्या ही होती की क्लाउड कंटेनर्स काहीवेळा नवीन सेटिंग्ज केवळ अंशतः लागू करतात (केवळ ipfrag_low_thresh), आणि काहीवेळा ते अजिबात लागू होत नाहीत - ते फक्त सुरुवातीला क्रॅश झाले. समस्या स्थिरपणे पुनरुत्पादित करणे शक्य नव्हते (सर्व सेटिंग्ज कोणत्याही अडचणीशिवाय व्यक्तिचलितपणे लागू केल्या गेल्या होत्या). सुरुवातीला कंटेनर का क्रॅश होतो हे समजून घेणे देखील इतके सोपे नाही: कोणत्याही त्रुटी आढळल्या नाहीत. एक गोष्ट निश्चित होती: सेटिंग्ज परत केल्याने कंटेनर क्रॅशची समस्या सोडवली जाते.

होस्टवर Sysctl लागू करणे पुरेसे का नाही? कंटेनर त्याच्या स्वतःच्या समर्पित नेटवर्क नेमस्पेसमध्ये राहतो, त्यामुळे किमान नेटवर्क Sysctl पॅरामीटर्सचा भाग कंटेनरमध्ये होस्टपेक्षा वेगळे असू शकते.

कंटेनरमध्ये Sysctl सेटिंग्ज नेमक्या कशा लागू केल्या जातात? आमचे कंटेनर विशेषाधिकार नसल्यामुळे, तुम्ही कंटेनरमध्ये जाऊन कोणतीही Sysctl सेटिंग बदलू शकणार नाही - तुमच्याकडे पुरेसे अधिकार नाहीत. कंटेनर चालविण्यासाठी, आमच्या क्लाउडने त्या वेळी डॉकर (आता पोडमॅन). आवश्यक Sysctl सेटिंग्जसह नवीन कंटेनरचे पॅरामीटर्स API द्वारे डॉकरला पास केले गेले.
आवृत्त्यांमधून शोध घेत असताना, असे दिसून आले की डॉकर एपीआयने सर्व त्रुटी परत केल्या नाहीत (किमान आवृत्ती 1.10 मध्ये). जेव्हा आम्ही "डॉकर रन" द्वारे कंटेनर सुरू करण्याचा प्रयत्न केला, तेव्हा आम्हाला शेवटी काहीतरी दिसले:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

पॅरामीटर मूल्य वैध नाही. पण का? आणि ते कधी कधी वैध का नाही? असे दिसून आले की डॉकर Sysctl पॅरामीटर्स लागू केलेल्या क्रमाची हमी देत नाही (नवीनतम चाचणी केलेली आवृत्ती 1.13.1 आहे), म्हणून काहीवेळा ipfrag_high_thresh ने 256K वर सेट करण्याचा प्रयत्न केला जेव्हा ipfrag_low_thresh अजूनही 3M होते, म्हणजे, वरची मर्यादा कमी होती. कमी मर्यादेपेक्षा, ज्यामुळे त्रुटी आली.

त्या वेळी, आम्ही आधीच सुरू केल्यानंतर कंटेनर पुन्हा कॉन्फिगर करण्यासाठी आमची स्वतःची यंत्रणा वापरली (नंतर कंटेनर गोठवणे गट फ्रीजर आणि द्वारे कंटेनरच्या नेमस्पेसमध्ये कमांड कार्यान्वित करणे ip netns), आणि आम्ही या भागात Sysctl पॅरामीटर्स लिहिणे देखील जोडले. प्रश्न सुटला.

FragmentSmack/SegmentSmack. पहिले रक्त 2

क्लाउडमधील वर्कअराउंडचा वापर समजून घेण्यासाठी आम्हाला वेळ मिळण्यापूर्वी, वापरकर्त्यांकडून पहिल्या दुर्मिळ तक्रारी येऊ लागल्या. त्या वेळी, पहिल्या सर्व्हरवर वर्कअराउंड वापरणे सुरू होऊन अनेक आठवडे उलटून गेले होते. प्राथमिक तपासणीत असे दिसून आले आहे की वैयक्तिक सेवांविरुद्ध तक्रारी प्राप्त झाल्या होत्या, आणि या सेवांच्या सर्व सर्व्हरवर नाही. समस्या पुन्हा अत्यंत अनिश्चित बनली आहे.

सर्व प्रथम, आम्ही अर्थातच, Sysctl सेटिंग्ज परत करण्याचा प्रयत्न केला, परंतु याचा कोणताही परिणाम झाला नाही. सर्व्हर आणि अनुप्रयोग सेटिंग्जसह विविध हाताळणी देखील मदत करत नाहीत. रीबूटने मदत केली. लिनक्स रीबूट करणे तितकेच अनैसर्गिक आहे जितके जुन्या काळात विंडोजसाठी सामान्य होते. तथापि, याने मदत केली आणि Sysctl मध्ये नवीन सेटिंग्ज लागू करताना आम्ही ते "कर्नल ग्लिच" पर्यंत पोहोचवले. किती फालतू होतं ते...

तीन आठवड्यांनंतर समस्या पुन्हा उद्भवली. या सर्व्हरचे कॉन्फिगरेशन अगदी सोपे होते: प्रॉक्सी/बॅलन्सर मोडमध्ये Nginx. जास्त रहदारी नाही. नवीन प्रास्ताविक टीप: क्लायंटवरील 504 त्रुटींची संख्या दररोज वाढत आहे (गेटवे कालबाह्य). आलेख या सेवेसाठी दररोज 504 त्रुटींची संख्या दर्शवितो:

सर्व त्रुटी समान बॅकएंड बद्दल आहेत - क्लाउडमध्ये असलेल्या बद्दल. या बॅकएंडवरील पॅकेजच्या तुकड्यांसाठी मेमरी वापर आलेख असे दिसत होते:

ऑपरेटिंग सिस्टम आलेखांमधील समस्येचे हे सर्वात स्पष्ट अभिव्यक्तींपैकी एक आहे. क्लाउडमध्ये, त्याच वेळी, QoS (ट्रॅफिक कंट्रोल) सेटिंग्जसह आणखी एक नेटवर्क समस्या निश्चित केली गेली. पॅकेटच्या तुकड्यांसाठी मेमरी वापराच्या आलेखावर, ते अगदी सारखेच दिसत होते:

गृहीतक सोपे होते: जर ते आलेखांवर सारखे दिसत असतील तर त्यांचे कारण समान आहे. शिवाय, या प्रकारच्या मेमरीसह कोणतीही समस्या अत्यंत दुर्मिळ आहे.

निश्चित समस्येचे सार हे होते की आम्ही QoS मध्ये डीफॉल्ट सेटिंग्जसह fq पॅकेट शेड्यूलर वापरले. डीफॉल्टनुसार, एका कनेक्शनसाठी, ते तुम्हाला रांगेत 100 पॅकेट जोडण्याची परवानगी देते आणि काही कनेक्शन्स, चॅनेलच्या कमतरतेच्या परिस्थितीत, रांगेला क्षमतेनुसार रोखू लागतात. या प्रकरणात, पॅकेट सोडले जातात. tc आकडेवारीमध्ये (tc -s qdisc) हे असे पाहिले जाऊ शकते:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0) backlog 0b 0p requeues 0 1024 flows (1021 inactive, 0 throttled) 0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

“464545 flows_plimit” हे एका कनेक्शनच्या रांगेची मर्यादा ओलांडल्यामुळे सोडलेली पॅकेट आहे आणि “ड्रॉप 464545” ही या शेड्युलरच्या सर्व सोडलेल्या पॅकेटची बेरीज आहे. रांगेची लांबी 1 हजारांपर्यंत वाढवल्यानंतर आणि कंटेनर पुन्हा सुरू केल्यानंतर समस्या येण्याचे थांबले. तुम्ही परत बसून स्मूदी पिऊ शकता.

FragmentSmack/SegmentSmack. शेवटचे रक्त

प्रथम, कर्नलमधील भेद्यतेच्या घोषणेनंतर अनेक महिन्यांनंतर, फ्रॅगमेंटस्मॅकसाठी एक निराकरण शेवटी दिसून आले (मी तुम्हाला आठवण करून देतो की ऑगस्टमधील घोषणेसह, फक्त सेगमेंटस्मॅकसाठी एक निराकरण जारी केले गेले), ज्यामुळे आम्हाला वर्कअराउंड सोडण्याची संधी मिळाली, ज्यामुळे आम्हाला खूप त्रास झाला. या काळात, आम्ही आधीच काही सर्व्हर नवीन कर्नलमध्ये हस्तांतरित करण्यात व्यवस्थापित केले होते, आणि आता आम्हाला सुरुवातीपासून सुरुवात करायची होती. FragmentSmack फिक्सची वाट न पाहता आम्ही कर्नल का अपडेट केले? वस्तुस्थिती अशी आहे की या असुरक्षिततेपासून संरक्षण करण्याची प्रक्रिया CentOS स्वतः अद्यतनित करण्याच्या प्रक्रियेशी जुळली (आणि विलीन झाली) (ज्याला फक्त कर्नल अद्यतनित करण्यापेक्षा जास्त वेळ लागतो). याव्यतिरिक्त, SegmentSmack ही अधिक धोकादायक असुरक्षा आहे, आणि त्याचे निराकरण ताबडतोब दिसून आले, त्यामुळे तरीही त्याचा अर्थ झाला. तथापि, आम्ही CentOS वर कर्नल फक्त अद्यतनित करू शकलो नाही कारण CentOS 7.5 दरम्यान दिसणारी FragmentSmack असुरक्षा केवळ आवृत्ती 7.6 मध्ये निश्चित केली गेली होती, म्हणून आम्हाला 7.5 वर अद्यतनित करणे थांबवावे लागले आणि 7.6 च्या अद्यतनासह पुन्हा सुरू करावे लागले. आणि हे देखील घडते.

दुसरे म्हणजे, समस्यांबद्दल दुर्मिळ वापरकर्त्याच्या तक्रारी आमच्याकडे परत आल्या आहेत. आता आम्हाला आधीच माहित आहे की ते सर्व क्लायंटकडून आमच्या काही सर्व्हरवर फायली अपलोड करण्याशी संबंधित आहेत. शिवाय, एकूण वस्तुमानातून खूप कमी संख्येने अपलोड या सर्व्हरमधून झाले.

वरील कथेवरून आपल्याला आठवत आहे की, Sysctl परत आणण्याने काही फायदा झाला नाही. रीबूटने मदत केली, परंतु तात्पुरते.
Sysctl बाबतच्या शंका दूर झाल्या नाहीत, पण यावेळी जास्तीत जास्त माहिती गोळा करणे आवश्यक होते. काय घडत आहे याचा अधिक अचूकपणे अभ्यास करण्यासाठी क्लायंटवर अपलोड समस्या पुनरुत्पादित करण्याच्या क्षमतेची देखील मोठी कमतरता होती.

सर्व उपलब्ध आकडेवारी आणि नोंदींचे विश्लेषण आम्हाला काय घडत आहे हे समजून घेण्याच्या जवळ आणले नाही. विशिष्ट कनेक्शन "वाटण्यासाठी" समस्या पुनरुत्पादित करण्याच्या क्षमतेची तीव्र कमतरता होती. शेवटी, विकसकांनी, अनुप्रयोगाची एक विशेष आवृत्ती वापरून, Wi-Fi द्वारे कनेक्ट केलेले असताना चाचणी डिव्हाइसवर समस्यांचे स्थिर पुनरुत्पादन प्राप्त करण्यात व्यवस्थापित केले. तपासात ही मोठी प्रगती होती. Nginx शी कनेक्ट केलेला क्लायंट, जो बॅकएंडला प्रॉक्सी करतो, जो आमचा Java अनुप्रयोग होता.

समस्यांसाठी संवाद असा होता (Nginx प्रॉक्सी बाजूला निश्चित):

क्लायंट: फाइल डाउनलोड करण्याबद्दल माहिती प्राप्त करण्याची विनंती.
जावा सर्व्हर: प्रतिसाद.
क्लायंट: फाइलसह POST.
Java सर्व्हर: त्रुटी.

त्याच वेळी, जावा सर्व्हर लॉगवर लिहितो की क्लायंटकडून 0 बाइट डेटा प्राप्त झाला आहे आणि Nginx प्रॉक्सी लिहिते की विनंतीला 30 सेकंदांपेक्षा जास्त वेळ लागला (30 सेकंद क्लायंट ऍप्लिकेशनची कालबाह्यता आहे). कालबाह्य का आणि 0 बाइट्स का? HTTP दृष्टीकोनातून, सर्वकाही जसे पाहिजे तसे कार्य करते, परंतु फाइलसह POST नेटवर्कमधून अदृश्य होत आहे. शिवाय, ते क्लायंट आणि Nginx दरम्यान अदृश्य होते. Tcpdump सह स्वतःला सज्ज करण्याची वेळ आली आहे! परंतु प्रथम आपल्याला नेटवर्क कॉन्फिगरेशन समजून घेणे आवश्यक आहे. Nginx प्रॉक्सी L3 बॅलन्सरच्या मागे आहे NFware. L3 बॅलन्सरमधून सर्व्हरवर पॅकेट वितरीत करण्यासाठी टनेलिंगचा वापर केला जातो, जे पॅकेटमध्ये त्याचे शीर्षलेख जोडते:

या प्रकरणात, नेटवर्क Vlan-टॅग केलेल्या रहदारीच्या स्वरूपात या सर्व्हरवर येते, जे पॅकेटमध्ये स्वतःचे फील्ड देखील जोडते:

आणि ही रहदारी देखील खंडित केली जाऊ शकते (आम्ही वर्कअराउंडमधील जोखमींचे मूल्यांकन करताना बोललो होतो अशा येणार्‍या खंडित रहदारीची तीच लहान टक्केवारी), जे शीर्षलेखांची सामग्री देखील बदलते:

पुन्हा एकदा: पॅकेट्स Vlan टॅगसह encapsulated आहेत, एक बोगदा सह encapsulated, खंडित. हे कसे होते हे अधिक चांगल्या प्रकारे समजून घेण्यासाठी, क्लायंटपासून Nginx प्रॉक्सीपर्यंत पॅकेट मार्ग शोधूया.

पॅकेट L3 बॅलन्सरपर्यंत पोहोचते. डेटा सेंटरमध्ये योग्य राउटिंगसाठी, पॅकेट एका बोगद्यामध्ये कॅप्स्युलेट केले जाते आणि नेटवर्क कार्डवर पाठवले जाते.
पॅकेट + टनेल हेडर MTU मध्ये बसत नसल्यामुळे, पॅकेट तुकड्यांमध्ये कापले जाते आणि नेटवर्कवर पाठवले जाते.
L3 बॅलन्सर नंतरचे स्विच, पॅकेट प्राप्त करताना, त्यात Vlan टॅग जोडते आणि ते पाठवते.
Nginx प्रॉक्सी समोरील स्विच (पोर्ट सेटिंग्जवर आधारित) पाहतो की सर्व्हरला Vlan-encapsulated पॅकेटची अपेक्षा आहे, म्हणून तो Vlan टॅग न काढता जसे आहे तसे पाठवतो.
लिनक्स वैयक्तिक पॅकेजेसचे तुकडे घेते आणि त्यांना एका मोठ्या पॅकेजमध्ये विलीन करते.
पुढे, पॅकेट Vlan इंटरफेसवर पोहोचते, जिथे त्यातून पहिला स्तर काढला जातो - Vlan encapsulation.
लिनक्स नंतर ते टनेल इंटरफेसवर पाठवते, जिथे त्यातून दुसरा स्तर काढला जातो - टनेल एन्कॅप्सुलेशन.

हे सर्व पॅरामीटर्स tcpdump ला पास करणे ही अडचण आहे.
चला शेवटपासून सुरुवात करूया: क्लायंटकडून स्वच्छ (अनावश्यक शीर्षलेखांशिवाय) आयपी पॅकेट्स आहेत, ज्यामध्ये vlan आणि टनेल एन्कॅप्सुलेशन काढून टाकले आहे?

tcpdump host <ip клиента>

नाही, सर्व्हरवर असे कोणतेही पॅकेज नव्हते. त्यामुळे समस्या आधी असणे आवश्यक आहे. फक्त Vlan encapsulation असलेले कोणतेही पॅकेट काढले आहेत का?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx हे हेक्स फॉरमॅटमधील क्लायंट IP पत्ता आहे.
32:4 — पत्ता आणि फील्डची लांबी ज्यामध्ये SCR IP टनल पॅकेटमध्ये लिहिलेला आहे.

फील्ड अॅड्रेस ब्रूट फोर्सद्वारे निवडणे आवश्यक होते, कारण इंटरनेटवर ते सुमारे 40, 44, 50, 54 लिहितात, परंतु तेथे कोणताही IP पत्ता नव्हता. तुम्ही हेक्समधील पॅकेटपैकी एक देखील पाहू शकता (tcpdump मधील -xx किंवा -XX पॅरामीटर) आणि तुम्हाला माहीत असलेल्या IP पत्त्याची गणना करू शकता.

Vlan आणि Tunnel encapsulation काढल्याशिवाय पॅकेटचे तुकडे आहेत का?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))
ही जादू आपल्याला शेवटच्या एकासह सर्व तुकडे दर्शवेल. कदाचित, समान गोष्ट आयपीद्वारे फिल्टर केली जाऊ शकते, परंतु मी प्रयत्न केला नाही, कारण असे बरेच पॅकेट नाहीत आणि मला आवश्यक असलेले सामान्य प्रवाहात सहज सापडले. ते आले पहा:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0, flags [+], proto IPIP (4), length 1500) 11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500) 33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448 0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A.... 0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8} 0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 [email protected]. 0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@.. 0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W....... 0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....jEx 0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480, flags [none], proto IPIP (4), length 40) 11.11.11.11 > 22.22.22.22: ip-proto-4 0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A.... 0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8} 0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C 0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q 0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

हे एका पॅकेजचे दोन तुकडे आहेत (समान आयडी 53652) एका छायाचित्रासह (पहिल्या पॅकेजमध्ये Exif हा शब्द दिसतो). या स्तरावर पॅकेजेस आहेत या वस्तुस्थितीमुळे, परंतु डंपमध्ये विलीन केलेल्या स्वरूपात नाही, समस्या स्पष्टपणे असेंब्लीसह आहे. शेवटी याचा कागदोपत्री पुरावा आहे!

पॅकेट डीकोडरने बिल्डला प्रतिबंध करणारी कोणतीही समस्या प्रकट केली नाही. येथे प्रयत्न केला: hpd.gasmi.net. सुरुवातीला, जेव्हा तुम्ही तिथे काहीतरी भरण्याचा प्रयत्न करता तेव्हा डिकोडरला पॅकेट स्वरूप आवडत नाही. असे दिसून आले की Srcmac आणि Ethertype मध्ये काही अतिरिक्त दोन ऑक्टेट्स आहेत (तुकड्यांच्या माहितीशी संबंधित नाही). त्यांना काढून टाकल्यानंतर, डीकोडरने काम सुरू केले. तथापि, यात कोणतीही समस्या दिसून आली नाही.
कोणी काहीही म्हणो, त्या Sysctl शिवाय दुसरे काहीही सापडले नाही. स्केल समजून घेण्यासाठी आणि पुढील कृतींवर निर्णय घेण्यासाठी समस्या सर्व्हर ओळखण्याचा मार्ग शोधणे बाकी आहे. आवश्यक काउंटर पटकन पुरेसे सापडले:

netstat -s | grep "packet reassembles failed”

हे OID=1.3.6.1.2.1.4.31.1.1.16.1 अंतर्गत snmpd मध्ये देखील आहे (ipSystemStatsReasmFails).

"IP री-असेंबली अल्गोरिदमद्वारे आढळलेल्या अपयशांची संख्या (कोणत्याही कारणास्तव: कालबाह्य, त्रुटी इ.)."

सर्व्हरच्या गटांपैकी ज्यावर समस्येचा अभ्यास केला गेला होता, दोनवर हे काउंटर वेगाने वाढले, आणखी दोनवर हळूहळू आणि आणखी दोनवर ते अजिबात वाढले नाही. या काउंटरच्या गतिशीलतेची Java सर्व्हरवरील HTTP त्रुटींच्या गतिशीलतेशी तुलना केल्याने परस्परसंबंध दिसून आला. म्हणजेच मीटरचे निरीक्षण करता आले.

समस्यांचे विश्वसनीय सूचक असणे खूप महत्वाचे आहे जेणेकरून Sysctl परत आणणे मदत करते की नाही हे आपण अचूकपणे निर्धारित करू शकता, कारण मागील कथेवरून आम्हाला माहित आहे की हे अनुप्रयोगातून त्वरित समजले जाऊ शकत नाही. हे सूचक वापरकर्त्यांना ते शोधण्यापूर्वी उत्पादनातील सर्व समस्या क्षेत्रे ओळखण्याची परवानगी देईल.
Sysctl ला परत आणल्यानंतर, मॉनिटरिंग त्रुटी थांबल्या, अशा प्रकारे समस्यांचे कारण सिद्ध झाले, तसेच रोलबॅक मदत करते हे देखील सिद्ध झाले.

आम्ही इतर सर्व्हरवरील फ्रॅगमेंटेशन सेटिंग्ज परत आणल्या, जिथे नवीन मॉनिटरिंग कार्यान्वित झाले आणि कुठेतरी आम्ही तुकड्यांसाठी पूर्वीच्या डीफॉल्टपेक्षा अधिक मेमरी वाटप केली (ही UDP आकडेवारी होती, ज्याचे आंशिक नुकसान सामान्य पार्श्वभूमीवर लक्षात येण्यासारखे नव्हते) .

सर्वात महत्वाचे प्रश्न

आमच्या L3 बॅलन्सरवर पॅकेटचे तुकडे का केले जातात? वापरकर्त्यांकडून बॅलन्सरपर्यंत येणारी बहुतेक पॅकेट SYN आणि ACK आहेत. या पॅकेजेसचे आकार लहान आहेत. परंतु अशा पॅकेट्सचा वाटा खूप मोठा असल्याने, त्यांच्या पार्श्‍वभूमीवर आम्हाला मोठ्या पॅकेटची उपस्थिती लक्षात आली नाही जी तुकडे होऊ लागली.

कारण एक तुटलेली कॉन्फिगरेशन स्क्रिप्ट होती advmss Vlan इंटरफेससह सर्व्हरवर (त्यावेळी उत्पादनात टॅग केलेले रहदारी असलेले खूप कमी सर्व्हर होते). Advmss आम्हाला क्लायंटला माहिती पोहोचवण्याची परवानगी देते की आमच्या दिशेने असलेल्या पॅकेट्सचा आकार लहान असावा जेणेकरुन त्यांना बोगदा शीर्षलेख जोडल्यानंतर ते खंडित होऊ नयेत.

Sysctl रोलबॅकने का मदत केली नाही, परंतु रीबूट का केले? Sysctl रोल बॅक केल्याने पॅकेजेस विलीन करण्यासाठी उपलब्ध मेमरीचे प्रमाण बदलले. त्याच वेळी, तुकड्यांच्या मेमरी ओव्हरफ्लोच्या वस्तुस्थितीमुळे कनेक्शनची गती कमी झाली, ज्यामुळे तुकड्यांना रांगेत बराच वेळ उशीर झाला. म्हणजेच, प्रक्रिया चक्रात गेली.
रीबूटने मेमरी साफ केली आणि सर्वकाही क्रमाने परत आले.

वर्कअराउंडशिवाय करणे शक्य होते का? होय, परंतु आक्रमण झाल्यास वापरकर्त्यांना सेवेशिवाय सोडण्याचा उच्च धोका आहे. अर्थात, वर्कअराउंडच्या वापरामुळे विविध समस्या उद्भवल्या, ज्यामध्ये वापरकर्त्यांसाठी एक सेवा मंदावली आहे, परंतु तरीही आम्हाला विश्वास आहे की कृती न्याय्य होत्या.

आंद्रे टिमोफीव्ह यांचे खूप आभार (atimofeyev) तपास करण्यात मदत करण्यासाठी, तसेच अलेक्सी क्रेनेव्ह (devicex) - सर्व्हरवर सेंटोस आणि कर्नल अद्यतनित करण्याच्या टायटॅनिक कार्यासाठी. एक अशी प्रक्रिया जी या प्रकरणात सुरुवातीपासून अनेक वेळा सुरू करावी लागली, म्हणूनच ती अनेक महिने खेचली गेली.

स्त्रोत: www.habr.com

कामाच्या फेऱ्या आणणाऱ्या असुरक्षिततेपासून सावध रहा. भाग 1: FragmentSmack/SegmentSmack