एक पोस्ट के आधार पर मैंने सदियों पहले लिखा था जब मैं अभी भी ब्लॉग पर परेशान हो सकता था।
हैकर्स के पीड़ितों द्वारा उनके वेब सर्वर में सेंध लगाने से यह सवाल बार-बार पूछा जा रहा है। जवाब बहुत कम ही बदलते हैं, लेकिन लोग सवाल पूछते रहते हैं। मुझे यकीन नहीं है कि क्यों। शायद लोग सिर्फ उन उत्तरों को पसंद नहीं करते हैं जो उन्होंने मदद के लिए खोजे हैं, या वे किसी ऐसे व्यक्ति को नहीं खोज सकते हैं जिस पर वे उन्हें सलाह देने के लिए भरोसा करते हैं। या शायद लोग इस सवाल का जवाब पढ़ते हैं और 5% पर ध्यान केंद्रित करते हैं कि उनका मामला विशेष क्यों है और उन उत्तरों से अलग है जो वे ऑनलाइन पा सकते हैं और 95% प्रश्न और उत्तर को याद कर सकते हैं जहां उनका मामला पर्याप्त पास है जैसा कि वे ऑनलाइन पढ़ते हैं।
यह मुझे सूचना की पहली महत्वपूर्ण डली में लाता है। मैं वास्तव में सराहना करता हूं कि आप एक विशेष अद्वितीय स्नोफ्लेक हैं। मैं सराहना करता हूं कि आपकी वेबसाइट बहुत अधिक है, क्योंकि यह आपके और आपके व्यवसाय का प्रतिबिंब है या बहुत कम से कम, एक नियोक्ता की ओर से आपकी मेहनत। लेकिन बाहर की ओर देखने वाले किसी व्यक्ति के लिए, चाहे वह कंप्यूटर सुरक्षा वाला व्यक्ति आप पर हमला करने में मदद करने के लिए या यहां तक कि खुद हमलावर की समस्या को देख रहा हो, यह बहुत संभावना है कि आपकी समस्या हर दूसरे मामले में कम से कम 95% के समान होगी। कभी देखा।
हमले को व्यक्तिगत रूप से न लें, और उन अनुशंसाओं को न लें जो आपको यहां आती हैं या जो आपको अन्य लोगों से व्यक्तिगत रूप से मिलती हैं। यदि आप वेबसाइट हैक के शिकार बनने के बाद इसे पढ़ रहे हैं तो मुझे वास्तव में खेद है, और मुझे वास्तव में आशा है कि आप यहां कुछ मददगार हो सकते हैं, लेकिन यह समय आपके अहंकार को उस रास्ते पर आने का नहीं है जो आपको चाहिए। करना।
आपको अभी पता चला है कि आपका सर्वर हैक हो गया है। अब क्या?
घबराओ मत। बिल्कुल जल्दबाजी में काम नहीं करते हैं, और पूरी कोशिश नहीं करते हैं और दिखावा करते हैं कि चीजें कभी नहीं हुईं और बिल्कुल भी अभिनय नहीं किया।
पहला: यह समझिए कि आपदा पहले ही हो चुकी है। यह इनकार का समय नहीं है; यह उस समय को स्वीकार करने का समय है जो हुआ है, इसके बारे में यथार्थवादी होना और प्रभाव के परिणामों का प्रबंधन करने के लिए कदम उठाना।
इन चरणों में से कुछ को चोट पहुंचाने जा रहे हैं, और (जब तक कि आपकी वेबसाइट मेरे विवरण की एक प्रति नहीं रखती है) मुझे वास्तव में परवाह नहीं है यदि आप इन सभी या कुछ चरणों की उपेक्षा करते हैं लेकिन ऐसा करने से अंत में चीजें बेहतर होंगी। दवा का स्वाद भयानक हो सकता है, लेकिन कभी-कभी आपको यह भी अनदेखा करना पड़ता है कि क्या आप वास्तव में काम करना चाहते हैं।
समस्या को पहले से ही बदतर होने से रोकें:
- पहली चीज जो आपको करनी चाहिए वह इंटरनेट से प्रभावित सिस्टम को डिस्कनेक्ट करना है। आपको जो भी अन्य समस्याएं हैं, वे वेब से जुड़े सिस्टम को छोड़कर केवल हमले को जारी रखने की अनुमति देंगे। मेरा यह शाब्दिक अर्थ है; किसी को शारीरिक रूप से सर्वर और अनप्लग नेटवर्क केबलों को देखने के लिए प्राप्त करें यदि ऐसा होता है, लेकिन इससे पहले कि आप कुछ और करने की कोशिश करें, अपने शिकार से शिकार को डिस्कनेक्ट करें।
- सभी कंप्यूटरों पर सभी खातों के लिए अपने सभी पासवर्ड बदलें जो एक ही नेटवर्क पर हैं जो समझौता किए गए सिस्टम के समान हैं। सच में नहीं। सभी खाते हैं। सभी कंप्यूटर। हां, आप सही कह रहे हैं, यह ओवरकिल हो सकता है; दूसरी ओर, यह नहीं हो सकता है। आप किसी भी तरह से नहीं जानते, क्या आप?
- अपने अन्य सिस्टम की जाँच करें। अन्य इंटरनेट का सामना करने वाली सेवाओं पर और उन लोगों पर विशेष ध्यान दें जो वित्तीय या अन्य व्यावसायिक रूप से संवेदनशील डेटा रखते हैं।
- यदि सिस्टम किसी का व्यक्तिगत डेटा रखता है, तो संभावित रूप से एक ही बार में किसी को भी पूर्ण और स्पष्ट प्रकटीकरण करें। मैं जानता हूं कि यह कठिन है। मुझे पता है कि यह चोट करने वाला है। मुझे पता है कि कई व्यवसाय इस तरह की समस्या को कालीन के नीचे झाडू देना चाहते हैं, लेकिन मुझे डर है कि आप इससे निपटने के लिए बस करने जा रहे हैं।
फिर भी यह आखिरी कदम उठाने में संकोच? मैं समझता हूं, मैं करता हूं। लेकिन इसे इस तरह से देखें:
कुछ स्थानों पर आपको अच्छी तरह से अधिकारियों और / या इस तरह की गोपनीयता भंग के शिकार लोगों को सूचित करने की कानूनी आवश्यकता हो सकती है। हालाँकि, आपके ग्राहक नाराज हो सकते हैं कि आप उन्हें एक समस्या के बारे में बताएं, यदि आप उन्हें नहीं बताएंगे तो वे और अधिक नाराज हो जाएंगे, और वे केवल क्रेडिट कार्ड विवरणों का उपयोग करके $ 8,000 मूल्य के सामान का शुल्क लेने के बाद खुद के लिए पता लगाते हैं अपनी साइट से चुरा लिया।
याद रखें कि मैंने पहले क्या कहा था? बुरी बात पहले ही हो चुकी है । एकमात्र सवाल अब यह है कि आप इससे कैसे निपटते हैं।
समस्या को पूरी तरह से समझें:
- प्रभावित प्रणालियों को ऑनलाइन वापस न करें जब तक कि यह चरण पूरी तरह से पूरा नहीं हो जाता है, जब तक कि आप वह व्यक्ति नहीं बनना चाहते हैं जिसका पद मेरे लिए वास्तव में इस लेख को लिखने का निर्णय लेने वाला था। मैं पोस्ट से लिंक नहीं कर रहा हूं ताकि लोगों को एक सस्ता हंसी मिल सके; मैं आपको इस पहले चरण का पालन करने में विफल रहने के परिणामों से सावधान करने के लिए लिंक कर रहा हूं।
- यह समझने के लिए कि 'हमले' सिस्टम की जाँच करें कि हमले आपकी सुरक्षा से समझौता करने में कैसे सफल हुए। यह पता लगाने के लिए हर संभव प्रयास करें कि हमले "कहां से आए", ताकि आप समझ सकें कि भविष्य में आपके सिस्टम को सुरक्षित बनाने के लिए आपको क्या समस्याएं हैं और इसका समाधान करने की आवश्यकता है।
- 'अटैक' सिस्टम को फिर से परखें, इस बार यह समझने के लिए कि हमले कहाँ गए, ताकि आप समझ सकें कि हमले में किन प्रणालियों से समझौता किया गया था। सुनिश्चित करें कि आप किसी भी संकेत का पालन करते हैं जो सुझाव देते हैं कि समझौता किए गए सिस्टम आपके सिस्टम पर आगे हमला करने के लिए एक स्प्रिंगबोर्ड बन सकते हैं।
- किसी भी और सभी हमलों में इस्तेमाल होने वाले "गेटवे" सुनिश्चित करें, ताकि आप उन्हें ठीक से बंद करना शुरू कर सकें। (उदाहरण के लिए, यदि आपके सिस्टम में SQL इंजेक्शन के हमले से समझौता किया गया है, तो न केवल आपको उस कोड की विशेष त्रुटिपूर्ण लाइन को बंद करने की जरूरत है, जिससे वे टूट गए हैं, आप अपने सभी कोड का ऑडिट करना चाहेंगे कि क्या उसी प्रकार की गलती हुई है। कहीं और बनाया गया था)।
- समझें कि एक से अधिक दोषों के कारण हमले सफल हो सकते हैं। अक्सर, हमले एक प्रणाली में एक प्रमुख बग को खोजने के माध्यम से सफल नहीं होते हैं, लेकिन एक प्रणाली से समझौता करने के लिए कई मुद्दों (कभी-कभी मामूली और खुद से मामूली) को एक साथ तार करके। उदाहरण के लिए, डेटाबेस सर्वर पर कमांड भेजने के लिए एसक्यूएल इंजेक्शन के हमलों का उपयोग करना, जिस वेबसाइट / एप्लिकेशन पर आप हमला कर रहे हैं, उसकी खोज करना एक प्रशासनिक उपयोगकर्ता के संदर्भ में चल रहा है और उस खाते के अधिकारों का उपयोग अन्य भागों के साथ समझौता करने के लिए एक कदम-पत्थर के रूप में करना एक प्रणाली। या जैसा कि हैकर्स इसे कॉल करना पसंद करते हैं: "आम गलतियों का फायदा उठाते हुए कार्यालय में एक और दिन"।
पुनर्प्राप्ति के लिए एक योजना बनाएं और अपनी वेबसाइट को ऑनलाइन वापस लाएं और उससे चिपके रहें:
कोई भी इससे अधिक समय तक ऑफ़लाइन नहीं रहना चाहता है, जितना उसे होना है। वह दे दिया गया। यदि यह वेबसाइट राजस्व पैदा करने वाला तंत्र है तो इसे जल्दी से ऑनलाइन वापस लाने का दबाव तीव्र होगा। यहां तक कि अगर दांव पर एकमात्र चीज आपकी / आपकी कंपनी की प्रतिष्ठा है, तो यह अभी भी चीजों को जल्दी से वापस लाने के लिए बहुत अधिक दबाव पैदा कर रहा है।
हालाँकि, बहुत जल्दी ऑनलाइन वापस जाने के प्रलोभन में न दें। इसके बजाय जितना संभव हो उतना समझने के लिए तेजी से आगे बढ़ें और समस्या को हल करने और इससे पहले कि आप ऑनलाइन वापस जाएं या फिर आप लगभग निश्चित रूप से एक बार फिर घुसपैठ का शिकार हो जाएंगे, और याद रखें, "एक बार हैक होने के लिए दुर्भाग्य के रूप में वर्गीकृत किया जा सकता है; फिर से सीधे हैक होने के लिए लापरवाह जैसा दिखता है "(ऑस्कर वाइल्ड के लिए माफी के साथ)।
- मैं मान रहा हूँ कि आपने उन सभी मुद्दों को समझ लिया है जिनके कारण आप इस खंड को शुरू करने से पहले पहली बार सफल घुसपैठ में सफल हुए थे। मैं मामले को खत्म नहीं करना चाहता, लेकिन अगर आपने ऐसा नहीं किया है, तो आपको वास्तव में करने की जरूरत है। माफ़ करना।
- कभी भी ब्लैकमेल / सुरक्षा के पैसे न दें। यह एक आसान निशान का संकेत है और आप नहीं चाहते कि यह वाक्यांश कभी आपका वर्णन करे।
- एक ही सर्वर (एस) को बिना पूर्ण पुनर्निर्माण के ऑनलाइन वापस करने का प्रलोभन न दें। पुराने बॉक्स पर एक नया बॉक्स बनाने या "सर्वर से nuke सर्वर को साफ करने और एक क्लीन इन्स्टॉल करने के लिए" यह जल्दी होना चाहिए, क्योंकि पुराने सिस्टम के हर एक कोने को ऑडिट करना होगा, यह सुनिश्चित करने के लिए कि इसे वापस डालने से पहले यह साफ हो। फिर से ऑनलाइन। यदि आप इससे सहमत नहीं हैं, तो आप शायद यह नहीं जानते कि सिस्टम को पूरी तरह से साफ करने का वास्तव में क्या मतलब है, या आपकी वेबसाइट परिनियोजन प्रक्रिया एक अपवित्र गड़बड़ है। आपके पास निश्चित रूप से आपकी साइट के बैकअप और परीक्षण परिनियोजन हैं, जिनका उपयोग आप केवल लाइव साइट बनाने के लिए कर सकते हैं, और यदि आप नहीं करते हैं तो हैक होना आपकी सबसे बड़ी समस्या नहीं है।
- हैक के समय सिस्टम पर "लाइव" डेटा का उपयोग करने के बारे में बहुत सावधान रहें। मैं यह नहीं कहूंगा कि "कभी भी ऐसा न करें" क्योंकि आप सिर्फ मुझे अनदेखा करेंगे, लेकिन मुझे लगता है कि जब आप जानते हैं कि आपको इसकी अखंडता की गारंटी नहीं हो सकती है, तो आपको डेटा रखने के परिणामों पर विचार करने की आवश्यकता है। आदर्श रूप से, आपको घुसपैठ से पहले किए गए बैकअप से इसे पुनर्स्थापित करना चाहिए। यदि आप ऐसा नहीं कर सकते हैं या नहीं करेंगे, तो आपको उस डेटा से बहुत सावधान रहना चाहिए क्योंकि यह दागी है। आपको विशेष रूप से दूसरों को इसके परिणामों के बारे में पता होना चाहिए यदि यह डेटा ग्राहकों या साइट के आगंतुकों से संबंधित है बजाय सीधे आपके।
- सिस्टम की निगरानी ध्यान से करें। आपको भविष्य में (नीचे और अधिक) चल रही प्रक्रिया के रूप में इसे करने का संकल्प करना चाहिए, लेकिन आप अपनी साइट पर ऑनलाइन वापस आने के तुरंत बाद की अवधि में सतर्क रहने के लिए अतिरिक्त दर्द उठाते हैं। घुसपैठिए लगभग निश्चित रूप से वापस आ जाएंगे, और यदि आप उन्हें फिर से तोड़ने की कोशिश कर सकते हैं, तो आप निश्चित रूप से जल्दी से देख पाएंगे यदि आपने वास्तव में उन सभी छेदों को बंद कर दिया है जो वे अपने लिए किए गए किसी भी उपयोग से पहले करते हैं, और आप उपयोगी हो सकते हैं जानकारी जिसे आप अपने स्थानीय कानून प्रवर्तन में पास कर सकते हैं।
भविष्य में जोखिम को कम करना।
पहली बात जो आपको समझने की ज़रूरत है वह यह है कि सुरक्षा एक ऐसी प्रक्रिया है जिसे आपको इंटरनेट-फेसिंग प्रणाली के डिजाइनिंग, तैनाती और रखरखाव के पूरे जीवन-चक्र में लागू करना है, न कि कुछ ऐसी चीज़ों पर जिन्हें आप अपने कोड के बाद कुछ परतों पर थप्पड़ मार सकते हैं जैसे सस्ते रंग। ठीक से सुरक्षित होने के लिए, एक सेवा और एक आवेदन को परियोजना के प्रमुख लक्ष्यों में से एक के रूप में इसे ध्यान में रखकर शुरू किया जाना चाहिए। मुझे लगता है कि यह उबाऊ है और आपने यह सब पहले सुना है और मुझे अपनी बीटा web2.0 (बीटा) सेवा को वेब पर बीटा स्थिति में प्राप्त करने का "सिर्फ दबाव आदमी का एहसास नहीं है", लेकिन तथ्य यह है कि यह रखता है दोहराया जा रहा है क्योंकि यह पहली बार सच कहा गया था और यह अभी तक झूठ नहीं बन गया है।
आप जोखिम को खत्म नहीं कर सकते। आपको ऐसा करने की कोशिश भी नहीं करनी चाहिए। हालांकि आपको क्या करना चाहिए यह समझने के लिए कि आपके लिए कौन से सुरक्षा जोखिम महत्वपूर्ण हैं, और जोखिम के प्रभाव और जोखिम दोनों होने की संभावना को प्रबंधित करने और कम करने के तरीके को समझें ।
किसी हमले के सफल होने की संभावना को कम करने के लिए आप क्या कदम उठा सकते हैं?
उदाहरण के लिए:
- क्या वह दोष था जो लोगों को आपकी साइट को विक्रेता कोड में एक ज्ञात बग में तोड़ने की अनुमति देता था, जिसके लिए एक पैच उपलब्ध था? यदि हां, तो क्या आपको अपने दृष्टिकोण पर फिर से विचार करने की आवश्यकता है कि आप अपने इंटरनेट-फेसिंग सर्वर पर एप्लिकेशन को कैसे पैच करते हैं?
- क्या वह दोष था जिसने लोगों को आपकी साइट पर वेंडर कोड में एक अज्ञात बग बनाने की अनुमति दी थी, जिसके लिए एक पैच उपलब्ध नहीं था? मैं निश्चित रूप से बदलते आपूर्तिकर्ताओं की वकालत नहीं करता जब भी कुछ इस तरह आपको काटता है क्योंकि उनकी सभी समस्याएं हैं और आप इस दृष्टिकोण को लेने पर सबसे अधिक एक साल में प्लेटफार्मों से बाहर निकल जाएंगे। हालांकि, यदि कोई सिस्टम आपको लगातार नीचे जाने देता है, तो आपको या तो कुछ अधिक मजबूत पर पलायन करना चाहिए या बहुत कम से कम, अपने सिस्टम को फिर से आर्किटेक्ट करना चाहिए ताकि कमजोर घटक रुई के फाहे में लिपटे रहें और जहां तक हो सके शत्रुतापूर्ण नजर से दूर रहें।
- क्या दोष आपके द्वारा विकसित कोड (या आपके लिए काम करने वाले ठेकेदार) में एक बग था? यदि हां, तो क्या आपको अपने दृष्टिकोण पर फिर से विचार करने की आवश्यकता है कि आप अपनी लाइव साइट पर तैनाती के लिए कोड को कैसे अनुमोदित करते हैं? क्या बग को एक बेहतर परीक्षण प्रणाली के साथ, या आपके कोडिंग "मानक" में परिवर्तन के साथ पकड़ा जा सकता है (उदाहरण के लिए, जबकि तकनीक रामबाण नहीं है, आप अच्छी तरह से प्रलेखित कोडिंग तकनीकों का उपयोग करके एक सफल एसक्यूएल इंजेक्शन हमले की संभावना को कम कर सकते हैं। )।
- क्या सर्वर या एप्लिकेशन सॉफ़्टवेयर को तैनात करने की समस्या के कारण दोष था? यदि हां, तो क्या आप सर्वर का निर्माण करने और जहां संभव हो उसे तैनात करने के लिए स्वचालित प्रक्रियाओं का उपयोग कर रहे हैं? ये आपके सभी सर्वरों पर एक सुसंगत "बेसलाइन" स्थिति बनाए रखने में बहुत मदद करते हैं, प्रत्येक पर किए जाने वाले कस्टम काम की मात्रा को कम करते हैं और इसलिए गलती होने के अवसर की उम्मीद कम से कम करते हैं। समान कोड परिनियोजन के साथ जाता है - यदि आपको अपने वेब ऐप के नवीनतम संस्करण को तैनात करने के लिए कुछ "विशेष" करने की आवश्यकता है, तो इसे स्वचालित करने के लिए कड़ी मेहनत करें और यह सुनिश्चित करें कि यह हमेशा सुसंगत तरीके से किया जाए।
- क्या आपके सिस्टम की बेहतर निगरानी के साथ घुसपैठ को पहले पकड़ा जा सकता था? बेशक, आपके कर्मचारियों के लिए 24-घंटे की निगरानी या "ऑन कॉल" प्रणाली प्रभावी नहीं हो सकती है, लेकिन ऐसी कंपनियां भी हैं जो आपके लिए आपकी वेब फेसिंग सेवाओं की निगरानी कर सकती हैं और किसी समस्या की स्थिति में आपको सतर्क कर सकती हैं। आप तय कर सकते हैं कि आप इसे बर्दाश्त नहीं कर सकते या इसकी आवश्यकता नहीं है और यह ठीक है ... बस इसे ध्यान में रखें।
- ट्रिपवायर और नेसस जैसे उपकरण जहां उचित हो - का उपयोग करें, लेकिन बस उन्हें आँख बंद करके उपयोग न करें क्योंकि मैंने ऐसा कहा था। यह जानने के लिए समय निकालें कि कुछ अच्छे सुरक्षा उपकरणों का उपयोग कैसे करें जो आपके वातावरण के लिए उपयुक्त हैं, इन उपकरणों को अद्यतन रखें और नियमित रूप से उनका उपयोग करें।
- नियमित आधार पर अपनी वेबसाइट की सुरक्षा को 'ऑडिट' करने के लिए सुरक्षा विशेषज्ञों को काम पर रखने पर विचार करें। फिर, आप तय कर सकते हैं कि आप इसे बर्दाश्त नहीं कर सकते या इसकी आवश्यकता नहीं है और यह ठीक है ... बस इसे ध्यान में रखें।
एक सफल हमले के परिणामों को कम करने के लिए आप क्या कदम उठा सकते हैं?
यदि आप तय करते हैं कि आपके घर के निचले तल की "जोखिम" अधिक है, लेकिन वारंट हिलाने के लिए पर्याप्त नहीं है, तो आपको कम से कम अपूरणीय परिवार के उत्तराधिकारियों को ऊपर ले जाना चाहिए। सही?
- क्या आप इंटरनेट से सीधे संपर्क में आने वाली सेवाओं की मात्रा कम कर सकते हैं? क्या आप अपनी आंतरिक सेवाओं और अपनी इंटरनेट-फेसिंग सेवाओं के बीच किसी प्रकार का अंतर रख सकते हैं? यह सुनिश्चित करता है कि भले ही आपके आंतरिक सिस्टम सीमित होने के लिए आपके बाहरी सिस्टम इसे स्प्रिंगबोर्ड के रूप में उपयोग करने की संभावना से समझौता कर लें।
- क्या आप ऐसी जानकारी संग्रहीत कर रहे हैं जिसे आपको संग्रहीत करने की आवश्यकता नहीं है? क्या आप ऐसी जानकारी "ऑनलाइन" संग्रहीत कर रहे हैं जब इसे कहीं और संग्रहीत किया जा सकता है। इस भाग के दो बिंदु हैं; स्पष्ट यह है कि लोग आपसे ऐसी जानकारी नहीं चुरा सकते जो आपके पास नहीं है, और दूसरा बिंदु यह है कि आप जितना कम स्टोर करेंगे, आपको बनाए रखने और कोड करने की आवश्यकता उतनी ही कम होगी, और इसलिए कीड़े के फिसलने की संभावना कम है। आपका कोड या सिस्टम डिज़ाइन
- क्या आप अपने वेब ऐप के लिए "कम से कम एक्सेस" सिद्धांतों का उपयोग कर रहे हैं? यदि उपयोगकर्ताओं को केवल डेटाबेस से पढ़ने की आवश्यकता है, तो यह सुनिश्चित करें कि वेब ऐप का उपयोग करने वाले खाते का उपयोग केवल इसने पढ़ा है, इसे एक्सेस लिखने की अनुमति न दें और निश्चित रूप से सिस्टम-स्तरीय एक्सेस न करें।
- यदि आप किसी चीज़ में बहुत अनुभवी नहीं हैं और यह आपके व्यवसाय के लिए केंद्रीय नहीं है, तो इसे आउटसोर्सिंग पर विचार करें। दूसरे शब्दों में, यदि आप डेस्कटॉप एप्लिकेशन कोड लिखने के बारे में बात करने वाली एक छोटी सी वेबसाइट चलाते हैं और साइट से छोटे डेस्कटॉप एप्लिकेशन बेचना शुरू करने का निर्णय लेते हैं, तो अपने क्रेडिट कार्ड ऑर्डर सिस्टम को "आउटसोर्सिंग" करें जैसे कि किसी को पेपल।
- यदि संभव हो, तो अपने डिजास्टर रिकवरी प्लान के समझौता किए गए सिस्टम से रिकवरी का अभ्यास करें। यह यकीनन एक और "आपदा परिदृश्य" है जिसका सामना आप कर सकते हैं, बस अपनी समस्याओं और मुद्दों के अपने सेट के साथ जो सामान्य से भिन्न हैं 'सर्वर रूम में आग लग गई' / 'को विशाल सर्वर द्वारा फरारी खाने की तरह से आक्रमण किया गया था। (संपादित करें, प्रति XTZ)
... और अंत में
मैंने शायद सामान का कोई अंत नहीं छोड़ा है जो दूसरों को महत्वपूर्ण मानते हैं, लेकिन ऊपर दिए गए कदम कम से कम आपको चीजों को छांटने में मदद करना चाहिए अगर आप हैकर्स के शिकार होने के लिए पर्याप्त रूप से बदकिस्मत हैं।
इन सबसे ऊपर: घबराओ मत। करने से पहले सोचो। यदि आपने कोई निर्णय लिया है तो एक बार दृढ़ता से कार्य करें, और मेरे चरणों की सूची में कुछ जोड़ने के लिए नीचे एक टिप्पणी छोड़ दें।
