डीएमजेड में एक वेब सर्वर में छेद करने के लिए कितनी बड़ी समस्या है?

15

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

मेरी समझ से (और मुझे ब्रांडों की जानकारी नहीं है), हमारे पास अपने फ़ायरवॉल के साथ अपने प्राथमिक आईपी से एक अलग बाहरी आईपी के साथ DMZ के लिए एक फ़ायरवॉल है। वेब सर्वर और इंट्रानेट के बीच एक और फ़ायरवॉल है।

तो कुछ इस तरह:

Web Server  <==== Firewall ===== Intranet
     |                              |
     |                              |
  Firewall                      Firewall
     |                              |
     |                              |
 Internet IP1                  Internet IP2

security firewall dmz

— माइक विल्स
स्रोत

कुछ विवरण जैसे कि किस प्रकार का फ़ायरवॉल इस DMZ को प्रदान कर रहा है?

— स्पेसमैनस्पीफ

@स्पेसmanSpiff मैंने नेटवर्क के न्यूनतम ज्ञान से प्रयास किया। मैं इस अगली परियोजना की योजना बना रहा हूं और विकल्पों के साथ आ रहा हूं।

— माइक

25

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

ध्यान देने योग्य मुख्य बातें हैं:

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

यदि आप इसे एक तरीके से देखते हैं और इसके बारे में कुछ सामान्य ज्ञान रखते हैं, तो इसका कोई कारण नहीं है कि आप ऐसा नहीं कर सकते हैं, जबकि आप एक ही समय में जोखिम को कम करते हुए इसका वर्णन कर रहे हैं।

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

— इवान एंडरसन
स्रोत

मेरी तुलना में वाया अधिक पूरी तरह से जवाब :) +1

— मैथ्यू

मुझे यह जानकारी अच्छी लगी। इससे पहले कि मैं पूछूं, मैंने कुछ ऐसी बातें समझीं जिनके बारे में आपने बात की थी। लेकिन इसका एक बहुत मैं पूरी तरह से समझ नहीं आया। धन्यवाद!

— माइक विल्स

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

— माइक विल्स

6

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

— मैथ्यू
स्रोत