मुझे फ़ायरवॉल सर्वर क्यों चाहिए?


104

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

हालांकि, मैं ऐसे लोगों से जवाब ढूंढ रहा हूं जो सुरक्षा के विशेषज्ञ हैं । मेरा मानना ​​है कि यह एक महत्वपूर्ण सवाल है, और इस जवाब से मुझे और मेरे द्वारा काम करने वाली कंपनी को ही फायदा होगा। मैं कई वर्षों से बिना किसी समझौते के, बिना किसी फ़ायरवॉल के हमारे सर्वर नेटवर्क को चला रहा हूँ। कोई भी सुरक्षा समझौता जो हमारे पास नहीं था, एक फ़ायरवॉल के साथ रोका जा सकता था।

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

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

यह सर्वर सुरक्षा के लिए मेरा दृष्टिकोण है:

  1. मेरे सर्वर को इंटरनेट से जोड़ने से पहले मेरे ऑपरेटिंग सिस्टम के सुरक्षा दिशानिर्देशों का पालन करें ।

  2. कम संख्या में IP पतों पर SSH (और अन्य प्रबंधन सेवाओं) तक पहुँच को प्रतिबंधित करने के लिए TCP रैपर का उपयोग करें।

  3. मुनिन के साथ इस सर्वर की स्थिति की निगरानी करें । और इसके डिफ़ॉल्ट कॉन्फ़िगरेशन में मुनिन-नोड के लिए निहित गंभीर सुरक्षा समस्याओं को ठीक करें।

  4. मेरा नया सर्वर Nmap (इंटरनेट से मेरा सर्वर कनेक्ट करने से पहले भी)। यदि मैं इस सर्वर को फ़ायरवॉल के लिए कर रहा था, तो यह बंदरगाहों का सटीक सेट होना चाहिए जो आने वाले कनेक्शनों तक सीमित होना चाहिए।

  5. सर्वर रूम में सर्वर स्थापित करें और इसे एक सार्वजनिक आईपी पता दें।

  6. मेरे ऑपरेटिंग सिस्टम की सुरक्षा अपडेट सुविधा का उपयोग करके सिस्टम को सुरक्षित रखें।

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

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

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

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


2
और इसलिए आपके सर्वर के बीच से गुजरने वाले सभी ट्रैफ़िक को एन्क्रिप्ट किया गया है?
ग्रेग

5
इसे प्यार करना। स्थानीय फ़ायरवॉल नियम लगभग हमेशा ही वूडू हैं।
4

2
क्या आपके नेटवर्क में भी डेस्कटॉप / कर्मचारी हैं? आप उन लोगों के साथ क्या करेंगे?
ब्रैंडन


2
@routeNpingme: ऐसा लगता है कि मैंने अपने मूल पोस्ट में उस tidbit को शामिल नहीं किया। हमारे सभी सर्वरों को जनता के लिए खुला होना चाहिए, और एक समर्पित डेटासेंटर में रहना होगा। यदि आपका कार्यालय आपका डेटासेंटर है, तो मुझे लगता है कि आपके सर्वर नेटवर्क और आपके कार्यालय नेटवर्क के बीच फ़ायरवॉल होना आवश्यक होगा। किस मामले में, मैं सर्वर नेटवर्क के बारे में बात कर रहा हूं - क्यों फ़ायरवॉल कुछ ऐसा है जिसमें पूर्ण सार्वजनिक पहुंच है?
एर्नी

जवाबों:


54

फ़ायरवॉल के लाभ:

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

इन सबसे ऊपर अगर आपके पास फ़ायरवॉल नहीं है और सिस्टम से छेड़छाड़ की जाती है तो आप इसका पता कैसे लगाएंगे? स्थानीय सिस्टम पर कुछ कमांड 'ps', 'netstat' आदि चलाने की कोशिश नहीं की जा सकती क्योंकि उन बायनेरिज़ को बदला जा सकता है। रिमोट सिस्टम से 'नैम्प' की सुरक्षा की गारंटी नहीं है क्योंकि एक हमलावर सुनिश्चित कर सकता है कि रूट-किट केवल चयनित स्रोत आईपी पते से कनेक्शन स्वीकार करता है।

हार्डवेयर फ़ायरवॉल ऐसे परिदृश्यों में मदद करते हैं क्योंकि होस्ट OS / फ़ाइलों की तुलना में फ़ायरवॉल OS / फ़ाइलों को बदलना बहुत मुश्किल है।

फ़ायरवॉल के नुकसान:

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

6
Above all this if you do not have firewall and system is compromised then how would you detect it?घुसपैठ का पता लगाना फ़ायरवॉल का काम नहीं है। यह काम अधिक रूप से HIDS (मेजबान-आधारित घुसपैठ का पता लगाने वाली प्रणाली) द्वारा संचालित किया जाता है, जो फ़ायरवॉल से स्वतंत्र है।
स्टीवन सोमवार

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

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

2
यह उत्तर अधिक लोकप्रिय एक पर स्वीकार किया गया था क्योंकि यह फ़ायरवॉल का उपयोग करने के लिए बेहतर और अधिक व्यापक कारण प्रदान करता है। और नहीं, उस बात के लिए।
Ernie

स्टेटफ़ुल पैकेट निरीक्षण फ़ायरवॉल सर्वरों के सामने नहीं हैं। वे DDoS हमलों में एक बड़ी देयता हैं, और आम तौर पर हमले के तहत असफल होने वाली पहली चीज हैं।
ralayter

33

टीसीपी रैपर्स को यकीनन एक मेजबान-आधारित फ़ायरवॉल कार्यान्वयन कहा जा सकता है; आप नेटवर्क ट्रैफ़िक फ़िल्टर कर रहे हैं।

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

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

असल में, एक फ़ायरवॉल सक्रिय संरक्षण है। आगे आप सक्रिय होने से दूर हो जाते हैं, सबसे अधिक संभावना है कि आप खुद को ऐसी स्थिति में पाएंगे जहां आप समस्या को रोकने के बजाय समस्या पर प्रतिक्रिया कर रहे हैं। सीमा पर अपनी सुरक्षा को ध्यान में रखते हुए, एक समर्पित फ़ायरवॉल के साथ, चीजों को प्रबंधित करना आसान बनाता है क्योंकि आपके पास हर जगह नियमों की नकल करने के बजाय एक केंद्रीय चोक बिंदु है।

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


6
इसके अलावा अगर वे इमारत के अंदर घुसते हैं और बाहर अपने दोस्त के लिए अंदर का दरवाजा खोलते हैं, तो उन्हें बाहरी दरवाजे को भी खोलना और खोलना होगा। (यानी एक बाहरी फ़ायरवॉल के बिना, कोई है जो अपने सर्वर में हो जाता है खोल सकते हैं ठीक है, जबकि एक बाहरी फ़ायरवॉल अभी भी बाहर से खुला बंदरगाहों को ब्लॉक कर देगा)
Ricket

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

1
@ ईनी - नहीं, यह केवल वेयरज़, ग्राहक डेटाबेस, वित्तीय जानकारी, पासवर्ड और बॉटनेट में जोड़े जाने के लिए स्वत: रिक्त स्थान के लिए स्वचालित रूप से जांच की जानी चाहिए। अगर ऐसा लगता है कि आप लाश की मेजबानी करते हैं।
रोरी अलसोप

TCP Wrappers could be arguably called a host-based firewall implementationएक महान जवाब के लिए +1।
22

15

(आप " फायरवॉल के बिना जीवन " पढ़ना चाह सकते हैं )

अब: उस विरासत प्रणाली के बारे में क्या जिसके लिए कोई पैच अब प्रकाशित नहीं होता है? जिस समय आपको ऐसा करने की आवश्यकता होती है, उस समय पैच को एन-मशीनों पर लागू करने में सक्षम नहीं होने के बारे में, जबकि एक ही समय में आप उन्हें नेटवर्क (फायरवॉल) में कम नोड्स में लागू कर सकते हैं?

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


1
हे। मैं पिछले 8 वर्षों से बिना फ़ायरवॉल के अपना सर्वर नेटवर्क चला रहा हूँ। मैं "लाइफ विदाउट फायरवॉल" लिख सकता था, लेकिन उसने एक तरह से बेहतर काम किया और एक बड़ा नेटवर्क चला, जैसे मैं।
एरनी

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

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

9

आपके अधिकांश स्पष्टीकरण एक फ़ायरवॉल की आवश्यकता का खंडन करते प्रतीत होते हैं, लेकिन मुझे एक को सेट करने के लिए समय की छोटी राशि के अलावा, एक कोन नहीं दिखता है।

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

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

आपके प्रश्न के व्यावहारिक नोट पर मेरे लिए सबसे महत्वपूर्ण यह है कि आप SSH, ICMP, और अन्य आंतरिक सेवाओं को स्थानीय सबनेट्स के साथ-साथ DOS हमलों को कम करने के लिए आने वाले कनेक्शनों को दर सीमा में बंद कर सकते हैं।

"एक सफल हमले के बाद सुरक्षा का मुद्दा खुद का बचाव नहीं करता है - यह पहले से ही असंभव साबित हो रहा है - यह हमलावरों को पहले स्थान पर रखना है।"

मैं असहमत हूं। नुकसान सीमित करना उतना ही महत्वपूर्ण हो सकता है। (इस आदर्श के अंतर्गत हैश पासवर्ड क्यों? या अपने वेब एप्लिकेशनों की तुलना में किसी भिन्न सर्वर पर अपने डेटाबेस सॉफ़्टवेयर को स्टिक करें?) मुझे लगता है कि पुरानी कहावत "अपने सभी अंडे एक टोकरी में न रखें" यहां लागू है।


1
ठीक है, तुम ठीक कह रहे हो, मैंने वहां कोई विपक्ष नहीं रखा। विपक्ष: बढ़ी हुई नेटवर्क जटिलता, विफलता का एकल बिंदु, एकल नेटवर्क इंटरफ़ेस जिसके माध्यम से बैंडविड्थ अड़चन है। इसी तरह, एक फ़ायरवॉल पर की गई प्रशासनिक गलतियाँ आपके पूरे नेटवर्क को मार सकती हैं। और देवता मना करते हैं कि जब आप सर्वर रूम में 20 मिनट की यात्रा करते हैं तो इस बीच आप खुद को इससे बाहर कर लेते हैं।
एर्नी

1
यह पूरी तरह से बयानबाजी हो सकती है, लेकिन जब आप कहते हैं "सुरक्षा आपके द्वारा किए जाने वाले सभी अवरोधों को स्थापित करने के बारे में अधिक है", तो मैं सुनना पसंद करूंगा "सुरक्षा डिफ़ॉल्ट रूप से सब कुछ अवरुद्ध करने के बारे में है, और सावधानीपूर्वक संचालित करने के लिए सख्त न्यूनतम खोलने"।
13th

+1 एक व्यापक सुरक्षा योजना रोकथाम, पहचान और प्रतिक्रिया को कवर करती है।
जिम ओहलोरन

8

Should I firewall my server?अच्छा प्रश्न। ऐसा लगता है कि एक नेटवर्क स्टैक के शीर्ष पर फ़ायरवॉल को थप्पड़ मारने का बहुत कम बिंदु है जो पहले से ही सभी के कनेक्शन के प्रयासों को अस्वीकार कर देता है लेकिन मुट्ठी भर बंदरगाहों जो वैध रूप से खुले हैं। यदि OS में भेद्यता है जो दुर्भावनापूर्ण रूप से तैयार किए गए पैकेट को होस्ट को बाधित / शोषण करने की अनुमति देता है, तो क्या उसी होस्ट पर चलने वाला फ़ायरवॉल शोषण को रोक सकता है? खैर, शायद ...

और वह संभवतः प्रत्येक मेजबान पर फ़ायरवॉल चलाने का सबसे मजबूत कारण है: फ़ायरवॉल नेटवर्क स्टैक भेद्यता को शोषण होने से रोक सकता है। क्या यह एक मजबूत पर्याप्त कारण है? मुझे नहीं पता, लेकिन मुझे लगता है कि कोई भी कह सकता है, "फायरवॉल स्थापित करने के लिए कोई भी कभी भी निकाल दिया गया।"

एक सर्वर पर फ़ायरवॉल चलाने का एक अन्य कारण इन दोनों को अलग करना है अन्यथा दृढ़ता से सहसंबद्ध चिंताएँ:

  1. कहां से, और किस पोर्ट से, क्या मैं कनेक्शन स्वीकार करता हूं?
  2. कौन सी सेवाएं चल रही हैं और कनेक्शन के लिए सुन रहे हैं?

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

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


1
HIDS सिस्टम के उल्लेख के लिए +1।
सैम हेलिके

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

कोई दर्द नहीं, कोई लाभ नहीं, जैसा कि वे कहते हैं। बहुत सारे परिवर्तनों के साथ सर्वर पर, अपेक्षित शोर को फ़िल्टर करना संभव है, जिससे आप अप्रत्याशित पर ध्यान केंद्रित कर सकते हैं।
स्टीवन सोमवार

6

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

बहुत सारे उपकरण हैं जो हम कह सकते हैं कि हमें ज़रूरत नहीं है ... क्या एंटीवायरस के बिना विंडोज कंप्यूटर चलाना संभव है? हाँ यह है ... लेकिन यह बीमा की एक अच्छी परत है।

मैं फ़ायरवॉल के बारे में भी यही कहूँगा - जो भी आप उनके बारे में कह सकते हैं, वे बीमा का एक अच्छा स्तर हैं। वे पैचिंग का विकल्प नहीं हैं, मशीनों को बंद करने के लिए, आपके द्वारा उपयोग की जाने वाली सेवाओं को अक्षम करने के लिए, लॉगिंग आदि के लिए ... लेकिन वे एक उपयोगी पूरक हो सकते हैं।

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

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


1
इस प्रकार मैंने "ऑफिस नेटवर्क" के बजाय "सर्वर" कहा है? :) हमारे मामले में विशेष रूप से, डेटासेंटर और कार्यालय दो शारीरिक रूप से अलग-अलग संस्थाएं हैं।
एर्नी

मैं समझता हूं कि एर्नी, लेकिन यह एक ऐसा बिंदु है जो रेखांकित करने लायक है ... इसलिए मैंने किया।
रॉब मिर

5

सभी महान प्रश्न। लेकिन - मुझे बहुत आश्चर्य है कि प्रदर्शन को मेज पर नहीं लाया गया है।

अत्यधिक (CPU-वार) वेब फ्रंट एंड्स का उपयोग करने के लिए, स्थानीय फ़ायरवॉल वास्तव में प्रदर्शन, अवधि को घटा देता है। लोड परीक्षण का प्रयास करें और देखें। मैंने कई बार इस टन को देखा। फ़ायरवॉल बंद करने से प्रदर्शन (प्रति सेकंड अनुरोध) में 70% या उससे अधिक की वृद्धि हुई।

इस व्यापार बंद पर विचार किया जाना चाहिए।


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

4

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


+1 पूरी तरह से, गहराई में रक्षा महत्वपूर्ण है।
जिम ओहलोरन

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

3

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


3

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

भूमिकाओं का पृथक्करण

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

सॉफ्टवेयर एक गतिशील लक्ष्य है

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

अपडेट की बात करें तो, फ़ायरवॉल फ़र्मवेयर अपडेट आम तौर पर साल में एक या दो बार आते हैं, जबकि OS और सर्विस अपडेट एक निरंतर स्ट्रीम होते हैं।

पुन: प्रयोज्य सेवाओं / नीतियों / नियमों, प्रबंधन क्षमता

अगर मैं एक बार "वेब सर्वर" नामक एक सेवा / नीति स्थापित करता हूं (टीसीपी 80 और टीसीपी 443 कहते हैं), और इसे फ़ायरवॉल स्तर पर "वेब सर्वर समूह" पर लागू करें, जो कि बहुत अधिक कुशल है (कॉन्फ़िगरेशन परिवर्तन की एक जोड़ी) और 10 बॉक्स पर फ़ायरवॉल सेवाओं को स्थापित करने और 2 पोर्ट x 10 बार खोलने की तुलना में मानव त्रुटि के लिए तेजी से कम प्रवण। जब उस नीति को बदलना होगा, तो यह 1 परिवर्तन बनाम 10 है।

मैं अभी भी एक हमले के दौरान, या एक समझौते के बाद एक फ़ायरवॉल का प्रबंधन कर सकता हूं

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

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

स्वतंत्र निगरानी

समर्पित फ़ायरवॉल इकाइयों में लॉगिंग आमतौर पर होस्ट-आधारित सॉफ़्टवेयर फ़ायरवॉल से बेहतर है। कुछ अच्छे हैं कि आपको सटीक तस्वीर प्राप्त करने के लिए बाहरी एसएनएमपी / नेटफ्लो मॉनिटरिंग सॉफ्टवेयर की भी आवश्यकता नहीं है।

IPv4 संरक्षण

यदि कोई वेब के लिए है और एक मेल के लिए है, तो दो आईपी पते होने का कोई कारण नहीं है। सेवाओं को अलग-अलग बॉक्स पर रखें और ऐसा करने के लिए डिज़ाइन किए गए डिवाइस के माध्यम से बंदरगाहों को उचित रूप से रूट करें।


2

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

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

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

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


It may just open your eyes.+1 क्योंकि यह ताबूत में आखिरी कील होगी।
sjas

2

सामान्य तौर पर, सुरक्षा एक प्याज की चीज है, जैसा कि पहले ही उल्लेख किया गया है। वहाँ कारण फ़ायरवॉल मौजूद हैं, और यह बेवकूफ मूर्खों जा रहा है अन्य सभी lemmings नहीं है।

यह उत्तर आता है, क्योंकि इस पृष्ठ पर 'fail2ban' की खोज ने मुझे कोई परिणाम नहीं दिया। इसलिए अगर मैं अन्य सामग्री को दोगुना करता हूं, तो मेरे साथ सहन करें। और मुझे माफ करना, अगर मैं थोड़ा सा शेख़ी करता हूं, तो मैं सादे अनुभव प्रदान करता हूं क्योंकि यह दूसरों के काम आ सकता है। :)

नेटवर्किंग के विचार, स्थानीय बनाम बाहरी

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

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

लागत और उपलब्धता और हर समय एक ही कहानी:

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

लेकिन क्या होगा अगर पूरा डेटासेंटर अगम्य है, क्योंकि दोनों बाहरी वाहक व्यवसाय से बाहर हैं (खुदाई करने वाले ने आपके फाइबर को मार दिया)? बस अपने क्लस्टर को कई डेटासेंटरों में फैलाएं, फिर।

वो तो महंगा है? क्लस्टर बहुत जटिल हैं? खैर, व्यामोह के लिए भुगतान किया जाना है।

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

यह पैटर्न इन सभी चर्चाओं पर लागू होता है, चाहे वह सेवा दिन का वर्तमान मामला हो। कोई फर्क नहीं पड़ता कि यह एक वीपीएन गेटवे है, सिस्को एएसए सिर्फ फायरवॉलिंग के लिए उपयोग किया जाता है, एक MySQL या पोस्टग्रेक्यूएल डेटाबेस, एक वर्चुअल सिस्टम या सर्वर हार्डवेयर, एक स्टोरेज बैकेंड, स्विच / राउटर, ...

अब तक आप विचार प्राप्त करें।

फायरवॉल से क्यों परेशान?

सिद्धांत रूप में आपका तर्क ध्वनि है। (केवल चल रही सेवाओं का फायदा उठाया जा सकता है।)

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

आसान, केंद्रीय, असतत अभिगम नियंत्रण

आपने टीसीपी रैपर का उल्लेख किया है जो मूल रूप से आपके कार्य को सुरक्षित करने के लिए समान कार्यक्षमता को लागू करता है। तर्क के लिए, मान लें कि किसी को tcpdमाउस का उपयोग करना और पसंद नहीं है ? fwbuilderमन में आ सकता है।

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

एक बहु-सर्वर सेटअप के बारे में कैसे, जहां डेटाबेस कहीं और चलता है और आप दोनों / सभी मशीनों को किसी भी कारण से साझा (निजी) सबनेट में नहीं डाल सकते हैं? केवल सरल, अन्य सर्वर के दिए गए IP पते के लिए पोर्ट 3306 पर MySQL के उपयोग की अनुमति देने के लिए फ़ायरवॉल का उपयोग करें, सरल।

और यह भी यूडीपी के लिए निर्दोष रूप से काम करता है। या जो भी प्रोटोकॉल हो। फायरवॉल इतना लचीला हो सकता है। ;)

पोर्ट्सकॉन शमन

इसके अलावा, फ़ायरवॉलिंग के साथ, सामान्य पोर्टस्कैन का पता लगाया जा सकता है और इसे कम किया जा सकता है क्योंकि प्रति बार कनेक्शन की मात्रा को कर्नेल और उसके नेटवर्किंग स्टैक के माध्यम से मॉनिटर किया जा सकता है, और फ़ायरवॉल उस पर कार्य कर सकता है।

इसके अलावा अमान्य या अस्पष्ट पैकेटों को कभी भी आपके आवेदन तक पहुंचने से पहले संभाला जा सकता है।

आउटबाउंड यातायात सीमित

आउटबाउंड ट्रैफ़िक को फ़िल्टर करना आमतौर पर गधे में दर्द होता है। लेकिन यह एक अनुबंध के आधार पर होना चाहिए।

आंकड़े

एक और बात जो एक फ़ायरवॉल आपको दे सकता है, वह है आँकड़े। ( watch -n1 -d iptables -vnxL INPUTपैकेट के माध्यम से आ रहे हैं, यह देखने के लिए ऊपर की तरफ विशेष आईपी पते के लिए कुछ नियम जोड़े जाने के साथ सोचें ।)

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

आईडीएस / आईपीएस

Layer7 फ़ायरवॉलिंग आमतौर पर साँप-तेल (IPS / IDS) है, यदि ठीक से उपस्थित नहीं है और नियमित रूप से अपडेट किया जाता है। इसके अलावा लाइसेंस महंगे हैं, इसलिए यदि आपको कोई वास्तविक ज़रूरत नहीं है तो आपको हर चीज़ खरीदने के लिए कोई ज़रूरत नहीं है।

Masqerading

आसान, बस अपने रैपर के साथ यह कोशिश करें। : डी

स्थानीय बंदरगाह अग्रेषण

मसलन देखें।

गतिशील आईपी पते के साथ पासवर्ड एक्सेस चैनल सुरक्षित करना

अगर ग्राहकों के पास गतिशील आईपी पते हैं और वीपीएन सेटअप नहीं है तो क्या होगा? या फ़ायरवॉलिंग के लिए अन्य गतिशील दृष्टिकोण? यह पहले से ही प्रश्न में संकेत दिया गया है, और यहाँ दुर्भाग्य के लिए एक उपयोग मामला आएगा , मैं ऐसा करने वाले किसी भी फ़ायरवॉल को नहीं ढूंढ सकता। अंश।

एक पासवर्ड के माध्यम से रूट अकाउंट एक्सेस को अक्षम करना एक आवश्यक है। भले ही एक्सेस कुछ आईपी पते तक सीमित हो।

इसके अलावा, अगर कोई ssh कुंजी खो जाती है या तैनाती विफल हो जाती है, तब भी एक अन्य रिक्त खाता पासवर्ड लॉगिन के साथ तैयार होता है यदि कुछ वास्तव में गलत हो जाता है (उपयोगकर्ता के पास मशीन तक प्रशासनिक पहुंच है और 'चीजें हुईं?')। यह नेटवर्क एक्सेस के लिए समान विचार है क्योंकि यह लिनक्स पर एकल-उपयोगकर्ता मोड है या स्थानीय उपयोग के init=/bin/bashमाध्यम से grubवास्तव में खराब है और जो भी कारण के लिए एक लाइव डिस्क का उपयोग नहीं कर सकता है। हँसो मत, वहाँ वर्चुअलाइजेशन उत्पादों को प्रतिबंधित कर रहे हैं। यहां तक ​​कि अगर कार्यक्षमता मौजूद है, तो क्या होगा यदि एक पुराना सॉफ्टवेयर संस्करण चलाने के लिए कार्यक्षमता की कमी है?

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

आमतौर पर आप दक्षता के कारणों के लिए समान पोर्ट और सेवाओं के साथ एक ही कॉन्फ़िगरेशन वाले सभी सर्वर भी सेट करते हैं। आप हर मशीन पर एक अलग पोर्ट पर ssh सेट नहीं कर सकते। इसके अलावा, जब आप इसे 'सार्वजनिक' जानकारी मानते हैं, तो आप इसे सभी मशीनों पर नहीं बदल सकते, क्योंकि यह स्कैन के बाद पहले से ही है। nmapआपके निपटान में हैक किए गए वाई-फाई कनेक्शन होने पर कानूनी होने या न होने का सवाल कोई मुद्दा नहीं है।

यदि इस खाते का नाम 'रूट' नहीं है, तो लोग आपके 'पिछले दरवाजे' के उपयोगकर्ता खाते के नाम का अनुमान लगाने में सक्षम नहीं हो सकते हैं। लेकिन उन्हें पता चल जाएगा, अगर उन्हें आपकी कंपनी का कोई दूसरा सर्वर मिलता है, या सिर्फ कुछ वेपन्स खरीदते हैं, और उन पर अनचाहे / अनजेंड / अनकंटेक्टेड लुक है /etc/passwd

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

लेकिन विषय पर फिर से, बस एक अतिरिक्त पासवर्ड वाले खाते का उपयोग न करें, और परेशान न करें? कृपया पर पढ़ें।

यहां तक ​​कि अगर हमलावर इस अतिरिक्त खाते का नाम और पोर्ट प्राप्त करने के लिए, एक fail2ban+ iptablesसंयोजन उन्हें छोटा कर देगा, भले ही आपने केवल आठ-अक्षर पासवर्ड का उपयोग किया हो। प्लस फ़ेल 2बन को अन्य सेवाओं के लिए भी लागू किया जा सकता है, निगरानी क्षितिज को चौड़ा करने के लिए भी!

अपनी स्वयं की सेवाओं के लिए, यदि कभी आवश्यकता हुई तो: मूल रूप से किसी फ़ाइल में विफल होने वाली प्रत्येक सेवा लॉगिंग विफल हो सकती है एक फ़ाइल प्रदान करने के माध्यम से सहायता, क्या मेल खाता है और कितनी विफलताओं की अनुमति है, और फ़ायरवॉल सिर्फ हर आईपी पते को खुशी से बताएगा को बताया गया है।

मैं 8-अंकीय पासवर्ड का उपयोग करने के लिए नहीं कह रहा हूँ! लेकिन अगर उन्हें पांच गलत पासवर्ड के लिए 24 घंटे के लिए प्रतिबंधित कर दिया जाता है, तो आप अनुमान लगा सकते हैं कि अगर उन्हें ऐसी घटिया सुरक्षा के साथ भी उनके निपटान में बॉटनेट नहीं है तो उन्हें कितनी देर तक कोशिश करनी होगी। और आप चकित होंगे कि ग्राहक किन पासवर्डों का उपयोग करते हैं, न कि केवल इसके लिए sshPlesk के माध्यम से लोगों के मेल पासवर्डों पर एक नज़र रखने से आपको वह सब कुछ पता चलता है जो आप जानना चाहते हैं, अगर आप कभी भी ऐसा करना चाहते हैं, लेकिन मैं यहाँ क्या करने की कोशिश नहीं कर रहा हूँ। :)

अनुकूली वैश्विक फ़ायरवॉलिंग

fail2banकेवल एक एप्लिकेशन है, जो की तर्ज पर कुछ का उपयोग करता है iptables -I <chain_name> 1 -s <IP> -j DROP, लेकिन आप आसानी से अपने सामान को कुछ बैश जादू के साथ काफी तेजी से बना सकते हैं।

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

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

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


1

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

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

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

आपको लगता है कि आप अपने फ़ायरवॉल के माध्यम से अपने सर्वर से सीधे "बाहरी दुनिया" पैकेट को अग्रेषित कर रहे हैं जो मूल पोस्ट में हैं। उस स्थिति में, हां, आपका फ़ायरवॉल बहुत अधिक काम नहीं कर रहा है। एक बेहतर परिधि रक्षा दो फायरवॉल और एक गढ़ होस्ट के साथ की जाती है, जहां बाहर से अंदर तक कोई सीधा तार्किक कनेक्शन नहीं है - हर कनेक्शन DMZ गढ़ मेजबान में समाप्त होता है; हर पैकेट को अग्रेषित करने से पहले उचित रूप से (और संभवतः पार्स किया गया) की जांच की जाती है।


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

-1 क्योंकि मैंने पहले ही इस तथ्य को कवर कर लिया है कि सर्वर में सेंध लगाने से पहले आपको फ़ायरवॉल में नहीं घुसना है - फ़ायरवॉल को जनता को उस सेवा तक पहुँच प्रदान करने की अनुमति देनी चाहिए जिसे आप जनता के लिए पेश कर रहे हैं , इसलिए सर्वर स्वयं जनता से हमला करने के लिए खुला है। हमारे किसी भी सर्वर पर ऐसी कोई सेवा नहीं है जिसे हम पहले से ही नहीं चाहते हैं कि जनता तक पहुंच हो।
एरनी

@ इरीनी - आप बिंदु को याद करते हैं। एक गढ़ मेजबान डिजाइन DMZ दोनों तरफ से फ़ायरवॉल द्वारा एक मेजबान को अलग करता है। यही कारण है कि मेजबान है हमले के संपर्क में है, और अंततः विकृत कर दिया जाएगा। लेकिन वह होस्ट आपका सर्वर नहीं है और ठीक से उस पर आपकी महत्वपूर्ण जानकारी न्यूनतम मात्रा में होगी। DMZ (host + firewalls) आपके सर्वर पर एक हमले को काफी देर तक धीमा कर देता है जिसे आप प्रतिक्रिया दे सकते हैं और इसकी सफलता को रोक सकते हैं।
mpez0

1
@Per Wiklander - GAAP में नियमित चेक ऑडिट शामिल हैं। एक गबन लेखाकार संख्याओं को पकाने और उपस्थित होने पर उन चेक ऑडिट के दौरान खोज को रोकने में सक्षम हो सकता है, लेकिन यदि लगातार दो सप्ताह तक नौकरी से दूर रहने की आवश्यकता होती है, तो कोई और रिपोर्टिंग करेगा और उनकी खराबी की खोज की जा सकती है। यह दो-व्यक्ति नियंत्रण का एक रूप है।
mpez0

कैसे गढ़ होस्ट सर्वर पर कुछ भी रक्षा करता है? एक उदाहरण: पोर्ट 80, 25 और 110 एक सर्वर पर केवल खुले पोर्ट हैं। फ़ायरवॉल पूरे इंटरनेट से इन बंदरगाहों को यातायात की अनुमति देता है। इसलिए, फ़ायरवॉल कुछ भी नहीं बचाता है। यदि आपके सर्वर आपके कार्यालय से अलग स्थान पर हैं, तो आपको अपने कार्यालय में फ़ायरवॉल के अलावा और किसी सुरक्षा की आवश्यकता नहीं है।
एरनी

1

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

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

पक्षीय लेख; फ़ायरवॉल केवल इंटरनेट के लिए नहीं हैं। आपका लेखा विभाग अपने ldap सर्वर के लिए ssh / जो भी आवश्यक हो, इसलिए उन्हें न दें। आंतरिक सेवाओं को कम्पार्टमेंटलाइज़ करने से इस घटना में सफाई के काम में बड़ा अंतर आ सकता है कि कुछ महल की दीवारों को तोड़ता है।


2
फ़ायरवॉल होने पर बार नहीं उठाया जाता है, जब आपको फ़ायरवॉल नियम खोलने की आवश्यकता होती है कि पोर्ट 80, 53, 25, 110, 143, 443, 993, 995 और अधिक पूरे इंटरनेट पर खुलें। वे सर्वर बिना फ़ायरवॉल के जैसे ही असुरक्षित हैं, अगर आपको इस तरह के नियम बनाने की आवश्यकता है।
Ernie

2
यह सच है, लेकिन उसी सर्वर में संभवतः पोर्ट 3306 (mysql) और कई अन्य प्रोटोकॉल हैं जो संभावित रूप से फ़ायरवॉल से लाभान्वित होंगे। यह कहना नहीं है कि आपको कोई अन्य सुरक्षा नहीं होनी चाहिए; बस यह है कि फ़ायरवॉल को चोट नहीं पहुंच रही है। इसके अलावा, मुझे लगता है कि आपने मेरी बात को याद किया है कि सभी उपयोगकर्ताओं के लिए सभी ट्रैफ़िक को खोलने की आवश्यकता नहीं है। पोर्ट 22 को खोलने की आवश्यकता हो सकती है, लेकिन आपके सभी मेजबानों पर नहीं, और निश्चित रूप से पूरे इंटरनेट (या अकाउंटिंग और एचआर) पर नहीं। लेखांकन के लिए 25 को बंद करना अगर उन्हें 465 से अधिक काम करना है तो उदाहरण के लिए कुछ स्पैम मैलवेयर को कम कर सकते हैं।
Enki

1

एर्नी को कहना है कि जब आप अपने सर्वर को सख्त करने और हमलों और कमजोरियों के खिलाफ कम करने के लिए बहुत कुछ करते हैं, तो मैं फायरवॉल पर आपके रुख से सहमत नहीं हूं।

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

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

अब मैं सुझाव दे रहा हूँ कि फायरवॉल इससे दूर न हों, और न ही फ़ायरवॉल इम्यून बग्स / कमज़ोरियों से ग्रसित हों, जाहिर है कि "हार्डवेयर" फ़ायरवॉल सिर्फ हार्डवेयर स्टैक पर चलने वाला सॉफ़्टवेयर है।

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


1

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

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

इसी तरह, सभी ट्रैफ़िक को अनुमति देने के लिए कॉन्फ़िगर किया गया फ़ायरवॉल बिल्कुल भी फ़ायरवॉल नहीं है।

लेकिन, क्या "सभी ट्रैफ़िक को अनुमति दें" वास्तव में आप जो नीति चाहते हैं? क्या किसी को कभी भी रूसी आईपी पते से आपके किसी सर्वर पर ssh करने की आवश्यकता है? जब आप कुछ नए प्रायोगिक नेटवर्क डेमन के कॉन्फ़िगरेशन के साथ छेड़छाड़ कर रहे हैं, तो क्या पूरी दुनिया को वास्तव में इसकी आवश्यकता है?

फ़ायरवॉल की शक्ति यह है कि यह आपको केवल उन्हीं सेवाओं को खुला रखने की अनुमति देता है जिन्हें आप जानते हैं कि इस नीति को लागू करने के लिए आपको खुले रहने और नियंत्रण के एक बिंदु को बनाए रखने की आवश्यकता है।


2
आपके सभी बिंदुओं को मेरे प्रश्न में संबोधित किया गया है। हां, "सभी ट्रैफ़िक को अनुमति दें" वास्तव में वह नीति है जो हम गैर-प्रबंधन सेवाओं जैसे एसएसएच या कुछ सर्वर के प्रबंधन पोर्ट के लिए चाहते हैं। अन्यथा लोग हमारे वेब पेजों को देखने और हमें मेल भेजने में सक्षम नहीं होंगे!
एरनी

2
केवल उन सेवाओं को खोलने के लिए जिनकी आवश्यकता है, वह है चरण 1 और 4।
एर्नी

1

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

राउटर पर स्टेटलेस पैकेट फिल्टर सार्वजनिक सर्वरों के सामने मायने रखते हैं, लेकिन केवल तभी जब वे सभी इनग्रेस और इगोर ट्रैफिक की लाइन दर (जैसे एक राउटर में हार्डवेयर एसीएल) को संभाल सकें।

Google, फेसबुक और यहां तक ​​कि माइक्रोसॉफ्ट ने सार्वजनिक सर्वरों के सामने पारंपरिक "फायरवॉल" नहीं रखा है। जिस किसी ने भी "एक से अधिक सर्वर" पैमाने पर सार्वजनिक वेब सेवाएं चलाई हैं, उन्हें यह पता होना चाहिए।

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


1
मुझे लगता है कि संदर्भ मायने रखता है। ओपी संभावना वेब-स्केल सिस्टम के बारे में नहीं बोल रहा था, जहां लोड संतुलन और फायरवॉलिंग को एक एसएमबी के बैक-ऑफिस टेक्नोलॉजी स्टैक की तुलना में बहुत अलग तरीके से लागू किया जाएगा।
ewwhite

एक सर्वर के सामने भी, एक स्टेटफुल फ़ायरवॉल आपको मदद करने के लिए कुछ भी नहीं करता है अगर आप हर जगह से कनेक्शन स्वीकार कर रहे हैं। आपको वैसे भी सब कुछ के लिए टीएलएस या अन्य एन्क्रिप्शन का उपयोग करने की आवश्यकता है, इसलिए सभी फ़ायरवॉल यह कह सकते हैं कि "अरे, पोर्ट 443 पर मेरे पास कुछ और डेटा है"। फायरवॉल काफी मर चुके हैं: etherealmind.com/why-firewalls-wont-matter-in-a-few-years
rmalayter

0

आपके सभी सर्वरों को सार्वजनिक पते की आवश्यकता क्यों है?

सर्वर रूम में सर्वर स्थापित करें और इसे एक सार्वजनिक आईपी पता दें।

14 या तो सर्वर से जो मैं नियमित रूप से चलाता हूं, केवल 2 में सार्वजनिक रूप से सुलभ इंटरफेस हैं।

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

इसके अलावा, सभी ट्रैफ़िक जो सर्वर के बीच से गुजरते हैं, पूरी तरह से एन्क्रिप्टेड हैं?

आप निश्चित रूप से बिना सीटबेल्ट, बिना एयरबैग और गंजे टायर के साथ कार 100 मील प्रति घंटे की ड्राइव कर सकते हैं, लेकिन आप क्यों करेंगे ??


1
क्योंकि उन सभी के पास ऐसी सेवाएँ हो सकती हैं जिन्हें "इंटरनेट से" एक्सेस करने की आवश्यकता होती है
adamo

उम नहीं। अधिक सीट बेल्ट और एयरबैग के साथ 70 मील प्रति घंटे की गति से कार चलाना पसंद करते हैं। लेकिन अपने दरवाजे बंद किए बिना। जगह में एक सुरक्षा नीति है, और सर्वर सुरक्षित हैं, लेकिन कोई फ़ायरवॉल नहीं है। फायरवॉल सुरक्षा के सभी और अंत नहीं हैं, आप जानते हैं।
एरनी

2
मैंने यह नहीं कहा कि, कभी-कभी, फायरवॉल सुरक्षा के सभी या अंत होते हैं। मैं यहां पर पहले से कही गई बातों को नहीं दोहराऊंगा। वे सुरक्षा के कई लेयर्स में एक लेयर हैं। मैंने आपसे अब दो बार पूछा है और आपने उत्तर नहीं दिया है। LAN पर सर्वर चैट करने वाली चीजें हैं। क्या आपके सभी सर्वर केवल एन्क्रिप्टेड चैनलों पर एक दूसरे से बात करते हैं?
ग्रेग

0

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

फ़ायरवॉल एक अन्य सुरक्षा जाल है जो सुनिश्चित करता है कि आपकी नीतियों का पालन किया जाए। निश्चित रूप से, ऐसी सेवाएँ न चलाएं जिनकी आपको अपेक्षा नहीं है।

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


0

आप को साकार नहीं किया जा सकता है कि आप कितना फायरवॉल से लाभ कर रहे हैं बस क्योंकि हर कोई किसी और उन्हें इस्तेमाल कर रहा है। एक दिन में जब शाब्दिक रूप से हर कोई, घर के नीचे के डीएसएल उपयोगकर्ताओं के पास पोर्ट सूँघने की जगह फायरवॉल है, लेकिन सभी को एक व्यवहार्य हमला वेक्टर के रूप में दिया गया है। एक सभ्य हैकर ऐसी चीजों के लिए अपना समय बर्बाद नहीं करने वाला है।

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