Çoğu küçük ve orta ölçekli işletme, logları yalnızca bir sorun yaşandığında kontrol eder. O noktada kritik loglar çoktan üzerine yazılmış, disk alanı dolduğu için kayıtlar kesilmiş veya ilgili sunucuya erişim mümkün olmayabilir. Sorunun ne zaman başladığını, hangi hesapla gerçekleştirildiğini ve hangi sistemleri etkilediğini anlamak için geriye dönük veri yoktur.
Merkezi log yönetimi bu tabloyu kökten değiştirir. Tüm sistemlerden gelen loglar tek bir noktada toplanır, korelasyon yapılabilir, alarm kuralları tanımlanır ve saklama politikasıyla uyumluluk sağlanır. Bu yazıda merkezi log toplamanın neden gerekli olduğunu, nasıl kurgulandığını ve hangi adımlarla başlanabileceğini ele alıyoruz.
1. Log dağınıklığının maliyeti
Tipik bir KOBİ ortamında loglar farklı yerlerde dağınık halde bulunur: Windows sunucularda Event Viewer, Linux sunucularda /var/log altındaki dosyalar, ağ cihazlarında kendi dahili bellekleri, uygulamalarda farklı dizinlere yazılan log dosyaları. Her birinin formatı, saklama süresi ve erişim yöntemi farklıdır.
Bu dağınıklığın pratik sonuçları ciddidir. Bir güvenlik olayı araştırılırken birden fazla sunucuya tek tek bağlanmak, farklı log formatlarını okumak ve zaman damgalarını elle eşleştirmek gerekir. Bu süreç saatler alır ve hata payı yüksektir. Ayrıca saldırganlar ele geçirdikleri sunucudaki logları silebilir veya değiştirebilir; loglar yalnızca kaynak sunucuda tutuluyorsa bu kanıtlar geri getirilemez.
Disk alanı yönetimi de ayrı bir sorundur. Logrotate veya benzeri bir mekanizma yoksa loglar diski doldurarak servis kesintisine neden olabilir. Aşırı agresif rotasyon ise soruşturma için gereken verilerin erken silinmesine yol açar.
2. Hangi logları toplamalısınız?
Her şeyi toplamak cazip görünse de gerçekte depolama maliyeti ve analiz kapasitesi bunu sınırlar. Önceliklendirme yaparak başlamak daha sürdürülebilir bir yaklaşımdır.
Kimlik doğrulama logları: Başarılı ve başarısız oturum açma denemeleri, hesap kilitlemeleri, parola değişiklikleri. Windows ortamında Event ID 4624, 4625, 4740, 4723 gibi olaylar bu kategoriye girer. Linux tarafında /var/log/auth.log veya /var/log/secure dosyaları izlenmelidir.
Sistem logları: Servis başlatma/durdurma olayları, disk ve bellek uyarıları, zamanlanmış görev çalışma kayıtları, sistem yeniden başlatmaları. Bu loglar altyapı sağlığının temel göstergeleridir.
Uygulama logları: Web sunucusu erişim ve hata logları, veritabanı bağlantı ve sorgu logları, iş uygulamalarının kendi ürettiği kayıtlar. Bu loglar hem performans sorunlarını hem de uygulama katmanındaki güvenlik olaylarını gösterir.
Ağ ve güvenlik duvarı logları: İzin verilen ve engellenen bağlantılar, NAT çevirileri, VPN oturum kayıtları. Ağ katmanındaki görünürlük, yanal hareket ve veri sızıntısı tespiti için temeldir.
# Windows Event Log - kritik olay ID'leri
# 4624 - Basarili oturum acma
# 4625 - Basarisiz oturum acma
# 4720 - Yeni hesap olusturuldu
# 4726 - Hesap silindi
# 4732 - Yerel gruba uye eklendi
# 4740 - Hesap kilitlendi
# 4756 - Universal gruba uye eklendi
# 1102 - Denetim logu temizlendi (kritik uyari)3. Merkezi toplama nasıl çalışır?
Merkezi log toplama, kaynak sistemlerdeki logları bir ağ protokolü aracılığıyla merkezi bir sunucuya iletme mantığına dayanır. Linux ve ağ cihazları tarafında Syslog (UDP 514 veya TCP 514) en yaygın protokoldür. Windows tarafında ise Windows Event Forwarding (WEF) veya bir agent tabanlı çözüm kullanılır.
Temel bir rsyslog yapılandırması ile Linux sunuculardan merkezi toplama başlatılabilir:
# Merkezi log sunucusu - /etc/rsyslog.conf
# TCP uzerinden syslog kabul et
module(load="imtcp")
input(type="imtcp" port="514")
# Gelen loglari kaynak sunucuya gore ayir
template(name="RemoteLogs" type="string"
string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
*.* ?RemoteLogs# Istemci sunucu - /etc/rsyslog.conf
# Tum loglari merkezi sunucuya gonder (TCP)
*.* @@log-sunucu.firma.local:514Windows ortamında Windows Event Forwarding yapılandırması Group Policy ile yönetilebilir. Collector sunucu olarak belirlenen makinede Windows Event Collector (WEC) servisi etkinleştirilir ve kaynak bilgisayarlar subscription tanımlarına göre belirli Event ID'leri merkeze iletir.
# WEF - Collector sunucuda servisi etkinlestir
wecutil qc /q
# Yeni bir subscription olustur (XML tabanli)
wecutil cs subscription.xml
# Mevcut subscription'lari listele
wecutil es
# Subscription durumunu kontrol et
wecutil gs "Guvenlik-Loglari"Toplanan logların düz metin dosyaları olarak saklanması yerine yapılandırılmış bir veritabanına veya indeksleme motoruna yazılması, arama ve korelasyon işlemlerini çok daha verimli hale getirir. Ancak başlangıç için rsyslog ile dosya tabanlı toplama bile dağınık yapıdan çok daha iyi bir konumdur.
4. Korelasyon ve alarm kurgusu
Logları toplamak tek başına yeterli değildir; anlamlı olayları tespit edecek kurallar tanımlanmalıdır. Korelasyon, farklı kaynaklardan gelen logları bir araya getirerek tek başına anlamsız görünen olaylardan anlamlı desenler çıkarmaktır.
Basit ama etkili korelasyon örnekleri:
- Kaba kuvvet tespiti: Aynı IP adresinden 5 dakika içinde 10'dan fazla başarısız oturum açma denemesi.
- Hesap ele geçirme şüphesi: Başarısız denemeler ardından başarılı oturum açma ve hemen ardından yetki değişikliği.
- Servis anomalisi: Kritik bir servisin mesai saatleri dışında yeniden başlatılması.
- Disk ve yedekleme korelasyonu: Disk alanı uyarısı ile aynı sunucuda yedekleme hatasının aynı zaman diliminde gerçekleşmesi.
- Log silme uyarısı: Windows Event ID 1102 (denetim logu temizlendi) olayı her zaman kritik alarm tetiklemelidir.
Alarm kurgusunda eşik değerleri ortama göre ayarlanmalıdır. Çok düşük eşikler yanlış pozitif alarm yorgunluğuna, çok yüksek eşikler ise gerçek olayların gözden kaçmasına neden olur. Başlangıçta geniş eşiklerle başlayıp zamanla ortamınızın normal davranış profiline göre daraltmak en sağlıklı yaklaşımdır.
# Ornek: rsyslog ile basarisiz SSH girislerini sayma
# /etc/rsyslog.d/ssh-alarm.conf
if $programname == 'sshd' and $msg contains 'Failed password' then {
action(type="omfile" file="/var/log/ssh-failed.log")
}
# Basit bir alarm scripti (cron ile 5 dk'da bir calistir)
#!/bin/bash
THRESHOLD=10
COUNT=$(grep -c "Failed password" /var/log/ssh-failed.log)
if [ "$COUNT" -gt "$THRESHOLD" ]; then
echo "SSH brute-force tespit edildi: $COUNT basarisiz deneme" | \
mail -s "ALARM: SSH Brute-Force" admin@firma.com
fi5. Saklama politikası
Logların ne kadar süre saklanacağı, hem teknik kapasite hem de yasal uyumluluk açısından belirlenmesi gereken bir karardır. Farklı log türleri için farklı saklama süreleri tanımlamak hem depolama maliyetini optimize eder hem de gerektiğinde verilerin mevcut olmasını sağlar.
Genel bir yol haritası olarak:
- Kimlik doğrulama logları: Minimum 12 ay. Güvenlik soruşturmalarında geriye dönük analiz için kritiktir.
- Güvenlik duvarı ve ağ logları: Minimum 6 ay. Yanal hareket ve veri sızıntısı analizleri için gereklidir.
- Sistem logları: 3-6 ay. Tekrarlayan altyapı sorunlarının kök neden analizinde kullanılır.
- Uygulama logları: 1-3 ay. Debug ve performans analizi için yeterlidir; ancak kritik uygulamalarda süre uzatılabilir.
- Erişim logları (web sunucusu): 3-6 ay. Saldırı vektörü analizi ve trafik deseni incelemesi için gereklidir.
Depolama planlaması yaparken günlük log hacmini ölçmek ilk adımdır. Sıkıştırma ile ham log boyutunun genellikle yüzde 5-10'u kadar alana düşürülebilir. Soğuk depolama (cold storage) stratejisi ile eski loglar ucuz depolama katmanlarına taşınabilir.
# Gunluk log hacmini olcme
du -sh /var/log/remote/*/ # Sunucu basina gunluk boyut
find /var/log/remote/ -name "*.log" -mtime -1 -exec du -ch {} + | tail -1
# Logrotate ile sıkıştırma ve rotasyon
# /etc/logrotate.d/remote-logs
/var/log/remote/*/*.log {
daily
rotate 180
compress
delaycompress
missingok
notifempty
create 0640 syslog adm
}Yasal uyumluluk gereksinimleriniz varsa (KVKK, sektörel düzenlemeler) saklama sürelerini bu gereksinimlere göre belirleyin. Gerektiğinde hukuki danışmanlık alarak minimum saklama süresini netleştirin.
6. Hızlı kontrol listesi
- Tüm sunucu ve ağ cihazlarının logları merkezi bir noktada toplanıyor mu?
- Kimlik doğrulama logları (başarılı ve başarısız giriş) izleniyor mu?
- Log iletimi için güvenli bir protokol (TCP/TLS) kullanılıyor mu?
- Kritik olaylar için alarm kuralları tanımlı mı (kaba kuvvet, log silme, yetki değişikliği)?
- Saklama politikası log türüne göre belirlenmiş mi?
- Logların bütünlüğü korunuyor mu (kaynak sunucuda silinse bile merkezi kopya mevcut mu)?
- Disk alanı izlemesi yapılıyor mu (log sunucusunun diski dolma riski)?
- Log arama ve filtreleme altyapısı mevcut mu?
- Alarm bildirimleri doğru kişilere ulaşıyor mu?
- Yedekleme ve log toplama sistemleri birbirinden haberdar mı?
Logları toplamak başlangıçtır; asıl değer, bu loglardan anlamlı alarmlar üreterek olaylara sorun büyümeden müdahale edebilmektedir.
Sonuç
Merkezi log yönetimi, güvenlik olaylarını tespit etmenin, altyapı sorunlarını erken yakalamanın ve uyumluluk gereksinimlerini karşılamanın temelidir. Küçük bir rsyslog yapılandırmasıyla başlayarak bile dağınık log yapısından merkezi görünürlüğe geçiş sağlanabilir.
Log toplama, korelasyon ve alarm altyapısı kurulumu konusunda destek almak isterseniz log yönetimi hizmetlerimi inceleyebilirsiniz. Daha kapsamlı bir güvenlik izleme çalışması için siber güvenlik hizmetleri de birlikte değerlendirilebilir. Sorularınız için benimle iletişime geçebilirsiniz.