fatih@oktay

Ortak Dizinde "Kim Sildi?" – Windows Denetimi ve Wazuh ile Merkezi İzleme

18.10.2026 #wazuh #windows-server #audit #dosya-sunucusu #siem #active-directory

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şenLab değeri
Dosya sunucusuDC1 (Windows Server, mcse.local), paylaşım yolu E:\ORTAK
İstemciWindows 10/11, test kullanıcısı MCSE\PERSONEL1
Wazuh sunucusuUbuntu (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çaNe yaparKapsam
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 boyutuOlayları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
  • /ms log dosyasının azami boyutudur (bayt). 2147483648 = 2 GB. Lab için 512 MB (536870912) da yeter.
  • wevtutil gl Security çıktısında maxSize: 2147483648 ve retention: false görünmelidir (log dolunca eski olaylar ezilir).
  • /failure:disable ile 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.

Auditing sekmesinde Everyone için Success, Delete ve Delete subfolders and files işaretli

Ş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ında Success görünmezse ayarı GPO’da tanımlayıp gpupdate /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.

\dc1\ortak üzerindeki NTFS izinleri

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

İstemciden \dc1\ortak paylaşımı

Ş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):

DurumOlayAccess MaskNot
Paylaşımdan dosya silme4659 – “handle requested with intent to delete”0x10080Kullanıcı ve dosya adı aynı olayda. HandleId 0x0, ProcessId 0x4 (SMB/System). 4660 gelmez.
Paylaşımdan klasör silme4663 + 46600x10000İkisi aynı Handle ID’yi taşır. Ad 4663’te, “silindi” onayı 4660’ta.
Rename / taşıma46630x10000Aynı 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:

  • 0x10080 nedir? 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 $saat değerini artırın (168 = 7 gün).
  • CSV için son satırdaki ft -AutoSize yerine Export-Csv C:\silinenler.csv -NoTypeInformation -Encoding UTF8 yazın.
  • Neden hızlı? Olay ID ve AccessMask filtresi XPath ile Event Log servisinde yapılır. Tüm Security logunu çekip Where-Object ile 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:

  1. Agent ile Windows Security loglarını toplar,
  2. Olayı alanlara ayrıştırır (subjectUserName, objectName, accessMask),
  3. Kurallarla eşleştirip alarm üretir,
  4. 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 sonunda admin parolası 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ı:

PortGörev
443Dashboard (tarayıcı)
1514Agent → manager log akışı
1515Agent kayıt (enrollment)
55000Wazuh API
9200Indexer

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.

  1. Dashboard → Deploy new agent → Windows → Wazuh sunucu IP’sini yazın → çıkan PowerShell komutunu sunucuda çalıştırın.
  2. 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 and kalmamalı, 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ırAnlamı
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.eventIdOlay ID’si 4663 veya 4659 olsun.
win.eventdata.objectNameYolda 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.accessMask için ^(0x10000|0x10080)$ filtresi ekleyin. Lab’da 4659 olayı bazen 0x0 maskesiyle (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"

Wazuh Discover: rule.id 100100 sonuçları

Ş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ımKontrol
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‘u no yapı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ı? auditpol sunucu 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:disable ve SACL kuralını kaldırmak.
  • auditpol ayarını GPO ile dağıtın, SACL’i hedef klasörlere script ile uygulayın.
  • Principal: Everyone yerine Authenticated Users / Domain Users düşünün.
  • Agent kaydını parola ile koruyun. Manager’da /var/ossec/etc/ossec.conf içindeki <auth> bloğuna <use_password>yes</use_password> ekleyin, parolayı /var/ossec/etc/authd.pass dosyasına yazın (chmod 640, chown root:wazuh), manager’ı yeniden başlatın; agent kurulumunda WAZUH_REGISTRATION_PASSWORD ile 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ımNe yapılır
1auditpol ile File System denetimi açılır, Security log boyutu artırılır.
2Ortak klasöre SACL eklenir (sadece Delete hakları).
3Dosya silme 4659 (0x10080), klasör silme 4663 (0x10000) + 4660 olarak loglanır.
4Wazuh sunucusu kurulur, dosya sunucusuna agent yüklenir.
5Agent’ta 4663 dışlaması kaldırılır.
6Manager’da 4659/4663 için özel kural yazılır.
7Dashboard’da rule.id ile “kim, neyi, ne zaman sildi” sorgulanır.