Ortak Dizinde "Kim Sildi?" – Windows Denetimi ve Wazuh ile Merkezi İzleme
Bu rehber, bir Windows dosya paylaşımında (ör. \\DC1\ORTAK) yapılan silme işlemlerinin kim tarafından, ne zaman ve hangi dosya/klasör için yapıldığını nasıl tespit edeceğinizi ve bu olayları Wazuh ile nasıl merkezi olarak toplayıp aratacağınızı adım adım anlatır.
Tüm adımlar lab ortamında denenmiştir:
| Bileşen | Lab değeri |
|---|---|
| Dosya sunucusu | DC1 (Windows Server, mcse.local), paylaşım yolu E:\ORTAK |
| İstemci | Windows 10/11, test kullanıcısı MCSE\PERSONEL1 |
| Wazuh sunucusu | Ubuntu (all-in-one), Wazuh 4.14 |
Not: Komutlardaki IP adresleri ve hesap adları örnektir; kendi ortamınıza göre değiştirin.
1. Mantık: üç parça birlikte çalışır
Windows’ta dosya silme olayının Security loguna yazılması için üç şey gerekir. Biri eksikse olay oluşmaz:
| Parça | Ne yapar | Kapsam |
|---|---|---|
auditpol (File System, Success) | Sunucuda dosya denetim motorunu açar. Tek başına olay üretmez. | Sunucu geneli |
| SACL (klasör denetim kuralı) | Hangi klasörde, hangi hak kullanılınca olay yazılacağını belirler. | Sadece ilgili klasör |
| Security log boyutu | Olayların ne kadar geriye saklanacağını belirler (dolunca eskiler ezilir). | Sunucu geneli |
SACL tanımlı olmayan klasörlerde auditpol açık olsa bile olay üretilmez. Bu yüzden log artışı sadece izlediğiniz klasörle sınırlı kalır.
2. Windows tarafı kurulum
2.1 Denetimi aç ve log boyutunu artır
Yönetici PowerShell:
auditpol /set /subcategory:"File System" /success:enable /failure:disable
auditpol /get /subcategory:"File System"
wevtutil sl Security /ms:2147483648
wevtutil gl Security
/mslog dosyasının azami boyutudur (bayt).2147483648= 2 GB. Lab için 512 MB (536870912) da yeter.wevtutil gl SecurityçıktısındamaxSize: 2147483648veretention: falsegörünmelidir (log dolunca eski olaylar ezilir)./failure:disableile yalnızca başarılı işlemler loglanır, log şişmez.
2.2 Ortak dizine SACL ekle (sadece silme hakları)
$path = "E:\ORTAK"
$acl = Get-Acl $path -Audit
$rights = [System.Security.AccessControl.FileSystemRights]"Delete,DeleteSubdirectoriesAndFiles"
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule(
"Everyone", $rights, "ContainerInherit,ObjectInherit", "None", "Success")
$acl.AddAuditRule($rule)
Set-Acl $path $acl
(Get-Acl $path -Audit).Audit
Son satır kuralı göstermelidir: Everyone, Delete, DeleteSubdirectoriesAndFiles, Success, ContainerInherit, ObjectInherit.
Aynısı GUI’den: klasör → sağ tık → Properties → Security → Advanced → Auditing → Add → Principal: Everyone → Type: Success → Applies to: This folder, subfolders and files → Show advanced permissions → önce Clear all, sonra yalnızca Delete ve Delete subfolders and files → OK → Apply.

Şekil 1 – E:\ORTAK üzerindeki denetim kuralı: yalnızca Delete hakları izleniyor.
Dikkat (Domain Controller üzerinde): DC’lerde Default Domain Controllers Policy audit ayarını ezebilir.
auditpolçıktısındaSuccessgörünmezse ayarı GPO’da tanımlayıpgpupdate /forceçalıştırın. Gerçek ortamda dosya sunucusunu DC’ye değil, ayrı bir member server’a kurun.
2.3 Test ortamı
Test için paylaşımda kullanıcıya yazma/silme (Modify) yetkisi verilmiştir. İstemciden \\dc1\ortak paylaşımına bağlanıp dosya ve klasör oluşturup silerek test yapılır.

Şekil 2 – Test paylaşımının NTFS izinleri (test kullanıcısına Modify).

Şekil 3 – İstemci tarafında paylaşım ve test klasörü.
3. Hangi silme hangi olayı üretir?
Lab’da gözlenen davranış (paylaşım üzerinden silme):
| Durum | Olay | Access Mask | Not |
|---|---|---|---|
| Paylaşımdan dosya silme | 4659 – “handle requested with intent to delete” | 0x10080 | Kullanıcı ve dosya adı aynı olayda. HandleId 0x0, ProcessId 0x4 (SMB/System). 4660 gelmez. |
| Paylaşımdan klasör silme | 4663 + 4660 | 0x10000 | İkisi aynı Handle ID’yi taşır. Ad 4663’te, “silindi” onayı 4660’ta. |
| Rename / taşıma | 4663 | 0x10000 | Aynı Handle’da 4660 yoksa silme değil, rename/taşıma olabilir. |
| Yerel süreç (Defender vb.) | 4663 + 4660 | – | Kullanıcı DC1$ gibi makine hesabıdır, sorgularda elenir. |
Bilmeniz gerekenler:
0x10080nedir?0x10000(DELETE) +0x80(ReadAttributes). Explorer/SMB istemcisi dosyayı silerken bu haklarla açar (delete-on-close). Dosya silmenin tipik imzasıdır.- 4660’ta ne var? Sadece “An object was deleted”, Subject ve Handle ID. Nesne adı ve Access Mask yoktur. Silinen nesnenin adı için aynı Handle ID’li 4663’e bakılır.
- 4659 bir istek kaydıdır. Silme sonucunu doğrulayan ayrı bir olay yoktur. Kesin doğrulama için dosyanın artık klasörde olmadığına bakın (
Test-Path) ya da yedekle karşılaştırın. - Farklı uygulamalar farklı maskeyle silebilir. Beklediğiniz silme listede yoksa maske filtresini kaldırıp ham 4659/4663 olaylarına bakın.
4. Windows’ta sorgu: ortak dizinde silinenler
Event Viewer yerine PowerShell ile, sadece ilgili olayları XPath ile süzen hızlı sorgu:
$saat = 24
$ms = $saat * 3600000
$xp = "*[System[(EventID=4659 or EventID=4663) and " +
"TimeCreated[timediff(@SystemTime) <= $ms]]] and " +
"*[EventData[Data[@Name='AccessMask']='0x10080' or " +
"Data[@Name='AccessMask']='0x10000']]"
Get-WinEvent -LogName Security -FilterXPath $xp |
ForEach-Object {
$x=[xml]$_.ToXml(); $d=@{}
$x.Event.EventData.Data | % { $d[$_.Name]=$_.'#text' }
[pscustomobject]@{
Zaman=$_.TimeCreated
Tur=$(if($_.Id -eq 4659){'Dosya'}else{'Klasör/Diğer'})
Kullanici="$($d.SubjectDomainName)\$($d.SubjectUserName)"
Dosya=$d.ObjectName } } |
Where-Object { $_.Dosya -like 'E:\ORTAK*' -and $_.Kullanici -notlike '*$' -and
$_.Dosya -notmatch '~\$|\.tmp$' } |
Sort-Object Zaman -Descending | ft -AutoSize
- Geçmişe daha uzun bakmak için
$saatdeğerini artırın (168 = 7 gün). - CSV için son satırdaki
ft -AutoSizeyerineExport-Csv C:\silinenler.csv -NoTypeInformation -Encoding UTF8yazın. - Neden hızlı? Olay ID ve AccessMask filtresi XPath ile Event Log servisinde yapılır. Tüm Security logunu çekip
Where-Objectile süzmek DC’de çok yavaştır.
5. Neden Wazuh?
Event Viewer ve PowerShell tek sunucuda işe yarar; ama sunucu sayısı arttıkça, geçmişe dönük arama, alarm ve uzun süreli saklama gerekir. Wazuh:
- Agent ile Windows Security loglarını toplar,
- Olayı alanlara ayrıştırır (
subjectUserName,objectName,accessMask), - Kurallarla eşleştirip alarm üretir,
- Dashboard’da aranabilir hale getirir.
Önemli: Wazuh denetimi kendisi üretmez. Silme olaylarını Windows yazar; Wazuh onları toplar ve aranabilir kılar. Bu yüzden 2. bölümdeki auditpol ve SACL adımları Wazuh kurulsa da gereklidir.
6. Wazuh sunucusu kurulumu (Ubuntu, all-in-one)
Donanım (lab): 4 vCPU, 8 GB RAM, 50 GB disk. 4 GB RAM kurulumu zorlar, önerilmez. Ubuntu 22.04 / 24.04 önerilir; resmi desteklenen işletim sistemi listesini kontrol edin.
Sunucuya sabit IP verin (agent’lar bu adrese bağlanacak), sonra:
sudo apt update && sudo apt -y upgrade
sudo apt install curl gnupg apt-transport-https unzip -y
curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
chmod +x wazuh-install.sh
sudo bash wazuh-install.sh -a
Sürüm numarası (
4.14) zamanla değişir; güncel komutu Wazuh dokümanındaki Quickstart sayfasından alın.-a, tüm bileşenleri (indexer, server, dashboard) tek makineye kurar. Kurulum sonundaadminparolası ekrana yazılır.
Parolayı sonradan görmek için:
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt
6.1 Servisleri ve portları doğrula
systemctl is-active wazuh-manager
systemctl is-active wazuh-indexer
systemctl is-active wazuh-dashboard
systemctl is-active filebeat
ip -br addr
ss -lntp | grep -E ':(443|1514|1515|55000|9200)'
Dört servis de active döndürmeli. Portların anlamı:
| Port | Görev |
|---|---|
| 443 | Dashboard (tarayıcı) |
| 1514 | Agent → manager log akışı |
| 1515 | Agent kayıt (enrollment) |
| 55000 | Wazuh API |
| 9200 | Indexer |
Dashboard’a https://<WAZUH_IP> adresinden admin kullanıcısıyla girin (self-signed sertifika uyarısı normaldir).
7. Windows agent kurulumu
Dosya sunucusuna (burada DC1) agent kurulur. Agent, Security logunu okuyup Wazuh’a gönderir; Wazuh Windows loglarını uzaktan kendisi çekmez.
- Dashboard → Deploy new agent → Windows → Wazuh sunucu IP’sini yazın → çıkan PowerShell komutunu sunucuda çalıştırın.
- Servisi başlatın:
NET START WazuhSvc.
Komut satırından da kurulabilir:
msiexec /i wazuh-agent.msi /q WAZUH_MANAGER="<WAZUH_IP>" WAZUH_AGENT_NAME="DC1"
Bilmeniz gerekenler:
- Agent Local System hesabıyla çalışır; Security logunu okumak için ayrı bir servis hesabı gerekmez.
- Kurulum sırasında yalnızca sunucu IP’si istenir, anahtar sormaz. Agent, açılışta manager’ın 1515 portundaki kayıt servisine bağlanıp kendini kaydeder ve anahtarı otomatik alır (
client.keys). - Varsayılan kayıt parolasızdır: 1515 portuna ulaşabilen herkes kendini agent olarak kaydedebilir. Üretimde parola ile kayıt kullanın (bkz. bölüm 10).
Bağlantıyı kontrol etmek için manager’da:
sudo /var/ossec/bin/agent_control -l
sudo /var/ossec/bin/agent_control -i 002
Agent tarafında C:\Program Files (x86)\ossec-agent\ossec.log içinde Connected to the server satırını görmelisiniz.
8. Agent ayarı: 4663 olayını açın
Wazuh Windows agent’ı varsayılan olarak bazı gürültülü olay ID’lerini göndermez. Bu listede 4663 ve 4660 de vardır. Klasör silmelerini görmek için 4663 dışlamasını kaldırmalısınız.
Dosya: C:\Program Files (x86)\ossec-agent\ossec.conf (Notepad’i yönetici olarak açın, önce yedek alın).
Varsayılan Security bloğu:
<localfile>
<location>Security</location>
<log_format>eventchannel</log_format>
<query>Event/System[EventID != 5145 and EventID != 5156 and EventID != 5447 and
EventID != 4656 and EventID != 4658 and EventID != 4663 and EventID != 4660 and
EventID != 4670 and EventID != 4690 and EventID != 4703 and EventID != 4907 and
EventID != 5152 and EventID != 5157]</query>
</localfile>
EventID != 4663 and kısmını silin (4660’ı bırakabilirsiniz, nesne adı zaten 4663’te):
<localfile>
<location>Security</location>
<log_format>eventchannel</log_format>
<query>Event/System[EventID != 5145 and EventID != 5156 and EventID != 5447 and
EventID != 4656 and EventID != 4658 and EventID != 4660 and
EventID != 4670 and EventID != 4690 and EventID != 4703 and EventID != 4907 and
EventID != 5152 and EventID != 5157]</query>
</localfile>
Sonra servisi yeniden başlatın:
Restart-Service WazuhSvc
- Son ID’den sonra
andkalmamalı, sorgu]ile kapanmalı. Sorgu bozulursa agent Security logunu hiç göndermez. - 4659 bu listede yok; yani dosya silme olayları zaten gönderilir.
- Çok sayıda agent varsa bu değişikliği manager’dan grup bazında dağıtabilirsiniz (
/var/ossec/etc/shared/default/agent.conf).
9. Wazuh kuralı: silme olaylarını alarma çevir
Wazuh, kurala eşleşmeyen olayı alarm olarak saklamaz. Bu yüzden 4659/4663 için kendi kuralınızı yazmanız gerekir.
Manager’da /var/ossec/etc/rules/local_rules.xml dosyasına ekleyin:
</group>
<group name="windows,file_delete,">
<rule id="100100" level="8">
<if_sid>60103</if_sid>
<field name="win.system.eventID" type="pcre2">^(4663|4659)$</field>
<field name="win.eventdata.accessMask" type="pcre2">^(0x10000|0x10080)$</field>
<field name="win.eventdata.objectName" type="pcre2">(?i)ORTAK</field>
<description>ORTAK klasorunde silme erisimi: $(win.eventdata.subjectUserName) - $(win.eventdata.objectName)</description>
</rule>
<rule id="100101" level="8">
<if_sid>60103</if_sid>
<field name="win.system.eventID" type="pcre2">^(4663|4659)$</field>
<field name="win.eventdata.accessMask" type="pcre2">^(0x10000|0x10080)$</field>
<field name="win.eventdata.objectName" type="pcre2">(?i)IT</field>
<description>IT klasorunde silme erisimi: $(win.eventdata.subjectUserName) - $(win.eventdata.objectName)</description>
</rule>
</group>
Satır satır:
| Satır | Anlamı |
|---|---|
id="100100" | Kural numarası. 100000 ve üstü kendi kurallarınız içindir, hazır kurallarla çakışmaz. |
level="8" | Önem derecesi. |
<if_sid>60103</if_sid> | Wazuh’un hazır “Windows audit success” ana kuralına zincirlenir. |
win.system.eventId | Olay ID’si 4663 veya 4659 olsun. |
win.eventdata.objectName | Yolda ORTAK geçsin (büyük/küçük harf duyarsız). |
$(...) | Alarm mesajına kullanıcı adı ve nesne yolunu yazar. |
Kuralı doğrulayın ve yükleyin:
sudo /var/ossec/bin/wazuh-analysisd -t
sudo systemctl restart wazuh-manager
Hata yoksa kural yüklenmiştir.
İsteğe bağlı sıkılaştırma (kendi ortamınızda test edin):
- Yol filtresini başa sabitleyin:
(?i)^E:\\ORTAK. Aksi halde yolunda “ortak” geçen her dosya (ör.C:\Users\x\ortak notlar.docx) alarm üretir. win.eventdata.accessMaskiçin^(0x10000|0x10080)$filtresi ekleyin. Lab’da 4659 olayı bazen0x0maskesiyle (silme olmayan erişim) de geldi.- Alarm açıklamasında “silindi” yerine “silme/rename” demek daha dürüsttür: 4663 (
0x10000) rename/taşımada da oluşur.
10. Sonucu görme
Dashboard → Discover (wazuh-alerts-*) → son 24 saat:
rule.id:"100100"

Şekil 4 – Silme alarmları: nesne yolu, silen kullanıcı (PERSONEL1) ve kural grupları (windows, file_delete) tek ekranda.
Sütun olarak data.win.eventdata.objectName, data.win.eventdata.subjectUserName ve rule.groups ekleyerek bu görünümü elde edersiniz.
11. Sorun giderme
Olay gelmiyorsa zinciri kaynaktan sona doğru kontrol edin:
| Adım | Kontrol |
|---|---|
| Windows olay üretiyor mu? | auditpol /get /subcategory:"File System" → Success. (Get-Acl E:\ORTAK -Audit).Audit boş mu? |
| Paylaşım yolu doğru mu? | Get-SmbShare ortak | select Name, Path |
| Agent bağlı mı? | ossec.log içinde Connected to the server; dashboard’da agent Active mi? |
| Olay manager’a ulaşıyor mu? | Manager’da logall_json açıp archives.json‘a bakın (aşağıda). |
| Kural eşleşiyor mu? | wazuh-logtest ile olayı test edin. |
| Zaman aralığı | Manager UTC çalışıyor olabilir; dashboard’da “Last 15 minutes” deneyin. |
Olayın manager’a ulaştığını doğrulama (geçici):
# /var/ossec/etc/ossec.conf içinde <global> bloğuna ekleyin:
# <logall_json>yes</logall_json>
sudo systemctl restart wazuh-manager
sudo grep -a 'ORTAK' /var/ossec/logs/archives/archives.json | tail -3 | cut -c1-400
- Satır çıkıyorsa olay manager’a ulaşıyor, sorun kural tarafındadır.
- Çıkmıyorsa agent filtresine (bölüm 8) ve agent bağlantısına bakın.
- Test bitince
logall_json‘unoyapın; tüm olayları kaydettiği için diski şişirir.
Kuralı kesin test etmek için:
sudo /var/ossec/bin/wazuh-logtest
archives.json‘daki bir olayın ham halini yapıştırın. Phase 2 alan adlarını, Phase 3 eşleşen kuralı gösterir.
Servis uyarısı: systemctl restart sonrası “unit file changed on disk” uyarısı zararsızdır; sudo systemctl daemon-reload ile giderilir.
12. Gerçek ortama geçerken
- Pilot ile başlayın: Tek paylaşım, az kullanıcı. Bir hafta boyunca günlük olay sayısını ve log doluluğunu izleyin, sonra genişletin.
- Başka SACL var mı?
auditpolsunucu geneli açılır; başka klasörlerde zaten SACL varsa onlar da olay üretmeye başlar. Kontrol:(Get-Acl "D:\BaskaKlasor" -Audit).Audit. - Geri alma planı:
auditpol /set /subcategory:"File System" /success:disableve SACL kuralını kaldırmak. auditpolayarını GPO ile dağıtın, SACL’i hedef klasörlere script ile uygulayın.- Principal:
EveryoneyerineAuthenticated Users/Domain Usersdüşünün. - Agent kaydını parola ile koruyun. Manager’da
/var/ossec/etc/ossec.confiçindeki<auth>bloğuna<use_password>yes</use_password>ekleyin, parolayı/var/ossec/etc/authd.passdosyasına yazın (chmod 640,chown root:wazuh), manager’ı yeniden başlatın; agent kurulumundaWAZUH_REGISTRATION_PASSWORDile verin. Ayrıca 1514/1515 portlarını yalnızca agent ağına açın. - Disk: Boyut, olay hacmine ve saklama süresine bağlıdır. Lab’da 50 GB ile başlayıp günlük index büyümesini ölçün, üretim diskini o rakamla hesaplayın. Disk dolunca indexer yazmayı durdurur; en az %20-30 boş alan bırakın, eski index’leri ISM politikasıyla otomatik silin.
- İnternetsiz ortam: Log toplama, kurallar ve dashboard internet gerektirmez. Yalnızca CVE (açık) taraması için çevrimdışı güncelleme yöntemi gerekir; silme denetimi bundan etkilenmez.
- Uzun süreli saklama: Windows Security logu 2 GB’da döner; geçmiş silmeleri aramak için Wazuh index saklama süresini planlayın.
Özet
| Adım | Ne yapılır |
|---|---|
| 1 | auditpol ile File System denetimi açılır, Security log boyutu artırılır. |
| 2 | Ortak klasöre SACL eklenir (sadece Delete hakları). |
| 3 | Dosya silme 4659 (0x10080), klasör silme 4663 (0x10000) + 4660 olarak loglanır. |
| 4 | Wazuh sunucusu kurulur, dosya sunucusuna agent yüklenir. |
| 5 | Agent’ta 4663 dışlaması kaldırılır. |
| 6 | Manager’da 4659/4663 için özel kural yazılır. |
| 7 | Dashboard’da rule.id ile “kim, neyi, ne zaman sildi” sorgulanır. |