Windows Defender Firewall: İleri Seviye Kural Tanımlama

yazar

Firewall kurallarını GUI üzerinden tıklaya tıklaya oluşturmak bir yere kadar işe yarıyor. Ama 50 sunucunuz varsa, özel protokolleriniz varsa ya da audit loglarını düzgün okumak istiyorsanız, Windows Defender Firewall’ın arka planında neler döndüğünü gerçekten anlamanız gerekiyor. Bu yazıda sadece “kural ekle, port aç” seviyesini değil, üretim ortamlarında işinize gerçekten yarayacak ileri seviye teknikleri ele alacağız.

Windows Defender Firewall’ın Mimarisi

Önce temel bir şeyi netleştirelim: Windows Defender Firewall ile Advanced Security (WFAS) aynı şeyin farklı arayüzleri. wf.msc açtığınızda gördüğünüz şey, altta yatan Windows Filtering Platform (WFP) üzerine oturuyor. WFP, kernel seviyesinde çalışan bir framework ve tüm network trafiğini burada filtreleniyor.

Üç profil var ve bunları doğru anlamak kritik:

  • Domain Profile: Makine domain’e joined olduğunda ve domain controller’a erişebildiğinde aktif oluyor
  • Private Profile: Ev/ofis ağı olarak işaretlenmiş ağlarda aktif
  • Public Profile: Bilinmeyen ağlarda, kafedeki wifi’de, vb. aktif

Bir kural tanımlarken hangi profile uyguladığınız çok önemli. Özellikle laptop’larda ve hybrid ortamlarda bu profil geçişleri beklenmedik davranışlara yol açabiliyor.

netsh ile Kural Yönetimi

GUI güzel ama otomasyon için netsh advfirewall veya daha modern olan PowerShell cmdlet’leri kullanmak zorundasınız. Önce netsh tarafına bakalım, çünkü eski ortamlarda hala sık karşılaşıyorsunuz.

Mevcut tüm kuralları listelemek için:

netsh advfirewall firewall show rule name=all

Belirli bir kural aramak için:

netsh advfirewall firewall show rule name="SQL Server" verbose

Inbound TCP kuralı eklemek:

netsh advfirewall firewall add rule name="App Server 8443" dir=in action=allow protocol=TCP localport=8443 profile=domain remoteip=192.168.10.0/24

Bu örnekte birkaç önemli parametre var. remoteip ile sadece belirli bir subnet’ten gelen trafiğe izin veriyorsunuz. Production ortamında “her yerden” izin vermek yerine kaynak IP kısıtlaması koymak temel bir güvenlik pratiği.

PowerShell ile Kural Tanımlama

netsh eski güzel ama NetSecurity modülü çok daha güçlü. Windows Server 2012 ve üzeri için PowerShell yolunu tercih etmenizi öneririm.

Temel bir kural oluşturma:

New-NetFirewallRule -DisplayName "RDP Restricted" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 3389 `
    -RemoteAddress 10.0.1.0/24 `
    -Action Allow `
    -Profile Domain `
    -Description "RDP only from management subnet"

Var olan bir kuralı değiştirmek için:

Set-NetFirewallRule -DisplayName "RDP Restricted" `
    -RemoteAddress "10.0.1.0/24","10.0.2.50"

Kuralı devre dışı bırakmak (silmeden):

Disable-NetFirewallRule -DisplayName "RDP Restricted"

Bu özellikle maintenance pencerelerinde işe yarıyor. Kuralı silip sonra yeniden oluşturmak yerine disable/enable döngüsü çok daha temiz.

Senaryo 1: SQL Server Güvenliği

Diyelim ki bir SQL Server’ınız var ve sadece belirli uygulama sunucularının 1433 portuna erişmesini istiyorsunuz. Basit ama kritik bir senaryo.

# Önce varsayılan SQL kuralını kapat (varsa)
Get-NetFirewallRule | Where-Object {$_.DisplayName -like "*SQL*"} | Disable-NetFirewallRule

# Sadece app sunucularına izin ver
New-NetFirewallRule -DisplayName "SQL Server - App Servers Only" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 1433 `
    -RemoteAddress "10.10.5.10","10.10.5.11","10.10.5.12" `
    -Action Allow `
    -Profile Domain `
    -Enabled True

# SQL Browser servisi için UDP 1434
New-NetFirewallRule -DisplayName "SQL Browser - App Servers Only" `
    -Direction Inbound `
    -Protocol UDP `
    -LocalPort 1434 `
    -RemoteAddress "10.10.5.10","10.10.5.11","10.10.5.12" `
    -Action Allow `
    -Profile Domain `
    -Enabled True

Burada dikkat edilmesi gereken nokta: IP listesi statik tutulursa yönetimi zorlaşır. Daha büyük ortamlarda bu kuralları Group Policy üzerinden yönetmek ve IP aralıkları yerine service tags veya named IP sets kullanmak daha ölçeklenebilir.

Senaryo 2: Outbound Kural Kısıtlaması

Çoğu sysadmin inbound kurallara odaklanır, outbound’u göz ardı eder. Ama özellikle web sunucularında, bir servisin internete istenmedik bağlantı kurmasını engellemek için outbound kısıtlaması şart.

Varsayılan olarak outbound trafik izinlidir. Bunu kısıtlamak için önce politikayı değiştirmeniz gerekiyor:

# Domain profili için outbound varsayılanını block yap
Set-NetFirewallProfile -Profile Domain -DefaultOutboundAction Block

# Sonra gerekli outbound trafiğe izin ver
New-NetFirewallRule -DisplayName "Allow DNS Outbound" `
    -Direction Outbound `
    -Protocol UDP `
    -RemotePort 53 `
    -RemoteAddress "10.0.0.53","10.0.0.54" `
    -Action Allow `
    -Profile Domain

New-NetFirewallRule -DisplayName "Allow HTTPS Outbound" `
    -Direction Outbound `
    -Protocol TCP `
    -RemotePort 443 `
    -Action Allow `
    -Profile Domain

Bu yaklaşım whitelist mantığıyla çalışıyor. Sadece izin verdiğiniz trafik geçiyor, geri kalan her şey bloklı. Evet, başta zahmetli ama bir ransomware veya supply chain saldırısı durumunda lateral movement ve data exfiltration’ı ciddi ölçüde kısıtlıyor.

Application-Based Filtering

Port bazlı filtreleme yeterli değil. Aynı port üzerinde çalışan farklı uygulamalar olabilir. Windows Defender Firewall, executable path bazlı kural tanımlamayı destekliyor.

# Sadece belirli bir uygulamanın 8080'i kullanmasına izin ver
New-NetFirewallRule -DisplayName "MyApp HTTP" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 8080 `
    -Program "C:AppsMyServicemyservice.exe" `
    -Action Allow `
    -Profile Domain

Servis bazlı filtreleme de yapılabiliyor:

# Windows Update servisinin dışarı çıkmasına izin ver
New-NetFirewallRule -DisplayName "Windows Update Outbound" `
    -Direction Outbound `
    -Protocol TCP `
    -RemotePort 443 `
    -Service wuauserv `
    -Action Allow `
    -Profile Domain

Bu yaklaşım özellikle hardened sistemlerde çok işe yarıyor. “Port 443 açık” demek yetmiyor, hangi uygulamanın 443’ü kullandığını da kontrol altına alabiliyorsunuz.

Group Policy ile Merkezi Yönetim

50 sunucuya ayrı ayrı firewall kuralı girmek kabustur. Group Policy Object (GPO) üzerinden merkezi yönetim şart.

GPO path’i: Computer Configuration > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security

Buradan tanımladığınız kurallar domain’deki tüm makinelere push ediliyor. Ama dikkat: local kurallar ile GPO kuralları birlikte çalışıyor. GPO’dan gelen kurallar merge edilebilir veya override edebilir, bu ayar profil bazında yapılandırılıyor.

PowerShell ile GPO üzerindeki mevcut firewall ayarlarını okumak için:

# Etkin domain firewall politikasını kontrol et
Get-NetFirewallProfile -PolicyStore ActiveStore | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

# Tüm aktif kuralları kaynak belirterek listele
Get-NetFirewallRule -PolicyStore ActiveStore | Where-Object {$_.Enabled -eq "True"} | Select-Object DisplayName, Direction, Action, PolicyStoreSourceType

PolicyStoreSourceType sütunu size kuralın nereden geldiğini gösteriyor: Local mi, GPO mu, yoksa MDM mi? Bu bilgi sorun giderirken çok değerli.

IPSec ile Kural Bağlantısı: Connection Security Rules

Çoğu kişi bilmez ama WFAS sadece stateful firewall değil, aynı zamanda IPSec policy’lerini de yönetiyor. Connection Security Rules ile iki nokta arasındaki trafiği şifreleyebilirsiniz, authentication zorunlu kılabilirsiniz.

Örnek senaryo: Kritik bir veritabanı sunucusuna sadece belirli domain makinelerinden, Kerberos ile kimlik doğrulanmış bağlantılara izin vermek:

# Authentication gerektiren connection security rule
New-NetIPsecRule -DisplayName "Require Auth to DB Server" `
    -InboundSecurity Require `
    -OutboundSecurity Request `
    -RemoteAddress "10.10.10.50" `
    -Phase1AuthSet (Get-NetIPsecPhase1AuthSet -PolicyStore ActiveStore | Where-Object {$_.DisplayName -eq "Default"}).Name

Bu yaklaşım “sadece domain üyesi makineler bağlanabilir” gibi bir kısıtlama için network segmentasyonundan çok daha etkili. IP sahteciliği yapılsa bile Kerberos authentication geçilemiyor.

Loglama ve Monitoring

Firewall kuralları doğru ayarlanmış olsa bile neyin bloklandığını görmüyorsanız kör uçuyorsunuz demektir.

Log dosyasını etkinleştirmek için:

# Domain profili için logging aç
Set-NetFirewallProfile -Profile Domain `
    -LogFileName "C:WindowsSystem32LogFilesFirewallpfirewall.log" `
    -LogMaxSizeKilobytes 32768 `
    -LogBlocked True `
    -LogAllowed False

LogAllowed genellikle kapalı tutulur çünkü yüksek trafikli sunucularda log dosyası hızla şişer. Önce sadece blocked trafiği loglamak, sonra gerekirse allowed’ı eklemek daha pratik.

Log dosyasını PowerShell ile parse etmek:

# Son 100 blocked connection'ı göster
Get-Content "C:WindowsSystem32LogFilesFirewallpfirewall.log" | 
    Where-Object {$_ -match "DROP"} | 
    Select-Object -Last 100 | 
    ForEach-Object {
        $fields = $_ -split " "
        [PSCustomObject]@{
            Date = $fields[0]
            Time = $fields[1]
            Action = $fields[2]
            Protocol = $fields[3]
            SrcIP = $fields[4]
            DstIP = $fields[5]
            SrcPort = $fields[6]
            DstPort = $fields[7]
        }
    }

Bu çıktıyı düzenli olarak incelemek, hangi trafiğin bloklandığını görmenizi ve yanlış konfigürasyonları erken yakalamayı sağlıyor. Üretimde Event Log tarafına da bakın: Security log’unda firewall ile ilgili event’lar 5152 (blocked), 5154 (listen), 5156 (allowed) ID’leri ile geliyor.

Kural Önceliği ve Çakışma Yönetimi

Windows Defender Firewall’da kurallar “en kısıtlayıcı kazanır” prensibine göre çalışmıyor. Bunun yerine allow kuralı block kuralını ezer mantığı var, çoğu insanın kafasını karıştıran nokta da bu.

Eğer hem allow hem de block kuralı aynı trafiğe uyuyorsa:

  • Block action’ı Allow action’ını override eder (bu noktada çoğu kaynak yanıltıcı)
  • Aslında doğrusu şu: Explicit Block kuralları, explicit Allow kurallarına göre öncelikli
  • Ama Authentication bypass kuralları her şeyi geçer

Özel durumlar için Block kuralı yazarken rule name’e dikkat edin, troubleshooting sırasında hangi kuralın neden var olduğunu anlamak için açıklayıcı isimler hayat kurtarıyor.

# Belirli bir IP'yi tamamen blokla (allow kuralı olsa bile)
New-NetFirewallRule -DisplayName "BLOCK - Suspicious Host 203.0.113.50" `
    -Direction Inbound `
    -RemoteAddress "203.0.113.50" `
    -Action Block `
    -Profile Any `
    -Enabled True

Üretim Ortamında Kural Dağıtımı: Betik Tabanlı Yaklaşım

Tüm firewall konfigürasyonunu kod olarak yönetmek, Infrastructure as Code pratiğinin önemli bir parçası. Aşağıdaki örnek, bir web sunucusu için temel kural setini idempotent şekilde uygulayan bir betik:

# web-server-firewall.ps1
# Parametreler
$managementSubnet = "10.0.1.0/24"
$appSubnets = @("10.10.5.0/24", "10.10.6.0/24")

# Mevcut custom kuralları temizle
Get-NetFirewallRule | Where-Object {$_.DisplayName -like "CUSTOM-*"} | Remove-NetFirewallRule

# Inbound kurallar
$rules = @(
    @{Name="CUSTOM-HTTP-Inbound"; Port=80; Remote="Any"; Proto="TCP"},
    @{Name="CUSTOM-HTTPS-Inbound"; Port=443; Remote="Any"; Proto="TCP"},
    @{Name="CUSTOM-RDP-Mgmt"; Port=3389; Remote=$managementSubnet; Proto="TCP"},
    @{Name="CUSTOM-WinRM-Mgmt"; Port=5985; Remote=$managementSubnet; Proto="TCP"}
)

foreach ($rule in $rules) {
    New-NetFirewallRule -DisplayName $rule.Name `
        -Direction Inbound `
        -Protocol $rule.Proto `
        -LocalPort $rule.Port `
        -RemoteAddress $rule.Remote `
        -Action Allow `
        -Profile Domain `
        -Enabled True | Out-Null
    Write-Host "Kural olusturuldu: $($rule.Name)"
}

Write-Host "Firewall konfigurasyonu tamamlandi."

Bu betiği bir DSC (Desired State Configuration) pipeline’ına veya basitçe bir Scheduled Task’a bağlayarak konfigürasyon drift’ini önleyebilirsiniz. Birisi GUI’den kural ekler veya siler, betik çalıştığında tutarlı bir duruma geri dönüyorsunuz.

Windows Firewall’ı Tamamen Devre Dışı Bırakmak Üzerine

Bunu bir section olarak eklemek istedim çünkü hala çok sık yapılan bir hata. “Ağ ekibimiz zaten bir firewall cihazı koydu, Windows Firewall’a ne gerek var” mantığı tehlikeli.

Perimeter firewall’ınız delinirse veya içeriden bir saldırı olursa (insider threat, yanal hareket eden malware) host-based firewall son savunma hattınız. East-west trafiği perimeter firewall’unuz görmüyor bile. Lateral movement senaryolarında Windows Defender Firewall açık ve doğru konfigüre edilmiş olması, saldırganın bir sunucudan diğerine atlamasını çok zorlaştırıyor.

Şu an hangi profillerin aktif olduğunu ve genel durumu öğrenmek için:

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction, LogFileName, LogBlocked

Çıktıda herhangi bir profil için Enabled: False görüyorsanız ve bunun kasıtlı bir karar olmadığını düşünüyorsanız, derhal düzeltmeniz gerekiyor.

Sorun Giderme: “Kural Var Ama Çalışmıyor”

Bu klasik bir senaryo. Kuralı ekliyorsunuz, ama bağlantı hala gelmiyor ya da gitmiyor. Sistematik yaklaşım:

1. Kuralın gerçekten aktif olduğunu doğrula:

Get-NetFirewallRule -DisplayName "Kural Adi" | Select-Object DisplayName, Enabled, Direction, Action, Profile

2. Hangi profile bağlandığını kontrol et:

# Mevcut aktif profili göster
Get-NetConnectionProfile

3. Kural filtresini detaylı incele:

$rule = Get-NetFirewallRule -DisplayName "Kural Adi"
$rule | Get-NetFirewallPortFilter
$rule | Get-NetFirewallAddressFilter
$rule | Get-NetFirewallApplicationFilter

Çoğu zaman “kural var ama çalışmıyor” dediğinizde aslında kural yanlış profile atanmıştır. Domain profil için kural yazmışsınızdır ama makine o an Public profil üzerindedir (örneğin domain controller’a ulaşamıyor). Ya da remote address filtresi yanlış subnet’tir.

4. Windows Firewall logunu gerçek zamanlı izle:

Get-Content "C:WindowsSystem32LogFilesFirewallpfirewall.log" -Wait -Tail 50

Bağlantı denemesi yapın, DROP satırı geliyorsa hangi port ve IP’nin bloklandığını görebiliyorsunuz. Gelmiyor ve bağlantı yine de olmuyor mu? O zaman sorun firewall’da değil başka bir yerde demektir.

Sonuç

Windows Defender Firewall, düzgün kullanıldığında kurumsal ortamlar için son derece güçlü bir araç. GUI yeterli değil, PowerShell ve GPO tabanlı yönetim şart. Outbound kısıtlamayı ihmal etmeyin, uygulama bazlı filtrelemeyi değerlendirin ve her şeyden önemlisi loglama açık olsun.

Özellikle vurgulamak istediğim birkaç nokta: Kurallarınızı kod olarak tutun ve versiyon kontrolüne alın. “Birisi GUI’den bir şey değiştirdi” sorununu ancak bu şekilde takip edebilirsiniz. IPSec connection security rules genellikle göz ardı ediliyor ama kritik servisler arasında kimlik doğrulamalı şifreli kanal için çok değerli. Ve son olarak, firewall kuralı eklemenin kolay, neden eklendiğini anlamanın zor olduğu bir ortam yaratmayın. Her kurala açıklama yazın, isimlerini standardize edin, kim için ne zaman eklendiğini belgeleyin.

Güvenlik katmanlı bir yaklaşım gerektiriyor. Windows Defender Firewall bu katmanların önemli bir parçası ve onu doğru yönetmek, bir sonraki güvenlik olayında fark yaratabilir.

Yorum yapın