Ağ Cihazları İçin Merkezi Syslog Sunucusu Kurulumu ve Log Saklama

Bir switch portu gece 03:12’de kapanıp açıldığında, bir OSPF komşuluğu düştüğünde ya da biri yetkisiz şekilde yapılandırma değiştirdiğinde iz cihazın yerel log tamponunda kalır. Tampon dolar veya cihaz yeniden başlar. İz gider. Aşağıda switch, router, firewall ve kablosuz erişim noktalarının loglarını rsyslog tabanlı merkezi bir sunucuda toplamayı, zaman damgalarını tutarlı hale getirmeyi ve saklama alanını boyutlandırmayı ağ operasyonu gözüyle anlatıyoruz.

Ağ operasyonunda merkezi logun rolü

Merkezi syslog sunucusu ağ ekibine üç şey verir: cihaz yeniden başlasa bile kalıcı kayıt, birden fazla cihazın olaylarını aynı zaman çizgisinde ilişkilendirme ve izleme sistemine bağlanabilecek tek bir olay kaynağı. Çekirdek switch’teki spanning tree topoloji değişikliği ile erişim katmanındaki port flap’lerinin aynı dakikada başladığını görmek, ancak loglar tek yerde ve aynı saatle tutuluyorsa mümkündür. Arıza anında konsolda ilk açılan pencere bu olmalıdır.

Buradaki kapsam ağ operasyonudur: arıza teşhisi, değişiklik takibi, kapasite ve donanım uyarıları. Güvenlik olaylarının korelasyonu, SIEM entegrasyonu ve mevzuata göre saklama süreleri ayrı bir tasarım konusudur; o taraf için merkezi log saklama mimarisi rehberini referans alın. İki yapı birbirine bağlanabilir: ağ syslog sunucusu logları yerelde saklarken bir kopyasını SIEM’e iletebilir.

Syslog severity seviyeleri ve facility seçimi

Syslog mesajlarının önceliği RFC 5424’te tanımlı sekiz severity seviyesiyle ifade edilir. Cihazda seçilen seviye, o seviye ve daha önemli (sayısal olarak küçük) tüm mesajların gönderilmesi anlamına gelir.

Merkezi sunucuya gönderim için genellikle informational (6) doğru seviyedir. Notice’te durmak, ACL log satırları gibi işe yarar bilgileri dışarıda bırakır. Debug ise merkezi sunucuya hiçbir zaman kalıcı açılmaz; hem cihaz CPU’sunu hem diski hızla tüketir. Sahada “geçici” açılıp aylarca unutulan debug’lar sık çıkar.

Facility alanı, alıcı tarafta mesajları sınıflandırmak için kullanılır. Ağ cihazları genellikle local0–local7 aralığından birini kullanır (Cisco IOS varsayılanı local7). Cihaz türüne göre farklı facility atamak (switch’ler local5, firewall’lar local4 gibi) rsyslog’da filtrelemeyi kolaylaştırır; yine de modern rsyslog yapılandırmasında kaynak IP’ye göre ayrıştırma daha güvenilirdir.

Zaman tutarlılığı: NTP ve timestamp ayarları

Zaman damgası tutarsız loglarla korelasyon yapılmaz; yapılırsa yanlış sonuca götürür. Tüm cihazlar aynı NTP kaynağına (tercihen iç ağda iki NTP sunucusuna) senkronize olmalı ve log satırına milisaniye ile saat dilimi bilgisi eklemelidir. Cihazlarda UTC ya da tüm ağda tek bir yerel saat dilimi kullanın. Karışık kullanım en sık gördüğümüz hatadır.

Syslog sunucusu ayrıca mesajın alındığı zamanı kaydeder. Cihaz zamanı ile alım zamanı arasında sistematik bir fark varsa NTP senkronizasyonu bozulmuştur. Cisco’da kontrol için show ntp status ve show ntp associations yeterlidir.

Cisco IOS ve diğer cihazlarda log gönderimi

Aşağıdaki Cisco IOS/IOS XE örneği NTP, zaman damgası, yerel tampon ve merkezi sunucuya gönderimi birlikte tanımlar:

clock timezone TRT 3 0
ntp server 10.10.99.1
ntp server 10.10.99.2
!
service timestamps log datetime msec localtime show-timezone
service sequence-numbers
!
logging buffered 64000 informational
logging source-interface Loopback0
logging facility local5
logging trap informational
logging origin-id hostname
logging host 10.10.99.30
!
! TCP ile gönderim (platform destekliyorsa)
! logging host 10.10.99.30 transport tcp port 514

• service sequence-numbers her mesaja sıra numarası ekler. UDP kayıplarını ancak böyle fark edersiniz.
• logging source-interface mesajların hep aynı yönetim adresinden çıkmasını sağlar; rsyslog’da cihaz bazlı dosya ayırma bu adrese dayanır.
• logging buffered merkezi sunucuya ulaşılamayan anlarda yerel kopya tutar.
• TCP portu iki tarafta aynı olmalıdır. IANA kaydında 514/tcp syslog’a değil rsh’ye aittir; yine de pek çok ürün TCP syslog için 514’ü kullanır. Cisco IOS’ta transport tcp port belirtilmezse varsayılan 601’dir. rsyslog’un dinlediği portu buna göre ayarlayın; “UDP çalışıyor, TCP’ye geçince log kesildi” vakalarının çoğu bu uyumsuzluktur.

Diğer üreticilerde mantık aynıdır: hedef sunucu, seviye, kaynak arayüz ve NTP. Kablosuz kontrolcüler ve bulut yönetimli AP’lerde syslog genellikle kontrolcü veya bulut paneli üzerinden tanımlanır; bu durumda logların AP’den değil kontrolcüden geldiğini hesaba katın.

rsyslog ile alıcı sunucu: UDP/TCP, cihaz bazlı dosyalar

Çoğu Linux dağıtımında hazır gelen rsyslog, ağ cihazları için yeterli bir alıcıdır. Aşağıdaki yapılandırma uzak logları sunucunun kendi loglarından ayırır ve her cihaz için ayrı dosya açar. Dosyayı /etc/rsyslog.d/10-network.conf olarak kaydedin:

module(load="imudp")
module(load="imtcp")

template(name="NetDevFile" type="string"
         string="/var/log/network/%FROMHOST-IP%.log")

ruleset(name="netdevices") {
    action(type="omfile" dynaFile="NetDevFile"
           dirCreateMode="0750" fileCreateMode="0640")
    stop
}

input(type="imudp" port="514" ruleset="netdevices")
input(type="imtcp" port="514" ruleset="netdevices")

Ayrı bir ruleset kullanmak, uzak mesajların /var/log/messages veya /var/log/syslog dosyasına karışmasını önler. Dosya adında cihazın gönderdiği hostname yerine %FROMHOST-IP% kullanmak bilinçli bir tercihtir: Bazı cihazlar hostname alanını standart dışı doldurur. IP–cihaz adı eşlemesi dokümantasyonda veya DNS’te tutulur.

Ardından yapılandırmayı doğrulayın, servisi yeniden başlatın ve test mesajı gönderin:

rsyslogd -N1                      # sözdizimi kontrolü
systemctl restart rsyslog
firewall-cmd --permanent --add-port=514/udp --add-port=514/tcp
firewall-cmd --reload
logger -n 10.10.99.30 -P 514 -d "syslog alim testi"   # UDP test
tcpdump -ni any port 514          # cihazdan gelen paketleri gözlemleme

UDP 514 geniş uyumluluk sağlar ama teslim garantisi yoktur. Ağ tıkanıklığı anında kaybolan loglar, tam da ihtiyaç duyacağınız loglardır. Cihaz destekliyorsa TCP tercih edin; güvenilmeyen bir ağ kesitinden geçiliyorsa TLS üzerinden syslog (RFC 5425) değerlendirin. Syslog sunucusuna yalnız yönetim ağından erişim verin.

Saklama süresi, logrotate ve disk boyutlandırma

Cihaz bazlı dosyalar logrotate ile döndürülür. /etc/logrotate.d/network örneği:

/var/log/network/*.log {
    daily
    rotate 180
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        systemctl kill -s HUP rsyslog.service
    endscript
}

Bu yapılandırma 180 günlük geçmiş tutar; süreyi kurum politikanıza göre belirleyin. Disk boyutu için örnek hesap: 150 cihaz, cihaz başına günde ortalama 4.000 mesaj ve mesaj başına 200 bayt varsayılırsa günlük ham hacim 150 × 4.000 × 200 = 120 MB olur; 180 günlük sıkıştırılmamış toplam yaklaşık 21,6 GB eder. Metin loglar gzip ile tipik olarak birkaç kat küçülür; oranı kendi verinizde ölçün. Asıl risk ortalama değil, ani artıştır. Bir döngü (loop) veya flap eden bir uplink dakikalar içinde binlerce mesaj üretebilir. Bu yüzden /var/log/network ayrı bir dosya sistemine konmalı ve doluluğu izlenmelidir; log diski dolduğunda sunucunun kendi servisleri etkilenmemelidir.

Alarm üretmesi gereken kritik ağ log mesajları

Logu toplamak işin yarısıdır. Belirli mesajlar izleme sistemine alarm olarak düşmelidir. Aşağıdaki Cisco mesaj türleri ağ operasyonu için iyi bir başlangıç listesidir; diğer üreticilerin eşdeğer mesajlarını aynı mantıkla eşleyin:

Erişim portlarındaki her LINK-3-UPDOWN mesajı alarm olmamalıdır; kullanıcı bilgisayarlarının açılıp kapanması bu mesajı üretir. Alarm kuralını uplink, sunucu ve trunk portlarıyla sınırlamak için port açıklamalarında tutarlı bir isimlendirme kullanın; kural yazmak böylece kolaylaşır. SYS-5-CONFIG_I mesajlarını sürümlü konfigürasyon yedeğiyle birleştirmek “kim, ne zaman, neyi değiştirdi” sorusunu kapatır; kurulumu Oxidized ile konfigürasyon yedekleme yazısında. Logları bir izleme platformuna bağlamak için ağ izleme yazılımı karşılaştırması, log kanıtıyla yavaşlık teşhisi için ağ yavaşlığında sorun giderme yazısına bakın.

Syslog, NTP ve izleme altyapısının birlikte kurulup periyodik olarak gözden geçirilmesi ağ bakım, izleme ve periyodik kontrol hizmetinin kapsamındadır.

Sık sorulan sorular

Syslog için UDP mi TCP mi kullanılmalı?

UDP 514 en geniş uyumluluğu sağlar ama teslim garantisi yoktur; tıkanıklık anında mesajlar kaybolabilir. Cihaz destekliyorsa TCP tercih edin; güvenilmeyen bir ağ kesitinden geçiliyorsa TLS üzerinden syslog değerlendirin.

Cihazlarda hangi log seviyesi seçilmeli?

Merkezi sunucuya gönderim için informational (6) genellikle doğru dengedir. Debug seviyesi yalnız sorun giderme sırasında ve geçici olarak açılır; merkezi sunucuya kalıcı gönderilmez.

Loglar ne kadar süre saklanmalı?

Ağ operasyonu için süre, arıza ve değişiklik incelemelerinde ne kadar geriye bakmanız gerektiğine göre belirlenir. Güvenlik ve mevzuat kaynaklı saklama yükümlülükleri ayrıca değerlendirilmeli ve kurum politikasına yazılmalıdır.

Log dosyalarında neden hostname yerine IP adresi kullanılıyor?

Bazı ağ cihazları syslog mesajındaki hostname alanını standart dışı biçimde doldurur veya hiç doldurmaz. Kaynak IP, logging source-interface ile sabitlendiğinde cihazı güvenilir şekilde tanımlar; IP ile cihaz adı eşlemesi dokümantasyonda veya DNS’te tutulur.