Bu makalede7 bölüm
- Teknoloji
- NGFW, güvenlik politikası, hit count, FortiOS, PAN-OS, Cisco ASA
- Konu
- Biriken firewall kural setinin denetimi ve güvenli temizliği
- Seviye
- Orta–ileri
- Ön koşullar
- Firewall yönetim arayüzüne okuma erişimi
- Trafik loglarının en az birkaç aylık geçmişi
- Değişiklik yönetimi süreci
Firewall’a yıllardır kural ekleniyor, silinen yok. Yüzlerce satır var ve hangisinin hâlâ bir iş ihtiyacını karşıladığını bilen kimse yok. Bu noktada temizliği tahminle yapmak iki sonuç doğurur: ya bir uygulama durur ya da kimse dokunmaya cesaret edemez. Aşağıda gölgelenmiş, atıl, yinelenen ve aşırı geniş kuralları veriyle nasıl bulacağınızı, hangi sırayla ve hangi geri dönüş güvencesiyle kaldıracağınızı adım adım anlatıyoruz.
Kural seti neden şişer, bedeli ne olur
Sebepler hemen her kurumda aynıdır. Proje için açılan geçici erişim kapatılmaz. Sunucu taşınır, eski IP’ye yazılmış kural yerinde kalır. Arıza gecesi “önce çalışsın” diye açılan geniş kural kalıcı olur. Uygulama devreden çıkar ama kuralları kimsenin sorumluluğunda olmadığı için silinmez. Değişiklik taleplerine bakın: hep “ekle” vardır, “kaldır” neredeyse hiç gelmez.
Bu birikimin bedeli somuttur:
- Saldırı yüzeyi büyür. Kapanan sunucunun IP’si başka bir sisteme verildiğinde eski izin kuralı yeni sisteme kimsenin istemediği bir yol açar. Sahada en sık karşılaştığımız sürpriz budur.
- Denetimde bulgu çıkar. Neden var olduğu açıklanamayan kural, konfigürasyon denetiminde doğrudan bulgu olur; yeni bir değişikliğin etkisini öngörmek de zorlaşır.
- Sorun giderme yanlış yere gider. Yeni yazılan kural, üstündeki geniş bir kural yüzünden hiç eşleşmez; ekip saatlerce yanlış satıra bakar.
- Yönetim yavaşlar. Modern NGFW’ler eşleştirmeyi optimize etse de çok büyük ve nesne yoğun politikalar derleme süresini, yönetim arayüzünün yanıtını ve HA senkronizasyonunu uzatır.
Gölge, atıl, yinelenen ve aşırı geniş kuralları ayırmak
Silmeye başlamadan önce her kuralı bir kategoriye koyun. Kategori, hangi analizin yapılacağını ve kaldırmanın ne kadar riskli olduğunu belirler.
| Kural türü | Tanım | Tespit yöntemi | Kaldırma riski |
|---|---|---|---|
| Gölgelenmiş (shadowed) | Üstteki bir kural aynı trafiği önce yakalar | Politika analiz aracı, kapsam karşılaştırması | Düşük; kural zaten hiç eşleşmez |
| Atıl (unused) | Ölçüm penceresinde hiç eşleşmemiş | Hit count, son kullanım tarihi | Orta; yıllık işler gözden kaçabilir |
| Yinelenen / birleştirilebilir | Aynı amaçla yazılmış benzer kurallar | Kaynak-hedef-servis karşılaştırması | Düşük–orta |
| Aşırı geniş | any kaynak/hedef/servis veya geniş alt ağ | Log ile gerçek trafik profili çıkarma | Yüksek; daraltma yanlış yapılırsa kesinti |
| Süresi dolmuş geçici | Belirli bir proje veya tarih için açılmış | Kural açıklaması, talep kaydı | Düşük; sahibi teyit ederse |
Gölgeleme bir mantık hatasıdır. Kurallar yukarıdan aşağıya okunur ve ilk eşleşen uygulanır. Kaynağı 10.10.0.0/16, servisi any olan bir izin kuralı, altında 10.10.5.0/24 için yazılmış daha dar kuralı tamamen etkisiz bırakır. Ters durum daha tehlikelidir: Alttaki bir “deny” kuralı, üstteki geniş izin yüzünden hiç devreye girmez ve ekip korunduğunu sanır. Kâğıt üstünde engel var. Trafikte yok. Çoğu üreticinin yönetim aracında veya ayrı politika analiz yazılımlarında gölgeleme raporu bulunur; yoksa kuralları kaynak, hedef, servis ve uygulama alanlarıyla dışa aktarıp kapsam karşılaştırması yapmanız gerekir.
Aşırı geniş kurallar en çok riski taşır ama silinemez, yalnız daraltılabilir. “DMZ’den iç ağa any” gibi bir kural, gerçekte çoğunlukla birkaç sunucu ve birkaç port için kullanılıyordur. Bunu kanıtlamanın tek yolu log verisidir.
Hit count ve log verisiyle kullanım analizi
Hit count bir kuralın kaç kez eşleştiğini, son kullanım tarihi (last hit) ise en son ne zaman eşleştiğini gösterir. Rakama güvenmeden önce üç şeyi kontrol edin:
- Sayaç ne zamandan beri sayıyor? Bazı platformlarda yeniden başlatma, firmware yükseltmesi, HA failover veya sayaçların elle temizlenmesi hit count değerlerini sıfırlar. “0 eşleşme” ancak sayacın başlangıç tarihi biliniyorsa bir şey ifade eder.
- Pencere yeterince uzun mu? Ay sonu kapanışı, yıllık denetim, yedek veri merkezine geçiş testi veya sezonluk uygulamalar kısa bir pencerede görünmez. En az 90 gün, kritik ortamlarda bir yıllık log geçmişi tercih edilir.
- Kümenin her üyesine baktınız mı? Aktif-aktif kümelerde veya birden fazla firewall’a dağıtılmış politikalarda sayaçlar cihaz başına tutulabilir. Tek cihazdaki sıfır, kuralın kullanılmadığı anlamına gelmez.
Veriye erişim üreticiye göre değişir. Fortinet FortiGate’te politika listesindeki “Hit Count”, “Bytes” ve “Last Used” sütunları bu bilgiyi verir. Palo Alto Networks PAN-OS’ta Policy Optimizer kullanılmayan kuralları listeler; CLI karşılığı aşağıdadır. Cisco ASA’da her ACE için hitcnt değeri görülür.
# Palo Alto PAN-OS: tüm güvenlik kurallarının eşleşme sayıları
show rule-hit-count vsys vsys-name vsys1 rule-base security rules all
# Cisco ASA: hiç eşleşmemiş erişim listesi satırları
show access-list | include hitcnt=0
Aşırı geniş bir kuralı daraltmak için hit count yetmez; kuralın hangi kaynak, hedef ve servis kombinasyonlarıyla eşleştiğini görmeniz gerekir. İlgili kuralda oturum sonu loglamasını açın, logları SIEM’e veya log yöneticisine aktarın, kural kimliğine göre gruplayıp tekil kaynak–hedef–port üçlülerini çıkarın. Ortaya çıkan liste, geniş kuralın yerine yazılacak dar kuralların taslağıdır. Aynı loglardan tespit üretme tarafı firewall loglarından tehdit tespiti rehberinde ayrıca ele alınıyor.
Güvenli temizlik akışı: devre dışı bırak, izle, sil
Kuralı doğrudan silmek geri dönüşü zorlaştırır: Sırası, nesneleri, açıklaması ve profil bağlantıları kaybolur. Bir uygulama gece yarısı durduğunda o kuralı hafızadan yeniden yazmaya çalışmak istemezsiniz. Akış şu sırayla işler:
- Yedek ve aday listesi. Değişiklikten önce tam konfigürasyon yedeği alınır. Aday kurallar sahipleriyle paylaşılır, itiraz süresi tanımlanır (örneğin iki hafta).
- Devre dışı bırakma. Aday kurallar silinmez, devre dışı bırakılır; açıklama alanına tarih ve değişiklik kaydı numarası yazılır. Etki alanını sınırlamak için değişiklik gruplar halinde ve bakım penceresinde yapılır.
- İzleme. Devre dışı kuralın altında kalan varsayılan “deny” kuralında veya açıkça yazılmış bir “deny + log” kuralında beklenmeyen engellemeler izlenir. Yardım masasına gelen erişim şikâyetleri değişiklik kaydıyla eşleştirilir.
- Silme. İzleme süresi (tipik olarak 30–90 gün) sorunsuz geçtiyse kural ve artık hiçbir yerde kullanılmayan adres/servis nesneleri silinir.
FortiOS’ta kuralı devre dışı bırakıp gerekçesini kuralın üzerinde bırakmak için:
config firewall policy
edit 87
set status disable
set comments "CHG-2026-0412: atil kural, 2026-11-10 devre disi, 2027-01-10 silinecek"
next
end
PAN-OS’ta aynı işlem kuralın “Disable Rule” seçeneğiyle veya konfigürasyon modunda set rulebase security rules <kural-adı> disabled yes ile yapılır ve commit gerektirir; çoklu vsys kullanan cihazlarda yol set vsys vsys1 rulebase security rules <kural-adı> disabled yes biçimindedir.
Kural sahipliği ve son kullanma tarihi standardı
Temizlik bir kez yapılınca iş bitmez. Süreç yoksa aynı birikim iki yıl içinde geri gelir. Kalıcı çözüm, her kuralın üzerinde taşıması gereken asgari bilgiyi standart hale getirmektir:
- Sahip: Mümkünse kişi değil, rol veya ekip (“ERP uygulama ekibi”). Kişi ayrıldığında kural sahipsiz kalmaz.
- İş gerekçesi ve talep numarası: Kuralın neden var olduğunu anlatan kısa metin ve değişiklik kaydına bağlantı.
- Son kullanma tarihi: Geçici erişimlerde zorunlu; kalıcı kurallarda bir sonraki gözden geçirme tarihi olarak kullanılır.
- Adlandırma kuralı: Kaynak bölge, hedef bölge ve amaç kural adından okunabilmeli.
Bazı platformlar zamanlamaya bağlı politikaları destekler. FortiGate’te tek seferlik bir zamanlama nesnesi (schedule) kurala bağlandığında kural bitiş tarihinden sonra eşleşmez; geçici tedarikçi erişimleri için kullanışlıdır. Ancak süresi geçmiş kural listede kalmaya devam eder ve periyodik gözden geçirmede silinmelidir. Yeni kurulumlarda bu standardı baştan oturtmak için FortiGate kurulumunda kritik kontroller yazısındaki politika tasarımı adımlarına bakabilirsiniz.
Periyodik kural gözden geçirme kontrol listesi
NIST SP 800-41 Rev. 1, firewall politikalarının düzenli olarak gözden geçirilmesini ve politika yönetiminin bir süreç olarak işletilmesini önerir (NIST SP 800-41 Rev. 1). Çeyreklik veya altı aylık gözden geçirmede şu listeyi kullanın:
- Konfigürasyon yedeği alındı ve önceki gözden geçirmeden bu yana yapılan değişikliklerle karşılaştırıldı.
- Hit count sayaçlarının en son sıfırlandığı tarih kayda geçti.
- Ölçüm penceresinde eşleşmeyen kurallar listelendi ve sahiplerine gönderildi.
- Gölgelenmiş ve yinelenen kurallar raporlandı.
- Kaynak, hedef veya servis alanında any içeren izin kuralları tek tek gerekçelendirildi.
- Son kullanma tarihi geçmiş kurallar devre dışı bırakıldı.
- Sahibi veya açıklaması eksik kural kalmadı.
- Kullanılmayan adres ve servis nesneleri temizlendi.
- Devre dışı bırakılıp izleme süresini tamamlayan kurallar silindi.
- Yönetim arayüzüne erişim kuralları yalnız yönetim ağıyla sınırlı.
- Gözden geçirme sonucu ve alınan kararlar kayda geçti.
Kural setini yazan ekip kendi kör noktalarını göremez. Bağımsız bir göz burada işe yarar. Bu kapsamda siber güvenlik kontrol ve konfigürasyon denetimi ile kural tasarımı ve işletimini kapsayan firewall kural yönetimi birlikte planlanabilir. Cihaz seçimi aşamasındaysanız politika yönetimi araçlarının kalitesini kurumsal firewall seçim kriterleri arasına ekleyin; sonraki yılların temizlik yükü doğrudan buna bağlıdır.
Sık sorulan sorular
Hit count sıfır olan bir kuralı hemen silebilir miyim?
Hayır. Önce sayacın ne zamandan beri saydığını doğrulayın, ölçüm penceresinin yıllık ve dönemsel işleri kapsadığından emin olun, kural sahibine sorun. Kuralı silmeden önce devre dışı bırakıp bir izleme süresi uygulayın.
Gölgelenmiş kural ile atıl kural arasındaki fark nedir?
Gölgelenmiş kural, üstündeki daha geniş bir kural aynı trafiği önce yakaladığı için mantıksal olarak hiç eşleşemez. Atıl kural eşleşebilecek durumdadır ama ölçüm penceresinde ona uyan trafik gelmemiştir. İlki politika analiziyle, ikincisi kullanım verisiyle bulunur.
Kural temizliği ne sıklıkla yapılmalı?
Sabit bir sıklık yoktur; değişiklik yoğunluğuna göre çeyreklik veya altı aylık gözden geçirme yaygın bir yaklaşımdır. Kural sahipliği ve son kullanma tarihi standardı oturduğunda her döngü daha kısa sürer.
Any içeren bir kuralı nasıl güvenle daraltırım?
Kuralda oturum loglamasını açın, gerçek kaynak, hedef ve port kombinasyonlarını loglardan çıkarın, bunlar için dar kuralları geniş kuralın üstüne ekleyin. Geniş kuralın eşleşme sayısı sıfıra indikten sonra onu devre dışı bırakın.
- Teknoloji
- NGFW, güvenlik politikası, hit count, FortiOS, PAN-OS, Cisco ASA
- Konu
- Biriken firewall kural setinin denetimi ve güvenli temizliği
- Seviye
- Orta–ileri
- Ön koşullar
- Firewall yönetim arayüzüne okuma erişimi
- Trafik loglarının en az birkaç aylık geçmişi
- Değişiklik yönetimi süreci
Ağ ve Firewall