Merkezi Log Sunucusu Kurulumu: rsyslog ile Uzak Log Yönetimi

Bykomut

Onlarca sunucu yönetirken en büyük kabusu yaşadım bir keresinde: Gece yarısı bir uygulama çöktü, sabah geldiğimde log dosyaları rotate edilmiş, ilgili sunucu da patching sırasında yeniden başlatılmıştı. Delil yok, iz yok. O günden sonra merkezi log yönetimi benim için opsiyonel değil, zorunluluk haline geldi. Eğer siz de “logları sonra bakarım” diyenlerdenseniz, bu yazı tam size göre.

Merkezi Log Yönetimi Neden Gereklidir?

Birden fazla sunucu yönetiyorsanız, her birine ayrı ayrı SSH açıp tail -f /var/log/syslog yapmak hem verimsiz hem de riskli. Sunucu çöktüğünde diskinizdeki loglar da gider. Güvenlik olaylarını geriye dönük incelemek istediğinizde elimiz boş kalır.

Merkezi log sunucusunun sağladığı avantajlar:

  • Tek noktadan izleme: Tüm sunucuların loglarını bir yerden görebilirsiniz
  • Log bütünlüğü: Sunucu çökse bile loglar merkezi sunucuda güvende
  • Korelasyon analizi: Farklı sistemlerden gelen logları birbirleriyle ilişkilendirebilirsiniz
  • Uyumluluk gereksinimleri: PCI-DSS, ISO 27001 gibi standartlar merkezi log saklamayı şart koşar
  • Alarm mekanizmaları: Belirli log pattern’larında otomatik bildirim

Bu yazıda rsyslog kullanarak sıfırdan bir merkezi log altyapısı kuracağız. Hem log sunucusunu hem de client yapılandırmasını adım adım geçeceğiz. Üstüne güvenlik ve performans optimizasyonlarını da ekleyeceğiz.

Ortam Hakkında

Senaryomuzda şu yapıyı kullanacağız:

  • Log Sunucusu: Ubuntu 22.04, IP: 192.168.1.10
  • Client Sunucular: Ubuntu/CentOS karışık, çeşitli IP’ler
  • rsyslog versiyonu: 8.x (Ubuntu 22.04’te default olarak gelir)
  • İletişim protokolü: TCP (UDP’ye göre daha güvenilir)
  • Port: 514 (standart syslog portu)

Gerçek dünyada bu yapı bir datacenter içi kurulum için geçerli. Eğer internet üzerinden log göndericekseniz TLS şifrelemeyi mutlaka devreye alın, o konuya da değineceğiz.

Log Sunucusu Kurulumu

rsyslog Kurulumu ve Versiyon Kontrolü

Ubuntu 22.04’te rsyslog genellikle yüklü gelir ama kontrol edelim:

# Versiyon kontrolü
rsyslogd -v

# Eğer yüklü değilse
sudo apt update && sudo apt install rsyslog -y

# Servis durumunu kontrol et
sudo systemctl status rsyslog

CentOS/RHEL sistemlerde:

sudo yum install rsyslog -y
# veya
sudo dnf install rsyslog -y

Log Sunucusu Ana Yapılandırması

rsyslog’un ana yapılandırma dosyası /etc/rsyslog.conf dosyasıdır. Ubuntu’da ek yapılandırmalar /etc/rsyslog.d/ dizini altında .conf uzantılı dosyalarla yapılır. Bu modüler yapı çok pratik; her şeyi tek dosyaya doldurmak yerine mantıksal parçalara bölebilirsiniz.

Önce /etc/rsyslog.conf dosyasını açıp TCP modülünün aktif olduğundan emin olalım:

sudo nano /etc/rsyslog.conf

Şu satırları bulun ve yorum satırından çıkarın (başındaki # işaretini kaldırın):

# UDP desteği için (opsiyonel ama eski sistemler için gerekebilir)
module(load="imudp")
input(type="imudp" port="514")

# TCP desteği için (önerilen)
module(load="imtcp")
input(type="imtcp" port="514")

Merkezi Log Depolama Yapılandırması

Şimdi gelen logları nasıl saklayacağımızı tanımlayacağız. /etc/rsyslog.d/ altına ayrı bir dosya oluşturalım:

sudo nano /etc/rsyslog.d/10-remote-logs.conf

Dosya içeriği:

# Uzak loglar için template tanımla
# Her host kendi dizinine, her servis kendi dosyasına
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
$template DailyPerHost,"/var/log/remote/%HOSTNAME%/%$YEAR%-%$MONTH%-%$DAY%.log"

# Uzaktan gelen TÜM logları hostname bazında ayır
# İlk kural: program bazında dosyalama
:fromhost-ip, !isequal, "127.0.0.1" ?RemoteLogs

# Log sonrası işlemi durdur (local loglara da yazmasın)
& stop

Bu yapılandırmada iki template tanımladık. RemoteLogs template’i her host için ayrı dizin açar ve program adına göre dosyalara yazar. Böylece web-server-01 hostundan gelen nginx logları /var/log/remote/web-server-01/nginx.log dosyasına düşer.

Dizin Yapısı ve İzinler

# Log dizinini oluştur
sudo mkdir -p /var/log/remote

# rsyslog'un bu dizine yazabilmesi için izin ver
sudo chown syslog:adm /var/log/remote
sudo chmod 755 /var/log/remote

# rsyslog'u yeniden başlat
sudo systemctl restart rsyslog

# Hata var mı kontrol et
sudo journalctl -u rsyslog -n 20

Firewall Kuralları

Log sunucusuna gelen bağlantılara izin vermeliyiz:

# UFW kullanıyorsanız
sudo ufw allow 514/tcp
sudo ufw allow 514/udp
sudo ufw reload

# iptables kullanıyorsanız
sudo iptables -A INPUT -p tcp --dport 514 -j ACCEPT
sudo iptables -A INPUT -p udp --dport 514 -j ACCEPT

# Kuralı kalıcı hale getir
sudo iptables-save > /etc/iptables/rules.v4

Client Yapılandırması

Ubuntu/Debian Client

Client sunucularda rsyslog’u yapılandırarak logları merkezi sunucuya iletmesi gerekiyor. /etc/rsyslog.d/ altına yeni bir dosya oluşturalım:

sudo nano /etc/rsyslog.d/99-remote-server.conf
# Tüm logları TCP üzerinden merkezi sunucuya gönder
# @@ = TCP, @ = UDP
# 192.168.1.10 = log sunucunuzun IP'si
*.* @@192.168.1.10:514

# Kuyruk yapılandırması - sunucu erişilemez olursa logları bellekte tut
$ActionResumeRetryCount -1
$ActionQueueType LinkedList
$ActionQueueFileName remotequeue
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on

Bu yapılandırmada dikkat edilmesi gereken önemli bir detay var: kuyruk yapılandırması. Merkezi log sunucusu geçici olarak erişilemez hale gelirse, client logları diskte kuyruğa alır ve bağlantı yeniden kurulduğunda gönderir. Bu sayede log kaybı yaşanmaz.

# Client'ta rsyslog'u yeniden başlat
sudo systemctl restart rsyslog

CentOS/RHEL Client

CentOS’ta yapı biraz farklı, ana yapılandırma dosyasına ekleyebilirsiniz:

sudo nano /etc/rsyslog.conf

Dosyanın sonuna ekleyin:

# Tüm priority ve facility loglarını merkezi sunucuya gönder
*.* @@192.168.1.10:514

# Yeniden bağlanma ayarları
$ActionResumeRetryCount -1
$ActionQueueType LinkedList
$ActionQueueSaveOnShutdown on

Gelişmiş Yapılandırmalar

Facility Bazlı Log Yönlendirme

Belki her şeyi değil, sadece belirli servislerin loglarını merkezi sunucuya göndermek istiyorsunuzdur. Örneğin sadece auth logları ve kernel logları:

sudo nano /etc/rsyslog.d/99-selective-remote.conf
# Sadece auth ve security loglarını gönder
auth,authpriv.* @@192.168.1.10:514

# Kernel loglarını da gönder
kern.* @@192.168.1.10:514

# Kritik ve üzeri tüm logları gönder
*.crit @@192.168.1.10:514

# Belirli bir uygulama logunu gönder (örneğin nginx)
:programname, isequal, "nginx" @@192.168.1.10:514

Log Sunucusunda Gelişmiş Filtreleme

Log sunucusuna döndük. Gelen logları daha akıllıca işleyelim:

sudo nano /etc/rsyslog.d/20-filters.conf
# Template: Detaylı zaman damgası ile
$template DetailedFormat,"%timegenerated% %HOSTNAME% %syslogseverity-text% %programname%: %msg%n"

# Kritik loglar için ayrı dosya
if $syslogseverity <= 2 then /var/log/remote/CRITICAL.log
& stop

# Auth loglarını ayrı tut (güvenlik analizi için)
if $syslogfacility-text == 'auth' or $syslogfacility-text == 'authpriv' then /var/log/remote/auth-all.log
& stop

# Belirli bir host'tan gelen logları özel işle
if $fromhost-ip == '192.168.1.50' then /var/log/remote/db-server/all.log
& stop

TLS ile Güvenli Log İletimi

İnternet üzerinden veya hassas ortamlarda log gönderiyorsanız TLS şifrelemesi zorunludur. Önce gerekli modülü yükleyin:

# Log sunucusunda
sudo apt install rsyslog-gnutls -y

# Sertifika oluştur (test için self-signed)
sudo mkdir /etc/rsyslog-certs
cd /etc/rsyslog-certs

# CA anahtarı ve sertifikası oluştur
sudo openssl genrsa -out ca-key.pem 4096
sudo openssl req -new -x509 -days 3650 -key ca-key.pem -out ca-cert.pem 
  -subj "/C=TR/ST=Istanbul/O=SysAdmin/CN=LogServer-CA"

# Sunucu sertifikası oluştur
sudo openssl genrsa -out server-key.pem 4096
sudo openssl req -new -key server-key.pem -out server-req.pem 
  -subj "/C=TR/ST=Istanbul/O=SysAdmin/CN=192.168.1.10"
sudo openssl x509 -req -days 3650 -in server-req.pem 
  -CA ca-cert.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem

Log sunucusunda TLS yapılandırması:

sudo nano /etc/rsyslog.d/05-tls-server.conf
# TLS modülünü yükle
module(load="imtcp"
       StreamDriver.Name="gtls"
       StreamDriver.Mode="1"
       StreamDriver.Authmode="anon")

# TLS sertifika dosyaları
global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/rsyslog-certs/ca-cert.pem"
  DefaultNetstreamDriverCertFile="/etc/rsyslog-certs/server-cert.pem"
  DefaultNetstreamDriverKeyFile="/etc/rsyslog-certs/server-key.pem"
)

# TLS üzerinden 6514 portunu dinle (TLS için standart syslog portu)
input(type="imtcp" port="6514")

Log Rotasyonu

Merkezi log sunucusunda loglar hızla büyür. logrotate ile bunu kontrol altında tutalım:

sudo nano /etc/logrotate.d/remote-logs
/var/log/remote/*/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    sharedscripts
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Bu yapılandırma logları günlük rotate eder, 30 gün saklar ve sıkıştırır. Büyük ortamlarda 30 gün bile ciddi disk alanı gerektirebilir. Buna göre rotate değerini ayarlayın.

Gerçek Dünya Senaryosu: SSH Brute Force Tespiti

Merkezi log sunucusunun en güzel yanı, tüm sunucuların auth loglarını tek yerden analiz edebilmek. Şu basit komutla brute force denemelerini görebilirsiniz:

# Merkezi log sunucusunda çalıştırın
# Tüm sunuculardaki başarısız SSH girişlerini say ve sırala
grep "Failed password" /var/log/remote/auth-all.log | 
  awk '{print $11}' | 
  sort | uniq -c | sort -rn | head -20

Bunu biraz daha geliştirerek otomatik alarm scripti yazabiliriz:

#!/bin/bash
# /usr/local/bin/ssh-bruteforce-check.sh

THRESHOLD=10
LOG_FILE="/var/log/remote/auth-all.log"
ALERT_MAIL="[email protected]"

# Son 5 dakikadaki başarısız girişleri kontrol et
FAILED_ATTEMPTS=$(grep "Failed password" $LOG_FILE | 
  awk -v date="$(date -d '5 minutes ago' '+%b %e %H:%M')" 
  '$0 > date' | wc -l)

if [ $FAILED_ATTEMPTS -gt $THRESHOLD ]; then
    echo "UYARI: Son 5 dakikada $FAILED_ATTEMPTS başarısız SSH girişi tespit edildi!" | 
    mail -s "SSH Brute Force Alarm" $ALERT_MAIL
    
    # Saldıran IP'leri de raporla
    grep "Failed password" $LOG_FILE | 
      awk -v date="$(date -d '5 minutes ago' '+%b %e %H:%M')" 
      '$0 > date {print $11}' | 
      sort | uniq -c | sort -rn >> /var/log/bruteforce-report.log
fi

Bu scripti cron’a ekleyin:

sudo crontab -e
# Her 5 dakikada bir çalıştır
*/5 * * * * /usr/local/bin/ssh-bruteforce-check.sh

Yapılandırmayı Test Etme

Her şeyi kurduktan sonra test etmeden geçmeyin. Client sunucuda:

# Manuel log mesajı gönder
logger -p auth.info "TEST: Bu bir test mesajidir - $(hostname)"

# Belirli bir priority ile test
logger -p kern.crit "CRITICAL TEST: Kernel test mesaji"

# rsyslog'un durumunu kontrol et
sudo systemctl status rsyslog

# rsyslog konfigürasyonunu test et (syntax hataları için)
sudo rsyslogd -N1

# Bağlantıyı test et
telnet 192.168.1.10 514

Log sunucusunda gelen mesajı doğrulayın:

# Gelen logları real-time izle
sudo tail -f /var/log/remote/CLIENT_HOSTNAME/syslog.log

# Veya tüm remote logları izle
sudo find /var/log/remote -name "*.log" -newer /tmp/test-timestamp | 
  xargs tail -f 2>/dev/null

Performans Optimizasyonu

Çok sayıda client varsa (50+), log sunucusu altında ezilmeye başlayabilir. Birkaç önemli optimizasyon:

sudo nano /etc/rsyslog.conf
# Yüksek performans için global ayarlar
global(
  # Asenkron yazma - I/O beklemeden işleme devam et
  workDirectory="/var/spool/rsyslog"
)

# Ana mesaj kuyruğu boyutunu artır
main_queue(
  queue.size="100000"
  queue.dequeueBatchSize="1000"
  queue.workerThreads="4"
  queue.workerThreadMinimumMessages="10000"
)

Disk I/O darboğaz yaratıyorsa logları önce RAM’e alıp toplu yazma yapabilirsiniz:

# /etc/rsyslog.d/10-remote-logs.conf içine ekleyin
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"

# Asenkron action kuyruğu
$ActionQueueType LinkedList
$ActionQueueSize 50000
$ActionQueueDiscardMark 40000
$ActionQueueHighWaterMark 35000

:fromhost-ip, !isequal, "127.0.0.1" ?RemoteLogs
& stop

Monitoring: Log Sunucusunu Kim İzleyecek?

Log sunucusunun kendisinin sağlıklı çalışıp çalışmadığını da izlemeniz gerekir. Basit bir health check scripti:

#!/bin/bash
# /usr/local/bin/rsyslog-health-check.sh

# rsyslog çalışıyor mu?
if ! systemctl is-active --quiet rsyslog; then
    echo "KRITIK: rsyslog servisi çalışmıyor!" | 
    mail -s "Log Sunucusu Arıza" [email protected]
    systemctl start rsyslog
fi

# Disk doluluk oranı
DISK_USAGE=$(df /var/log/remote | awk 'NR==2 {print $5}' | tr -d '%')
if [ $DISK_USAGE -gt 80 ]; then
    echo "UYARI: Log diski %$DISK_USAGE dolu!" | 
    mail -s "Log Diski Dolma Uyarısı" [email protected]
fi

# Port dinleniyor mu?
if ! ss -tlnp | grep -q ':514'; then
    echo "KRITIK: rsyslog 514 portunu dinlemiyor!" | 
    mail -s "rsyslog Port Hatası" [email protected]
fi

Yaygın Sorunlar ve Çözümleri

Problem: Client logları gelmiyor Çözüm: Önce firewall kurallarını kontrol edin, sonra tcpdump -i any port 514 ile trafiği izleyin. Client’ta logger ile test mesajı gönderin.

Problem: Duplicate log girişleri var Çözüm: Client konfigürasyonunda & stop direktifini kullanmadıysanız loglar hem local hem de remote’a yazılıyor olabilir. Bu normal bir davranış, remote-only istiyorsanız local’e yazmayı durdurun.

Problem: Loglar yanlış zaman damgasıyla geliyor Çözüm: Tüm sunucuların NTP senkronizasyonunu kontrol edin:

timedatectl status
ntpq -p

Problem: Log sunucusu çok fazla CPU kullanıyor Çözüm: queue.workerThreads değerini CPU core sayısına göre ayarlayın. Çok fazla regex filtreleme de CPU tüketir, filtreleri optimize edin.

Sonuç

rsyslog ile merkezi log sunucusu kurmak göründüğü kadar karmaşık değil. Temel kurulumu birkaç saat içinde yapabilirsiniz. Önemli olan kurulduktan sonra bu altyapıyı aktif kullanmak ve logları gerçekten analiz etmek.

Benim önerdiğim adım sırası şu: Önce TCP ile basit bir kurulum yapın, logların geldiğini doğrulayın. Sonra log rotasyonunu ayarlayın, disk problemi yaşamayın. Ardından TLS şifrelemeyi devreye alın. Son olarak alarm mekanizmalarını kurun.

Bu yazıda anlattığımız yapı küçük ve orta ölçekli ortamlar için yeterli. Eğer günde milyonlarca log satırı işleyecekseniz veya daha gelişmiş analiz istiyorsanız rsyslog’u Elasticsearch ile entegre etmeyi düşünebilirsiniz. ELK Stack veya daha modern alternatifi olan Grafana Loki bu noktada devreye girer ama o hikaye başka bir yazının konusu.

En önemli şu: Mükemmel bir log altyapısı kurmak için beklemeyin. Basit bir rsyslog kurulumu bile sizi o “gece yarısı panic” anlarından kurtarır.

Similar Posts

Bir yanıt yazın

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