IIS’te IP Kısıtlama ve Güvenlik Duvarı Kuralları

Yazar:komut.io ekibi IIS Web Sunucusu Kurulum ve Yönetimi
0 Yorum

Yıllar içinde IIS üzerinde çalışırken en çok ihmal edilen konunun erişim kontrolü olduğunu fark ettim. Sunucu kurulur, uygulama deploy edilir, herkes mutludur. Ta ki birisi logları incelemeye başlayana kadar. O noktada genellikle şaşırtıcı IP adreslerinden gelen isteklerin var olduğunu, bazı endpoint’lerin sürekli tarandığını ve yönetim arayüzlerine dünyanın her yerinden erişim denendiğini görürsünüz. Bu yazıda IIS üzerinde IP kısıtlaması ve güvenlik duvarı kurallarını nasıl doğru şekilde yapılandıracağınızı, gerçek senaryolar üzerinden anlatacağım.

IIS IP Kısıtlaması Neden Önemli?

Windows Firewall tek başına yeterli değil mi diye sorabilirsiniz. Kısmen yeterli, ama web uygulamaları söz konusu olduğunda katmanlı güvenlik şart. IIS düzeyinde IP kısıtlaması yapmanın birkaç kritik avantajı var:

  • Granüler kontrol: Belirli bir site, uygulama havuzu veya sanal dizin için farklı kurallar tanımlayabilirsiniz. Windows Firewall bu esnekliği sunmuyor.
  • Erken engelleme: İstek IIS’e ulaştığında, uygulamanın koduna bile varmadan reddedilir. Bu hem güvenlik hem de performans açısından avantajlı.
  • Dinamik IP kısıtlama: Belirli bir eşiği aşan istekleri otomatik olarak engelleyebilirsiniz. Brute force saldırılarına karşı çok etkili.
  • Log yönetimi: Engellenen istekler W3C loglarına düşer, SIEM sistemlerinize besleyebilirsiniz.

Bir keresinde kurumsal bir müşteride ERP sisteminin yönetim panelinin internete açık olduğunu fark ettim. Ekip “zaten şifre var, sorun olmaz” diyordu. Birkaç günlük log analizinden sonra her gün binlerce başarısız giriş denemesi yapıldığını gösterdim. O günden sonra IP kısıtlaması projenin olmazsa olmazı haline geldi.

IIS IP and Domain Restrictions Modülünü Yüklemek

Başlamadan önce modülün kurulu olup olmadığını kontrol etmeniz gerekiyor. Bu özellik IIS ile birlikte otomatik gelmiyor.

# Modülün yüklü olup olmadığını kontrol etmek için
Get-WindowsFeature -Name Web-IP-Security

# Eğer yüklü değilse kurmak için
Install-WindowsFeature -Name Web-IP-Security -IncludeManagementTools

# Kurulumu doğrula
Get-WindowsFeature -Name Web-IP-Security | Select-Object Name, InstallState

Sunucu Core kullanıyorsanız veya automation pipeline’ınızda bunu yapmak istiyorsanız bu komutlar işinizi görecek. GUI üzerinden de yapabilirsiniz tabii: Server Manager > Add Roles and Features > Web Server (IIS) > Security > IP and Domain Restrictions.

Temel IP Kısıtlama Yapılandırması

IIS Manager ile Yapılandırma

IIS Manager açtıktan sonra kısıtlamayı uygulamak istediğiniz seviyeyi seçin: sunucu geneli, belirli bir site veya uygulama olabilir. IP and Domain Restrictions simgesine çift tıklayın.

Burada iki temel yaklaşım var:

Whitelist yaklaşımı (önerilen): Varsayılan olarak herkesi engelle, sadece izin verilen IP’lere açık. Yönetim panelleri ve internal API’lar için ideal.

Blacklist yaklaşımı: Varsayılan olarak herkese aç, bilinen kötü IP’leri engelle. Public web siteleri için kullanılır ama çok daha az etkilidir.

appcmd ile Yapılandırma

appcmd hâlâ sevdiğim araçlardan biri. Eski alışkanlık, vazgeçemiyorum.

rem Belirli bir IP adresini engellemek için
%windir%system32inetsrvappcmd.exe set config "Default Web Site" -section:system.webServer/security/ipSecurity /+"[ipAddress='192.168.1.100',allowed='false']"

rem Bir IP aralığını izin vermek için (subnet mask ile)
%windir%system32inetsrvappcmd.exe set config "Default Web Site" -section:system.webServer/security/ipSecurity /+"[ipAddress='10.0.0.0',subnetMask='255.255.0.0',allowed='true']"

rem Varsayılan davranışı "deny" olarak ayarlamak için
%windir%system32inetsrvappcmd.exe set config "Default Web Site" -section:system.webServer/security/ipSecurity /allowUnlisted:false

PowerShell ile Yapılandırma

Modern ortamlarda PowerShell ile IIS yönetimi çok daha temiz. WebAdministration modülünü kullanabilirsiniz:

# WebAdministration modülünü import et
Import-Module WebAdministration

# Belirli bir siteye IP kısıtlaması eklemek
Add-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
    -Filter "system.webServer/security/ipSecurity" `
    -Location "Default Web Site" `
    -Name "." `
    -Value @{ipAddress='203.0.113.0'; subnetMask='255.255.255.0'; allowed='false'}

# Varsayılan davranışı ayarlamak
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
    -Filter "system.webServer/security/ipSecurity" `
    -Location "Default Web Site" `
    -Name "allowUnlisted" `
    -Value "false"

# Mevcut kuralları listelemek
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
    -Filter "system.webServer/security/ipSecurity" `
    -Location "Default Web Site" `
    -Name "."

Web.config ile Doğrudan Yapılandırma

Bazı durumlarda doğrudan web.config üzerinde çalışmak daha mantıklı. Özellikle uygulama dağıtımı sırasında yapılandırmanın kodla birlikte version control’de olmasını istiyorsanız.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <security>
            <ipSecurity allowUnlisted="false" enableReverseDns="false">
                <!-- Localhost her zaman erişebilir -->
                <add ipAddress="127.0.0.1" allowed="true" />
                <!-- Ofis IP aralığı -->
                <add ipAddress="10.0.0.0" subnetMask="255.255.0.0" allowed="true" />
                <!-- VPN subnet -->
                <add ipAddress="172.16.0.0" subnetMask="255.240.0.0" allowed="true" />
                <!-- Belirli bir partner IP -->
                <add ipAddress="203.0.113.45" allowed="true" />
            </ipSecurity>
        </security>
    </system.webServer>
</configuration>

enableReverseDns: Bu özelliği dikkatli kullanın. Açık bırakırsanız her istek için DNS reverse lookup yapılır, bu ciddi performans sorununa yol açabilir. Domain bazlı kısıtlama yapmıyorsanız kapalı tutun.

allowUnlisted: false yaptığınızda listelenmeyen tüm IP’ler engellenir. Whitelist yaklaşımı için şart.

Dinamik IP Kısıtlama

Bu özellik IIS 8.0 ile geldi ve bence çok az kullanılıyor. Brute force koruması için mükemmel.

# Dinamik IP kısıtlaması modülünü yükle
Install-WindowsFeature -Name Web-Dyn-Compression

# Saniyede maksimum istek sayısına göre kısıtlama
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
    -Filter "system.webServer/security/dynamicIpSecurity/denyByConcurrentRequests" `
    -Location "Default Web Site" `
    -Name "enabled" -Value "true"

Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
    -Filter "system.webServer/security/dynamicIpSecurity/denyByConcurrentRequests" `
    -Location "Default Web Site" `
    -Name "maxConcurrentRequests" -Value 20

# Belirli zaman aralığında istek sayısına göre kısıtlama
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
    -Filter "system.webServer/security/dynamicIpSecurity/denyByRequestRate" `
    -Location "Default Web Site" `
    -Name "enabled" -Value "true"

Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
    -Filter "system.webServer/security/dynamicIpSecurity/denyByRequestRate" `
    -Location "Default Web Site" `
    -Name "maxRequests" -Value 100

Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' `
    -Filter "system.webServer/security/dynamicIpSecurity/denyByRequestRate" `
    -Location "Default Web Site" `
    -Name "requestIntervalInMilliseconds" -Value 2000

Yukarıdaki yapılandırma şunu söylüyor: Eş zamanlı 20’den fazla istek yapan veya 2 saniye içinde 100’den fazla istek gönderen IP’leri otomatik olarak engelle. E-ticaret siteleri için bu değerleri biraz daha yüksek tutmanız gerekebilir, ama başlangıç noktası olarak iyi.

Windows Firewall ile Entegrasyon

IIS kuralları genellikle yeterli olsa da bazı senaryolarda Windows Firewall tarafında da kural oluşturmak gerekiyor. Özellikle DoS saldırılarına karşı, TCP bağlantısı IIS’e ulaşmadan önce drop edilmesi daha iyi.

# Belirli bir IP bloğunu tamamen engellemek
New-NetFirewallRule -DisplayName "Block Malicious IP Range" `
    -Direction Inbound `
    -RemoteAddress "198.51.100.0/24" `
    -Action Block `
    -Protocol Any `
    -Profile Any

# Sadece HTTP/HTTPS trafiği için belirli bir IP'yi engellemek
New-NetFirewallRule -DisplayName "Block Scraper Bot" `
    -Direction Inbound `
    -RemoteAddress "203.0.113.15" `
    -LocalPort 80,443 `
    -Action Block `
    -Protocol TCP `
    -Profile Any

# Mevcut kuralları listelemek
Get-NetFirewallRule -DisplayName "Block*" | 
    Get-NetFirewallAddressFilter | 
    Select-Object -Property RemoteAddress

# Toplu IP engelleme (bir dosyadan okuyarak)
$blocklist = Get-Content "C:blocked_ips.txt"
foreach ($ip in $blocklist) {
    if ($ip -match '^d{1,3}.d{1,3}.d{1,3}.d{1,3}') {
        New-NetFirewallRule -DisplayName "Block-$ip" `
            -Direction Inbound `
            -RemoteAddress $ip `
            -Action Block `
            -Protocol TCP `
            -LocalPort 80,443 `
            -Profile Any
        Write-Host "$ip engellendi" -ForegroundColor Green
    }
}

Bir noktanın altını çizmek istiyorum: Yüzlerce veya binlerce tek tek IP kuralı oluşturmak Windows Firewall performansını olumsuz etkiler. Bu tür durumlarda IP aralıkları veya ülke bazlı engelleme daha mantıklı. IPSet kullanımı veya Windows Filtering Platform (WFP) doğrudan müdahale bu noktada devreye girebilir.

Gerçek Dünya Senaryosu: Yönetim Paneli Güvenliği

Şimdi somut bir senaryo üzerinden gidelim. Diyelim ki bir kurumsal web uygulamanız var ve /admin path’i sadece şirket ofisinden ve VPN üzerinden erişilebilir olmalı. Dışarıdan gelen her istek 403 dönmeli.

<!-- Web.config - sadece /admin dizini için -->
<configuration>
    <location path="admin">
        <system.webServer>
            <security>
                <ipSecurity allowUnlisted="false">
                    <!-- Ofis statik IP -->
                    <add ipAddress="203.0.113.10" allowed="true" />
                    <!-- VPN IP havuzu -->
                    <add ipAddress="10.8.0.0" subnetMask="255.255.0.0" allowed="true" />
                    <!-- İkinci ofis -->
                    <add ipAddress="198.51.100.25" allowed="true" />
                </ipSecurity>
            </security>
        </system.webServer>
    </location>
</configuration>

Bu yapılandırma sadece /admin path’i için geçerli. Ana site herkese açık kalıyor. Çok sık görülen bir ihtiyaç ve doğru yapılması kritik.

Bunu PowerShell ile de yapabilirsiniz:

# Sadece belirli bir path için kısıtlama
$siteName = "Default Web Site"
$path = "admin"

Add-WebConfigurationProperty `
    -PSPath "IIS:Sites$siteName" `
    -Location $path `
    -Filter "system.webServer/security/ipSecurity" `
    -Name "." `
    -Value @{ipAddress='203.0.113.10'; allowed='true'}

Set-WebConfigurationProperty `
    -PSPath "IIS:Sites$siteName" `
    -Location $path `
    -Filter "system.webServer/security/ipSecurity" `
    -Name "allowUnlisted" `
    -Value "false"

Engellenen İsteklerin İzlenmesi ve Alerting

Güvenlik yapılandırması yaptınız, güzel. Peki bu kurallar çalışıyor mu? Engellemeler oluyor mu? Bunu izlemek şart.

IIS, engellenen istekleri W3C format loglarına yazar. Varsayılan log konumu C:inetpublogsLogFilesW3SVC1 şeklinde. HTTP 403 dönen isteklere bakabilirsiniz ama daha da iyisi Failed Request Tracing ile bunu izlemek.

Logları parse edip günlük rapor alan basit bir PowerShell scripti:

# Bugünkü IIS loglarından engellenen istekleri bul
$logPath = "C:inetpublogsLogFilesW3SVC1"
$today = Get-Date -Format "yyMMdd"
$logFile = "$logPathu_ex$today.log"

if (Test-Path $logFile) {
    $blocked = Get-Content $logFile | Where-Object { 
        $_ -notmatch "^#" -and $_ -match " 403 " 
    }
    
    $report = $blocked | ForEach-Object {
        $fields = $_ -split ' '
        [PSCustomObject]@{
            Tarih    = $fields[0]
            Saat     = $fields[1]
            ClientIP = $fields[8]
            Path     = $fields[4]
            Status   = $fields[11]
        }
    }
    
    # IP bazında grupla ve sırala
    $report | Group-Object ClientIP | 
        Sort-Object Count -Descending | 
        Select-Object Count, Name | 
        Format-Table -AutoSize
    
    # En çok engellenen ilk 10 IP'yi kaydet
    $report | Group-Object ClientIP | 
        Sort-Object Count -Descending | 
        Select-Object -First 10 | 
        Export-Csv "C:reportsblocked_ips_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
    
    Write-Host "Toplam engellenen istek: $($blocked.Count)" -ForegroundColor Yellow
}

Bu scripti Task Scheduler ile günlük çalıştırıp sonuçları mail atabilir veya monitoring sisteminize besleyebilirsiniz.

Sık Yapılan Hatalar

Yıllar içinde gördüğüm yaygın hataları aktarayım:

  • Reverse proxy arkasındaki IP sorunları: Load balancer veya CDN arkasında çalışıyorsanız IIS, gerçek client IP’sini değil proxy IP’sini görür. X-Forwarded-For header’ını işlemek için ek yapılandırma gerekir. ARR (Application Request Routing) kullanıyorsanız bunu mutlaka göz önünde bulundurun.
  • IPv6’yı unutmak: Sadece IPv4 kuralları tanımlayıp IPv6 üzerinden gelen trafiği gözden kaçırmak. Sunucunuzda IPv6 aktifse her iki protokol için de kural yazmanız gerekiyor.
  • Çok granüler firewall kuralları: Yukarıda bahsettiğim gibi, yüzlerce tek IP kuralı performans sorununa yol açabilir. IP aralıklarını tercih edin.
  • Test etmeden production’a almak: IIS kuralları bazen tahmin etmediğiniz sonuçlar doğurabilir. Staging ortamında mutlaka test edin. Kendinizi kilitlemek çok can sıkıcı bir durum, özellikle fiziksel erişiminiz yoksa.
  • Inheritance’ı anlamadan yapılandırma yapmak: IIS’te üst seviyede yapılan kısıtlamalar alt seviyelere miras kalır. Sunucu genelinde bir kural koyduğunuzda tüm siteleri etkilediğini unutmayın.

URL Rewrite ile Ek Güvenlik Katmanı

IP kısıtlamasını URL Rewrite modülüyle kombine etmek bazı senaryolarda çok güçlü bir çözüm sunar. Örneğin belirli User-Agent’lardan gelen istekleri engellemek veya bilinen scanner imzalarını yakalamak:

<rewrite>
    <rules>
        <rule name="Block Bad Bots" stopProcessing="true">
            <match url=".*" />
            <conditions>
                <add input="{HTTP_USER_AGENT}" 
                     pattern="(nikto|sqlmap|masscan|zgrab)" 
                     ignoreCase="true" />
            </conditions>
            <action type="CustomResponse" 
                    statusCode="403" 
                    statusReason="Forbidden" 
                    statusDescription="Access Denied" />
        </rule>
        <rule name="Block Specific Paths" stopProcessing="true">
            <match url="^(wp-admin|phpmyadmin|.env|.git).*" />
            <action type="CustomResponse" 
                    statusCode="404" 
                    statusReason="Not Found" 
                    statusDescription="Not Found" />
        </rule>
    </rules>
</rewrite>

İkinci kural ilginç bir taktik: WordPress admin, phpMyAdmin gibi yaygın hedeflere 403 yerine 404 dönüyorsunuz. Saldırganın gözünden bakınca, servis hiç yokmuş gibi görünüyor. Güvenlik yoluyla gizlilik (security through obscurity) tek başına yeterli değil ama katmanlar oluştururken faydalı.

Yapılandırmayı Test Etmek

Her değişiklikten sonra test etmek hayat kurtarıcı.

# Belirli bir IP'yi taklit ederek istek göndermek (test için)
$headers = @{
    "X-Forwarded-For" = "203.0.113.100"
}

try {
    $response = Invoke-WebRequest -Uri "http://localhost/admin" `
        -Headers $headers `
        -UseBasicParsing
    Write-Host "Status: $($response.StatusCode)" -ForegroundColor Green
} catch {
    Write-Host "Engellendi: $($_.Exception.Response.StatusCode)" -ForegroundColor Red
}

# IIS konfigürasyonunu doğrulamak
& "$env:windirsystem32inetsrvappcmd.exe" list config "Default Web Site" /section:system.webServer/security/ipSecurity

Sonuç

IIS’te IP kısıtlama ve güvenlik duvarı kuralları, tek başına sihirli bir çözüm değil. Ama doğru uygulandığında saldırı yüzeyini ciddi ölçüde küçülten güçlü bir araç. Burada anlattığım yaklaşımı özetlersem:

Whitelist yaklaşımını tercih edin, özellikle hassas endpoint’ler için. Dinamik IP kısıtlamasını aktive edin, brute force saldırılarına karşı çok etkili. Windows Firewall ile IIS kurallarını birlikte kullanın, katmanlı savunma prensibine göre. Logları izleyin, yapılandırdıktan sonra bırakmayın. URL Rewrite ile ekstra katmanlar ekleyin.

Son olarak şunu hatırlatayım: Güvenlik statik bir hedef değil. Bugün yeterli olan yarın yeterli olmayabilir. Loglarınızı düzenli gözden geçirin, yeni tehdit kaynaklarına karşı kurallarınızı güncel tutun. Bir tehdit istihbarat servisi veya blocklist beslemesi kullanıyorsanız bunu otomatize edin. Güvenlik, bir kez yapıp bitirilen bir proje değil, sürekli devam eden bir süreç.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir