Seberapa amankah SSH ForceCommand pada host melompat?

Saya memiliki pengaturan berikut di jaringan saya:

Internet <--> Bastion <--> Local Network

Saya memiliki beberapa pengguna dan setiap pengguna ditugaskan ke mesin tertentu. Atau dengan kata lain: Setiap pengguna harus hanya memiliki akses ke salah satu server itu. Misalnya: User1 -> Machine1, User2 -> Machine2 dan sebagainya.

Para pengguna itu akan terhubung dari luar jaringan saya dan saya telah mempertimbangkan banyak opsi bagaimana meneruskan koneksi mereka melalui host benteng saya ke jaringan saya.

Akhirnya saya memilih Blok Pencocokan dan forcecommand.

Jadi, / etc / ssh / sshd_config saya di bastion terlihat seperti ini:

Match User User1
        ForceCommand ssh User1@Machine1 $SSH_ORIGINAL_COMMAND

User1 terhubung ke bastion host yang secara otomatis membuat koneksi dengan Machine1.

Sejauh yang saya mengerti ForceCommand, User1 tidak akan memiliki akses nyata ke host benteng, karena semua operasinya akan ditangani oleh blok pertandingan terlebih dahulu, maka dialihkan ke Machine1. Namun apakah ini benar? Apakah ini sudah cukup untuk menjadi pengaturan yang aman? Pengguna dipenjara di Machine1, jadi dia tidak akan memiliki banyak kemungkinan di sana.

Cara saya menggunakan bastion host menggunakan ProxyCommanddan -Wbendera seperti dalam contoh ini:

ssh -o ProxyCommand='ssh -W %h:%p user@bastion' user@machine

Saya menggunakan pendekatan ini untuk alasan keamanan. Komunikasi antara klien dan mesin target dienkripsi dan dikonfirmasi dari ujung ke ujung, yang berarti tetap aman bahkan jika benteng dikompromikan. Host bastion yang dikompromikan akan memberikan keamanan yang tidak kalah dari menggunakan ssh end-to-end tanpa bastion.

Ini juga menghilangkan kebutuhan untuk menggunakan agen forwarding. Klien dapat menggunakan otentikasi berbasis kunci terlebih dahulu untuk mengakses benteng dan kemudian lagi untuk mengakses host target tanpa salah satu dari mereka yang disediakan dengan koneksi agen yang dapat digunakan untuk menyalahgunakan kunci pribadi yang ada pada klien.

Ini juga membatasi kode saya bergantung pada host benteng. Saya tidak perlu menjalankan perintah sama sekali di benteng. -Wmengimplikasikan flag tanpa perintah dan juga satu port forwarding tunggal, port forwarding ini adalah semua yang diperlukan oleh tuan rumah benteng.

Dengan mengingat pendekatan ini, rekomendasi saya akan mengunci sebanyak mungkin bastion host yang memungkinkan hanya perintah dari struktur di atas yang akan digunakan.

The ~/.ssh/authorized_keysfile di benteng bisa dimiliki oleh root (seperti bisa semua direktori di jalan dari akar sistem file untuk itu), ini mengurangi risiko itu bisa dimodifikasi bahkan jika seseorang berhasil mematahkan sebagai user biasa di tuan rumah benteng.

Dalam authorized_keyshak klien dapat dibatasi dengan menggunakan opsi command, no-agent-forwarding, no-pty, no-user-rc, no-X11-forwarding, serta menggunakan permitopenuntuk forwardings pelabuhan batas untuk hanya memungkinkan akses ke port 22 pada host yang pengguna ini diperbolehkan akses ke.

Pada prinsipnya pendekatan ini akan aman bahkan jika banyak pengguna berbagi nama pengguna tunggal di benteng. Tetapi Anda mendapatkan sedikit lebih banyak pemisahan dengan menggunakan nama pengguna yang terpisah pada bastion.

Anda dapat dengan mudah menghindari ForceCommand karena itu menendang ketika shell Anda sudah mulai. Ini pada dasarnya berarti bahwa file rc shell Anda diproses terlebih dahulu dan kemudian ForceCommand jika Anda mengizinkannya untuk sampai ke sana. Sederhana exec shdalam file rc shell Anda akan menelurkan shell lain dan terus ForceCommand menunggu sampai Anda keluar dari shell ini.

Jadi intinya; jika pengguna dapat mengedit shell rc-nya (katakanlah .bashrc) melalui ftp, sftp, scp atau cara lain, maka ForceCommand bukanlah sesuatu yang bisa diandalkan.

Saya membayangkan itu baik-baik saja hampir sepanjang waktu, tetapi masalah dengan keamanan adalah hal-hal yang belum dipikirkan oleh siapa pun. Tidak ada jaminan.

Seperti misalnya untuk waktu yang lama tidak ada yang berpikir terlalu keras tentang cara fungsi dapat dibuat dari variabel lingkungan di bash, tetapi baru-baru ini orang menyadari bahwa dapat ditumbangkan, dan salah satu efek dari itu adalah bahwa ForceCommand dapat disiasati (pada paling tidak seperti yang diterapkan dalam file Authorized_key) jika shell pengguna adalah bash. Bash diperbaiki, dan semoga versi Anda mutakhir, tetapi hal-hal seperti ini terjadi.

Saya tidak sepenuhnya yakin apakah mendefinisikan ForceCommand secara efektif sama dengan mendefinisikan perintah-perintah itu di file Authorized_key. Saya belum melihat sedekat itu.

Jadikan .bashrcdimiliki oleh root:usergrptetapi masih dapat dibaca oleh sshd berjalan saat pengguna masuk. Setel perms / pemilik pada $ HOME yang tidak mengizinkan membuat file baru oleh pengguna. Dengan cara ini root mengontrol konten .bashrc, membiarkannya melakukan apa yang diperlukan, tetapi pengguna itu sendiri tidak dapat mengubah pengaturan itu, atau izin pada file / direktori yang secara tidak langsung akan memungkinkan mereka untuk mengubah konten .bashrc.

Saya punya ide lain. Untuk setiap pengguna di server benteng Anda dapat mendefinisikan shell mereka di / etc / passwd menjadi skrip bash yang menjalankan ssh user1 @ machine1, user2 @ machine2, dll. Dengan cara ini Anda akan memastikan bahwa mereka tidak memiliki valid apa pun shell pada server itu sendiri dan bahwa mereka hanya terhubung ke mesin yang mereka harus terhubung.