Kebijakan pembatasan Applocker vs Software

Tujuannya adalah untuk mencegah pengguna menjalankan program yang tidak diinginkan pada server terminal.

Saya telah membaca banyak artikel dari Microsoft dan lainnya yang mengatakan bahwa fitur Applocker yang baru 100% lebih baik daripada Kebijakan Pembatasan Perangkat Lunak yang lama dan direkomendasikan sebagai pengganti yang terakhir.

Saya tidak yakin untuk memahami keuntungan nyata dari Applocker selain dari eksekusi mode kernel. Sebagian besar fungsinya dapat direproduksi dengan Kebijakan Pembatasan Perangkat Lunak.

Pada saat yang sama ia memiliki satu kelemahan BESAR yang membuatnya sangat tidak berguna: itu tidak dapat diperpanjang, dan Anda tidak dapat menambahkan ekstensi file khusus yang ingin Anda batasi.

Apa kelebihan Applocker dibandingkan SRP dan apa yang akan Anda rekomendasikan untuk kontrol perangkat lunak?

Kebijakan Pembatasan Perangkat Lunak tidak digunakan lagi oleh Microsoft ( secara teknis mengklaim SRP tidak didukung ), karena Windows 7 Enterprise / Ultimate memperkenalkan AppLocker.

Dalam praktiknya SRP memiliki jebakan tertentu, baik negatif palsu dan positif palsu. AppLocker memiliki keuntungan bahwa itu masih dipelihara dan didukung secara aktif. Jika AppLocker adalah pilihan maka itu bisa menjadi yang lebih murah - setelah memperhitungkan waktu dan risiko Anda. Mungkin juga ada alternatif pihak ketiga yang cocok (tapi pertanyaan ini tidak termasuk opsi itu :).

Mudah-mudahan Anda akan mendapatkan pemahaman yang sempurna dari perangkap SRP sebelum Anda jatuh ke dalam salah satu dari mereka </sarcasm>. Beberapa dari mereka dijelaskan dalam artikel keamanan yang bagus dari Vadims Podāns .

Perangkap yang dikenal

1. Secara default, eksekusi dari \Windowsfolder diizinkan. Beberapa sub-folder dapat ditulis oleh pengguna. Applocker adalah sama, tetapi setidaknya dokumentasi resmi menyebutkan batasan ini .

   EDIT: "Untuk menghitung semua folder dengan akses tulis pengguna yang dapat Anda gunakan, misalnya, utilitas AccessEnum dari paket Sysinternals." (atau AccessChk ).

   Secara teknis, dokumentasi juga memperingatkan Anda agar tidak mengabaikan aturan default . EDIT: Dokumen NSA memberikan 16 contoh folder ke daftar hitam dengan SRP , meskipun aturan jalur registri menggunakan backslash secara tidak benar sehingga harus dikoreksi (lihat titik di jalur registri di bawah) dan memperingatkan tentang entri daftar hitam umum yang terlalu luas.

   Pertanyaan yang jelas adalah mengapa kita tidak memilih jalur individual dengan hati-hati \Windows. (Termasuk \Windows\*.exewarisan System32\*.exe,, dll). Saya tidak melihat ada jawaban untuk ini di mana saja :(.

2. Menggunakan variabel lingkungan seperti %systemroot%, SRP dapat dilewati oleh pengguna dengan menghapus variabel lingkungan. EDIT: Ini tidak digunakan dalam standar yang disarankan. Namun mereka mungkin tergoda untuk menggunakannya. Footgun ini diperbaiki di AppLocker, karena tidak pernah melihat variabel lingkungan.

3. Default yang disarankan lalai untuk memungkinkan dua yang berbeda \Program Filesdigunakan pada instalasi 64-bit modern. Saat menyelesaikan ini menggunakan "jalur registri" yang lebih aman, ada laporan penolakan palsu dalam situasi acak, yang dapat dengan mudah dilewatkan dalam pengujian. mis. lihat komentar di SpiceWorks SRP howto . EDIT: Ini berkaitan dengan aplikasi 32-bit yang membaca jalur yang relevan dari WOW6432Node registri: resolusi adalah menambahkan kedua jalur ini ke SRP untuk memungkinkan semua program bekerja pada mesin 32-bit dan 64-bit sebagai Tidak Terbatas apakah dimulai dari proses host x64 atau x86:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. Ekstensi default diabaikan untuk melarang skrip PowerShell (* .PS1) yang didukung oleh Windows . (Lihat video ). Dan APPX juga ... juga menurut tabel perbandingan Microsoft, SRP tidak dapat mengelola "Paket aplikasi" di Windows 8, saya tidak tahu apa artinya ini.
5. Aturan Registry jalan tidak harus memiliki garis miring segera setelah tanda persen terakhir (meskipun termasuk dalam Microsoft sendiri built-in aturan untuk XP / Server 2003) dan backslash apapun harus diganti dengan forwardslashes agar aturan kerja ( 1 / 2 / 3 ).
6. Dari sumber yang saya temukan untuk SRP, tidak ada yang menaruh daftar lengkap di atas untuk Anda. Dan saya hanya menemukan artikel Vadims Podan secara tidak sengaja. Apa lagi yang mengintai di luar sana?
7. Banyak sumber merekomendasikan hanya menghapus file LNK dari daftar. (Dan Pintasan Web untuk menghindari melanggar Favorit ?!). Yang mengganggu, tampaknya tidak ada sumber yang membahas kerentanan LNK ... atau meminta penerjemah skrip untuk menjalankan file dengan ekstensi yang tidak terduga, misalnyawscript /e ... atau mungkin memasukkan cukup shellcode dalam parameter skrip inline ... dll.
8. Jika Anda mencoba berkompromi dengan mengizinkan file LNK di desktop, dan Anda meninggalkan pengguna dengan akses tulis ke desktop, mereka sekarang dapat mem-bypass kebijakan Anda sepenuhnya. Tip yang indah dari Vadims Podāns lagi. Perhatikan bahwa penjelasannya berlaku untuk menggunakan ekstensi apa pun dalam aturan jalur. Microsoft menghadirkan beberapa contohnya termasuk *.Extension, tanpa peringatan. Jadi Anda tidak bisa mempercayai dokumentasi resmi , dan sepertinya tidak mungkin diperbaiki sekarang.
9. [Kerugian AppLocker potensial]. Vadims Podāns melaporkan bahwa entri SRP menggunakan drive yang dipetakan tidak berfungsi. Jalur UNC harus digunakan sebagai gantinya. Mungkin mereka kemudian berlaku untuk mengakses melalui drive yang dipetakan? tidak 100% jelas. Rupanya AppLocker berbeda: tidak berfungsi dengan baik :(. "Karena alasan yang tidak diketahui, jalur UNC tidak berfungsi di Applocker! Ini berarti bahwa jika aplikasi Anda diinstal di jaringan, Anda harus membuat aturan hash atau penerbit . "

Pendekatan pragmatis

Daftar putih perangkat lunak berpotensi menjadi pertahanan yang sangat kuat. Jika kita bersikap sinis: inilah mengapa Microsoft mencela versi yang lebih murah dan menciptakan yang lebih rumit.

Mungkin tidak ada opsi lain yang tersedia (termasuk solusi pihak ketiga). Maka pendekatan pragmatis adalah mencoba mengkonfigurasi SRP sesederhana mungkin. Perlakukan itu sebagai lapisan pertahanan tambahan, dengan lubang yang dikenal. Mencocokkan perangkap di atas:

1. Mulai dari aturan default (dari era pra-Win7 :).
2. Lebih suka tidak menggunakan variabel lingkungan, mis %systemroot%.
3. Tambahkan aturan untuk memastikan kedua \Program Files\direktori diizinkan pada mesin 64-bit modern. "Jalur registri" tambahan yang perlu Anda tambahkan \Program Files\di komputer 64-bit adalah %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%dan %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. Saat menambahkan aturan jalur registri, tinggalkan backslash segera setelah tanda persen, dan ganti backslash lebih lanjut \dengan forwardslashes /(misalnya %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Tambahkan PS1 ke daftar ekstensi yang dikontrol.
6. Memahami bahwa konfigurasi SRP yang dapat dikelola tidak aman terhadap pengguna yang bertekad untuk mengalahkannya. Tujuannya adalah untuk membantu / mendorong pengguna untuk bekerja di dalam kebijakan, untuk melindungi mereka terhadap serangan seperti "unduhan drive-by".
7. Izinkan file LNK. (Lebih disukai dengan menghapusnya dari daftar ekstensi, bukan melalui beberapa aturan jalur).
8. Lihat di atas :).
9. Pastikan folder skrip masuk Anda diizinkan. Dokumen NSA menyarankan untuk menambahkan \\%USERDNSDOMAIN%\Sysvol\. (Lihat poin # 2, desah, lalu lihat poin # 6).

Saya setuju bahwa SRP memiliki beberapa fitur tambahan yang benar-benar dapat dimanfaatkan oleh AppLocker.

Yang sedang berkata, saya melihat manfaat besar dari AppLocker (sebagaimana didokumentasikan oleh perbandingan ini ) sebagai:

• Aturan AppLocker dapat ditargetkan untuk pengguna tertentu atau sekelompok pengguna, sedangkan SRP diberlakukan di seluruh komputer.
• AppLocker mendukung mode audit sehingga aturan dapat diuji dalam produksi sebelum ditegakkan. SRP tidak memiliki mode log-only yang setara.

Keuntungan terbesar bagi saya adalah kemampuan untuk membuat daftar putih executables yang ditandatangani oleh penerbit. Lihatlah http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx ini

Tidak ada manfaat dari AppLocker, kebohongan terang-terangan yang diterbitkan Microsoft: 1. GPO dengan aturan yang lebih aman dapat dilampirkan ke pengguna dan grup pengguna; 2. Windows Vista memperkenalkan beberapa GPO lokal yang mencapai hasil yang sama tanpa pengontrol domain; 3. mode audit tersedia melalui fitur logging yang diperluas tanpa penegakan hukum.

Saya menggunakan Applocker di perusahaan saya. Strategi yang kami gunakan adalah: Tolak semuanya sebagai garis dasar (pada kenyataannya: standar Applocker), lalu lakukan apa yang disarankan: buat aturan yang memungkinkan hanya aplikasi yang ditandatangani (kantor, adobe, wintools, kapak dll). Sebagian besar, mungkin semua malware adalah perangkat lunak yang tidak ditandatangani sehingga tidak akan dijalankan. Ini hampir tidak ada pemeliharaan. Saya hanya perlu mengizinkan 3 aplikasi lawas tambahan.

Lebih lanjut saya tidak dapat mengkonfirmasi bahwa seseorang tidak dapat menggunakan jalur UNC. Dalam beberapa aturan keselamatan ditolak saya menggunakan UNC-path dengan sukses. Perangkap dalam menggunakan variabel lingkungan: mereka tidak bekerja untuk Applocker. Gunakan * wildcard. Saya menggunakannya pada Windows 2008 R2 dan Windows 2012 R2.

Saya sangat menyukainya: hampir tidak ada kejatuhan kinerja. Seperti yang dikatakan dalam dokumentasi: Applocker mengandalkan Layanan Identitas Aplikasi (pastikan itu dimulai secara otomatis).