Syslog Nedir? Facility, Severity ve 514 Portu

Syslog, bir cihazın başına gelenleri düz metin satırları hâlinde yazıp merkezî bir sunucuya göndermesini sağlayan protokoldür. Switch’ler, firewall’lar, sunucular, yazıcılar ve kesintisiz güç kaynakları bunu kırk yıldır neredeyse aynı biçimde yapar: olay olur, cihaz bir satır üretir, o satır ağa çıkar. Sizin tarafınızda yapılması gereken tek şey, o satırı dinleyecek birinin bulunmasıdır.

Bir duruşma salonunda zabıt katibi tam olarak bunu yapar. Hâkim konuşur, taraflar konuşur, tanık konuşur; katip söylenenleri yorumlamadan, olduğu gibi ve saatiyle yazar. Katibin işi karar vermek değildir, hatta ne konuşulduğunu anlamak zorunda bile değildir. İşi kaydın var olmasını sağlamaktır. Duruşma bittikten aylar sonra bir itiraz geldiğinde herkesin başvurduğu şey hafızalar değil, o tutanaktır.

Ağdaki cihazlarınız da sürekli konuşuyor. Sorun konuşmamaları değil, çoğu kurumda katibin olmaması. Bu yazıda bir syslog satırının neye benzediğini, baştaki köşeli parantezin içindeki sayının nasıl çözüldüğünü, protokolün neden UDP 514’ü seçtiğini ve neyi taşımadığını ele alıyoruz. Sonunda da lab switch’imden gelen gerçek kayıtlara bakıp asıl zor soruya geliyoruz: kayıtlar akmaya başladığında onların hangisi işe yarar?

Elinizde zaten bir log satırı varsa ve doğrudan onu çözmek istiyorsanız, bir syslog satırının anatomisine geçebilirsiniz.

Bu makale Kurumsal Ağ Protokolleri rehberimizin “görmek” ayağına, yani cihazların kendi durumlarını dışarı bildirme biçimine odaklanır.

Syslog Nedir ve Hangi Sorunu Çözer?

Syslog, olayları üreten cihaz ile o olayları saklayan sunucuyu birbirinden ayırır. Cihaz yalnızca “şu oldu” der ve satırı ağa bırakır; satırın nereye yazılacağı, ne kadar saklanacağı ve kimin okuyacağı artık cihazın sorunu değildir. Protokolün bütün gücü bu ayrımdan gelir, ve bütün eksikleri de.

Katip benzetmesi burada birebir oturuyor. Hâkim tutanağı kendi tutmaz. Tutsaydı iki iş birden yapmak zorunda kalırdı ve ikisini de kötü yapardı.

Kayıt Tutulmayan Olay Olmamış Sayılır

Bir arızanın en pahalı hâli, iz bırakmadan geçenidir. Gece üçte bir port bir dakikalığına düşüp geri kalkarsa, sabah kimse bir şey fark etmez. Kullanıcılar “internet bir ara gitti galiba” der, siz bakarsınız her şey normaldir, ve aynı şey üç hafta sonra tekrarlanır.

Bu, teşhis edilemeyen bir arıza değildir. Kaydı olmayan bir arızadır. İkisi arasındaki fark, elinizde tutanak olup olmamasıdır.

Cihazın Kendi Üstündeki Log Neden Yetmez?

Her switch ve firewall kendi içinde bir kayıt tutar. Sorun bu kaydın var olması değil, üç ayrı şekilde elinizden kaçmasıdır:

1. Kalıcı değildir. Cihazın hafızasındaki kayıt alanı yetersiz gelebilir ya da elektrik gidince silinebilir.
2. Sınırlıdır. Alan dolduğunda en eski satırların üzerine yazılır. Cihaz ne kadar konuşkansa geçmiş o kadar kısalır.
3. Arıza anında ulaşılamaz. Asıl ihtiyaç duyduğunuz an, cihazın kendisinin cevap vermediği andır. Kayıt oradaysa, o kayda da ulaşamazsınız.

Birinci maddeyi lab switch’imde ölçtüm ve kanıtı ilginç bir yerde duruyor. Switch elektrik kesintisiyle yeniden başladıktan sonra hafızasındaki kayıt defterinin en eski satırı şuydu:

<185> Aug 19 06:57:16 0.0.0.0-1 SIM[Cnfgr_Thread ]: sim_util.c(3804) 8 %% Switch was reset due to power disruption.

Bu satırın öncesi yok. Kesintiden önceki bütün geçmiş, kesintiyle birlikte gitti. Cihaz size hafızasını kaybettiğini söylüyor, ve bunu kaybettiği hafızanın içinden söylüyor.

Syslog Ne Zaman Gerekmez?

Üç kişilik bir ofiste, tek bir modem ve tek bir switch varsa merkezi log kurmak gereksiz bir katman olur. Cihaz sayısı bir elin parmaklarını geçmiyorsa ve arıza olduğunda tek tek bakmak birkaç dakika sürüyorsa, çözüm zaten elinizdedir.

Eşik cihaz sayısında değil, soruyu cevaplama süresindedir. “Dün akşam saat kaçta ne oldu” sorusuna cihazlara tek tek bakarak cevap veremiyorsanız, merkezi log gerekiyor demektir.

Burada sahada çok sık gördüğüm bir durumu ayırmak gerekiyor. Birçok kurumda merkezi log yoktur ama tek bir yapılandırılmış kayıt vardır: RADIUS accounting. Kablosuz ağ ya da 802.1X kurulurken kendiliğinden gelir, kimse ayrıca kurmaz, ve yıllarca birikir. Bu gerçek bir kayıttır, ama farklı bir soruyu cevaplar:

• RADIUS accounting oturumları kaydeder: kim, ne zaman bağlandı, ne zaman ayrıldı, ne kadar trafik geçti. Yapısı bellidir, alanları sabittir. Ayrıntısı RADIUS protokolü rehberimizde.
• Syslog olayları kaydeder: hangi port düştü, hangi süreç hata verdi, hangi yapılandırma değişti. Yapısı serbesttir, cümledir.

Biri “kim girdi” sorusunun, diğeri “ne bozuldu” sorusunun cevabıdır. Elinizde yalnız birincisi varsa, ikinci soruya cevap verecek kaydınız hiç yok demektir.

Üçüncü bir kanal daha var ve onu da karıştırmamak gerekiyor: SNMP. SNMP cihazdan sayı çeker, syslog ise cihazın ürettiği cümleyi alır. İşlemcinin yüzde seksende olduğunu SNMP söyler; o yükün hangi süreçten geldiğini syslog söyler. İkisi rakip değil, aynı olayın iki farklı kanalıdır ve doğru kurulum ikisini birden toplar. Ayrımı SNMP protokolü yazımızda mekanizma düzeyinde ele alıyoruz.

Windows Neden Kendiliğinden Syslog Göndermez?

Karışık bir ağda merkezi log kurarken en sık takılınan yer burasıdır. Switch, firewall, yazıcı ve Linux sunucular syslog’u doğrudan konuşur; Windows konuşmaz.

Windows olaylarını Event Log’a yazar. Bu ayrı bir sistemdir: kayıtlar düz metin satırı değil, kimlik numarası ve alanları olan yapılandırılmış nesnelerdir. Bir olayın 4624 numarası vardır, gövdesi ayrı alanlara bölünmüştür ve dosya biçimi metin değildir.

Sonuç pratikte şudur: ağdaki cihazların çoğunu toplayıcıya bağlamak tek satırlık bir ayardır, Windows sunucular ise araya çeviri yapan bir ajan ister. Planlama yaparken bu iki grubu ayrı düşünün; aksi halde kurulum bittiğinde “her şey akıyor ama sunucular yok” tablosuyla karşılaşırsınız.

Syslog Mesajı Neye Benzer? Bir Satırın Anatomisi

Bir syslog mesajı düz metindir ve üç parçadan oluşur: öncelik alanı, zaman ve kaynak bilgisi, gövde. Tamamı tek satırdır, ayraç yoktur, uzunluğu değişkendir.

Lab switch’imin gönderdiği gerçek bir satır:

<189> Aug 19 06:57:33 sercebilisimsw01-1 TRAPMGR[trapTask]: traputil.c(735) 235 %% Link Up: Vl5

Bu satıra bakarken üç yere dikkat edin:

• Baştaki <189> süs değil, protokolün taşıdığı tek yapısal bilgidir.
• Ortadaki kısım kaydı kime ve ne zamana bağlar.
• Sondaki metin cihaz üreticisinin serbestçe yazdığı bölümdür ve hiçbir standarda uymak zorunda değildir.

Öncelik Alanı: Baştaki Köşeli Parantezin İçindeki Sayı

Öncelik alanı (PRI), iki ayrı bilgiyi tek bir sayıya sıkıştırır: mesajın hangi kaynaktan geldiği ve ne kadar acil olduğu. Formül tek satır:

PRI = (facility × 8) + severity

İlk okuyuşta kafa karıştırıyorsa bu normaldir, çünkü ortada tek bir sayı var ve içine iki ayrı bilgi gömülü; hangisinin nerede bittiği görünmüyor. Bir örnek üzerinden bölünce yerine oturuyor. Yukarıdaki satırın 189 değerini açalım:

1. 189 ÷ 8 = 23, kalan 5.
2. Bölüm 23, yani facility 23.
3. Kalan 5, yani severity 5.

Facility 23 local7e, severity 5 noticea karşılık gelir. Yani bu satır, local7 tesisinden gelen bilgilendirici bir kayıttır.

Bu çözümün doğru olduğunu tahmin etmek yerine cihaza sordum:

show logging

Logging is enabled
Console Logging: Level warnings. Messages : 85 logged, 315 ignored
Buffer Logging: Level informational. Messages : 210 logged, 190 ignored
File Logging: Level emergencies. Messages : 0 logged, 400 ignored
Logging facility level : local7

Son satır local7 diyor. Hesabın bölüm kısmı cihazın kendi ayarıyla birebir tutuyor.

local7’nin tam olarak ne olduğuna ve neden sekiz tane local değeri bulunduğuna birazdan geliyoruz; şimdiden merak ettiyseniz tesis değerlerini anlattığımız bölüme atlayabilirsiniz. Buradaki tek iddia şu: hesap tutuyor.

Zaman, Kaynak ve Gövde

Öncelik alanından sonra gelen kısım kaydı bir ana ve bir cihaza bağlar. Yukarıdaki satırda Aug 19 06:57:33 zaman damgası, sercebilisimsw01-1 ise cihazın kendini tanıttığı isimdir.

Bu iki alanın kaynağı farklıdır ve ikisine de aynı derecede güvenilmez. Zaman damgasını cihaz kendi saatinden okur; saati kaymışsa kayıt yanlış anla arşive girer. Cihaz adını da yine cihazın kendisi yazar, yani toplayıcı bu ismi doğrulamaz, olduğu gibi kabul eder. Lab switch’imin sercebilisimsw01-1 demesinin sebebi, o ismin cihaza elle verilmiş olmasıdır; sondaki -1 ise yığın (stack) içindeki birim numarasıdır ve tek cihazlı kurulumda bile görünür.

Gövde tarafında standart biter. TRAPMGR[trapTask]: traputil.c(735) 235 %% Link Up: Vl5 ifadesi tamamen cihaz üreticisinin tercihidir ve dört parça taşır:

1. TRAPMGR[trapTask] : mesajı üreten süreç ve iş parçacığı.
2. traputil.c(735) : üretici yazılımının hangi kaynak dosyasının kaçıncı satırından geldiği.
3. 235 : cihazın kendi olay sayacı, her mesajda bir artar.
4. %% Link Up: Vl5 : insan tarafından okunacak asıl mesaj.

Bu dört parçadan yalnız sonuncusu sizin için yazılmıştır; ilk üçü üreticinin destek ekibi içindir. Başka bir markanın cihazı aynı olayı bambaşka bir cümleyle bildirir, çünkü bu alanın biçimini hiçbir standart belirlemez.

Bu, protokolün en çok yanlış anlaşılan tarafıdır. Syslog mesajın nasıl taşınacağını standartlaştırır, ne yazacağını değil. Farklı markaları aynı toplayıcıya bağladığınızda kayıtlar yan yana durur ama aynı dili konuşmaz.

RFC 3164 ve RFC 5424: İki Format, İkisi de Sahada

Syslog’un iki format tanımı vardır ve sahada ikisiyle de karşılaşırsınız:

Lab switch’im Aug 19 06:57:33 yazıyor, yani eski formatı kullanıyor. Yılın olmaması küçük bir ayrıntı gibi durur ama uzun saklamada sorun çıkarır: iki yıl arşivlenen bir kayıtta “19 Ağustos” hangi yılın 19 Ağustos’udur? Toplayıcı bu boşluğu kendi aldığı andan doldurur, yani doğruluk cihazın değil sunucunun saatine bağlanır.

Syslog Facility ve Severity: Tek Sayının İçindeki İki Bilgi

Severity mesajın ne kadar acil olduğunu, facility ise nereden geldiğini söyler. İkisi bağımsızdır: bir yazıcıdan da kritik mesaj gelebilir, çekirdekten de bilgilendirme.

Tutanağın kapağında da aynı iki bilgi durur: hangi mahkemenin tuttuğu ve dosyanın aciliyeti. İkisi ayrı ayrı yazılır, çünkü biri evrakın nereye dosyalanacağını, diğeri kimin ne zaman bakacağını belirler. Syslog bu iki bilgiyi tek bir sayının içine sıkıştırır, ve o sayıyı ayırmak toplayıcının ilk işidir.

Sekiz Önem Derecesi ve Sahada Hangisinin İşe Yaradığı

Severity sekiz değer alır ve küçük sayı daha acil demektir:

Sayının küçüldükçe acilleşmesi ilk bakışta ters gelir, ama sıralama bir kez öğrenildiğinde eşik mantığı kendiliğinden oturur.

Aynı cihazdan gelen iki satırı yan yana koyunca ayrım somutlaşıyor:

<189> Aug 19 06:57:33 sercebilisimsw01-1 TRAPMGR[trapTask]: %% Link Up: Vl5
<185> Aug 19 06:57:16 0.0.0.0-1 SIM[Cnfgr_Thread ]: %% Switch was reset due to power disruption.

1. 189 = 23 × 8 + 5 → local7.notice. Bir arayüz ayağa kalktı. Normal işleyiş.
2. 185 = 23 × 8 + 1 → local7.alert. Cihaz elektrik kesintisi yüzünden yeniden başladı. Sabah ilk bakılacak satır budur.

Aradaki fark tek karakter. Ama o tek karakter, “her şey yolunda” ile “gece burada bir şey oldu” arasındaki farktır.

Yirmi Dört Tesis ve local0-local7 Neden Ayrılmış?

Facility toplam 24 değer alır ve bu 24 değer ikiye ayrılır. Ayrımın sebebi tarihsel.

İlk 16’sının anlamı sabittir ve değiştiremezsiniz. Bu liste 1980’lerin Unix sunucusundan kalma: kern çekirdek, mail posta servisi, auth kimlik doğrulama, lpr yazıcı kuyruğu. Bir switch’in ya da firewall’un bu listede karşılığı yok, çünkü liste yazıldığında “ağ cihazı” diye bir kategori henüz yoktu.

Kalan 8’i ise bilerek tanımsız bırakılmıştır. Adları local0’dan local7’ye kadar gider ve anlamlarını siz verirsiniz. Standart size “local4 şu demektir” demez; ne derseniz odur.

Sahada şöyle kullanılır: her cihaz sınıfına bir değer atarsınız, toplayıcıda da her değeri ayrı bir yere yazarsınız.

Kazanç şu: bir kaydın hangi cihaz sınıfından geldiğini, satırı hiç okumadan, yalnız baştaki sayıya bakarak anlarsınız.

Ama bir tuzağı var. Lab switch’im varsayılan olarak local7 kullanıyor, ve çoğu üretici aynı varsayılanı seçiyor. Yani hiçbir atama yapmazsanız bütün cihazlarınız aynı değere düşer; facility’nin sunduğu ayrım hiç oluşmaz.

Eşik Nasıl Çalışır: “Bu Seviyeden Yukarısı”

Cihazlar her hedef için ayrı bir eşik tutar ve o eşiğin altındaki mesajları hiç göndermez. Yukarıdaki show logging çıktısı bu mekanizmayı sayıyla gösteriyor:

Üç satır aynı olay akışına bakıyor ve üç farklı sonuç veriyor:

1. Konsol warning ve daha acil olanları alıyor, 400 mesajın 315’ini eliyor.
2. Hafıza info seviyesine kadar iniyor, o yüzden daha fazlasını tutuyor.
3. Dosya yalnız emerg istiyor. Bu cihazda hiç emerg üretilmediği için dosyaya tek satır bile yazılmamış.

Üçüncü satır sahada en sık yapılan hatanın ölçülmüş hâlidir: eşik fazla dar tutulduğunda log “çalışıyor” görünür ve içi boştur. Kimse emerg seviyesinde mesaj üretmeyi planlamaz; o seviye sistemin tamamen çöktüğü an içindir.

Syslog Neden 514 Portunu ve UDP’yi Kullanır?

Syslog varsayılan olarak UDP 514 kullanır, ve bu tercih protokolün tasarım amacından çıkar: kaydı üreten cihaz, kaydı göndermek için yavaşlamamalıdır.

UDP’de bağlantı kurulmaz, el sıkışma yapılmaz, teslim beklenmez. Cihaz satırı ağa bırakır ve kendi işine döner. Bir switch için bu ciddi bir avantajdır: log göndermek asıl işi olan paket anahtarlamanın önüne geçmez. İki taşıma protokolü arasındaki farkı ve bir portun ne anlama geldiğini port ve TCP/UDP yazımızda ayrıntısıyla anlatıyoruz.

Kayıp Neden Sessizdir?

Bedeli şudur: UDP teslim garantisi vermez, ve vermediğini kimseye haber de vermez. Kayıt yolda kaybolursa gönderen bunu bilmez, alıcı da eksik bir şey olduğunu fark etmez. İki taraf da mutludur, kayıt yoktur.

Katip benzetmesinde bu, tutanağın bir sayfasının kaybolmasına benzer. Sorun kaybolması değil; kaç sayfa olduğunu kimsenin yazmamış olması. Elinizdekinin eksik olduğunu anlamanızın bir yolu yoktur.

Peki bu ne kadar önemli? Ağ içi, düşük yükte bir bağlantıda UDP kaybı pratikte ihmal edilebilir. Kayıp asıl şu iki durumda anlamlı olur: toplayıcı ile cihaz arasında yoğun ve dar bir hat varsa, ya da toplayıcı ani bir mesaj patlamasında yetişemiyorsa. İkisi de tam olarak kayda en çok ihtiyaç duyduğunuz anlarda ortaya çıkar.

Yönetim trafiğini ayrı bir VLAN’a almanın sebeplerinden biri tam olarak budur. Log ve yönetim paketleri kullanıcı trafiğiyle aynı hattı paylaşırsa, hat dolduğunda ilk düşen onlar olur. Ayrı bir yönetim ağı bu paketleri kalabalıktan çıkarır; öncelik yapılandırması ise sıkışma anında onlara geçiş üstünlüğü verir. VLAN tarafını yönetim VLAN’ını ele aldığımız bölümde, öncelik tarafını ise QoS ve öncelikli devreler başlığında anlatıyoruz.

Bu tercihin mantığı, iki kaybı yan yana koyunca netleşiyor. Dosya indiren birinin bağlantısı bir saniye geç açılsa, ya da video görüşmesinin kalitesi birkaç saniye düşse, kimse ölmez. Ama biri firewall’unuza içeriden parola deneyerek girmeye çalışıyorsa ve o denemeleri bildiren satırlar tam o sırada kalabalığa takılıp kayboluyorsa, kaybettiğiniz şey birkaç saniyelik konfor değil, olayın kendisidir. Önceliklendirmenin gerçek gerekçesi hız değil, hangi paketin kaybolmasını göze aldığınızdır.

Tek @ ve Çift @@: Gönderen Tarafta Tek Karakterlik Fark

Linux tarafında gönderen yapılandırılırken taşıma tercihi tek bir karakterle yazılır ve bu, ilk kez görenleri en çok şaşırtan ayrıntıdır:

*.* @192.168.1.46:514
*.* @@192.168.1.46:514

1. Tek @ UDP demektir.
2. Çift @@ TCP demektir.

Aradaki fark bir karakter, sonuç ise kaybın sessiz olup olmamasıdır. Bir yapılandırmayı devralırken bakılacak ilk yerlerden biridir.

TCP ve TLS Ne Zaman Gerekir?

Üç durumda varsayılanın dışına çıkılır:

• Kaybı görmek istiyorsanız TCP. Teslim onaylanır, kopan bağlantı fark edilir. Bedeli cihaz üstünde biraz daha kaynak ve bağlantı yönetimidir.
• Kayıtların yolda okunmasını istemiyorsanız TLS. Syslog düz metin taşır; aynı ağdaki biri paketleri yakalarsa kullanıcı adları, cihaz adları ve yapılandırma değişiklikleri okunabilir. Şifreli taşıma 6514 portunu kullanır.
• Yasal saklama yapıyorsanız ikisi birden. Delil değeri taşıyacak bir kaydın hem eksiksiz hem de değiştirilmemiş olması beklenir.

TLS’in burada ne yaptığını karıştırmamak gerekiyor: taşımayı şifreler, kaydı imzalamaz. Kanal boyunca satırı okunamaz hâle getirir ve toplayıcının kimliğini sertifikayla doğrular, yani gönderen cihaz karşısındaki sunucunun gerçekten kendi toplayıcısı olduğunu anlar. Bu doğrulamanın kime dayandığı ayrı bir konudur ve iç ağda genellikle kendi kurduğunuz bir otoriteye bağlanır: sertifika otoritesi rehberimizde ele alıyoruz. Ama kayıt toplayıcıya ulaşıp diske yazıldıktan sonra TLS’in işi biter. Diskteki dosyanın sonradan değiştirilip değiştirilmediği ayrı bir sorudur ve cevabı bir sonraki bölümde. Ayrıca 6514 ayrı bir port olmak zorundadır, çünkü şifreli oturum ilk baytından itibaren el sıkışmayla başlar; 514’ü dinleyen bir toplayıcı o baytları syslog satırı sanardı.

Düz metin taşımanın ne demek olduğunu bu sitede daha önce paket düzeyinde gösterdik: Telnet protokolü yazımızda aynı switch’in yakalanan trafiğinde parolanın açıkça göründüğünü ölçmüştük. Syslog aynı sınıftadır.

Syslog Neyi Taşımaz? Kimlik, Bütünlük ve Sıra

Buraya kadar protokolün ne yaptığını gördük. Şimdi yapmadıklarını koyuyoruz, çünkü bir kaydın delil değeri tam olarak burada belirlenir.

Syslog kırk yıl önce, ağdaki herkesin birbirine güvendiği varsayımıyla tasarlandı. O varsayım artık geçerli değil ve protokol de bunu telafi etmeye çalışmıyor.

Gönderen Adresi Bir Kimlik Değildir

Toplayıcı, gelen kaydı paketin kaynak adresine bakarak bir cihaza atar. Bu bir kimlik doğrulaması değildir. UDP’de kaynak adresi taklit edilebilir; ağdaki herhangi bir makine, switch’inizin adresinden geliyormuş gibi görünen kayıtlar üretebilir.

Sonucu iki yönlüdür ve ikisi de kötüdür: uydurma kayıtlar arşive girebilir, ya da gerçek kayıtlar sahte olanların arasında değersizleşir.

Pratikte alınacak önlem protokolün içinde değil, çevresindedir: toplayıcının 514 portunu ağın tamamına değil yalnız bilinen gönderen adreslerine açmak. Bu, kimlik doğrulaması yerine geçmez ama çıtayı belirgin biçimde yükseltir.

Kaydın Sonradan Değiştirilmediğini Kim Garanti Eder?

Kısa cevap: syslog garanti etmez. Protokolün taşıdığı satırda ne imza vardır ne sağlama. Kayıt toplayıcıya ulaştıktan sonra sıradan bir metin dosyasıdır; o dosyaya yazma yetkisi olan herkes içeriğini değiştirebilir.

Bu, protokolün eksikliği değil kapsamının sınırıdır. Bütünlük garantisi toplayıcının üstüne kurulan ayrı bir katmandır: kayıtların zincirlenmiş sağlama değerleriyle mühürlenmesi, yazma yetkisinin daraltılması, arşivin ayrı bir ortamda tutulması.

Türkiye’de bu katman isteğe bağlı da değildir. 5651 sayılı kanun kapsamındaki kayıtlar için zaman damgası, değiştirilemezlik ve saklama süresi ayrı ayrı şart koşulur; bunların hiçbiri syslog’un işi değildir. Yükümlülüğün tamamını ve teknik karşılıklarını 5651 log yönetimi rehberimizde ele alıyoruz.

Saat Kayarsa Tutanak Ne Kadar İşe Yarar?

Bir tutanağın en kritik alanı zamandır. İki cihazın saati birbirinden on dakika farklıysa, ikisinden gelen kayıtları yan yana koyduğunuzda olayların sırası yanlış görünür. Önce olan sonra olmuş gibi durur.

Bunun teşhisi zordur, çünkü kayıtların kendisi doğrudur. Yanlış olan tek şey damganın vurulduğu andır.

Bu yüzden merkezi log kurulumunun ilk adımı toplayıcı değil, saat kaynağıdır. Ağdaki bütün cihazlar aynı zaman kaynağına bağlanmadan toplanan kayıtlar, tek tek doğru ve birlikte yanlış olur. Kurumsal ağda saat dağıtımını NTP protokolü yazımızda ayrıntılarıyla anlatıyoruz.

Sahada Syslog: Gürültüyü Nasıl Ayıklarsınız?

Toplayıcıyı kurdunuz, cihazları bağladınız, kayıtlar akıyor. Asıl iş şimdi başlıyor, çünkü toplamak ile okumak aynı şey değil.

Lab: Bir Switch Bir Dakikada Ne Kadar Konuşur?

Bu soruya sahada verilen standart cevap “bir switch pek konuşmaz, ara sıra bir port düşer” şeklindedir. Ölçtüm.

Lab switch’imi (sw01) yeni kurduğum toplayıcıya bağladım ve tek yaptığım şey beklemek oldu. Yapılandırma değiştirmedim, kablo takmadım, kimseyi bağlamadım. Altmış saniye sonunda gelen:

60 satır / 8.670 bayt

Bu hızda, tek bir switch günde yaklaşık 11 MB, yılda yaklaşık 4,3 GB kayıt üretiyor. Hiçbir şey olmuyorken.

Sayı tek başına şaşırtıcı değil. Şaşırtıcı olan içeriği. Toplanan 149 satırın dağılımı şöyleydi:

Anlamlı olan tek kayıt, hacmin binde yedisi. O 147 baytlık satır şuydu:

<190> Aug 19 07:01:59 sercebilisimsw01-1 CLI_WEB[emWeb]: %% [CLI:ilker:192.168.1.115] User has succesfully logged in

Yani switch’e kimin, ne zaman, hangi adresten yönetici olarak girdiği. Bir arıza incelemesinde ya da bir güvenlik sorusunda ilk bakacağınız satır tam olarak budur. Ve diğer 148 satırın arasında kaybolmuş durumda.

Aynı Satırın Yüzlerce Kez Tekrarı Bir Arıza İşaretidir

Gürültüyü oluşturan 148 satır rastgele değildi. İki mesajın dönüşümlü tekrarıydı:

<187> DOT1S[dtlTask]: dot1s_txrx.c(306) %% dot1sBpduReceive(): Discarding the BPDU, since it is an invalid BPDU type
<189> DOT1S[dtlTask]: dot1s_txrx.c(1286) %% dot1sBpduReceive(): Invalid Forward Delay

Her iki saniyede bir, aralıksız. Switch, ağ döngülerini engelleyen protokolün mesajlarını alıyor ve anlamlandıramadığı için atıyor.

Buradan çıkan kural şudur: saniyede tekrarlanan bir mesaj bilgi değil, semptomdur. Bir kaydın yüzlerce kez tekrarlanması, o kaydı önemsiz yapmaz; tam tersine, arka planda düzelmemiş bir şeyin sürdüğünü gösterir.

Ama aynı kural, o mesajın arşive olduğu gibi girmemesi gerektiğini de söyler. Yılda 4,3 GB’ın neredeyse tamamı aynı iki cümlenin kopyasıdır.

Neyi Toplarsınız, Neyi Atarsınız?

Toplayıcıya gelen her satırı sonsuza kadar saklamak hem gereksiz hem masraflıdır. Ayıklama üç kademede yapılır:

1. Gönderen tarafta eşik. Cihazın hangi seviyeden yukarısını göndereceğini ayarlayın. debug seviyesini sürekli açık bırakmak, gürültünün en büyük kaynağıdır. Bu ayarın en çok fark yarattığı cihaz firewall’dur: bir güvenlik duvarı her bağlantı için kayıt üretebilir ve kurumsal firewall kurulumunda hangi kural setinin loglanacağı baştan kararlaştırılır.
2. Toplayıcıda ayrıştırma. Kayıtları gönderen cihaza ve üreten sürece göre ayrı dosyalara yazın. DOT1S ile CLI_WEB aynı dosyada olduğunda ikincisi görünmez olur; ayrı dosyada olduğunda 147 baytlık dosya kendini gösterir.
3. Tekrar bastırma ve saklama süresi. Aynı mesajın arka arkaya tekrarı tek satıra indirilir, eski kayıtlar sıkıştırılıp arşivlenir.

Üçünü de atlarsanız sonuç öngörülebilir: disk dolar, log yazımı durur, ve bunu ancak ihtiyacınız olduğu gün fark edersiniz.

Bu ayıklamanın ölçekteki karşılığını bir vaka üzerinden de anlatmıştık: on üç lokasyonlu bir ağda pahalı bir izleme ürününden açık kaynak araçlara geçerken karşılaştığımız asıl sorun veri toplamak değil, toplanan veriyi okunur kılmaktı.

Bu ayıklamanın nasıl kurulduğunu, hangi yapılandırma dosyasına ne yazıldığını ve gönderen cihazın nasıl bağlandığını Ubuntu’da syslog sunucusu kurulumu rehberimizde adım adım gösteriyoruz.

Sonuç: Katip Yoksa Duruşma Hiç Olmamıştır

Syslog karmaşık bir protokol değil. Cihaz bir satır üretir, öncelik alanına iki bilgi sıkıştırır, 514 portundan gönderir. Öğrenilecek asıl şey protokolün kendisi değil, neyi garanti etmediğidir: teslimi garanti etmez, göndereni doğrulamaz, kaydın değiştirilmediğini kanıtlamaz, saatin doğruluğundan sorumlu değildir.

Bunların hepsi sizin kuracağınız katmanlardır. Protokol yalnız tutanağın tutulmasını sağlar; tutanağın güvenilir olması ayrı bir iştir.

Ve ölçüm şunu gösterdi: bir switch hiçbir şey olmuyorken bile dakikada altmış satır konuşuyor. Bu satırların yüzde doksan dokuzu size bir şey anlatmayabilir. Ama geri kalan binde yedi, gece üçte kimin sisteme girdiğini söyleyen tek kayıttır.

O kaydı toplamıyorsanız, o olay hiç olmamış sayılır.

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üren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.