Windows Server'da Ağ İzolasyonu ve Segmentasyon

Yıllar önce bir müşterinin datacenter’ında yaşanan bir olayı hiç unutamam. Muhasebe departmanının kullandığı bir Windows Server, üretim ağındaki kritik veritabanı sunucusuna doğrudan erişebiliyordu. Kimse bunu yanlış yapılandırmış değildi, sadece hiç doğru yapılandırılmamıştı. Bir ransomware saldırısında bu açık, saldırganlara tüm ağı şifrelemek için yeterli yolu sağladı. İşte o günden beri ağ izolasyonu ve segmentasyon benim için bir tercih değil, temel gereksinim haline geldi.

Ağ Segmentasyonu Neden Bu Kadar Kritik?

Windows Server ortamlarında segmentasyon, salt güvenlik meselesi değil. Performans yönetimi, compliance gereksinimleri ve operasyonel verimlilik açısından da doğrudan etkisi var. PCI-DSS, ISO 27001 veya KVKK kapsamında denetlenen ortamlarda segmentasyon olmadan audit geçmek neredeyse imkansız.

Temel mantık şu: Bir sistemi ele geçiren saldırgan, aynı broadcast domain’deki tüm sistemlere ulaşabilir. Lateral movement denen bu yayılma, düzgün segmente edilmiş ağlarda ciddi ölçüde kısıtlanır. “Blast radius”ü minimize etmek, modern güvenlik mimarisinin temel prensibi.

VLAN Tabanlı Segmentasyonun Temelleri

Fiziksel altyapıda segmentasyonun ilk adımı VLAN yapılandırmasıdır. Windows Server tarafında bunu Hyper-V sanal switchleri veya NIC ekip yapılandırmaları üzerinden yönetiriz. Ama önce kavramsal çerçeveyi netleştirelim.

Tipik bir kurumsal ortamda şu segmentleri görmek makul:

Yönetim ağı (Management VLAN): Sunucu yönetimi, RDP, WinRM trafiği
Üretim ağı (Production VLAN): Uygulama sunucuları arası iletişim
Veritabanı ağı (Database VLAN): Sadece uygulama sunucularının erişebildiği izole segment
DMZ: İnternet’e açık servisler
Yedekleme ağı: Backup trafiğinin izole edildiği segment

PowerShell ile mevcut NIC yapılandırmanızı görmek için:

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status, MacAddress, LinkSpeed

VLAN tag’leme için NIC’in desteklemesi gerekiyor. Desteklenen adaptörlerde VLAN ID atamak:

# Belirli bir adaptore VLAN ID atama
Set-NetAdapterAdvancedProperty -Name "Ethernet 2" -RegistryKeyword "VlanID" -RegistryValue 100

# Mevcut VLAN ayarlarini goruntuleme
Get-NetAdapterAdvancedProperty -Name "Ethernet 2" | Where-Object {$_.DisplayName -like "*VLAN*"}

Hyper-V Ortamında Sanal Ağ İzolasyonu

Hyper-V kullanan ortamlarda işler hem kolaylaşıyor hem de karmaşıklaşıyor. Sanal switchler üzerinden granüler izolasyon mümkün, ama yanlış yapılandırılmış bir sanal switch tüm güvenlik mimarinizi delmek için yeterli.

Private Switch: Sadece aynı Hyper-V host’undaki VM’lerin birbiriyle konuşabildiği, fiziksel ağa hiç çıkışı olmayan switch tipi. Geliştirme ve test ortamları için mükemmel.

Internal Switch: Host ile VM’lerin konuşabildiği ama fiziksel ağa çıkışın olmadığı tip. NAT yapılandırmasıyla birlikte internet erişimi sağlanabilir.

External Switch: Fiziksel NIC’e bağlı, gerçek ağ trafiği için kullanılan tip.

PowerShell ile Hyper-V sanal switch oluşturmak:

# Izole production switch olusturma
New-VMSwitch -Name "ProductionSwitch" -NetAdapterName "Ethernet" -AllowManagementOS $false

# Database segment icin tamamen izole private switch
New-VMSwitch -Name "DatabaseSwitch" -SwitchType Private

# Yonetim trafiği icin internal switch
New-VMSwitch -Name "ManagementSwitch" -SwitchType Internal

-AllowManagementOS $false parametresi kritik. Bu parametre host işletim sisteminin ilgili switch üzerinden trafiğe katılmasını engeller. Production trafiği üzerinde host OS’un bulunması hem güvenlik açığı hem de potansiyel performans sorunu.

VM’e birden fazla ağ adaptörü ekleyerek farklı segmentlere dahil etmek:

# VM'e production ağı icin adaptör ekle
Add-VMNetworkAdapter -VMName "AppServer01" -SwitchName "ProductionSwitch" -Name "Production"

# Ayni VM'e database ağına erisim icin ikinci adaptör
Add-VMNetworkAdapter -VMName "AppServer01" -SwitchName "DatabaseSwitch" -Name "Database"

# Adaptör VLAN yapilandirmasi
Set-VMNetworkAdapterVlan -VMName "AppServer01" -VMNetworkAdapterName "Production" -Access -VlanId 100

Windows Firewall ile Host Tabanlı İzolasyon

Ağ seviyesindeki segmentasyonu host tabanlı firewall ile tamamlamak, derinlemesine savunma (defense-in-depth) prensibinin gereği. Windows Firewall, doğru yönetildiğinde kurumsal sınıf bir host güvenlik katmanı sağlıyor.

Önce mevcut firewall profillerini görelim:

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

Sadece belirli bir IP aralığından RDP erişimine izin veren, diğer her şeyi reddeden bir kural seti:

# Oncelikle tum RDP erisimini engelle
New-NetFirewallRule -DisplayName "Block RDP Default" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 3389 `
    -Action Block `
    -Priority 100

# Sadece yonetim VLAN'indan (10.10.10.0/24) RDP izni
New-NetFirewallRule -DisplayName "Allow RDP from Management VLAN" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 3389 `
    -RemoteAddress "10.10.10.0/24" `
    -Action Allow `
    -Priority 50

Veritabanı sunucusu için sadece uygulama sunucularından SQL erişimine izin veren kural:

# Sadece uygulama sunucularinin IP'lerinden SQL erişimi
New-NetFirewallRule -DisplayName "Allow SQL from App Servers" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 1433 `
    -RemoteAddress @("10.20.1.10", "10.20.1.11", "10.20.1.12") `
    -Action Allow

# Diger tum SQL baglantilari reddet
New-NetFirewallRule -DisplayName "Block SQL Default" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 1433 `
    -Action Block

Group Policy ile Merkezi Firewall Yönetimi

Her sunucuya tek tek kural yazmak hem hataya açık hem de ölçeklenemiyor. Group Policy Object’ler (GPO) üzerinden merkezi firewall yönetimi şart. Ancak burada dikkat edilmesi gereken bir nokta var: GPO ile gelen kurallar yerel kurallarla çakışabilir ve bu çakışmalar beklenmedik erişim açıklarına yol açabilir.

GPO üzerinden Windows Firewall’u yönetmek için netsh advfirewall veya PowerShell’in New-NetFirewallRule cmdlet’lerini GPO başlangıç scriptleri olarak dağıtabilirsiniz. Daha iyi yöntem ise GPO’nun “Windows Defender Firewall with Advanced Security” bölümünü kullanmak.

Mevcut tüm firewall kurallarını export etmek:

# Firewall kurallarini CSV olarak export et
Get-NetFirewallRule | Select-Object DisplayName, Enabled, Direction, Action, Priority | Export-Csv -Path "C:AuditFirewallRules.csv" -NoTypeInformation

# Spesifik port icin aktif kurallari filtrele
Get-NetFirewallRule -Action Allow -Enabled True -Direction Inbound | 
    Get-NetFirewallPortFilter | 
    Where-Object {$_.LocalPort -eq "3389"} | 
    ForEach-Object {Get-NetFirewallRule -AssociatedNetFirewallPortFilter $_}

IPsec ile Şifreli Segment İletişimi

VLAN izolasyonu fiziksel/mantıksal ayrım sağlar ama trafiği şifrelemez. Kritik segment iletişimini, örneğin uygulama sunucusu ile veritabanı sunucusu arasını, IPsec ile şifrelemek ek bir güvenlik katmanı ekler. Buna Microsoft terminolojisinde “Connection Security Rules” deniyor.

# Iki sunucu arasinda IPsec zorunlulugu tanimla
New-NetIPsecRule -DisplayName "Require IPSec AppServer to DB" `
    -InboundSecurity Require `
    -OutboundSecurity Require `
    -RemoteAddress "10.30.1.0/24" `
    -LocalAddress "10.20.1.0/24"

# IPsec politikasini goruntule
Get-NetIPsecRule | Select-Object DisplayName, InboundSecurity, OutboundSecurity

Gerçek dünyada IPsec’i her yerde uygulamak performans açısından maliyetli. Sadece gerçekten kritik olan segmentler arası trafikte, özellikle veritabanı bağlantıları ve yönetim trafiğinde kullanmak makul.

Windows Server 2019/2022’de Software Defined Networking

SDN, özellikle büyük Hyper-V ortamlarında ağ segmentasyonunu tamamen farklı bir boyuta taşıyor. Network Controller ile merkezi yönetim, Distributed Firewall ile her VM’e atanan mikro-segmentasyon politikaları mümkün hale geliyor.

SDN altyapısında Network Controller durumunu kontrol etmek:

# Network Controller saglik kontrolu
$NCNodes = Get-NetworkControllerNode
$NCNodes | Select-Object Name, Status, FaultDomain

# Virtual network'leri listele
Get-NetworkControllerVirtualNetwork -ConnectionUri "https://nc.domain.local"

SDN’nin dezavantajı ciddi altyapı gereksinimi. En az üç node’luk Network Controller cluster’ı, Software Load Balancer ve RAS Gateway gerekiyor. Küçük ve orta ölçekli ortamlarda overkill olabilir, ama büyük çok kiracılı (multi-tenant) ortamlarda vazgeçilmez.

Pratik Senaryo: Üç Katmanlı Uygulama Segmentasyonu

Gerçek bir senaryoyu inceleyelim. Bir e-ticaret platformu için tipik üç katmanlı mimari:

Web katmanı: DMZ’de, internet’e açık (VLAN 10, 192.168.10.0/24)
Uygulama katmanı: İzole iç ağ (VLAN 20, 192.168.20.0/24)
Veritabanı katmanı: Maksimum izolasyon (VLAN 30, 192.168.30.0/24)

Bu mimariyi PowerShell ile yapılandırmak:

# Web sunucusuna sadece 80/443 uzerinden disaridan erisim
New-NetFirewallRule -DisplayName "Allow HTTP/HTTPS Inbound" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort @(80, 443) `
    -Action Allow

# Web sunucusundan sadece app katmanina 8080 portunda erisim
New-NetFirewallRule -DisplayName "Allow Web to App Tier" `
    -Direction Outbound `
    -Protocol TCP `
    -RemotePort 8080 `
    -RemoteAddress "192.168.20.0/24" `
    -Action Allow

# Web sunucusunun db katmanina dogrudan erisimini engelle
New-NetFirewallRule -DisplayName "Block Web to DB Direct" `
    -Direction Outbound `
    -Protocol TCP `
    -RemoteAddress "192.168.30.0/24" `
    -Action Block `
    -Priority 100

# App sunucusundan sadece SQL portuna db erisimi
New-NetFirewallRule -DisplayName "Allow App to DB SQL" `
    -Direction Outbound `
    -Protocol TCP `
    -RemotePort 1433 `
    -RemoteAddress "192.168.30.0/24" `
    -Action Allow

İzleme ve Güvenlik Denetimi

Segmentasyon yapılandırdıktan sonra en sık yapılan hata: izlemeyi ihmal etmek. Firewall logları aktif edilmezse kim nereye bağlanmaya çalıştığını bilemezsiniz.

Windows Firewall loglamayı aktive etmek:

# Domain profili icin firewall loglama ayarlari
Set-NetFirewallProfile -Profile Domain `
    -LogFileName "%systemroot%system32LogFilesFirewallpfirewall.log" `
    -LogMaxSizeKilobytes 32767 `
    -LogBlocked True `
    -LogAllowed True

# Anlık bağlantı durumlarini goruntule
Get-NetTCPConnection -State Established | 
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, OwningProcess |
    Sort-Object RemoteAddress

Belirli bir segmentten beklenmedik bağlantı denemelerini tespit etmek için log analizi:

# Firewall log'undan engellenen baglantilari parse et
$LogPath = "$env:SystemRootsystem32LogFilesFirewallpfirewall.log"
Get-Content $LogPath | Where-Object {$_ -match "DROP"} | 
    ForEach-Object {
        $Fields = $_ -split " "
        [PSCustomObject]@{
            Date = $Fields[0]
            Time = $Fields[1]
            Action = $Fields[2]
            SourceIP = $Fields[4]
            DestIP = $Fields[5]
            DestPort = $Fields[7]
        }
    } | Group-Object SourceIP | Sort-Object Count -Descending | Select-Object -First 20

Bu script, en çok engellenen kaynak IP’leri gösterir. Kendi iç ağınızdan gelen çok sayıda DROP kaydı, muhtemelen yanlış yapılandırılmış bir uygulama ya da lateral movement girişiminin işareti.

Sık Yapılan Hatalar ve Kaçınma Yolları

Yıllarca bu işi yapanların başına gelen ortak sorunlar:

Çok açık başlamak: “Önce çalıştıralım, sonra kısıtlarız” zihniyeti genellikle “sonra” hiç gelmez. Baştan kısıtlayıcı yapılandırın, ihtiyaç oldukça açın.
Yönetim ağını ihmal etmek: Üretim segmentleri mükemmel izole edilmiş ama yönetim ağı herkese açık. Saldırganlar bunu sever.
Firewall kurallarını belgelememek: Altı ay sonra kim hangi kuralı neden ekledi bilinmiyor. Her kurala açıklayıcı bir DisplayName ve yorum ekleyin.
Test etmemek: Yapılandırdıktan sonra gerçekten çalışıyor mu diye test etmemek. Test-NetConnection ve portqry ile doğrulamak şart.

# Segment erisimini test et
Test-NetConnection -ComputerName "192.168.30.10" -Port 1433 -InformationLevel Detailed

# Belirli bir porta UDP/TCP testi
Test-NetConnection -ComputerName "10.30.1.5" -Port 443

Sonuç

Windows Server ortamında ağ izolasyonu ve segmentasyon, tek seferlik bir yapılandırma değil, sürekli bakım gerektiren bir süreç. VLAN’lar, Hyper-V sanal switchleri, Windows Firewall kuralları ve IPsec politikaları birbirini tamamlayan katmanlar olarak düşünülmeli. Hiçbiri tek başına yeterli değil.

Nereden başlayacağınızı bilemiyorsanız şu önceliklendirmeyi öneririm: Önce kritik veritabanı sunucularını izole edin. Sonra yönetim trafiğini ayrı bir segmente taşıyın. Ardından firewall loglamayı aktif hale getirin ve birkaç hafta veri toplayın. Hangi trafiğin nereye gittiğini gördükten sonra gerçekçi bir segmentasyon mimarisi çizebilirsiniz.

Segmentasyon acı veren bir süreç gibi görünebilir, özellikle köklü altyapılarda geriye dönük uygulamak zorunda kaldığınızda. Ama daha da acı veren şey, segmentasyon yokken yaşanan bir güvenlik olayını yönetmeye çalışmak. O acıyı yaşayanlar bir daha bu işi ertelemez.

Windows Server’da Ağ İzolasyonu ve Segmentasyon