DMZ’de IIS + LAN’da SQL Server Doğru Mimari, Güvenli Firewall Kuralları ve Gerçek Saldırı Senaryoları

DMZ’de IIS + LAN’da SQL Server

Doğru Mimari, Güvenli Firewall Kuralları ve Gerçek Saldırı Senaryoları

Kurumsal ağ tasarımlarında en sık yapılan ve en tehlikeli hatalardan biri, web sunucusu ile veritabanını yanlış güvenlik bölgelerinde konumlandırmaktır.
Özellikle şu soru çok sık sorulur:

“DMZ’de IIS web sunucusu var, veritabanı LAN tarafında olabilir mi?”

Cevap:
Evet, olabilir. Ama sadece belirli ve katı şartlar sağlanıyorsa.
Aksi hâlde DMZ kavramı tamamen anlamını yitirir.

Bu yazıda, kurumsal güvenlik dünyasında kabul edilen tek doğru yaklaşımı, firewall kural setleri ve gerçek saldırı senaryolarıyla birlikte ele alıyoruz.

Senaryo Netleştirme

Bu yazı boyunca aşağıdaki referans mimari kullanılmıştır:

DMZ

• IIS Web Server → 10.10.10.2

LAN (Server / Management VLAN)

• SQL Server → 192.168.40.10 (VLAN40 önerilir)

❗ Veritabanı ASLA DMZ’de konumlandırılmaz
✔️ Doğru karar: Veritabanı LAN tarafında, sunucuya özel bir VLAN’da olmalıdır.

Altın Kural (Ezberlenmeli)

DMZ → LAN trafiği varsayılan olarak kapalıdır
Ancak
DMZ → LAN sadece: Tek IP + Tek Sunucu + Tek Port şeklinde açılabilir

Bu kural bozulduğu anda:

• DMZ izolasyonu çöker

• Yatay hareket (lateral movement) mümkün hâle gelir

• Web saldırısı, tüm iç ağa yayılabilir

Doğru Mimari (Production Standardı)

Internet
   |
Firewall
   |
DMZ
[IIS Web Server]
   |
(Firewall üzerinde kontrollü TEK kural)
   |
LAN (Server VLAN)
[SQL Server]

Bu yapı; bankalar, ISP’ler ve kamu ağlarında kullanılan standart DMZ yaklaşımıdır.

Veritabanı Hangi VLAN’da Olmalı?

Yanlış Yaklaşım

• Kullanıcı VLAN’ları (VLAN10 / VLAN20 / VLAN30)

Doğru Yaklaşım

• VLAN40 – Management / Server VLAN

Örnek:

DB Server IP : 192.168.40.10
VLAN        : 40

Bu VLAN’da:

• Kullanıcı PC bulunmaz

• Sadece sunucu ve yönetim sistemleri yer alır

En Kritik Nokta: Firewall Kuralı

DMZ ile LAN arasında sadece tek bir izin kuralı bulunur.

IIS → SQL Firewall Kuralı

Source Zone      : DMZ
Source IP        : 10.10.10.2        (IIS Server)
Destination Zone : VLAN40
Destination IP  : 192.168.40.10      (SQL Server)
Service          : MSSQL (TCP 1433)  (veya MySQL 3306)
Action           : Allow
Log              : Enabled
IPS              : Enabled

Dikkat Edilmesi Gerekenler

• DMZ → LAN ANY olmaz

• DMZ → VLAN10/20/30 olmaz

• DMZ → Subnet bazlı izin verilmez

• ✔️ Sadece IP → IP → Port

Veritabanı Sunucusu Üzerinde Ek Güvenlik

Firewall kuralı tek başına yeterli değildir.
Sunucu üzerinde de ikinci bir güvenlik katmanı olmalıdır.

Windows Firewall (SQL Server)

ALLOW TCP 1433 FROM 10.10.10.2
DENY  ALL FROM ANY

🔐 Firewall + OS Firewall = Çift kilit

Kimlik Doğrulama: En Sık Yapılan Hata

Yanlış

• sa / root kullanıcıları

• Full permission DB user

Doğru

• Sadece ilgili veritabanı

• Yetkiler:

  • SELECT

  • INSERT

  • UPDATE

• DROP / ALTER yok

Bu sayede web uygulaması ele geçirilse bile zarar sınırlı kalır.

IIS Tarafında Güvenlik Önlemleri

Connection String

• Şifreli tutulmalı

• Web root dışında saklanmalı

• Mümkünse environment variable kullanılmalı

Ek Önlemler

• Connection pool limitli

• Timeout değerleri kısa

• Parametreli sorgular / ORM kullanımı

• SQL Injection koruması

DMZ → LAN Bağlantı Testi

IIS sunucusundan:

telnet 192.168.40.10 1433

Firewall log’unda:

ALLOW DMZ(10.10.10.2) → VLAN40(192.168.40.10) TCP 1433

Bunun dışında tek bir port görürseniz:

⚠️ Yanlış yapılandırma vardır.

Firewall Rule Set (Özet)

WAN → DMZ

• HTTPS (443) → IIS

DMZ → VLAN40

• Sadece IIS → SQL (TCP 1433)

VLAN40 → DMZ

• Sadece yönetim (RDP / SSH)

DMZ → LAN / User VLAN

• Tamamen kapalı

En altta

• Default deny (log açık)

Reverse Proxy + SSL Offload ile Bir Üst Seviye

Daha gelişmiş yapılarda, IIS’in önüne Reverse Proxy eklenir.

DMZ

• Reverse Proxy (Nginx) → 10.10.10.10

• IIS Web Server → 10.10.10.2

Akış

Internet → Reverse Proxy (HTTPS)
Reverse Proxy → IIS (HTTP – internal)
IIS → SQL (TCP 1433)

SSL Offload Neden Önemli?

• Sertifika tek noktada

• TLS açıkları merkezi yönetilir

• WAF / rate-limit / header kontrolü

• Daha temiz ve anlamlı loglar

• Performans artışı

Gerçekçi Saldırı Senaryoları

SQL Injection Denemesi

GET /login.aspx?user=admin' OR 1=1--

Reverse Proxy Log

ACTION=BLOCK
REASON=SQL_INJECTION_PATTERN

IIS ve SQL’e ulaşamaz

Directory Traversal

GET /../../windows/system32/cmd.exe

Sonuç

• Reverse proxy tarafından bloklanır

Brute Force Login

• Rate-limit devreye girer

• Firewall IPS bağlantıyı keser

IIS Ele Geçirilirse Ne Olur?

• SQL’e sadece uygulama yetkisiyle erişilir

• User VLAN’lara geçiş yapılamaz

• Domain ele geçirilemez

Zarar uygulama + DB tablosu seviyesinde kalır

Asla Yapılmaması Gerekenler

• DB’yi DMZ’ye koymak

• DMZ → LAN ANY kuralı açmak

• DB’yi kullanıcı VLAN’ına koymak

• sa / root kullanmak

• Management VLAN’a kullanıcı PC almak

Sonuç

DMZ’de IIS olabilir.
Veritabanı LAN’da olmalıdır.
Arada tek yönlü, tek IP, tek port, loglanan bir firewall kuralı bulunur.

Bu yaklaşım:

• Gerçek DMZ izolasyonu sağlar

• Saldırı yüzeyini ciddi biçimde daraltır

• Kurumsal ağlarda yıllardır kullanılan kanıtlanmış bir standarttır

Reverse Proxy saldırıyı görür,
Firewall sınırlar,
DMZ hapseder,
LAN korur.