सवाल पोर्ट 22 आउटबाउंड क्यों ब्लॉक करें?


मैं एक प्रोग्रामर हूं, और मैंने कुछ ग्राहकों के लिए काम किया है जिनके नेटवर्क पोर्ट 22 पर आउटगोइंग कनेक्शन ब्लॉक करते हैं। ध्यान में रखते हुए कि प्रोग्रामर को अक्सर एसएसएच के लिए पोर्ट 22 का उपयोग करने की आवश्यकता होती है, यह एक प्रतिकूल प्रक्रिया की तरह लगता है। सबसे अच्छा, यह प्रोग्रामर को 3 जी इंटरनेट के लिए कंपनी को बिल करने के लिए मजबूर करता है। सबसे खराब, इसका मतलब है कि वे अपनी नौकरियों को प्रभावी ढंग से नहीं कर सकते हैं।

इससे उत्पन्न कठिनाइयों को देखते हुए, क्या एक अनुभवी sysadmin कृपया खोने वाली कार्रवाई की तरह दिखने के लिए वांछित लाभ की व्याख्या कर सकता है?


55
2018-06-14 17:08


मूल


ब्लॉकिंग बंदरगाह केवल आधा लड़ाई है। चक्र को पूरा करने के लिए, आपको यह सुनिश्चित करना होगा कि जिन सेवाओं को आप सुरक्षित करने की कोशिश कर रहे हैं वे गैर-मानक बंदरगाहों पर नहीं चल रहे हैं। - aharden
प्रश्न वास्तव में "पोर्ट 22 आउटबाउंड ब्लॉक क्यों होना चाहिए?" क्योंकि एक लाख अच्छे कारण हैं कि आप एक गैर मानक पोर्ट पर अपनी एसएसएच सेवा क्यों चलाना चाहते हैं। आउटबाउंड ... इतना नहीं। मैंने रॉबर्ट मोइर के जवाब पर एक +1 डाला क्योंकि उसने इसे समझाया एक बहुत अच्छा काम किया था। - KPWINC
@ केपीडब्ल्यूआईएनसी ने शीर्षक को स्पष्टीकरण जोड़ा। धन्यवाद! - runako
पोर्ट 22 को पैंडोरा के बॉक्स के रूप में सोचें। नेटवर्क प्रशासक यातायात में क्या है और सबसे खराब अभी तक नहीं देख सकते हैं, एसएसएच नेटवर्क की अखंडता समझौता समझौता बाईपास नेटवर्क सुरक्षा का उपयोग किया जा सकता है। - biosFF
@biosFF: पोर्ट 443। - Hello71


जवाब:


मुझे नहीं लगता कि किसी ने एसएसएच पोर्ट अग्रेषण के साथ विस्तार से विशिष्ट जोखिम की वर्तनी की है।

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

अगर आपका डेस्कटॉप है और बर्नी आपकी कंपनी में एक महत्वपूर्ण सर्वर है और विल्मा सार्वजनिक है, तो चल रहा है (fred पर):

एसएसएच-आर *: 9 000: बरनी: 22 विल्मा

और लॉग इन करने से हमलावर एसएसएच को विल्मा पर पोर्ट 9000 पर बंद कर देगा और बार्नी के एसएसएच डिमन से बात करेगा।

आपकी फ़ायरवॉल इसे आने वाले कनेक्शन के रूप में कभी नहीं देखती है क्योंकि डेटा को किसी कनेक्शन के माध्यम से पारित किया जा रहा है जो मूल रूप से आउटगोइंग दिशा में स्थापित किया गया था।

यह कष्टप्रद है, लेकिन एक पूरी तरह से वैध नेटवर्क सुरक्षा नीति है।


68
2018-06-14 19:50



एक बहुत ही अंतर्दृष्टि प्रतिक्रिया के लिए धन्यवाद। यह उन कुछ प्रतिक्रियाओं में से एक है जो खुले आउटबाउंड बंदरगाहों के तकनीकी जोखिम (राजनीतिक जोखिमों के विपरीत) को संबोधित करते हैं। - runako
एक अच्छा तकनीकी कारण देने के लिए +1। (हालांकि, यह केवल एक नरभक्षी इंटर्न द्वारा किया जा सकता है, जो रिमोट होस्ट पर टीसीपी 22 की तुलना में अन्य बंदरगाहों का भी उपयोग कर सकता है। जिसके साथ हम सभी नीतियों को कुछ ब्लॉक में वापस कर रहे हैं) - DerMike
एक कस्टम अनुरूप प्रोटोकॉल और कुछ चालाक प्रॉक्सी प्रोग्रामिंग के साथ, यह धीमी गति के बावजूद HTTPS के माध्यम से किया जा सकता है। जब तक आप आउटबाउंड एन्क्रिप्टेड यातायात की अनुमति देते हैं, तब तक आप इस तरह के "हमले" के लिए कमजोर होते हैं। - Michael Sondergaard
यह जेम्सएफ की एक अच्छी प्रतिक्रिया है, लेकिन इसके बारे में सोचने के लिए सुरक्षा समस्या नहीं है क्योंकि यह बेहद दुर्लभ परिदृश्य मानती है और एसएसएच सर्वर / ग्राहकों के शोषण की आवश्यकता होती है। दुर्भावनापूर्ण उपयोगकर्ता को पहले एसएसएच सर्वर (अपने डेस्कटॉप पर) का फायदा उठाना होगा और फिर अपने एसएसएच क्लाइंट (अपने व्यापार होस्ट पर) का फायदा उठाने का एक तरीका पता लगाना होगा। चूंकि आप पोर्ट-फ़ायरवॉल होस्ट (जो केवल आउटगोइंग पोर्ट 22 है) तक पहुंचने या उससे बात करने के लिए पोर्ट 22 का उपयोग नहीं कर सकते हैं। यदि आपका सुरक्षा मानक इतना ऊंचा है, तो आपके व्यवसाय-होस्ट को किसी भी स्थिति में इंटरनेट पर भी नहीं होना चाहिए। - Dexter
@Dexter को क्या कहना था, इस पर जारी रखना, इंट्रानेट स्कोप पर फ़ायरवॉल नीतियों को भी लागू किया जा सकता है। तो आंतरिक सर्वर इंट्रानेट पर डेस्कटॉप से ​​भी सुरक्षित हैं। - nass


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

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

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

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

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

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

अब चेतावनी के लिए, और संभवतः चीजों को मुक्त करने की योजना:

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

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


36
2018-06-14 17:52



+1 के लिए यदि वे सभी बंदरगाहों को अवरुद्ध कर रहे हैं, तब तक उस बंदरगाह के माध्यम से यातायात की अनुमति देने के लिए एक विशिष्ट व्यावसायिक मामला नहीं है, जिस बिंदु पर इसकी सावधानीपूर्वक प्रबंधित की जाती है, तो वे इसे कर रहे हैं क्योंकि वे अपनी नौकरियों में सक्षम हैं। - cop1152
-1 क्योंकि सुरक्षा लोगों द्वारा एसएसएच की निगरानी नहीं की जा सकती है लेकिन टेलनेट हो सकता है। मेरा मुद्दा यह है कि मूर्ख नेटवर्क सुरक्षा नीतियां हैं, जबकि वास्तविक व्यापार आवश्यकताओं की समझ के बिना नीति को "यादृच्छिक" और "सनकी" के रूप में चिह्नित करना भी कम है। - pcapademic
वैसे आप एरिक के बारे में आपकी राय के हकदार हैं, और यदि आप महसूस करते हैं कि वे अपमानजनक हैं, तो मैं उन शब्दों को खुशी से बदल दूंगा, लेकिन मुझे पूरा भरोसा है कि ऐसी नीति या तो खराब विचार या एक असामान्य एज केस होगा। - Rob Moir
"सभी बंदरगाहों" के लिए +1 - Ian Boyd


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

दूसरे शब्दों में, कंपनियां कभी-कभी बेवकूफ निर्णय लेती हैं, और फिर अपनी गलतियों को स्वीकार करने के बजाय सुरक्षा के बारे में बाल्नी बहाने बनाती हैं।


17
2018-06-14 17:33



टेलनेट सुरक्षा छेद है। इसे प्रतिबंधित किया जाना चाहिए (यह सिर्फ लोगों के लिए भविष्य में बेहतर बेवकूफ निर्णय लेने के लिए है)। - nik
मुझे यहां विस्तृत करने दें, सुरक्षा छेद क्या है सतह को सुरक्षित करने के लिए व्यक्तिपरक है। यदि आप एक वेब साइट स्वामी हैं, तो अपने सर्वर से कनेक्ट करने का प्रयास कर रहे हैं, TELNET एक छेद है। यदि आप एक वित्तीय कंपनी कर्मचारी हैं जो आपके घर सर्वर से बाहर कनेक्ट करने की कोशिश कर रहे हैं (आपके नियोक्ता द्वारा निगरानी की जा रही लाइनों पर), एसएसएच आपके नियोक्ताओं के लिए सुरक्षा छेद है! - nik
दोनों दिशाओं में टेलनेट को खराब करना कितना आसान है, मैं कहूंगा कि टेलनेट कंपनी के लिए भी एक सुरक्षा छेद है जो इसे बाहर जाने की अनुमति देता है। लेकिन एक कंपनी जो इसे अनुमति देती है लेकिन एसएसएच की अनुमति नहीं देती है वह किसी भी मामले में बुद्धिमान सुरक्षा निर्णय नहीं ले रही है। - Paul Tomblin
टेलनेट वह उपहार है जो सिर्फ दे रहा है। यह 20 साल पहले ठीक था लेकिन अब मैं वास्तव में चाहता हूं कि यह रुक जाएगा। - Rob Moir
यह सब आपके पीओवी पर निर्भर करता है। उनके पास शायद ऐसे लोग थे जिन्हें टेलनेट के माध्यम से कुछ विरासत प्रक्रिया तक पहुंचने की आवश्यकता थी, जिसका हम आसानी से ऑडिटेबल हैं। ओटीओएच, आपको पता नहीं है कि एसएसएच के साथ क्या चल रहा है, लोग विदेशी नेटवर्क पर सुरंग स्थापित कर सकते हैं और गूंगा चीजों के सभी प्रकार कर सकते हैं। इन दिनों टेलीनेट का उपयोग नहीं किया जाना चाहिए, लेकिन एसएसएच से बाहर निकलने की अनुमति देने वाले किसी भी नए कैरियर की तलाश करनी चाहिए। - duffbeer703


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

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

ऐसे कई सार्वजनिक डोमेन टूल्स भी हैं जो आपको एंटरप्राइज़ (पोर्ट 80 या एचटीटीपीएस पोर्ट 443) पर एंटरप्राइज़ से बाहर निकलने देते हैं और आपको पोर्ट 22 के बाहर कनेक्ट करने के लिए प्रॉक्सी प्रदान करते हैं।


संपादित करें: ठीक है, एक सेकंड प्रतीक्षा करें, मुझे पता है कि यह नीति क्यों हो सकती है।

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

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


5
2018-06-14 17:32



पोर्ट 443 बेहतर है, क्योंकि इसे पहले ही एन्क्रिप्टेड माना जाता है, इसलिए प्रॉक्सी अजीब डेटा पर परेशान नहीं होंगे। आप पोर्ट 443 पर आसानी से एक एसएसएच सर्वर सुन सकते हैं, और वहां से आप कहीं भी जा सकते हैं। - bandi
एक जगह मैंने काम किया, मेरे सहकर्मियों में से एक ने एक कार्यक्रम का उपयोग किया जो हमारे वेब प्रॉक्सी के माध्यम से अपने वेब प्रॉक्सी के माध्यम से एक एसएस सुरंग पर सभी नेटवर्क यातायात को सुरंग करता था, और वहां से इंटरनेट पर बाहर जाता था। वह किसी भी प्रोटोकॉल का उपयोग कर सकता था, लेकिन ऐसा लगता था कि यह कंपनी के बजाय अपने घर से आ रहा था। सौभाग्य से वह जानता था कि नेटवर्क प्रशासक कितने अनजान थे इसलिए वह पकड़े जाने का जोखिम नहीं उठा रहा था। - Paul Tomblin
बेशक, अगर आप फ़ायरवॉल को घुमाने के लिए इन विस्तृत नृत्यों में से एक के माध्यम से पकड़े गए हैं, तो आप वास्तव में निर्दोषता और अज्ञानता की मांग नहीं कर सकते हैं। उन सभी को करने के लिए कड़ी मेहनत करें और कहें "माफ करना मालिक, यह सिर्फ काम करता है 'इसलिए मुझे नहीं पता था कि मैं कुछ भी गलत कर रहा था।" - Rob Moir


यह शायद एक विनियामक / अनुपालन मुद्दा है। आपका नियोक्ता सभी संचार को पढ़ने / संग्रहीत करने में सक्षम होना चाहता है। यह अक्सर बैंकिंग जैसे उद्योगों में एक आवश्यकता है।


4
2018-06-14 17:11



क्या इसका मतलब यह नहीं है कि उन्हें एचटीटीपीएस को भी अवरुद्ध करना है? - runako
नहीं, वे एसएसएल निरीक्षण सक्षम करते हैं। यह प्रक्रिया समूह नीति द्वारा सभी वर्कस्टेशन में एक विश्वसनीय प्रमाण इंजेक्शन द्वारा HTTPS को डिक्रिप्ट करता है, फिर / आउटबाउंड पैकेट को पुन: प्रयास करता है। इस तरह, वे HTTP के साथ फ़िल्टर / स्कैन कर सकते हैं। बैंकिंग उद्योग नेटवर्क लॉक करने के लिए सबसे कठिन वातावरण में से एक है। - spoulson


मेरी राय में आउटबाउंड पोर्ट 22 को अवरुद्ध करने के दो प्राथमिक कारण हैं।

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

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


4
2018-06-15 03:38





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

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

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


3
2018-06-14 17:33



हां, यह काफी संभावना है कि सभी आउटबाउंड सेवाओं का उपयोग करने की आवश्यकता नहीं है, फिर भी अवरुद्ध हो सकते हैं (डिफ़ॉल्ट रूप से)। - nik
लेकिन, टीसीपी / 22 को अवरुद्ध करना सुरक्षित आउटबाउंड संचार को रोकने के लिए नहीं जा रहा है (जिसे किसी भी बंदरगाह पर तब तक बनाया जा सकता है जब तक कि उपयोगकर्ता के पास श्रोता न हो, जो इन दिनों एक कठिन बात नहीं है)। - nik
यदि आंतरिक नेटवर्क एसएसएच संचार के लिए उपयोग किया गया है, तो इसे अवरुद्ध करना काम नहीं करेगा और यदि कोई एसएसएच संचार आवश्यक नहीं है, तो आमतौर पर नेटवर्क के अंदर कोई कमजोर एसएसएच सुनने मशीन नहीं होगी। और, सामान्य कृमि प्रसार एसएसएच को बलपूर्वक करने की कोशिश नहीं करता है (यदि आप उस बारे में चिंतित हैं en.wikipedia.org/wiki/SSHBlock) यह आपकी विंडोज मशीनों के साथ टीसीपी / 445 कोशिश करने की अधिक संभावना है। - nik


आपके ग्राहक शायद गैर-तुच्छ डेटा के कब्जे में हैं जो वे बनाए रखना चाहते हैं। आउटबाउंड एसएसएच एक संपूर्ण नेटवर्क के लिए खोलने के लिए वास्तव में एक बुरी चीज है। यह proxys बाईपास, संवेदनशील डेटा रिसाव, और आम तौर पर अप्रिय होने के लिए बहुत छोटा है।

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


3
2018-06-15 00:24



जवाब के लिए धन्यवाद। आप अपने नियंत्रण के बाहर की साइटों पर समर्पित वीपीएन कैसे प्रबंधित करते हैं (उदा। ईसी 2, वेब होस्ट इत्यादि)? क्या ये विक्रेता आम तौर पर आपके लिए यह कस्टम सेटअप करने के इच्छुक हैं, या क्या आपको आमतौर पर ऐसा करने के लिए व्यवसाय के संदर्भ में कुछ बड़ी न्यूनतम प्रतिबद्धता करना पड़ता है? - runako
साथ ही, क्या आप चिंता करते हैं कि आप लोगों को अपना काम पूरा करने के लिए ऑफ-नेटवर्क 3 जी कार्ड का उपयोग करने के लिए मजबूर करते हैं? मेरे अनुभव में, लॉक डाउन नेटवर्क अनिवार्य रूप से 3 जी कार्ड और अन्य छिपे हुए छेड़छाड़ का कारण बनते हैं, क्योंकि लोग आवंटित समय में अपनी नौकरी नहीं कर सकते हैं अगर उन्हें आईटी के उपयोग को मंजूरी देने के लिए इंतजार करना पड़ता है, अगर कोई भी जानता है कि कौन अपवाद पाने के लिए कॉल करने के लिए। (एक गंभीर मामले में एक मेलसर्वर शामिल था जो इंटरनेट से आने वाले अनुलग्नकों को स्वीकार नहीं करेगा। यिक्स!) मैं उत्सुक हूं कि आप इस संतुलन को कैसे प्रबंधित करते हैं। - runako
एसएसएच पर बंदरगाह अग्रेषण के बारे में टिप्पणी में जोड़ें, और मुझे लगता है कि यह सवाल का सही जवाब है। प्रॉक्सी सर्वर के माध्यम से अनुमति देने के लिए एसएसएच एक अच्छा प्रोटोकॉल हो सकता है। व्यवस्थापक क्या देख रहे हैं, इसकी निगरानी कर सकते हैं, पोर्ट अग्रेषण को अवरुद्ध कर सकते हैं, और लोग रिमोट शैल और रिमोट कॉपी सेवाओं के लिए इसका उपयोग कर सकते हैं। - pcapademic
हम इतने बड़े हैं कि हमारी 90% सेवाओं को चलाने के लिए कोई आउटबाउंड प्रशासन की आवश्यकता नहीं है। आम तौर पर जब हम करते हैं, हम एक आरएफपी में एक समर्पित वीपीएन सुरंग की आवश्यकता बनाते हैं, जो विक्रेताओं को खत्म करने के लिए होता है जो इसे प्रदान नहीं कर सकते हैं या नहीं कर सकते हैं। इसके कारण, मेरा मानना ​​है कि हमारे पास 3 जी और इसी तरह के कामकाज का उपयोग करने वाले लोगों की संख्या कम से कम है। - duffbeer703
साथ ही, आप सुरक्षा लोगों को पहुंच को निर्देशित नहीं कर सकते हैं। सुरक्षा समीक्षा के अधीन, आप आवेदन समर्थन और नेटवर्किंग लोगों को एक स्वीकार्य समाधान का काम करने देते हैं। प्रक्रिया में शुरुआती समाधान का समाधान करें, सुबह को आपको उत्पादन में जाने की जरूरत नहीं है। हालांकि आपको अनुरोध प्राप्त करने में डीएमवी-शैली की देरी से दूर रखा जाता है। - duffbeer703