Pertimbangan Keamanan untuk Jarak Jauh PowerShell menggunakan WinRM

  • Artikel

PowerShell Remoting adalah cara yang disarankan untuk mengelola sistem Windows. PowerShell Remoting diaktifkan secara default di Windows Server 2012 R2 dan yang lebih tinggi. Dokumen ini mencakup masalah keamanan, rekomendasi, dan praktik terbaik saat menggunakan PowerShell Remoting.

Apa itu PowerShell Remoting?

PowerShell Remoting menggunakan Windows Remote Management (WinRM) untuk memungkinkan pengguna menjalankan perintah PowerShell di komputer jarak jauh. WinRM adalah implementasi Microsoft dari protokol Web Services for Management (WS-Management ). Anda dapat menemukan informasi selengkapnya tentang menggunakan PowerShell Remoting di Menjalankan Perintah Jarak Jauh.

PowerShell Remoting tidak sama dengan menggunakan parameter ComputerName cmdlet untuk menjalankannya di komputer jarak jauh, yang menggunakan Panggilan Prosedur Jarak Jauh (RPC) sebagai protokol yang mendasarinya.

Pengaturan default PowerShell Remoting

PowerShell Remoting (dan WinRM) mendengarkan port berikut:

  • HTTP: 5985
  • HTTPS: 5986

Secara default, PowerShell Remoting hanya mengizinkan koneksi dari anggota grup Administrator. Sesi diluncurkan di bawah konteks pengguna, sehingga semua kontrol akses sistem operasi diterapkan ke pengguna dan grup individual terus berlaku untuk mereka saat terhubung melalui PowerShell Remoting.

Pada jaringan privat, aturan Windows Firewall default untuk PowerShell Remoting menerima semua koneksi. Pada jaringan publik, aturan Windows Firewall default memungkinkan koneksi Akses Jauh PowerShell hanya dari dalam subnet yang sama. Anda harus secara eksplisit mengubah aturan tersebut untuk membuka PowerShell Jarak Jauh ke semua koneksi di jaringan publik.

Peringatan

Aturan firewall untuk jaringan publik dimaksudkan untuk melindungi komputer dari upaya koneksi eksternal yang berpotensi berbahaya. Berhati-hatilah saat menghapus aturan ini.

Isolasi proses

PowerShell Remoting menggunakan WinRM untuk komunikasi antar komputer. WinRM berjalan sebagai layanan di bawah akun Layanan Jaringan, dan menelurkan proses terisolasi yang berjalan sebagai akun pengguna untuk menghosting instans PowerShell. Instans PowerShell yang berjalan karena satu pengguna tidak memiliki akses ke proses yang menjalankan instans PowerShell sebagai pengguna lain.

Log peristiwa yang dihasilkan oleh PowerShell Remoting

FireEye telah memberikan ringkasan yang baik tentang log peristiwa dan bukti keamanan lainnya yang dihasilkan oleh sesi Jarak Jauh PowerShell, yang tersedia di Menyelidiki Serangan PowerShell.

Protokol enkripsi dan transportasi

Sangat membantu untuk mempertimbangkan keamanan koneksi Jarak Jauh PowerShell dari dua perspektif: autentikasi awal, dan komunikasi yang sedang berlangsung.

Terlepas dari protokol transportasi yang digunakan (HTTP atau HTTPS), WinRM selalu mengenkripsi semua komunikasi jarak jauh PowerShell setelah autentikasi awal.

Autentikasi awal

Autentikasi mengonfirmasi identitas klien ke server - dan idealnya - server ke klien.

Saat klien tersambung ke server domain menggunakan nama komputernya, protokol autentikasi default adalah Kerberos. Kerberos menjamin identitas pengguna dan identitas server tanpa mengirim kredensial yang dapat digunakan kembali.

Saat klien tersambung ke server domain menggunakan alamat IP-nya, atau tersambung ke server grup kerja, autentikasi Kerberos tidak dimungkinkan. Dalam hal ini, PowerShell Remoting bergantung pada protokol autentikasi NTLM. Protokol autentikasi NTLM menjamin identitas pengguna tanpa mengirim kredensial yang dapat didelegasikan. Untuk membuktikan identitas pengguna, protokol NTLM mengharuskan klien dan server menghitung kunci sesi dari kata sandi pengguna tanpa pernah bertukar kata sandi itu sendiri. Server biasanya tidak mengetahui kata sandi pengguna, sehingga berkomunikasi dengan pengontrol domain, yang mengetahui kata sandi pengguna dan menghitung kunci sesi untuk server.

Namun, protokol NTLM tidak menjamin identitas server. Seperti semua protokol yang menggunakan NTLM untuk autentikasi, penyerang dengan akses ke akun komputer komputer yang bergabung dengan domain dapat memanggil pengendali domain untuk menghitung kunci sesi NTLM dan dengan demikian meniru server.

Autentikasi berbasis NTLM dinonaktifkan secara default, tetapi dapat diizinkan dengan mengonfigurasi SSL di server target, atau dengan mengonfigurasi pengaturan WinRM TrustedHosts pada klien.

Menggunakan sertifikat SSL untuk memvalidasi identitas server selama koneksi berbasis NTLM

Karena protokol autentikasi NTLM tidak dapat memastikan identitas server target (hanya saja sudah mengetahui kata sandi Anda), Anda dapat mengonfigurasi server target untuk menggunakan SSL untuk PowerShell Remoting. Menetapkan sertifikat SSL ke server target (jika dikeluarkan oleh Otoritas Sertifikat yang juga dipercaya klien) memungkinkan autentikasi berbasis NTLM yang menjamin identitas pengguna dan identitas server.

Mengabaikan kesalahan identitas server berbasis NTLM

Jika menyebarkan sertifikat SSL ke server untuk koneksi NTLM tidak layak, Anda dapat menekan kesalahan identitas yang dihasilkan dengan menambahkan server ke daftar WinRM TrustedHosts . Harap dicatat bahwa menambahkan nama server ke daftar TrustedHosts tidak boleh dianggap sebagai bentuk pernyataan kepercayaan host itu sendiri - karena protokol autentikasi NTLM tidak dapat menjamin bahwa Anda sebenarnya terhubung ke host yang ingin Anda sambungkan. Sebagai gantinya, Anda harus mempertimbangkan pengaturan TrustedHosts sebagai daftar host yang ingin Anda tekan kesalahan yang dihasilkan dengan tidak dapat memverifikasi identitas server.

Komunikasi yang Sedang Berlangsung

Setelah autentikasi awal selesai, WinRM mengenkripsi komunikasi yang sedang berlangsung. Saat menyambungkan melalui HTTPS, protokol TLS digunakan untuk menegosiasikan enkripsi yang digunakan untuk mengangkut data. Saat menyambungkan melalui HTTP, enkripsi tingkat pesan ditentukan oleh protokol autentikasi awal yang digunakan.

  • Autentikasi dasar tidak menyediakan enkripsi.
  • Autentikasi NTLM menggunakan sandi RC4 dengan kunci 128-bit.
  • Enkripsi autentikasi Kerberos ditentukan oleh etype dalam tiket TGS. Ini adalah AES-256 pada sistem modern.
  • Enkripsi CredSSP menggunakan rangkaian sandi TLS yang dinegosiasikan dalam jabat tangan.

Membuat lompatan kedua

Secara default, PowerShell Remoting menggunakan Kerberos (jika tersedia) atau NTLM untuk autentikasi. Kedua protokol ini mengautentikasi ke komputer jarak jauh tanpa mengirim kredensial ke dalamnya. Ini adalah cara paling aman untuk mengautentikasi, tetapi karena komputer jarak jauh tidak memiliki kredensial pengguna, komputer dan layanan lain tidak dapat mengakses komputer dan layanan lain atas nama pengguna. Ini dikenal sebagai "masalah hop kedua".

Ada beberapa cara untuk menghindari masalah ini. Untuk deskripsi metode ini, dan pro dan kontra masing-masing, lihat Membuat hop kedua di PowerShell Remoting.

Referensi