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


59

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

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

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

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

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

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

VPS की भौतिक सुरक्षा के मुद्दों को एक पल के लिए अलग रखें।

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

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


2
इन्हें भी देखें: serverfault.com/questions/201298/why-should-i-firewall-servers
splattne


6
मुझे अपना आईपी पता दें और मैं आपको दिखाऊंगा कि आपको फ़ायरवॉल की आवश्यकता क्यों है।
ग्रेग

जवाबों:


87

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

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

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

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

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


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

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

+1 @ मैटरहैटर - फायरवॉल कैसे पसंद के बजाय डिफ़ॉल्ट रूप से सुरक्षा प्रदान कर सकता है, इसका अच्छा विवरण।
फॉप

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

14

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

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

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

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

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

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

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

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


4

अगर आपके पास कोई फ़ायरवॉल नहीं है जो पैकेट लेवल इंस्पेक्शन का काम करता है, तो कई हमले हो सकते हैं।

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

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

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

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

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


2

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


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

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

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

1

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

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


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

1

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

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


उत्कृष्ट, प्लेटफॉर्म (ओएस और हार्डवेयर) को मिलाना प्रमुख है।
डचयूनल अंक

1

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


-2

मुझे चिंता होगी कि अगर आप कभी हैक हो जाते हैं और जगह में फ़ायरवॉल नहीं है। हैकर्स आपके सर्वर पर अन्य पोर्ट खोल सकते हैं। इसके अलावा, अगर किसी सलाहकार को कुछ सफाई और ऑडिटिंग करने के लिए लाया जाता है, तो सबसे पहले वे कहेंगे, "ATAT!?!! आपके पास फ़ायरवॉल नहीं है! " तब आपको जलाया जा सकता था।


-1 थोड़ा सनसनीखेज जवाब + वास्तव में रचनात्मक नहीं हो रहा है।
Coops

2
यदि सर्वर से छेड़छाड़ की जाती है, तो एक फ़ायरवॉल आवश्यक रूप से मदद करने के लिए नहीं जा रहा है जब बोजो जो बस टूट गया है, उसे निष्क्रिय कर देता है! * अस्वीकरण, सवाल ने iptables का उपयोग करने का उल्लेख किया, न कि एक अलग हार्डवेयर फ़ायरवॉल।
ब्रायन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.