Incident sonrası en pahalı cümlelerden biri şudur: “Log gelmemiş.” Ağ cihazı logları; kim girdi, hangi komut çalıştı, hangi interface flap oldu, hangi ACL hit aldı gibi olayların kanıt katmanıdır. Ama syslog dünyasında üç klasik problem vardır:
- UDP kaybı: yoğunlukta paket düşer, kanıt kaybolur.
- Log storm: tek bir arıza (örn. flap) binlerce satır üretir, pipeline’ı boğar.
- Güven: TLS yoksa, loglar yolda görülebilir/manipüle edilebilir; özellikle yönetim ağında risk büyür.
Bu yazıda, ağ cihazı loglamasını “bir ayar” değil, dayanıklı bir mimari olarak ele alıyorum.
Hedef: üç soruya kesintisiz cevap
İyi bir syslog mimarisinin sahadaki başarı ölçütü:
- Collector kesilince loglar kayboluyor mu, kuyruklanıyor mu?
- Log storm olunca pipeline çöküyor mu, kontrollü kısıyor mu?
- Loglar şifreli ve kimliği doğrulanmış şekilde taşınıyor mu?
TLS: her cihaz desteklemiyorsa bile mimari çözülür
Gerçek hayatta bazı ağ cihazları syslog’u TLS ile gönderemez. Bu durumda iki pratik yaklaşım:
- Yerel relay: cihaz → (UDP/TCP) → aynı segmentte relay → (TLS) → merkezi collector
- Out-of-band management: syslog trafiğini yönetim ağında, dar ACL’lerle taşımak
Relay üzerinde TLS (tercihen mTLS) kullanmak; “yolda dinleme” riskini düşürür ve collector tarafında kaynak doğrulamasını kolaylaştırır.
Buffering / Queue: collector down iken ne olur?
Üretimde collector kesintisi kaçınılmazdır (bakım, disk dolması, network problem). Bu yüzden:
- Relay/agent üzerinde disk-backed queue kullanın
- Kuyruk için maksimum disk ve drop policy belirleyin
- “Queue doluyor” alarmını, “log yok” alarmından önce görün
Bu yaklaşım; “collector down → log kaybı” zincirini kırar.
Log storm: flood’u “gürültü”ye çevirmeden yönet
Log storm’un tipik kaynakları:
- Interface flap (özellikle fiber/edge)
- Routing adjacency flap
- Authentication denemeleri (brute force / yanlış config)
- ACL hit patlaması (DDoS / scan)
Log storm’a karşı iki katman:
- Kaynakta sınırlama: cihaz tarafında severity, facility, sampling (mümkünse)
- Pipeline’da sınırlama: per-source rate limit, burst tolerance, ayrı kuyruklar
Timestamp: NTP yoksa syslog da yok
Syslog’da zaman, olayın kendisi kadar önemlidir. Bu yüzden:
- Cihazlar NTP/chrony hiyerarşisine bağlı olsun
- Zaman drift alarmları syslog pipeline’ına dahil olsun
- Collector tarafında ingest time ile event time farkı izlenebilsin
Minimum “kanıt seti”: incident ve audit için hangi loglar kritik?
Üretimde “her şeyi alalım” yaklaşımı pahalıdır. Benim minimum kanıt setim:
- AAA login/logout, başarısız deneme
- Konfig değişikliği (commit/save, user, source)
- Routing adjacency up/down
- Uplink interface up/down
- CPU/memory kritik eşikler (cihaz destekliyorsa)
Test: bir kere değil, düzenli tatbikat
Bu mimariyi doğrulamanın en iyi yolu basit bir tatbikat:
- Collector bağlantısını kes (kontrollü)
- 10 dakika log üret (ör. test interface flap)
- Bağlantıyı geri getir
- Logların “geri aktığını” ve sıra/bozulma davranışını gözlemle
Eğer bu tatbikat yoksa, “dayanıklı syslog” sadece bir inanç olur.
Kapanış
Ağ cihazı syslog mimarisi; güvenlik ve operasyon liderliği açısından kritik bir “görünürlük sözleşmesi”dir. TLS, buffering ve log storm yönetimi ile syslog’u sadece bir çıkış değil; incident anında güvenilen bir kanıt hattı haline getirebilirsiniz.