rsyslog Yapılandırması: Filtre ve Yönlendirme Kuralları

Bykomut

Sunuculardan akan log verilerini anlamlı bir şekilde yönetmek, her sysadmin’in günlük hayatının kaçınılmaz bir parçası. rsyslog, bu işin tam merkezinde duran güçlü bir araç. Basit bir log daemon’ından çok daha fazlası olan rsyslog; esnek filtre mekanizmaları, güçlü yönlendirme kuralları ve yüksek performansıyla kurumsal ortamlarda bile rahatlıkla kullanılabiliyor. Bu yazıda rsyslog’un filtre ve yönlendirme altyapısını gerçek dünya senaryolarıyla birlikte derinlemesine inceleyeceğiz.

rsyslog’a Genel Bakış ve Yapılandırma Temelleri

rsyslog, klasik syslog protokolünün çok ötesine geçen, modüler yapısıyla öne çıkan bir log işleme sistemi. Debian/Ubuntu tabanlı sistemlerde /etc/rsyslog.conf ana yapılandırma dosyası olarak kullanılırken, ek yapılandırmalar /etc/rsyslog.d/ dizinine .conf uzantılı dosyalar olarak yerleştiriliyor.

Yapılandırma dosyasının genel iskeletine bakalım:

# /etc/rsyslog.conf temel yapısı

#### MODULES ####
module(load="imuxsock")    # Yerel sistem logları için
module(load="imklog")      # Kernel log mesajları için
module(load="imudp")       # UDP üzerinden log almak için
input(type="imudp" port="514")

module(load="imtcp")       # TCP üzerinden log almak için
input(type="imtcp" port="514")

#### GLOBAL DIRECTIVES ####
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

#### RULES ####
# Kural tanımları buraya gelir
auth,authpriv.*    /var/log/auth.log
*.*;auth,authpriv.none    -/var/log/syslog

rsyslog iki farklı sözdizimini destekliyor: eski sysklogd formatı ve yeni RainerScript formatı. Modern ortamlarda RainerScript tercih ediliyor çünkü çok daha esnek ve okunabilir.

Facility ve Severity Kavramlarını Anlamak

Filtre kuralları yazmadan önce facility (tesis) ve severity (önem derecesi) kavramlarını netleştirmek gerekiyor.

Facility değerleri log mesajının hangi sistemden geldiğini belirtiyor:

  • kern: Kernel mesajları
  • user: Kullanıcı seviyesi mesajlar
  • mail: Mail sistemi
  • daemon: Sistem daemon’ları
  • auth: Güvenlik ve yetkilendirme mesajları
  • syslog: rsyslog’un kendi mesajları
  • lpr: Yazıcı sistemi
  • news: Ağ haber sistemi
  • cron: Cron daemon’u
  • local0 – local7: Özel kullanım için ayrılmış

Severity değerleri önem derecesine göre 0’dan 7’ye sıralanıyor:

  • emerg (0): Sistem kullanılamaz durumda
  • alert (1): Acil müdahale gerekiyor
  • crit (2): Kritik koşullar
  • err (3): Hata koşulları
  • warning (4): Uyarı mesajları
  • notice (5): Normal ama önemli koşullar
  • info (6): Bilgi mesajları
  • debug (7): Debug mesajları

Filtre Kuralları: Üç Temel Yaklaşım

rsyslog üç farklı filtre mekanizması sunuyor. Her birinin kendine özgü kullanım alanları var.

1. Selector Tabanlı Filtreler (Klasik Yöntem)

Selector formatı facility.severity şeklinde yazılıyor ve en yaygın kullanılan yöntem:

# /etc/rsyslog.d/basic-filters.conf

# Tüm kernel mesajlarını yakala
kern.*                          /var/log/kernel.log

# Mail sisteminin sadece kritik ve üstü hatalarını kaydet
mail.crit                       /var/log/mail-critical.log

# Auth facilit'inden gelen her şeyi kaydet
auth,authpriv.*                 /var/log/auth.log

# Belirli bir severity'nin altındakileri hariç tut
# "none" ile bir facility'yi tamamen dışla
*.*;mail.none;auth.none         /var/log/syslog

# Sadece warning ve üstü mesajları yakala (= işareti exact match yapar)
*.warning                       /var/log/warnings.log

# Exact match: Sadece info seviyesini yakala, altını veya üstünü değil
*.=info                         /var/log/info-only.log

# Debug hariç her şey
*.!debug                        /var/log/nodebug.log

2. Property Tabanlı Filtreler

Property tabanlı filtreler çok daha güçlü. Log mesajının herhangi bir özelliğine göre filtreleme yapmanıza izin veriyor:

# /etc/rsyslog.d/property-filters.conf

# Mesaj içeriğinde "error" geçiyorsa özel dosyaya yaz
:msg, contains, "error"         /var/log/error-messages.log

# NGINX ile ilgili tüm mesajları yakala
:programname, isequal, "nginx"  /var/log/nginx-syslog.log

# Hostname'e göre filtrele
:hostname, isequal, "web01"     /var/log/web01.log

# Regex ile gelişmiş filtreleme
:msg, regex, "Failed.*password" /var/log/failed-auth.log

# IP adresi içeren mesajları yakala
:msg, contains, "192.168.1."    /var/log/internal-network.log

# Büyük-küçük harf duyarsız arama
:msg, contains_i, "WARNING"     /var/log/warnings-ci.log

Property-based filtreler için kullanılabilecek karşılaştırma operatörleri:

  • isequal: Tam eşleşme
  • contains: İçerme kontrolü
  • contains_i: Büyük/küçük harf duyarsız içerme
  • startswith: Başlangıç kontrolü
  • regex: POSIX regex eşleşmesi
  • ereregex: Extended regex eşleşmesi

3. RainerScript Expression Tabanlı Filtreler

Modern ve en esnek yaklaşım olan RainerScript, programlama diline yakın bir sözdizimi sunuyor:

# /etc/rsyslog.d/rainerscript-filters.conf

# if-then yapısıyla gelişmiş filtreleme
if $syslogseverity <= 3 then {
    action(type="omfile" file="/var/log/critical-and-above.log")
}

# Birden fazla koşulu birleştir
if ($programname == "sshd") and ($msg contains "Failed") then {
    action(type="omfile" file="/var/log/ssh-failures.log")
    action(type="omfwd" target="192.168.1.100" port="514" protocol="tcp")
}

# OR koşulu kullanımı
if ($programname == "nginx") or ($programname == "apache2") then {
    action(type="omfile" file="/var/log/web-servers.log")
}

# Negatif koşul
if not ($programname == "cron") then {
    action(type="omfile" file="/var/log/non-cron.log")
}

Yönlendirme Kuralları ve Action Tanımları

Filtreler neyin işleneceğini belirlerken, action’lar bu mesajlarla ne yapılacağını tanımlıyor.

Dosyaya Yazma

# /etc/rsyslog.d/file-actions.conf

# Senkron yazma (yavaş ama güvenli)
auth.*      /var/log/auth.log

# Asenkron yazma (- öneki ile, performans için)
*.*         -/var/log/syslog

# RainerScript ile dosya action'ı
auth.* action(type="omfile"
              file="/var/log/auth.log"
              fileOwner="syslog"
              fileGroup="adm"
              fileCreateMode="0640"
              dirCreateMode="0755")

Uzak Sunucuya Yönlendirme

Merkezi log sunucusu senaryolarında uzak yönlendirme kritik önem taşıyor:

# /etc/rsyslog.d/remote-forwarding.conf

# UDP ile yönlendirme (hızlı ama güvenilmez)
*.* @192.168.1.100:514

# TCP ile yönlendirme (güvenilir)
*.* @@192.168.1.100:514

# Hostname ile TCP yönlendirme
*.* @@logserver.example.com:514

# RainerScript ile gelişmiş yönlendirme
*.* action(type="omfwd"
           target="logserver.example.com"
           port="514"
           protocol="tcp"
           action.resumeRetryCount="100"
           queue.type="linkedList"
           queue.size="10000")

# TLS şifreli yönlendirme
module(load="omfwd")
*.* action(type="omfwd"
           target="secure-logserver.example.com"
           port="6514"
           protocol="tcp"
           StreamDriver="gtls"
           StreamDriverMode="1"
           StreamDriverAuthMode="x509/name"
           StreamDriverPermittedPeers="*.example.com")

Queue Yapılandırması ile Dayanıklı Yönlendirme

Ağ kesintilerine karşı dayanıklı bir yapı kurmak için queue kullanımı şart:

# /etc/rsyslog.d/queue-config.conf

# Disk destekli queue ile güvenilir yönlendirme
action(type="omfwd"
       target="192.168.1.100"
       port="514"
       protocol="tcp"
       queue.filename="fwdRule1"
       queue.maxdiskspace="1g"
       queue.saveonshutdown="on"
       queue.type="LinkedList"
       action.resumeRetryCount="-1")

Gerçek Dünya Senaryoları

Senaryo 1: Web Sunucusu Log Merkezileştirme

Birden fazla web sunucusunun loglarını merkezi bir sunucuda toplamak istiyorsunuz. Her sunucuya aşağıdaki yapılandırmayı uyguluyorsunuz:

# /etc/rsyslog.d/50-web-forward.conf (Web sunucularında)

# Nginx loglarını merkezi sunucuya gönder
if ($programname == "nginx") then {
    action(type="omfwd"
           target="logserver.internal"
           port="514"
           protocol="tcp"
           queue.type="LinkedList"
           queue.size="50000"
           queue.filename="nginx-queue"
           queue.saveonshutdown="on"
           action.resumeRetryCount="-1")
    stop
}

# Uygulama hatalarını ayrıca yerel dosyaya da yaz
if ($programname == "myapp") and ($syslogseverity <= 3) then {
    action(type="omfile" file="/var/log/myapp/critical.log")
    action(type="omfwd" target="logserver.internal" port="514" protocol="tcp")
}

Merkezi log sunucusunda ise gelen logları hostname bazında ayrıştırıyorsunuz:

# /etc/rsyslog.d/10-remote-logs.conf (Log sunucusunda)

# Uzak logları al
module(load="imtcp")
input(type="imtcp" port="514")

# Hostname bazında dosyalara dağıt
template(name="RemoteLogs" type="string"
         string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")

if $fromhost-ip != "127.0.0.1" then {
    action(type="omfile" DynaFile="RemoteLogs"
           dirCreateMode="0755"
           fileCreateMode="0644")
    stop
}

Senaryo 2: Güvenlik Olaylarını İzleme ve Alarm

SSH brute force saldırılarını tespit edip özel bir dosyaya yazmak ve aynı zamanda bir alarm mekanizması tetiklemek:

# /etc/rsyslog.d/60-security-monitoring.conf

# SSH başarısız giriş denemelerini yakala
if ($programname == "sshd") and
   ($msg contains "Failed password" or $msg contains "Invalid user") then {
    action(type="omfile"
           file="/var/log/security/ssh-attacks.log"
           fileCreateMode="0600"
           fileOwner="root")
}

# Sudo kullanımını logla
if ($programname == "sudo") then {
    action(type="omfile" file="/var/log/security/sudo-usage.log")
    action(type="omfwd" target="siem.company.com" port="514" protocol="tcp")
}

# Kritik güvenlik eventlarını email ile bildir
if ($syslogseverity == 0) then {
    action(type="ommail"
           server="smtp.company.com"
           port="25"
           mailfrom="[email protected]"
           mailto="[email protected]"
           subject.template="RSYSLOG_SyslogProtocol23Format")
}

Senaryo 3: Uygulama Loglarını Yapılandırılmış Formatta Kaydetme

Modern uygulamalar için JSON formatında log kaydetmek analizi kolaylaştırıyor:

# /etc/rsyslog.d/70-json-logging.conf

# JSON template tanımla
template(name="JSONFormat" type="list") {
    constant(value="{")
    constant(value=""timestamp":"")
    property(name="timereported" dateFormat="rfc3339")
    constant(value="","hostname":"")
    property(name="hostname")
    constant(value="","program":"")
    property(name="programname")
    constant(value="","severity":"")
    property(name="syslogseverity-text")
    constant(value="","facility":"")
    property(name="syslogfacility-text")
    constant(value="","message":"")
    property(name="msg" format="json")
    constant(value=""}n")
}

# Uygulama loglarını JSON formatında kaydet
if ($programname startswith "app-") then {
    action(type="omfile"
           file="/var/log/apps/structured.json"
           template="JSONFormat")
}

Log Rotasyonu ile Entegrasyon

rsyslog’un ürettiği log dosyalarını logrotate ile düzenlemek önemli:

# /etc/logrotate.d/rsyslog-custom

/var/log/security/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

/var/log/apps/structured.json {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    dateext
    dateformat -%Y%m%d
    postrotate
        kill -HUP $(cat /var/run/rsyslogd.pid 2>/dev/null) 2>/dev/null || true
    endscript
}

Performans Optimizasyonu ve İzleme

Yüksek log hacimli ortamlarda birkaç kritik ayar performansı doğrudan etkiliyor:

# /etc/rsyslog.conf - Performans ayarları

# Ana queue boyutunu artır
main_queue(
    queue.size="100000"
    queue.type="LinkedList"
    queue.workerThreads="4"
    queue.workerThreadMinimumMessages="100"
    queue.timeoutWorkerthreadShutdown="10000"
)

# Rate limiting - saniyede maksimum mesaj sayısı
module(load="imuxsock"
       SysSock.RateLimit.Interval="1"
       SysSock.RateLimit.Burst="10000")

# Impstats ile rsyslog istatistiklerini izle
module(load="impstats"
       interval="300"
       severity="7"
       log.syslog="off"
       log.file="/var/log/rsyslog-stats.log")

Yapılandırma değişikliklerinden sonra mutlaka syntax kontrolü yapın:

# Syntax kontrolü
rsyslogd -N1

# Detaylı syntax kontrolü
rsyslogd -N2

# Servisi yeniden başlatmadan reload
systemctl reload rsyslog

# Durumu kontrol et
systemctl status rsyslog

# Log akışını canlı izle
journalctl -fu rsyslog

Hata Ayıklama İpuçları

Filtre kurallarınızın beklediğiniz gibi çalışıp çalışmadığını test etmek için:

# Test mesajı gönder
logger -p auth.warning "Test warning message from sysadmin"
logger -p kern.crit "Critical kernel test message"
logger -t myapp "Application test message"

# rsyslog debug modunda çalıştır
rsyslogd -dn 2>&1 | head -100

# Belirli bir mesajın nereye gittiğini takip et
tail -f /var/log/syslog | grep "test"
tail -f /var/log/auth.log

Filtre testlerinde dikkat edilmesi gereken yaygın hatalar:

  • stop direktifini unutmak: Bir mesajın birden fazla kuralla eşleşmesini istemiyorsanız stop kullanmayı unutmayın
  • Sıralama hatası: Kurallar sırayla işleniyor, daha spesifik kurallar daha genel kurallardan önce gelmelidir
  • Dosya izinleri: rsyslog genellikle syslog kullanıcısıyla çalışır, hedef dizinin yazılabilir olduğundan emin olun
  • Queue boyutu: Yüksek hacimli ortamlarda yetersiz queue boyutu mesaj kaybına yol açar

Sonuç

rsyslog’un filtre ve yönlendirme mekanizmaları, ilk bakışta karmaşık görünse de mantıksal bir yapıya sahip. Selector tabanlı klasik filtreler günlük kullanım için yeterli olurken, property tabanlı ve RainerScript filtreler daha karmaşık senaryoları ele almanızı sağlıyor. Gerçek bir ortamda genellikle bu üç yaklaşımı bir arada kullanıyorsunuz.

Kurumsal bir ortamda iyi bir rsyslog yapılandırması şu üç prensibi gözetmeli: güvenilirlik için queue mekanizmaları ve disk tabanlı tamponlar kullanın, ölçeklenebilirlik için template’leri etkin biçimde yönetin, izlenebilirlik için yapılandırma değişikliklerinizi belgeleyin ve düzenli olarak test edin. Merkezi log yönetimi altyapısını rsyslog üzerine kurarken TLS şifrelemesini ve kimlik doğrulamayı da ihmal etmeyin; loglar hassas veri içerebilir ve güvenli kanallar üzerinden taşınmalı.

Son olarak, rsyslog yapılandırmanızı bir Git reposunda tutmanızı şiddetle öneririm. Değişiklik geçmişi, özellikle karmaşık filtre kurallarında hata ayıklamanızı inanılmaz ölçüde kolaylaştırıyor.

Similar Posts

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir