Switch Syslog Ayarı: Log Sunucusu, Seviye ve Komut Kaydı

Switch syslog ayarı, switch’in olaylarını satır satır bir log sunucusuna göndermesini sağlayan ayardır. Bu satırlar kimin girdiğini, hangi komutun yazıldığını ve hangi portun kapandığını anlatır. Ayar birkaç satırdır; switch’e log sunucusunun adresi ve gönderilecek en düşük önem derecesi yazılır.

Bu rehberde lab switch’imde log gönderimini kuruyorum ve kurulumun ötesinde üç şeyi ölçüyorum:

1. Log seviyesi. Gürültüyü azaltmak için eşiği yükseltince hangi satırlar kaybolur?
2. Komut kaydı. Kimin hangi komutu yazdığı kayda nasıl girer, kayda yanlışlıkla ne girer?
3. Sessiz sunucu. Log sunucusu susunca switch bunu fark eder mi?

Bir süpermarket şubesi genel müdürlüğe gün sonu raporu gönderir. Bu yazıda o rapor switch’in log sunucusuna gönderdiği satırlardır. Switch’in raporu gün sonunu beklemez; her satırı olduğu anda yollar.

Bu yazı, switch yapılandırma rehberimizdeki kontrol listesinin 9. adımıdır ve Kurumsal Network Kurulumu hizmetimizin switch tarafına aittir. Aynı işi müşterilerimizin ağında nasıl yürüttüğümüzü switch kurulumu ve VLAN yapılandırma hizmeti sayfamızda anlattık.

Bir syslog satırının nasıl okunduğunu, önem derecelerini ve protokolün neyi garanti etmediğini Syslog nedir yazımızda anlattık. Bu yazı o protokolün switch üzerindeki ayarıdır. Rehberin bir sonraki adımı, switch’in sayaçlarını izleme sistemine açmaktır; onu switch SNMP yapılandırması yazımızda kurduk.

Switch Syslog Ayarından Önce: Sunucu, Saat ve Yol

Switch’in göndereceği satırları bir yerin alması gerekir. Bu rehber, logları toplayacak sunucuyu zaten kurduğunuzu varsayar. Lab’daki log sunucusu Ubuntu üzerinde çalışan rsyslog; kurulumunu Linux syslog sunucusu kurulumu yazımızda anlattık.

İki ön koşul daha var:

• Switch’in saati doğru olmalı. Log satırının zamanını switch kendi saatinden yazar. Saati iç NTP sunucusuna bağlamayı switch NTP ayarı yazımızda anlattık. Bu ölçümün yapıldığı gün lab’daki NTP sunucusu kapalıydı ve switch’in saati log sunucusundan yaklaşık 35 saniye gerideydi; aşağıdaki satırlarda bu farkı göreceksiniz.
• Switch sunucuya ulaşabilmeli. Lab switch’imin yönetim adresi yönetim VLAN’ında duruyor (192.168.10.2), log sunucusu ise 192.168.1.46. İki ağ arasındaki yol switch’in ağ geçidinden geçer; ağ geçidi yoksa switch satırları üretir ama hiçbirini teslim edemez.

Switch Syslog Ayarı: Log Sunucusu ve Seviye

Önce switch’in bugün neyi, nereye kaydettiğine bakın.

Lab switch’imde log sunucusu daha önce tanımlanmıştı ve show logging şunu gösterdi:

gmsw01#show logging
Logging is enabled
Logging protocol version: 0
Console Logging: Level warnings. Messages : 5373 logged, 5716 ignored
Monitor Logging: disabled
Buffer Logging: Level informational. Messages : 10831 logged, 258 ignored
File Logging: Level emergencies. Messages : 0 logged, 11089 ignored
Switch Auditing : enabled
CLI Command Logging: disabled
Web Session Logging : disabled
SNMP Set Command Logging : disabled
Logging facility level : local7
Syslog Server Details:
192.168.1.46 : Level informational. Messages : 34 dropped
0 Messages dropped due to lack of resources
Buffer Log:
...

Çıktıda dört satır işinize yarar:

1. Buffer Logging switch’in kendi belleğindeki tampondur. Log sunucusu olmasa da satırlar burada tutulur, ama sınırlı sayıda.
2. CLI Command Logging: disabled yazılan komutların kaydedilmediğini söyler. Aşağıda açacağım.
3. Logging facility level : local7 switch’in satırlarına koyduğu kaynak etiketidir. Satır başındaki <190> gibi sayılar bu etiketle önem derecesinin birleşimidir; hesabını Syslog nedir yazısının öncelik alanı bölümünde anlattık.
4. 192.168.1.46 : Level informational log sunucusunu ve ona gönderilen en düşük önem derecesini gösterir. Satırın sonundaki 34 dropped sayacına aşağıda döneceğim.

Log sunucusunu tanımlayan satırlar şunlar:

configure
logging 192.168.1.46
level informational
exit
exit

logging satırı ayrı bir alt moda girer ve seviye orada yazılır. Lab switch’imde varsayılan seviye zaten informational geldi. Çalışan yapılandırmada seviye ayrı bir satır olarak görünmedi, orada yalnız logging 192.168.1.46 duruyordu; seviyeyi show logging çıktısındaki sunucu satırından okursunuz.

Switch Syslog Doğrulaması: Sunucuya Hangi Satırlar Ulaştı?

Tanım yapıldı. Doğrulamak için switch’te bilinen bir olay seti ürettim ve log sunucusuna ulaşan paketleri yakaladım. Olay seti dört adımdı:

1. Yanlış parola. Yanlış parolayla bir kez girmeyi denedim.
2. Başarılı giriş. Doğru parolayla girdim.
3. Port açıklaması. Kullanılmayan bir porta açıklama yazıp sildim.
4. Portu açıp kapamak. Aynı portu açıp yeniden kapattım.

Sunucuya ulaşan satırlar, switch’in her iki saniyede bir tekrarlanan gürültüsü ayıklanınca şunlardı:

<190> Sep 27 04:31:43 gmsw01-1 USER_MGR[tRpcsrv.01000]: user_mgr.c(1793) 11166 %% User ilker Failed to login because of authentication failures.
<189> Sep 27 04:31:43 gmsw01-1 TRAPMGR[tRpcsrv.01000]: traputil.c(777) 11167 %% Failed User Login with User ID: ilker.
<190> Sep 27 04:31:46 gmsw01-1 CLI_WEB[emWeb]: cmd_logger_api.c(260) 11172 %% [CLI:ilker:192.168.10.1] User has succesfully logged in.

Satırlar üç şey gösteriyor:

1. Başarılı giriş, girenin adresini taşıyor: [CLI:ilker:192.168.10.1].
2. Başarısız giriş iki satır üretti, ikisi de adressiz. Switch yanlış parolayı hangi kullanıcı adıyla denendiğini yazdı, nereden denendiğini yazmadı. Bir parola deneme saldırısında asıl soru kaynağın ne olduğudur; o soruyu bu satır cevaplamaz. Deneme saldırılarının nasıl sınırlandığını brute force nedir yazımızda anlattık.
3. Port açıklaması ve portun açılıp kapanması hiç satır üretmedi. Kablosu takılı olmayan bir port açıldığında bağlantı kurulmaz; yazılan açıklama da bir olay sayılmadı. Yapılandırma değişti, log sessiz kaldı.

Gürültünün kaynağı modemden gelen geçersiz BPDU paketleriydi ve 45 saniyede 44 satır tuttu. Aynı gürültüyü log sunucusu kurulduğu gün de ölçmüştük; bir dakikalık dökümü Syslog nedir yazısının lab bölümünde duruyor.

Log Seviyesini warnings’e Çekmek: Girişler Kaybolur

Bu kadar gürültüye verilen standart cevap şudur: log seviyesini yükseltin, sunucuya yalnız uyarı ve üstü gitsin. Seviyeyi warnings yaptım ve aynı olay setini tekrarladım:

gmsw01(config)#logging 192.168.1.46
gmsw01(config-logging)#level warnings
gmsw01(config-logging)#exit
gmsw01(config)#exit
gmsw01#show logging | include 192.168.1.46
192.168.1.46 : Level warnings. Messages : 34 dropped

İki ölçümü yan yana koyalım:

Gürültü yarıya indi, ama sunucuya giden satırların tamamı hâlâ gürültüydü. Başarılı ve başarısız girişlerin ikisi de kayboldu. Sebebi önem dereceleriydi. Gürültünün yarısı error (<187>) seviyesindeydi ve eşiği geçti. Giriş kayıtları ise informational (<190>) ve notice (<189>) seviyesindeydi ve eşikte kaldı. Eşik gürültüyü değil denetim izini kesti.

Doğrusu seviyeyi informational’da bırakmak ve gürültüyü sunucu tarafında süzmektir. Hangi satırın toplanıp hangisinin atılacağını Syslog nedir yazısının gürültü bölümünde anlattık. Aynı satırın saniyede bir tekrarı ayrıca bir arıza işaretidir; bu lab’da modeme bakan portun STP davranışını STP korumaları yazımızda ölçtük. Ben seviyeyi yeniden informational yaptım.

Switch Komut Kaydı: Kim Hangi Komutu Yazdı?

Doğrulama bir boşluk bıraktı. Portu açıp kapadım ve log hiçbir şey söylemedi. Kimin neyi değiştirdiğini görmek için komut kaydını açmak gerekir. Tek satırdır:

configure
logging cli-command
exit

Aynı olay setini üçüncü kez çalıştırdım. Sunucuya bu kez her komut ayrı bir satır olarak ulaştı:

<189> Sep 27 04:35:51 gmsw01-1 CMDLOGGER[emWeb]: cmd_logger_api.c(83) 11429 %% CLI:192.168.10.1:ilker:User  logged in.
<189> Sep 27 04:35:55 gmsw01-1 CMDLOGGER[emWeb]: cmd_logger_api.c(83) 11436 %% CLI:192.168.10.1:ilker:configure.
<189> Sep 27 04:35:57 gmsw01-1 CMDLOGGER[emWeb]: cmd_logger_api.c(83) 11439 %% CLI:192.168.10.1:ilker:interface Gi1/0/48.
<189> Sep 27 04:35:59 gmsw01-1 CMDLOGGER[emWeb]: cmd_logger_api.c(83) 11442 %% CLI:192.168.10.1:ilker:description OLCUM-15-cli.
<189> Sep 27 04:36:01 gmsw01-1 CMDLOGGER[emWeb]: cmd_logger_api.c(83) 11445 %% CLI:192.168.10.1:ilker:no shutdown.
<189> Sep 27 04:36:03 gmsw01-1 CMDLOGGER[emWeb]: cmd_logger_api.c(83) 11448 %% CLI:192.168.10.1:ilker:shutdown.
<189> Sep 27 04:36:11 gmsw01-1 CMDLOGGER[emWeb]: cmd_logger_api.c(83) 11460 %% CLI:192.168.10.1:ilker:show running-config interface Gi1/0/48.

Her satır adresi, kullanıcıyı ve komutun kendisini taşıyor. Satırlar notice seviyesinde gidiyor, yani informational eşiği onları geçirir. show komutları da yazılıyor; kimin neye baktığı da kayda giriyor.

Komut kaydı kapalıyken de bazı değişiklikler log’a düşüyor. Bunu switch’in ayrı bir kaydı yapıyor: denetim kaydı (Switch Auditing). Bu kayıt fabrika ayarında açık gelir, yani siz bir şey yapmasanız da çalışır. Komut kaydını kapatıp geçici bir kullanıcı açtım ve sildim. Log sunucusuna şu satırlar gitti:

<190> Sep 27 04:56:26 gmsw01-1 CLI_WEB[emWeb]: cmd_logger_api.c(260) 12856 %% [CLI:ilker:192.168.10.1] New user olcumdeneme2 has been added.
<190> Sep 27 04:56:26 gmsw01-1 CLI_WEB[emWeb]: cmd_logger_api.c(260) 12857 %% [CLI:ilker:192.168.10.1] Access level of user olcumdeneme2 has been set to 1.
<190> Sep 27 04:56:28 gmsw01-1 CLI_WEB[emWeb]: cmd_logger_api.c(260) 12860 %% [CLI:ilker:192.168.10.1] User olcumdeneme2 has been deleted.

Her satır işi kimin (ilker) ve hangi adresten (192.168.10.1) yaptığını taşıyor. Aynı oturumda bir portun açıklamasını da değiştirdim; bu değişiklik için tek satır gitmedi. Yani komut kaydı kapalıyken switch, kullanıcı hesaplarındaki değişiklikleri kaydediyor ama port ayarlarındaki değişiklikleri kaydetmiyor. Portlarda kimin neyi değiştirdiğini görmek istiyorsanız komut kaydını açmanız gerekir.

Neyin değiştiğini yapılandırma yedeğinin farkı da gösterir; gece alınan yedekleri karşılaştırmayı switch yapılandırma yedeği yazımızda anlattık. Yedek farkı kimin yaptığını söylemez, komut kaydı söyler. Komutları merkezi bir sunucuya sorup her birini orada kaydetmenin yolu ise switch TACACS+ yapılandırmasının komut kaydı bölümünde duruyor.

Komut Kaydı Parolayı da Yazar

Komut kaydı açıkken switch’e bir SNMPv3 izleme kullanıcısı tanımladım. Log sunucusuna şu satır gitti:

<189> Sep 27 04:45:51 gmsw01-1 CMDLOGGER[emWeb]: cmd_logger_api.c(83) 12124 %% CLI:192.168.10.1:ilker:snmp-server user izleme DefaultRead auth-sha IzlemeAuth2026 priv-aes128 IzlemePriv2026.

Komut, iki parolasıyla birlikte düz metin olarak ağdan geçti ve sunucudaki dosyaya yazıldı. Karşılaştırmak için aynı açıkken yerel bir kullanıcıyı parolasıyla tanımladım. O komut kayda hiç girmedi; switch yerine “yeni kullanıcı eklendi” satırını yazdı. Switch bir parolayı gizlemeyi biliyor, ötekini bilmiyor.

Bundan üç sonuç çıkıyor:

1. Komut kaydı açıksa log sunucusu parola taşıyan bir sunucudur. Erişimini parola kasası gibi sınırlayın.
2. Parola içeren komutu yazmadan önce komut kaydını kapatın ya da o parolayı sonradan değiştirin. SNMPv3 kullanıcısını kurduğumuz switch SNMP yapılandırması turunu bu yüzden komut kaydı kapalıyken yaptım.
3. Syslog yolu şifresizdir. Satır yönetim ağında düz metin gider; o ağı kullanıcı ağından ayırmak bu yüzden de gereklidir.

Log Sunucusu Susarsa Switch Ne Yapar?

Buraya kadar switch’in gönderdiği her satır sunucuya ulaştı. Gerçek hayatta log sunucusu iki biçimde susar: sunucu açıktır ama üzerindeki log servisi durmuştur, ya da switch ile sunucu arasındaki yol kesilmiştir. İkisini de lab’da denedim ve her denemede üç soruya baktım:

1. Switch durumu fark ediyor mu?
2. Satırlar sunucuya ulaşıyor mu?
3. Sunucu geri gelince arada kaybolan satırlar yeniden gönderiliyor mu?

Birinci sorunun cevabını switch’in kendi sayacında aradım. Başta gördüğümüz show logging çıktısında log sunucusunun satırı 34 dropped ile bitiyordu, yani “34 satır düşürüldü”. Adından beklenen, teslim edilemeyen her satırda bu sayının artmasıdır.

Log Servisi Durursa: Sunucu Reddeder, Switch Duymaz

Sunucuyu açık bıraktım ve üzerindeki log servisini 40 saniye durdurdum. Switch bu sürede 55 satır gönderdi. Sunucunun işletim sistemi bu satırların çoğuna “bu portta kimse dinlemiyor” cevabını döndü; paket yakalamasında böyle 44 cevap vardı:

04:38:01.506479 IP 192.168.1.46 > 192.168.10.2: ICMP 192.168.1.46 udp port 514 unreachable, length 153

Switch’in sayacı ise yerinden kıpırdamadı:

gmsw01#show logging | include dropped
192.168.1.46 : Level informational. Messages : 34 dropped
0 Messages dropped due to lack of resources

Sunucu satırları açıkça reddetti, ama switch bu cevaba hiç tepki vermedi: sayacı artmadı, satır göndermeyi de bırakmadı. Reddetmekle yok saymanın ağda nasıl ayrı göründüğünü ICMP yazımızda anlattık.

Ağ Geçidi Kaybolursa: Log Satırları Hiç Gönderilmez

Ön koşullarda söylediğim gibi switch satırları sunucuya ağ geçidi üzerinden gönderir. İkinci denemede ağ geçidini ortadan kaldırdım. Önce ağ geçidinin adresini sildim, ama satırlar gitmeye devam etti: switch ağ geçidinin donanım adresini ARP tablosunda hatırlıyordu. Yol, bu kaydı da silince gerçekten kesildi. Burada bir ayrıntı çıktı: düz clear arp-cache komutu ağ geçidi kaydına dokunmadı, kaydı silmek için clear arp-cache gateway gerekti.

Yol kesildikten sonraki 60 saniyede sunucuya tek bir satır ulaşmadı. Switch bu sürede ağ geçidinin adresini 49 kez sordu ve cevap alamadı. Satırları kime teslim edeceğini bilmediği için hiçbirini göndermedi. Sayaç yine 34’tü.

İki denemede de sayaç yerinde kaldı. Arttığını yalnız bir kez gördüm: switch aynı akşam yeniden başladı ve açılıştan yaklaşık çeyrek saat sonra sayaç 38’di. Bu arada log yolunu kesen hiçbir şey yapmamıştım. Hangi satırları saydığını göremedim; açılışta, switch’in ağ bağlantısı hazır olmadan üretilen satırları sayıyor olabilir. Kesin olan şu: çalışan bir switch’te bu sayaç satırların sunucuya ulaşıp ulaşmadığını göstermez.

Kaybolan Log Satırları Geri Gelmez

Üçüncü sorunun cevabı birinci denemeden geldi. Log servisi kapalıyken bir portun açıklamasını değiştirmiştim. O sırada komut kaydı açıktı, yani switch bu komut için bir log satırı üretti. Servis geri geldikten sonra o satır sunucuda yoktu; yalnız switch’in kendi tamponunda duruyordu. Syslog satırları UDP ile gider ve switch teslim edemediği satırı yeniden göndermez; nedenini Syslog nedir yazısının kayıp bölümünde anlattık.

Tamponu da yedek saymayın. Lab switch’imin tamponu 400 satır tutuyordu; modemden gelen gürültüyle bu, geriye doğru yalnız 6 dakika 38 saniyelik geçmiş demekti.

Üç sorunun cevabı da hayırdı: switch durumu fark etmedi, satırlar sunucuya ulaşmadı ve kaybolanlar sonradan gönderilmedi.

Benzetme burada kopuyor. Süpermarket şubesinin gün sonu raporu gelmezse genel müdürlük şubeyi arar. Syslog’da rapor yolda kaybolduğunda ne switch fark eder ne sunucu; o telefonu sizin kurmanız gerekir. İki yolu var:

• Sessizlik alarmı. Log sunucusunda her cihaz için son satırın ne zaman geldiğine bakan bir denetim kurun. Dakikalardır tek satır göndermeyen switch ya kapanmıştır ya da yolunu kaybetmiştir.
• İkinci kanal. İzleme sistemi switch’i SNMP ile yokluyor ve cevap alıyor ama log gelmiyorsa sorun switch’te değil, log yolundadır. İki kanal aynı anda susuyorsa önce switch’e bakın.

Switch Syslog Ayarında Sık Yapılan Hatalar

Loglar gelmiyorsa ya da kayıtta beklediğiniz satır yoksa önce şunlara bakın:

• Gürültüyü seviyeyle susturmak. warnings eşiği lab’da giriş kayıtlarının tamamını kesti, gürültünün yarısı ise geçmeye devam etti.
• Komut kaydını açmadan yapılandırma değişikliği aramak. Varsayılan kayıt kullanıcı ekleme ve silmeyi yazıyor, port değişikliklerini yazmıyor.
• Komut kaydı açıkken parola yazmak. SNMPv3 kullanıcısının iki parolası düz metin olarak log sunucusuna gitti.
• dropped sayacına güvenmek. Sayaç, sunucu reddederken de yol kopukken de sabit kaldı; teslimatın göstergesi değil.
• Tamponu yedek sanmak. Gürültülü bir switch’te tampon birkaç dakikalık geçmiş tutar.
• Başarısız girişin kaynağını switch logunda aramak. Satır kullanıcı adını yazıyor, adresi yazmıyor.
• Saati kurmadan logu kurmak. Satırın zamanı switch’in saatidir; saat kaymışsa log sunucusundaki sıralama da kayar.
• Kaydetmemek. Ayarlar yalnız çalışan yapılandırmada kalırsa switch ilk yeniden başlatmada onları kaybeder. Çalışan ve kalıcı yapılandırmanın farkını yönetilebilir switch ayarları yazımızda anlattık.

Sonuç: Switch Log Gönderir, Ulaştığını Siz Denetlersiniz

Switch syslog ayarı birkaç satırdır: log sunucusu, seviye ve istenirse komut kaydı. Lab switch’imde değer satırlarda değil, satırların söylemediklerindeydi. warnings eşiği gürültüyü değil giriş kayıtlarını kesti, komut kaydı SNMPv3 parolalarını düz metin gönderdi ve başarısız giriş kaynak adres taşımadı.

Log sunucusu sustuğunda switch’in sayacı değişmedi, kaybolan satırlar yeniden gönderilmedi. Girişteki süpermarket benzetmesinde genel müdürlük, şubeden gün sonu raporunun gelmediğini ancak onu beklediği için fark eder; log sunucusuna da o bekleyişi sizin kurmanız gerekir.

Rehberin sıradaki adımı, switch’in sayaçlarını izleme sistemine açmak ve olayları bildirmesini sağlamaktır; onu switch SNMP yapılandırması yazımızda kurduk. Sıralamanın tamamı switch yapılandırma rehberimizde duruyor.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn