Reboot Sonrası CSF/LFD Loglarının Gelmemesi Sorunu ve Kesin Çözümü

Sunucu yöneticileri olarak sıkça karşılaştığımız problemlerden biri, güvenlik duvarı (CSF/LFD) tarafından üretilen “TCP in” ve “TCP out” block loglarının, sistem yeniden başlatıldığında /var/log/messages dosyasında görünmemesidir. Oysa csf -r komutunu çalıştırdığımızda loglar aniden gelmeye başlar. Bu yazıda, sorunun nedenini ve kalıcı çözümünü adım adım açıklayacağım.

Sorunun Belirtileri

  • Sunucu reboot atıldıktan sonra /var/log/messages dosyasında hiçbir bloklanma (block) logu yer almaz.
  • csf -r (veya systemctl restart lfd) yapıldığında loglar yeniden akışa geçer.
  • Servis durumu kontrol edildiğinde (systemctl status lfd) LFD active (running) görünür.
  • LFD loglarında (/var/log/lfd.log) “/var/log/messages has been reset” gibi mesajlar görülmez.

Sorunun Sebebi

Sorun iki temel faktörden kaynaklanır:

  1. Servis Başlangıç Sırası
    Systemd, servisleri varsayılan olarak paralel başlatır. LFD servisi, rsyslog servisinden önce başlatılabilir. O anda /var/log/messages dosyası henüz oluşmamıştır (rsyslog başlayınca oluşur). LFD dosyayı bulamadığı için onu izlemeye başlayamaz, ancak diğer log dosyalarını (ör. /var/log/secure) izlemeye devam ettiğinden servis active görünür. Bu nedenle loglar gelmez.
  2. Manuel Dosya Silme (Opsiyonel)
    Eğer /var/log/messages dosyasını rm komutuyla siliyorsanız, LFD’nin açık dosya tanımlayıcısı geçersiz olur ve yeni oluşan dosyayı otomatik olarak açmaz. csf -r ile LFD restart edilince yeni dosya bulunur ve loglar gelir.

Kalıcı Çözüm Adımları

Aşağıdaki üç çözümü birlikte uygulamanız, reboot sonrası sorunu tamamen ortadan kaldıracaktır.

1. LFD Servisini Rsyslog’dan Sonra Başlatacak Şekilde Yapılandırma

Bu ayar, reboot sonrası LFD’nin /var/log/messages oluştuktan sonra başlamasını garanti eder.

bash

systemctl edit lfd

Açılan dosyaya şu satırları ekleyin:

text

[Unit]
After=rsyslog.service

Kaydedip çıkın (Ctrl+O, Enter, Ctrl+X). Aynı işlemi CSF için de yapabilirsiniz (isteğe bağlı):

bash

systemctl edit csf

text

[Unit]
After=rsyslog.service

Sonra systemd’yi yeniden yükleyip servisleri restart edin:

bash

systemctl daemon-reload
systemctl restart rsyslog
systemctl restart lfd
systemctl restart csf
2. Logrotate ile copytruncate Kullanımı

Logrotate, log dosyalarını döndürürken varsayılan olarak dosyayı taşır (mv) ve yeni bir dosya oluşturur. Bu da LFD’nin izlediği dosyayı değiştirir. copytruncate seçeneği, dosyayı silmeden kopyalayıp içeriğini sıfırlar, böylece LFD’nin dosya tanımlayıcısı geçerli kalır.

/etc/logrotate.d/syslog dosyasını düzenleyin:

bash

vi /etc/logrotate.d/syslog

Aşağıdaki gibi messages bölümüne copytruncate ekleyin:

text

/var/log/messages {
    daily
    rotate 4
    copytruncate
    compress
    missingok
    notifempty
    create 0640 root root
}

Değişiklikleri kaydedin. Logrotate bundan sonra dosyayı silmeden döndürecektir.

3. Manuel Olarak Dosyayı Silmeyin, İçeriğini Boşaltın

Eğer log dosyasını temizlemek istiyorsanız, sakın rm /var/log/messages kullanmayın. Bunun yerine içeriğini sıfırlayın:

bash

> /var/log/messages

Bu komut dosyayı silmez, sadece içini boşaltır. LFD bu değişikliği anında algılar (“has been reset” mesajıyla) ve dosyayı yeniden açar, loglar kesintisiz gelir.

Çözümün Test Edilmesi

  1. Tüm ayarları yaptıktan sonra sunucuyu yeniden başlatın:bashreboot
  2. Açıldıktan sonra logları izleyin:bashtail -f /var/log/messages
  3. Başka bir terminalden bir test bağlantısı yapın (örneğin kapalı bir porta SSH deneyin) ve block loglarının geldiğini teyit edin.

Artık csf -r yapmaya gerek kalmadan reboot sonrası da loglarınız eksiksiz akacaktır.

Ek Tavsiyeler

  • Güvenlik: /etc/csf/csf.conf içinde RESTRICT_SYSLOG ayarını 3 olarak değiştirmeniz (syslog erişimini kısıtlamak) güvenlik açısından faydalıdır.
  • csf.ignore: LFD loglarında “Invalid entry” uyarısı varsa (ör. 131.0.72.0/222400:cb00::/32), bu geçersiz girişi csf.ignore dosyasından kaldırın.

Sonuç

Bu yazıdaki adımları uyguladığınızda, LFD’nin reboot sonrası /var/log/messages dosyasını kaçırması sorunu tamamen çözülür. Ayrıca manuel dosya silme alışkanlığınızı da düzeltmiş olursunuz. Sunucunuz artık her başlangıçta eksiksiz log kaydı tutacak ve güvenlik duvarı olaylarını anında raporlayacaktır.

Umarım bu makale, benzer sorunu yaşayan diğer sysadmin’lere de ışık tutar. Sorularınız varsa yorum bırakabilirsiniz.

Not: Bu içerik, AlmaLinux 8 / CentOS 8 ve CSF v14.24 üzerinde test edilmiştir. Farklı dağıtımlarda küçük farklılıklar olabilir.

Scroll to Top