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

61

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

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

ssh port blocking

— रुनाको
स्रोत

1

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

— १०

1

सवाल वास्तव में होना चाहिए "ब्लॉक पोर्ट 22 आउटबाउंड क्यों?" चूंकि एक लाख अच्छे कारण हैं कि आप गैर-मानक पोर्ट पर अपनी ssh सेवा क्यों चलाना चाहते हैं। आउटबाउंड ... इतना नहीं। मैंने रॉबर्ट मोइर के जवाब पर एक +1 लगाया क्योंकि उन्होंने इसे समझाते हुए बहुत अच्छा काम किया।

— KPWINC

@KPWINC ने शीर्षक में स्पष्टीकरण जोड़ा। धन्यवाद!

— रनको

3

पोर्ट 22 को पेंडोरा के बॉक्स के प्रकार के रूप में सोचें। नेटवर्क व्यवस्थापक यह नहीं देख सकते हैं कि ट्रैफ़िक में क्या है और अभी तक सबसे खराब है, ssh नेटवर्क की अखंडता से समझौता करके बाइपास नेटवर्क सुरक्षा का उपयोग किया जा सकता है।

— biosFF

1

@biosFF: पोर्ट 443.

— हैलो 71

77

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

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

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

ssh -R *: 9000: बार्नी: 22 विल्मा

और लॉग इन करने पर हमलावर को ssh को wilma पर 9000 पोर्ट करने और बार्नी के SSH डेमॉन से बात करने देगा।

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

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

— जेम्स एफ
स्रोत

1

बहुत ही सुखद प्रतिक्रिया के लिए धन्यवाद। यह उन कुछ प्रतिक्रियाओं में से एक है जो खुले आउटबाउंड बंदरगाहों के तकनीकी जोखिमों (राजनीतिक जोखिमों के विपरीत) को संबोधित करते हैं।

— रनको

6

एक अच्छा तकनीकी कारण देने के लिए +1। (हालांकि, यह केवल एक पुरुषवादी इंटर्न द्वारा किया जा सकता है, जो रिमोट होस्ट पर टीसीपी 22 के अलावा अन्य पोर्ट का भी उपयोग कर सकते हैं। जिसके साथ हम सभी पॉलिसी को कुछ ब्लॉक में वापस कर रहे हैं)

— DerMike

7

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

— माइकल सोनगार्ड

3

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

— डेक्सटर

1

यदि आप iodineHTTPS और SSH अनुपलब्ध हैं, तो आप DNS (जैसे ) के साथ ट्रैफ़िक को टनल कर सकते हैं। लेकिन यह बहुत धीमा है।

— मार्क के कोवान

38

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

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

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

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

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

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

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

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

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

— रोब मोइर
स्रोत

3

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

— कॉप 1152

-1 क्योंकि ssh की सुरक्षा लोगों द्वारा निगरानी नहीं की जा सकती है लेकिन टेलनेट हो सकता है। मेरा कहना यह है कि जब मूर्ख नेटवर्क सुरक्षा नीतियां होती हैं, तो वास्तविक व्यावसायिक जरूरतों की समझ के बिना "यादृच्छिक" और "व्हेकजॉब" के रूप में नीति को चिह्नित करना भी कमतर होता है।

— ५५:३० पर pcap शैक्षिक

2

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

— रोब मोइर

"सभी बंदरगाहों" के लिए +1

— इयान बॉयड

18

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

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

— पॉल टॉम्बलिन
स्रोत

6

TELNET सुरक्षा छेद है। इसे प्रतिबंधित किया जाना चाहिए (यह सिर्फ लोगों के लिए भविष्य में बेहतर बेवकूफ निर्णय लेने के लिए है)।

— निक

3

मुझे यहां विस्तृत रूप से बताएं कि एक सुरक्षा छेद क्या है जो सतह के अधीन है। यदि आप एक वेब साइट के मालिक हैं, तो अपने सर्वर से कनेक्ट करने की कोशिश कर रहे हैं, TELNET एक छेद है। यदि आप एक वित्तीय कंपनी के कर्मचारी हैं, जो आपके होम सर्वर से बाहर जुड़ने की कोशिश कर रहे हैं (आपके नियोक्ता द्वारा लाइन्स की निगरानी की जा रही है), SSH आपके नियोक्ताओं के लिए सुरक्षा छेद है!

— निक

1

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

— पॉल टॉम्बलिन

3

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

— रोब मोइर

2

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

— duffbeer703

6

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

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

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

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

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

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

— Nik
स्रोत

3

पोर्ट 443 बेहतर है, क्योंकि यह पहले से ही एन्क्रिप्टेड माना जाता है, इसलिए प्रॉक्सी अजीब डेटा पर परेशान नहीं होंगे। आप आसानी से पोर्ट 443 पर सुनने वाले ssh सर्वर को सेट कर सकते हैं, और वहाँ से आप कहीं भी जा सकते हैं।

— बंदी

1

एक जगह मैंने काम किया, मेरे सहकर्मियों में से एक ने एक प्रोग्राम का उपयोग किया, जिसने हमारे होम प्रॉक्सी पर 80 वेब पोर्ट के माध्यम से एक ssh टनल पर अपने घर के कंप्यूटर पर पोर्ट करने के लिए, और वहां से इंटरनेट तक सभी नेटवर्क ट्रैफ़िक को टनल किया। वह अपने इच्छित किसी भी प्रोटोकॉल का उपयोग कर सकता था, लेकिन ऐसा लग रहा था कि यह कंपनी के बजाय उसके घर से आ रहा है। सौभाग्य से वह जानता था कि नेटवर्क व्यवस्थापकों की कुलबुलाहट कितनी थी इसलिए वह पकड़ में नहीं आ रहा था।

— पॉल टॉम्बलिन

1

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

— रोब मोइर

4

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

— जो
स्रोत

क्या इसका मतलब यह नहीं है कि उन्हें HTTPS को भी रोकना होगा?

— रनको

3

नहीं, वे एसएसएल निरीक्षण को सक्षम करते हैं। यह प्रक्रिया HTTPS को घटाती है, फिर समूह नीति द्वारा सभी वर्कस्टेशनों में एक विश्वसनीय प्रमाण पत्र इंजेक्ट करके / आउटबाउंड पैकेट में reencrypts। इस तरह, वे HTTP के समान ही फ़िल्टर / स्कैन कर सकते हैं। बैंकिंग उद्योग नेटवर्क को बंद करने के लिए सबसे कठोर वातावरण में से एक है।

— स्पूलसन

4

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

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

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

— jtimberman
स्रोत

3

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

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

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

— डेविड स्पिलेट
स्रोत

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

— निक

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

— निक

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

— निक

3

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

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

— duffbeer703
स्रोत

जवाब के लिए धन्यवाद। आप अपने नियंत्रण से बाहर की साइटों के लिए समर्पित वीपीएन कैसे संभालते हैं (उदाहरण के लिए EC2, वेब होस्ट आदि)? क्या ये विक्रेता आमतौर पर आपके लिए यह कस्टम सेटअप करने के लिए तैयार हैं, या क्या आपको ऐसा करने के लिए आमतौर पर व्यापार के संदर्भ में कुछ बड़ी न्यूनतम प्रतिबद्धता बनानी होगी?

— रनको

2

इसके अलावा, क्या आप चिंता करते हैं कि आप लोगों को अपना काम निकालने के लिए ऑफ-नेटवर्क 3 जी कार्ड का उपयोग करने के लिए मजबूर करते हैं? मेरे अनुभव में, लॉक-डाउन नेटवर्क अनिवार्य रूप से बहुत सारे 3 जी कार्ड और अन्य छिपे हुए परिधि का नेतृत्व करते हैं, क्योंकि लोग आवंटित समय में अपना काम नहीं कर सकते हैं यदि उन्हें अपने उपयोग को मंजूरी देने के लिए आईटी का इंतजार करना पड़ता है, अगर कोई भी जानता है कि कौन एक अपवाद प्राप्त करने के लिए कॉल करने के लिए। (एक गंभीर मामले में एक मेलस्वर शामिल होता है जो इंटरनेट से आने वाले अटैचमेंट को स्वीकार नहीं करता है। Yikes!) मैं उत्सुक हूं कि आप इस संतुलन को कैसे प्रबंधित करेंगे।

— रनको

1

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

— एकेडमिक

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

— duffbeer703

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

— duffbeer703

2

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

— कर्ट
स्रोत

अंतर्दृष्टि के लिए धन्यवाद। ऐसा लगता है कि आप 3 जी को एक गुप्त सुरंग नहीं मानेंगे। क्या आप इस बात पर कुछ प्रकाश डाल सकते हैं कि इंटरनेट पर संचार करते समय लोगों को पूरी तरह से ऑफ-नेटवर्क होने के लिए अधिक समझ में क्यों आता है? ऐसा लगता है कि आप आउटबाउंड के लिए खुले 22 से भी कम दुष्ट उपकरण पसंद करेंगे।

— रनको

1

"... आप आसानी से गैर-मानक बंदरगाहों पर एसएसएच पा सकते हैं ..." वास्तव में? 443 के अलावा बंदरगाहों पर SSL / TLS वार्ता की तलाश कर रहे हैं? बहुत उत्सुक।

— Dscoduc

हाँ, आप ssh ट्रैफ़िक का पता लगा सकते हैं, Google: snort / ssh / डिटेक्शन / कंटेंट / रूल्स, अन्य IDS के बारे में पता नहीं, लेकिन अगर Snort कर सकते हैं तो उन्हें ऐसा न करने के लिए बहुत ही व्यग्र होना पड़ेगा।

— कर्ट

1

मैं ऐसे कुछ लोगों को जानता हूं जो SSH की क्षमताओं का दुरुपयोग SSH में SOCKS प्रॉक्सी को स्थापित करने के लिए करते हैं, जिससे कुछ साइट प्रतिबंधों को दरकिनार किया जाता है।

या यहां तक कि कुछ सरल बंदरगाह अग्रेषण ( ssh -L ....), यदि बंदरगाह वास्तव में साइट प्रतिबंधों के कारण अवरुद्ध है, तो मैं यहां जाऊंगा:

स्थानीय व्यवस्थापक और
आपका प्रोजेक्ट मैनेजर

उन्हें एक मेज पर ले जाएं और उन्हें इस कारण से विस्तृत करें कि यह क्यों अवरुद्ध है। बेशक आपके पास आंतरिक उत्पाद विकसित करने के लिए बाहरी एसएसएच पोर्ट तक पहुंच की आवश्यकता के अच्छे कारण हैं (आंतरिक जा रहा है: आपको कंपनी के लिए काम करने की आवश्यकता क्यों है।

लेकिन मैं अभी तक निवर्तमान SSH को रोकने वाली कंपनी देख रहा हूँ :)

— serverhorror
स्रोत

मैंने एक कंपनी देखी है जो निवर्तमान SSH को ब्लॉक करती है। उन्होंने लगभग सभी चीजों को अवरुद्ध कर दिया और उदाहरण के लिए वायरस ने प्रॉक्सी का उपयोग करके सभी HTTP स्थानांतरणों की जाँच की। कंपनी एक केंद्रीय प्रतिभूति डिपॉजिटरी थी।

— एस्को लुओंटोला

मैं इस तरह एक कंपनी के लिए काम करता हूं। सौभाग्य से, SSH को https पर टनल किया जा सकता है। बेशक, वे केवल https को 443 पोर्ट करने की अनुमति देते हैं ... बचाव के लिए sslh!

— मिकेग

proxytunnel FTW :)

— serverhorror

1

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

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

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

— dr.pooter
स्रोत

0

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

— मैक्सिमस मिनिमस
स्रोत

0

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

हम एक ऐसी संस्था नहीं हैं जो सूचना के रिसाव से संबंधित है। लेकिन अगर हम थे, तो हमें ऑडिटिंग के साथ ड्रैकियन एसेट सिक्योरिटी पॉलिसी के साथ ड्रैकॉनियन नेटवर्क सिक्योरिटी पॉलिसी को संयोजित करना होगा। अपने ज्ञान के सर्वश्रेष्ठ के लिए, मुझे नहीं लगता कि एक बंद-शेल्फ सुरक्षा पैकेज मौजूद है जो किसी परिसंपत्ति के नेटवर्क जैक को बंद कर देगा जो किसी प्रकार के बाहरी नेटवर्क कनेक्शन के साथ आविष्कार करता है। यह शुरू हो सकता है।

इस तरह के पैकेज की अनुपस्थिति में, एसेट-इन्वेंट्री प्रक्रिया 3 जी या वाईमैक्स जैसे एंड-रन नेटवर्क कनेक्शन को पकड़ने के सर्वोत्तम तरीकों में से एक है।

और अंत में, टीसीपी / 22 का अंधा अवरुद्ध केवल अपने काम के नेटवर्क के लिए एयूपी का उल्लंघन करने वाले अंतिम-उपयोगकर्ताओं के इरादे को कम से कम रोक देगा।

— sysadmin1138
स्रोत

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

— duffbeer703

0

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

— शॉन एंडरसन
स्रोत

0

अधिकांश बड़े संगठन सब कुछ अवरुद्ध कर देंगे और केवल एक प्रॉक्सी सर्वर के माध्यम से HTTP / HTTPS तक पहुँचने की अनुमति देंगे।

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

— कैफा
स्रोत

0

पोर्ट 80 पर अपने दूरस्थ sshd को चलाने से कुछ भी नहीं रोकता है। ssh और sshd दोनों के पास पोर्ट सेट करने के लिए -p विकल्प है।

बेशक, अगर आपके प्रवेश स्मार्ट हैं, तो उन्हें ssh ट्रैफ़िक के लिए देखना चाहिए, न कि केवल 22 ट्रैफ़िक को पोर्ट करना चाहिए। तो, ऐसा लगता है कि आपके पास एक नीतिगत समस्या है, न कि तकनीकी समस्या।

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

— ब्रूस ओनेल
स्रोत