सवाल अगर मेरा सर्वर अच्छी तरह से कॉन्फ़िगर किया गया है तो मुझे फ़ायरवॉल की आवश्यकता क्यों होगी?


मैं जिस कंपनी के लिए काम करता हूं उसके लिए मैं कुछ हद तक क्लाउड-आधारित (वीपीएस) सर्वर प्रशासित करता हूं।

सर्वर न्यूनतम ubuntu इंस्टॉल होते हैं जो LAMP स्टैक / इनबाउंड डेटा संग्रह (rsync) के बिट्स चलाते हैं। डेटा बड़ा है लेकिन निजी, वित्तीय या ऐसा कुछ भी नहीं (यानी वह दिलचस्प नहीं है)

स्पष्ट रूप से यहां लोग हमेशा कॉन्फ़िगर करने के बारे में पूछ रहे हैं फायरवॉल और इस तरह की।

मैं सर्वरों को सुरक्षित करने के लिए दृष्टिकोणों का एक समूह का उपयोग करता हूं, उदाहरण के लिए (लेकिन प्रतिबंधित नहीं)

  • गैर मानक बंदरगाहों पर एसएसएच; कोई पासवर्ड टाइपिंग नहीं, केवल लॉगिन के लिए ज्ञात ips से एसएसएच कुंजी ज्ञात है
  • https, और प्रतिबंधित गोले (rssh) आमतौर पर केवल ज्ञात कुंजी / ips से ही
  • सर्वर न्यूनतम, अद्यतित हैं और नियमित रूप से पैच किए जाते हैं
  • निगरानी के लिए rkhunter, cfengine, lynis denyhosts आदि जैसी चीजों का उपयोग करें

मेरे पास यूनिक्स sys व्यवस्थापक का व्यापक अनुभव है। मुझे विश्वास है कि मुझे पता है कि मैं अपने सेटअप में क्या कर रहा हूं। मैं / etc फ़ाइलों को विन्यस्त करता हूं। मैंने फ़ायरवॉल जैसे सामान स्थापित करने की एक अनिवार्य आवश्यकता महसूस नहीं की है: iptables इत्यादि।

वीपीएस की शारीरिक सुरक्षा के मुद्दों को एक पल के लिए अलग रखो।

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

आज तक (लकड़ी को छूएं) मुझे सुरक्षा के साथ कभी भी कोई समस्या नहीं हुई है, लेकिन मैं इसके बारे में भी संतुष्ट नहीं हूं।


57
2018-02-08 12:50


मूल


यह भी देखें: serverfault.com/questions/201298/why-should-i-firewall-servers - splattne
आपको कोशिश करनी चाहिए security.stackexchange.com - AviD
मुझे अपना आईपी पता दें और मैं करूंगा प्रदर्शन आपको फ़ायरवॉल की आवश्यकता क्यों है। - GregD


जवाब:


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

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

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

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

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


85
2018-02-08 13:07



यह एक बहुत ही अंतर्दृष्टिपूर्ण जवाब है, विशेष रूप से "सबकुछ अनुमति है ..." से फ़्लिप करने के बारे में पाठ "सबकुछ प्रतिबंधित है ..." आपका बिंदु स्थानीय डिमन्स के बारे में भी अच्छी तरह से बनाया गया है। जैसा कि अक्सर होता है - मुझे यकीन है कि आप सहमत होंगे - खतरे अक्सर "अंदर" - Aitch
(एच, अगर मैं थोड़ा अनुमान लगा सकता हूं, तो आपकी प्रोफ़ाइल से पता चलता है कि आप सर्वरफॉल्ट पर नए हैं। स्थानीय शिष्टाचार यह है कि जब आप किसी उत्तर से खुश होते हैं, तो आप टिक आउटलाइन पर क्लिक करके इसे स्वीकार करते हैं, अगर स्मृति सेवा करता है; जो प्रतिष्ठा प्रणाली को चलाता है। बेशक, यदि आप इसे पहले से जानते हैं, या आप यह देखने का इंतजार कर रहे हैं कि क्या अन्य, बेहतर, उत्तर बदलते हैं, तो यह भी बहुत सही और उचित है, और कृपया मुझे अनदेखा करें। समुदाय केवल पूछता है कि एक बार आप अपने प्रश्न के उत्तर से पूरी तरह से संतुष्ट हैं, आप इसे स्वीकार करते हैं।) - MadHatter
+1 @MatHatter - फ़ायरवॉल कैसे पसंद के बजाय डिफ़ॉल्ट रूप से सुरक्षा प्रदान कर सकता है इसका अच्छा विवरण। - Coops
यह एक गणना जोखिम है। कम से कम ओपनबीएसडी पर, पीएफ को सक्षम करने से कर्नेल में कोड की 35K लाइनें जुड़ती हैं, जिनमें बग हो सकती है। दूसरी ओर, एक डिफ़ॉल्ट इनकार - और उचित लॉगिंग फ़ायरवॉल - सबसे बड़ा आईडीएस पैसा खरीद सकता है। बुरी चीजों को देखने के लिए स्नॉर्ट का उपयोग करने की कोशिश करना बंद करें: किसी भी समय आपकी मशीनों में से कोई भी ऐसा कुछ करता है जिसे आपने विशेष रूप से अनुमति नहीं दी है, आपको अधिसूचित होना चाहिए। - Alex Holst


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

एक और बात यह है कि आपके सर्वर एक मानक सर्वर ओएस (यूनिक्स, एनटी, लिनक्स) के शीर्ष पर चल रहे सर्वर सॉफ़्टवेयर को संभालने के लिए कमोडिटी हार्डवेयर या हार्डवेयर विशिष्ट होने की संभावना है। यही है, उनके पास आने वाले यातायात को प्रभावी ढंग से संभालने और फ़िल्टर करने के लिए विशेष हार्डवेयर नहीं है। क्या आप चाहते हैं कि आपका सर्वर हर संभव मल्टीकास्ट, आईसीएमपी पैकेट या पोर्ट स्कैन को अपना रास्ता आ सके?

सबसे अधिक संभावना है कि आप अपने सर्वरों के लिए केवल कुछ बंदरगाहों (80, 443, अपने एसएसएल पोर्ट, अपने ठेठ ऑरैकल 1521 पोर्ट, अपने आरएसआईएनसीसी पोर्ट इत्यादि) के अनुरोधों को शारीरिक रूप से संभालने के लिए चाहते हैं। हां, निश्चित रूप से आप अपने सॉफ्टवेयर सॉफ़्टवेयर फ़ायरवॉल सेट अप करते हैं सर्वर केवल उन बंदरगाहों को सुनने के लिए। लेकिन आपके एनआईसी अभी भी अवांछित यातायात का शिकार हो जाएंगे (चाहे वह आपके संगठन में घातक या सामान्य हो।) यदि आपके एनआईसी हथियार प्राप्त कर रहे हैं, तो नेटवर्क सर्वर आपके सर्वर से जा रहे हैं (और संभवतः आपके सर्वर और आंतरिक ग्राहकों और कनेक्शन के बीच अन्य आंतरिक सर्वर और सेवाएं।)

न केवल आपके एनआईसी को हथियार मिलते हैं, आपके सॉफ़्टवेयर फ़ायरवॉल को भी शामिल किया जा रहा है क्योंकि इसे हर एक पैकेट या डेटाग्राम का निरीक्षण करना पड़ता है।

दूसरी ओर फायरवॉल, विशेष रूप से सबनेट्स के किनारों पर (या बाहरी दुनिया से अपने सबनेट को अलग करना) विशेष रूप से उस प्रकार की मात्रा को संभालने के लिए विशेषीकृत हार्डवेयर होते हैं।

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

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

फ़ायरवॉल नहीं है क्योंकि आपके सर्वर में एक को धुंध के कारण शून्य दृश्यता के तहत 120 मील प्रति घंटे ड्राइविंग करते समय अपनी सीट बेल्ट रखने में सुरक्षित महसूस करना है। यह उस तरह से काम नहीं करता है।


13
2018-02-08 21:08





ऐसे कई हमले हैं जिनके लिए आपको फ़ायरवॉल नहीं मिल सकता है जो कि किसी प्रकार का पैकेट स्तर निरीक्षण करता है:

उदाहरण है क्रिसमस ट्री पैकेट

http://en.wikipedia.org/wiki/Christmas_tree_packet

डीडीओएस हमलों को आपके सिस्टम के खिलाफ चलाया जा सकता है, फ़ायरवॉल (बाहरी हो सकता है, आपके किसी भी सर्वर से पहले) आपके सर्वर को अपंग करने से पहले यातायात को धीमा / धीमा / मार देगा।

केवल इसलिये आपके पास सर्वर पर वित्तीय, या व्यक्तिगत डेटा नहीं है इसका मतलब यह नहीं है कि आपको 'चोट' नहीं मिलेगी। मुझे यकीन है कि आप बैंडविड्थ, या सीपीयू उपयोग के लिए भुगतान करते हैं, या आपके पास मीटर की दर है। एक रात के दौरान कल्पना करें (जब आप सो रहे हों) कोई आपके मीटर को चलाता है (मैंने देखा है कि यह वीओआईपी स्विच प्रदाताओं के साथ होता है, रात में यातायात के MINUTES के लिए हिट करता है, कि उन्हें बिल को पैर देना होगा)।

तो स्मार्ट बनें, अगर वहां है तो सुरक्षा का उपयोग करें, आप बिल्कुल सही नहीं हैं, न ही सॉफ्टवेयर है। यह तब तक सुरक्षित है जब तक कि अगला शोषण नहीं मिलता है। ;)


4
2018-02-08 19:27





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


2
2018-02-08 13:01



एकल कॉन्फ़िगरेशन के बारे में अच्छा बिंदु, त्रुटि के लिए कम कमरा। जहां भी संभव हो मैं आलसी होने के साथ सहमत हूँ! cfengine कुछ जटिलता फाइलों के मुद्दे को आंशिक रूप से कम करने के लिए इस जटिलता में से कुछ लेता है .... लेकिन ... यह पाठ्यक्रम के रूप में केवल नियमों के समान ही अच्छा है। तो आप प्राथमिक कॉन्फ़िगरेशन फ़ाइलों को "डिफ़ॉल्ट" (या पास के रूप में) को माध्यमिक बाधा के रूप में छोड़ देते हैं और फ़ायरवॉल को प्राथमिक रूप से (कम से कम एक परत में) प्राथमिक चिंता के रूप में छोड़ देते हैं। - Aitch
मैं सबसे पहले पीओएलपी के लिए उभरा, फिर आलस्य के लिए downvoted। फायरवॉल उपकरण नहीं हैं ताकि वे अपने मालिकों को बेवकूफ़ बना सकें। आपको अपनी आक्रमण की सतह को कसने से परेशान होना चाहिए क्योंकि अगर हमलावर फ़ायरवॉल के माध्यम से जाता है (बाद में आपको कुछ खुला होना चाहिए), तो वे केवल iptables बंद कर सकते हैं। अपनी आलस्य को लागू करें जहां यह संबंधित है: सिस्टम को यथासंभव ढलान मुक्त करें, इसलिए आपको इसे लंबे समय तक ठीक करने की आवश्यकता नहीं है। - Marcin
@ मार्सिन मेरा मतलब है कि अगर कोई फ़ायरवॉल का उपयोग कर सिस्टम को सुरक्षित करना चाहता है, तो उसे पहले एक व्यापक खतरा मॉडल बनाना होगा। फ़ायरवॉल कुछ प्रकार के प्रसिद्ध और अच्छी तरह से वर्णित खतरे मॉडल का अर्थ है, इसलिए मुझे इसे प्रत्येक होस्ट के लिए खरोंच से नहीं बनाना है। बेशक, अगर हम सैन्य-श्रेणी की सुरक्षा के बारे में बात करते हैं, तो कोई विकल्प नहीं है, औपचारिक धमकी मॉडल बनाया जाना चाहिए। - Alex


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

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


1
2018-02-08 17:37



इसके अतिरिक्त, ऐसा करने से फ़ायरवॉल को किसी भी तरह से कॉन्फ़िगर करना है - यह बस प्रत्येक सर्वर पर होता है। - mfinni


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

(अपने फ़ायरवॉल को चलाने की कोशिश न करें वही आपके सर्वर के रूप में ओएस, अन्यथा ओएस में एक ही बग .... मैं यूनिक्स के सभी संस्करणों को एक ही ओएस मानता हूं, क्योंकि उनके पास बहुत आम है)


1
2018-02-08 22:26



उत्कृष्ट, प्लेटफॉर्म (ओएस और हार्डवेयर) मिश्रण करना महत्वपूर्ण है। - DutchUncle


यातायात हेरफेर में फायरवॉल spicialized हैं। वे इसे जल्दी करते हैं और संसाधन होते हैं। और आप ट्रैफिक फ़िल्टर करने के लिए सर्वर संसाधनों को बर्बाद नहीं करते हैं (डिस्क io / proc time / etc)। आप सर्वर सुरक्षा में कुछ सुरक्षा कॉन्फ़िगर करते हैं लेकिन सभी ट्रैफिक निरीक्षण और वायरस स्कैनिंग और इसी तरह विशेष सर्वर करना चाहिए।


0
2018-04-19 08:50