FortiGate Firewall IPS Yapılandırması: Sensör ve İmzalar

FortiGate Firewall IPS (Intrusion Prevention System, saldırı önleme sistemi), kuraldan geçen trafiğin içinde bilinen bir saldırının izini arayan ve bulduğunda bağlantıyı durduran güvenlik profilidir. Saldırının izine imza denir. FortiGate’te imzalar bir sensörde toplanır, sensör de kurala bağlanır.

IPS bilinen saldırıyı tanır, bilinmeyeni tanımaz. NIST’in saldırı tespit ve önleme rehberi bunu açıkça yazıyor: imzaya dayalı tespit bilinen tehditlerde çok etkili, daha önce görülmemiş tehditlerde ve bilinenlerin değiştirilmiş biçimlerinde büyük ölçüde etkisiz. FortiGate’te bu yüzden iki soru öne çıkıyor: imzalar ne kadar güncel ve sensör hangi imzaya ne yaptırıyor?

Bu yazı FortiGate Firewall ileri seviye rehberimizin 4. adımıdır. Burada dışarıya açık bir web sunucusunun kuralına IPS bağlıyorum ve onu saldırı trafiği üretmeden, kendi yazdığım zararsız bir imzayla sınıyorum. Lab cihazımın FortiGuard aboneliği yok, IPS imzaları 1 Aralık 2015 tarihinde kalmış. Ölçümün dersi de buradan çıkıyor: eski imzalarla yeni bir saldırıyı sınamak bir şey göstermez, ama IPS’in nasıl karar verdiğini kendi imzanızla görebilirsiniz.

Lab’da üç şey beklenenden farklı çıktı:

1. Kendi imzamı engelle eylemiyle sensöre ekledim ve IPS onu yalnız logladı, istek sunucuya ulaştı. Sebebi sensördeki satırların sırasıydı.
2. Engelle (block) eylemi bağlantıyı kesmedi, istemciyi 10 saniye bekletti.
3. İmza büyük harfle ve adres kodlamasıyla yazılmış dizeyi de tanıdı.

Örnekteki sınır kapısında görevli tırın altına uzun saplı bir aynayla bakar. Nereye bakacağını elindeki el kitabından bilir: kaçakçıların bilinen saklama yerleri orada çizilidir. El kitabı 2015’te basılmışsa sonradan icat edilen saklama yerini tanımaz. FortiGate’te el kitabı imza veritabanı, ayna da IPS motorudur.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde dışarıya servis açan kurumların kurallarına IPS koyarken izlediğimiz sırayı anlatır.

FortiGate IPS Nasıl Olmalı?

IPS önce dışarıya açık servislerin kuralına bağlanır ve sensör korunan servise göre seçilir: web sunucusunun kuralına web sunucusu imzaları. İmzalar güncel tutulur. Engellenmesi gereken imza satırları filtrelerin üstünde durur ve logda gerçekten engellendiği görülür. Yanlış pozitifler ayıklanır, çünkü IPS kurulup bırakılan bir özellik değildir.

Bu düzeni dört kaynak birlikte tarif ediyor:

1. NIST SP 800-94 (Şubat 2007), saldırı tespit ve önleme sistemleri rehberi, bölüm 2.3.1: imzaya dayalı tespit bilinen tehditleri yakalamakta çok etkili, bilinmeyen tehditlerde, gizlenmiş saldırılarda ve bilinen tehditlerin birçok türevinde büyük ölçüde etkisizdir. Aynı rehberin bölüm özetine göre (bölüm 2.5) hiçbir sistem kusursuz tespit yapmaz: hepsi zararsız trafiği saldırı sanar (yanlış pozitif) ve bazı saldırıları kaçırır (yanlış negatif). Sistemi bu dengeye göre ayarlamaya ince ayar (tuning) denir.
2. Fortinet FortiOS 7.0 Best Practices, Security profiles: sınırdaki bir FortiGate için verdiği örnek tabloda IPS’e iki iş veriyor. Gelen trafikte dışarıya açık servisleri bilinen açık kullanımlarına ve protokol aykırılıklarına karşı korur. Giden trafikte botnet sitelerine giden bağlantıları engeller.
3. Fortinet FortiOS 7.0 yönetim kılavuzu, imzaya dayalı savunma sayfası: IPS motoru trafiği bütün imzalarla değil, sensörde seçilen imzalarla tarar. Sensör korunan trafiğe göre kurulur, örneğin web sunucusu imzaları web sunucusunun kuralına bağlanır. Filtreyle seçilen imzalara FortiGuard’ın sonradan eklediği uygun imzalar kendiliğinden katılır.
4. Fortinet Community, IPS imzalarının fabrika eylemi nasıl seçilir: her yeni imza fabrika eylemi geçir (pass) olarak yayımlanır, izlendikten sonra engelle (block) eylemine alınıp alınmayacağına karar verilir. Fortinet’e göre imzaların yüzde 90’ından fazlası engelle eylemiyle geliyor ve IPS her ortama göre ayarlanıp düzenli olarak ince ayar görmesi gereken bir özellik.

Kararlar:

FortiGate IPS Öncesi: İmza Veritabanı ve Hazır Sensörler

IPS’in neyi tanıyacağını imza veritabanı belirliyor, o yüzden önce onun tarihine baktım (diagnose autoupdate versions):

IPS Attack Engine
---------
Version: 7.00157
Contract Expiry Date: n/a
Last Updated using manual update on Thu Feb  9 19:45:00 2023
...
Attack Definitions
---------
Version: 6.00741
Contract Expiry Date: n/a
Last Updated using manual update on Tue Dec  1 02:30:00 2015

IPS motoru 2023 tarihli, saldırı imzaları (Attack Definitions) 1 Aralık 2015 tarihli. Motor imzaları okuyan program, imzalar el kitabının kendisi. Abonelik olmadığı için ikisi de kurulum imajında geldiği gibi kaldı.

Veritabanının neyi bildiğini saldırı trafiği göndermeden, imza listesinde arayarak gördüm:

gmfw01 # get ips rule status | grep -c rule-name
5864

gmfw01 # get ips rule status | grep -i -A6 "Bash.Function.Definitions"
rule-name: "Bash.Function.Definitions.Remote.Code.Execution"
rule-id: 39294
rev: 5.581
date: 1417680000
action: block
status: enable
log: disable

gmfw01 # get ips rule status | grep -i log4j

gmfw01 #

Veritabanında 5.864 imza var. Eylül 2014’te duyurulan Bash açığının (Shellshock) imzası duruyor, imzanın tarihi (1417680000) Aralık 2014’e denk geliyor. Aralık 2021’de duyurulan Log4j açığını aramak boş döndü. 2015’ten sonra bulunan açıklar için bu cihazın IPS’inde imza yok.

Aynı listede imzaların fabrika eylemleri de sayılabiliyor: 5.015 imza engelle (block), 849 imza geçir (pass) eylemiyle geliyor, yani yüzde 85,5’i engelle. Fortinet bugünkü veritabanı için bu oranın yüzde 90’ı aştığını söylüyor. 103 imza da fabrika ayarında kapalı. Arayüzde aynı liste Security Profiles → IPS Signatures ekranında, her imzanın hedefi (sunucu ya da istemci), işletim sistemi ve fabrika eylemiyle görünüyor:

Security Profiles → Intrusion Prevention ekranında fabrika ayarında dokuz sensör var. Açıklamalarıyla:

Dışarıya açık bir web sunucusu için doğru başlangıç protect_http_server. Komut satırındaki tam yapılandırması tek bir filtre satırı:

config ips sensor
    edit "protect_http_server"
        set comment "Protect against HTTP server-side vulnerabilities."
        ...
        config entries
            edit 1
                set location server 
                set severity all
                set protocol HTTP 
                set os all
                set application all
                set status default
                set log enable
                ...
                set action default

Filtre, hedefi sunucu (location server) ve protokolü HTTP olan bütün imzaları seçiyor ve her birine kendi fabrika eylemini (action default) uyguluyor. Yani bu sensörde fabrika eylemi geçir olan bir imza yalnız loglanır.

FortiGate IPS Sensörü Oluşturmak ve Kurala Bağlamak

Lab’da DMZ’deki web sunucusu dışarıya bir sanal IP ile açık: kural 3, internetten 203.0.113.10:80 adresine gelen HTTP’yi DMZ’deki 10.34.80.10 sunucusuna taşıyor. Bu kurulumu temel rehberin NAT adımında anlattık. IPS’i bu kurala bağlıyorum.

Fabrika sensörünü doğrudan kullanmak yerine kopyaladım ve kopyaya hangi sunucu için olduğunu yazdım. Arayüzde listedeki protect_http_server seçilip Clone (kopyala) düğmesine basılır. Komut satırında:

config ips sensor
    clone "protect_http_server" to "dmz-web-ips"
    edit "dmz-web-ips"
        set comment "DMZ web sunucusu: HTTP sunucu imzalari + lab test imzasi"
    next
end

Sensör kurala Policy & Objects → Firewall Policy → kural formundaki Security Profiles bölümünden, IPS alanından bağlanır. Lab’da sensörün yeri dışarıdan DMZ’deki web sunucusuna gelen kural (3):

1. Incoming Interface: dis-hatlar, Outgoing Interface: dmz, Destination: sanal IP v-dmz-web. Sensör yalnız dışarıya açılan sunucuya giden trafiği tarar.
2. Service: HTTP. Sensördeki imzalar da bu servise göre seçildi.
3. IPS: açık, dmz-web-ips.

config firewall policy
    edit 3
        set name "Disaridan DMZ web sunucusuna"
        set utm-status enable
        set ssl-ssh-profile "certificate-inspection"
        set ips-sensor "dmz-web-ips"
    next
end

Kural akış kipinde (flow-based). Akış ve proxy kipinin farkını FortiGate antivirüs yazımızda ölçtük.

FortiGate IPS’i Saldırı Trafiği Olmadan Sınamak: Özel İmza

Sensör bağlandı, ama gerçekten çalıştığını görmek için onu tetikleyen bir trafik gerekiyor. Gerçek bir saldırı aracı çalıştırmak yerine kendi imzamı yazdım. FortiGate özel imzaları Fortinet’in imza dilinde (F-SBID) yazılır. Fortinet’in özel imza örneğindeki anahtar sözcükleri kullandım:

config ips custom
    edit "SistemKusu.Lab.Test.Dizesi"
        set signature "F-SBID( --name \"SistemKusu.Lab.Test.Dizesi\"; --protocol tcp; --service HTTP; --flow from_client; --pattern \"sistemkusu-ips-deneme\"; --context uri; --no_case; )"
        set comment "Lab testi: URI icinde sistemkusu-ips-deneme gecen HTTP istegi"
    next
end

Anahtar sözcükler sırayla şunu söylüyor:

1. --protocol tcp ve --service HTTP: yalnız TCP üzerindeki HTTP trafiğine bak.
2. --flow from_client: yalnız istemciden sunucuya giden yönde ara.
3. --pattern "sistemkusu-ips-deneme" ve --context uri: dizeyi isteğin adres kısmında ara.
4. --no_case: büyük ve küçük harf farkını gözetme.

FortiGate imzaya kendisi bir numara verdi (--attack_id 7512). Arayüzde imza Security Profiles → IPS Signatures listesinde Custom IPS Signature grubunda görünüyor, çift tıklanınca bu metin açılıyor:

İmzayı sensöre ekledim. Arayüzde sensör formunda IPS Signatures and Filters (IPS imzaları ve filtreleri) bölümünde Create New ile tür olarak imza seçilir ve eylem Block (engelle) yapılır. Komut satırında yeni satır kopyalanan filtrenin altına, 2 numarayla eklendi:

config ips sensor
    edit "dmz-web-ips"
        config entries
            edit 2
                set rule 7512
                set status enable
                set log enable
                set action block
            next
        end
    next
end

İnternetteki bir istemciyi taklit eden makineden (203.0.113.80) sunucuya önce dizesiz, sonra dizeyle istek gönderdim:

curl -s -o /dev/null -w "GET $u : HTTP %{http_code}, %{size_download} bayt, %{time_total} sn, cikis " --max-time 10 "http://203.0.113.10$u"; echo $?

2026-10-04 09:31:57 UTC
GET / : HTTP 200, 17 bayt, 0.004789 sn, cikis 0
GET /?ara=sistemkusu-ips-deneme : HTTP 200, 17 bayt, 0.003620 sn, cikis 0
GET /?ara=sistemkusu-ips-deneme : HTTP 200, 17 bayt, 0.003203 sn, cikis 0
GET /?ara=SISTEMKUSU-IPS-DENEME : HTTP 200, 17 bayt, 0.003881 sn, cikis 0
GET /?ara=sistemkusu%2Dips%2Ddeneme : HTTP 200, 17 bayt, 0.003759 sn, cikis 0
GET / : HTTP 200, 17 bayt, 0.004233 sn, cikis 0

Hiçbir istek engellenmedi, hepsi sunucudan 200 aldı. IPS logu ise (execute log display, kategori 4) dört eşleşmenin dördünü de yazmıştı:

date=2026-10-04 time=12:31:57 ... type="utm" subtype="ips" eventtype="signature" level="alert" vd="root" severity="critical" srcip=203.0.113.80 ... dstip=10.34.80.10 ... action="detected" proto=6 service="HTTP" policyid=3 ... attack="SistemKusu.Lab.Test.Dizesi" ... url="/?ara=sistemkusu-ips-deneme" ... attackid=7512 profile="dmz-web-ips" ... msg="custom: SistemKusu.Lab.Test.Dizesi"

action="detected", yani tanındı ama geçirildi. Logun bir iyi haberi de var: büyük harfle yazılan dize (SISTEMKUSU-IPS-DENEME) ve tirelerin adres kodlamasıyla yazıldığı dize (sistemkusu%2Dips%2Ddeneme) de tanındı. IPS adresi karşılaştırmadan önce çözüyor. NIST’in gizleme (evasion) dediği basit hileler bu imzayı atlatmadı.

FortiGate IPS Sensöründe Satır Sırası Neden Önemli?

İmzanın kendi eylemini değiştirmek ve IPS motorunu yeniden başlatmak sonucu değiştirmedi. Değiştiren, filtre satırını silmek oldu: sensörde yalnız imza satırı kalınca aynı istek düşürüldü. Sebebi ayırmak için filtreyi geri ekleyip önce imzanın altına, sonra üstüne koydum. Arayüzde satırlar sürüklenerek, komut satırında move ile taşınır:

config ips sensor
    edit "dmz-web-ips"
        config entries
            move 3 before 2
        end
    next
end

İmza satırı üstte, filtre altta:

2026-10-04 09:39:32 UTC
GET /?ara=sistemkusu-ips-deneme : HTTP 000, 0 bayt, 10.003142 sn, cikis 28
GET / : HTTP 200, 17 bayt, 0.005347 sn, cikis 0

Filtre üstte, imza satırı altta:

2026-10-04 09:40:23 UTC
GET /?ara=sistemkusu-ips-deneme : HTTP 200, 17 bayt, 0.005100 sn, cikis 0
GET / : HTTP 200, 17 bayt, 0.003046 sn, cikis 0

İmza satırı üstteyken istek düşürüldü (dropped), filtre üstteyken geçti (detected). Ölçümün gösterdiği şu: hedefi ve protokolü tanımsız olan özel imza sunucu filtresinin kapsamına da giriyor ve filtre üstteyse ona kendi eylemini uyguluyor. Filtrenin eylemi fabrika eylemi (default). Bu denemede özel imzanın kendi eylemi engelle olduğu hâlde istek geçti, yani filtre bu imzaya geçir uyguladı.

Son olarak imzanın kendi eylemini fabrika değerine (geçir) bırakıp imza satırını yeniden üste aldım, istek yine düşürüldü. Belirleyici olan imzanın kendi eylemi değil, sensördeki satırın eylemi ve sırası.

Fortinet’in kılavuzu imza satırlarının her zaman filtrelerden önce denetlendiğini yazıyor. 7.0.10’da ölçtüğüm davranış bunu doğrulamadı: satır sırası belirleyiciydi. Kendi cihazınızda sürüm farklı olabilir, o yüzden kural basit: engellenmesini istediğiniz imza satırını filtrelerin üstüne koyun ve logda dropped gördüğünüzü doğrulayın.

Örnekteki sınır kapısında el kitabının başında genel bir talimat var: “Sunucu yüklerinde kitaptaki varsayılanı uygula.” Özel talimat bunun altına yazılmışsa görevli ona hiç gelmez, genel talimatla yükü geçirir.

Block mı Reset mi?

Sensör satırında engellemenin iki biçimi var. Block eşleşen paketi düşürür, Reset bağlantıyı iki tarafa sıfırlama paketi (TCP RST) göndererek keser. İkisini aynı istekle ölçtüm. Block:

2026-10-04 09:41:20 UTC
GET /?ara=sistemkusu-ips-deneme : HTTP 000, 0 bayt, 10.002802 sn, cikis 28
GET /?ara=sistemkusu-ips-deneme : HTTP 000, 0 bayt, 10.002654 sn, cikis 28
GET / : HTTP 200, 17 bayt, 0.003539 sn, cikis 0

Reset:

2026-10-04 09:42:31 UTC
GET /?ara=sistemkusu-ips-deneme : HTTP 000, 0 bayt, 0.001788 sn, cikis 56
GET /?ara=sistemkusu-ips-deneme : HTTP 000, 0 bayt, 0.001548 sn, cikis 56

Block’ta istemci cevap bekledi ve 10 saniyelik süre dolunca vazgeçti (curl 28, zaman aşımı). Reset’te bağlantı 2 milisaniyede kesildi (curl 56, bağlantı karşıdan sıfırlandı). Dizesiz istek iki durumda da geçti.

Fark kullanıcının ve saldırganın gördüğü şeyde:

1. Dışarıdan gelen trafikte block: saldırgan isteğinin neden cevapsız kaldığını bilmez ve her denemede süre harcar.
2. İç kullanıcının trafiğinde reset: bir yanlış pozitif kullanıcıyı takılan bir sayfa yerine hemen bir hatayla karşılar, sorun ve kaynağı hızlı bulunur.

Fortinet bu seçim için bir öneri vermiyor. Yukarıdaki ayrım lab ölçümüne dayanan bizim tercihimizdir.

FortiGate IPS Logunu Okumak: detected, dropped, reset

IPS logu her eşleşmeyi, eylem ne olursa olsun yazıyor. Arayüzde Log & Report → Intrusion Prevention ekranında bu yazının bütün denemeleri duruyor:

Action sütunundaki üç değer:

1. detected: imza tanındı, trafik geçti. Satırın eylemi geçir ya da izle.
2. dropped: eşleşen paket düşürüldü.
3. reset: bağlantı sıfırlandı.

Lab’daki ilk ölçümde olduğu gibi engellendiğini sandığınız bir saldırı logda detected görünüyorsa sensör onu engellemiyordur. IPS’in kurulduğu gün bu sütuna bakmak, sensörün gerçekten ne yaptığını gösteren en kısa yoldur. Logların cihazdan bir log sunucusuna nasıl gönderildiğini FortiGate log ayarları yazımızda anlattık.

Giden Trafikte FortiGate IPS: Botnet Bağlantıları

Fortinet’in en iyi uygulama tablosu IPS’e giden trafikte de bir iş veriyor: iç ağdaki bir bilgisayarın botnet komuta sunucularına bağlanmasını engellemek. Sensör formundaki Botnet C&C bölümünde Scan Outgoing Connections to Botnet Sites (botnet sitelerine giden bağlantıları tara) seçeneği bunu yapar ve fabrika ayarında kapalıdır (Disable).

Bu seçeneği lab’da ölçmedim, çünkü tanıyacağı bir liste yok. diagnose autoupdate versions çıktısında botnet alan adı veritabanı boş görünüyor:

Botnet Domain Database
---------
Version: 0.00000
Contract Expiry Date: n/a
Last Updated using manual update on Mon Jan  1 00:00:00 2001

Sürüm 0.00000, tarih de 2001, yani cihaz hiçbir botnet adresi bilmiyor. Bu liste FortiGuard aboneliğiyle gelir ve güncel olmayan bir liste bugünün komuta sunucularını tanımaz. Seçenek, aboneliği olan cihazda çalışan ağının internet çıkış kuralına bağlanan bir sensörde açılır.

Doğrulama: FortiGate IPS Doğru Çalışıyor mu?

1. Kural: dışarıya açık her servisin kuralında IPS alanı o servise uygun sensörü gösteriyor.
2. İmza tarihi: diagnose autoupdate versions çıktısında Attack Definitions tarihi yakın.
3. Satır sırası: engellenecek imza satırları filtrelerin üstünde.
4. Test: özel bir test imzasıyla gönderilen istek düşürülüyor ya da sıfırlanıyor, dizesiz istek geçiyor.
5. Log: Log & Report → Intrusion Prevention ekranında test denemesi dropped ya da reset olarak görünüyor, detected değil.
6. Test imzası: sınama bitince sensörden çıkarılmış ya da eylemi bilerek bırakılmış, kimsenin bilmediği bir test kuralı kalmamış.

Sonuç: FortiGate IPS, El Kitabı Kadar Güncel ve Sensör Kadar Doğrudur

FortiGate’te IPS’i açmak bir sensörü kurala bağlamaktır. IPS’in bir saldırıyı gerçekten durdurup durdurmadığını ise imzaların yaşı ve sensördeki satırların sırası belirliyor. Lab’da dört şey öne çıktı:

1. İmza veritabanı 2015’te kalmış: 2014’teki Shellshock imzası var, 2021’deki Log4j imzası yok.
2. Engelle eylemli imza yalnız loglandı, çünkü fabrika eylemli bir filtre satırının altındaydı. Satır üste alınınca istek düşürüldü.
3. Block istemciyi 10 saniye bekletti, reset bağlantıyı 2 milisaniyede kesti.
4. Büyük harfle ve adres kodlamasıyla yazılan dize de tanındı.

Örnekteki sınır kapısında görevlinin aynası ne kadar iyi olursa olsun, el kitabında çizili olmayan saklama yerine bakmaz. Kitaptaki talimatların sırası da yanlışsa çizili olanı bile geçirir. FortiGate’te el kitabı imza veritabanı, talimatların sırası da sensörün satırlarıdır. IPS’i diğer profillerle birlikte tek seferde kurala takmayı rehberin profil grubu bölümünde anlattık. Sıradaki adım rehberin 5. adımı, antivirüs.

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