क्या फ़ायरवॉल बनाना संभव है जो केवल पोर्ट 443 पर वैध वेबसर्वर ट्रैफ़िक की अनुमति देता है और किसी अन्य सेवा को नहीं?

Question

मैंने हमेशा सबसे फ़ायरवॉल को बायपास करने के लिए सरल चाल का उपयोग किया, जिसने मुझे किसी भी पोर्ट का उपयोग करने से रोका। मैंने बस पोर्ट 443 पर अपने एक सर्वर पर ssh खोला और वहां से सारे ट्रैफिक को टनल किया।

हालाँकि मैं अब एक ऐसे नेटवर्क पर हूँ जो फ़ायरवॉल को मिला है जो मैंने पहले कभी नहीं देखा था और मुझे यह भी नहीं पता था कि यह संभव है।

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

यह संभव ही कैसे है? क्या कुछ सुपर परिष्कृत फ़ायरवॉल हैं जो यह सत्यापित करने के लिए एन्क्रिप्टेड ट्रैफ़िक का विश्लेषण करने में सक्षम हैं कि यह वैध https ट्रैफ़िक है? कैसे?

Comments

इसके SPI, उच्च अंत उपकरण अधिक उन्नत निरीक्षण कर सकते हैं और अवांछित कनेक्शन समाप्त कर सकते हैं।

— लाइनफुल्ट

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

— रामहुंड

आप SSH ट्रैफ़िक को हानिरहित HTTP (S) ट्रैफ़िक के रूप में बाधित करने के लिए उदाहरण के लिए Obfsproxy का उपयोग कर सकते हैं।

— माइकल

Answer 1

हां, और उन्हें यहां किसी जादू की जरूरत नहीं है, बस टीसीपी पैकेट सामग्री पर तुच्छ मिलान है। भले ही एसएसएच और टीएलएस (एसएसएल) अपने पेलोड को एन्क्रिप्ट करते हैं , लेकिन प्रोटोकॉल हेडर स्वयं अभी भी एक दूसरे से अलग और बहुत अलग हैं। उदाहरण के लिए, SSHv2 कनेक्शन हमेशा क्लाइंट भेजने के साथ शुरू होता है SSH-2.0-(client name and version)। इसी तरह, भले ही आपके फ़ायरवॉल को वास्तव में पता न चले कि क्या टीएलएस कनेक्शन HTTP को अंदर ले जाता है, यह TLS को ही पहचान सकता है ।

टीसीपी के ऊपर की परतों का निरीक्षण आम तौर पर "डीप पैकेट निरीक्षण" के अंतर्गत आता है, जो एक अपेक्षाकृत सामान्य विशेषता है।

बाईपास करने का एक स्पष्ट तरीका यह है कि एसएसएल को टीएलएस के अंदर रखा जाए - उदाहरण के लिए, स्टनेल, हाइपोक्सी, या स्निप्रोसी का उपयोग करके। (सादा टनलिंग के अलावा, जहाँ पोर्ट 443 SSH-over-TLS को समर्पित है, वे SSH / HTTP / अन्य प्रोटोकॉल को SNI और ALPN पर आधारित समान पोर्ट पर मल्टीप्लेक्स भी कर सकते हैं।)

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

---

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

Comments

तो SSH अपनी खुद की, अनुप्रयोग-स्तर की सुरक्षा करता है, बजाय TLS पर एक और प्रोटोकॉल (जो डिफ़ॉल्ट रूप से, इसका उपयोग नहीं करता है) के बजाय?

— मेडिनोक

@ मेदीनोक: हाँ, यह समान सुविधाओं (SSHv2 "ट्रांसपोर्ट" और "ऑथेंटिकेशन" लेयर्स में ) को लागू करता है और इसके लिए टीएलएस की आवश्यकता नहीं है।

— १६:१६

क्या इन सूंघने वाले फायरवॉल को पहचानने का कोई विश्वसनीय तरीका है? मुझे यह विचार पसंद नहीं है कि कोई व्यक्ति https का उपयोग करते समय मेरे पासवर्ड को बाधित करे। मुझे पता भी नहीं था कि यह अब तक संभव है।

— पेट्र

POST / HTTP / 1.0 base64garbage HTTP / 200 200 ओके बेस64 गार्गेज एक ट्रांसपोर्ट प्रोटोकॉल बनाता है

— जोशुआ

@Petr व्यापकता की टिप्पणियों को बढ़ाता है, अगर यह एक नियोक्ता का स्वामित्व वाला कंप्यूटर है, तो शायद यह आपके द्वारा दिए जाने से पहले ही स्थापित हो गए थे; और MITM फ़ायरवॉल को कॉन्फ़िगर किया जाएगा ताकि यदि आप उनके प्रमाण पत्र का उपयोग नहीं कर रहे हैं तो कोई भी https ट्रैफ़िक की अनुमति नहीं होगी, इसलिए आपकी पसंद नीति का अनुपालन करने वाली है या कोई https नहीं है। उस मामले में ओटीओएच प्रमाणित करने की स्थिति में शायद "एम्प्लॉयर नाम से सत्यापित" और सीए नाम में कुछ इसी तरह की बात कहेंगे यदि आप गहरी ड्रिल करते हैं। जैसे मेरे काम के कंप्यूटर पर यह bluecoat.companyname.com है (जहां bluecoat फ़ायरवॉल का ब्रांड है)।

— डैन नीली