Windows Server Audit Policy ile Oturum Denetimi

yazar

Bir gün patronunuz sizi çağırıp “Geçen hafta sunucumuza kim girdi, ne yaptı?” diye sorduğunda, eğer audit policy kurulmamışsa yapabileceğiniz tek şey omuz silkmek olur. Bu durum hem sizin için hem de şirket için ciddi bir güvenlik açığı demektir. Windows Server ortamlarında oturum denetimi, adli analiz süreçlerinin ve güvenlik uyumluluğunun temel taşlarından biridir. Bu yazıda, Windows Server üzerinde Audit Policy yapılandırmasını, oturum açma olaylarını izlemeyi ve bu logları anlamlı hale getirmeyi ele alacağız.

Audit Policy Nedir ve Neden Önemlidir?

Windows Server’ın güvenlik altyapısında Audit Policy, sistemde gerçekleşen olayların güvenlik günlüğüne (Security Event Log) kaydedilmesini sağlayan politikalar bütünüdür. Bu politikalar olmadan, sisteminizde neler döndüğü konusunda kör uçuş yapıyorsunuz demektir.

Oturum denetimi (logon auditing) özelinde konuşacak olursak, şunları takip edebilirsiniz:

  • Sisteme başarıyla giriş yapan kullanıcılar
  • Başarısız oturum açma denemeleri
  • Oturum kapatma işlemleri
  • Uzak masaüstü (RDP) bağlantıları
  • Servis hesaplarının aktiviteleri
  • Ağ üzerinden yapılan kimlik doğrulama işlemleri

Özellikle PCI-DSS, ISO 27001, HIPAA gibi uyumluluk standartlarını karşılamanız gerekiyorsa, oturum denetimi zorunlu bir gereksinim haline gelir. Ama bunun ötesinde, gerçek bir saldırı veya iç tehdit senaryosunda bu loglar sizin tek kanıt kaynağınız olacaktır.

Temel Kavramlar: Basic vs Advanced Audit Policy

Windows Server’da iki farklı audit policy yapılandırma yöntemi bulunur.

Basic Audit Policy, Group Policy Management üzerinden Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy yoluyla erişilen, 9 kategoriden oluşan klasik yapıdır. Basittir ama granüler değildir.

Advanced Audit Policy, Windows Server 2008 R2 ile birlikte gelen ve Basic Policy’ye kıyasla çok daha ayrıntılı yapılandırma imkanı sunan gelişmiş sistemdir. 10 kategori altında toplamda 58 alt kategori içerir. Production ortamlarda mutlaka Advanced Audit Policy kullanmanızı tavsiye ederim.

Önemli bir not: Eğer hem Basic hem Advanced Audit Policy tanımlanmışsa, Advanced Policy her zaman öncelik alır. İkisini aynı anda kullanmak kafa karışıklığına neden olur, bu yüzden birini seçip ona bağlı kalın.

Mevcut Audit Policy Durumunu Kontrol Etmek

Yapılandırmaya başlamadan önce mevcut durumu görmek iyi bir alışkanlıktır. PowerShell veya komut satırından bunu kolayca yapabilirsiniz.

# Mevcut audit policy'yi görüntüle
auditpol /get /category:*

# Sadece Logon/Logoff kategorisini görüntüle
auditpol /get /category:"Logon/Logoff"

# Belirli bir alt kategoriyi kontrol et
auditpol /get /subcategory:"Logon"

Bu komutun çıktısında her kategori için “No Auditing”, “Success”, “Failure” veya “Success and Failure” değerlerinden birini göreceksiniz. Temiz bir sistemde çoğu kategori “No Auditing” olarak gelir, bu da hiçbir şeyin loglanmadığı anlamına gelir.

# Mevcut ayarları dosyaya export et (yedek almak için)
auditpol /backup /file:C:AuditPolicy_Backup.csv

# Daha sonra geri yüklemek için
auditpol /restore /file:C:AuditPolicy_Backup.csv

Bir değişiklik yapmadan önce mutlaka yedek alın. Özellikle domain controller’larda yapacağınız değişiklikler tüm etki alanını etkiler.

Oturum Denetimi için Kritik Alt Kategoriler

Advanced Audit Policy içinde oturum denetimi için odaklanmanız gereken ana kategoriler şunlardır:

Logon/Logoff Kategorisi

  • Logon: Kullanıcı oturum açma olayları (başarılı ve başarısız)
  • Logoff: Oturum kapatma olayları
  • Account Lockout: Hesap kilitlenme olayları
  • Special Logon: Yönetici yetkisiyle yapılan özel oturumlar
  • Other Logon/Logoff Events: Ağ oturumları ve diğer olaylar

Account Logon Kategorisi

  • Credential Validation: Kimlik bilgisi doğrulama işlemleri
  • Kerberos Authentication Service: Kerberos TGT talepleri
  • Kerberos Service Ticket Operations: Kerberos servis bileti işlemleri

Bu iki kategoriyi karıştırmamak gerekir. Account Logon olayları kimlik doğrulamanın gerçekleştiği yerde (genellikle domain controller) loglanırken, Logon/Logoff olayları kaynağa erişimin yapıldığı makinede loglanır.

PowerShell ile Audit Policy Yapılandırması

Şimdi asıl konfigürasyona geçelim. Tek bir sunucu için PowerShell ile yapılandırma yapabilirsiniz:

# Logon olaylarını Success ve Failure için etkinleştir
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

# Logoff olaylarını etkinleştir
auditpol /set /subcategory:"Logoff" /success:enable /failure:disable

# Account Lockout'u etkinleştir
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable

# Special Logon'u etkinleştir
auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable

# Credential Validation'ı etkinleştir
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable

# Kerberos Authentication'ı etkinleştir (DC'lerde önemli)
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable

Birden fazla sunucuya aynı yapılandırmayı uygulamak için PowerShell’in Invoke-Command özelliğini kullanabilirsiniz:

# Birden fazla sunucuya aynı anda uygula
$servers = @("SERVER01", "SERVER02", "SERVER03", "DC01")

Invoke-Command -ComputerName $servers -ScriptBlock {
    auditpol /set /subcategory:"Logon" /success:enable /failure:enable
    auditpol /set /subcategory:"Logoff" /success:enable /failure:disable
    auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable
    auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable
    auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable
    Write-Host "$env:COMPUTERNAME - Audit policy basariyla uygulandı"
}

Group Policy ile Merkezi Yapılandırma

Production ortamlarda tek tek sunucuya bağlanıp komut çalıştırmak sürdürülebilir değildir. Domain ortamında Group Policy Object (GPO) kullanarak merkezi yönetim sağlayabilirsiniz.

Group Policy Management Console’dan yeni bir GPO oluşturun veya mevcut bir Security GPO’nuzu düzenleyin. Yol: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies

GPO’yu oluşturduktan sonra PowerShell ile de kontrol edebilirsiniz:

# GPO'nun uygulanıp uygulanmadığını kontrol et
gpresult /r /scope computer

# Detaylı GPO raporu HTML formatında
gpresult /H C:GPO_Report.html

# Audit policy GPO ayarlarını zorla uygula
gpupdate /force

# Belirli bir OU'ya GPO bağlama (AD modülü gerektirir)
New-GPLink -Name "Server Audit Policy" -Target "OU=Servers,DC=sirket,DC=com" -LinkEnabled Yes

GPO yapılandırmasında dikkat etmeniz gereken bir nokta: Advanced Audit Policy ayarları GPO’da Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration altında bulunurken, eski Basic Policy ayarları Audit Policy altındadır. İkisini karıştırmayın.

Güvenlik Olay Loglarını Okumak

Audit policy’yi yapılandırdınız, loglar akmaya başladı. Şimdi bu logları nasıl okuyacaksınız? Windows Security Event Log’unda her olay türünün kendine özgü bir Event ID‘si vardır.

Oturum denetimi için kritik Event ID’ler:

  • 4624: Başarılı oturum açma
  • 4625: Başarısız oturum açma girişimi
  • 4634: Oturum kapatma
  • 4647: Kullanıcı tarafından başlatılan oturum kapatma
  • 4648: Açık kimlik bilgileriyle oturum açma girişimi (runas)
  • 4672: Yeni oturuma özel ayrıcalıklar atandı (admin logon)
  • 4776: DC’de kimlik doğrulama girişimi
  • 4771: Kerberos ön kimlik doğrulama başarısız
  • 4768: Kerberos TGT isteği
  • 4769: Kerberos servis bileti isteği

PowerShell ile bu logları filtreleyerek okuyabilirsiniz:

# Son 24 saatteki başarısız oturum açma denemelerini listele
$StartTime = (Get-Date).AddHours(-24)

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
    StartTime = $StartTime
} | Select-Object TimeCreated, 
    @{N='KullaniciAdi';E={$_.Properties[5].Value}},
    @{N='KaynakIP';E={$_.Properties[19].Value}},
    @{N='BasarisizlikNedeni';E={$_.Properties[8].Value}} | 
    Format-Table -AutoSize

# Belirli bir kullanıcının tüm oturum açma geçmişi
$hedefKullanici = "ahmet.yilmaz"

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = @(4624, 4625, 4634)
} | Where-Object {
    $_.Properties[5].Value -eq $hedefKullanici -or 
    $_.Properties[6].Value -eq $hedefKullanici
} | Select-Object TimeCreated, Id, 
    @{N='EventTuru';E={
        switch($_.Id) {
            4624 {"Basarili Giris"}
            4625 {"Basarisiz Giris"}
            4634 {"Cikis"}
        }
    }},
    @{N='KullaniciAdi';E={$_.Properties[5].Value}} |
    Sort-Object TimeCreated -Descending |
    Format-Table -AutoSize

Gerçek Dünya Senaryosu: Brute Force Tespiti

Diyelim ki bir sabah iş yerinde güvenlik uyarısı aldınız. Birinin domain controller’ınıza brute force saldırısı yaptığından şüpheleniyorsunuz. Audit policy doğru yapılandırılmışsa, bunu birkaç dakika içinde doğrulayabilirsiniz.

# Son 1 saatte 10'dan fazla basarisiz giris deneyen IP adreslerini bul
$BaslangicZamani = (Get-Date).AddHours(-1)
$EsikDeger = 10

$SaldiriRaporu = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
    StartTime = $BaslangicZamani
} | Group-Object {$_.Properties[19].Value} | 
    Where-Object {$_.Count -ge $EsikDeger} |
    Select-Object @{N='KaynakIP';E={$_.Name}}, 
                  @{N='DenemeSayisi';E={$_.Count}} |
    Sort-Object DenemeSayisi -Descending

if ($SaldiriRaporu) {
    Write-Host "UYARI: Olasi brute force saldirisi tespit edildi!" -ForegroundColor Red
    $SaldiriRaporu | Format-Table -AutoSize
    
    # E-posta bildirimi gondermek icin (SMTP yapılandırması gerektirir)
    $Konu = "GUVENLIK UYARISI: Brute Force Tespit - $(Get-Date -Format 'dd.MM.yyyy HH:mm')"
    $Govde = $SaldiriRaporu | Out-String
    # Send-MailMessage -To "[email protected]" -Subject $Konu -Body $Govde -SmtpServer "mail.sirket.com"
} else {
    Write-Host "Son 1 saatte anormal giris denemesi tespit edilmedi." -ForegroundColor Green
}

Bu scripti bir Scheduled Task olarak her saat çalıştırarak otomatik izleme yapabilirsiniz. Kritik sistemlerde bu tür otomatik uyarı mekanizmaları kurmak, güvenlik ekibinin yükünü ciddi ölçüde azaltır.

Event Log Boyutu ve Retention Politikası

Oturum denetimini etkinleştirdiğinizde log üretimi dramatik biçimde artar. Varsayılan olarak Windows Security Event Log boyutu 20 MB ile sınırlıdır ve dolduğunda eski kayıtların üzerine yazar. Bu, delil kaybı anlamına gelir.

Production ortamlarda log boyutunu mutlaka artırmanız gerekir:

# Security Event Log boyutunu 512 MB'a cıkar
wevtutil sl Security /ms:536870912

# Mevcut log boyutunu ve ayarlarını goruntule
wevtutil gl Security

# Log retention politikasını "archive" moduna al (dolu olunca uzerine yazma)
wevtutil sl Security /rt:true

# PowerShell ile de yapabilirsiniz
$log = Get-WmiObject -Class Win32_NTEventlogFile -Filter "LogFileName='Security'"
$log.MaxFileSize = 536870912
$log.Put()

Uzun vadeli log saklama için Windows Event Log’larını merkezi bir SIEM çözümüne (Splunk, Elastic Stack, Microsoft Sentinel) veya en azından bir log sunucusuna yönlendirmeniz gerekir. Windows Event Forwarding (WEF) ile bu işlemi ücretsiz olarak yapabilirsiniz.

Windows Event Forwarding ile Merkezi Log Yönetimi

Domain ortamında tüm sunucuların loglarını tek bir koleksiyon sunucusunda toplamak için WEF kullanabilirsiniz:

# Koleksiyon sunucusunda WinRM'i etkinlestir
winrm quickconfig

# Windows Event Collector servisini baslat ve otomatik yap
sc config wecsvc start=auto
net start wecsvc

# Kaynak sunucularda (GPO ile de yapilabilir)
winrm quickconfig -quiet

# Subscription olusturmak icin (koleksiyon sunucusunda)
wecutil cs C:Logon_Subscription.xml

# Mevcut subscription'lari listele
wecutil es

# Subscription durumunu kontrol et
wecutil gr "Logon-Events-Subscription"

Subscription XML dosyasında hangi event ID’leri toplayacağınızı, hangi makinelerden toplayacağınızı ve loglama aralığını belirleyebilirsiniz.

Logon Type Değerlerini Anlamak

4624 ve 4625 Event ID’lerinde karşınıza çıkan Logon Type değeri, oturumun nasıl gerçekleştiğini gösterir. Bu değeri doğru okumak kritik öneme sahiptir:

  • Logon Type 2: İnteraktif oturum (fiziksel klavye/ekran)
  • Logon Type 3: Ağ üzerinden oturum (dosya paylaşımı, vb.)
  • Logon Type 4: Batch oturum (Scheduled Task)
  • Logon Type 5: Servis oturumu (Windows servisi)
  • Logon Type 7: Ekran kilidi açma
  • Logon Type 8: Ağ üzerinden cleartext kimlik bilgisi
  • Logon Type 10: Uzak interaktif oturum (RDP)
  • Logon Type 11: Cached credentials ile oturum

Logon Type 3 ile gelen başarısız denemelerin yoğunluğu genellikle ağ üzerinden yapılan saldırı girişimlerine işaret eder. Logon Type 10 ise RDP bağlantılarını temsil eder ve özellikle dikkatle izlenmesi gereken bir kategoridir.

Pratik Güvenlik Kontrol Scripti

Aşağıdaki script, audit policy yapılandırmanızın doğru olup olmadığını hızlıca kontrol etmenizi sağlar. Bunu düzenli sağlık kontrollerinize dahil edebilirsiniz:

# Audit Policy Saglik Kontrolu
Write-Host "=== AUDIT POLICY SAGLIK KONTROLU ===" -ForegroundColor Cyan
Write-Host "Sunucu: $env:COMPUTERNAME | Tarih: $(Get-Date -Format 'dd.MM.yyyy HH:mm')" -ForegroundColor Gray
Write-Host ""

$KritikAyarlar = @(
    @{Ad="Logon"; Beklenen="Success and Failure"},
    @{Ad="Logoff"; Beklenen="Success"},
    @{Ad="Account Lockout"; Beklenen="Success and Failure"},
    @{Ad="Special Logon"; Beklenen="Success"},
    @{Ad="Credential Validation"; Beklenen="Success and Failure"}
)

$SorunVar = $false

foreach ($Ayar in $KritikAyarlar) {
    $Sonuc = auditpol /get /subcategory:"$($Ayar.Ad)" 2>$null
    $MevcutDurum = ($Sonuc | Select-String -Pattern "(No Auditing|Success|Failure|Success and Failure)$").Matches.Value
    
    if ($MevcutDurum -eq $Ayar.Beklenen) {
        Write-Host "[OK] $($Ayar.Ad): $MevcutDurum" -ForegroundColor Green
    } else {
        Write-Host "[HATA] $($Ayar.Ad): Beklenen '$($Ayar.Beklenen)', Mevcut '$MevcutDurum'" -ForegroundColor Red
        $SorunVar = $true
    }
}

# Log boyutunu kontrol et
$LogBilgisi = wevtutil gl Security | Select-String "maxSize"
Write-Host ""
Write-Host "Security Log: $LogBilgisi" -ForegroundColor Gray

if ($SorunVar) {
    Write-Host ""
    Write-Host "DIKKAT: Bazi audit policy ayarlarinda eksiklik var!" -ForegroundColor Yellow
    exit 1
} else {
    Write-Host ""
    Write-Host "Tum kritik audit policy ayarlari dogru yapilandirilmis." -ForegroundColor Green
    exit 0
}

Dikkat Edilmesi Gereken Tuzaklar

Yıllarca bu işi yapan biri olarak, sık karşılaşılan hatalar konusunda uyarmak isterim:

Log flood problemi: Her şeyi “Success and Failure” olarak açmak, özellikle yoğun kullanılan sunucularda günde milyonlarca log satırı oluşturabilir. Logoff olayları için “Success and Failure” yerine sadece “Success” veya hiç loglamamak bile düşünülebilir. İhtiyacınıza göre dengeleme yapın.

Domain controller ile member server farkı: DC’lerde Account Logon olayları domain genelindeki kimlik doğrulamalarını kapsar ve çok daha yoğun log üretir. DC’ler için ayrı, daha kapsamlı bir audit policy oluşturmanızı öneririm.

Audit policy vs SACL karışıklığı: File/object access denetimi için sadece audit policy yetmez, ayrıca ilgili nesne üzerinde System Access Control List (SACL) de tanımlamanız gerekir.

GPO çakışmaları: Birden fazla GPO’nun aynı sunucuya uygulandığı durumlarda hangi GPO’nun öncelikli olduğunu mutlaka doğrulayın.

Sonuç

Windows Server Audit Policy ve oturum denetimi, güvenlik stratejinizin temel bileşenlerinden biridir. “Belki ihtiyaç olmaz” diye ertelemek, gerçek bir güvenlik olayı yaşandığında elinizin boş kalması anlamına gelir. Yapılandırması zor değil, ama dikkat gerektiriyor.

Özetlemek gerekirse pratik adımlar şunlardır: Önce mevcut durumu kontrol edin, Advanced Audit Policy’ye geçin, kritik alt kategorileri etkinleştirin, log boyutlarını artırın ve mümkünse merkezi log yönetimi kurun. Domain ortamında GPO tercih edin, tek tek sunuculara elle müdahaleden kaçının. Son olarak, bu logları sadece toplamak değil düzenli olarak incelemek ve anomalileri otomatik tespit edecek mekanizmalar kurmak da kritiktir.

Loglar olmadan güvenlik, şüphelisi olmayan bir suç mahalli gibidir: Bir şeylerin ters gittiğini bilirsiniz ama kimin ne yaptığını asla öğrenemezsiniz. Audit policy’nizi bugün yapılandırın, yarın pişman olmayın.

Yorum yapın