Firewall Loglarından Tehdit Tespiti: Kullanım Senaryoları

Çoğu kurumda firewall logu SIEM’e akar, saklama süresi dolana kadar bekler ve yalnızca bir olaydan sonra geriye dönük aranır. Oysa kurumdaki en zengin ağ telemetrisi budur. Doğru alanlar toplanıp normalleştirildiğinde aynı veri iç ağ taramasını, komuta-kontrol trafiğini ve veri sızıntısını olay büyümeden yakalayan tespitlere dönüşür. Aşağıdaki senaryolar, SIEM’de firewall loglarından somut ve işletilebilir tespitler üretmek isteyen SOC ve güvenlik ekipleri için.

Hangi firewall logları gerçekten gereklidir

NGFW’ler birden fazla log türü üretir; tespit değerleri ve hacimleri farklıdır:

Log türü	Tespit değeri	Hacim
Trafik (izin verilen)	Beaconing, sızıntı, yatay hareket	Çok yüksek
Trafik (engellenen)	Tarama, yanlış yapılandırma, politika ihlali	Yüksek
IPS/tehdit	İstismar girişimi, bilinen zararlı imza	Düşük–orta
URL/DNS filtreleme	Zararlı alan adı, kategori ihlali	Orta–yüksek
VPN ve kimlik	Hesap ele geçirme, olağan dışı konum	Düşük
Sistem ve yönetim	Yetkisiz yapılandırma değişikliği, HA olayı	Düşük

Yönetim ve VPN logları düşük hacimli ve yüksek değerlidir; her koşulda toplayın. Firewall’a yönetici girişi ve politika değişikliği, saldırganın iz bıraktığı en kritik olaylardandır. Bu loglar yoksa gerisi eksik kalır. Bunlarla birlikte DNS filtreleme logları, alan adı bazlı tespitlerde IP bazlı firewall loglarını tamamlar.

Sahada sık atlanan bir ayrıntı: çoğu NGFW trafik logunu oturum sona erdiğinde üretir. Günlerce açık kalan bir bağlantı, kapanana kadar logda görünmeyebilir. Uzun oturumlar için ara log (interim) veya oturum başlangıç logu seçeneği varsa kritik bölgelerde açın.

Log alanları ve normalleştirme

Farklı üreticilerin logları aynı kavramı farklı adlarla taşır: bir cihaz srcip, diğeri src, bir başkası source_address der. Tespit kurallarının üreticiden bağımsız çalışması için loglar ortak bir şemaya dönüştürülmelidir. Microsoft Sentinel’de CEF loglarının düştüğü CommonSecurityLog tablosu, Elastic tarafında ECS (Elastic Common Schema) bu işi görür. Tespit için asgari alan seti:

• Zaman damgası (cihaz saati NTP ile senkronize ve saat dilimi belirli olmalı)
• Kaynak IP/port, hedef IP/port, protokol
• Eylem (izin, engelle, düşür) ve eşleşen kural adı veya kimliği
• Gönderilen ve alınan bayt, oturum süresi
• Kaynak ve hedef bölge (zone) veya arayüz
• Kullanıcı adı ve uygulama adı (NGFW kimlik ve uygulama tanıma açıksa)
• NAT öncesi ve sonrası adresler

NAT öncesi adres kaybolursa dış bir alarmı iç cihaza bağlamak imkansızlaşır. Kural adı ise tespiti doğrudan aksiyona çevirir: hangi kuralın bu trafiğe izin verdiğini bilmeden kuralı sıkılaştıramazsınız. Aynı bilgi firewall kural temizliği çalışmasında da kullanılır. Konsolda ilk bakılacak yer cihaz saatidir; NTP’si kaymış bir firewall’un logu başka kaynaklarla ilişkilendirilemez. Logların merkezi toplanması ve iletimi network sitesindeki merkezi syslog sunucusu rehberinde anlatılıyor.

Tespit senaryosu: iç ağdan tarama ve yatay hareket

Ele geçirilen bir iş istasyonu genellikle çevresindeki hedefleri keşfetmeye çalışır (MITRE ATT&CK T1046, Network Service Discovery) ve ardından SMB, RDP veya WinRM üzerinden yayılır (T1021, Remote Services). Firewall bu trafiği ancak bölgeler arasında bir denetim noktası varsa görür. Segmentasyon yoksa log da yok.

Mantık: kısa bir zaman penceresinde tek bir iç kaynaktan çok sayıda farklı hedefe veya porta yönelen, büyük kısmı engellenen bağlantılar. Aşağıdaki KQL örneğinde eşikler örnek değerdir:

CommonSecurityLog
| where TimeGenerated > ago(1h)
| where ipv4_is_private(SourceIP) and ipv4_is_private(DestinationIP)
| summarize Hedefler = dcount(DestinationIP),
            Portlar = dcount(DestinationPort),
            Engellenen = countif(DeviceAction in~ ("deny", "drop", "block"))
          by SourceIP, bin(TimeGenerated, 10m)
| where Hedefler > 50 or Portlar > 100

Ayarlama notları: zafiyet tarayıcıları, izleme sunucuları ve ağ keşif araçları bu kuralı sürekli tetikler. Bu kaynakları izin listesine alın ama listeyi düzenli gözden geçirin; saldırganın tarayıcı sunucusunu kullanması da gerçek bir senaryodur. Yatay hareket için ek kural: iş istasyonu bölgesinden başka iş istasyonlarına 445, 3389 veya 5985/5986 portlarına başarılı bağlantılar. İki iş istasyonunun SMB ile konuşması için meşru bir neden nadiren vardır. Mikrosegmentasyon politikası uygulanmış ortamlarda bu akışların engellenen loglarda görünmesi hem tespit hem kontrol doğrulaması sağlar.

Tespit senaryosu: beaconing ve C2 trafiği

Zararlı yazılımlar komuta-kontrol sunucusuna düzenli aralıklarla bağlanıp talimat bekler (T1071, Application Layer Protocol). Bu düzenlilik insan kaynaklı web trafiğinden belirgin biçimde farklıdır. Tespit mantığı: aynı kaynak-hedef çifti için bağlantılar arası sürenin ortalaması ve standart sapması hesaplanır; sapması ortalamaya göre çok küçük, bağlantı sayısı yüksek olan çiftler aday olarak işaretlenir.

CommonSecurityLog
| where TimeGenerated > ago(24h)
| where ipv4_is_private(SourceIP) and not(ipv4_is_private(DestinationIP))
| project TimeGenerated, SourceIP, DestinationIP, DestinationPort
| sort by SourceIP asc, DestinationIP asc, DestinationPort asc, TimeGenerated asc
| extend Onceki = prev(TimeGenerated), OncekiKaynak = prev(SourceIP),
         OncekiHedef = prev(DestinationIP), OncekiPort = prev(DestinationPort)
| where SourceIP == OncekiKaynak and DestinationIP == OncekiHedef and DestinationPort == OncekiPort
| extend Aralik = datetime_diff('second', TimeGenerated, Onceki)
| summarize Baglanti = count(), Ort = avg(Aralik), Sapma = stdev(Aralik)
          by SourceIP, DestinationIP, DestinationPort
| where Baglanti > 50 and Sapma < Ort * 0.1

Saldırgan araçları aralıklara rastgelelik (jitter) ekleyebilir; yalnız standart sapmaya dayanmak yetmez. Daha güçlü sinyal hedefin nadirliğidir: kurumda yalnızca bir veya iki cihazın düzenli olarak bağlandığı, yeni kaydedilmiş veya itibarı bilinmeyen bir hedef. Sonuç tablosunu her hedefe kaç farklı iç kaynağın bağlandığı bilgisiyle zenginleştirin. Güncelleme servisleri ve izleme ajanları gibi yaygın hedefler böylece kendiliğinden elenir. Nadir hedef, asıl ipucudur.

Tespit senaryosu: olağan dışı dış çıkış ve veri sızıntısı

Veri sızıntısı çoğu zaman tek bir göstergeyle değil, birkaç sinyalin birleşimiyle görünür (T1048, Exfiltration Over Alternative Protocol; T1041, Exfiltration Over C2 Channel):

• Bir cihazın dışarıya gönderdiği bayt miktarının kendi geçmiş ortalamasının çok üzerine çıkması; özellikle gönderilenin alınandan büyük olduğu oturumlar.
• Sunucu bölgesinden internete, normalde hiç görülmeyen bir hedefe başlatılan bağlantı.
• Mesai dışı saatlerde dosya paylaşım veya bulut depolama kategorisine büyük yükleme.
• Beklenmeyen port ve protokol kullanımı: 53 numaralı porttan DNS olmayan trafik, iç DNS sunucuları dışındaki cihazlardan dışarıya 53 veya 853 (DoT) bağlantısı, TLS olmayan bir protokolün 443 üzerinden taşınması.
• Coğrafi anomali: VPN girişlerinde kullanıcının daha önce görülmemiş bir ülkeden bağlanması veya kurumun iş ilişkisi olmayan bölgelere yönelik çıkış.

Hacim tabanlı kurallarda sabit eşik yerine cihaz bazlı taban çizgisi kullanın; yedekleme sunucusu için olağan olan bir hacim, muhasebe iş istasyonu için olağan dışıdır. Sentinel’de SentBytes ve ReceivedBytes alanları bu hesap için kullanılabilir. Alanların dolu gelip gelmediği üreticinin CEF eşlemesine bağlıdır; kuralı yazmadan önce birkaç satır logu açıp kontrol edin. Boş alana kural yazılmaz.

Log hacmi, filtreleme ve saklama dengesi

İzin verilen trafik logları SIEM lisans ve depolama maliyetinin büyük kısmını oluşturabilir. Hacmi tespit değerini kaybetmeden düşürmek için:

• Yüksek hacimli ve düşük riskli akışları (iç DNS sunucusundan dış çözümleyicilere, yedekleme trafiği) kaynakta toplulaştırın veya ayrı, ucuz bir depolama katmanına yönlendirin.
• Aynı oturum için birden fazla log üreten ayarları (oturum başı ve sonu) yalnızca gereken bölgelerde açın.
• Analitik kurallarda kullanılan alanları sıcak katmanda, ham logu soğuk katmanda tutun.
• Saklama sürelerini mevzuat ve iç politika ile hizalayın; bu tasarım merkezi log saklama mimarisi yazısının konusu.

Tespitlerin ayarlanması ve sahiplenilmesi

Kurumsal siber güvenlik izlemesinde bir tespit kuralı ancak sahibi, ayarlama geçmişi ve müdahale adımı olduğunda işletilebilir. Her kural için şunları kayda geçirin: amaç ve ATT&CK eşlemesi, veri kaynağı ve gerekli alanlar, eşik ve izin listesi gerekçesi, beklenen yanlış pozitif türleri, alarm geldiğinde ilk 15 dakikada yapılacak kontroller ve son gözden geçirme tarihi. Sahibi olmayan kural gürültüdür.

Yeni kuralları önce yalnızca kayıt üreten (alarm üretmeyen) modda birkaç hafta çalıştırın, sonuçları inceleyip eşikleri kurumun verisine göre ayarlayın. Hiç tetiklenmeyen kuralları da test edin: izinli bir tarama penceresinde kontrollü bir port taraması yapıp tarama kuralının gerçekten alarm ürettiğini görün. Hiç ötmeyen alarm, çalışıyor demek değildir. Teknik referans olarak MITRE ATT&CK teknik sayfalarındaki tespit önerilerini kullanabilirsiniz.

Log kaynaklarını SIEM’e bağlamak ve kural setini işletmek için SIEM kurulumu ve güvenlik logları ile SOC ve yönetilen güvenlik hizmetleri birlikte değerlendirilebilir.

Sık sorulan sorular

İzin verilen trafiğin loglarını tutmak gerçekten gerekli mi?

Tespit açısından evet. Beaconing, veri sızıntısı ve iç ağda yatay hareket gibi senaryoların büyük kısmı izin verilen trafikte görünür; yalnız engellenen trafik loglanırsa başarılı saldırı adımları kayıt dışı kalır. Hacim sorununu log türü bazında filtreleme ve saklama katmanlarıyla yönetin.

Beaconing tespitinde en sık yanlış pozitif kaynağı nedir?

Yazılım güncelleme servisleri, izleme ajanları, saat senkronizasyonu ve bulut uygulamalarının düzenli kontrol bağlantıları beaconing’e çok benzer. Bu hedefleri tek tek izin listesine almak yerine kaynak-hedef çiftinin ne kadar yaygın olduğuna bakın; yalnızca az sayıda cihazın gittiği hedeflere odaklanmak daha sağlıklı sonuç verir.

Firewall logları EDR varken hâlâ değerli mi?

Değerli. EDR ajanı olmayan cihazlar (yazıcı, IP kamera, OT cihazı, ağ cihazları, misafir cihazlar) ancak ağ verisiyle görülür. EDR ajanı devre dışı bırakılmış bir uç noktanın ağ davranışı da firewall loglarında görünmeye devam eder.

Tespit kuralındaki eşik değerleri nasıl belirlenmeli?

Kurumun kendi verisinden. Sorguyu birkaç haftalık log üzerinde izleme modunda çalıştırın, normal davranışın dağılımına bakın ve eşiği bu dağılımın belirgin biçimde dışında kalan değerlere göre ayarlayın. Hazır kurallardaki sayılar yalnızca başlangıç noktasıdır.