Linux Güvenlik Denetimi: Lynis ve Auditd Rehberi

Bir gün üretim sunucunuzda beklenmedik bir süreç çalıştığını fark ettiniz, ya da daha kötüsü, fark etmediniz. İşte güvenlik denetiminin tam olarak devreye girmesi gereken yer burası. Lynis ve auditd, Linux sistemlerde güvenlik açıklarını tespit etmek ve sistem aktivitelerini kayıt altına almak için birbirini tamamlayan iki güçlü araç. Bu yazıda her ikisini de gerçek dünya senaryolarıyla ele alacağız.

Lynis ile Güvenlik Taraması

Lynis, açık kaynaklı bir güvenlik denetim aracı. CISOlerin seveceği türden raporlar üretiyor ama asıl değeri sysadminler için: size sistemin güvenlik durumunu, zayıf noktalarını ve düzeltme önerilerini veriyor. CIS Benchmark ve diğer güvenlik standartlarıyla uyumlu kontroller yapıyor.

Kurulum

Lynis’i paket yöneticisiyle kurabilirsiniz ama en güncel sürümü için doğrudan GitHub’dan çekmek daha mantıklı. Paket depolarındaki sürümler genellikle birkaç versiyon geride kalıyor.

# Debian/Ubuntu
apt install lynis

# RHEL/CentOS/AlmaLinux
dnf install lynis

# Ya da güncel sürüm için:
cd /opt
git clone https://github.com/CISOfy/lynis
cd lynis

Kurulumdan sonra ilk taramayı çalıştırmadan önce Lynis’in veritabanını güncelleyin:

cd /opt/lynis
./lynis update info

İlk Tarama

Temel sistem taraması için şu komutu kullanıyoruz:

./lynis audit system

Bu komut yaklaşık 200’den fazla kontrol çalıştırır ve terminalde renk kodlu çıktı üretir. Yeşil tamam, sarı dikkat gerektiren, kırmızı kritik sorunlar anlamına gelir. Ama asıl önemli olan terminalden akan çıktı değil, /var/log/lynis.log ve /var/log/lynis-report.dat dosyaları.

Raporu okunabilir bir formatta kaydetmek için:

./lynis audit system --report-file /tmp/lynis-rapor-$(date +%Y%m%d).dat --log-file /tmp/lynis-$(date +%Y%m%d).log

Lynis Çıktısını Anlamak

Tarama tamamlandığında en önemli metrik Hardening Index değeri. 0-100 arasında bir puan. Yeni kurulmuş bir sistemde genellikle 55-65 bandında çıkar. 80 üzeri iyi bir hedef olarak kabul edilir, ama 90 üzeri için ciddi manuel müdahale gerekir.

Önerilen düzeltmeleri görmek için:

grep -i "suggestion" /var/log/lynis.log | head -30

Ya da rapor dosyasından:

grep "^suggestion" /var/log/lynis-report.dat

Gerçek dünyadan bir örnek: Geçen ay bir müşteri sunucusunda yaptığım taramada Lynis şunları buldu:

/tmp dizini ayrı bir partition’da değildi ve noexec flag’i yoktu
SSH’da PermitRootLogin yes hâlâ aktifti
Kernel parametreleri sertleştirilmemiş, net.ipv4.tcp_syncookies kapalıydı
AIDE ya da başka bir dosya bütünlük aracı yoktu

Bunların hepsini daha önce biliyorduk ama sayıları görünce önceliklendirme kolaylaştı.

Lynis ile Özelleştirme ve Profil Kullanımı

Farklı sunucu rolleri için farklı profiller oluşturabilirsiniz. Örneğin web sunucusu için:

# /etc/lynis/custom.prf dosyası oluştur
cat > /etc/lynis/custom.prf << 'EOF'
# Web sunucu profili
profile-name=webserver
profile-version=1

# Apache/Nginx kontrolleri aktif
enable-test=HTTP-6640
enable-test=HTTP-6643

# Gereksiz kontrolleri devre dışı bırak
skip-test=MAIL-8704
skip-test=MAIL-8706
EOF

Profille tarama:

./lynis audit system --profile /etc/lynis/custom.prf

Zamanlanmış Tarama ve Karşılaştırma

Lynis’i cron’a ekleyip haftalık tarama yapabilirsiniz. Daha da önemlisi, iki tarama arasındaki farkı görmek:

# Cron için script
cat > /usr/local/bin/lynis-haftalik.sh << 'EOF'
#!/bin/bash
TARIH=$(date +%Y%m%d)
RAPOR_DIZIN="/var/log/lynis-raporlar"
mkdir -p $RAPOR_DIZIN

/opt/lynis/lynis audit system 
    --report-file ${RAPOR_DIZIN}/rapor-${TARIH}.dat 
    --log-file ${RAPOR_DIZIN}/log-${TARIH}.log 
    --cronjob

# Hardening Index değerini çek ve kaydet
SKOR=$(grep "^hardening_index" ${RAPOR_DIZIN}/rapor-${TARIH}.dat | cut -d'=' -f2)
echo "${TARIH}: ${SKOR}" >> ${RAPOR_DIZIN}/skor-gecmisi.txt
EOF

chmod +x /usr/local/bin/lynis-haftalik.sh

# Cron'a ekle
echo "0 2 * * 0 root /usr/local/bin/lynis-haftalik.sh" > /etc/cron.d/lynis-tarama

Auditd ile Sistem Aktivitelerini İzleme

Lynis size “ne yapmalısın” sorusunun cevabını verirken, auditd “sistemde ne oldu” sorusunun cevabını veriyor. Linux Audit Framework üzerine kurulu bir daemon. Kernel seviyesinde çalışıyor, dolayısıyla kullanıcı alanındaki araçların kolayca atlatabileceği şeyleri yakalıyor.

Kurulum ve Temel Yapılandırma

# RHEL/CentOS/AlmaLinux
dnf install audit audit-libs

# Debian/Ubuntu
apt install auditd audispd-plugins

# Servisi başlat ve enable et
systemctl enable --now auditd

Ana yapılandırma dosyası /etc/audit/auditd.conf. Kritik birkaç parametreye bakalım:

# /etc/audit/auditd.conf içinde önemli ayarlar
log_file = /var/log/audit/audit.log
log_format = RAW
max_log_file = 100         # MB cinsinden, büyük sistemlerde artır
num_logs = 10              # Kaç tane rotasyon dosyası tutulsun
max_log_file_action = ROTATE
space_left = 500           # MB disk alanı kaldığında uyar
space_left_action = SYSLOG
admin_space_left = 100
admin_space_left_action = SUSPEND  # Kritik: disk dolunca audit'i durdurma

admin_space_left_action = SUSPEND ayarı tartışmalı. Compliance ortamlarında log kaybını önlemek için HALT bile kullanılıyor ama production için genellikle SYSLOG yeterli.

Audit Kuralları

Auditd’nin gücü kurallarda. /etc/audit/rules.d/ dizinine .rules uzantılı dosyalar bırakıyorsunuz. Sonra augenrules --load ile yüklüyorsunuz.

Temel bir kural seti oluşturalım:

cat > /etc/audit/rules.d/99-uygulama.rules << 'EOF'
# Buffer boyutunu artır
-b 8192

# Kimlik doğrulama olayları
-w /etc/passwd -p wa -k kimlik_degisikligi
-w /etc/shadow -p wa -k kimlik_degisikligi
-w /etc/group -p wa -k kimlik_degisikligi
-w /etc/sudoers -p wa -k sudo_degisikligi
-w /etc/sudoers.d/ -p wa -k sudo_degisikligi

# SSH yapılandırması
-w /etc/ssh/sshd_config -p wa -k ssh_konfig

# Başarısız giriş denemeleri
-w /var/log/faillog -p wa -k giris_basarisiz
-w /var/log/lastlog -p wa -k giris_gecmisi

# Yetkisiz dosya erişim denemeleri
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k yetkisiz_erisim
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k yetkisiz_erisim

# Yönetim araçları
-w /usr/bin/passwd -p x -k sifre_degisimi
-w /usr/bin/sudo -p x -k sudo_kullanim
-w /usr/sbin/useradd -p x -k kullanici_yonetim
-w /usr/sbin/userdel -p x -k kullanici_yonetim
-w /usr/sbin/usermod -p x -k kullanici_yonetim

# Cron değişiklikleri
-w /etc/cron.d/ -p wa -k cron_degisikligi
-w /etc/crontab -p wa -k cron_degisikligi
-w /var/spool/cron/ -p wa -k cron_degisikligi

# Sistem çağrısı bazlı kurallar (64-bit)
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k zaman_degisimi
-a always,exit -F arch=b64 -S sethostname -S setdomainname -k sistem_degisimi

# Kuralları değiştirilemez yap (reboot gerektirir geri almak için)
# -e 2
EOF

# Kuralları yükle
augenrules --load
auditctl -l  # Yüklenen kuralları kontrol et

Son satırdaki -e 2 yorum satırı olarak bırakıldı çünkü bu kuralları immutable yapıyor. Bir kez aktif edince kernel yeniden başlatılana kadar kuralları değiştiremezsiniz. Production’a almadan önce test edin.

Audit Loglarını Okumak: ausearch ve aureport

Ham audit logları oldukça kalabalık. ausearch ve aureport araçları bunları anlamlandırıyor.

# Son 1 saatteki sudo kullanımlarına bak
ausearch -k sudo_kullanim --start recent -i

# Belirli bir kullanıcının aktiviteleri
ausearch -ua ahmet --start today -i

# Başarısız giriş denemeleri
ausearch -k giris_basarisiz --start yesterday --end now -i

# Kimlik değişikliklerinin özet raporu
aureport --auth --summary

# Genel güvenlik özeti
aureport --summary

# Başarısız olayların raporu
aureport --failed --summary

Gerçek dünya senaryosu: Bir web sunucusunda gece 03:00’te www-data kullanıcısının /etc/passwd dosyasını okuduğunu auditd loglarından tespit ettik. Normal şartlarda web uygulamasının bu dosyaya ihtiyacı yok. Araştırdığımızda, bir PHP uygulamasına inject edilmiş kod parçası bulundu. Auditd olmasa bunu bulması günler sürerdi.

Gerçek Zamanlı Uyarı: audispd ve Syslog Entegrasyonu

Auditd tek başına log tutar ama sizi uyarmaz. audispd (audit dispatcher) ile logları gerçek zamanlı olarak işleyebilirsiniz.

# /etc/audisp/plugins.d/syslog.conf
cat > /etc/audisp/plugins.d/syslog.conf << 'EOF'
active = yes
direction = out
path = builtin_syslog
type = builtin
args = LOG_INFO
format = string
EOF

systemctl restart auditd

Artık audit olayları syslog’a da yazılıyor. Buradan rsyslog veya filebeat ile merkezi bir log sistemine (ELK, Graylog, Loki) yönlendirebilirsiniz.

Lynis ve Auditd’yi Birlikte Kullanmak

Bu iki araç birbirini güzel tamamlıyor. Tipik bir güvenlik denetim akışı şöyle işler:

Lynis ile önce mevcut güvenlik durumunuzu değerlendiriyorsunuz. Lynis “SSH root girişine izin veriyorsun” diyor. Siz de bunu düzeltiyorsunuz. Auditd ise bu değişikliklerin ardından sistemde ne olduğunu takip ediyor, sshd_config dosyasına yapılan her yazma işlemini kaydediyor.

Lynis’in önerdiği bir audit kural setini sisteme uygulayabilirsiniz:

# Lynis'in önerdiği audit kurallarını göster
grep "audit" /var/log/lynis-report.dat

# Lynis, genellikle şunu önerir:
# ACCT-9630: auditd servisinin aktif olmasını
# ACCT-9632: audit kurallarının yapılandırılmasını
# ACCT-9634: immutable audit kurallarını

Pratik Senaryo: PCI DSS veya ISO 27001 Uyum Hazırlığı

Uyum denetimine hazırlanıyorsanız her iki aracı da düzenli çalıştırmanız gerekiyor. Şöyle bir script hazırlayabilirsiniz:

#!/bin/bash
# /usr/local/bin/guvenlik-denetim.sh

TARIH=$(date +%Y%m%d_%H%M%S)
RAPOR_DIZIN="/var/log/guvenlik-raporlar/${TARIH}"
mkdir -p ${RAPOR_DIZIN}

echo "[*] Lynis taraması başlıyor..."
/opt/lynis/lynis audit system 
    --report-file ${RAPOR_DIZIN}/lynis-rapor.dat 
    --log-file ${RAPOR_DIZIN}/lynis.log 
    --cronjob

# Hardening Index değerini al
SKOR=$(grep "^hardening_index" ${RAPOR_DIZIN}/lynis-rapor.dat | cut -d'=' -f2)
ONERILER=$(grep "^suggestion" ${RAPOR_DIZIN}/lynis-rapor.dat | wc -l)
UYARILAR=$(grep "^warning" ${RAPOR_DIZIN}/lynis-rapor.dat | wc -l)

echo "[*] Audit log özeti çıkarılıyor..."
aureport --summary > ${RAPOR_DIZIN}/aureport-ozet.txt
aureport --failed > ${RAPOR_DIZIN}/aureport-basarisiz.txt
aureport --auth > ${RAPOR_DIZIN}/aureport-auth.txt

# Özet rapor
cat > ${RAPOR_DIZIN}/ozet.txt << OZET
Güvenlik Denetim Raporu - ${TARIH}
Sunucu: $(hostname)
Lynis Hardening Index: ${SKOR}/100
Öneri Sayısı: ${ONERILER}
Uyarı Sayısı: ${UYARILAR}
OZET

echo "[+] Rapor hazır: ${RAPOR_DIZIN}"

# Eğer skor belirli bir eşiğin altındaysa alarm ver
if [ "${SKOR}" -lt 65 ]; then
    echo "UYARI: Güvenlik skoru kritik seviyede: ${SKOR}/100" | 
    mail -s "[ALARM] Güvenlik Skoru Düşük: $(hostname)" [email protected]
fi

Sıkça Yapılan Hatalar

Auditd kurallarını yazarken dikkat edilmesi gereken birkaç nokta var.

Kural sayısı ve performans: Her kural bir kernel hook. Çok fazla kural yazarsanız, özellikle yoğun I/O yapan sunucularda performans etkisi hissedilir. -a never,exit kurallarıyla gürültüyü filtrelemek önemli.

auid filtresi: -F auid!=4294967295 filtresi önemli. Bu değer (UINT_MAX) kimlik doğrulaması yapılmamış süreçleri ifade eder. Bu filtresi koymadan cron jobları ve sistem servisleri binlerce gereksiz kayıt üretir.

Log rotasyonu: Auditd kendi log rotasyonunu yapıyor ama logrotate ile çakışabilir. /etc/logrotate.d/audit dosyasını kontrol edin ve ikisi arasında çakışma olmadığından emin olun.

Lynis tarafında da şunlara dikkat:

Root olmadan tarama yapmak: Lynis root olmadan çalışabilir ama bazı kontroller atlanır. Tam sonuç için root veya sudo gerekli.

False positive’leri tanımak: Lynis bazen ortamınıza göre anlamsız öneriler sunabilir. Örneğin, container ortamında çalışıyorsanız bazı kernel parametresi önerilerini uygulayamazsınız. Bunları profilinizde skip-test ile işaretleyin, her seferinde görmek sinir bozucu oluyor.

Sonuç

Lynis ve auditd, farklı katmanlarda çalışan ama birbirini güçlendiren araçlar. Lynis ile periyodik güvenlik değerlendirmeleri yapıyor, hardening skorunuzu takip ediyor ve standartlara uyum sürecinizi yönetiyorsunuz. Auditd ile ise sürekli, kernel seviyesinde sistem aktivitelerini kayıt altında tutuyorsunuz.

Bu araçların gerçek değeri düzenli kullanımdan geliyor. Sadece bir kez çalıştırıp unutulan bir araç değil bunlar. Lynis’i haftalık cron’a bağlayın, hardening skorunuzu zaman içinde takip edin. Auditd için ise kurallara kaos gibi ekleme yapmak yerine, iş gereksinimlerinize göre düşünülmüş, bakımı yapılabilir bir kural seti oluşturun.

Bir güvenlik ihlali yaşandığında “ne oldu” sorusuna cevap vermek için geri dönüp log kurmaya çalışmak, savaş başladıktan sonra siper kazmak gibi. Auditd çalışıyor ve Lynis düzenli tarama yapıyor olmalı; hem siz hem de CISO’nuz rahat uyusun.

Linux Sistemde Güvenlik Denetimi: Lynis ve Auditd Kullanımı