FortiGate Firewall Policy Yapılandırması: Kural Seti

FortiGate Firewall policy yapılandırması, hangi bölgeden hangi bölgeye hangi trafiğin geçeceğini kural kural yazmaktır. Fortinet’in kendi en iyi uygulama kılavuzunun ve NIST’in tarif ettiği düzende kural seti varsayılan retle başlar ve dar kurallar listenin üstünde durur.

İzin yalnız gereken trafiğe, belirli arayüzler arasında ve gereken servisle verilir; her kuralın benzersiz bir adı ve açıklaması olur. Kurallar Policy & Objects → Firewall Policy ekranında yazılır.

Bu yazı FortiGate Firewall yapılandırma rehberimizin 14. adımıdır. Çalışan bir cihaza tek kural eklemeyi FortiGate kullanım rehberimizde anlattık; burada lab’ın kural setini erişim matrisinden yeniden kuruyorum. İki bulgu beklenenden farklı çıktı. Yeni yazılan bir ret kuralı genel iznin altına düşünce hiç çalışmadı; üste alınınca çalıştı, ama fabrika ayarında logda tek satır bırakmadı.

Örnekteki sınır kapısında aynı şeritte art arda iki kol durabilir: önde özel bir kontrol, arkada ana kapı. Özel kontrol ana kapının arkasına konursa, ana kapıdan geçirilen araç ona hiç ulaşmaz. FortiGate’te şerit arayüz çifti, öndeki kol dar kural, arkadaki kol genel izin kuralı, şeridin sonundaki duvar da örtük rettir.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde bir firewall’un kural setini kurarken izlediğimiz sırayı anlatır.

FortiGate Kuralı Nasıl Seçer? Sıra Neden Sonucu Değiştirir?

FortiGate kural listesini yukarıdan aşağı okur, trafiğe uyan ilk kuralda durur ve onun eylemini uygular. Lab’da iki kural aynı trafiği kapsıyor: kural 5 iç bölümlerin internete çıkışına izin veriyor, kural 8 iç bölümlerdeki yazıcıların (g-yazicilar) çıkışını reddediyor. Kural 8’i, arayüzden açılan yeni bir kuralın düştüğü yere, kural 5’in altına aldım. Trafik göndermeden hangi kuralın eşleşeceğini FortiGate’e sordum:

<src [10.34.70.50-40000] dst [198.18.0.1-80] proto tcp dev muhasebe> matches policy id: 5
<src [10.34.70.10-40000] dst [198.18.0.1-80] proto tcp dev muhasebe> matches policy id: 5

Satırlar sırayla şunu söylüyor:

1. Yazıcı (10.34.70.50) ret kuralına değil, genel izne takılıyor.
2. Aynı VLAN’daki bilgisayar (10.34.70.10) da genel izne takılıyor; bu beklenen sonuç.

Yazıcıdan internetteki bir web sunucusuna gerçek bir istek gönderdim ve paketin yolunu izledim:

... msg="vd-root:0 received a packet(proto=6, 10.34.70.50:44446->198.18.0.1:80) tun_id=0.0.0.0 from muhasebe. flag [S], seq 647323689, ack 0, win 64240"
... msg="find a route: flag=04000000 gw-203.0.113.80 via port3"
... msg="Allowed by Policy-5: SNAT"

İstek 200 ile döndü. Ret kuralı doğru yazılmış, ama hiç çalışmıyor. Kural setinde bu yüzden yalnız hangi kuralların bulunduğu değil, hangi sırada durdukları da sonucu belirler.

FortiGate’te Kural Seti Nasıl Olmalı?

Kural seti varsayılan retle başlar ve erişim matrisinin her satırı tek bir kurala dönüşür. İzin kuralı belirli arayüzler arasında, gereken adres ve servisle yazılır; dar kurallar üstte, genel izinler altta durur. Her kuralın benzersiz bir adı ve neden yazıldığını söyleyen bir açıklaması olur, kullanılmayan kural listede kalmaz.

Bu düzeni üç kaynak birlikte tarif ediyor:

1. Fortinet FortiOS 7.0 Best Practices, Policies sayfası: en belirgin kurallar listenin en üstüne konur ve en az yetki ilkesine uyulur. Aynı sayfa izin kurallarının any arayüze değil belirli arayüze yazılmasını, all ve any nesnelerinin yalnız internete giden kurallarda kullanılmasını ister. Bir de şunu: her kuralın kendine özgü bir adı olmalı ve kullanılmayan kural bulunmamalı.
2. NIST SP 800-41 Rev. 1 (Eylül 2009), bölüm 4: firewall, policy’nin açıkça izin vermediği gelen ve giden bütün trafiği engeller. NIST buna varsayılan olarak reddetme (deny by default) der. Bölüm 5.2.2 kural setinin olabildiğince belirgin olmasını ve her kurala açıklama yazılmasını ister.
3. NSA Network Infrastructure Security Guidance (Mart 2022, sürüm 1.0), bölüm 2.4: kurallar yalnız gereken servislere ve sistemlere açıkça izin verir ve geri kalan her şeyi reddeder. Bölüm 7.4 ret satırını açıkça yazmayı ister, böylece reddedilen denemeler loglanır.

Kural setinde dört tür satır var:

Tablonun üçüncü sütunu, ret kuralının ne zaman yazıldığını açıklıyor; kapalı kalacak bir yön için kural yazılmaz.

Kaç Kural Olmalı?

Fortinet de NIST de bir sayı vermiyor. İlkenin pratik karşılığı: erişim matrisinin her açık hücresi bir kural, her kapalı hücresi yazılmayan bir kuraldır. Matriste karşılığı olmayan kural ya bir istisnadır ya da artık kullanılmayan bir kayıt.

Kullanılmayan kuralı bulmanın yolu kuralın istatistiğidir. Kural formunun sağındaki Statistics paneli, kuralın son ne zaman eşleştiğini (Last used) ve kaç kez eşleştiğini (Hit count) gösteriyor. Lab’daki kural 5 için 38 saniye ve 71 eşleşme yazıyordu. Aylarca eşleşmeyen bir kural, Fortinet’in kullanılmayan kural (unused policy) dediği kuraldır ve gözden geçirmede silinir ya da neden durduğu açıklamasına yazılır.

Ne Zaman Ret Kuralı Yazılır?

Açık ret kuralı iki durumda yazılır:

1. Genel bir iznin içinden bir alt küme çıkarılacaksa: kural 8, kural 5’in izin verdiği iç bölümlerin içinden yazıcıları çıkarıyor. Kesmek istediği iznin üstünde durur.
2. Sanal IP’li bir izni geçersiz kılmak gerekiyorsa: sanal IP taşıyan kurallar sıradan önce gelir; ret kuralı onları ancak match-vip ile yakalar. Bunu WAN ayarı yazımızda ölçtük.

Kapalı kalacak bir yön için ret kuralı yazılmaz. Fortinet’in kılavuzu açıkça örtük ret kuralının (implicit deny) geçersiz kılınmamasını istiyor. Listenin sonundaki örtük ret o yönü zaten reddeder. Örtük retin logunu log ayarları yazımızda açtık.

Erişim Matrisinden Kural Setine

Kural seti ekranda değil, kâğıtta başlar. Ağ segmentasyonu yazımızdaki erişim matrisi hangi bölümün hangisine ulaşacağını söyler. Lab’ın matrisi, önceki adımlarda kurulan zone’lar ve adres nesneleri üzerine şöyle kuruldu:

Matrisi lab’daki kurallarla yan yana koyunca üç satır kendi kuralına uymuyordu:

1. Dışarıya açılan web sunucusu personel ağındaydı. Sanal IP 203.0.113.10, personeldeki 10.34.30.20’ye açılıyordu; zone yazısının kuralı ise dışarıdan erişilen sunucuyu DMZ’ye koyar. Sanal IP’yi DMZ’deki 10.34.80.10’a çevirdim, adını v-dmz-web yaptım ve kural 3’ün hedef arayüzünü dmz yaptım. Dışarıdan aynı adrese gelen istek önce ic web sunucusu, değişiklikten sonra dmz web sunucusu yazan sayfayı aldı.
2. İki genel izin ALL taşıyordu. Kural 1 ve 5, internete her servisi açıyordu; kullanıcıların ihtiyacı web ve sorun giderme için ping. İkisini HTTP, HTTPS ve PING’e daralttım; ölçümü aşağıda.
3. Dört kuralın açıklaması boştu. Her kurala ne yaptığını, kimin istediğini ve tarihini yazdım (NIST 5.2.2, NSA 3.1).

Kural 3’ün yeni hâli formda (Policy & Objects → Firewall Policy, kurala çift tıklanır):

1. Incoming Interface: dış hatlar (dis-hatlar). Outgoing Interface: dmz, çünkü sanal IP’nin açıldığı sunucu artık DMZ’de.
2. Destination: sanal IP’nin kendisi, v-dmz-web. Kuralın hedefinde sunucunun iç adresi değil sanal IP durur; FortiGate dışarıdan gelen paketi bu nesneyle eşleştirip iç adrese çevirir.
3. Service: yalnız HTTP.
4. NAT: kapalı. Dışarıdan gelen isteğin kaynağı değiştirilmez, sunucunun logu internetteki istemciyi görür.

config firewall policy
    edit 3
        set name "Disaridan DMZ web sunucusuna"
        set srcintf "dis-hatlar"
        set dstintf "dmz"
        set action accept
        set srcaddr "all"
        set dstaddr "v-dmz-web"
        set schedule "always"
        set service "HTTP"
    next
end

Sunucu ağına giden kurallar (iç DNS, Active Directory) bu matriste yok: lab’da sunucu ağı firewall’un yönetim tarafında duruyor. Gerçek bir kurulumda sunucular kendi VLAN’ında olur ve bu satırlar matrise eklenir.

Genel İzni Daraltmak: ALL Yerine Gereken Servisler

Daraltmadan önce iç bölümlerdeki bir bilgisayarın internetteki bir sunucuya SSH portundan (TCP 22) bağlanması kural 5’e takılıyordu. Kuralların servisini değiştirip aynı sorguyu tekrarladım:

<src [10.34.70.10-40000] dst [198.18.0.1-22] proto tcp dev muhasebe> matches policy id: 0
<src [10.34.70.10-40000] dst [198.18.0.1-443] proto tcp dev muhasebe> matches policy id: 5

SSH artık hiçbir izne uymuyor ve örtük rete (policy id: 0) düşüyor; HTTPS kural 5’ten geçiyor. Gerçek bir bağlantı denemesi de aynı yere düştü:

... msg="vd-root:0 received a packet(proto=6, 10.34.70.10:48574->198.18.0.1:22) tun_id=0.0.0.0 from muhasebe. flag [S], seq 2407984992, ack 0, win 64240"
... msg="Denied by forward policy check (policy 0)"

Aynı bilgisayardan web isteği 200 döndü ve ping geçti. Lab’daki bütün bölümleri, misafir ve dışarıdan sanal IP dahil, değişiklikten sonra yeniden denedim; beklenen her yol açık, beklenen her yol kapalı kaldı.

FortiGate’te Kural Yazmak: Form Alanları

Bu adımdan önce hazır olması gerekenler:

1. Arayüzler ve zone’lar: ic-bolumler (muhasebe ve depo), dis-hatlar (iki internet hattı). Kurulumları zone yazısında ve statik rota yazısında.
2. Adres ve servis nesneleri: kurala adres değil nesne adı yazılır; adres nesneleri yazısında açtık.
3. Erişim matrisi: yukarıdaki tablo.

Menü yolu: Policy & Objects → Firewall Policy → Create New; var olan kural satırına çift tıklanarak düzenlenir. Kural 5’in formundaki alanlar:

1. Name: benzersiz ve ne yaptığını söyleyen bir ad. Lab’da Ic bolumler dis aga.
2. Incoming Interface ve Outgoing Interface: belirli arayüz ya da zone, any değil. Lab’da ic-bolumler ve dis-hatlar.
3. Source ve Destination: nesne adları. İnternete giden kuralda hedef all olabilir; Fortinet’in kılavuzu all’a yalnız bu durumda izin veriyor.
4. Service: gereken servisler. Lab’da HTTP, HTTPS ve PING.
5. Action: ACCEPT. Formun fabrika değeri de bu.
6. NAT: iç ağdan internete çıkan kuralda açık; fabrika ayarında açık geliyor. NAT’ın ayrıntısı bir sonraki adımın konusu.
7. Comments: ne yaptığı, kimin istediği, tarih. Lab’da Ic bolumler internet cikisi; yalniz web ve ping. Isteyen: BT, 2026-10-01.

Eylemi DENY yapınca form üç yerde değişiyor:

1. NAT, güvenlik profilleri ve izin logu alanları kayboluyor.
2. Log için tek bir anahtar kalıyor: Log Violation Traffic.
3. Bu anahtar kapalı geliyor.

Lab’da yazıcıların internete çıkmasını kesen kural 8 bu formla yazıldı:

1. Name: Yazicilar internete cikmasin.
2. Incoming Interface: ic-bolumler, Outgoing Interface: dis-hatlar.
3. Source: yazıcıların grubu, g-yazicilar. Gruba yeni bir yazıcı eklenince kural onu da kendiliğinden kapsar.
4. Service: ALL. Ret kuralında her servisi kapsamak doğru, çünkü amaç yazıcının dışarıya hiçbir yoldan çıkmaması.
5. Action: DENY.
6. Log Violation Traffic: açık. Yazıcının dışarı çıkma denemesi loga düşer.

Kural 8’in komut satırındaki karşılığı:

config firewall policy
    edit 8
        set name "Yazicilar internete cikmasin"
        set srcintf "ic-bolumler"
        set dstintf "dis-hatlar"
        set srcaddr "g-yazicilar"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set comments "Yazicilar internete cikmaz; ret logu acik. Isteyen: BT, 2026-10-01"
    next
end

Bu blokta set action satırı yok. Kısa show çıktısı fabrika değerlerini göstermiyor ve CLI’da eylemin fabrika değeri deny; izin kurallarında set action accept satırı görünüyor. Arayüzde izin, CLI’da ret fabrika değeri. CLI’dan izin kuralı yazarken set action accept satırı unutulursa kural ret olarak kaydedilir.

İlk Eşleşme: Paket Listede İlk Uyduğu Kuralda Durur

Bir bankada sıra numarası aldığınızı düşünün: ilk boşalan veznede işiniz görülür ve bankadan çıkarsınız. Arkadaki veznelere hiç uğramazsınız; orada sizin için daha uygun bir görevli olsa bile.

Bu sahneyi sınır kapısının dört parçası taşıyor:

1. Arayüz çifti tek bir şerittir. Kaynak ve hedef arayüzü aynı olan kurallar aynı şeritte art arda durur.
2. Kural şeritteki bir koldur. Kendi aracını, yani kaynağı, hedefi ve servisi tutan trafiği ya geçirir ya durdurur; tutmayan araç bir sonraki kola ilerler.
3. Sıra kolların şeritteki dizilişidir.
4. Örtük ret şeridin sonundaki duvardır. Hiçbir kola uymayan araç orada durur.

Örnekteki sınır kapısında ana kapının kolu her aracı geçirecek şekilde ayarlanmışsa, onun arkasına konan özel kontrol hiç araç görmez. Mekanizma şöyle işliyor:

1. Paket gelir; FortiGate kaynak ve hedef arayüzünü bulur.
2. O arayüz çiftindeki kuralları yukarıdan aşağı okur.
3. Kaynağı, hedefi, servisi ve zamanı tutan ilk kuralda durur ve onun eylemini uygular.
4. Hiçbiri tutmazsa örtük reddi (policy 0) uygular.

Kazanç ve bedel aynı mekanizmadan geliyor. Kazanç: genel izin bir kez yazılır, istisnalar onun üstüne eklenir. Bedel: arayüzden açılan yeni kural listenin sonuna eklenir; bunu kullanım rehberinde ölçtük. Sona eklenen bir ret kuralı, üstündeki genel iznin gölgesinde kalır ve hata vermeden hiç çalışmaz.

1. Adım: Hangi Kuralın Eşleşeceğini Sorun

FortiGate’e trafik göndermeden hangi kuralın eşleşeceğini sormanın iki yolu var. Arayüzde Firewall Policy ekranındaki Policy Lookup düğmesi; CLI’da şu komut:

diagnose firewall iprope lookup 10.34.70.50 40000 198.18.0.1 80 tcp muhasebe

Komutun parçaları:

1. 10.34.70.50 40000: kaynak adres ve kaynak port. Kaynak port gerçek trafikte rastgeledir; sorgu için herhangi bir sayı yazılır.
2. 198.18.0.1 80: hedef adres ve port.
3. tcp: protokol.
4. muhasebe: paketin geldiği arayüz. Zone değil, zone’a üye arayüz yazılır.

Kural 8 alttayken cevap, yazının başındaki ölçümde görülen matches policy id: 5 idi.

2. Adım: Dar Kuralı Üste Taşıyın

Kural 8’i kural 5’in önüne aldım ve sorguyu tekrarladım:

config firewall policy
    move 8 before 5
end

<src [10.34.70.50-40000] dst [198.18.0.1-80] proto tcp dev muhasebe> matches policy id: 8
<src [10.34.70.10-40000] dst [198.18.0.1-80] proto tcp dev muhasebe> matches policy id: 5

Yazıcı artık ret kuralına, aynı VLAN’daki bilgisayar genel izne takılıyor. Arayüzde aynı işi kural satırını sürükleyip bırakmak yapıyor. Listenin son hâli:

3. Adım: Gerçek Trafikle Doğrulayın

Sorgu bir tahmindir; doğrulama gerçek pakettir. Yazıcıdan aynı web isteğini yeniden gönderdim:

... msg="vd-root:0 received a packet(proto=6, 10.34.70.50:53078->198.18.0.1:80) tun_id=0.0.0.0 from muhasebe. flag [S], seq 1528623122, ack 0, win 64240"
... msg="Denied by forward policy check (policy 8)"

Paket kural 8’de durdu; istek cevapsız kaldı.

Sırayı Geri Almak

Sıra aynı komutla geri alınır: move 8 after 5 kural 8’i yeniden genel iznin arkasına koyar. Lab’da bu durumu yukarıdaki ilk ölçüm için bu komutla kurmuştum. Kol ana kapının arkasına geri alınınca araç yine ana kapıdan geçer.

FortiGate Ret Kuralının Logu: Fabrika Ayarında Kapalı

Ret kuralının değerinin yarısı, neyin denendiğini göstermesidir. NSA’nın 7.4 bölümü ret satırını bu yüzden açıkça yazdırıyor: reddedilen denemeler loglansın diye.

Ret Çalışıyor, Log Boş

Kural 8’in log anahtarını fabrika ayarına, kapalıya (set logtraffic disable) aldım ve yazıcının isteğini gönderdim. Paket Denied by forward policy check (policy 8) ile reddedildi. Sonra trafik logunda yazıcının adresini aradım:

gmfw01 # execute log filter category traffic
gmfw01 # execute log filter field srcip 10.34.70.50
gmfw01 # execute log display
0 logs found.
0 logs returned.

Ret çalışıyor, ama logda tek kayıt yok. Anahtarı açıp (set logtraffic all, arayüzde Log Violation Traffic) aynı isteği gönderdim ve aynı aramayı yaptım:

3 logs found.
3 logs returned.
...
1: date=2026-10-01 time=15:44:49 ... srcip=10.34.70.50 srcport=58728 srcintf="muhasebe" ... dstip=198.18.0.1 dstport=80 dstintf="port3" ... action="deny" policyid=8 ... policyname="Yazicilar internete cikmasin" service="HTTP" ...

Aynı arama bu kez üç kayıt buldu: yazıcının işletim sistemi bağlantıyı üç kez denedi ve FortiGate her denemeyi kuralın adıyla kaydetti. Teşhis sırası şöyle:

1. Ret kuralının çalıştığı debug çıktısındaki Denied by forward policy check (policy N) satırıyla doğrulanır.
2. Logda kayıt yoksa önce kuralın Log Violation Traffic anahtarına bakılır; fabrika ayarında kapalıdır.
3. Örtük retin logu ayrı bir ayardır; log ayarları yazımızda açtık.

Logu kapalı ret kuralı engeller ama bir şey göstermez. Bu yüzden kendi yazdığımız her ret kuralında logu açıyoruz.

FortiGate’te Zamanlı Kural: Schedule

Kuralların hepsi Schedule alanında always taşıyor. Bir kural yalnız belirli saatlerde geçerli olacaksa ona bir zaman çizelgesi verilir; örneğin bakım penceresinde açılan bir erişim. Gece 01:00 ile 02:00 arasını kapsayan bir çizelge açtım ve DMZ web kuralına (6) verdim:

config firewall schedule recurring
    edit "gece-bakim"
        set start 01:00
        set end 02:00
        set day sunday monday tuesday wednesday thursday friday saturday
    next
end

Saat 15:46’da muhasebedeki bilgisayardan DMZ’deki web sunucusuna istek gönderdim:

... msg="vd-root:0 received a packet(proto=6, 10.34.70.10:43006->10.34.80.10:80) tun_id=0.0.0.0 from muhasebe. flag [S], seq 3033162463, ack 0, win 64240"
... msg="Denied by forward policy check (policy 0)"

İstek kural 6’ya hiç takılmadı; çizelgenin dışında kalan kural yokmuş gibi atlandı ve paket örtük retle düştü. Zamanlı bir kuralın altında aynı trafiği kapsayan başka bir izin varsa, çizelge dışındaki saatlerde trafik o izinden geçer; zamanlı bir kısıtlama tasarlarken altındaki kurallara da bakılır. Ölçümden sonra kuralı always’e geri aldım ve çizelgeyi sildim; istek yeniden 200 döndü.

Doğrulama: FortiGate’in Kural Seti Doğru mu?

1. Her kural erişim matrisinin bir satırına karşılık geliyor; kapalı yönler için kural yok.
2. Her ret kuralı, kestiği iznin üstünde: Policy Lookup ret kuralının numarasını veriyor.
3. İzin kuralları belirli arayüzler arasında ve all yalnız internete giden kurallarda.
4. Genel izinlerde servis sayılı; lab’da internete web ve ping.
5. Her kuralın benzersiz adı ve açıklaması var; açıklama kimin istediğini ve tarihi söylüyor.
6. Ret kurallarında log açık; trafik logunda kuralın adıyla kayıt görünüyor.
7. Uzun süre eşleşmeyen kural yok; Statistics panelinde Last used ve Hit count okunuyor.

Sonuç: FortiGate Kural Setinde Sıra Tasarımın Kendisidir

FortiGate kural setini ekranda değil erişim matrisinde başlatın: her açık hücre bir kural, her kapalı hücre yazılmayan bir kuraldır. Fortinet’in, NIST’in ve NSA’nın kesiştiği yerde dar kurallar genel izinlerin üstünde durur ve izinler yalnız gereken servisi açar. Lab’da dört şey beklenenden farklı çıktı:

1. Sona eklenen ret kuralı genel iznin gölgesinde kaldı; yazıcının isteği Allowed by Policy-5 ile internete çıktı.
2. Üste alınan ret kuralı çalıştı ama fabrika ayarında logda tek kayıt bırakmadı.
3. CLI’da eylemin fabrika değeri ret; arayüzde izin.
4. Zamanlı kural çizelgesinin dışında yok sayıldı ve trafik örtük rete düştü.

Örnekteki sınır kapısında özel kontrol ana kapının önünde durur ve durdurduğu her aracı deftere yazar. Ana kapının arkasına konan kontrol, ne kadar doğru kurulmuş olursa olsun, araç görmez.

Kural setinde çıkışta adres çevirisi yapan NAT’ı FortiGate Firewall NAT ayarı yazımızda anlattık. Açılış listesinin kalanı 20 adımlık kontrol listesinde duruyor.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn