Sanılanın aksine Unix ve türevi sistemlerdeki tek log dosyası syslog değildir.
Fakat bu dosyaların çoğuna yine “syslog” servisi aracılığı ile loglar yazılır. Ayrıca farklı Unix’ler ve linux dağıtımları arasında da farklı loglar farklı dosyalara yazılır.
Tüm bu log dosyalarının nereden kaynaklandığını anlamak için göz atmamız gereken dosya syslog konfigürasyon dosyası olan “/etc/rsyslog.conf” dosyasıdır.
Linux dağıtımlarında görülebilecek syslog daemon’ları:
- sysklogd
- rsyslogd
- syslog-ng’dir.
Kali üzerinde çalışan syslog daemon’ının ne olduğunu çalışan proseslerin listesini inceleyerek anlayabiliriz. Buna göre gördüğünüz gibi parent process id’si 1 olan ve ayrıca adında da syslog geçen daemon’ın “rsyslog” olduğunu görebiliriz.
Syslog kavramları ve konfigürasyonuna geçmeden önce syslog dışındaki birkaç log dosyasına değinmek istiyorum. Bu dosyalar başarılı ve başarısız login denemeleri, şu anda sisteme bağlı kullanıcılar gibi bilgileri tutar. Dosya formatları binary’dir, yani bir metin editörü ile içeriklerini anlamak mümkün değildir. Bu dosyalardaki veriler belli uygulamalar tarafından kullanılır ve raporlanır.
/var/run/utmp: Bu dosya için aslında tam olarak bir log dosyası diyemeyiz, çünkü sadece sisteme şu anda bağlı kullanıcıların kayıtlarını içerir. Zaten “/var/run” dizini genellikle sistemin son başlatılmasında hangi prosesin hangi id’yi aldığı gibi mevcut oturumla (current run) ilgili bilgileri barındırır. Bu dosyadaki bilgileri listeleyen komut “who” komutudur.
“who” komutunun çıktısı olarak hangi kullanıcının aktif olduğunu, hangi terminalden (terminal de Unix için bir dosyadır ve write gibi komutlarla başkalarının terminallerine mesaj gönderebilirsiniz) ve ne zaman login olduğunu görebilirsiniz. “utmp” dosyasının man page’inde sisteme erişim sağlayan tüm uygulamalar “utmp” dosyasını beslemiyor olabileceğinden “who” komutunun çıktısına tamamen güvenilmemesi gerektiği belirtilmektedir.
/var/log/wtmp: utmp sadece şu an bağlı kullanıcı kayıtlarını içerirken log dizini altında bulunan wtmp dosyası ise daha önce bağlanmış kullanıcı kayıtlarını içerir. “last” komutu hem geçmişte hem de şu anda bağlı kullanıcı kayıtlarını listeler. “reboot” olarak gösterilen pseudo (sözde) kullanıcı sistem her reboot olduğunda logon olmuş gibi gösterilir. Bu sayede sistemin kaç defa açılıp kapatıldığını da izleyebiliriz.
/var/log/btmp: Bad logonların kayıtlarını tutan bu dosyadaki kayıtları “lastb” komutu ile listeleyebiliriz.
Artık syslog altyapısını açıklamaya geçebiliriz. “syslog” dediğimizde aslında hem logların kendisinden, hem logları ağ üzerinden veya sistem proses’lerinden bekleyen bir servisten, hem de syslog üretmek için çağrılabilecek bir C kütüphane fonksiyonundan bahsediyoruz.
Debian dağıtımında daha önce de belirttiğimiz gizi “rsyslog” daemon’ı çalışıyor. “rsyslogd” ile gelen temel ek imkanlar aşağıdakiler:
- “syslog” ağ üzerinden gelen logları UDP ve TCP portlarından dinleyebilir. “rsyslog” da aynı şeyi yapabilir ancak bunun üzerine IP bazlı kısıtlama da yapabilir.
- “rsyslog” ile log kayıtları üzerinde herhangi bir bilgiyi kullanarak log kaydını istediğiniz log dosyasına yönlendirebilirsiniz. Mesela gelen log kaydının içinde bir regular expression ile aradığınız bir ifadeyi logun kaydedileceği dosya adı olarak kullanabilirsiniz.
- “rsyslog” servisi modüler olarak pek çok fonksiyonaliteyi hayata geçirebilir. Örneğin “ommysql” modülünü yükleyerek logları bir MySQL veritabanına yazabilirsiniz.
Syslog kaydı ile ilgili bilgileri açıklamak için bir uzaktan syslog senaryosu oluşturalım. Syslog kaydı üretecek bir istemci uygulaması olarak “logger” uygulamasını kullanacağız. Bu uygulamayı “cron” işlerimizde mail ile bazı mesajları iletmek yerine syslog mesajları ile bu mesajları kaydetmek için de kullanabiliriz.
“logger” uygulaması ile farklı bir sunucuda bulunan syslog servisine syslog mesajı göndereceğiz.
Bu komutla “logger” uygulamasına
- (-n opsiyonu ile) mesajı lokal syslog daemon’ına değil uzaktaki 192.168.163.148 IP adresinde çalışan servise göndermesini,
- (-i opsiyonu ile) “logger” uygulamasının process id’sini göndermesini (bu uzaktan loglama için çok da gerekli değil aslında, ama lokal loglar için faydalı olabilir logun hangi proses’ten kaynaklandığı bilgisi lokal loglar için faydalı olabilir),
- (-p yani priority opsiyonu ile) mesajın önceliğini facility ve level bilgilerini kullanarak belirtmesini,
- (-t opsiyonu ile) tag bilgisi olarak “btrisk” ifadesini göndermesini,
- ve son olarak da mesajın içeriğini göndermesini söylüyoruz.
Şimdi diğer sunucunun network üzerinden gelecek syslog kayıtlarını dinlemesi ve kaydetmesi için gerekli ayarları yapalım.
Öntanımlı olarak comment’li olarak gelen ve UDP üzerinden log toplamayı aktif hale getiren “imudp” input modülünü yükleyen satırı aktif hale getiriyoruz. Hemen altındaki ayarı da öntanımlı 514 değerinde bırakarak aktif hale getiriyoruz.
Modules bölümünün altında bulunan Rules bölümünde hangi tip logların nereye yazılacağı ile ilgili kurallar tanımlanıyor.
Bu bölüm biraz kafa karıştırıcı olabilir. Burada tanımlanan kuralları sunucu kuralları olarak düşünün. Ayrıca bu sunucuyu hem bu sunucu üzerinde çalışan uygulamaların kullandığını hem de ağ üzerinden kayıt gönderen istemcilerin kullandığını düşünün. Ancak bu sunucu aynı zamanda bir proxy gibi davranarak kendisine gelen kayıtları ağ üzerindeki başka bir sunucuya da gönderebilir. Yani bu sunucu hem bir sunucu hem de bir istemci olarak görev yapabilir.
Rules bölümünün formatı şu şekilde:
- Selector: Birinci bölüm kuralın hangi tür loglar ile ilgili olduğunu belirleyen bir bölüm. Selector’ler de iki bölümden oluşuyor: 1-Facility, 2-Priority. Facility’yi logu üreten proses türü olarak düşünebiliriz. Priority ise logun önceliği gibi bir anlama geliyor, ama öncelik sizin bu logu nasıl ele aldığınıza bağlı tek başına bir anlamı yok.
- Action: Selector kriterine göre seçilen logların nereye aktarılacağı bu bölümde belirtiliyor. Loglar konsola yazılabilir, bir dosyaya yazılabilir, bir veritabanı tablosuna yazılabilir veya network üzerinden başka bir syslog sunucusuna yönlendirilebilir.
Dolayısıyla bizim gönderdiğimiz loglar da “*.*” koşuluna denk düşeceğinden bu satırda görülen “/var/log/syslog” dosyasına yazılacak. Action’ın başında görülen “-“ karakteri eğer genel olarak dosya sync işlemi (yani alınan mesajın anında dosyaya yazılması) aktif hale getirilmişse bu dosyanın bu kuraldan muaf olması anlamına geliyor. Tahmin edilebileceği gibi dosyaya anında yazma performans kaybına yol açacak bir uygulama, son belli sayıdaki log kaydının hafızadayken elektrik kesintisi sonucu kaybedilmesi riskini alamayacağınız bir durum söz konusuysa uygulanabilir.
Son olarak “syslog” dosyasında logu gönderen sunucunun adını değil de IP adresini görmek için bir değişiklik yapmak istiyorum. Bu değişikliği yapmazsak sunucu her kayıt için gördüğü IP adresini reverse DNS lookup yaparak sunucu adına dönüştürmeye çalışacak.
Sunucu tarafında son olarak “/etc/rsyslog.conf” ve “/etc/default/rsyslog” dosyalarındaki değişikliklerimizin aktif hale gelmesi için “rsyslog” servisini yeniden başlatmamız gerekiyor.
Yukarıda rsyslog servisimizin UDP 514 portunda dinlediğini görebiliriz.
Gelen kaydı syslog dosyasında izleyeceğiz, ancak bununla birlikte “tcpdump” ile gelen ağ paketini de inceleyeceğiz.
Syslog kaydının alanları aşağıdaki gibidir:
- Tarih: “Jul 3”
- Saat: “11:30:59”
- Sunucu adı: “btrisk-syslogclient” Sunucu adının IP adresi olarak görünmesi için gerekli düzenlemeyi “/etc/default/rsyslog” dosyasında yapmıştık. Ancak görünen o ki “rsyslogd” servisi yukarıda görünen ağ paketlerinde burada bir host adı görürse bu alanda onu kullanıyor, gerçekte gelen paketin kaynak IP adresini dikkate almıyor.
- Tag (Etiket): “btrisk[prosess id’si]”
- Mesaj: “Test mesaji”
Cron işlerinin nasıl çalıştırıldığını incelediğimizde günlük işlerin “anacron” tarafından çalıştırıldığını görmüştük. Bu yüzden “/etc/cron.daily” dizini altına bir göz atalım.
Bu dizin altında tanımlı scriptlerden birisi de logrotate script’i. Bu script’in yaptığı iş ise “/etc/logrotate.conf” konfigürasyon dosyasını okuyarak “logrote”i çalıştırmak.
“/etc/logrotate.conf” dosyası “/etc/logrotate.d” dizinindeki dosyaları da include ediyor. Şimdi bu dizine bir göz atalım.
“/etc/logrotate.d” dizini altında bulunan rsyslog dosyası rsyslog servisi için logrotate konfigürasyonunu içeriyor.
“/var/log/syslog” dosyası için yapılan logrotate konfigürasyonunu şöyle açıklayabiliriz:
- “rotate 7”: Son 7 arşivi sakla, bundan öncekileri ez anlamına gelir.
- “daily”: Günlük olarak dosyaları rotate ettir.
- “missingok”: Eğer log dosyası mevcut değilse hata mesajı vermeden bir sonraki işleme geç.
- “notifempty”: Eğer log dosyası boş ise rotate ettirme (yeni en eski arşiv dosyasını ezme).
- “delaycompress”: En taze arşiv dosyasını sıkıştırma, bir sonraki turda sıkıştır.
- “compress”: Arşiv dosyalarını sıkıştır.
- “postrotate - endscript”: Log dosyası arşiv dosyası olarak kopyalandıktan sonra çalıştırılmasını istediğimiz komutları buraya yazabiliriz. Bu konfigürasyonda “rsyslog” servisi yeniden başlatılıyor.
“/var/log” dizini altında syslog ile başlayan dosyaları listelediğimizde logrotate konfigürasyonunda belirtildiği gibi 7 arşiv dosyası görüyoruz. Bunların en yenisi delaycompress ayarı gereği sıkıştırılmamışken geri kalanı sıkıştırılmış şekilde saklanıyor.
Log yönetiminde önemli konulardan bir tanesi de sistem saatinin doğruluğu ve aynı güvenlik alanında bulunan diğer sunucuların saatleri ile senkronize olmasıdır. Bunun nedeni bir ihlal gerçekleştiğinde veya bir inceleme sürecinde farklı sistemlerden alınan loglar arasındaki zaman ilişkilerini kurma ihtiyacımızdır.
Kali dağıtımı üzerinde “ntp” paketi kurulu olarak gelir, ayrıca kurulmasına gerek yoktur. Ancak bu servis öntanımlı olarak otomatik başlatılmaz. Bunun için sizin servisi başlatmanız (ve tabi her sistem açılışında aktif olmasını istiyorsanız “systemctl” aracı ile “enable” etmeniz) gerekir.
Ntp sunucu tanımlarını “/etc/ntp.conf” dosyası içinde yapmanız gerekir.
Bu dosyada “server” komutuyla başlayan satırlara kendi coğrafyanıza daha yakın veya varsa kurum içindeki ntp sunucu alan adı veya IP adresini yazabilirsiniz. Eğer yazmazsanız aşağıda gelen pool komutlarının yanındaki alan adları zaman sunucu olarak kullanılır. Ntp servisi birden fazla sunucuyu hepsine istekte bulunarak aralarında birbirleriyle en tutarlı olan zamanı seçmek için kullanıyor. “pool” yani havuz mantığı ise şu şekilde çalışıyor, aslında “pool” komutuyla doğrudan ilgisi yok, “ntp.org” alanı altındaki “pool” alan adları belli periyotlarda havuza dahil olan farklı IP adreslerine çözülüyor. Yani bir alan adı sürekli olarak farklı IP adresleri için kullanılıyor. Böylece siz havuzdaki IP adreslerini takip etmek zorunda kalmıyorsunuz, DNS sunucusu yükü arkadaki havuza dağıtıyor.
Örneğin aşağıdaki örnekte “0.debian.pool.ntp.org” alan adı birinci istekte “62.12.173.12” olarak çözülürken ikinci istekte “195.50.171.101” olarak çözülüyor.
Servis başlatıldıktan sonra sunucuların listesi ve durumlarıyla ilgili bilgiyi “ntpq –p” komutu ile izleyebiliriz:
Eğer buna benzer bir liste göremezseniz “ntpq” servisiniz çalışmıyor demektir. Bu durumda servisinizi kontrol edin.
<<Önceki Bölüm Sonraki Bölüm>>
