सवाल मैं एक समझौता सर्वर से कैसे निपटूं?


यह है एक कैननिकल प्रश्न सर्वर सुरक्षा के बारे में - उल्लंघन घटनाओं का जवाब देना (हैकिंग)
  यह भी देखें:

कैननिकल संस्करण
मुझे संदेह है कि मेरे एक या अधिक सर्वरों को हैकर, वायरस या अन्य तंत्र से समझौता किया गया है:

  • मेरे पहले कदम क्या हैं? जब मैं साइट पर पहुंचूं, तो क्या मुझे सर्वर को डिस्कनेक्ट करना चाहिए, "साक्ष्य" को संरक्षित करना चाहिए, क्या अन्य प्रारंभिक विचार हैं?
  • मैं ऑनलाइन सेवाओं को वापस पाने के बारे में कैसे जा सकता हूं?
  • मैं एक ही चीज़ को तुरंत फिर से कैसे रोकूं?
  • क्या इस घटना से सीखने के लिए सर्वोत्तम प्रथाएं या पद्धतियां हैं?
  • अगर मैं एक घटना प्रतिक्रिया योजना को एक साथ रखना चाहता था, तो मैं कहां से शुरू करूंगा? क्या यह मेरी आपदा रिकवरी या बिजनेस कंटिन्यूटी प्लानिंग का हिस्सा होना चाहिए?

मूल संस्करण 

2011/01/02 - मैं 9.30 बजे काम में जा रहा हूं। रविवार को क्योंकि हमारे सर्वर से किसी भी तरह से समझौता किया गया है और जिसके परिणामस्वरूप ए    डॉस हमारे प्रदाता पर हमला। सर्वर इंटरनेट तक पहुंच   बंद कर दिया गया है जिसका मतलब है कि हमारी क्लाइंट साइट्स के 5-600 से अधिक अब हैं   नीचे। अब यह एक एफ़टीपी हैक, या कोड में कुछ कमजोरी हो सकती है   कहीं। मुझे यकीन नहीं है जब तक मैं वहां नहीं जाता।

मैं इसे जल्दी से कैसे ट्रैक कर सकता हूं? हम पूरी तरह से अंदर हैं   मुकदमेबाजी अगर मुझे सर्वर वापस ASAP नहीं मिलता है। कोई मदद है   की सराहना की। हम ओपन एसयूएसई 11.0 चला रहे हैं।


2011/01/03 - मदद के लिए सभी को धन्यवाद। सौभाग्य से मैं इस सर्वर के लिए जिम्मेदार एकमात्र व्यक्ति नहीं था, बस निकटतम। हम संभाल लिया   इस समस्या को हल करने के लिए, हालांकि यह कई अन्य लोगों पर लागू नहीं हो सकता है   अलग स्थिति मैं विस्तार से बताऊंगा कि हमने क्या किया।

हमने नेट से सर्वर को अनप्लग किया। यह प्रदर्शन कर रहा था (कोशिश कर रहा था   प्रदर्शन) इंडोनेशिया में किसी अन्य सर्वर पर सेवा हमले का एक अस्वीकार,   और दोषी पार्टी भी वहां आधारित थी।

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

तब हम उस अपमानजनक फ़ाइल की पहचान करने में सक्षम थे जो अंदर था   एक के भीतर अपलोड छवियों फ़ोल्डर ZenCart वेबसाइट।

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

इसका मतलब था कि किसी भी फाइल को अपलोड किया जा सकता है, जिसमें एक PHP फ़ाइल भी शामिल है   आक्रमण। हमने संक्रमित ज़ेनकार्ट के साथ भेद्यता को सुरक्षित किया   साइट, और अपमानजनक फ़ाइलों को हटा दिया।

काम किया गया था, और मैं 2 एएम के लिए घर था।


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


578
2018-01-02 21:31


मूल


मुझे पता है कि आप कैसा महसूस करते हैं - हम इस साइट पर "सहायक" हैकर्स के साथ बहुत भाग्यशाली रहे हैं, जहां वे हमें बताते हैं कि उन्होंने क्या किया है! मैं इस प्रश्न के महान जवाब की उम्मीद कर रहा हूं, बस अगर हमें भविष्य में "सहायक नहीं" मेहमान मिलते हैं। - Jarrod Dixon♦
मदद करने के लिए एक पेशेवर को बुलाओ! - marcog
मैं स्मार्ट-एसी या असम्बद्ध नहीं होना चाहता (मैं न तो हूं), और निश्चित रूप से मैं आपकी स्थिति के विवरण से अनजान हूं, लेकिन यदि आप 500-600 साइट सेटअप के लिए जिम्मेदार एकमात्र व्यक्ति हैं, तो हो सकता है यह सर्वर कैसे चल रहा है में एक मौलिक दोष बनें। कुछ कंपनियां समर्पित सिसडमिन को रोजगार देती हैं जो पूरे दिन कुछ और नहीं करती है लेकिन सर्वर बनाए रखती है - एक कार्य जो है नहीं स्वचालित रूप से प्रोग्रामर के दायरे में, भले ही ऐसा लगता है। शायद संकट खत्म हो जाने पर विचार करने योग्य कुछ है। वैसे भी, अभी स्थिति में हाथ मिलाकर स्थिति में सबसे अच्छा भाग्य। - Pekka 웃
यह जरूरी नहीं है कि आपके पास एक पूर्ण उड़ा हुआ कर्नेल रूट किट है और आपके रूट पासवर्ड से समझौता किया गया है। इसकी संभवतः सिर्फ एक स्नीकी बैश / पर्ल स्क्रिप्ट है, और इसके बारे में गाना बजानेवालों के बावजूद इसे बनाने के बिना इसे साफ करना संभव है ... serverfault.com/questions/639699/... - Hayden Thring


जवाब:


आपने यहां जो पोस्ट किया है उससे विशिष्ट सलाह देना मुश्किल है, लेकिन मेरे पास कुछ साल पहले लिखा गया एक पोस्ट के आधार पर कुछ सामान्य सलाह है जब मुझे अभी भी ब्लॉग पर परेशान किया जा सकता है।

घबराओ मत

सबसे पहले चीजें, घुसपैठ से पहले किए गए बैकअप से आपके सिस्टम को बहाल करने के अलावा कोई "त्वरित समाधान" नहीं है, और इसमें कम से कम दो समस्याएं हैं।

  1. घुसपैठ कब हुआ यह तय करना मुश्किल है।
  2. यह आपको "छेद" को बंद करने में मदद नहीं करता है जो उन्हें पिछली बार तोड़ने की अनुमति देता है, न ही किसी भी "डेटा चोरी" के परिणामों से निपटता है।

हैकर्स के पीड़ितों द्वारा अपने वेब सर्वर में तोड़ने से बार-बार पूछा जा रहा है। जवाब बहुत ही कम बदलते हैं, लेकिन लोग सवाल पूछते रहते हैं। मुझे यकीन नहीं है क्यों। शायद लोग मदद के लिए खोज करते समय देखे गए उत्तरों को पसंद नहीं करते हैं, या वे किसी को सलाह नहीं दे सकते कि वे उन्हें सलाह दें। या शायद लोग इस प्रश्न का उत्तर पढ़ते हैं और 5% पर बहुत अधिक ध्यान केंद्रित करते हैं कि उनका मामला विशेष क्यों है और वे उन उत्तरों से अलग हैं जो वे ऑनलाइन पा सकते हैं और 9 5% प्रश्न और उत्तर को याद करते हैं जहां उनका मामला पर्याप्त है जैसा कि वे ऑनलाइन पढ़ते हैं।

यह मुझे जानकारी के पहले महत्वपूर्ण गले में लाता है। मैं वास्तव में सराहना करता हूं कि आप एक विशेष अद्वितीय हिमपात का मैदान हैं। मैं सराहना करता हूं कि आपकी वेबसाइट भी है, क्योंकि यह आपके और आपके व्यवसाय का प्रतिबिंब है या कम से कम, नियोक्ता की तरफ से आपका कड़ी मेहनत है। लेकिन बाहर की ओर किसी को देखने के लिए, क्या कोई कंप्यूटर सुरक्षा व्यक्ति समस्या को देख रहा है ताकि आप या यहां तक ​​कि हमलावर की भी मदद कर सकें, यह बहुत संभावना है कि आपकी समस्या कम से कम 9 5% अन्य सभी मामलों के समान होगी कभी देखा

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

आपने अभी पाया है कि आपके सर्वर को हैक किया गया है। अब क्या?

घबराओ मत। पूरी तरह से जल्दबाजी में कार्य नहीं करते हैं, और पूरी तरह से कोशिश नहीं करते हैं और नाटक करते हैं और काम नहीं करते हैं।

सबसे पहले: समझें कि आपदा पहले ही हो चुकी है। यह अस्वीकार करने का समय नहीं है; यह स्वीकार करने का समय है कि क्या हुआ है, इसके बारे में यथार्थवादी होने के लिए, और प्रभाव के परिणामों को प्रबंधित करने के लिए कदम उठाने का समय है।

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

समस्या को पहले से ही बदतर होने से रोकें:

  1. सबसे पहले आपको जो करना चाहिए वह प्रभावित सिस्टम को इंटरनेट से डिस्कनेक्ट करना है। आपके पास जो भी अन्य समस्याएं हैं, वेब से जुड़े सिस्टम को छोड़कर हमले को जारी रखने की अनुमति होगी। मेरा मतलब यह सचमुच है; किसी को शारीरिक रूप से सर्वर पर जाने और नेटवर्क केबल्स को अनप्लग करने के लिए प्राप्त करें यदि वह ऐसा होता है, लेकिन पीड़ित को किसी और चीज करने से पहले अपने मगर्स से डिस्कनेक्ट करें।
  2. समझौता किए गए सिस्टम के समान नेटवर्क पर मौजूद सभी कंप्यूटरों पर सभी खातों के लिए अपने सभी पासवर्ड बदलें। सच में नहीं। सभी खाते सभी कंप्यूटर हाँ, आप सही हैं, यह अधिक हो सकता है; दूसरी ओर, यह नहीं हो सकता है। आप किसी भी तरह से नहीं जानते, क्या आप?
  3. अपने अन्य सिस्टम की जांच करें। अन्य इंटरनेट सामना करने वाली सेवाओं, और उन लोगों के लिए विशेष ध्यान दें जो वित्तीय या अन्य व्यावसायिक रूप से संवेदनशील डेटा रखते हैं।
  4. यदि सिस्टम किसी के व्यक्तिगत डेटा को रखता है, तो तुरंत डेटा सुरक्षा के लिए जिम्मेदार व्यक्ति को सूचित करें (यदि यह आप नहीं है) और यूआरजीई एक पूर्ण प्रकटीकरण है। मुझे पता है कि यह मुश्किल है। मुझे पता है कि यह चोट पहुंचाने वाला है। मुझे पता है कि कई व्यवसाय कार्पेट के तहत इस तरह की समस्या को खत्म करना चाहते हैं लेकिन व्यापार को इससे निपटना होगा - और किसी भी और सभी प्रासंगिक गोपनीयता कानूनों पर नजर रखने की जरूरत है।

हालांकि, आपके ग्राहकों को परेशान होने के कारण आप उन्हें किसी समस्या के बारे में बता सकते हैं, यदि आप उन्हें नहीं बताते हैं तो वे बहुत अधिक परेशान होंगे, और वे केवल क्रेडिट कार्ड के विवरण का उपयोग करके 8,000 डॉलर के सामान का शुल्क लेने के बाद खुद के लिए खोज लेंगे आपकी साइट से चुरा लिया।

याद रखें मैंने पहले क्या कहा था? बुरी चीज पहले से ही हो चुकी है। एकमात्र सवाल यह है कि आप इससे कितना अच्छा व्यवहार करते हैं।

पूरी तरह से समस्या को समझें:

  1. इस चरण को पूरी तरह से पूरा होने तक प्रभावित सिस्टम को वापस ऑनलाइन न रखें, जब तक कि आप उस व्यक्ति बनना न चाहें जिसकी पोस्ट वास्तव में इस लेख को लिखने का निर्णय लेती है। मैं उस पोस्ट से लिंक नहीं कर रहा हूं ताकि लोग सस्ते हंसी प्राप्त कर सकें, लेकिन असली त्रासदी तब होती है जब लोग अपनी गलतियों से सीखने में असफल होते हैं।
  2. यह समझने के लिए 'हमला' सिस्टम की जांच करें कि आपकी सुरक्षा समझौता करने में हमले कैसे सफल हुए। यह पता लगाने के लिए हर संभव प्रयास करें कि हमले "कहाँ से आए" थे, ताकि आप समझ सकें कि आपके पास कौन सी समस्याएं हैं और भविष्य में आपके सिस्टम को सुरक्षित बनाने के लिए संबोधित करने की आवश्यकता है।
  3. 'हमला' सिस्टम फिर से जांचें, इस बार यह समझने के लिए कि हमले कहाँ गए थे, ताकि आप समझ सकें कि हमले में किस प्रणाली से समझौता किया गया था। सुनिश्चित करें कि आप किसी भी पॉइंटर्स का पालन करें जो सुझाव देते हैं कि समझौता सिस्टम आपके सिस्टम पर हमला करने के लिए एक springboard बन सकता है।
  4. किसी भी और सभी हमलों में इस्तेमाल किए गए "प्रवेश द्वार" को सुनिश्चित करें, ताकि आप उन्हें ठीक से बंद कर सकें। (उदाहरण के लिए यदि आपके सिस्टम को एसक्यूएल इंजेक्शन हमले से समझौता किया गया था, तो न केवल आपको उस कोड की विशेष त्रुटिपूर्ण रेखा को बंद करने की आवश्यकता है जिसे उन्होंने तोड़ दिया था, आप उसी प्रकार की गलती को देखने के लिए अपने सभी कोड का ऑडिट करना चाहेंगे कहीं और बनाया गया था)।
  5. समझें कि एक से अधिक दोषों के कारण हमले सफल हो सकते हैं। अक्सर, हमले सिस्टम में एक प्रमुख बग खोजने के माध्यम से सफल नहीं होते हैं, बल्कि सिस्टम को समझौता करने के लिए कई मुद्दों (कभी-कभी मामूली और तुच्छ) स्वयं को स्ट्रिंग करके सफल होते हैं। उदाहरण के लिए, डेटाबेस सर्वर पर कमांड भेजने के लिए एसक्यूएल इंजेक्शन हमलों का उपयोग करके, उस वेबसाइट / एप्लिकेशन को खोजना जिसे आप हमला कर रहे हैं, एक प्रशासनिक उपयोगकर्ता के संदर्भ में चल रहा है और दूसरे खाते के समझौता करने के लिए एक चरण-पत्थर के रूप में उस खाते के अधिकारों का उपयोग कर रहा है एक प्रणाली। या हैकर्स इसे कॉल करना पसंद करते हैं: "कार्यालय में एक और दिन आम गलतियों का लाभ लेते हैं"।

क्यों न केवल शोषण या रूटकिट को "मरम्मत" करें और सिस्टम को ऑनलाइन वापस रखें?

इस तरह की परिस्थितियों में समस्या यह है कि आपके पास उस प्रणाली का नियंत्रण नहीं है। यह अब आपका कंप्यूटर नहीं है।

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

वसूली के लिए एक योजना बनाएं और अपनी वेबसाइट को ऑनलाइन वापस लाएं और इसके साथ चिपके रहें:

कोई भी लंबे समय तक ऑफ़लाइन होना नहीं चाहता है। वह दे दिया गया। यदि यह वेबसाइट राजस्व उत्पन्न करने वाली तंत्र है तो इसे तुरंत ऑनलाइन लाने का दबाव तीव्र होगा। भले ही हिस्सेदारी पर एकमात्र चीज आपकी / आपकी कंपनी की प्रतिष्ठा है, फिर भी यह चीजों को जल्दी से वापस रखने के लिए बहुत दबाव पैदा कर रहा है।

हालांकि, ऑनलाइन वापस जाने के लिए प्रलोभन में न आएं। इसके बजाय जितनी जल्दी हो सके समस्या को समझने के लिए और ऑनलाइन वापस जाने से पहले इसे हल करने के लिए जितना तेज़ हो सके, अन्यथा आप निश्चित रूप से एक बार फिर घुसपैठ के शिकार हो जाएंगे, और याद रखें, "एक बार हैक करने के लिए दुर्भाग्य के रूप में वर्गीकृत किया जा सकता है; सीधे बाद में हैक करने के लिए लापरवाही की तरह दिखता है "(ऑस्कर वाइल्ड के लिए माफ़ी के साथ)।

  1. मुझे लगता है कि आप इस मुद्दे को शुरू करने से पहले सभी मुद्दों को समझ चुके हैं जो पहले घुसपैठ में सफल घुसपैठ का कारण बन गए हैं। मैं मामले को ओवरस्टेट नहीं करना चाहता हूं लेकिन अगर आपने पहले ऐसा नहीं किया है तो आपको वास्तव में आवश्यकता है। माफ़ कीजिये।
  2. कभी ब्लैकमेल / सुरक्षा पैसे का भुगतान न करें। यह एक आसान चिह्न का संकेत है और आप नहीं चाहते कि वह वाक्यांश कभी भी आपको वर्णन करने के लिए उपयोग किया जाए।
  3. एक पूर्ण पुनर्निर्माण के बिना एक ही सर्वर को वापस ऑनलाइन रखने का लुत्फ उठाएं। यह एक नया बॉक्स बनाने के लिए बहुत तेज़ होना चाहिए या पुराना हार्डवेयर पर "क्लीन से सर्वर को क्लीन करें" और पुराने सिस्टम के हर एक कोने को ऑडिट करना होगा ताकि यह सुनिश्चित किया जा सके कि इसे वापस रखने से पहले साफ है ऑनलाइन फिर से। यदि आप इससे असहमत हैं तो शायद आपको नहीं पता कि यह सुनिश्चित करने के लिए वास्तव में क्या मतलब है कि सिस्टम पूरी तरह से साफ हो गया है, या आपकी वेबसाइट परिनियोजन प्रक्रियाएं अपवित्र गड़बड़ हैं। संभवतः आपके पास अपनी साइट के बैकअप और परीक्षण तैनाती हैं जिनका उपयोग आप लाइव साइट बनाने के लिए कर सकते हैं, और यदि आप नहीं हैं तो हैक किया जा रहा है आपकी सबसे बड़ी समस्या नहीं है।
  4. हैक के समय सिस्टम पर "लाइव" डेटा का पुन: उपयोग करने के बारे में बहुत सावधान रहें। मैं यह नहीं कहूंगा कि "कभी ऐसा न करें" क्योंकि आप मुझे केवल अनदेखा करेंगे, लेकिन स्पष्ट रूप से मुझे लगता है कि आपको डेटा को रखने के परिणामों पर विचार करने की आवश्यकता है जब आप जानते हैं कि आप इसकी ईमानदारी की गारंटी नहीं दे सकते। आदर्श रूप में, आपको घुसपैठ से पहले किए गए बैकअप से इसे पुनर्स्थापित करना चाहिए। यदि आप ऐसा नहीं कर सकते हैं या नहीं करेंगे, तो आपको उस डेटा से बहुत सावधान रहना चाहिए क्योंकि यह दंडित है। यदि आपको यह डेटा सीधे आपके बजाय ग्राहकों या साइट आगंतुकों से संबंधित है, तो आपको विशेष रूप से दूसरों के परिणामों से अवगत होना चाहिए।
  5. ध्यान से सिस्टम की निगरानी करें। आपको इसे भविष्य में एक चल रही प्रक्रिया के रूप में करने के लिए हल करना चाहिए (नीचे अधिक) लेकिन आप अपनी साइट को ऑनलाइन वापस आने के तुरंत बाद सावधानी बरतने के लिए अतिरिक्त दर्द लेते हैं। घुसपैठियां लगभग निश्चित रूप से वापस आ जाएंगी, और यदि आप उन्हें फिर से तोड़ने की कोशिश कर सकते हैं तो आप निश्चित रूप से जल्दी से देख पाएंगे यदि आपने वास्तव में उन सभी छेदों को बंद कर दिया है जो उन्होंने स्वयं के लिए किए गए किसी भी प्लस से पहले बंद कर दिए हैं, और आप उपयोगी हो सकते हैं जानकारी जो आप अपने स्थानीय कानून प्रवर्तन पर भेज सकते हैं।

भविष्य में जोखिम को कम करना।

पहली बात यह है कि आपको समझने की आवश्यकता है कि सुरक्षा एक ऐसी प्रक्रिया है जिसे आपको इंटरनेट-फेसिंग सिस्टम को डिज़ाइन करने, तैनात करने और बनाए रखने के पूरे जीवन चक्र में आवेदन करना होता है, ऐसा कुछ नहीं जो आप अपने कोड पर कुछ परतों को बाद में सस्ता कर सकते हैं रंग। उचित रूप से सुरक्षित होने के लिए, इस सेवा के एक प्रमुख लक्ष्यों में से एक के रूप में शुरुआत में शुरुआत से एक सेवा और आवेदन को डिजाइन करने की आवश्यकता है। मुझे एहसास है कि यह उबाऊ है और आपने इसे पहले सुना है और मैं वेब पर बीटा स्थिति में अपनी बीटा वेब 2.0 (बीटा) सेवा प्राप्त करने के दबाव वाले व्यक्ति को "एहसास नहीं कर रहा हूं", लेकिन तथ्य यह है कि यह रहता है दोहराया जा रहा है क्योंकि यह पहली बार सच था जब यह कहा गया था और यह अभी तक झूठ नहीं बन गया है।

आप जोखिम को खत्म नहीं कर सकते हैं। आपको ऐसा करने की कोशिश भी नहीं करनी चाहिए। आपको क्या करना चाहिए, यह समझना है कि कौन से सुरक्षा जोखिम आपके लिए महत्वपूर्ण हैं, और जोखिम के प्रभाव और जोखिम की संभावना दोनों को प्रबंधित करने और उन्हें कम करने के तरीके को समझना है।

हमले की संभावना को कम करने की संभावना को कम करने के लिए आप क्या कदम उठा सकते हैं?

उदाहरण के लिए:

  1. क्या वह दोष था जिसने लोगों को आपकी साइट में विक्रेता कोड में एक ज्ञात बग तोड़ने की इजाजत दी, जिसके लिए एक पैच उपलब्ध था? यदि हां, तो क्या आपको अपने इंटरनेट-फेस सर्वर पर एप्लिकेशन को पैच करने के तरीके के बारे में फिर से विचार करने की आवश्यकता है?
  2. क्या वह दोष था जिसने लोगों को आपकी साइट में विक्रेता कोड में अज्ञात बग को तोड़ने की इजाजत दी, जिसके लिए एक पैच उपलब्ध नहीं था? मैं निश्चित रूप से बदलते आपूर्तिकर्ताओं की वकालत नहीं करता जब भी ऐसा कुछ आपको काटता है क्योंकि उन्हें सभी की समस्याएं होती हैं और यदि आप इस दृष्टिकोण को लेते हैं तो आप एक वर्ष में प्लेटफॉर्म से बाहर निकल जाएंगे। हालांकि, अगर कोई सिस्टम आपको लगातार नीचे जाने देता है तो आपको या तो कुछ अधिक मजबूत या कम से कम, अपने सिस्टम को पुन: आर्किटेक्ट करना चाहिए ताकि कमजोर घटक कपास ऊन में लपेट जाएं और शत्रुतापूर्ण आंखों से जितनी दूर हो सके।
  3. क्या आपके द्वारा विकसित कोड में एक बग दोष था (या आपके लिए काम कर रहे ठेकेदार)? यदि हां, तो क्या आपको अपनी लाइव साइट पर तैनाती के लिए कोड को स्वीकृति देने के तरीके के बारे में फिर से विचार करने की आवश्यकता है? क्या बग को एक बेहतर परीक्षण प्रणाली के साथ पकड़ा जा सकता है, या आपके कोडिंग "मानक" में परिवर्तन के साथ (उदाहरण के लिए, जबकि तकनीक पैनासिया नहीं है, आप अच्छी तरह से प्रलेखित कोडिंग तकनीकों का उपयोग कर सफल एसक्यूएल इंजेक्शन हमले की संभावना को कम कर सकते हैं )।
  4. सर्वर या एप्लिकेशन सॉफ़्टवेयर को कैसे तैनात किया गया था, इस समस्या के कारण दोष था? यदि हां, तो क्या आप संभवतः सर्वर बनाने और तैनात करने के लिए स्वचालित प्रक्रियाओं का उपयोग कर रहे हैं? ये आपके सभी सर्वरों पर एक सतत "बेसलाइन" स्थिति बनाए रखने में एक बड़ी मदद है, प्रत्येक पर कस्टम कार्य की मात्रा को कम करने और इसलिए गलती के अवसर को कम करने के लिए उम्मीद है। कोड परिनियोजन के साथ ही चला जाता है - यदि आपको अपने वेब ऐप के नवीनतम संस्करण को तैनात करने के लिए कुछ "विशेष" करने की आवश्यकता है तो इसे स्वचालित करने के लिए कड़ी मेहनत करें और सुनिश्चित करें कि यह हमेशा एक सतत तरीके से किया जाता है।
  5. क्या आपके सिस्टम की बेहतर निगरानी के साथ घुसपैठ पहले पकड़ा जा सकता है? बेशक, 24 घंटे की निगरानी या आपके कर्मचारियों के लिए "ऑन कॉल" प्रणाली लागत प्रभावी नहीं हो सकती है, लेकिन वहां ऐसी कंपनियां हैं जो आपके लिए आपकी वेब फेस सेवाओं की निगरानी कर सकती हैं और किसी समस्या की स्थिति में आपको सतर्क कर सकती हैं। आप तय कर सकते हैं कि आप इसे बर्दाश्त नहीं कर सकते हैं या इसकी आवश्यकता नहीं है और यह ठीक है ... इसे ध्यान में रखें।
  6. ट्रिपवायर और नेसस जैसे औजारों का उपयोग करें जहां उपयुक्त हो - लेकिन इन्हें अंधाधुंध रूप से उपयोग न करें क्योंकि मैंने ऐसा कहा था। अपने पर्यावरण के लिए उपयुक्त कुछ अच्छे सुरक्षा उपकरण का उपयोग करने के तरीके को जानने के लिए समय निकालें, इन उपकरणों को अद्यतन रखें और नियमित आधार पर उनका उपयोग करें।
  7. नियमित रूप से अपनी वेबसाइट सुरक्षा को 'ऑडिट' करने के लिए सुरक्षा विशेषज्ञों को भर्ती करने पर विचार करें। दोबारा, आप तय कर सकते हैं कि आप इसे बर्दाश्त नहीं कर सकते हैं या इसकी आवश्यकता नहीं है और यह ठीक है ... इसे ध्यान में रखें।

सफल हमले के परिणामों को कम करने के लिए आप क्या कदम उठा सकते हैं?

यदि आप तय करते हैं कि आपके घर की बाढ़ की निचली मंजिल का "जोखिम" उच्च है, लेकिन आगे बढ़ने के लिए पर्याप्त नहीं है, तो आपको कम से कम अपरिवर्तनीय परिवार के वायुमंडल को ऊपर की ओर ले जाना चाहिए। सही?

  1. क्या आप सीधे इंटरनेट से उजागर सेवाओं की मात्रा को कम कर सकते हैं? क्या आप अपनी आंतरिक सेवाओं और आपकी इंटरनेट-फेस सेवाओं के बीच किसी प्रकार का अंतर बनाए रख सकते हैं? यह सुनिश्चित करता है कि भले ही आपके बाहरी सिस्टम से समझौता किया गया हो, लेकिन आपके आंतरिक सिस्टम पर हमला करने के लिए स्प्रिंगबोर्ड के रूप में इसका उपयोग करने की संभावना सीमित है।
  2. क्या आप ऐसी जानकारी संग्रहीत कर रहे हैं जिसे आपको स्टोर करने की आवश्यकता नहीं है? क्या आप ऐसी जानकारी "ऑनलाइन" संग्रहीत कर रहे हैं जब इसे कहीं और संग्रहीत किया जा सकता है। इस भाग में दो अंक हैं; स्पष्ट बात यह है कि लोग आपके पास ऐसी जानकारी चोरी नहीं कर सकते हैं जो आपके पास नहीं है, और दूसरा बिंदु यह है कि जितना कम आप स्टोर करते हैं, उतना कम आपको बनाए रखने और कोड करने की आवश्यकता होती है, और इसलिए बग्स को फिसलने की संभावना कम होती है आपका कोड या सिस्टम डिज़ाइन।
  3. क्या आप अपने वेब ऐप के लिए "कम से कम एक्सेस" सिद्धांतों का उपयोग कर रहे हैं? यदि उपयोगकर्ताओं को केवल डेटाबेस से पढ़ने की आवश्यकता है, तो सुनिश्चित करें कि वेब ऐप उस सेवा के लिए उपयोग करता है जिस पर केवल सेवा पढ़ने के लिए उपयोग किया जाता है, इसे एक्सेस लिखने की अनुमति न दें और निश्चित रूप से सिस्टम-स्तरीय पहुंच न दें।
  4. यदि आप किसी चीज़ पर बहुत अनुभवी नहीं हैं और यह आपके व्यवसाय के लिए महत्वपूर्ण नहीं है, तो आउटसोर्सिंग पर विचार करें। दूसरे शब्दों में, यदि आप डेस्कटॉप एप्लिकेशन कोड लिखने के बारे में बात करते हुए एक छोटी सी वेबसाइट चलाते हैं और साइट से छोटे डेस्कटॉप एप्लिकेशन बेचने का फैसला करते हैं तो पेपैल जैसे किसी को अपने क्रेडिट कार्ड ऑर्डर सिस्टम को "आउटसोर्सिंग" पर विचार करें।
  5. यदि संभव हो, तो अपनी आपदा रिकवरी योजना के समझौता सिस्टम भाग से पुनर्प्राप्ति का अभ्यास करें। यह तर्कसंगत रूप से सिर्फ एक और "आपदा परिदृश्य" है जिसे आप सामना कर सकते हैं, केवल अपने स्वयं के समस्याओं और मुद्दों के सेट के साथ जो सामान्य 'सर्वर रूम फ्लाई फायर' / 'से अलग हैं, विशाल सर्वर द्वारा फर्बीज की चीज़ों पर हमला किया गया था।

... और अंत में

मैंने शायद सामानों का कोई अंत नहीं छोड़ा है, जो दूसरों को महत्वपूर्ण मानते हैं, लेकिन ऊपर दिए गए कदमों से कम से कम चीजों को हल करना शुरू करना चाहिए यदि आप हैकर्स से पीड़ित होने के लिए पर्याप्त भाग्यशाली हैं।

सबसे ऊपर: घबराओ मत। करने से पहले सोचो। एक बार निर्णय लेने के बाद दृढ़ता से कार्य करें, और यदि आपके पास चरणों की सूची में कुछ जोड़ने के लिए कुछ है तो नीचे एक टिप्पणी छोड़ दें।


988
2018-01-02 21:46



लोगों को एक दिशा में शुरू करने के लिए हाथ पर रहने के लिए एक उत्कृष्ट पद के लिए +1। मुझे पता है कि शौकिया सर्वर प्रशासकों के लिए इस आतंक मोड में प्रवेश करना कितना आम है जब पहली बार उनके पास 'हैक' होता है। यह है विशाल उस स्थान पर होने की गलती है, लेकिन ऐसा होता है। आशा है कि यह एक ही व्यक्ति के साथ दो बार नहीं होगा। - Andrew Barber
+1 "... लेकिन यह समय नहीं है कि आप अपनी अहंकार को जिस तरीके से करना चाहते हैं उसके रास्ते में आ जाए।" कभी-कभी समझने के लिए साइज़ प्रशासन के लिए यह महत्वपूर्ण है। कोई फर्क नहीं पड़ता कि आप कितने जानकार हैं, हमेशा वे (कभी-कभी दुर्भावनापूर्ण) होते हैं जो आपके से अधिक जानकार या चालाक होते हैं। - Grahamux
बहुत बढ़िया जवाब। मुझे यकीन नहीं है कि क्यों हर कोई वैकल्पिक रूप से "कॉल कानून प्रवर्तन" चरण का इलाज कर रहा है। यदि आप अन्य लोगों के डेटा (और मुकदमेबाजी के बारे में चिंतित) के लिए ज़िम्मेदार हैं तो यह आपकी चीजों की सूची में पहली चीजों में से एक होना चाहिए। - wds
बहुत अच्छा लिखना, सिर्फ एक गोचा - "किसी को भी संभावित रूप से प्रभावित किसी के लिए पूर्ण और स्पष्ट खुलासा करें।" माननीय, लेकिन हमेशा सही नहीं है। एक समझौता के जवाब में, आपको कुछ प्रशासनिक कोनों में कटौती करने की आवश्यकता हो सकती है, और आपकी कंपनी आम तौर पर आपको कुछ ढीला कर देगी, हालांकि ... प्रकटीकरण या नहीं, विशेष रूप से जब डेटा संरक्षण प्रभाव आपके वेतन ग्रेड से ऊपर हो सकता है और कानूनी प्रभाव हो सकता है। यह सुझाव देना बेहतर हो सकता है कि आप तुरंत डेटा सुरक्षा के लिए जिम्मेदार व्यक्ति को सूचित करें (यदि यह आप नहीं हैं) और यूआरजीई एक पूर्ण प्रकटीकरण है। - TheoJones
@GilesRoberts वर्चुअल मशीन होस्ट्स में आम तौर पर एक नियंत्रण कक्ष होता है जो आपको अपने मेहमानों की सेटिंग्स में हेरफेर करने देता है, और वास्तव में अतिथि में लॉग इन करने के लिए आरडीपी या एसएसएच का उपयोग किये बिना उन्हें रिमोट कंट्रोल भी देता है। ऐसा करने के लिए होस्ट के नियंत्रण का उपयोग करके अतिथि को अलग करने में सक्षम होना चाहिए, फिर अपने अवकाश पर अतिथि की जांच के लिए अपने दूरस्थ देखने के टूल का उपयोग करें। - Rob Moir


ऐसा लगता है जैसे आपके सिर पर थोड़ा सा है; ठीक है। अपने मालिक को बुलाओ और एक आपातकालीन सुरक्षा प्रतिक्रिया बजट के लिए बातचीत शुरू करें। शुरू करने के लिए $ 10,000 एक अच्छी जगह हो सकती है। फिर आपको सुरक्षा घटना प्रतिक्रिया में विशेषज्ञ कंपनियों को कॉल करने शुरू करने के लिए किसी को (एक पीएफवाई, एक सहकर्मी, एक प्रबंधक) प्राप्त करने की आवश्यकता है। कई 24 घंटे के भीतर जवाब दे सकते हैं, और कभी-कभी तेज़ भी होते हैं यदि उनके शहर में कोई कार्यालय हो।

ग्राहकों को ट्राय करने के लिए आपको किसी की भी आवश्यकता है; निस्संदेह, कोई पहले से ही है। किसी को भी यह समझाने के लिए फोन पर होना चाहिए कि क्या हो रहा है, स्थिति को संभालने के लिए क्या किया जा रहा है, और उनके सवालों के जवाब देने के लिए क्या किया जा रहा है।

फिर, आपको ...

  1. शांत रहो। यदि आप घटना प्रतिक्रिया के प्रभारी हैं, तो अब आपको अत्यधिक व्यावसायिकता और नेतृत्व का प्रदर्शन करने की आवश्यकता है। जो कुछ भी आप करते हैं उसे दस्तावेज करें, और अपने प्रबंधक और कार्यकारी टीम को आपके द्वारा उठाए गए प्रमुख कार्यों के बारे में अवगत कराएं; इसमें प्रतिक्रिया टीम के साथ काम करना, सर्वर को अक्षम करना, डेटा का बैक अप लेना और चीजों को ऑनलाइन लाने में शामिल है। उन्हें गोर के विवरण की आवश्यकता नहीं है, लेकिन उन्हें हर 30 मिनट या उससे भी आपके बारे में सुनना चाहिए।

  2. वास्तविक बनो। आप एक सुरक्षा पेशेवर नहीं हैं, और ऐसी चीजें हैं जिन्हें आप नहीं जानते हैं। ठीक है। सर्वर में लॉग इन करते समय और डेटा को देखते समय, आपको अपनी सीमाओं को समझने की आवश्यकता होती है। धीरे से चलना। अपनी जांच के दौरान, सुनिश्चित करें कि आप महत्वपूर्ण जानकारी पर स्टॉप नहीं करते हैं या बाद में किसी चीज को बदल सकते हैं। यदि आप असहज महसूस करते हैं या आप अनुमान लगा रहे हैं, तो यह रोकने के लिए एक अच्छी जगह है और एक अनुभवी पेशेवर को लेने के लिए।

  3. एक साफ यूएसबी छड़ी और अतिरिक्त हार्ड ड्राइव प्राप्त करें। आप सबूत इकट्ठा करेंगे। जो कुछ भी आपको लगता है उसका बैकअप लें प्रासंगिक हो सकता है; आपके आईएसपी, नेटवर्क डंप आदि के साथ संचार। यहां तक ​​कि अगर कानून प्रवर्तन शामिल नहीं होता है, तो मुकदमे के मामले में आप यह सबूत साबित करना चाहते हैं कि आपकी कंपनी ने सुरक्षा घटना को पेशेवर और उचित तरीके से संभाला है।

  4. नुकसान को रोकने के लिए सबसे महत्वपूर्ण है। समझौता सेवाओं, डेटा और मशीनों तक पहुंच को पहचानें और कट करें। अधिमानतः, आपको अपने नेटवर्क केबल को खींचना चाहिए; यदि आप नहीं कर सकते हैं, तो शक्ति खींचें।

  5. इसके बाद, आपको हमलावर को हटाने और छेद को बंद करने की आवश्यकता है। संभवतः, हमलावर के पास अब तक इंटरैक्टिव पहुंच नहीं है क्योंकि आपने नेटवर्क खींच लिया है। अब आपको पहचानने, दस्तावेज (बैकअप, स्क्रीनशॉट, और अपने स्वयं के व्यक्तिगत अवलोकन संबंधी नोट्स के साथ, या अधिमानतः प्रभावित सर्वर से ड्राइव को हटाकर और एक पूर्ण डिस्क छवि प्रतिलिपि बनाकर) की पहचान करने की आवश्यकता है, और फिर उसके पीछे छोड़े गए किसी भी कोड और प्रक्रियाओं को हटा दें । यदि आपके पास बैकअप नहीं है तो यह अगला भाग चूस जाएगा; आप हमलावर को सिस्टम से हाथ से उलझाने की कोशिश कर सकते हैं, लेकिन आप कभी भी यह सुनिश्चित नहीं करेंगे कि आपको वह सब कुछ मिला जो उसने छोड़ा था। रूटकिट्स पागल हैं, और सभी पता लगाने योग्य नहीं हैं। सबसे अच्छी प्रतिक्रिया उस भेद्यता को पहचानने के लिए होगी जो वह प्राप्त करती थी, प्रभावित डिस्क की छवि प्रतियां बनाती थी, और फिर प्रभावित सिस्टम को मिटा देती है और ज्ञात अच्छे बैकअप से पुनः लोड होती है। अंधेरे से अपने बैकअप पर भरोसा न करें; इसे सत्यापित करें! नए मेजबान नेटवर्क पर फिर से जाने से पहले भेद्यता को मरम्मत या बंद करें, और फिर इसे ऑनलाइन लाएं।

  6. अपने सभी डेटा को एक रिपोर्ट में व्यवस्थित करें। इस बिंदु पर भेद्यता बंद है और आपके पास सांस लेने में कुछ समय है। इस कदम को छोड़ने के लिए लुभाने मत बनो; यह बाकी प्रक्रिया की तुलना में और भी महत्वपूर्ण है। रिपोर्ट में, आपको यह पहचानने की आवश्यकता है कि क्या गलत हुआ, आपकी टीम ने कैसे प्रतिक्रिया दी, और इस घटना को फिर से होने से रोकने के लिए आप जो कदम उठा रहे हैं। जैसा कि आप कर सकते हैं के रूप में विस्तृत हो; यह सिर्फ आपके लिए नहीं है, बल्कि आपके प्रबंधन के लिए और एक संभावित मुकदमे में रक्षा के रूप में है।

यह क्या करना है की एक आकाश-उच्च समीक्षा है; अधिकांश काम बस दस्तावेज़ीकरण और बैकअप हैंडलिंग है। घबराओ मत, आप वह सामान कर सकते हैं। मैं दृढ़ता से आपको पेशेवर सुरक्षा सहायता प्राप्त करने की सलाह देते हैं। यहां तक ​​कि यदि आप क्या कर रहे हैं, इसे संभालने में सक्षम हैं, तो उनकी सहायता अमूल्य होगी और आमतौर पर प्रक्रिया को आसान और तेज़ बनाने के लिए वे उपकरण के साथ आते हैं। यदि आपका बॉस लागत पर झुकता है, तो उसे याद दिलाएं कि मुकदमे को संभालने की तुलना में यह बहुत छोटा है।

आपके पास अपनी स्थिति के लिए मेरी सांत्वना है। सौभाग्य।


199
2018-01-02 22:16



+1 महान जवाब। ऐसा लगता है कि ओपी में पूर्व-परिभाषित "आपातकालीन प्रतिक्रिया" नहीं है और आपकी पोस्ट, अन्य अच्छी चीजों के साथ, उन्हें सेट अप करने की दिशा में इंगित करनी चाहिए। - Rob Moir


सीईआरटी का एक दस्तावेज है यूनिक्स या एनटी सिस्टम समझौता से पुनर्प्राप्त करने के लिए कदम यह अच्छा है। इस दस्तावेज़ का विशिष्ट तकनीकी विवरण कुछ हद तक पुराना है, लेकिन बहुत सी सामान्य सलाह अभी भी लागू होती है।

बुनियादी चरणों का एक त्वरित सारांश यह है।

  • अपनी सुरक्षा नीति या प्रबंधन से परामर्श लें।
  • नियंत्रण प्राप्त करें (कंप्यूटर को ऑफ़लाइन लें)
  • घुसपैठ का विश्लेषण करें, लॉग प्राप्त करें, पता करें कि क्या गलत हुआ
  • मरम्मत सामान
    • अपने ऑपरेटिंग सिस्टम का एक साफ संस्करण स्थापित करें !!! अगर सिस्टम से समझौता किया गया है तो आप इस पर भरोसा नहीं कर सकते हैं, अवधि।
  • सिस्टम अपडेट करें ताकि यह फिर से न हो
  • संचालन फिर से शुरू करें
  • भविष्य और दस्तावेज़ के लिए अपनी नीति अपडेट करें

मैं विशेष रूप से आपको अनुभाग E.1 पर इंगित करना चाहता हूं।

E.1।   ध्यान रखें कि अगर एक मशीन है   समझौता, उस प्रणाली पर कुछ भी   सहित संशोधित किया जा सकता था   कर्नेल, द्विआधारी, डेटाफाइल,   चल रही प्रक्रियाओं, और स्मृति। में   सामान्य, उस पर विश्वास करने का एकमात्र तरीका ए   मशीन बैकडोर्ड्स से मुक्त है और   घुसपैठ संशोधन पुनर्स्थापित करने के लिए है   ऑपरेटिंग

यदि आपके पास ट्रिपवायर जैसी जगह पहले से मौजूद सिस्टम नहीं है, तो आपके पास 100% निश्चित होने का कोई संभावित तरीका नहीं है कि आपने सिस्टम को साफ़ कर लिया है।


105
2018-05-08 09:02



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


  1. की पहचान समस्या। लॉग पढ़ें।
  2. होते हैं। आपने सर्वर को डिस्कनेक्ट कर दिया है, इसलिए यह हो गया है।
  3. उन्मूलन। सबसे अधिक संभावना प्रभावित प्रणाली को पुनर्स्थापित करें। हालांकि हैक की हार्ड ड्राइव को मिटाना न भूलें, एक नया इस्तेमाल करें। यह सुरक्षित है, और आपको बदसूरत हैक्स का बैक अप लेने के लिए पुराने व्यक्ति की आवश्यकता हो सकती है, और यह पता लगाने के लिए फोरेंसिक करना है कि क्या हुआ।
  4. वसूली। अपने ग्राहकों को ऑनलाइन प्राप्त करने के लिए जो भी आवश्यक है इंस्टॉल करें और बैकअप पुनर्प्राप्त करें।
  5. ऊपर का पालन करें। यह पता लगाएं कि समस्या क्या थी, और इसे फिर से होने से रोकें।

64
2018-01-02 21:49





रॉबर्ट की "कड़वी गोली" जवाब स्पॉट-ऑन है लेकिन पूरी तरह से सामान्य है (ठीक है, जैसा आपका प्रश्न था)। ऐसा लगता है कि आपके पास एक प्रबंधन समस्या है और पूर्णकालिक sysadmin की सख्त आवश्यकता है यदि आपके पास एक सर्वर और 600 क्लाइंट हैं लेकिन इससे आपकी मदद नहीं मिलती है।

मैं एक होस्टिंग कंपनी चलाता हूं जो इस स्थिति में थोड़ा सा हाथ पकड़ लेता है, इसलिए मैं कई समझौता मशीनों से निपटता हूं, बल्कि अपने लिए सर्वोत्तम अभ्यास भी करता हूं। हम हमेशा हमारे समझौता किए गए ग्राहकों को पुनर्निर्माण के बारे में बताते हैं जब तक कि वे एक समझौता की प्रकृति के बारे में पूरी तरह से सुनिश्चित नहीं हैं। लंबी अवधि में कोई अन्य जिम्मेदार मार्ग नहीं है।

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

इस प्रक्रिया में कुछ घंटे लग सकते हैं यदि आपने पहले ऐसा नहीं किया है, और कभी फ़ायरवॉल नहीं माना है, लेकिन आपकी क्लाइंट सेवा को पुनर्स्थापित करने में आपकी सहायता कर सकता है हमलावर को अपने ग्राहकों के डेटा तक पहुंच प्रदान करने के जोखिम पर। चूंकि आप कहते हैं कि आपके पास एक मशीन पर सैकड़ों ग्राहक हैं, मुझे लगता है कि आप छोटे व्यवसायों के लिए छोटी ब्रोशर वेबसाइट्स होस्ट कर रहे हैं, न कि 600 ईकॉमर्स सिस्टम क्रेडिट कार्ड नंबर से भरे हुए हैं। यदि ऐसा है तो यह आपके लिए स्वीकार्य जोखिम हो सकता है, और सुरक्षा बग के लिए 600 साइटों की ऑडिटिंग करने से आपके सिस्टम को ऑनलाइन तेज़ी से प्राप्त कर सकता है से पहले आप कुछ भी वापस लाओ। लेकिन आपको पता चलेगा कि कौन सा डेटा है, और आप उस निर्णय को कितना सहज महसूस करेंगे।

यह बिल्कुल सही अभ्यास नहीं है, लेकिन अगर ऐसा नहीं है कि आपके नियोक्ता पर अब तक क्या हो रहा है, तो उन पर अपनी उंगली को घुमाकर और SWAT टीम के लिए हजारों पाउंड मांगने के लिए कुछ ऐसा महसूस हो सकता है जो आपकी भावना है (हालांकि अन्यायपूर्ण! ) व्यावहारिक विकल्प की तरह नहीं लगता है।

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

लेकिन लंबी अवधि में आपको रॉबर्ट की पोस्ट और प्रत्येक साइट और उसके सेटअप के आधार पर सिस्टम पुनर्निर्माण पर योजना बनाना चाहिए। यदि आप अपनी टीम में एक sysadmin जोड़ा नहीं जा सकता है, तो एक के लिए देखो प्रबंधित होस्टिंग सौदा करें जहां आप sysadminning सहायता के लिए अपने आईएसपी का भुगतान करते हैं और इस तरह की चीज़ के लिए 24 घंटे की प्रतिक्रिया देते हैं। सौभाग्य :)


49
2018-01-03 13:48





आपको पुनः स्थापित करने की आवश्यकता है। आपको वास्तव में क्या चाहिए बचाओ। लेकिन ध्यान रखें कि आपकी सभी चलने योग्य फ़ाइलों को संक्रमित और छेड़छाड़ की जा सकती है। मैंने पाइथन में निम्नलिखित लिखा है: http://frw.se/monty.py जो किसी दिए गए निर्देशिका में आपकी सभी फ़ाइलों के MD5-sumbs बनाता है और अगली बार जब आप इसे चलाते हैं, तो यह जांचता है कि कुछ भी बदल दिया गया है और फिर आउटपुट फाइलें बदली गईं और फ़ाइलों में क्या बदल गया।

यह देखने के लिए आपके लिए आसान हो सकता है कि अजीब फाइलें नियमित रूप से बदल जाती हैं या नहीं।

लेकिन अब एकमात्र चीज जो आपको करनी चाहिए, वह आपके कंप्यूटर को इंटरनेट से हटा रही है।


38
2018-05-08 08:02



तो ... आपने ट्रिपवायर लागू किया है। - womble♦
हाँ, उसमें कुछ गड़बड़ है? - Filip Ekberg
अनप्लग के लिए +1, विश्लेषण करें (किसी को वास्तविक फोरेंसिक करने के लिए प्राप्त करें) और मिटाएं - Oskar Duveborn
एक अज्ञात पायथन स्क्रिप्ट और एक दस्तावेज, (कुछ हद तक) समर्थित, अच्छी तरह से समझने वाले मानक समाधान के बीच की पसंद को देखते हुए, आप उम्मीद कर रहे हैं कि वे पूर्व को चुन लेंगे? - tripleee


ध्यान दें: यह एक सिफारिश नहीं है। मेरा विशिष्ट घटना की प्रतिक्रिया मसविदा बनाना शायद नहीं होगा अनुदान अनचाहे मामले के लिए unmodified लागू नहीं है।

हमारी अकादमिक सुविधाओं में हमारे पास लगभग 300 शोधकर्ता हैं जो केवल गणना करते हैं। आपके पास वेबसाइटों के साथ 600 ग्राहक हैं इसलिए आपका प्रोटोकॉल शायद अलग होगा।

हमारे पहले कदम जब एक सर्वर समझौता प्रोटोकॉल हो जाता है है:

  1. पहचानें कि हमलावर रूट प्राप्त करने में सक्षम था (उन्नत विशेषाधिकार)
  2. प्रभावित सर्वर को अनप्लग करें। नेटवर्क या शक्ति? कृपया देखें एक अलग चर्चा
  3. अन्य सभी प्रणालियों की जांच करें
  4. एक लाइव सीडी से प्रभावित सर्वर बूट करें
  5. (वैकल्पिक) सभी सिस्टम ड्राइव की छवियों को पकड़ो dd
  6. पोस्ट-मॉर्टम फोरेंसिक करना शुरू करें। लॉग को देखें, हमले के समय को समझें, उस समय संशोधित फ़ाइलों को ढूंढें। जवाब देने का प्रयास करें कैसे? सवाल।

    • समानांतर में, अपनी वसूली की योजना बनाएं और निष्पादित करें।
    • सेवा को फिर से शुरू करने से पहले सभी रूट और उपयोगकर्ता पासवर्ड रीसेट करें

भले ही "सभी बैकडोर्ड्स और रूटकिट साफ़ हो जाएं", उस सिस्टम पर भरोसा न करें - स्क्रैच से पुनः इंस्टॉल करें।


34
2018-05-18 22:36



-1 सर्वर से बिजली को अनप्लग करें? आपने अपने फोरेंसिक डेटा का आधा हिस्सा खो दिया है! - Josh Brower
@ जोश, मैंने अपना जवाब समायोजित किया - अब यह सवाल अनप्लग करने के लिए तटस्थ है। - Aleksandr Levchuk
रैम फोरेंसिक (उदा। / Dev / shm) सहायक हो सकता है। मैं पावर केबल को अनप्लग करना पसंद करता हूं (लेकिन लॉग-इन करने का प्रयास करें और rsync / ठीक पहले proc)। हम लगातार वीएम स्नैपशॉट भी पेश कर सकते हैं ताकि रैम फोरेंसिक संभव हो। पावर केबल के लिए जाने के कारण हैं (1) जब आप एक हैक सिस्टम में फोरेंसिक करते हैं, तो आप "पूरे अपराध दृश्य में कदम उठा रहे हैं"; (2) रूट किट चलती रहती है - किसी को निष्पादित करने के लिए दुर्भावनापूर्ण (उदाहरण के लिए सिस्टम मिटाएं) पर इतना कठिन नहीं है नेटवर्क लिंक डाउन घटना। फोरेंसिक टॉक के लिए अपने अच्छे परिचय में केली रैंकिन (goo.gl/g21Ok) बिजली केबल खींचने की सिफारिश की। - Aleksandr Levchuk
सभी आईआर प्रोटोकॉल में कोई भी आकार फिट नहीं है - किसी भी कारण से कुछ संगठनों को थोड़ी देर के लिए समझौता सिस्टम ऑनलाइन रखने की आवश्यकता हो सकती है। (रैम और अस्थायी लॉग फोरेंसिक, घुसपैठियों के साथ बातचीत, इत्यादि) मेरा मुद्दा यह है कि "जेरोब बोर्ग ऊपर की तरह) एक सामान्य आईआर प्रोटोकॉल की सिफारिश करना बेहतर होगा" समझौता सर्वर के पावर प्लग को खींचें। " - Josh Brower


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

पिल्ला प्रारूपित करें।

लेकिन, अगर आप पुनर्निर्माण नहीं कर सकते हैं (या शक्तियां-जो आपको इसे अपने सख्त आग्रह के खिलाफ पुनर्निर्माण नहीं करने देगी), तो आप क्या देखते हैं?

चूंकि ऐसा लगता है कि घुसपैठ की खोज होने के बाद से कुछ समय हो गया है, और एक सिस्टम पुनर्स्थापना की गई है, यह बहुत संभव है कि सेवा को बहाल करने के लिए स्टैम्पेड में उन्हें कैसे मिला है, इसका पता लगाया गया है। दुर्भाग्य।

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

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


28
2018-01-03 14:31



'पिल्ला को प्रारूपित करें।' +1, ऋषि सलाह। यह भी देखें: "इसे कक्षा से नूक करें, यह सुनिश्चित करने का एकमात्र तरीका है।" - Avery Payne


मैं कहूंगा कि @ रॉबर्ट मोइर, @ अलेक्ज़ेंडर लेवचुक, @ ब्लूबेन और @ मैथ्यू ब्लोच उनके प्रतिक्रियाओं में बहुत अधिक स्पॉट-ऑन हैं।

हालांकि, विभिन्न पोस्टरों के उत्तरों में भिन्नता है - कुछ उच्च स्तर पर अधिक हैं और इस बारे में बात करते हैं कि आपके पास कौन सी प्रक्रियाएं होनी चाहिए (सामान्य रूप से)।

मैं इसे अलग-अलग हिस्सों में अलग करना पसंद करूंगा 1) विवाह, एकेए ग्राहकों और कानूनी प्रभावों से कैसे निपटें, और वहां से कहां जाना है (रॉबर्ट और @ ब्लूबेन द्वारा बहुत अच्छी तरह से सूचीबद्ध 2) प्रभाव की कमी 3) घटना प्रतिक्रिया 4) पोस्ट-मॉर्टम फोरेंसिक 5) उपचार वस्तुओं और वास्तुकला में परिवर्तन

(बॉयलरप्लेट एसएएनएस जीएससी प्रमाणित प्रतिक्रिया कथन यहां डालें) पिछले अनुभवों के आधार पर, मैं निम्नलिखित कहूंगा:

भले ही आप ग्राहक प्रतिक्रियाओं, अधिसूचनाओं, कानूनी और भविष्य की योजनाओं को कैसे प्रबंधित कर रहे हों, मैं मुख्य मुद्दे पर ध्यान केंद्रित करना पसंद करूंगा। ओपी का मूल प्रश्न वास्तव में केवल # 2 और # 3 से संबंधित है, मूल रूप से, हमले को कैसे रोकें, ग्राहकों को अपने मूल राज्य में ऑनलाइन ASAP प्राप्त करें, जो प्रतिक्रियाओं में अच्छी तरह से कवर किया गया है।

बाकी प्रतिक्रियाएं बहुत अच्छी हैं और भविष्य में होने वाली घटनाओं को रोकने के तरीकों के साथ-साथ बेहतर प्रतिक्रिया देने के लिए बहुत से पहचाने जाने वाले सर्वोत्तम अभ्यास और तरीके शामिल हैं।

यह वास्तव में ओपी के बजट और उद्योग के किस क्षेत्र में हैं, उनके वांछित समाधान आदि पर निर्भर करता है।

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

यह वास्तव में इस बात पर निर्भर करता है कि उनके व्यापार के लिए क्या काम करता है। हो सकता है कि उनकी मूल योग्यता सर्वर प्रबंधन में न हो और उनके लिए इसे विकसित करने का प्रयास न करें। या, हो सकता है कि वे पहले से ही एक सुंदर तकनीकी संगठन हैं और सही भर्ती निर्णय ले सकते हैं और एक समर्पित टीम पूर्णकालिक ला सकते हैं।


28
2018-01-04 02:21



हाँ, यह निर्भर करता है, हम जानते हैं। यह कहकर कि वास्तव में ज्यादा मदद नहीं करता है। - DOK