Linux’ta Auditd ile Ayrıcalıklı Komut İzleme Runbook’u

Üretimde “kim, neyi, ne zaman yaptı?” sorusu genelde bir incident sonrası gelir. Asıl problem, bu sorunun cevabının tek bir log satırında değil; sudo politikası, shell geçmişi, süreç ağacı ve dosya erişim izleri gibi farklı kanallarda dağılmış olmasıdır. Auditd burada sihirli değnek değil; ama doğru tasarlanırsa ayrıcalıklı işlemleri operasyonel olarak izlenebilir kılan en güvenilir katmanlardan biridir.

Bu yazıda, auditd’yi “kurduk bitti” seviyesinden çıkarıp bir runbook’a bağlayacağız: hangi olayları toplayacağız, nasıl gürültüyü azaltacağız, performansı nasıl koruyacağız ve SIEM tarafında nasıl anlamlandıracağız.

Hedef: ayrıcalıklı işlem izini tek bir hikâyeye bağlamak

Minimum hedefi şöyle tanımlıyorum:

• Kimlik: Hangi kullanıcı (ve mümkünse hangi oturum/pam bağlamı) yaptı?
• Eylem: Hangi komut çalıştı, hangi dosyalara dokundu?
• Bağlam: Hangi host, hangi rol (prod/stage), hangi değişiklik penceresi?
• İz: Log kaybı olmadan merkezi toplayıcıya gitti mi?

Auditd tek başına “komutun tam string’i”ni her zaman vermez; ancak syscall seviyesinde süreç ve dosya erişim izi sağladığı için çok değerli bir kanıt zinciri oluşturur.

Tasarım kararı: “çok kural” değil, “az ama güvenilir kural”

Üretimde auditd’nin en hızlı öldüğü yer, kontrolsüz kural setidir. Aşırı event üretimi:

• Disk I/O ve journald/audit backlog baskısı yaratır
• SIEM maliyetini ve gürültüyü yükseltir
• Incident anında aradığını bulmayı zorlaştırır

Bu yüzden yaklaşımım iki katmanlıdır:

1. Temel ayrıcalıklı iz: root erişimi, sudo kullanımı, kritik dosya değişimleri
2. Olay anı genişletme: Sadece incident sırasında açılan “geçici” ek kurallar

Kurulum ve servis sağlığı kontrolü

Distribüsyona göre paket isimleri değişse de sağlık kontrolü aynı:

sudo systemctl enable --now auditd
sudo systemctl status auditd --no-pager
sudo auditctl -s

auditctl -s çıktısında özellikle şu alanları takip et:

• enabled 1 (aktif)
• backlog_limit (yük altında kuyruk kapasitesi)
• lost (kayıp event sayısı)

Kritik iz alanları: sudo, root ve yapılandırma dosyaları

1) Sudo kullanımı (kimlik izi)

Sudo olayları çoğu zaman auth log’larında vardır; fakat auditd ile bunu daha deterministik yakalarsın. Aşağıdaki örnek, sudo binary’sinin çalıştırılmasını izlemeye odaklanır.

sudo auditctl -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv-sudo

Notlar:

• auid gerçek kullanıcıyı taşır (sudo ile euid root olsa bile).
• -k anahtarı, SIEM tarafında hızlı filtre için altın değerindedir.

2) Kritik dosyalarda yazma (değişiklik izi)

Prod’da kritik dosya listesi kurumdan kuruma değişir ama tipik bir baseline:

• /etc/sudoers ve /etc/sudoers.d/
• SSH: /etc/ssh/sshd_config, /root/.ssh/authorized_keys
• Servis tanımları: systemd unit dosyaları
• Ağ: firewall kural setleri, VPN konfigleri

Örnek:

sudo auditctl -w /etc/sudoers -p wa -k cfg-sudoers
sudo auditctl -w /etc/ssh/sshd_config -p wa -k cfg-sshd
sudo auditctl -w /etc/systemd/system -p wa -k cfg-systemd

Bu, “dosyaya yazıldı”yı yakalar; içeriğin ne olduğu için ise değişiklik yönetimi (GitOps / config repo) ve file integrity ek katman gerekir.

3) Ayrıcalıklı süreç zinciri (şüpheli davranış izi)

Kritik yaklaşım: Sadece “hangi komut” değil, “hangi süreç ağacı” da önemlidir. Auditd olaylarını korele ederken:

• pid / ppid ilişkisinden süreç ağacı çıkar
• exe alanı ile hangi binary çalıştı gör
• cwd ve comm alanlarını birlikte değerlendir

Sudo I/O logging: komut + çıktı izini tamamlamak

Auditd’nin eksik kaldığı yerde sudo’nun I/O log özelliği devreye girer. Ama bunu “her şey için” açmak yerine, kritik roller için hedeflemek daha sürdürülebilir olur.

Örnek sudoers yaklaşımı:

Defaults log_output
Defaults iolog_dir="/var/log/sudo-io/%{user}"
Defaults!ALL iolog_file="%Y%m%d_%H%M%S_%{command}"
Defaults iolog_compress

Runbook: Incident anında hızlı doğrulama

Aşağıdaki akışı gerçek hayatta defalarca kullandım:

1. Kapsam: Host + zaman aralığı + kullanıcı/auid belirle
2. Sudo izi: priv-sudo anahtarından filtrele
3. Konfig değişimi: cfg-* anahtarlarına bak
4. İz genişlet: Gerekirse geçici kural ekle (dar kapsam!)
5. Korelasyon: SIEM’de süreç zinciri / auth log / deployment log ile birleştir

Komut örnekleri:

sudo ausearch -k priv-sudo --start today
sudo ausearch -k cfg-sshd --start 2026-04-13 --end now
sudo aureport --auth --summary

SIEM tarafı: “event” değil, “anlam” taşı

Audit log’ları ham haliyle gürültülüdür. SIEM’de işe yarayan alanları normalize et:

• key → use-case etiketi (priv-sudo, cfg-sshd gibi)
• auid / uid / euid → kimlik üçlüsü
• exe / comm → çalıştırılan binary
• hostname / env → prod/stage ayrımı

Sonuç

Auditd, doğru hedeflerle ve iyi bir runbook’la kullanıldığında ayrıcalıklı erişimin en kritik boşluklarını kapatır: “kim yaptı?” ve “hangi sistemde yaptı?” soruları netleşir. Komutun tamamı ve çıktısı için sudo I/O logging gibi tamamlayıcı katmanları eklediğinde ise incident sonrası araştırma süreleri dramatik biçimde düşer. Asıl kazanım, güvenliği bir checklist olmaktan çıkarıp operasyonel bir kas hafızasına dönüştürmektir.