Bagikan melalui

Pertimbangan Keamanan untuk PowerShell Remoting dengan menggunakan WinRM

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 cara 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 PowerShell Remoting default

PowerShell Remoting dengan WinRM mendengarkan pada 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 Jarak Jauh PowerShell hanya dari dalam subnet yang sama. Anda harus secara eksplisit mengubah aturan tersebut untuk membuka PowerShell Remoting 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. Sebuah instans PowerShell yang dijalankan oleh satu pengguna tidak memiliki akses ke proses yang menjalankan instans PowerShell lainnya sebagai pengguna berbeda.

Log peristiwa yang dihasilkan oleh PowerShell Remoting

Para peneliti dari Mandiant menyajikan sesi di konferensi BlackHat yang memberikan ringkasan yang baik tentang log peristiwa dan bukti keamanan lainnya yang dihasilkan oleh sesi PowerShell Remoting. Untuk informasi selengkapnya, lihat 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 transfer yang digunakan (HTTP atau HTTPS), WinRM selalu mengenkripsi semua proses remoting 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 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 meniru server.

Autentikasi berbasis NTLM dinonaktifkan secara default. Anda dapat mengaktifkan NTLM 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 mengimplementasikan sertifikat SSL ke server untuk koneksi NTLM mustahil, Anda dapat mengabaikan kesalahan identitas yang muncul dengan menambahkan server ke daftar TrustedHosts WinRM. 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 abaikan kesalahan yang dihasilkan akibat ketidakmampuan memverifikasi identitas server.

Komunikasi Berkelanjutan

Setelah autentikasi awal selesai, WinRM mengenkripsi komunikasi yang sedang berlangsung. Saat Anda terhubung melalui HTTPS, WinRM menggunakan protokol TLS untuk menegosiasikan enkripsi yang digunakan untuk mengangkut data. Saat Anda tersambung melalui HTTP, WinRM menggunakan enkripsi tingkat pesan yang dinegosiasikan oleh protokol autentikasi awal.

  • Autentikasi dasar tidak menyediakan enkripsi.
  • Autentikasi NTLM menggunakan sandi RC4 dengan kunci 128-bit.
  • Elemen etype dalam tiket TGS menentukan enkripsi autentikasi Kerberos. 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-metode ini, dan kelebihan serta kekurangan dari masing-masing metode, lihat Membuat lompatan kedua dalam PowerShell Remoting.

Referensi