Masalah Pencatatan Kejadian Keamanan Sistem Windows

Sistem operasi Windows memiliki sistem pencatatan peristiwa keamanan yang cukup bagus. Banyak hal baik telah ditulis tentangnya di berbagai publikasi dan ulasan, tetapi artikel ini akan membahas hal lain. Di sini kita berbicara tentang masalah dan kekurangan dalam sistem ini. Beberapa masalah yang dipertimbangkan akan menjadi tidak kritis, hanya mempersulit prosedur untuk menganalisis peristiwa, sementara yang lain akan menimbulkan ancaman keamanan yang sangat serius.

Masalah yang diidentifikasi diuji pada Windows 7 Maximum (versi Rusia), Windows 7 Professional (versi bahasa Inggris), Windows 10 Pro (versi Rusia), Windows Server 2019 Datacenter (versi Rusia). Semua sistem operasi telah sepenuhnya diperbarui.

Masalah No. 1. Sistem manajemen parameter audit gagal

Masalahnya dikonfirmasi pada Windows 7/10 / Server 2019.

Deskripsi masalah

Ambil Windows 7 dan instal dengan pengaturan default. Kami tidak akan memasukkan domain. Mari kita lihat pengaturan audit acara keamanan. Untuk melakukan ini, buka snap-in Kebijakan Keamanan Lokal (secpol.msc, atau Control Panel -> Tools Administratif -> Kebijakan Keamanan Lokal) dan lihat pengaturan audit dasar (Pengaturan Keamanan -> Kebijakan Lokal -> Kebijakan Audit) )



Seperti yang Anda lihat, audit tidak dikonfigurasi. Sekarang mari kita lihat kebijakan audit lanjutan ("Pengaturan Keamanan -> Konfigurasi Kebijakan Audit Lanjutan -> Kebijakan Audit Sistem - Objek Kebijakan Grup Lokal").



Di sini, audit juga tidak dikonfigurasikan. Jika demikian, maka secara teori seharusnya tidak ada peristiwa keamanan dalam log. Kami periksa. Buka log keamanan (eventvwr.exe, atau "Panel Kontrol -> Alat Administratif -> Lihat Acara").



Pertanyaan: "Dari mana peristiwa itu berasal dari log keamanan jika audit tidak dikonfigurasi sama sekali?!"

Penjelasan

Untuk memahami alasan perilaku ini, Anda perlu "berada di bawah tudung" sistem operasi. Untuk memulainya, kita akan berurusan dengan kebijakan audit dasar dan lanjutan.

Sebelum Windows Vista, hanya ada satu kebijakan audit, yang sekarang disebut dasar. Masalahnya adalah bahwa rincian manajemen audit pada saat itu sangat rendah. Jadi, jika diminta untuk melacak akses ke file, maka mereka memasukkan kategori kebijakan dasar "Audit akses ke objek". Akibatnya, selain melakukan operasi file, banyak acara "noise" lainnya dituangkan ke dalam log keamanan. Ini sangat mempersulit pemrosesan log dan pengguna yang bingung.

Microsoft mendengar "rasa sakit" ini dan memutuskan untuk membantu. Masalahnya adalah bahwa Windows dibangun pada konsep kompatibilitas ke belakang, dan membuat perubahan pada mekanisme manajemen audit yang ada akan mematikan kompatibilitas ini. Oleh karena itu, vendor pergi dengan cara lain. Dia menciptakan alat baru dan menyebutnya Kebijakan Audit Lanjutan.

Inti dari alat ini adalah bahwa dari kategori kebijakan audit dasar, dibuat kebijakan tingkat lanjut, dan pada gilirannya dibagi menjadi beberapa subkategori yang dapat dihidupkan dan dimatikan secara terpisah. Sekarang, jika Anda perlu melacak akses ke file dalam kebijakan audit lanjutan, Anda hanya perlu mengaktifkan subkategori "Sistem File", yang termasuk dalam kategori "Akses Objek". Pada saat yang sama, kejadian "noise" yang terkait dengan akses ke registri atau penyaringan lalu lintas jaringan tidak akan dimasukkan dalam log keamanan.

Kebingungan yang sangat besar dalam keseluruhan skema ini disebabkan oleh fakta bahwa nama-nama kategori kebijakan audit dasar dan lanjutan tidak sesuai, dan pada awalnya mungkin terlihat bahwa ini adalah hal-hal yang sama sekali berbeda, tetapi tidak demikian halnya.

Berikut ini adalah tabel kesesuaian nama-nama kategori dasar dan lanjutan dari manajemen audit

Penting untuk dipahami bahwa kategori dasar dan lanjutan pada dasarnya mengendalikan hal yang sama. Dimasukkannya kategori kebijakan audit dasar mengarah ke dimasukkannya kategori kebijakan audit diperpanjang yang sesuai dan, sebagai hasilnya, semua subkategori. Untuk menghindari konsekuensi yang tidak terduga, Microsoft tidak merekomendasikan penggunaan kebijakan audit dasar dan lanjutan secara bersamaan.

Sekarang adalah waktu untuk mencari tahu di mana pengaturan audit disimpan. Untuk mulai dengan, kami memperkenalkan sejumlah konsep:

1. Kebijakan audit yang efektif - informasi yang disimpan dalam RAM yang menentukan parameter operasi saat ini dari modul sistem operasi yang menerapkan fungsi audit.
2. Kebijakan audit tersimpan - informasi yang disimpan dalam registri di HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv dan digunakan untuk menentukan kebijakan audit yang efektif setelah sistem dinyalakan ulang.

Kami akan mempertimbangkan berbagai alat administratif dan menunjukkan parameter audit mana yang ditampilkan dan yang ditetapkan. Data dalam tabel didasarkan pada eksperimen.

Mari kita jelaskan tabelnya dengan contoh.

Contoh 1

Jika Anda menjalankan auditpol untuk melihat pengaturan audit:
auditpol /get /category:* , maka pengaturan audit yang disimpan akan ditampilkan, yaitu yang disimpan dalam registri di HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv.

Contoh 2

Jika Anda menjalankan utilitas yang sama, tetapi sudah mengatur parameter:
auditpol /set /category:* , pengaturan audit yang efektif dan pengaturan audit yang disimpan akan diubah.

Komentar terpisah membutuhkan urutan pengaturan audit yang ditampilkan di snap-in "Kebijakan Keamanan Lokal" snap-in. Kategori kebijakan audit dasar ditampilkan sebagaimana diatur jika semua subkategori dari kebijakan audit diperluas yang terkait diinstal. Jika setidaknya salah satu dari mereka tidak diinstal, maka kebijakan akan ditampilkan sebagai tidak diinstal.

Contoh 3

Menggunakan perintah auditpol /set /category:* , auditpol /set /category:* mengatur semua subkategori audit ke Mode Keberhasilan Audit. Pada saat yang sama, jika Anda masuk ke "Kebijakan audit dasar" snap-in "Kebijakan keamanan lokal", maka Audit Keberhasilan akan dipasang di seberang setiap kategori.

Contoh 4

Sekarang administrator telah auditpol /clear dan mengatur ulang semua pengaturan audit. Dia kemudian mengatur audit sistem file dengan menjalankan auditpol /set /subcategory:" " . Sekarang, jika Anda masuk ke "Kebijakan audit dasar" dari snap-in "Kebijakan keamanan lokal", maka semua kategori akan ditentukan dalam status "Tidak audit", karena tidak satu pun kategori kebijakan audit tambahan yang sepenuhnya ditentukan.

Sekarang, akhirnya, kita dapat menjawab pertanyaan dari mana log berasal dari sistem operasi yang baru diinstal. Masalahnya adalah bahwa setelah instalasi, audit di Windows dikonfigurasi dan ditentukan dalam pengaturan audit yang disimpan. Anda dapat memverifikasi ini dengan menjalankan perintah auditpol /get /category:* .



Dalam Kebijakan Audit Dasar snap-in Kebijakan Keamanan Lokal, informasi audit ini tidak ditampilkan, karena semua kategori tidak memiliki satu atau beberapa subkategori yang ditentukan. Dalam Kebijakan Audit Lanjut dari snap-in Kebijakan Keamanan Lokal, informasi ini tidak ditampilkan karena snap-in hanya berfungsi dengan pengaturan audit yang disimpan dalam file% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv.

Apa inti dari masalahnya?

Pada awalnya mungkin tampak bahwa semua ini bukan masalah sama sekali, tetapi sebenarnya tidak. Fakta bahwa semua alat menunjukkan parameter audit dengan cara yang berbeda menciptakan peluang untuk manipulasi kebijakan yang berbahaya dan, sebagai hasilnya, hasil audit.

Pertimbangkan skenario yang mungkin terjadi

Biarkan workstation teknologi berbasis Windows 7 bekerja di jaringan perusahaan.

Mesin tidak termasuk dalam domain dan melakukan fungsi robot yang mengirim laporan setiap hari ke pihak berwenang. Penyerang dalam satu atau lain cara mendapatkan akses jarak jauh dengan hak administrator. Pada saat yang sama, tujuan utama penyerang adalah spionase, dan tugasnya adalah tetap tidak terdeteksi dalam sistem. Penyerang diam-diam memutuskan sehingga tidak ada peristiwa dengan kode 4719 "Perubahan kebijakan audit" dalam log keamanan, nonaktifkan audit akses ke file, tetapi pada saat yang sama semua alat administrasi mengatakan bahwa audit diaktifkan. Untuk mencapai tugas, mereka melakukan tindakan berikut:

1. Pada workstation yang diserang, mereka memberi diri mereka menulis izin ke kunci registri HKEY_LOCAL_MACHINE \ SECURITY \ Policy \ PolAdtEv dan mengekspor kunci ini ke file bernama "+ fs.reg".
2. File ini diimpor di komputer lain, reboot, dan kemudian auditpol mematikan audit sistem file, setelah itu kunci registri di atas diekspor ke file "-fs.reg".
3. Pada mesin yang diserang, file "-fs.reg" diimpor ke dalam registri.
4. Kami membuat salinan cadangan dari% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv file yang terletak di mesin yang diserang dan kemudian menghapus subkategori Sistem File dari itu.
5. Kami mem-boot ulang workstation yang diserang, dan kemudian mengganti file% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv dengan salinan cadangan yang sebelumnya tersimpan di dalamnya dan juga mengimpor file "+ fs.reg"

Sebagai hasil dari semua manipulasi ini, tidak ada entri perubahan kebijakan dalam log keamanan, semua alat menunjukkan bahwa audit diaktifkan, tetapi pada kenyataannya itu tidak berfungsi.

Masalah No. 2. Operasi logging yang gagal untuk menghapus file, direktori dan kunci registri

Masalahnya dikonfirmasi pada Windows 7/10 / Server 2019.

Deskripsi masalah

Untuk satu operasi untuk menghapus file, direktori atau kunci registri, sistem operasi menghasilkan urutan peristiwa dengan kode 4663 dan 4660 . Masalahnya adalah bahwa dari seluruh aliran acara, pasangan ini tidak begitu mudah terhubung satu sama lain. Untuk melakukan ini, peristiwa yang dianalisis harus memiliki parameter berikut:

Peristiwa 1. Kode 4663 "Suatu upaya dilakukan untuk mendapatkan akses ke objek." Parameter acara:
"ObjectType" = File.
"ObjectName" = nama file atau direktori yang akan dihapus.
"HandleId" = handle ke file yang akan dihapus.
“AcessMask” = 0x10000 (Kode ini sesuai dengan operasi DELETE. Anda dapat menemukan dekripsi semua kode operasi di situs web Microsoft ).



Acara 2. Kode 4660 "Objek dihapus."
Parameter acara:

"HandleId" = "HandleId acara 1"
"System \ EventRecordID" = "System \ EventRecordID dari event 1" + 1.



Dengan penghapusan kunci registri (kunci), semuanya sama, hanya pada acara pertama dengan kode 4663, parameter "ObjectType" = Kunci.

Perhatikan bahwa penghapusan nilai dalam registri dijelaskan oleh peristiwa lain (kode 4657 ) dan tidak menyebabkan masalah seperti itu.

Fitur menghapus file di Windows 10 dan Server 2019

Di Windows 10 / Server 2019, ada dua cara untuk menghapus file.

1. Jika file dihapus ke tempat sampah, maka, seperti sebelumnya, urutan kejadian 4663 dan 4660.
2. Jika file dihapus secara permanen (melewati tempat sampah), maka dengan satu peristiwa dengan kode 4659 .

Suatu hal yang aneh terjadi. Jika sebelumnya, untuk menentukan file yang dihapus, perlu untuk memantau totalitas peristiwa 4663 dan 4660, sekarang Microsoft telah "pergi untuk bertemu pengguna", dan alih-alih dua peristiwa, sekarang kita perlu memantau tiga. Perlu juga dicatat bahwa prosedur untuk menghapus direktori tidak berubah, itu, seperti sebelumnya, terdiri dari dua peristiwa 4663 dan 4660.

Apa inti dari masalahnya?

Masalahnya adalah bahwa mencari tahu siapa yang menghapus file atau direktori menjadi tugas yang tidak sepele. Alih-alih mencari secara dangkal peristiwa terkait dalam log keamanan, perlu untuk menganalisis urutan peristiwa, yang agak melelahkan untuk dilakukan secara manual. Pada habr bahkan tentang ini ada sebuah artikel: "Mengaudit penghapusan dan akses ke file dan merekam peristiwa dalam file log menggunakan Powershell . "

Masalah nomor 3 (kritis). Pencatatan operasi penggantian nama untuk file, direktori, dan kunci registri yang gagal

Masalahnya dikonfirmasi pada Windows 7/10 / Server 2019.

Deskripsi masalah

Masalah ini memiliki dua sub-masalah:

1. Dalam peristiwa yang dihasilkan oleh sistem selama penggantian nama, nama objek baru tidak diperbaiki di mana pun.
2. Prosedur penggantian nama sangat mirip dengan penghapusan. Itu hanya dapat dibedakan dengan fakta bahwa peristiwa pertama dengan kode 4663, dengan parameter "AcessMask" = 0x10000 (HAPUS) tidak memiliki peristiwa 4660.

Perlu dicatat bahwa berkenaan dengan registri, masalah ini hanya berlaku untuk kunci. Mengganti nama nilai dalam registri dijelaskan oleh urutan peristiwa 4657 dan tidak menyebabkan keluhan seperti itu, meskipun, tentu saja, akan jauh lebih nyaman jika hanya ada satu peristiwa.

Apa inti dari masalahnya?

Selain kesulitan mencari operasi penggantian nama file, fitur penjurnalan ini tidak memungkinkan pelacakan siklus hidup lengkap objek sistem file atau kunci registri. Akibatnya, menjadi sangat sulit untuk menentukan riwayat file yang telah berganti nama berkali-kali pada server file yang digunakan secara aktif.

Masalah nomor 4 (kritis). Tidak dapat melacak pembuatan direktori dan kunci registri

Masalahnya dikonfirmasi pada Windows 7/10 / Server 2019.

Deskripsi masalah

Windows tidak melacak pembuatan direktori sistem file dan kunci registri. Ini terdiri dari kenyataan bahwa sistem operasi tidak menghasilkan suatu peristiwa yang akan mengandung nama direktori atau kunci registri yang dibuat, dan yang parameternya akan menunjukkan bahwa ini adalah operasi pembuatan.

Secara teoritis, dengan tanda-tanda tidak langsung, fakta membuat katalog adalah mungkin. Misalnya, jika dibuat melalui "Explorer", maka selama proses pembuatan, peristiwa polling untuk atribut direktori baru akan dihasilkan. Masalahnya adalah bahwa jika Anda membuat direktori melalui perintah mkdir , maka tidak ada peristiwa yang dihasilkan sama sekali. Semua yang sama berlaku untuk membuat kunci di registri.

Apa inti dari masalahnya?

Masalah ini membuatnya sangat sulit untuk menyelidiki insiden keamanan informasi. Tidak ada penjelasan yang masuk akal untuk fakta bahwa informasi ini tidak dicatat dalam jurnal.

Masalah nomor 5 (kritis). Pengaturan audit buruk dalam versi Rusia Windows

Kehadiran masalah dikonfirmasi pada edisi Rusia Windows 7/10 / Server 2019.

Deskripsi masalah

Ada kesalahan dalam versi Rusia Windows yang membuat sistem manajemen audit keamanan tidak beroperasi.

Gejala

Mengubah kebijakan keamanan tingkat lanjut tidak memengaruhi pengaturan audit yang efektif, atau, dengan kata lain, kebijakan tersebut tidak diterapkan. Sebagai contoh, administrator mengaktifkan subkategori "Login", mem-boot ulang sistem, menjalankan perintah auditpol /get /category:* , dan subkategori ini tetap auditpol /get /category:* . Masalahnya relevan untuk kedua komputer domain yang dikelola melalui kebijakan grup dan komputer non-domain yang dikelola menggunakan GPO lokal yang dikonfigurasi melalui snap-in Kebijakan Keamanan Lokal.

Alasan

Masalah muncul jika administrator telah mengaktifkan setidaknya satu subkategori “gagal” dari kebijakan audit lanjutan. Kategori yang gagal tersebut, khususnya, meliputi:

1. Penggunaan hak -> Audit penggunaan hak yang memengaruhi data rahasia. PANDUAN: {0cce9228-69ae-11d9-bed3-505054503030}.
2. Penggunaan hak -> Audit penggunaan hak yang tidak memengaruhi data rahasia. GUID: {0cce9229-69ae-11d9-bed3-505054503030}.
3. Akses ke objek -> Acara audit yang dibuat oleh aplikasi. PANDUAN: {0cce9222-69ae-11d9-bed3-505054503030}.

Rekomendasi untuk menyelesaikan masalah

Jika masalah belum terjadi, maka jangan aktifkan sub-kategori "gagal" yang ditunjukkan. Jika peristiwa dari subkategori ini sangat diperlukan, maka gunakan utilitas auditpol untuk mengaktifkannya atau mengelola audit menggunakan kebijakan dasar.

Jika masalah terjadi, Anda harus:

1. Dari direktori kebijakan grup domain, hapus file \ Machine \ microsoft \ windows nt \ Audit \ audit.csv
2. Dari semua komputer yang memiliki masalah dengan audit, hapus file:% SystemRoot% \ security \ audit \ audit.csv,% SystemRoot% \ System32 \ GroupPolicy \ Machine \ Microsoft \ Windows NT \ Audit \ audit.csv

Apa inti dari masalahnya?

Kehadiran masalah ini mengurangi jumlah peristiwa keamanan yang dapat dipantau secara teratur melalui kebijakan audit lanjutan, dan juga menciptakan ancaman untuk memutus, memblokir, dan mengacaukan pengelolaan sistem audit dalam jaringan perusahaan.

Masalah nomor 6 (kritis). Sialan "New text document.txt ... serta bitmap.bmp"

Masalahnya telah dikonfirmasi pada Windows 7. Masalahnya hilang pada Windows 10 / Server 2019.

Deskripsi masalah

Ini adalah masalah yang sangat aneh yang ditemukan secara tidak sengaja. Inti dari masalahnya adalah bahwa sistem operasi memiliki celah yang memungkinkan Anda untuk melewati audit pembuatan file.

Bagian persiapan:

1. Ambil Windows 7 yang baru saja diinstal.
2. Atur ulang semua pengaturan audit menggunakan perintah auditpol /clear . Item ini opsional dan hanya berfungsi untuk kenyamanan menganalisis majalah.
3. Kami mengatur audit sistem file dengan menjalankan auditpol /set /subcategory:" " .
4. Mari kita membuat direktori C: \ TEST dan menetapkan parameter audit untuk akun "Semuanya": "Buat File / Tulis Data", "Buat Folder / Tulis Data", "Tulis Atribut", "Tulis Atribut Tambahan", "Hapus Subfolder dan file ”,“ Hapus ”,“ Ubah izin ”,“ Ubah kepemilikan ”, yaitu segala sesuatu yang terkait dengan penulisan data ke sistem file.

Untuk kejelasan, sebelum setiap percobaan, kami akan menghapus log keamanan sistem operasi.

Eksperimen 1.
Kami lakukan:

Dari baris perintah, jalankan perintah: echo > "c:\test\ .txt"
Kami mengamati:

Setelah membuat file, peristiwa dengan kode 4663 muncul di log keamanan, yang berisi nama file yang dibuat di bidang "ObjectName" dan 0x2 di bidang "AccessMask" ("Menulis data atau menambahkan file").



Untuk melakukan percobaan berikut, kami menghapus folder dan log peristiwa.

Eksperimen 2.
Kami lakukan:

Buka folder C: \ TEST melalui "Explorer" dan gunakan menu konteks "Create -> Text Document", dipanggil dengan mengklik kanan, buat file "New Text Document.txt".



Kami mengamati:

Tindakan ini tidak tercermin dalam log peristiwa !!! Juga, tidak akan ada entri jika menggunakan menu konteks yang sama untuk membuat "Bitmap".



Eksperimen 3.
Kami lakukan:

Menggunakan Explorer, buka folder C: \ TEST dan gunakan menu konteks "Buat -> Dokumen dalam format RTF", dipanggil dengan mengklik kanan, buat file "Dokumen baru dalam format RTF.rtf".

Kami mengamati:

Seperti halnya dengan pembuatan file melalui baris perintah, peristiwa dengan kode 4663 dan konten yang sesuai muncul di log.

Apa inti dari masalahnya?

Tentu saja, membuat dokumen teks atau gambar tidak terlalu berbahaya. Namun, jika "Explorer" dapat mem-bypass pencatatan operasi file, maka malware akan dapat melakukan ini.

Masalah ini mungkin yang paling signifikan dari semua yang dipertimbangkan, karena ini secara serius merusak kredibilitas hasil audit operasi file.

Kesimpulan

Daftar masalah di atas tidak lengkap. Dalam prosesnya, saya berhasil menemukan sejumlah kecil kelemahan kecil yang masih agak besar, yang meliputi penggunaan konstanta yang dilokalisasi sebagai nilai parameter untuk sejumlah peristiwa, yang memaksa kami untuk menulis skrip analisis kami untuk setiap lokalisasi sistem operasi, pembagian kode acara yang tidak masuk akal ke dalam operasi yang dekat dengan makna, misalnya, menghapus kunci registri adalah urutan peristiwa 4663 dan 4660, dan menghapus nilai dalam registri adalah 4.657, dan juga hal-hal kecil ...

Dalam keadilan, kami mencatat bahwa terlepas dari semua kekurangannya, sistem pencatatan peristiwa keamanan di Windows memiliki sejumlah besar aspek positif. Memperbaiki masalah-masalah penting yang tercantum di sini dapat mengembalikan mahkota ke solusi yang lebih baik untuk keluar dari acara keamanan.

MEMBUAT WINDOWS KEAMANAN PERISTIWA BESAR LAGI!