हैकिंग की रोकथाम, फोरेंसिक, ऑडिटिंग और काउंटर उपाय


11

हाल ही में (लेकिन यह एक आवर्तक प्रश्न भी है) हमने हैकिंग और सुरक्षा के बारे में 3 दिलचस्प सूत्र देखे:

मैं एक समझौता किए गए सर्वर से कैसे निपटूं?
यह पता लगाना कि हैक किए गए सर्वर को फ़ाइल अनुमतियों को हैक कैसे किया गया था

पिछले एक सीधे संबंधित नहीं है, लेकिन यह उजागर करता है कि वेब सर्वर प्रशासन के साथ गड़बड़ करना कितना आसान है।

जैसा कि कई चीजें हैं, जो हो सकता है, कुछ बुरा होने से पहले , मैं आपके सुझावों को एक हमले के पीछे के प्रभावों को सीमित करने के लिए अच्छे व्यवहार के संदर्भ में रखना चाहता हूं और दुख की स्थिति में प्रतिक्रिया कैसे करें।

यह केवल सर्वर और कोड हासिल करने की बात नहीं है, बल्कि ऑडिटिंग, लॉगिंग और काउंटर उपायों की भी है।

क्या आपके पास कोई अच्छी प्रैक्टिस सूची है या क्या आप सॉफ्टवेयर पर या ऐसे विशेषज्ञों पर भरोसा करना पसंद करते हैं जो लगातार आपके वेब सर्वर (या कुछ भी नहीं) का विश्लेषण करते हैं?

यदि हाँ, तो क्या आप अपनी सूची और अपने विचार / राय साझा कर सकते हैं?

अपडेट करें

मुझे कई अच्छी और दिलचस्प प्रतिक्रिया मिली।

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

भले ही हर कोई अच्छा और सही जवाब देता है, फिलहाल मैं रॉबर्ट में से एक को पसंद करता हूं क्योंकि यह सबसे सरल, स्पष्ट और संक्षिप्त है और sysadmin1138 में से एक है क्योंकि यह सबसे पूर्ण और सटीक है।

लेकिन कोई भी उपयोगकर्ता के दृष्टिकोण और धारणा पर विचार नहीं करता है, मुझे लगता है कि यह पहला विचार है।

जब उपयोगकर्ता मेरी हैक की गई साइट पर जाएंगे, तो आप क्या सोचेंगे, यदि आप उनके बारे में समझदार डेटा रखते हैं। यह केवल डेटा का स्टॉक करने के लिए नहीं है, बल्कि नाराज उपयोगकर्ताओं को कैसे शांत किया जाए।

डेटा, मीडिया, अधिकारियों और प्रतियोगियों के बारे में क्या?


3
Security.stackexchange.com से शुरू करें । हालाँकि यहाँ पहले से ही कुछ अच्छे उत्तर हैं ....
एवीडी

अच्छी बात! मुझे नहीं पता था कि एक है, मैंने सोचा कि पूरी सूची प्रत्येक स्टैक वेबसाइटों के पाद लेख में है।
tmow

मुझे लगता है कि बीटा साइटें फुलफिल्ड साइटों पर दिखाई नहीं देती हैं। और, fullfledged साइटों बीटा पाद पर या तो :) नहीं हैं
शौकीन चावला

जवाबों:


11

ध्यान केंद्रित करने के लिए दो बड़े क्षेत्र हैं:

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

मुश्किल हो रही है अंदर जाने के लिए

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

  • लॉग रखें (यह भी देखें, सुरक्षा सूचना इवेंट मैनेजमेंट)
    • किसी भी प्राधिकरण के प्रयास, दोनों सफल और असफल, अधिमानतः स्रोत जानकारी के साथ बरकरार है।
    • फ़ायरवॉल एक्सेस लॉग्स (इसमें प्रति सर्वर फ़ायरवॉल शामिल हो सकते हैं, यदि उपयोग में हों)।
    • वेबसर्वर एक्सेस लॉग
    • डेटाबेस सर्वर प्रमाणीकरण लॉग
    • अनुप्रयोग-विशिष्ट उपयोग लॉग
    • यदि संभव हो, तो CRM संदिग्ध पैटर्न पर अलर्ट फेंक सकता है।
  • उचित अभिगम नियंत्रण लागू करें
    • सुनिश्चित करें कि अधिकार हर जगह सही तरीके से सेट किए गए हैं, और जहां संभव हो वहां 'आलसी-अधिकारों' ("ओह बस सभी को पढ़ने दें") से बचें।
    • एसीएल के आवधिक ऑडिट यह सुनिश्चित करने के लिए कि प्रक्रियाओं का वास्तव में पालन किया जा रहा है, और अस्थायी समस्या निवारण चरणों ("सभी को पढ़ें, देखें कि यह काम करता है") समस्या निवारण समाप्त होने के बाद सही ढंग से हटा दिया गया है।
    • सभी फ़ायरवॉल पास-थ्रू नियमों को उचित और समय-समय पर ऑडिट करने की आवश्यकता है।
    • वेबसर्वर एक्सेस कंट्रोल को वेबसर्वर और फाइलसिस्टम ACL दोनों के साथ ही ऑडिट करने की आवश्यकता है।
  • परिवर्तन-प्रबंधन लागू करें
    • सुरक्षा वातावरण में किसी भी परिवर्तन को एक से अधिक लोगों द्वारा केंद्रीय रूप से ट्रैक और समीक्षा किए जाने की आवश्यकता है।
    • पैच को इस प्रक्रिया में शामिल किया जाना चाहिए।
    • एक सामान्य OS बिल्ड (टेम्प्लेट) होने से पर्यावरण सरल होगा और परिवर्तन को ट्रैक करने और लागू करने में आसानी होगी।
  • अतिथि खाते अक्षम करें।
  • सुनिश्चित करें कि सभी पासवर्ड डिफॉल्ट में सेट नहीं हैं।
    • ऑफ-द-शेल्फ एप्लिकेशन उपयोगकर्ताओं को पूर्वनिर्धारित पासवर्ड के साथ सेटअप कर सकते हैं। उन्हें बदलो।
    • उपयोगकर्ता / पासवर्ड जोड़े के साथ बहुत सारे आईटी उपकरण जहाज जो बहुत अच्छी तरह से ज्ञात हैं। उन्हें बदलें, भले ही आप साल में केवल एक बार उस चीज़ में लॉग इन करें।
  • कम से कम-विशेषाधिकार का अभ्यास करें। उपयोगकर्ताओं को वे एक्सेस दें जिनकी उन्हें वास्तव में आवश्यकता है।
    • व्यवस्थापक उपयोगकर्ताओं के लिए, दो-खाता सेटअप बुद्धिमान है। एक नियमित खाता ईमेल और अन्य कार्यालय कार्यों के लिए उपयोग किया जाता है, और दूसरा एक उन्नत-निजी कार्य के लिए। VMs के साथ रहना आसान बनाता है।
    • सामान्य व्यवस्थापक / रूट खातों के नियमित उपयोग को प्रोत्साहित न करें, यह ट्रैक करना मुश्किल है कि कौन क्या कर रहा था।

नीतियों और प्रक्रियाओं को शांति से और कुशलता से बनाना किसी के अंदर होने की घटना को संभालना

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

संगठन के सभी स्तरों को नीतियों के बारे में पता होना चाहिए। बड़ी घटना, अधिक संभावना ऊपरी प्रबंधन किसी तरह से जुड़ जाएगा, और चीजों को संभालने के लिए निर्धारित प्रक्रियाएं होने से उच्च से "सहायता" को बंद करने में बहुत मदद मिलेगी। यह संगठन के बाकी हिस्सों के साथ इंटरफेस के प्रबंधन के लिए प्रक्रियाओं के रूप में सीधे घटना की प्रतिक्रिया में शामिल तकनीशियनों के लिए एक स्तर का कवर भी देता है।

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

किसी भी घटना प्रतिक्रिया योजना के कुछ घटक:

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

एक समझौते से पहले की नीतियां और प्रक्रियाएँ , और उन लोगों द्वारा अच्छी तरह से जानी जाती हैं, जो उन्हें एक समझौते की स्थिति में लागू करेंगे, यह कुछ ऐसा है जिसे बस करने की ज़रूरत है। यह हर किसी को एक समय में एक प्रतिक्रिया फ्रेमवर्क प्रदान करता है जब लोग सीधे नहीं सोचेंगे। ऊपरी प्रबंधन मुकदमों और आपराधिक आरोपों के बारे में गड़गड़ाहट और उछाल सकता है, लेकिन वास्तव में एक मामले को एक साथ लाना एक महंगी प्रक्रिया है और यह जानना कि पहले से ही रोष को कम करने में मदद मिल सकती है।

मैं यह भी ध्यान देता हूं कि इस प्रकार की घटनाओं को समग्र आपदा प्रतिक्रिया योजना में विभाजित करने की आवश्यकता है। एक समझौता 'खोई हुई हार्डवेयर' प्रतिक्रिया नीति को ट्रिगर करने और 'डेटा हानि' प्रतिक्रिया को ट्रिगर करने की संभावना भी होगी। आपकी सेवा पुनर्प्राप्ति का समय जानने से यह अपेक्षा तय करने में मदद मिलती है कि सेवा-पुनर्प्राप्ति में आवश्यक सुरक्षा प्रतिक्रिया टीम को वास्तविक समझौता प्रणाली (यदि कानूनी साक्ष्य नहीं रखे जा रहे हैं) पर डालने से पहले कितनी देर हो सकती है।


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

फिर भी आपके और रॉबर्ट के जवाब के बीच यकीन नहीं है।
tmow

यह एक महान जवाब है, काश मैं सिर्फ +1 के बजाय +2
रोब मोइर

7

उचित हेल्पडेस्क प्रक्रियाएं कैसे मदद कर सकती हैं

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

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

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

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

कैसे परिनियोजन मानक मदद कर सकते हैं

एक सेट टेम्प्लेट (या कम से कम एक चेकलिस्ट) पर नियोजन करना, साथ ही किसी भी कस्टमाइज़ेशन / अपने तैनाती टेम्पलेट पर अपग्रेड / प्रबंधन में परिवर्तन नियंत्रण / प्रबंधन का अभ्यास करने में भी मदद करता है। अलग-अलग कार्य करने वाले सर्वर (जैसे एक मेल सर्वर टेम्पलेट, एक वेब सर्वर टेम्पलेट, आदि) के लिए आपके पास कई टेम्पलेट हो सकते हैं।

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

यह कई तरीकों से मदद करता है:

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

1
+1। हां, यह सही है, लेकिन फिर, अगर सब कुछ होता है तो इसका मतलब है कि आपका टेम्प्लेट उतना सुरक्षित नहीं है जितना आपने सोचा था, इसलिए आप इसका उपयोग नई वेबसाइट को तैनात करने के लिए नहीं कर सकते। आपको कम से कम एक रखरखाव पृष्ठ की आवश्यकता होती है जो ग्राहकों को एक अस्थायी मुद्दे के बारे में सूचित करता है और इसे कहीं और होस्ट करने के लिए बेहतर होता है (एक अन्य सर्वर, एक अन्य आईपी और पुराने से पुनर्निर्देशन)। मुझे लगता है कि हमें हमेशा सबसे खराब स्थिति को ध्यान में रखना चाहिए।
tmow

2
@tmow - आप सही हैं लेकिन टेम्पलेट आपको अपने "ज्ञात" कॉन्फ़िगरेशन के लिए एक सिस्टम को जल्दी से बहाल करने की अनुमति देता है, जिसे आपको फिर से सर्वर को तैनात करने से पहले संशोधित करने की आवश्यकता होती है। मैं इस उत्तर को प्रतिबिंबित करने के लिए संशोधन करूंगा क्योंकि इसमें इसका उल्लेख होना चाहिए, आप बिल्कुल वहीं हैं।
रोब मोइर

1
धन्यवाद। उपयोगकर्ता के दृष्टिकोण और धारणा को मत भूलना।
tmow

@tmow ने उपयोगकर्ताओं के बारे में थोड़ा जोड़ा और चीजों के उस छोर के साथ काम करने के लिए समर्थन डेस्क को रखा।
रोब मोइर

4

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


सब ठीक है, मुझे लगता है कि कुछ भी अधिक की आवश्यकता नहीं है, लेकिन फिर, जब ऐसा होता है, क्योंकि ऐसा होता है, वास्तव में आप क्या करते हैं, आपको तेजी से प्रतिक्रिया करने की क्या आवश्यकता है? लॉग की हजारों लाइनों का विश्लेषण, एक तनावपूर्ण स्थिति में बहुत अधिक, कम से कम उपयोगकर्ताओं को सूचित करने के लिए एक त्वरित समाधान या अस्थायी समाधान प्रदान नहीं करेगा।
tmow

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

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

4

आप वास्तव में क्या चाहते हैं 3 बुनियादी क्षेत्रों में नीचे गिर सकते हैं:

  1. मानक प्रणाली विन्यास
  2. सिस्टम / अनुप्रयोग निगरानी
  3. घटना की प्रतिक्रिया

यदि आपके पास कोई जानकारी (आश्वासन | सुरक्षा) स्टाफ उपलब्ध है, तो आपको निश्चित रूप से उनसे बात करनी चाहिए। जबकि इंसीडेंट रिस्पांस अक्सर उक्त कार्यालय का एकमात्र उद्देश्य होता है, बाकी सभी प्रभावित पक्षों के लिए एक संयुक्त विकास प्रयास होना चाहिए।

सेल्फ-पिंपिंग के जोखिम पर, संबंधित प्रश्न का यह उत्तर आपके लिए बहुत सारे उपयोगी संसाधनों को अनुक्रमित करना चाहिए: एक LAMP सर्वर की सुरक्षा के लिए टिप्स।

आदर्श रूप से, आपके पास समर्थित ओएस की सबसे छोटी संख्या होनी चाहिए, और आधार छवि का उपयोग करके प्रत्येक को बनाना चाहिए। आपको केवल उसी आधार से विचलन करना चाहिए जो सर्वर द्वारा प्रदान की जाने वाली सेवाओं को प्रदान करने के लिए आवश्यक है। यदि आपको PCI / HIPAA / etc मिलना है तो विचलन को प्रलेखित किया जाना चाहिए, या इसकी आवश्यकता हो सकती है। या अन्य अनुपालन। तैनाती और विन्यास प्रबंधन प्रणाली का उपयोग इस संबंध में बहुत मदद कर सकता है। विनिर्देश आपके ओएस, मोची / कठपुतली / Altiris / DeployStudio / SCMM, आदि पर बहुत कुछ निर्भर करेगा।

आपको कुछ प्रकार की नियमित लॉग समीक्षा जरूर करनी चाहिए। विकल्प को देखते हुए एक CRM बहुत मददगार हो सकता है , लेकिन उनके पास खरीद मूल्य और बिल्ड-आउट लागत दोनों में महंगा होने का नकारात्मक पहलू है। लॉग विश्लेषण पर कुछ टिप्पणियों के लिए आईटी सिक्योरिटी एसई साइट से इस प्रश्न की जाँच करें : आप लॉग विश्लेषण को कैसे संभालते हैं? यदि यह अभी भी भारी है, तो लॉगवॉच जैसे सामान्य उपकरण भी क्या चल रहा है, इसके लिए कुछ अच्छे संदर्भ प्रदान कर सकते हैं। हालांकि, महत्वपूर्ण टुकड़ा, केवल लॉग को देखने के लिए समय ले रहा है। यह आपको सामान्य व्यवहार का गठन करने में परिचित होने में मदद करेगा, ताकि आप असामान्य को पहचान सकें।

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


मैं लगभग हर बात पर सहमत हूं लेकिन यह मुख्य रूप से मध्यम और बड़ी कंपनियों पर लागू होता है। छोटे आकार की कंपनियों को इस तरह के महंगे ढांचे की जरूरत नहीं होगी।
tmow


2

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


2

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

http://www.scribd.com/doc/19982/OWASP-Web-Security-Guide

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