Mengapa Block Port 22 Outbound?

Saya seorang programmer, dan saya telah bekerja untuk beberapa klien yang jaringannya memblokir koneksi keluar pada port 22. Mengingat bahwa programmer sering perlu menggunakan port 22 untuk ssh, ini seperti prosedur kontraproduktif. Paling-paling, itu memaksa programmer untuk menagih perusahaan untuk Internet 3G. Paling buruk, itu berarti mereka tidak dapat melakukan pekerjaan mereka secara efektif.

Mengingat kesulitan yang ditimbulkannya, bisakah sysadmin yang berpengalaman tolong jelaskan manfaat yang diinginkan untuk apa yang tampak seperti tindakan kalah-kalah?

Saya tidak melihat ada yang menjelaskan risiko spesifik dengan penerusan port SSH secara terperinci.

Jika Anda berada di dalam firewall dan memiliki akses SSH keluar ke mesin di internet publik, Anda dapat SSH ke sistem publik itu dan dalam proses membuat terowongan sehingga orang-orang di internet publik dapat ssh ke sistem di dalam jaringan Anda, sepenuhnya melewati firewall.

Jika fred adalah desktop Anda dan barney adalah server penting di perusahaan Anda dan wilma bersifat publik, menjalankan (di fred):

ssh -R *: 9000: barney: 22 wilma

dan masuk akan membiarkan penyerang ssh ke port 9000 di wilma dan berbicara dengan daemon SSH barney.

Firewall Anda tidak pernah melihatnya sebagai koneksi masuk karena data dilewatkan melalui koneksi yang awalnya dibuat dalam arah keluar.

Ini menjengkelkan, tetapi kebijakan keamanan jaringan yang sepenuhnya sah.

Jika mereka memblokir kesalahan port, membiarkan beberapa hal melewatinya dan memblokir beberapa hal lainnya secara acak (saya suka kisah sedih Paul Tomblin tentang orang-orang yang memblokir SSH dan mengizinkan Telnet), maka mereka juga memiliki kasus tepi yang sangat aneh tentang bagaimana mereka pergi tentang mengamankan perimeter jaringan mereka, atau kebijakan keamanan mereka, dari luar setidaknya, tampaknya dipikirkan dengan buruk. Anda tidak dapat memahami situasi seperti itu, jadi cukup beri mereka tarif yang berlaku untuk orang-orang yang menyusahkan dan melanjutkan hari Anda.

Jika mereka memblokir SEMUA port kecuali ada kasus bisnis khusus untuk memungkinkan lalu lintas melalui port itu, pada titik yang dikelola dengan hati-hati maka mereka melakukannya karena mereka kompeten di pekerjaan mereka.

Ketika Anda mencoba untuk menulis aplikasi yang aman, apakah Anda membuatnya mudah bagi proses lain untuk membaca dan menulis informasi sesuka mereka atau apakah Anda memiliki beberapa API terdokumentasi dengan cermat yang Anda harapkan akan dihubungi orang dan yang Anda bersihkan dengan hati-hati?

Manajemen risiko - jika Anda merasa bahwa lalu lintas ke atau dari jaringan Anda ke Internet adalah risiko, maka Anda berupaya meminimalkan jumlah cara lalu lintas dapat mencapai Internet, baik dalam hal jumlah rute dan sejumlah metode. Anda kemudian dapat memantau dan memfilter gateway dan port "berkah" terpilih ini untuk mencoba dan memastikan bahwa lalu lintas yang melintasi mereka adalah yang Anda harapkan.

Ini adalah kebijakan firewall "default deny" dan biasanya dianggap sebagai ide yang bagus, dengan beberapa peringatan yang akan saya sampaikan. Apa artinya semua diblokir kecuali ada alasan khusus untuk membuka blokirnya, dan manfaat alasan itu lebih besar daripada risikonya.

Sunting: Saya harus mengklarifikasi, saya tidak hanya berbicara tentang risiko satu protokol diizinkan dan yang lain diblokir, saya sedang berbicara tentang risiko potensial terhadap bisnis informasi yang diizinkan mengalir masuk atau keluar dari jaringan secara tidak terkendali cara.

Sekarang untuk peringatan, dan mungkin rencana untuk membebaskan:

Ini bisa menjengkelkan ketika Anda dihalangi dari sesuatu, yang merupakan posisi Anda menemukan diri Anda dengan beberapa klien Anda. Terlalu sering, orang-orang yang bertanggung jawab atas firewall berpikir tugas mereka untuk mengatakan "Tidak", daripada "Inilah risikonya, sekarang apa manfaatnya, mari kita lihat apa yang bisa kita lakukan".

Jika Anda berbicara kepada siapa pun yang mengelola keamanan jaringan untuk klien Anda, mereka mungkin setuju untuk mengatur sesuatu untuk Anda. Jika Anda dapat mengidentifikasi beberapa sistem tertentu pada akhirnya Anda memerlukan akses ke, dan / atau menjamin Anda hanya akan terhubung dari alamat IP tertentu, mereka mungkin jauh lebih bahagia untuk membuat pengecualian firewall untuk koneksi SSH untuk kondisi tertentu daripada mereka akan hanya membuka koneksi ke seluruh internet. Atau mereka mungkin memiliki fasilitas VPN yang dapat Anda gunakan untuk menggali terowongan melalui firewall.

Sebuah perusahaan besar tertentu di Rochester NY yang dulu membuat banyak film diblokir ssh ketika saya bekerja di sana, tetapi mengizinkan telnet ! Ketika saya bertanya tentang hal itu, mereka berkata bahwa ssh adalah lubang keamanan.

Dengan kata lain, perusahaan terkadang membuat keputusan bodoh, dan kemudian membuat alasan omong kosong tentang keamanan daripada mengakui kesalahan mereka.

Saya dapat memahami pemblokiran komunikasi SSH masuk jika perusahaan tidak mengizinkan login eksternal. Tapi, ini pertama kalinya saya mendengar tentang blok SSH keluar.

Yang penting untuk dicatat adalah bahwa firewall semacam itu mungkin hanya akan membatasi pengguna SSH biasa. Jika seseorang benar-benar ingin SSH di luar (yang biasanya akan ke server / mesin mereka memiliki akses signifikan ke, di luar jaringan perusahaan) mereka dapat dengan mudah menjalankan server SSH pada port selain 22 (katakanlah, port 80). Blok akan dilewati dengan mudah.

Ada juga beberapa alat domain publik yang akan memungkinkan Anda keluar dari perusahaan melalui HTTP (port 80 atau port HTTPS 443) dan memberikan proxy untuk memungkinkan Anda terhubung ke port 22 di luar.

Sunting: Oke, tunggu sebentar, saya punya ide mengapa ini bisa menjadi kebijakan.

Terkadang, orang menggunakan terowongan SSH untuk mem-bypass firewall keluar dasar untuk protokol seperti IM dan Bittorrent (misalnya). Ini // mungkin // telah memicu kebijakan semacam itu. Namun, saya masih merasa bahwa sebagian besar alat terowongan ini akan dapat bekerja pada port selain 22.

Satu-satunya cara terowongan keluar tersebut dapat diblokir adalah dengan mendeteksi komunikasi SSH on the fly dan (secara dinamis) memblokir koneksi TCP ini.

Mungkin masalah regulasi / kepatuhan. Majikan Anda ingin dapat membaca / mengarsipkan semua komunikasi. Ini sangat sering menjadi persyaratan dalam industri seperti perbankan.

Ada dua alasan utama untuk memblokir port 22, menurut pendapat saya.

Pertama, seperti yang orang katakan, penerusan port SSH dapat digunakan sebagai proxy atau memotong di sekitar pelabuhan dan layanan lain untuk menghindari kebijakan TI yang menyatakan lalu lintas semacam itu tidak diperbolehkan.

Kedua, banyak malware / botnet akan menggunakan port 22 karena sering dianggap "aman" dan karenanya diizinkan. Mereka kemudian dapat meluncurkan proses keluar port itu, dan komputer yang terinfeksi mungkin juga meluncurkan serangan brute force SSH.

Lebih sering daripada tidak, itu adalah kasus pemblokiran semua koneksi keluar kecuali diperlukan, dan sampai Anda mencoba tidak ada yang meminta port 22 tersedia untuk koneksi keluar (hanya 80, 433, dan seterusnya). Jika hal ini terjadi maka solusinya mungkin sesederhana menghubungi IS / IT dan memberi tahu mereka mengapa Anda perlu menambahkan pengecualian sehingga stasiun Anda dapat membuat koneksi SSH keluar ke host tertentu atau secara umum.

Terkadang ada kekhawatiran bahwa orang mungkin menggunakan fasilitas untuk menggunakan SSH sebagai cara untuk mengatur proxy (melalui port forwarding melalui tautan) untuk menghindari kontrol lain. Ini bisa menjadi faktor yang sangat penting dalam beberapa industri yang diatur (yaitu bank) di mana semua komunikasi perlu dipantau / dicatat karena alasan hukum (mencegah perdagangan orang dalam, mendeteksi / memblokir transfer data perusahaan atau pribadi, dan sebagainya) atau perusahaan di mana ada adalah ketakutan besar akan kebocoran internal yang memberi, secara tidak sengaja atau sebaliknya, rahasia dagang. Dalam kasus ini menggunakan tautan 3G Anda (atau teknik lain seperti mencoba melakukan tunnel SSH melalui HTTP) untuk menghindari pembatasan mungkin merupakan pelanggaran kontrak Anda dan karenanya merupakan pelanggaran pemecatan (atau, mungkin lebih buruk, pelanggaran hukum) jadi berhati-hatilah untuk Dapatkan tindakan Anda disetujui sebelum Anda mencobanya.

Alasan lain mungkin untuk mengurangi jejak keluar (ke layanan internal yang dapat diakses oleh host di dalam firewall perusahaan dan ke dunia pada umumnya) jika sesuatu yang tidak diinginkan berhasil dipasang pada perusahaan yang menjalankan mesin. Jika tidak ada koneksi SSH yang memungkinkan pada port 22, banyak peretasan sederhana yang mencoba menggunakan login SSH brute-force karena salah satu rute propagasi mereka akan diblokir. Dalam hal ini, Anda dapat meminta pengecualian untuk ditambahkan agar mesin Anda dapat membuat koneksi SSH, jika koneksi ini dapat dibenarkan untuk orang-orang yang mengendalikan firewall.

Klien Anda mungkin memiliki data non-sepele yang ingin mereka simpan. SSH Outbound adalah hal yang sangat buruk untuk terbuka untuk seluruh jaringan. Cukup sepele untuk mem-bypass proksi, membocorkan data sensitif, dan secara umum menjengkelkan.

IMO, segala sesuatu yang melewati batas jaringan / internet harus dipahami dan dikontrol. Jika sekelompok devs memerlukan akses ke server di penyedia hosting melalui ssh, tidak apa-apa - tetapi juga perlu didokumentasikan. Secara umum di tempat-tempat saya bekerja, kami membangun koneksi VPN situs ke situs khusus untuk lokasi di luar jaringan kami, (pada dasarnya memperluas jaringan internal kami) dan menghindari protokol klien seperti SSH melalui internet.

Karena SSH dapat digunakan sebagai VPN. Ini dienkripsi sehingga admin jaringan benar-benar tidak tahu apa yang meninggalkan jaringan mereka (dump database pelanggan, dll.). Saya baru saja membahas hal ini di kolom bulanan "Terowongan Rahasia" . Biaya beberapa internet 3G jauh lebih murah daripada harus khawatir tentang protokol terenkripsi menyalurkan data Anda keluar dari jaringan. Ditambah lagi jika Anda memblokir default port keluar 22 dan memeriksa lalu lintas Anda dapat dengan mudah menemukan SSH pada port non-standar dan dengan demikian menemukan orang yang melanggar kebijakan keamanan.

Saya kenal beberapa orang yang menyalahgunakan kemampuan SSH untuk menginstal proxy SOCKS melalui SSH, sehingga menghindari beberapa batasan situs.

Atau bahkan beberapa penerusan port sederhana ( ssh -L ....), jika port memang diblokir karena batasan situs saya akan pergi ke:

• admin lokal dan
• manajer proyek Anda

bawa mereka ke meja dan biarkan mereka menguraikan alasan mengapa ini diblokir. Tentu saja Anda harus memiliki alasan yang bagus mengapa Anda memerlukan akses ke port SSH eksternal untuk mengembangkan produk internal (makhluk internal: Mengapa Anda memerlukan akses ke boxA.example.com ketika Anda bekerja di perusahaan snakeoil.invalid)

Tapi saya belum melihat perusahaan memblokir SSH keluar :)

Jawaban yang jelas semuanya telah dinyatakan. Ini adalah protokol terenkripsi yang dapat digunakan untuk menghindari kebijakan melalui pembuatan terowongan (ini adalah cara yang bagus untuk melewati filter web perusahaan) serta ancaman yang ditimbulkan oleh saluran komunikasi yang tidak sah (reverse proxy).

Memang benar, telnet harus dihancurkan di jaringan modern apa pun. Tapi, saya bisa melihat memungkinkan telnet keluar dari jaringan sambil melarang ssh. Telnet kurang mampu daripada ssh dan saya selalu bisa memantau aliran, secara real-time, melalui penghirup. Jika saya tidak memiliki perangkat telnet di jaringan inti saya, dan beberapa pengguna ingin melakukan telnet, apa yang saya pedulikan. Saya bisa melihatnya, dan memverifikasi bahwa itu bukan ancaman.

Tentu saja, semua ini tergantung pada gagasan bahwa kebijakan default adalah memblokir semua jalan keluar dan hanya mengizinkan protokol tertentu. Poin bonus jika Anda mem-proxy mereka sebelum mencapai ujung.

Ini bukan kasus yang secara khusus memblokir port 22 karena admin memiliki sesuatu yang menentang SSH, lebih merupakan kasus hanya membuka port yang mereka tahu perlu dibuka. Jika admin Anda belum diberi tahu bahwa SSH diperlukan terbuka, admin Anda akan memblokirnya, dengan prinsip yang sama yang berlaku untuk menonaktifkan layanan yang tidak digunakan di server.

Jelas, blok TCP / 22 keluar mudah untuk dihindari kecuali administrator jaringan telah mengambil upaya serius dan serius untuk memblokir lalu lintas SSH secara khusus . Terlebih lagi, administrator aset harus cukup siap untuk menjalankan inventarisasi aset yang cukup untuk menangkap modem 3G, dan alamat IP yang mencurigakan pada NIC kedua. Kami memiliki layanan ClearWire di area kami, jadi kami bahkan memiliki WiMax sebagai opsi jangka-akhir seputar keamanan jaringan kami.

Kami bukan lembaga yang terutama peduli dengan kebocoran informasi. Tetapi jika ya, kita perlu menggabungkan kebijakan keamanan jaringan kejam dengan kebijakan aset kejam, dengan audit. Sepengetahuan saya, saya tidak berpikir ada paket keamanan off-the-shelf yang akan mematikan jack jaringan aset yang persediaan dengan koneksi jaringan eksternal semacam. Itu mungkin akan datang.

Dengan tidak adanya paket seperti itu, proses inventarisasi aset adalah salah satu cara terbaik untuk menangkap koneksi jaringan yang dijalankan seperti 3G atau WiMax.

Dan akhirnya, pemblokiran blind TCP / 22 hanya akan memblokir sedikit pun niat pengguna akhir untuk melanggar AUP untuk jaringan kerja mereka.

Saya telah melihat 22 diblokir ketika mereka menemukan bahwa orang-orang mengarahkan lalu lintas http melalui 22. Itu adalah show stopper bagi kita yang membutuhkannya tetapi org yang berdiri di tanah mereka.

Sebagian besar organisasi besar akan memblokir semuanya dan hanya mengizinkan akses HTTP / HTTPS melalui server proxy.

Saya akan sangat terkejut mendengar adanya perusahaan yang mengizinkan koneksi eksternal langsung dari desktop atau server kecuali ada kebutuhan khusus.

Tidak ada yang menghentikan Anda dari menjalankan sshd jarak jauh di port 80. Baik ssh dan sshd memiliki opsi -p untuk mengatur port.

Tentu saja, jika admin Anda cerdas, mereka harus mengawasi lalu lintas ssh, bukan hanya lalu lintas port 22. Jadi, sepertinya Anda memiliki masalah kebijakan, bukan masalah teknologi.

Seperti yang ditunjukkan oleh orang lain, protokol terenkripsi dapat menyebabkan mulas pada orang-orang yang harus khawatir tentang berbagai masalah kepatuhan.