क्या मैंने हमला किया या सिर्फ बेवकूफ?


11

मैं कई OpenVZ कंटेनरों के साथ डेबियन निचोड़ का उपयोग करके एक सर्वर चलाता हूं। कंटेनर ज्यादातर स्क्वीज़, कुछ लेनी, और कुछ पहले से ही व्हीजी के लिए अपडेट होते हैं। मेजबान iptables और DHCP से परे ऐसा नहीं करता है। फ़ाइल सर्वर, परदे के पीछे, मेल सर्वर, kerberos, LDAP, ... सभी कंटेनर में रखे जाते हैं। यह प्रणाली कई वर्षों तक स्थिर रही और एक वर्ष से अधिक कुछ फ़ायरवॉल नियमों को छोड़कर कोई बड़ा बदलाव नहीं हुआ।

2 दिन पहले अचानक सिस्टम क्रैश हो गया। मुझे इसे फिर से लाने में बहुत सारी समस्याएं थीं। पहले तो यह मुझे ssh के माध्यम से लॉग इन नहीं करने देता था। रूट लॉगिन 'आप मौजूद नहीं है' से इनकार कर दिया था। चले जाओ!' स्थानीय लॉगिन ठीक था। कुछ समय बाद ssh ने फिर से काम किया। संयोग से मैंने बैश इतिहास से लाइन का फिर से उपयोग नहीं किया, लेकिन एक नई कमांड टाइप की, जिसे ट्राइ किए गए चेक लाइन के समान था, जो क्रैश से पहले काम नहीं करता था।

तब सिस्टम चला, लेकिन SYN ACK के बाद अधिकांश प्रोटोकॉल पर नेटवर्क ट्रैफ़िक अवरुद्ध हो गया था। डीएनएस, टेलनेट और एसएसएच ठीक थे, लेकिन बाकी एक गड़बड़ था। कुछ घंटों के बाद अंधेरे में मछली पकड़ने और फ़ायरवॉल को फिर से लोड करने के बाद कई बार अचानक सब कुछ फिर से ठीक हो गया। मुझे लॉग में कुछ भी संदिग्ध नहीं मिला - लेकिन मैं एक फोरेंसिक विशेषज्ञ नहीं हूं।

आज कंटेनर कोटे के कारण LDAP से संपर्क करने के लिए फ़ाइल सर्वर का nscd सॉकेट से बाहर चला गया। ऐसा कुछ जो पहले कभी नहीं हुआ। मैंने smbd द्वारा दावा किए गए सॉकेट्स का बहुत (> 30) भी देखा।

/ var / log / संदेश syslog के समान दिखाई देते थे । /var/log/kern.log के पास क्रैश कारणों पर यह अतिरिक्त जानकारी थी:

/var/log/kern.log:2950:Sep 19 10:46:57 asgard kernel: [6529441.320086] INFO: task sendmail:32181 blocked for more than 120 seconds.
/var/log/kern.log:2982:Sep 19 10:48:57 asgard kernel: [6529561.324525] INFO: task kdmflush:1932 blocked for more than 120 seconds.
/var/log/kern.log:3005:Sep 19 10:48:57 asgard kernel: [6529561.324694] INFO: task xfssyncd:10162 blocked for more than 120 seconds.
/var/log/kern.log:3027:Sep 19 10:48:57 asgard kernel: [6529561.324934] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:3060:Sep 19 10:49:51 asgard kernel: [6529561.325129] INFO: task imapd:31749 blocked for more than 120 seconds.
/var/log/kern.log:3084:Sep 19 10:49:51 asgard kernel: [6529561.325248] INFO: task cleanup:32194 blocked for more than 120 seconds.
/var/log/kern.log:3106:Sep 19 10:50:57 asgard kernel: [6529681.324028] INFO: task flush-253:3:3216 blocked for more than 120 seconds.
/var/log/kern.log:3142:Sep 19 10:50:57 asgard kernel: [6529681.324224] INFO: task kjournald:6859 blocked for more than 120 seconds.
/var/log/kern.log:3166:Sep 19 10:50:57 asgard kernel: [6529681.324366] INFO: task syslogd:11720 blocked for more than 120 seconds.
/var/log/kern.log:3198:Sep 19 10:50:57 asgard kernel: [6529681.324574] INFO: task postgres:16827 blocked for more than 120 seconds.
/var/log/kern.log:7152:Sep 19 19:29:41 asgard kernel: [ 1440.617090] INFO: task sendmail:11892 blocked for more than 120 seconds.

मशीन को रिबूट करने के बाद अंतिम 'सेंडमेल' क्रैश हो गया था। तब से इस तरह की और कोई घटना नहीं घटी। 'इमापेड' और 'पोस्टग्रेज' निश्चित रूप से विभिन्न कंटेनरों में चलते हैं।

ठीक है, मुझे कोई धूम्रपान बंदूक नहीं दिख रही है, लेकिन मैं शायद अंधा हूं। ज्ञात / प्रकल्पित अच्छे बैकअप से सिस्टम सेट करने पर मुझे बहुत अच्छे कारणों के बिना इसे आज़माने में बहुत कठिनाई होगी।

मैं आगे क्या जाँच करने के लिए किसी भी सलाह की सराहना करेंगे।

आपकी सहायता के लिए धन्यवाद।

अपडेट : दुर्घटना के कुछ पूर्व-कर्सर की खोज में अधिक प्रयास करना जो मुझे निम्नलिखित में मिला है:

Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (10490->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:09:56 asgard ntop[7965]:   **WARNING** packet truncated (17442->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (11650->8232)
Sep 19 10:11:02 asgard ntop[7965]:   **WARNING** packet truncated (10202->8232)
Sep 19 10:11:29 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:13:27 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)
Sep 19 10:20:33 asgard ntop[7965]:   **WARNING** packet truncated (8754->8232)

मुझे पता है कि यह अनियंत्रित माना जाता है, लेकिन यह एक दुर्लभ घटना है। पैकेट ट्रंकेशन केवल दूसरे क्रैश के दिन ही मौजूद होता है। सभी उपलब्ध लॉग फ़ाइलों में कहीं और नहीं।

जवाबों:


2

यह DoS की तरह दिखता है, सबसे अधिक संभावना नए कॉर्क से या समझौता किए गए कंटेनर में से एक के अंदर से होती है।

मैं vmstat में दिखूंगा, इसे हर 5 सेकंड में लगातार चलाएं: vmstat 5 और संसाधन खर्च किए जाने पर ध्यान दें। आप स्क्रीन का उपयोग कर सकते हैं और vmstat 60 (प्रत्येक मिनट) को एक अलग विंडो में चला सकते हैं - इस तरह आप स्पाइक्स को नोटिस कर सकते हैं जब वे अधिक समय तक होते हैं।

इस स्थिति में उच्च / स्पाइकिंग सिस्टम सीपीयू (एसई), उच्च संदर्भ स्विच रेट (सीएस) और उच्च आईओ (यह नेटवर्क और डिस्क दोनों दिखाता है) DoS को इंगित करेगा:

$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0   9584   6820 132432  23256    1    1   136    12    1    1 83  1 15  0  0
 0  0   9584   6696 132432  23256    0    0     0     0   20   32  0  0 99  0  1

उसी समय होस्ट पर नेटवर्क ट्रैफ़िक की निगरानी करें, मैं ntop की सिफारिश करता हूं, अर्थात:

$ nload -t 10000 -u H eth0

0

यह डिस्क I / O त्रुटि जैसा दिखता है। Fsck चलाएँ और त्रुटियों की जाँच करें।


मैं उस के लिए डाउनटाइम अनुसूची करने की कोशिश करेंगे। हालाँकि, कहीं भी I / O डिस्क विफलता संबंधित लॉग नहीं हैं। या आपने कोई देखा?
लार्स हैंके

0

हो सकता है कि आपके पास कोई फ़ाइल सिस्टम त्रुटियां न हों, लेकिन मुझे यकीन है कि आप अपनी लॉग इन चेतावनियों को देख सकते हैं, क्योंकि आपके पास D राज्य में कई प्रक्रियाएँ (I / O की प्रतीक्षा कर रही हैं) और कर्नेल आपको लंबे प्रतीक्षा की सूचना दे रहा है।


मुझे लगता है कि यह मामला रहा है। लेकिन क्यों? सामान्य परिस्थितियों में डी राज्य में कोई प्रक्रिया नहीं होती है। यदि वास्तव में नेटवर्क नीचे चला गया, तो यह समझा सकता है। लेकिन यह केवल कुछ सेवाओं के लिए नीचे क्यों जाएगा? वह स्थिति रिबूट से क्यों बची? और यह फिर से क्यों आया?
लार्स हेंके

0

त्रुटि इंगित करती है कि डिस्क तक पहुंचने के लिए आपकी प्रक्रियाएं बहुत लंबी (120 सेकंड) की प्रतीक्षा कर रही हैं; यह अत्यधिक भीड़ वाले सर्वरों पर होता है जहां डिस्क प्रक्रियाओं पर प्रतिक्रिया करने के लिए बहुत व्यस्त हैं।

आप vmstat के तहत "प्रतीक्षा" की जाँच करके सुनिश्चित कर सकते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.