Stateful firewall ve zone tabanlı politika tasarımı

Firewall’u “trafiğe izin veren ya da engelleyen kutu” diye tanımlamak doğru ama eksik. Asıl soru, neye bakarak karar verdiği. Bu yazıda stateless ve stateful denetimi karşılaştırıp, session tablosunun sahada nasıl sürprizler çıkardığına ve zone tabanlı politikanın nasıl düzenli tutulacağına bakacağız.

Stateless: her paket yabancı

Stateless filtre (klasik ACL) her paketi tek başına değerlendirir: kaynak, hedef, protokol, port. Paketin bir bağlantının parçası olup olmadığını bilmez. Dönüş paketi de bu yüzden yeni bir paket gibi değerlendirilir: dönüş yönünde ona izin veren bir kural varsa geçer, yoksa düşer.

Sorun dönüş trafiğinde başlar. İçerideki bir istemci dışarıdaki bir web sunucusuna 443’ten bağlanır. Cevap paketleri, istemcinin bağlantıyı başlatırken seçtiği geçici kaynak portuna (ephemeral port) döner ve bu port önceden bilinmez. Stateless bir filtrede bu dönüşe izin vermek için ya geniş bir port aralığını açarsın ya da TCP bayraklarına bakan (established benzeri) kurallar yazarsın. İkisi de kaba çözümler; özellikle UDP’de “kurulmuş bağlantı” kavramı olmadığı için iş daha da zorlaşır.

Stateless filtrenin yine de yeri var: hızlıdır, durum tutmaz ve router’larda, altyapı kenarında kaba filtreleme için idealdir.

Stateful: bağlantıyı hatırlayan firewall

Stateful firewall, izin verdiği ilk paketle birlikte bir session (oturum) kaydı oluşturur: kaynak ve hedef IP, kaynak ve hedef port, protokol ve bağlantının durumu. Dönüş paketleri politika listesinde baştan aranmaz; session tablosundaki kayıtla eşleştirilir.

Eşleşme koşulsuz geçiş demek değildir. Firewall paketin bağlantının o anki durumuna uyup uymadığına da bakar (TCP’de bayraklar ve sıra numaraları gibi). IPS ya da uygulama denetimi gibi başka güvenlik kontrolleri açıksa paket onlardan da geçer.

Sonuç: Politikada yalnızca bağlantıyı başlatan yönü yazarsın. “İçeriden dışarıya 443’e izin” yeterlidir, dönüş trafiği otomatik olarak geçer.

Session protokole göre farklı tutulur

• TCP: Bağlantının bir durumu vardır: el sıkışma, veri aktarımı, kapanış. Firewall bu durumları izler; kapanan bağlantının kaydını siler.
• UDP: Protokolde bağlantı kavramı yoktur. Firewall ilk paketten bir kayıt oluşturur ve bu kaydı yalnızca boşta kalma süresiyle siler. DNS gibi kısa akışlar ile ses ve görüntü gibi uzun akışlar aynı zaman aşımıyla iyi yönetilmez.
• ICMP: Echo isteği ve cevabı, ICMP başlığındaki tanımlayıcı (identifier) ile eşleştirilir.
• NAT: Adres çevirisi varsa session kaydı çeviri bilgisini de tutar. Dönüş paketi bu kayda göre geri çevrilir; session kaybolursa çeviri de kaybolur.

Session tablosunun sahadaki tuzakları

Stateful denetim hayatı kolaylaştırır ama kendi arızalarını da getirir. Bunlar genelde “firewall bazen paketi düşürüyor” şikâyeti olarak gelir.

Asimetrik yönlendirme

Gidiş paketi firewall A’dan, dönüş paketi firewall B’den geçerse B’de bu bağlantıya ait session yoktur. B, dönüş paketini yeni ve geçersiz bir bağlantı sayıp düşürür. Belirti: bağlantı kurulamaz ya da TCP el sıkışması yarıda kalır. Çözüm tasarımdadır: trafiğin simetrik akmasını sağlamak. Session senkronizasyonu yalnızca aynı HA kümesinin üyeleri arasında, desteklenen ve doğru yapılandırılmış bir mimaride işe yarar; birbirinden bağımsız iki firewall için çözüm değildir.

Session zaman aşımı

Uzun süre boşta kalan TCP bağlantıları (veritabanı bağlantı havuzları, bazı uygulama sunucuları) firewall’un boşta kalma süresini aştığında session tablodan silinir. Uygulama bağlantının hâlâ açık olduğunu sanır, bir sonraki paketi gönderir ve firewall onu düşürür. Belirti: “Gece boyunca açık kalan uygulama sabah ilk sorguda hata veriyor.” Çözüm, ilgili trafik için zaman aşımını uzatmak ya da uygulama tarafında keepalive kullanmaktır.

Session tablosunun dolması

Her session bellekte yer kaplar. SYN flood gibi saldırılar ya da hatalı bir uygulama, tabloyu doldurabilir. Tablo dolunca firewall meşru yeni bağlantıları da kabul edemez. Stateful firewall bu yüzden DDoS’ta korumadan çok hedef haline gelebilir; bunu DDoS yazısında ayrıntılı anlattık.

Zone tabanlı politika

Arayüz bazlı kurallar küçük ağlarda iş görür. Arayüz sayısı arttıkça kurallar çoğalır ve kimse neyin neden açık olduğunu hatırlamaz. Zone tabanlı modelde arayüzler güven seviyesine göre gruplanır ve politika arayüzler arasında değil, zone’lar arasında yazılır.

Tipik bir kurgu:

Politikalar bu zone çiftleri arasında yazılır: inside → outside, inside → servers, outside → dmz gibi.

Politika yazarken trafiği üç türe ayırmak gerekir:

• Zone’lar arası trafik: Bir zone’dan diğerine geçer ve yazılı bir politika gerektirir. Politika yoksa reddedilir.
• Aynı zone içi trafik: Varsayılan davranışı üreticiye göre değişir. Bazı platformlarda serbesttir, bazılarında politika ister.
• Cihazın kendisine giden ya da cihazdan çıkan trafik: Yönetim erişimi, routing protokolleri, VPN el sıkışmaları. Huawei’de local zone, Cisco ZBFW’de self zone bu trafiği temsil eder. Bu trafik ayrı politikayla korunmalıdır; aksi halde firewall’un yönetim arayüzü yanlış zone’dan erişilebilir kalabilir.

Bazı üreticilerin önceden tanımlı zone’larının (ör. güven seviyesi numaraları) anlamı da farklıdır. Varsayılanı bildiğini düşünme; kullandığın platformda doğrula.

Politika tasarımının kuralları

1. Varsayılan reddet. Politika setinin sonunda her şeyi reddeden bir kural olsun. Bazı platformlarda örtük reddetme loglanmaz ya da loglaması ayrıca açılır; böyle platformlarda açıkça yazılmış ve loglanan bir deny any, düşen trafiği görmenin en kolay yolu. Kendi platformunun varsayılanına bak.
2. En az yetki. any kaynağı, any hedefi ya da any servisi içeren her kural bir soru işaretidir. Gerekçesi yazılı olmalı.
3. Sıralama önemlidir. Firewall’ların çoğunda kurallar yukarıdan aşağıya okunur ve ilk eşleşen kural uygulanır; kendi platformunun kural işleme mantığını doğrula. Bu modelde geniş bir kural, altındaki dar kuralı gölgeler ve o kural hiç çalışmaz. Düzenli olarak sıfır isabetli (hit count) kuralları gözden geçir.
4. Nesne kullan, isimlendir. IP yerine anlamlı isimli nesneler ve gruplar: SRV-ERP-DB, GRP-MUHASEBE. Altı ay sonra kuralı okuyan kişi büyük ihtimalle sensin.
5. Her kurala bir açıklama. Kim istedi, hangi talep numarası, ne zamana kadar? Geçici açılan kurallar en kalıcı kurallardır.
6. Logla ama akıllıca. Reddedilen trafiği ve kritik izinleri logla. Yüksek hacimli rutin izinleri loglamak log sunucusunu boğar, değerli kaydı gürültüde kaybettirir.
7. Periyodik temizlik. Kullanılmayan, gölgelenmiş ve süresi geçmiş kurallar çeyrekte bir gözden geçirilmeli.

Üretici yaklaşımları

Dört platform da stateful çalışır; farklı olan, politikanın neye bağlandığıdır.

Örnek saha senaryosu: politika izin veriyor, bağlantı kurulmuyor

Kullanıcı bir uygulamaya bağlanamıyor. Firewall’da inside → servers yönünde ilgili porta izin veren kural var ve hit sayacı artıyor. Kural doğru görünüyorsa sorun büyük ihtimalle session’ın hayatındadır. Kontrol sırası:

1. Session oluşuyor mu? Session tablosunda bu bağlantıyı ara: Huawei USG’de display firewall session table, FortiGate’te diagnose sys session list, Cisco ASA’da show conn. Cisco FTD’de aynı show conn komutu, system support diagnostic-cli ile girilen diagnostic CLI’da çalıştırılır. Kayıt yoksa üç ihtimal var: paket firewall’a hiç gelmiyor, başka bir kurala takılıyor ya da firewall onu session açmadan düşürüyor. Son durumun sebebi TCP durum denetimi (ör. SYN olmadan gelen ilk paket), kaynak adres doğrulaması (uRPF) ya da IPS gibi bir güvenlik profili olabilir. Firewall’un düşürme loglarına ve paket izleme aracına bak.
2. Dönüş paketi aynı firewall’a geliyor mu? Kayıt var ama yarı açıkta kalıyorsa (SYN görüldü, cevap yok), dönüş trafiği başka bir yoldan dönüyor olabilir. Sunucunun varsayılan ağ geçidini ve routing tablosunu kontrol et.
3. NAT doğru mu? Sunucu cevabı çevrilmemiş adrese gönderiyorsa dönüş paketi session ile eşleşmez.
4. Bağlantı bir süre sonra mı kopuyor? Kurulup sonra düşüyorsa boşta kalma zaman aşımına bak.

Bu sıra, “kural var ama çalışmıyor” şikâyetlerinin büyük kısmını birkaç dakikada ayırt eder.

Sonuç

Stateless filtre paketlere bakar, stateful firewall bağlantılara. Bu fark politika yazmayı kolaylaştırır ama asimetrik yönlendirme, zaman aşımı ve tablo kapasitesi gibi yeni arıza sınıfları getirir. Zone tabanlı model ise politikayı arayüz karmaşasından kurtarıp güven ilişkileri üzerine kurar. İyi bir politika setinin ölçüsü kural sayısı değil; her kuralın neden orada olduğunun cevaplanabilmesidir.

Zone’ları belirledikten sonraki adım, bu zone’ları doğru sınırlarla çizmek. Bunu ağ segmentasyonu ve DMZ yazısında ele aldık.

Kaynaklar

• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy
• Huawei: Checking the Security Policy Configuration (firewall arıza giderme, zone çifti politikası ve zone öncelikleri)
• Cisco: Understand the Zone-Based Policy Firewall Design
• Cisco Secure Firewall: Security Zones and Interface Groups
• Fortinet: FortiGate Administration Guide, Zone
• HPE Aruba Networking: Configure Roles and Policies on APs for User Access Control