IPS Politikası Ayarlama: Yanlış Pozitifi Ayıklayıp Engellemeye Geçmek

IPS lisansı açık firewall’ların çoğunda tablo aynıdır: Ya profil yıllardır yalnız izleme modunda duruyor ya da varsayılan profil tüm trafiğe bağlanmış, ilk yanlış engellemeden sonra geniş istisnalarla fiilen kapatılmış. Lisans ödeniyor, koruma yok. Aşağıda IPS politikasını canlı ortamda nasıl ayarlayacağınızı anlatıyoruz: imza kapsamını daraltmaktan istisna yönetimine ve engelleme moduna aşamalı geçişe kadar.

IDS ve IPS: konum ve çalışma modu farkı

IDS trafiğin bir kopyasını (SPAN, TAP veya sanal ayna portu) inceler ve yalnız alarm üretir; IDS arızalansa trafik etkilenmez. IPS ise trafik yolunun üzerindedir (inline): Paketi bırakabilir, oturumu sıfırlayabilir, kaynağı geçici olarak engelleyebilir. Bu farkın iki pratik sonucu var. Birincisi, IPS’in her yanlış pozitifi bir kesintidir. İkincisi, IPS bir darboğaz ve arıza noktası olabilir; donanım arızasında trafiğin geçmesine mi (fail-open) yoksa kesilmesine mi (fail-closed) izin verileceği bilinçli bir karar olmalıdır. Bu kararı arıza anında vermek çok geç.

Özellik	IDS	IPS
Konum	Ayna/TAP, trafik dışı	Inline, trafik yolunda
Eylem	Alarm	Alarm, paket bırakma, oturum sıfırlama
Yanlış pozitif etkisi	Analist yükü	Kesinti
Gecikme etkisi	Yok	Var, kapasiteye bağlı
Tipik kullanım	Görünürlük, doğu-batı izleme	Kuzey-güney ve bölgeler arası koruma

NGFW’lerde IPS genellikle güvenlik politikasına bağlanan bir profil olarak çalışır. Aynı cihazda bir politikada izleme, diğerinde engelleme yapabilirsiniz. Aşamalı geçiş planı bu esnekliğe dayanır.

İmza profili seçimi: varlığa ve servise göre kapsam

Yanlış pozitiflerin ve performans kaybının bir numaralı kaynağı, tek bir “tüm imzalar” profilinin bütün politikalara bağlanmasıdır. Linux üzerinde çalışan bir web sunucusuna giden trafikte Windows istemci zafiyetlerine ait imzaları çalıştırmak hem işlemci harcar hem de anlamsız alarm üretir. Kapsamı daraltmak için profili şu eksenlerde ayırın:

• Yön ve hedef: İnternete yayınlanan sunuculara gelen trafik için sunucu tarafı imzalar; kullanıcıların internet çıkışı için istemci tarafı imzalar.
• İşletim sistemi ve uygulama: DMZ’deki varlıkların gerçekten kullandığı platformlar (örneğin Linux, nginx, belirli bir veritabanı).
• Önem derecesi: Başlangıçta yüksek ve kritik imzalar engellemeye adaydır; düşük ve bilgi seviyesindekiler izleme modunda kalabilir.
• Bölge: Kullanıcı ağından sunucu ağına geçen trafik, segmentler arası yatay hareketi görmek için ayrı bir profil ister. Bölge tasarımının kendisi ağ güvenliği ve segmentasyon çalışmasının konusudur.

Pratikte çoğu kurum için üç–beş profil yeter: yayınlanan sunucular, internet çıkışı, iç bölgeler arası ve gerekiyorsa OT veya misafir ağı. Profil sayısı arttıkça işletim yükü de artar. Fazlası bakımsız kalır.

İzleme modunda baseline toplama

Engellemeye geçmeden önce her profili yalnız alarm üreten modda en az iki–dört hafta çalıştırın. Amaç “sıfır alarm” görmek değil; alarmların neye benzediğini anlamak. Bu dönemde toplanacak bilgiler:

• İmza bazında alarm sayısı ve en çok tetiklenen ilk 20 imza
• Her imza için kaynak ve hedef dağılımı: tek bir sistemden mi geliyor, ağın geneline mi yayılıyor?
• Alarmların zaman deseni: yedekleme, tarama veya toplu iş saatleriyle örtüşüyor mu?
• Cihaz kaynak kullanımı: CPU, oturum sayısı ve gecikme değerleri

Alarmları tek tek değil, log yöneticisinde imza kimliği, kaynak ve hedefe göre gruplayarak inceleyin. Bu verinin SIEM’de tespit kuralına dönüştürülmesi firewall log analizi rehberinin konusudur.

Yanlış pozitif analizi ve istisna yönetimi

Sahada yanlış pozitiflerin kaynağı hemen hep aynı listeden çıkar: yetkili zafiyet tarayıcıları, izleme sistemlerinin protokol sorguları, eski veya standarda tam uymayan uygulama protokolleri, yedekleme ve replikasyon trafiğindeki büyük ikili veri akışları ve şifreli trafikte çözme yapılmadığı için eksik bağlamla eşleşen imzalar.

Bir alarmı yanlış pozitif diye kapatmadan önce dört soruya cevap verin: İmza hangi zafiyeti veya davranışı hedefliyor? Hedef sistem o zafiyete açık bir yazılım çalıştırıyor mu? Kaynak sistemin bu trafiği üretmesi beklenen bir durum mu? Paket yakalaması imzanın gerçekte neyle eşleştiğini gösteriyor mu? Cevapsız kapatılan alarm, bir sonraki gerçek saldırıda da kapalı kalır.

İstisna gerekiyorsa en dar haliyle yazın. Sıra şudur: belirli imza + belirli kaynak/hedef, sonra belirli imza + belirli alt ağ, en son imzanın tamamen kapatılması. Bir sunucu için tüm profili kapatmak istisna değildir. Açık kaynak Suricata’da bu yaklaşım threshold.config dosyasındaki suppress satırlarıyla, imza düzeyindeki değişiklikler ise suricata-update aracının disable.conf, drop.conf ve modify.conf dosyalarıyla yönetilir:

# /etc/suricata/threshold.config
# Ornek SID: yalniz yetkili tarayicidan gelen eslesmeleri bastir
suppress gen_id 1, sig_id 9000001, track by_src, ip 10.20.30.15

# /etc/suricata/drop.conf  (baseline sonrasi; suricata-update ile alert -> drop)
group:emerging-exploit.rules

# Kurallari guncelle, yapilandirmayi test et
sudo suricata-update
sudo suricata -T -c /etc/suricata/suricata.yaml

Ticari NGFW’lerde aynı mantık imza bazında eylem değiştirme ve IP istisnası (exempt) alanlarıyla uygulanır. Platform ne olursa olsun her istisna bir kayıtla yaşamalıdır:

Alan	Örnek içerik
İmza kimliği ve adı	Üretici imza ID’si ve açıklaması
Kapsam	Kaynak 10.20.30.15, hedef DMZ web havuzu
Gerekçe ve kanıt	Yetkili tarayıcı; paket yakalaması ekli
Onaylayan ve sahip	Güvenlik ekibi / zafiyet yönetimi sahibi
Gözden geçirme tarihi	Üç ay sonra; imza güncellemesinde tekrar kontrol

Engelleme moduna aşamalı geçiş planı

Geçiş sırası, riskle görünürlüğü dengeleyecek şekilde kurulur:

1. İnternete yayınlanan servisler, kritik ve yüksek imzalar. Saldırı olasılığı en yüksek, trafik profili en öngörülebilir alan.
2. İnternet çıkışı, istemci tarafı kritik imzalar. Exploit kit, bilinen zararlı yazılım iletişimi ve komuta-kontrol imzaları bu aşamada.
3. İç bölgeler arası trafik. Yanlış pozitif riski en yüksek alan; en son ve en dar imza setiyle başlanır.
4. Orta önem derecesi. İlk üç aşama oturduktan sonra baseline verisine göre seçici olarak eklenir.

Her aşamada değişiklik bakım penceresinde yapılır, ilk 48 saat engelleme logları yakından izlenir ve geri dönüş adımı (profili izleme moduna almak) önceden yazılır. Destek ekibine de net bir talimat verin: “Uygulama çalışmıyor” şikâyeti geldiğinde ilk bakılacak yer IPS engelleme logudur. Bu bilgi yoksa ekip yarım günü sunucuda arar.

Performans etkisi ve donanım kapasitesi

Üretici veri sayfalarında firewall throughput, IPS throughput ve “threat protection” throughput ayrı değerlerdir; IPS açıkken gerçek kapasite firewall throughput’unun belirgin şekilde altına iner. Bu değerler üreticinin seçtiği trafik karışımıyla ölçülür ve sizin trafiğinizi temsil etmeyebilir. Kapasiteyi değerlendirirken şunlara bakın:

• Profil kapsamı: Daraltılmış imza seti, aynı donanımda daha yüksek gerçek kapasite demektir.
• TLS çözme: IPS ile birlikte açıldığında kaynak tüketimi ciddi biçimde artar.
• Yoğun saat davranışı: Ortalama değil, en yoğun dönemdeki CPU ve oturum değerleri esas alınır.
• Fail-open/fail-closed: Yazılım veya donanım hatasında IPS motorunun davranışı test ortamında doğrulanır.

Cihaz seçimi aşamasında bu değerlerin nasıl okunacağı kurumsal firewall seçimi yazısında ele alınıyor.

IPS’in gerçekten çalıştığını doğrulama

Panelde “IPS açık” yazması, kurumsal siber güvenlik açısından korunduğunuz anlamına gelmez. Düzenli doğrulama için:

• Zararsız tetikleyici testi: Suricata dokümantasyonundaki hızlı başlangıç testi gibi, bilinen bir imzayı tetikleyen zararsız bir istek (curl http://testmynids.org/uid/index.html) izleme ve engelleme modunda beklenen sonucu vermelidir. Bu istek Suricata/ET kural setlerindeki bir imzayı tetikler; ticari NGFW’lerde aynı sonucu vermeyebilir. Bu durumda üreticinin önerdiği test yöntemini veya imzası bilinen zararsız bir test dosyasını (örneğin EICAR) kullanın.
• Güncelleme kontrolü: İmza veritabanı sürümü ve son güncelleme zamanı izleme sistemine bağlanmalı; güncellemenin durması alarm üretmelidir. Sahada en sık gördüğümüz sessiz arıza budur: Lisans biter, imzalar aylarca güncellenmez, kimse fark etmez.
• Kapsam kontrolü: Her güvenlik politikasının doğru IPS profiline bağlı olduğu periyodik olarak raporlanmalı; yeni eklenen kurallarda profilin unutulması yaygındır.
• Bağımsız test: Yetkili sızma testi veya saldırı simülasyonu, IPS’in gerçek saldırı tekniklerine tepkisini ölçer. Testten önce test kaynaklarının istisna listesine alınıp alınmayacağına bilinçli olarak karar verin.

IPS politikasının profil tasarımından işletimine kadar ele alınması, firewall kurulumu ve kural yönetimi çalışmasının bir parçası olarak planlanabilir. Suricata kural yönetimi ayrıntıları için Suricata User Guide birincil kaynaktır.

Sık sorulan sorular

IPS’i doğrudan engelleme modunda açmak neden önerilmez?

Çünkü trafiğinizde hangi imzaların yanlış pozitif üreteceğini önceden bilemezsiniz. Baseline toplanmadan açılan engelleme meşru uygulamaları keser ve ekibi geniş istisnalarla IPS’i fiilen kapatmaya iter.

İzleme modunda ne kadar kalmak gerekir?

Her profil için iki–dört hafta yaygın bir başlangıçtır; ay sonu işleri, yedekleme pencereleri ve periyodik taramalar bu süreye girmelidir. Asıl ölçüt süre değil, en sık tetiklenen imzaların her birinin açıklanmış olmasıdır.

Bir imzayı tamamen kapatmak ile istisna tanımlamak arasındaki fark nedir?

İmzayı kapatmak o tespiti tüm ağ için kaldırır. İstisna ise imzayı yalnız belirli bir kaynak veya hedef için bastırır, diğer trafikte tespit sürer. Tercih her zaman en dar istisnadır.

IPS şifreli trafikteki saldırıları görebilir mi?

TLS çözme yoksa yalnız bağlantı meta verisini ve bazı el sıkışma bilgilerini görür; uygulama katmanındaki saldırı içeriğini göremez. Yayınlanan sunucular için IPS ile TLS çözme birlikte planlanmalıdır.