सवाल रूट समझौता के बाद पुनर्स्थापित करें?


पढ़ने के बाद एक सर्वर समझौता पर यह सवाल, मुझे आश्चर्य हुआ कि लोग क्यों मानते हैं कि वे पहचान / सफाई उपकरण का उपयोग करके एक समझौता प्रणाली पुनर्प्राप्त कर सकते हैं, या सिस्टम को समझौता करने के लिए इस्तेमाल किए गए छेद को ठीक करके ठीक कर सकते हैं।

सभी विभिन्न रूट किट प्रौद्योगिकियों और अन्य चीजों को देखते हुए एक हैकर अधिकांश विशेषज्ञों को सुझाव दे सकता है कि आपको चाहिए ऑपरेटिंग सिस्टम को पुनर्स्थापित करें

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

यहां कुछ बिंदु दिए गए हैं, जिन्हें मैं संबोधित करना चाहता हूं।

  • क्या ऐसी स्थितियां हैं जहां एक प्रारूप / पुनर्स्थापित सिस्टम को साफ नहीं करेगा?
  • किस प्रकार की स्थितियों में आपको लगता है कि एक प्रणाली को साफ किया जा सकता है, और आपको पूर्ण पुनर्स्थापित करने के लिए कब करना चाहिए?
  • पूर्ण पुनर्स्थापित करने के विरुद्ध आपके पास क्या तर्क है?
  • यदि आप पुनर्स्थापित नहीं करना चुनते हैं, तो आप उचित तरीके से आत्मविश्वास के लिए किस विधि का उपयोग करते हैं, जिसे आपने फिर से होने से किसी और नुकसान को साफ और रोक दिया है।

56
2018-05-08 09:32


मूल




जवाब:


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

यहां आमतौर पर उस व्यावसायिक निर्णय में क्या होता है:

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

और इसलिए, जब आप उन लोगों की लागत को जोड़ते हैं, तो यह समझा जा सकता है कि "संभावित" अभी भी समझौता सिस्टम जारी रखना सिस्टम को पुनर्स्थापित करने से बेहतर है।


30
2018-05-08 09:58



कृपया कुछ समय लें और रिचर्ड बेजट्लिच की उत्कृष्ट पोस्ट को "सस्ता आईटी अंततः महंगा है" सारांश में, "सुरक्षा विश्लेषण को सक्षम करने के लिए सिस्टम को बाधित होने पर" उत्पादकता हिट "के कारण एंटरप्राइज़ के भीतर चल रहे समझौता सिस्टम छोड़ना सस्ता नहीं है।" - Josh Brower
मैंने थोड़ी देर के लिए इस बारे में सोचा, और एक कारण के साथ नहीं आ सकता है कि क्यों समझौता होने की संभावना वाले सिस्टम को तैनात करने के लिए और अधिक समझदारी होगी। - duffbeer703
मैं ऑनलाइन सिस्टम को तैनात या रखना नहीं चाहता हूं, मुझे पता है कि समझौता किया गया है, या तो। लेकिन यह मुझे एक तकनीशियन के रूप में है। और मैं इस पर बेजट्लिच से असहमत हूं क्योंकि जब वह कहता है कि एक नुकसान रोकथाम अभ्यास है, तो व्यवसाय इसका इलाज नहीं करता है। व्यापार इसे जोखिम परिप्रेक्ष्य से देखता है, और सही तरीके से। उदाहरण के लिए, वे मुकदमे की स्थिति में उन्हें कवर करने के लिए बीमा पर भरोसा कर सकते हैं और इस तरह वे जोखिम से निपटते हैं। और रिचर्ड इसका तर्क अपने तर्क में नहीं मानता है। मैंने यह नहीं कहा कि मैं इस सोच से सहमत हूं, लेकिन इस तरह आप इसका एहसास करते हैं, ओपी यही पूछ रहा था। - K. Brian Kelley
मैं बेजिलिच के साथ कुछ हद तक असहमत भी हूं, लेकिन मुझे कम से कम अपनी आखिरी टिप्पणी उद्धृत करने दें, क्योंकि यह इस चर्चा में एक और आयाम जोड़ता है: "मापने" जोखिम एक मजाक है। नुकसान का नुकसान ज्यादातर असंभव है। (मुझे बताएं कि जब कोई प्रतिस्पर्धी अगले 10 वर्षों में अपने उत्पादों को बेहतर बनाने के लिए आपके डेटा को चुरा लेता है तो आप कितना खो देते हैं) मापने की लागत सबसे अधिक विश्वसनीय परिणाम उत्पन्न करने की संभावना है क्योंकि आप कंपनी छोड़ने के पैसे को ट्रैक कर सकते हैं। लागत लगाना वह है जो मैं संदर्भित करता हूं इस पोस्ट में मुझे नुकसान को मापना अच्छा लगेगा लेकिन यह वास्तविक संख्या नहीं दे रहा है। जोखिम मापना एक विशाल अनुमान है। " - Josh Brower
... और फिर भी हमारा पूरा बीमा उद्योग और सिविल कोर्ट सिस्टम जोखिम को मापने और घाटे पर डॉलर के आंकड़े लगाने पर आधारित है। तो जाहिर है कि दृष्टिकोण है प्रभारी लोगों को स्वीकार्य। - Brian Knoblauch


एक पोस्ट I के आधार पर उम्र पहले लिखा था वापस जब मैं अभी भी ब्लॉग पर परेशान हो सकता था।

हैकर्स के पीड़ितों द्वारा अपने वेब सर्वर में तोड़ने से बार-बार पूछा जा रहा है। जवाब बहुत ही कम बदलते हैं, लेकिन लोग सवाल पूछते रहते हैं। मुझे यकीन नहीं है क्यों। शायद लोग मदद के लिए खोज करते समय देखे गए उत्तरों को पसंद नहीं करते हैं, या वे किसी को सलाह नहीं दे सकते कि वे उन्हें सलाह दें। या शायद लोग इस प्रश्न का उत्तर पढ़ते हैं और 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. यदि संभव हो, तो अपनी आपदा रिकवरी योजना के समझौता सिस्टम भाग से पुनर्प्राप्ति का अभ्यास करें। यह तर्कसंगत रूप से सिर्फ एक और "आपदा परिदृश्य" है जिसे आप सामना कर सकते हैं, केवल अपने स्वयं के समस्याओं और मुद्दों के सेट के साथ जो सामान्य 'सर्वर रूम फ्लाई फायर' / 'से अलग हैं, विशाल सर्वर द्वारा फर्बीज की चीज़ों पर हमला किया गया था। (संपादित करें, प्रति एक्सटीजेड)

... और अंत में

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

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


28
2018-06-14 21:00



+1, बहुत अच्छा, बहुत व्यापक। - Avery Payne
धन्यवाद एवरी, मुझे यकीन नहीं है कि आपकी तस्वीर उतनी जल्दी नहीं कहती है लेकिन मैं अभी वोटों से बाहर हूं! - Rob Moir
मेरी इच्छा है कि एसएफ में पसंदीदा के रूप में उत्तरों को चिह्नित करने की क्षमता होगी। ऐसा लगता है कि मैंने बहुत सारे जवाब देखे हैं कि मैं या तो क्रॉस-पोस्ट करना चाहता हूं या क्रॉस-पोस्ट होना चाहिए। वैसे भी, मैं पूरी तरह से उत्तर देने का प्रशंसक हूं - आप इसे जानने के बजाय इसे सब कुछ जानने से बेहतर हैं। - Avery Payne
एक चीज जो आपको जोड़ने की जरूरत है, इसे अपने डीआर प्लान का एक हिस्सा बनाएं !!! छोटी कंपनियों के पास केवल कुछ सर्वर हो सकते हैं, ऐसा होने से पहले इस बारे में सोचना चाहिए, जब आप अलग-अलग होते हैं, मूल्यांकन करते हैं, नाक, पुनर्निर्माण करते हैं तो आप ऐसा कर सकते हैं। - XTZ
अच्छा एक एक्सटीजेड, जो सूची में जा रहा है। - Rob Moir


हमेशा कक्षा से इसे nuke। यह सुनिश्चित करने का एकमात्र तरीका है।

alt text

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

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


18
2018-06-14 20:50





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

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


5
2018-05-08 09:40





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

मैं कहूंगा कि यह ज्यादातर मूलभूत दिनचर्या और नीतियों में कुछ ख़राब है और यह ऐसा कुछ नहीं है जिसे आप खुले तौर पर स्वीकार करना चाहते हैं - और इसके बजाय आप रक्षात्मक रुख लेते हैं। कम से कम मैं किसी समझौता प्रणाली को पोंछने या नहीं देख सकता हूं इससे कोई फर्क नहीं पड़ता कि आप किस कोण को देखते हैं।


2
2018-05-08 09:59





मैंने पिछले सिस्टम को नुकीला नहीं किया है ताकि मैं वेक्टर के कुछ विश्लेषण कर सकूं जो वे अंदर आए थे और बाद में उपयोग की गई थीं और यह देखने के लिए कि उन्हें कहां जाना है।

एक बार जब आप जड़ें हो जाएं - आपके पास एक लाइव हनीपॉट है और यह केवल हैक की तुलना में बहुत अधिक ऑफर कर सकता है। - खासकर पुलिस के लिए।

  • मैंने कहा कि मैं हॉट स्टैंड पर एक साफ प्रणाली पाने में सक्षम होने के लिए पूर्वनिर्धारित हूं और रूट बॉक्स को अलग करने के लिए तेजी से बढ़ी हुई नेटवर्क सुरक्षा प्रदान करने में सक्षम हूं।

2
2018-05-08 11:16