Apakah mungkin untuk membuat firewall yang hanya mengizinkan lalu lintas server web yang sah pada port 443 dan bukan layanan lain?


19

Saya selalu menggunakan trik sederhana untuk mem-bypass sebagian besar firewall yang mencegah saya menggunakan port apa pun. Saya hanya membuka ssh di salah satu server saya di port 443 dan menyalurkan semua lalu lintas ke sana.

Namun saya sekarang berada di jaringan yang memiliki firewall yang belum pernah saya lihat sebelumnya dan saya bahkan tidak tahu itu mungkin.

Di jaringan ini Anda dapat menggunakan port 443 hanya untuk lalu lintas server web yang sah. Jika saya membuka ssh, atau apa pun di port 443 dan mencoba untuk terhubung di sana dari jaringan ini, itu langsung terbunuh. Jika saya memulai apache di server itu, itu berfungsi.

Bagaimana ini mungkin? Apakah ada beberapa firewall super canggih yang bahkan dapat menganalisis lalu lintas terenkripsi untuk memverifikasi itu lalu lintas https yang sah? Bagaimana?


4
Disebut SPI, peralatan kelas atas dapat melakukan pemeriksaan lebih lanjut dan memutuskan koneksi yang tidak diinginkan.
Linef4ult

Anda dapat membuat daftar putih dan hanya mengizinkan lalu lintas masalahnya adalah bahwa lalu lintas server web yang sah dapat berubah, bahwa alamat ip dapat dipindahkan, sehingga apa yang mungkin menjadi Microsoft hari ini adalah Google besok. Anda lebih baik menggunakan terowongan aman untuk berkomunikasi dengan server Anda, dan membuat daftar putih klien yang diizinkan, kemudian menentukan prosedur untuk menambahkan klien tambahan di masa mendatang (karena daftar itu akan berubah).
Ramhound

Anda dapat menggunakan mis. Obfsproxy untuk mengaburkan lalu lintas SSH sebagai lalu lintas HTTP (S) yang tidak berbahaya.
Michael

Jawaban:


26

Ya, dan mereka tidak membutuhkan sihir apa pun di sini, hanya pencocokan sepele pada konten paket TCP. Meskipun SSH dan TLS (SSL) mengenkripsi muatannya , tajuk protokol itu sendiri masih dapat dibedakan dan sangat berbeda satu sama lain. Misalnya, koneksi SSHv2 selalu dimulai dengan pengiriman klien SSH-2.0-(client name and version). Demikian pula, meskipun firewall Anda tidak dapat benar - benar tahu apakah koneksi TLS membawa HTTP di dalamnya, ia dapat mengenali TLS itu sendiri .

Memeriksa lapisan-lapisan di atas TCP pada umumnya termasuk dalam "Deep Packet Inspection", fitur yang relatif umum.

Salah satu cara yang jelas untuk mem-bypass ini adalah dengan tunnel SSH di dalam TLS - misalnya, menggunakan stunnel, haproxy, atau sniproxy. (Selain tunneling polos, di mana port 443 didedikasikan untuk SSH-over-TLS, mereka juga dapat melipatgandakan SSH / HTTP / protokol lain melalui port yang sama berdasarkan SNI dan ALPN.)

Meskipun ini tidak akan selalu mengalahkan analisis lalu lintas yang sangat canggih, itu masih akan memotong sebagian besar filter yang hanya memeriksa "apakah ini terlihat seperti header TLS".


Dan kemudian ada jenis firewall yang mengganggu - yang mencegat TLS untuk mendekripsi dan mengenkripsi ulang semua lalu lintas. Ini benar-benar dapat melihat di dalam TLS, dan dapat melewati permintaan HTTP sambil memblokir yang lainnya. (Perhatikan bahwa beberapa program antivirus juga melakukan hal yang sama.) Anda dapat mengenali jenis ini dengan melihat sertifikat server; semua sertifikat yang dihasilkan proxy terlihat sama, dan seringkali tidak lulus validasi, sedangkan sertifikat nyata dikeluarkan oleh berbagai CA yang berbeda.


1
Jadi SSH melakukan sendiri, keamanan tingkat aplikasi, daripada hanya sekedar protokol lain melalui TLS (yang secara default, itu tidak digunakan)?
Medinoc

2
@Medinoc: Ya, itu menerapkan fitur serupa (di SSHv2 "transportasi" dan "otentikasi" lapisan ) dan tidak perlu TLS untuk apa pun.
grawity

Apakah ada cara yang dapat diandalkan untuk mengenali firewall ini? Saya tidak suka gagasan bahwa seseorang memotong kata sandi saya saat menggunakan https. Saya bahkan tidak tahu itu mungkin sampai sekarang.
Petr

2
POST / HTTP / 1.0 base64garbage HTTP / 200 200 OK base64garbage membuat protokol transport
Joshua

3
@Petr Memperluas pernyataan grawity, jika itu komputer milik perusahaan, sertifikat mungkin telah diinstal sebelum mereka memberikannya kepada Anda; dan firewall MITM akan dikonfigurasi sehingga jika Anda tidak menggunakan sertifikat mereka tidak ada lalu lintas https akan diizinkan sehingga pilihan Anda mematuhi kebijakan atau tidak memiliki https. OTOH dalam hal itu memeriksa sertifikat mungkin akan mengatakan sesuatu seperti "diverifikasi oleh Nama Pemberi Kerja" dan sesuatu yang serupa dalam nama CA jika Anda menggali lebih dalam. misalnya di komputer kerja saya itu bluecoat.companyname.com (di mana bluecoat adalah merek firewall yang digunakan).
Dan Neely
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.