Mengapa Block Port 22 Outbound?


61

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?


1
Memblokir port hanya setengah pertempuran. Untuk menyelesaikan siklus, Anda harus memastikan layanan yang Anda coba lindungi tidak berjalan pada port non-standar.
aharden

1
Pertanyaannya seharusnya adalah "Mengapa memblokir port 22 outbound?" karena ada sejuta alasan mengapa Anda ingin menjalankan layanan ssh pada port non-standar. Keluar ... tidak banyak. Saya memberi +1 pada jawaban Robert Moir saat dia melakukan pekerjaan yang cukup bagus untuk menjelaskannya.
KPWINC

@KPWINC, menambahkan klarifikasi pada judul. Terima kasih!
runako

3
Pikirkan port 22 sebagai kotak pandora. Admin jaringan tidak dapat melihat apa yang ada dalam lalu lintas dan yang terburuk, ssh dapat digunakan untuk memintas keamanan jaringan yang membahayakan integritas jaringan.
biosFF

1
@biosFF: Port 443.
Hello71

Jawaban:


77

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.


1
Terima kasih atas tanggapan yang sangat mendalam. Ini adalah salah satu dari sedikit tanggapan yang mengatasi risiko teknis (berbeda dengan risiko politik) dari pelabuhan keluar terbuka.
runako

6
+1 untuk memberikan alasan teknis yang bagus. (Namun, ini hanya bisa dilakukan oleh intern jahat, yang juga bisa menggunakan port lain selain TCP 22 pada host jarak jauh. Dengan mana kami kembali ke beberapa blok semua kebijakan)
DerMike

7
Dengan protokol yang dirancang khusus dan beberapa pemrograman proxy yang pintar, ini bisa dilakukan melalui HTTPS - meskipun lebih lambat. Selama Anda mengizinkan lalu lintas terenkripsi keluar, Anda rentan terhadap "serangan" semacam ini.
Michael Sondergaard

3
Ini adalah respons yang baik JamesF, tetapi bukan masalah keamanan yang layak dipikirkan karena mengasumsikan skenario yang sangat langka dan memerlukan eksploitasi server / klien SSH. Pengguna jahat harus terlebih dahulu mengeksploitasi server SSH (di desktop Anda) dan mencari cara untuk kemudian mengeksploitasi klien SSH Anda (pada host bisnis Anda). Karena Anda tidak dapat menggunakan port 22 untuk mengakses atau berbicara dengan host bisnis-firewall (yang hanya memiliki port keluar 22). Jika standar keamanan Anda setinggi itu, host bisnis Anda seharusnya tidak ada di internet dalam situasi apa pun.
Dexter

1
Anda dapat menyalurkan lalu lintas melalui DNS (misalnya dengan iodine) jika HTTPS dan SSH tidak tersedia. Tapi ini sangat lambat.
Mark K Cowan

38

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.


3
+1 untuk Jika mereka memblokir SEMUA port kecuali ada kasus bisnis khusus untuk mengizinkan lalu lintas melalui port itu, pada titik yang dikelola dengan hati-hati maka mereka melakukannya karena mereka kompeten dalam pekerjaan mereka.
cop1152

-1 karena ssh tidak dapat dimonitor oleh petugas keamanan tetapi Telnet bisa. Maksud saya adalah bahwa meskipun ada kebijakan keamanan jaringan yang bodoh, mengkarakteristikkan kebijakan itu sebagai "acak" dan "memukul-mukul" tanpa pemahaman tentang kebutuhan bisnis aktual juga ditempatkan dengan singkat.
pcapademic

2
Ya, Anda berhak atas pendapat Anda, tentu saja Eric, dan saya akan dengan senang hati mengubah kata-kata itu jika Anda merasa merendahkan, tetapi saya cukup yakin bahwa kebijakan semacam itu akan dipikirkan dengan buruk atau kasus tepi yang sangat tidak biasa.
Rob Moir

+1 untuk "semua port"
Ian Boyd

18

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.


6
TELNET adalah lubang keamanan. Itu harus dilarang (ini hanya untuk orang-orang untuk membuat keputusan bodoh yang lebih baik di masa depan).
nik

3
Biarkan saya menguraikan di sini, apa yang lubang keamanan adalah subjektif ke permukaan yang diamankan. Jika Anda adalah pemilik situs web, mencoba terhubung ke server Anda, TELNET adalah lubang. Jika Anda adalah karyawan perusahaan keuangan yang mencoba terhubung ke luar ke server rumah Anda (melalui jalur yang dipantau oleh majikan Anda), SSH adalah lubang keamanan bagi majikan Anda!
nik

1
Mempertimbangkan betapa mudahnya memalsukan telnet di kedua arah, saya akan mengatakan bahwa telnet adalah lubang keamanan bahkan bagi perusahaan yang memungkinkannya keluar. Tetapi perusahaan yang memperbolehkannya tetapi tidak mengizinkan ssh tidak akan membuat keputusan keamanan yang cerdas dalam hal apa pun.
Paul Tomblin

3
Telnet adalah hadiah yang terus diberikan. Itu baik-baik saja 20 tahun yang lalu, tetapi sekarang saya benar-benar berharap itu akan berhenti.
Rob Moir

2
Itu semua tergantung pada POV Anda. Mereka mungkin memiliki orang-orang yang perlu mengakses beberapa proses lama melalui Telnet, yang kami dengan mudah diaudit. OTOH, Anda tidak tahu apa yang sedang terjadi dengan SSH, orang bisa membangun terowongan ke jaringan asing dan melakukan segala macam hal bodoh. Telnet tidak boleh digunakan hari ini, tetapi siapa pun yang mengizinkan SSH keluar perlu mencari karir baru.
duffbeer703

6

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.


3
Port 443 lebih baik, karena sudah diasumsikan dienkripsi, sehingga proksi tidak akan marah pada data aneh. Anda dapat dengan mudah mengatur server ssh mendengarkan pada port 443, dan dari sana Anda dapat pergi ke mana saja.
bandi

1
Di satu tempat saya bekerja, salah satu rekan kerja saya menggunakan sebuah program yang menyalurkan semua lalu lintas jaringan melalui sebuah ssh tunnel melalui proxy web kami ke port 80 di komputer rumahnya, dan dari sana ke internet. Dia bisa menggunakan protokol apa pun yang dia inginkan, tetapi sepertinya itu berasal dari rumahnya, bukan dari perusahaan. Untungnya dia tahu betapa tidak tahu-tahu administrator jaringan sehingga dia tidak mau mengambil risiko ketahuan.
Paul Tomblin

1
Tentu saja, jika Anda ketahuan telah melalui salah satu tarian rumit ini untuk mengelilingi firewall, Anda tidak bisa benar-benar menyatakan tidak bersalah dan tidak tahu. Agak sulit untuk melakukan semua itu dan mengatakan "bos maaf, itu hanya berhasil" jadi saya tidak menyadari bahwa saya melakukan sesuatu yang salah. "
Rob Moir

4

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


Bukankah itu menyiratkan bahwa mereka juga harus memblokir HTTPS?
runako

3
Tidak, mereka mengaktifkan inspeksi SSL. Proses ini mendekripsi HTTPS, lalu memasukkan kembali paket in / outbound dengan menyuntikkan sertifikat tepercaya di semua workstation dengan kebijakan grup. Dengan cara ini, mereka dapat memfilter / memindai sama seperti dengan HTTP. Industri perbankan adalah salah satu lingkungan yang paling kejam untuk mengunci jaringan.
spoulson

4

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.


3

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.


Ya, sangat mungkin bahwa semua layanan keluar yang tidak diperlukan untuk digunakan mungkin telah diblokir (secara default).
nik

Tetapi, memblokir tcp / 22 tidak akan mencegah komunikasi keluar yang aman (yang dapat dibuat pada port apa saja selama pengguna memiliki pendengar di luar, yang bukan hal yang sulit hari ini).
nik

Jika jaringan internal telah digunakan untuk komunikasi SSH, pemblokiran itu tidak akan berfungsi dan jika tidak ada komunikasi SSH diperlukan, biasanya tidak akan ada mesin mendengarkan SSH yang rentan di dalam jaringan. Dan, propagasi worm tipikal tidak mencoba untuk brute force SSH (jika Anda khawatir tentang hal itu lihat en.wikipedia.org/wiki/SSHBlock ), kemungkinan besar akan mencoba tcp / 445 dengan mesin windows Anda.
nik

3

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.


Terima kasih atas jawabannya. Bagaimana Anda menangani VPN khusus ke situs di luar kendali Anda (mis. EC2, Host web, dll.)? Apakah vendor ini biasanya bersedia melakukan pengaturan khusus ini untuk Anda, atau apakah Anda biasanya harus membuat komitmen minimum yang besar dalam hal bisnis untuk membuat mereka melakukannya?
runako

2
Juga, apakah Anda khawatir bahwa Anda memaksa orang untuk menggunakan kartu 3G off-jaringan untuk menyelesaikan pekerjaan mereka? Dalam pengalaman saya, jaringan yang terkunci pasti menyebabkan banyak kartu 3G dan pengelakan tersembunyi lainnya, karena orang tidak dapat menyelesaikan pekerjaannya dalam waktu yang ditentukan jika mereka harus menunggu IT untuk menyetujui penggunaannya, jika ada yang tahu siapa menelepon untuk mendapatkan pengecualian. (Satu kasus mengerikan termasuk server surat yang tidak akan menerima lampiran yang masuk dari Internet. Ya!) Saya ingin tahu bagaimana Anda mengelola saldo ini.
runako

1
Tambahkan komentar tentang port forwarding over ssh, dan saya pikir ini adalah jawaban yang benar untuk pertanyaan itu. ssh mungkin protokol yang baik untuk diizinkan melalui server proxy. Admin dapat memantau apa yang sedang terjadi, dapat memblokir penerusan port, dan orang-orang dapat menggunakannya untuk layanan shell dan penyalinan jarak jauh.
pcapademic

Kami cukup besar sehingga mungkin 90% dari layanan kami tidak memerlukan administrasi keluar untuk dijalankan. Biasanya ketika kami melakukannya, kami membuat terowongan VPN khusus sebagai persyaratan dalam RFP, yang cenderung menghilangkan vendor yang tidak atau tidak bisa menyediakannya. Karena itu, saya percaya bahwa kami memiliki jumlah minimal orang yang menggunakan 3G dan solusi serupa.
duffbeer703

Selain itu, Anda tidak dapat membiarkan petugas keamanan mendikte akses. Anda membiarkan dukungan aplikasi dan orang-orang jaringan bekerja di luar solusi yang dapat diterima, tunduk pada tinjauan keamanan. Cari tahu solusi itu di awal proses, bukan di pagi hari Anda harus mulai berproduksi. Itu membuat Anda jauh dari keterlambatan gaya DMV dalam mendapatkan permintaan.
duffbeer703

2

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.


Terima kasih atas wawasannya. Sepertinya Anda tidak akan menganggap 3G sebagai terowongan rahasia. Bisakah Anda menjelaskan mengapa lebih masuk akal untuk membuat orang benar-benar kehilangan jaringan saat berkomunikasi ke Internet? Sepertinya Anda lebih suka perangkat jahat bahkan kurang dari 22 terbuka untuk keluar.
runako

1
"... kamu dapat dengan mudah menemukan SSH pada port non-standar ..." Benarkah? Suka mencari negosiasi SSL / TLS pada port selain 443? Sangat penasaran.
Dscoduc

Yup, Anda dapat mendeteksi lalu lintas ssh, Google: snort / ssh / deteksi / konten / aturan, tidak tahu tentang IDS lain, tetapi jika Snort dapat melakukannya, mereka harus cukup bangkrut untuk tidak melakukannya juga.
Kurt

1

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 :)


Saya telah melihat satu perusahaan yang memblokir SSH keluar. Mereka juga memblokir hampir semua hal lain dan misalnya virus memeriksa semua transfer HTTP menggunakan proxy. Perusahaan itu adalah pusat penyimpanan efek.
Esko Luontola

Saya bekerja untuk perusahaan seperti ini. Untungnya, SSH dapat ditembus melalui https. Tentu saja, mereka hanya mengizinkan https ke port 443 ... sslh untuk menyelamatkan!
Mikeage

proxytunnel FTW :)
serverhorror

1

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.


0

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.


0

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.


Anda dapat menyesuaikan laporan dengan sesuatu seperti SCCM untuk mendapatkan informasi itu. Di tempat saya bekerja, menggunakan laptop pribadi atau kartu WAN untuk memintas keamanan jaringan tunduk pada tindakan disipliner.
duffbeer703

0

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.


0

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.


0

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.

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.