auditd ile Sistem Denetim Günlüğü

Bir sunucuda bir gece yarısı /etc/passwd dosyası değiştiğinde ilk sorduğunuz soru şudur: kim, ne zaman, hangi süreçle ve hangi kullanıcı yetkisiyle bu değişikliği yaptı? Standart sistem günlükleri bu sorulara çoğu zaman yanıt veremez. Bir saldırgan içeri girip bir yapılandırma dosyasını değiştirdiğinde, syslog size yalnızca servisin yeniden başladığını söyler; asıl kritik olan "dosyaya kim dokundu" bilgisini vermez. İşte tam bu boşluğu Linux çekirdeğinin denetim alt sistemi ve onun kullanıcı alanı bileşeni olan auditd doldurur.

auditd, Linux Audit Framework'ün arka plan servisidir. Çekirdek seviyesinde gerçekleşen sistem çağrılarını (syscall), dosya erişimlerini, kimlik doğrulama olaylarını ve ayrıcalık değişimlerini yakalar; bunları değiştirilmesi zor, ayrıntılı bir denetim izine (audit trail) dönüştürür. Bu rehberde auditd'nin mimarisini, /etc/audit/rules.d altında kural yazmayı, ausearch ve aureport ile günlükleri sorgulamayı, passwd ve sudoers gibi kritik dosyaları izlemeyi ve tüm bunların uyumluluk (PCI-DSS, ISO 27001, KVKK) ve olay müdahalesindeki rolünü kıdemli bir sistem yöneticisinin gözünden ele alacağım.

auditd Mimarisi Nasıl Çalışır#

Denetim çerçevesi birkaç katmandan oluşur ve bu katmanları anlamak, sonradan "neden kural işlemiyor" gibi sorunları çözerken çok işe yarar. En altta çekirdek denetim alt sistemi vardır; syscall'ları ve olayları burada yakalar. Çekirdek, yakaladığı olayları bir soket üzerinden kullanıcı alanına iletir. Kullanıcı alanında ise ana bileşen auditd servisidir. auditd bu olayları alır ve varsayılan olarak /var/log/audit/audit.log dosyasına yazar.

auditd tek başına çalışmaz. Etrafında bir araç takımı bulunur:

• auditctl — çalışma zamanında kural ekleyen, silen ve denetim durumunu yöneten komut satırı aracı.
• augenrules — /etc/audit/rules.d/*.rules dosyalarını birleştirip kalıcı kural setini üreten araç.
• ausearch — ham günlükleri insan tarafından okunabilir biçimde sorgulayan arama aracı.
• aureport — özet raporlar üreten istatistik aracı.
• auditspd / audisp — denetim olaylarını başka sistemlere (örneğin bir SIEM'e) yönlendiren eklenti dağıtıcısı.

Önce paketi kuralım ve servisin durumunu kontrol edelim:

# Debian / Ubuntu
apt-get update && apt-get install -y auditd audispd-plugins

# RHEL / AlmaLinux / Rocky
dnf install -y audit audispd-plugins

systemctl enable --now auditd
systemctl status auditd

Servisin çalıştığını ve mevcut durumu görmek için:

auditctl -s

Bu komut enabled, pid, backlog_limit gibi değerleri gösterir. enabled değeri 2 ise denetim yapılandırması kilitlenmiştir ve yeniden başlatmadan değiştirilemez; bu, üretim sistemlerinde kural manipülasyonunu önlemek için kullanılan bir sertleştirme ayarıdır.

Denetim Kurallarını /etc/audit/rules.d ile Yazmak#

Kalıcı kurallar /etc/audit/rules.d/ dizinindeki .rules uzantılı dosyalarda tutulur. Servis başlarken augenrules --load bu dosyaları alfabetik sırayla birleştirir ve tek bir kural setine dönüştürür. Doğrudan audit.rules dosyasını elle düzenlemek yerine, konuya göre ayrılmış dosyalar oluşturmak (örneğin 10-kritik-dosyalar.rules, 20-syscall.rules) yönetimi kolaylaştırır.

Üç temel kural türü vardır. Aşağıdaki tablo bunları özetliyor:

Dosya izleme kuralları en anlaşılır olanlardır. Sözdizimi şöyledir:

# -w izlenecek yol, -p izin türü (r=okuma w=yazma x=çalıştırma a=öznitelik)
# -k olaya verilen anahtar (arama sırasında filtrelemek için)
-w /etc/passwd -p wa -k parola_dosyasi
-w /etc/shadow -p wa -k golge_dosyasi
-w /etc/sudoers -p wa -k yetki_degisikligi
-w /etc/sudoers.d/ -p wa -k yetki_degisikligi

Buradaki -p wa ifadesi "yazma ve öznitelik değişikliği" olaylarını yakalar; okuma denetimini genellikle eklemeyiz çünkü /etc/passwd gibi dosyalar sürekli okunur ve günlüğü gereksiz yere şişirir. -k anahtarı çok önemlidir; sonradan ausearch -k parola_dosyasi diyerek yalnızca bu olayları çekebilirsiniz.

Syscall kuralları daha güçlüdür ve dosya izlemeden farklı olarak davranışa göre filtreler. Örneğin, sistemdeki zaman değişikliklerini izlemek uyumluluk açısından kritiktir:

# Zaman ve saat değişikliklerini izle (64-bit)
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k zaman_degisikligi
-a always,exit -F arch=b32 -S adjtimex -S settimeofday -k zaman_degisikligi

# Başarısız dosya erişimlerini yakala (izin reddi ve dosya yok hataları)
-a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -k erisim_reddi
-a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k erisim_reddi

Buradaki -a always,exit "her zaman, sistem çağrısı çıkışında kaydet" anlamına gelir. -F arch=b64 mimariyi filtreler; hem 64-bit hem 32-bit çağrıları yakalamak için genellikle iki satır yazılır. -S yakalanacak syscall'ı belirtir. -F exit=... ise yalnızca belirli bir dönüş değeriyle biten çağrıları süzer.

Kuralı yazdıktan sonra yükleyip test edin:

augenrules --load
auditctl -l          # yüklü kuralları listele

Çalışma zamanında hızlıca bir kural denemek isterseniz auditctl ile geçici olarak ekleyebilirsiniz; ancak bu kural yeniden başlatmada kaybolur:

auditctl -w /etc/nginx/nginx.conf -p wa -k web_yapilandirma

Kritik Dosyaları İzleme — passwd, sudoers ve SSH#

Bir sunucuda hangi dosyaların değiştiğini bilmek, ihlal tespitinin belkemiğidir. Saldırganların ilk yaptığı işlerden biri kalıcılık sağlamak için kullanıcı ekleme, yetki yükseltme ya da SSH yapılandırmasını değiştirmektir. Bu yolları izleyen kapsamlı bir kural seti oluşturalım. /etc/audit/rules.d/50-kritik.rules dosyasına şunları yazın:

# Kullanıcı ve grup veritabanı
-w /etc/passwd -p wa -k kimlik_degisikligi
-w /etc/group -p wa -k kimlik_degisikligi
-w /etc/shadow -p wa -k kimlik_degisikligi
-w /etc/gshadow -p wa -k kimlik_degisikligi

# Ayrıcalık ve yetkilendirme
-w /etc/sudoers -p wa -k yetki_degisikligi
-w /etc/sudoers.d/ -p wa -k yetki_degisikligi

# SSH sunucu yapılandırması
-w /etc/ssh/sshd_config -p wa -k ssh_yapilandirma
-w /root/.ssh/ -p wa -k ssh_anahtar

# Zamanlanmış görevler (kalıcılık için sık kullanılır)
-w /etc/crontab -p wa -k zamanli_gorev
-w /etc/cron.d/ -p wa -k zamanli_gorev

# Çekirdek modülü yükleme/kaldırma
-a always,exit -F arch=b64 -S init_module -S delete_module -k cekirdek_modul

Bu kuralları yükledikten sonra bir test yapalım. Rutin bir kullanıcı ekleme işleminin denetim izinde nasıl göründüğünü görelim:

augenrules --load
useradd -m denemekullanici
ausearch -k kimlik_degisikligi -i | tail -n 30

-i bayrağı ham sayısal değerleri (UID, syscall numaraları) okunabilir isimlere çevirir, bu yüzden çıktıyı incelerken hep kullanın. Kayıtta auid (audit UID) alanına özellikle dikkat edin: bu, oturumu açan asıl kullanıcının kimliğidir ve sudo ile root'a geçilse bile değişmez. Yani biri sudo su - yapıp root olarak dosya değiştirse dahi, auid size arkadaki gerçek insanı gösterir. Bu, denetim izinin en değerli özelliğidir ve neden sudo günlüklerinden çok daha güvenilir olduğunun cevabıdır.

Web sunucuları için de benzer bir mantık kurabilirsiniz. Örneğin bir paylaşımlı hosting ya da WordPress ortamında yapılandırma dosyalarının izlenmesi, yetkisiz değişiklikleri erken yakalamanızı sağlar:

-w /etc/nginx/ -p wa -k web_yapilandirma
-w /var/www/html/wp-config.php -p wa -k wordpress_yapilandirma

Bu tür bir izleme katmanı, sunucu güvenliğinin genel resmini tamamlar. Denetim günlüğü tek başına saldırıyı engellemez; ancak güçlü bir temel yapılandırmayla birlikte kullanıldığında ne olduğunu geriye dönük olarak kanıtlar. Sunucu güvenliğinin bütününe bakmak isterseniz sunucu güvenliği temelleri rehberimiz iyi bir başlangıç noktasıdır.

ausearch ile Denetim Günlüklerini Sorgulama#

/var/log/audit/audit.log dosyasını doğrudan cat ile okumaya çalışmak boşuna bir uğraştır; her olay birden fazla kayıt satırına bölünmüştür ve alanlar sayısaldır. İşte bu yüzden ausearch vazgeçilmezdir. Bu araç ilişkili kayıtları tek bir olayda birleştirir, zamana göre filtreler ve okunabilir çıktı üretir.

En sık kullanılan sorgular şunlardır:

# Belirli bir anahtara ait olayları getir
ausearch -k yetki_degisikligi -i

# Belirli bir kullanıcının (auid) tüm eylemleri
ausearch -ua 1001 -i

# Belirli bir zaman aralığı
ausearch --start 07/10/2026 08:00:00 --end 07/10/2026 18:00:00 -i

# Son bir saatte olan olaylar
ausearch --start recent -i

# Belirli bir dosyaya yapılan erişimler
ausearch -f /etc/passwd -i

# Başarısız oturum açma denemeleri
ausearch -m USER_LOGIN --success no -i

-m bayrağı olay mesajı tipine göre filtreler. En çok işinize yarayacak tipler şunlardır:

Özellikle EXECVE bir olay müdahalesi sırasında altın değerindedir; saldırganın hangi komutu hangi argümanlarla çalıştırdığını gösterir. Örneğin tüm root komutlarını izlemek için şu syscall kuralını ekleyip ardından sorgulayabilirsiniz:

# root'un çalıştırdığı tüm komutları kaydet (dikkat: çok günlük üretir)
-a always,exit -F arch=b64 -F euid=0 -S execve -k root_komutlari

# Sonrasında sorgu
ausearch -k root_komutlari -i | grep -A2 EXECVE

Bu son kuralı üretimde kullanırken dikkatli olun; kök kullanıcı çok sayıda komut çalıştırdığında günlük hacmi hızla büyür. Genellikle bunu yalnızca aktif bir olay araştırması sırasında veya sıkı uyumluluk gerektiren sistemlerde açık tutarız.

aureport ile Özet Raporlar Üretmek#

ausearch tek tek olayları incelemek içinken, aureport genel resmi görmek içindir. Bir denetim döngüsünde önce aureport ile "nerede anormallik var" diye bakar, sonra ausearch ile o noktayı kazarsınız. Bu ikili yaklaşım zamandan büyük tasarruf sağlar.

Birkaç pratik rapor komutu:

# Genel özet
aureport

# Başarısız kimlik doğrulama olayları
aureport -au --failed

# Kullanıcıya göre olay dağılımı
aureport -u -i

# En çok değiştirilen dosyalar
aureport -f -i --summary

# Çalıştırılan tüm komutların özeti
aureport -x --summary

# Anormallik (anomaly) raporu
aureport --anomaly

aureport -au --failed çıktısı, brute-force saldırılarının tipik izini gösterir: kısa zaman aralığında yoğunlaşan başarısız kimlik doğrulama olayları. Bunu gördüğünüzde, saldırıyı yavaşlatmak için bir sonraki savunma katmanına, yani otomatik IP engellemeye geçmek istersiniz; bunun için Fail2ban kurulumu rehberimizdeki yöntemleri auditd ile birlikte kullanabilirsiniz. auditd size "ne oldu"yu kanıtlarken, Fail2ban "tekrarlamasını" engeller; ikisi birbirini tamamlar.

Raporları otomatikleştirmek için basit bir günlük özet betiği yazıp cron ile e-posta olarak alabilirsiniz:

#!/usr/bin/env bash
# /usr/local/bin/gunluk-denetim-ozeti.sh
DUN=$(date -d "yesterday" +%m/%d/%Y)
{
  echo "=== Başarısız Girişler ==="
  aureport -au --failed --start "$DUN" 00:00:00 --end "$DUN" 23:59:59
  echo "=== Yetki Değişiklikleri ==="
  ausearch -k yetki_degisikligi --start "$DUN" 00:00:00 -i 2>/dev/null | head -n 40
} | mail -s "Denetim Özeti $DUN" [email protected]

Günlük Bütünlüğü, Saklama ve Performans#

Bir denetim izinin işe yaraması için değiştirilemez olması gerekir. Saldırgan sisteme girip günlükleri silebiliyorsa, denetim izinin adli değeri kalmaz. Bu yüzden auditd yapılandırmasında birkaç sertleştirme ayarı kritiktir. /etc/audit/auditd.conf dosyasındaki şu değerlere dikkat edin:

# /etc/audit/auditd.conf
max_log_file = 50
num_logs = 10
max_log_file_action = ROTATE
space_left = 250
space_left_action = EMAIL
admin_space_left = 100
admin_space_left_action = SINGLE
disk_full_action = HALT
flush = INCREMENTAL_ASYNC

Buradaki disk_full_action = HALT ayarı, disk dolduğunda sistemin durmasını sağlar; bu radikal görünse de uyumluluk gereken ortamlarda "günlük tutulamıyorsa çalışma" ilkesi tercih edilir. Daha yumuşak bir yaklaşım için SYSLOG seçilebilir. En kritik önlem ise günlükleri başka bir sunucuya göndermektir; yerel diskteki günlük her zaman silinebilir, ama uzak bir log sunucusuna anlık iletilen kayıt saldırganın erişemeyeceği yerdedir. Bunu audisp-remote eklentisiyle ya da olayları bir SIEM'e ileten bir yapılandırmayla yaparsınız.

Performans tarafında iki ayar önemlidir. Birincisi -b ile ayarlanan arabellek boyutu (backlog limit); yoğun sistemlerde varsayılan 320 çok küçük kalır ve çekirdek olay düşürmeye başlar. /etc/audit/rules.d/ içindeki bir kontrol dosyasında şunu artırın:

# Arabellek limitini yükselt (yoğun sunucular için)
-b 8192
# Hata modu: 1=printk (uyar), 2=panik (kritik sistemler)
-f 1

İkincisi, gereksiz kurallardan kaçınmaktır. Her okuma işlemini izleyen -p r kuralları ya da tüm execve çağrılarını yakalayan geniş kurallar, işlem başına birkaç mikrosaniyelik gecikme ekler ve günlüğü şişirir. Kural yazarken "bu olayı bir ihlal araştırmasında gerçekten arayacak mıyım" diye sorun; cevap hayırsa o kuralı yazmayın. İyi bir denetim politikası dar ve amaca yöneliktir, geniş ve gürültülü değil.

Uyumluluk ve Olay Müdahalesindeki Rolü#

auditd'nin en büyük değeri, teknik bir araç olmanın ötesinde bir kanıt üretme mekanizması olmasıdır. PCI-DSS'in 10. gereksinimi, ISO 27001'in A.12.4 kontrolü ve KVKK'nın "veri güvenliğine ilişkin yükümlülükler" maddesi, hepsi hassas verilere ve sistemlere erişimin kaydedilmesini ve saklanmasını şart koşar. Bu düzenlemeler soyut bir "log tutun" talebi değildir; kimin, neye, ne zaman eriştiğini gösteren, değiştirilemez ve zaman damgalı bir iz isterler. auditd tam olarak bu izi üretir.

Uyumluluk için tipik bir kural seti şu unsurları içermelidir:

• Kimlik doğrulama olayları (başarılı ve başarısız oturum açmalar).
• Ayrıcalıklı komut kullanımı ve yetki değişiklikleri (sudo, sudoers).
• Hesap yönetimi (kullanıcı ekleme, silme, parola değişimi).
• Sistem ayarı değişiklikleri (zaman, ağ yapılandırması, çekirdek modülleri).
• Denetim yapılandırmasının kendisine yapılan değişiklikler.

Olay müdahalesi (incident response) tarafında auditd, olayların sıralamasını yeniden inşa etmenizi sağlar. Bir sunucunun ihlal edildiğinden şüphelenildiğinde şu akışı izlersiniz: önce aureport --anomaly ile genel anormalliklere bakarsınız, sonra şüpheli zaman aralığını ausearch --start ile daraltırsınız, ardından şüpheli auid veya IP üzerinden bütün eylem zincirini çıkarırsınız. EXECVE kayıtları saldırganın komutlarını, PATH kayıtları dokunduğu dosyaları, USER_LOGIN kayıtları giriş noktasını verir. Bu üçlüyü birleştirdiğinizde, spekülasyon değil kanıta dayalı bir zaman çizelgesi elde edersiniz.

Şunu unutmayın: auditd geçmişi kaydeder, geleceği engellemez. Bu yüzden onu bir savunma katmanının parçası olarak düşünün. Güncel bir işletim sistemi, sıkı bir güvenlik duvarı, düzenli yedekler, WAF ve DDoS koruması gibi önleyici katmanlar saldırıyı azaltırken auditd de olan biteni değişmez biçimde belgeler. Bu katmanların hepsini kendi sunucunuzda yönetmek isterseniz VDS sunucu çözümleri size tam kök erişimi ve auditd'yi özgürce yapılandırma imkânı sunar; kurulum ve sertleştirme yükünü uzmanlara bırakmak isterseniz sunucu yönetimi hizmetimiz devreye girer.

Sıkça Sorulan Sorular#

auditd ile syslog arasındaki fark nedir?#

syslog uygulamaların gönüllü olarak ürettiği mesajları toplar; yani bir program günlük yazmayı seçmezse orada iz kalmaz. auditd ise çekirdek seviyesinde çalışır ve sistem çağrılarını doğrudan yakalar, bu yüzden uygulamanın işbirliğine ihtiyaç duymaz. Ayrıca auditd oturumu açan asıl kullanıcıyı auid alanında saklar, böylece sudo ile kimlik değiştirilse bile gerçek fail izlenebilir; syslog bu bağlamsal derinliği sağlamaz. Kısacası ikisi rakip değil tamamlayıcıdır.

auditd performansı ne kadar etkiler?#

Etki büyük ölçüde yazdığınız kural sayısına ve kapsamına bağlıdır. Birkaç kritik dosyayı ve kimlik olaylarını izleyen dar bir politika, tipik bir sunucuda ölçülebilir bir yavaşlamaya yol açmaz. Ancak her execve çağrısını ya da tüm dosya okumalarını yakalayan geniş kurallar, işlem başına küçük gecikmeler ekler ve yoğun sistemlerde toplamda hissedilir. En iyi yaklaşım, arabellek limitini yeterince yüksek tutmak ve yalnızca bir ihlal araştırmasında gerçekten arayacağınız olayları izlemektir.

Denetim günlükleri diski çok doldurursa ne yapmalıyım?#

Öncelikle /etc/audit/auditd.conf içindeki max_log_file, num_logs ve max_log_file_action = ROTATE ayarlarıyla günlük döndürmeyi yapılandırın; bu, eski günlükleri otomatik arşivler. İkinci olarak izleme politikanızı gözden geçirin çünkü aşırı büyüyen günlük genellikle fazla geniş kuralların işaretidir. Uzun vadeli çözüm ise günlükleri uzak bir log sunucusuna ya da SIEM'e iletmektir; böylece yerel disk yükü azalır ve aynı zamanda günlükler saldırganın erişemeyeceği bir yere kopyalanmış olur.

Bir saldırgan auditd günlüklerini silebilir mi?#

Root erişimi elde eden bir saldırgan teorik olarak yerel /var/log/audit/audit.log dosyasını değiştirebilir, ancak bunu zorlaştıracak birkaç önlem vardır. Denetim yapılandırmasını -e 2 ile kilitlerseniz kurallar yeniden başlatmaya kadar değiştirilemez hale gelir. Daha önemlisi, günlükleri anlık olarak ayrı bir sunucuya ileterek yerel dosya silinse bile kanıtın uzakta kalmasını sağlarsınız. Bu yüzden ciddi ortamlarda uzak günlükleme, günlük bütünlüğünün olmazsa olmazıdır.

auditd kuralları yeniden başlatmadan sonra kayboluyor, neden?#

Muhtemelen kuralları auditctl komutuyla çalışma zamanında eklediniz; bu tür kurallar yalnızca bellekte tutulur ve servis yeniden başladığında silinir. Kalıcı kurallar /etc/audit/rules.d/ dizinindeki .rules dosyalarına yazılmalı ve augenrules --load ile yüklenmelidir. Servis her başladığında bu dosyaları otomatik olarak birleştirip uygular. auditctl -l ile o an yüklü kuralları, /etc/audit/rules.d/ içeriğiyle karşılaştırarak farkı doğrulayabilirsiniz.

Hangi dosyaları izlemeye öncelik vermeliyim?#

En yüksek öncelik, kimlik ve yetki ile ilgili dosyalardır: /etc/passwd, /etc/shadow, /etc/sudoers ve /etc/sudoers.d/. Hemen ardından uzaktan erişimin kapısı olan /etc/ssh/sshd_config ve SSH anahtar dizinleri gelir. Üçüncü sırada kalıcılık için sıkça kötüye kullanılan zamanlanmış görev dizinleri (/etc/cron.d/, /etc/crontab) yer alır. Bu çekirdek setle başlayıp, sisteminize özgü kritik yapılandırma dosyalarını (web sunucusu, veritabanı, uygulama config'leri) zamanla eklemek dengeli bir politika kurar.

Kapanış#

auditd, bir sunucuda olup biteni değiştirilemez biçimde belgeleyen, güvenlik ve uyumluluğun sessiz ama vazgeçilmez bir bileşenidir. Doğru yapılandırıldığında size "kim, ne zaman, neyi, hangi yetkiyle" sorularının kesin yanıtını verir; bir olay yaşandığında spekülasyon yerine kanıta dayalı bir zaman çizelgesi çıkarmanızı sağlar. Dar ve amaca yönelik kurallarla başlayın, kritik dosyaları izleyin, günlükleri uzağa iletin ve ausearch ile aureport'u rutininizin parçası yapın.

Bu denetim katmanını hayata geçirebileceğiniz sağlam bir altyapıya ihtiyacınız varsa, tam kök erişimi sunan VDS ve sanal sunucu çözümlerimizi inceleyebilir, güvenlik sertleştirmesini bize bırakmak isterseniz sunucu yönetimi hizmetimizden yararlanabilirsiniz. WAF, DDoS koruma ve yedekleme gibi tamamlayıcı katmanlarla birlikte, denetim günlüğü tutan bir sunucu hem düzenlemelere uyumlu hem de olaylara hazır olur. Clou.TR olarak, altyapınızı güvenle yönetebilmeniz için gereken tüm araçları bir arada sunuyoruz.