TR / EN

FortiGate’te Policy ID 0 Ne Anlama Gelir?

Güvenlik duvarı günlüğünde “policy id 0” görüldüğünde bunu bozuk bir kural numarası sanmak kolaydır. Çoğu IPv4 politika akışında mesaj daha basittir: paket, yönetici tarafından tanımlanmış izin politikalarından hiçbirine uymamış ve kural tabanının sonundaki görünmez ret davranışına ulaşmıştır. Asıl soru cihazın neden engellediği değil, beklediğimiz kuralın hangi eşleşme koşulunda kaçırıldığıdır.

21 Temmuz 2026 tarihli vakada belirli bir kaynaktan HTTPS servisine erişim reddediliyordu. Yeni ve geniş bir allow kuralı açmadan önce paketin giriş arayüzünü, rota nedeniyle seçilen çıkış arayüzünü, kaynak ve hedef objelerini, servis tanımını, zamanlamayı ve politika sırasını inceledik. Bu disiplin, hem sorunu dar bir değişiklikle çözdü hem de implicit deny’nin güvenlik tasarımındaki değerini korudu.

Sorunun ortaya çıkışı

Bir uygulama sunucusundan dışarıdaki izinli bir HTTPS uç noktasına bağlantı kurulamadı. Trafik günlüğünde kaynak ve hedef beklenen değerlere benziyor, eylem deny ve policy ID 0 görünüyordu. Ekip mevcut izin kuralında aynı servis adını gördüğü için FortiGate’in kuralı yanlış değerlendirdiğini düşündü. Oysa politika eşleşmesi yalnızca port adına değil tüm bağlama dayanır.

Değişiklik talebindeki kaynak bilgisi ile cihazın gördüğü kaynak adresi arasında NAT veya farklı çıkış yolu olasılığı vardı. Hedef adı birden fazla adrese çözülebiliyor, rota paketi tahmin edilenden farklı WAN arayüzüne çıkarabiliyordu. Önce tek bir kontrollü bağlantı zamanını ve beşli akışı belirledik. Böylece geçmişteki ilgisiz deny kayıtlarının analizimizi yönlendirmesini engelledik.

İlk belirtiler ve yanlış varsayımlar

En yaygın varsayım, kaynak ve hedef obje içinde adres bulunduğunda eşleşmenin garanti olduğudur. Politikanın giriş ve çıkış arayüzü, servis, kullanıcı/kimlik koşulu, schedule ve adres ailesi de uygun olmalıdır. Bir obje güncellenmiş fakat politika farklı VDOM’da veya farklı obje ile çalışıyor olabilir. Politika adı benzerliği teknik eşleşme kanıtı değildir.

İkinci yanlış yaklaşım, kuralı listenin en üstüne taşıyıp source ve destination alanlarını all yapmaktır. Bu işlem sorunu maskeleyebilir ama gereksiz erişim oluşturur. Route olmadığı durumda yeni politika da çözüm sağlamaz; local-in trafik ile forward trafik karıştırılırsa yanlış kural tabanına bakılır. Policy ID 0 sonucunu tek başına NAT hatası olarak yorumlamak da doğru değildir.

Teknik analiz

Analiz paket yönüyle başladı. Kaynak arayüz, hedef için routing tablosunun seçtiği çıkış arayüzü ve varsa SD-WAN kararı doğrulandı. Sonra policy lookup ile kaynak, hedef, protokol ve portun hangi politikaya düşmesi gerektiği kontrol edildi. Adres gruplarının gerçek üyeleri, FQDN objesinin güncel çözümü ve özel servis nesnesinin TCP/UDP tanımı incelendi. IPv4 ve IPv6 akışları ayrıldı.

Kontrollü debug flow yalnızca belirtilen kaynak, hedef ve kısa zaman aralığı için kullanıldı. Çıktıda route seçimi, policy lookup ve drop nedeni arandı; üretim cihazında sınırsız debug bırakılmadı. Donanım hızlandırma bazı mevcut oturumların çıktıda görünmesini etkileyebileceği için test yeni ve tek oturumla yapıldı. Gerekli kanıt alınınca debug hemen kapatıldı ve filtreler temizlendi.

Uygulanan çözüm veya önerilen mimari

Vakadaki izin politikası doğru kaynak objesini içeriyor fakat çıkış arayüzü eski WAN yolunu gösteriyordu. Rota değişikliğinden sonra trafik başka arayüzden çıktığı için politika eşleşmiyordu. Mevcut kuralın kapsamı, değişiklik kaydı ve ağ tasarımı doğrultusunda yeni çıkış yolu için güncellendi; kaynak, hedef ve HTTPS servisi dar bırakıldı. Yeni geniş kural oluşturulmadı.

Politika açıklamasına iş sahibi, talep referansı ve erişim amacı eklendi. Route ve politika değişikliklerinin birlikte değerlendirilmesi için kontrol adımı oluşturuldu. Doğrulamada izinli kaynak başarılı olurken başka bir test kaynağının implicit deny ile kalması beklendi ve doğrulandı. Böylece çözüm yalnızca pozitif testi değil güvenlik sınırının korunmasını da kanıtladı.

Alternatifler ve karar gerekçesi

Yeni bir politika eklemek mevcut kuralı değiştirmeden hızlı olabilirdi; ancak aynı iş akışı için iki kural sahiplik ve sıra karmaşası yaratacaktı. Arayüz çifti gerçekten kalıcı olarak değiştiği için mevcut kontrollü politikanın güncellenmesi daha anlaşılırdı. Multiple-interface politika veya zone kullanımı daha büyük tasarım değişikliği gerektiriyordu ve ayrı çalışma olarak bırakıldı.

Hedefi FQDN objesiyle yönetmek dinamik servislerde yararlı olabilir, fakat DNS güncelliği ve çoklu adresler ayrıca izlenmelidir. Sabit adres objesi daha öngörülebilir olsa da hizmet sağlayıcı adres değiştiriyorsa kırılgandır. Seçim hizmet sahibinin yayınladığı entegrasyon modeline göre yapılmalı; geçici olarak all hedefi açmak kalıcı çözüm sayılmamalıdır.

Güvenlik ve operasyonel riskler

Implicit deny kaldırılması gereken bir engel değil, açıkça izin verilmeyen trafiği durduran temel kontroldür. Sorun giderirken oluşturulan geçici kural süreli, kayıtlı ve otomatik kapanışlı değilse unutulabilir. Debug çıktısı gerçek adres, port ve politika adlarını içerir; destek kaydına veya genel kanala ham kopyalanmamalıdır. Yönetim erişimi ve VDOM bağlamı doğrulanmalıdır.

Politika değişikliği mevcut oturumlarda hemen görünmeyebilir; session tablosuna müdahale üretim bağlantılarını kesebilir. Yalnızca onaylı test akışı hedeflenmeli ve iş sahibiyle pencere belirlenmelidir. Kural sırası, gölge politikalar, hit count ve son kullanım bilgisi periyodik gözden geçirilmelidir. Başarılı erişim kadar gereksiz kaynakların reddedildiği de regresyon testine eklenmelidir.

Çıkarılan Dersler

Kontrol Listesi