Yanlış pozitif ayarı ve kural bakımı

Yeni bir kural devreye girdiğinde ilk günler gürültülü geçer. Kural, tasarlandığı saldırıyı yakalar ama bazen zararsız trafiği de aynı örüntüye benzediği için işaretler. Buna yanlış pozitif denir.

Az sayıda yanlış pozitif sorun değildir, analist hızlıca eler. Ama sayı arttıkça gerçek alarm gürültünün arasında kaybolur, bu duruma alarm yorgunluğu denir. Analist zamanla her alarmı ciddiye almayı bırakır ve gerçek bir saldırı da fark edilmeden geçebilir.

Ayarlama bu riski azaltır. Amaç kuralı tamamen susturmak değildir, gereksiz tekrarı ve yanlış eşleşmeyi kesmektir. İyi ayarlanmış bir kural seti az sayıda ama güvenilir alarm üretir. Bu derste önce gürültüyü ölçecek, sonra eşik ve susturma araçlarını, kalıcı ayar dosyalarını, ayar kaydını ve regresyon testini göreceksin.

Ayara tahminle değil ölçümle başlarsın. İlk soru şudur: alarmların çoğunu hangi imzalar üretiyor. Çoğu zaman birkaç imza toplam gürültünün büyük kısmını taşır. Bir bankanın giriş sayfasını koruyan kural buna iyi bir örnektir.

İlk hafta çok sayıda yanlış pozitif üretir, çünkü meşru kullanıcılar da benzer örüntüde istek gönderir. En gürültülü imzaları eve.json dosyasından tek satırlık bir komut zinciriyle çıkarırsın. jq yalnız alarm satırlarının imza numarasını yazar. sort numaraları sıralar, uniq -c her numarayı sayar.

İkinci sort sayıları büyükten küçüğe dizer, head ilk on satırı gösterir. Sonra her imzanın alarmlarından örnekler açar ve tabloya bir karar yazarsın.

$ jq -r 'select(.event_type=="alert") | .alert.signature_id' eve.json | sort | uniq -c | sort -rn | head
   8412 1000001
   3120 1000031
    944 1000045
    118 1000010
     37 1000052

sid       Hafta  İnceleme bulgusu                              Karar
1000001   8412   Çoğu güvenilir tarayıcıdan (198.51.100.10)    Sustur (suppress)
1000031   3120   Aynı kaynaklardan saniyede onlarca tekrar     Sınırla (threshold)
1000045    944   Meşru bir API parametresi içeriğe takılıyor   Yeniden yaz
1000010    118   Gerçek kötü alan adı sorguları                Dokunma
1000052     37   Hedef aldığı yazılım kaldırılmış              Kapat (disable.conf)

Tabloyu kararla birlikte oku. Beş imza, dört farklı karar alır. Susturma belirli bir kaynağın alarmını kalıcı keser ve kuralı öteki kaynaklar için açık bırakır. Sınırlama tekrarları azaltır ama ilk alarmları korur.

Yeniden yazma kuralın aradığı şeyi daraltır, örneğin içeriği doğru tampona taşır. Kapatma kuralı devreden çıkarır. 1000010 numaralı imza gürültülü görünse de doğru alarm üretir ve ona dokunulmaz. Çok alarm üretmek tek başına ayar gerekçesi değildir.

Karar her zaman örnek alarmları açıp okuduktan sonra verilir. Sayıyı gördüğün an kuralı susturmak, ayarın en pahalı kısayoludur. Örneğin 1000001 için karar vermeden önce alarmları kaynak adrese göre dağıtırsın. Aşağıdaki komut bu imzanın alarmlarını kaynaklara göre sayar.

$ jq -r 'select(.event_type=="alert" and .alert.signature_id==1000001) | .src_ip' eve.json | sort | uniq -c | sort -rn | head -3
   8105 198.51.100.10
    214 203.0.113.77
     93 203.0.113.12

Çıktıyı yukarıdan oku. 8412 alarmın 8105'i tek bir adresten gelir ve o adres kurumun güvenilir tarama sunucusudur. Geri kalan 307 alarm başka kaynaklardan gelir.

203.0.113.77 adresinin 214 alarmı bir tarama sunucusuna değil, dışarıdan gelen gerçek bir denemeye ait olabilir. Bu yüzden doğru karar imzanın tamamını değil, yalnız 198.51.100.10 adresini susturmaktır. Aynı dağılımı hedef adrese göre de çıkarırsın; gürültü tek bir sunucuda toplanıyorsa sorun çoğu zaman o sunucudaki bir uygulamadır. Kaynak ve hedef dağılımı, bir sonraki bölümde göreceğin track seçeneğinin de pusulasıdır.

Suricata bu ayarları threshold.config dosyasında tutar; suricata.yaml içindeki threshold-file ayarı bu dosyayı gösterir. Dosyadaki ayar kuralın kendi eşik ayarını da geçersiz kılar, böylece hazır bir kurala dokunmadan onu ayarlarsın. threshold satırı üç türden biriyle yazılır.

limit, belirli sürede en fazla N alarm üretir. threshold türü tersini yapar ve N eşleşme görmeden alarm vermez. both ikisini birleştirir: süre içinde N eşleşme olursa o süre için tek alarm üretir.

Kuralın içinde yazılabilen backoff ise alarmları giderek seyrelen aralıklarla verir ve yalnız track by_flow ile çalışır. track sayacın neye göre tutulacağını söyler. by_src kaynağa, by_dst hedefe, by_both adres çiftine, by_rule kuralın bütününe, by_flow tek bir akışa göre sayar.

suppress gen_id 1, sig_id 1000001, track by_src, ip 198.51.100.10
threshold gen_id 1, sig_id 1000031, type limit, track by_src, count 5, seconds 60
rate_filter gen_id 1, sig_id 1000060, track by_src, count 20, seconds 60, new_action drop, timeout 300

İlk satır 198.51.100.10 adresinden gelen 1000001 alarmlarını hep susturur, çünkü o adres güvenilir bir tarama sunucusudur. Susturma kuralı kapatmaz; aynı imza başka bir kaynaktan gelirse alarm üretmeye devam eder. suppress satırında track by_src, by_dst ya da iki yönü birden kapsayan by_either yazılır. ip alanı tek adres, 10.0.5.0/24 gibi bir alt ağ ya da $HOME_NET gibi bir değişken alabilir.

İkinci satır 1000031 alarmlarını her kaynak için altmış saniyede beşle sınırlar. Patlama halinde gelen yüzlerce tekrar en fazla beş alarma iner.

Üçüncü satır bir oran süzgecidir (rate_filter). Aynı kaynak altmış saniyede yirmiden fazla eşleşme üretirse kuralın eylemi beş dakika boyunca drop olur. Bu satır paketi yalnız IPS modunda gerçekten durdurur. Kuralın içindeki detection_filter ise ilk eşleşmeleri sessizce sayar ve eşik aşılınca her eşleşmede alarm üretir.

Hazır bir kural setini doğrudan düzenlersen ilk güncellemede değişikliğin silinir. suricata-update bu yüzden ayarı ayrı dosyalarda tutar ve her güncellemede yeniden uygular. /etc/suricata/disable.conf dosyasına yazdığın her satır bir ya da daha çok kuralı kapatır. Satır bir sid, re: ile başlayan bir düzenli ifade ya da group: ile başlayan bir kural dosyası adı olabilir.

modify.conf bir kuralın metninde bul ve değiştir yapar; satırın biçimi sid, aranan metin ve yeni metindir. enable.conf kapalı gelen bir kuralı açar, drop.conf seçilen kuralların eylemini drop yapar. suricata-update kuralları birleştirdikten sonra varsayılan olarak bir söz dizimi testi de çalıştırır. Test geçerse yeni set canlıya yüklenmeye hazırdır.

# /etc/suricata/disable.conf
1000052

# /etc/suricata/modify.conf
1000045 "http.request_body" "http.uri"

$ sudo suricata-update
$ sudo suricatasc -c reload-rules
{"message": "done", "return": "OK"}

disable.conf 1000052 numaralı ölü kuralı kapatır. modify.conf ise 1000045 numaralı kuralın aradığı tamponu istek gövdesinden adrese taşır. suricata-update seti yeniden birleştirir ve test eder.

suricatasc Suricata'nın yönetim soketine bağlanır. reload-rules komutu yeni kuralları süreci durdurmadan yükler ve iş bitene kadar bekler. Yükleme sırasında Suricata paket işlemeyi sürdürür, ama iki kural seti kısa bir süre bellekte birlikte durur.

Yükleme threshold.config dosyasını da yeniden okur, böylece eşik ve susturma değişikliği de süreci durdurmadan devreye girer. Ayarın maliyetini de ölçersin. Profilleme desteğiyle derlenmiş bir Suricata, rule_perf.log dosyasına her kuralın harcadığı işlemci süresini yazar. Aşağıdaki çıktıda 1000045 toplam sürenin yüzde 41'ini tek başına harcıyor.

  Num      Rule         Gid      Rev      Ticks        %      Checks   Matches  Max Ticks   Avg Ticks   Avg Match   Avg No Match
  -------- ------------ -------- -------- ------------ ------ -------- -------- ----------- ----------- ----------- --------------
  1        1000045      1        3        918273645    41.20  1822301  944      402113      503.91      1210.44     503.54
  2        1000031      1        2        201837465    9.06   2101288  3120     88120       96.05       140.10      95.99

Her ayar bir karardır ve her kararın bir izi olmalıdır. Ayar kaydı altı alan taşır: sid, yapılan değişiklik, gerekçe, sahip, tarih ve gözden geçirme tarihi. Gözden geçirme tarihi gelen susturma yeniden tartışılır; gerekçe geçerliliğini yitirdiyse kaldırılır.

rev alanı bu bakımın kuralın içindeki izidir. Bir kuralı düzeltince rev numarasını artırırsın, böylece hangi sürümün üretimde çalıştığı bellidir. Bir olay sonrası hangi kural sürümünün alarmı ürettiğini bilmek incelemeyi hızlandırır.

Kural setini ve ayar dosyalarını bir sürüm kontrol sisteminde tutmak da yaygın bir uygulamadır. Her değişiklik bir gözden geçirmeden geçer, tıpkı bir kod değişikliği gibi, ve gerekirse geri alınır.

sid:            1000001
degisiklik:     suppress track by_src ip 198.51.100.10
gerekce:        Haftalık zafiyet taraması, değişiklik kaydı DEG-2026-118
sahip:          soc-ekibi
tarih:          2026-09-24
gozden_gecirme: 2026-12-24

Ayar yanlış yönde de gidebilir. Gürültüyü keserken gerçek saldırıyı da susturmuş olabilirsin. Bu yüzden her değişiklikten sonra regresyon testi koşarsın. Her kural için bir olumlu ve bir olumsuz pcap saklarsın.

Olumlu kayıt kuralın yakalaması gereken saldırıyı, olumsuz kayıt ise benzer ama zararsız trafiği içerir. Elinde gerçek bir kayıt yoksa örnek paketleri Scapy gibi bir paket üretim kütüphanesiyle üretirsin. Bunu yalnız kendi lab ağında yapar, kurala uyan ve uymayan paketleri pcap olarak saklarsın. suricata -r ile hepsini sırayla çalıştırır, olumlu kayıtta alarm, olumsuz kayıtta sessizlik beklersin.

Kayıtları canlı bir test arayüzünde denemek istersen tcpreplay aracı pcap'i ağ arayüzüne yeniden oynatır. Bunu yalnız yalıtılmış bir lab ağında yaparsın. Test çıktısında sonucu beklentiyle satır satır karşılaştırırsın. threshold alarm sayısını azaltır ama yanlış eşleşmeyi düzeltmez; olumsuz kayıtta çıkan alarm bu yüzden hâlâ bir hatadır.

Ayarlama tek seferlik iş değildir, kural setinin bir yaşam döngüsü vardır. Yeni bir kural önce test modunda izlenir, üretilen alarm günlerce gözlenir. Gürültü fazlaysa eşik ya da susturma eklenir, hâlâ gürültülüyse kural yeniden yazılır.

Zamanla bazı kurallar işe yaramaz hale gelir; hedef aldığı yazılım artık kullanılmıyordur ya da imza çok genel kalmıştır. Bu kurallar arşivlenir ya da silinir, çünkü her aktif kural motora ek yük bindirir.

Kural setini güncel tutmak yalnız yeni tehdide karşı değil, kendi gürültünü azaltmak için de gerekir. Döngüyü takvime bağlamak ayarlamanın unutulmasını da önler. Bakımsız bir kural seti zamanla hem gürültülü hem güvenilmez hale gelir.

Döngünün işe yarayıp yaramadığını alarm yorgunluğunu ölçerek anlarsın. Üç sayı iyi bir başlangıçtır: analist başına günlük alarm, bir alarmın ortalama kapatılma süresi ve kapatılan alarmlar içinde yanlış pozitif oranı. İki analistin günde binlerce alarmı gerçekten incelemesi beklenemez. Bu sayı incelenebilir bir düzeye inmeden gerçek alarm görünmez kalır.

Ayar sonrası üç sayının da iyileşmesi, ama regresyon testlerinin geçmeye devam etmesi gerekir. Yanlış pozitifin kuruma maliyetini Mavi Takım yolunun "Yanlış pozitifin gerçek maliyeti" dersinde ayrıntılı görürsün. Bir SOC ekibi üç ay önce eklediği bir kuralın artık hiç alarm üretmediğini fark ediyor; hedef aldığı eski yazılım kullanımdan kalkmış. Aşağıdaki soruda doğru adımı seç.