Furkan İkkan English
Yazılara geri dön
Yazı

· Network & System Administrator

auditd Kurallarıyla /etc/passwd ve /etc/shadow Dosyalarına Yazma Girişlerini Önle

auditctl ve augenrules komutlarını kullanarak, systemd entegrasyonu üzerinden kritik şifre dosyalarına gerçek zamanlı olarak yetkisiz yazma işlemlerini izleyin ve engelleyin.

Siber Güvenlikauditdsystemdlog monitoringfile integrity

Çoğu yönetici, /etc/passwd ve /etc/shadow dosyalarını korumak için sadece dosya izinlerine güveniyor. 644 ve 600 izinleri gerekli olsa da, bunlar bir tehlikeye düşmüş hizmet veya yanlış yapılandırılmış betik tarafından bu dosyalara yazma girişimini engellemez. İşte burada auditd devreye girer — sadece loglama için değil, systemd ile birleştirildiğinde aktif önleme için de kullanılır.

auditd Kuralları Sadece Logları İzlemekten Daha İyi Neden

Denetim alt sistemi sadece olayları kaydetmez — eylem tetikleyebilir. auditctl -w komutuyla /etc/passwd ve /etc/shadow dosyalarına izleme ayarladığınızda, bu dosyalar yazma açıldığında her seferinde bir denetim kaydı oluşturulur. Ancak, sen uyuyorsan veya SIEM'in gecikmesi varsa, sadece log tutmak yeterli değildir. Gerçek güç, bu denetim olayını, kötü niyetli süreci anında sonlandırabilecek veya anında uyarı verebilecek bir systemd servisine bağlamada ortaya çıkar.

Watch'ı augenrules ile Kurma

Doğrudan auditctl komutları çalıştırmak yerine (yeniden başlatmalar sonrası kalmaz), kuralları kalıcı hale getirmek için augenrules kullanıyorum. /etc/audit/rules.d/ dizinine bir dosya oluşturun:

# /etc/audit/rules.d/99-protect-passwd.rules
-w /etc/passwd -p wa -k passwd_write
-w /etc/shadow -p wa -k shadow_write

-p wa bayrağı, yazma ve öznitelik değişikliklerini izlemek için kullanılır. -k etiketi, bu olayları daha sonra filtrelemek için kullanılır. Kaydettikten sonra kuralları yeniden yükleyin:

augenrules --load
systemctl restart auditd

Aktif olup olmadığını şu komutla doğrulayın:

auditctl -l | grep -E "passwd|shadow"

Her iki izlemenin de listelendiğini görmelisiniz.

Bağlama Olaylarını systemd ile Gerçek Zamanlı Yanıt İçin Bağlama

Şimdi entegrasyon kısmı geliyor. auditd, auditd kurallarının systemd eylemi üzerinden bir eşleşen olay gördüğünde bir betik çalıştırabilir. Ancak auditd, sistemd birimlerini doğrudan çağırmayacağı için, audit günlüğünü izleyen ve bir systemd hizmetini tetikleyen küçük bir daemon betiği kullanıyorum.

İlk olarak, bir yanıt betiği oluşturun:

# /usr/local/bin/block-passwd-write.sh
#!/bin/bash
# auditd, /etc/passwd veya /etc/shadow dosyasına yazma yaptığında tetiklenir
PID=$(ausearch -k passwd_write -k shadow_write -i --raw | aureport -f -i | tail -n 1 | awk '{print $2}')
if [ -n "$PID" ]; then
    logger -t audit-response "PID $PID, /etc/passwd veya /etc/shadow dosyasına yazma girişimi nedeniyle engellendi"
    kill -9 $PID
    systemctl start alert-passwd-breach.service  # isteğe bağlı: uyarıyı tetikle
fi

Yürütülebilir yapın:

chmod +x /usr/local/bin/block-passwd-write.sh

Ardından, bu betiği talep üzerine çalıştıracak bir systemd hizmeti oluşturun:

# /etc/systemd/system/audit-passwd-response.service
[Unit]
Description=Yetkisiz /etc/passwd veya /etc/shadow yazma işlemine yanıt
After=auditd.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/block-passwd-write.sh

[Install]
WantedBy=multi-user.target

Şimdi, auditd’yi bu hizmeti tetikleyecek şekilde yapılandırın. /etc/audit/auditd.conf dosyasını düzenleyin ve şunu ayarlayın:

admin_space_left_action = halt
# Ideal değil, ancak anında yanıt isteniyor — daha iyi bir yaklaşım aşağıda

Aslında, daha temiz bir yol, auditd kurallarındaki exec eylemini kullanmaktır — ancak bu sınırlıdır. Bunun yerine, ayrı bir günlük izleyiciye güveniyorum. Bu yüzden, audit günlüğünü izleyen ve yanıtı tetikleyen ikinci bir hizmet oluşturun:

# /etc/systemd/system/audit-watchdog.service
[Unit]
Description=Audit günlüğünde kritik dosya yazmalarını izleyin ve yanıtı tetikleyin
After=auditd.service

[Service]
Type=simple
ExecStart=/usr/local/bin/audit-log-watcher.sh
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Aşağıdaki gibi bir izleyici betiğiyle birlikte:

# /usr/local/bin/audit-log-watcher.sh
#!/bin/bash
while true; do
    if ausearch -k passwd_write -k shadow_write -i --raw | grep -q .; then
        /usr/local/bin/block-passwd-write.sh
        # Tekrar tetiklenmemesi için tamponu temizle
        ausearch -k passwd_write -k shadow_write -i --raw > /dev/null
    fi
    sleep 2

done

Her iki hizmeti etkinleştirin ve başlatın:

systemctl daemon-reload
systemctl enable audit-watchdog.service
systemctl start audit-watchdog.service

Kurulumu Güvenli Bir Şekilde Test Etme

Üretim kimlik doğrulama dosyasında doğrudan test yapmayın. Bunun yerine bir kopyasını oluşturun:

cp /etc/passwd /tmp/test-passwd
chmod 644 /tmp/test-passwd
# Geçici olarak test dosyasını izle
 auditctl -w /tmp/test-passwd -p wa -k test-passwd

Ardından ona yazmaya çalışın:

echo "test:x:1001:1001::/home/test:/bin/sh" >> /tmp/test-passwd

Gözlemcinin bunu yakalayıp yakalamadığını kontrol edin:

journalctl -u audit-watchdog.service -f

Betik tetiklenmeli, PID kaydedilmeli ve süreç sonlandırılmalıdır.

Bu, Sadece inotify Kullanmaktan Daha İyi Neden

Daha önce dosya izleme için inotifywait kullanmıştım, ancak sınırlamaları var: ağır yük altında olayları kaçırabilir, çok sayıda dosya için iyi ölçeklenmez ve auditd'nin çekirdek seviyesindeki denetim bütünlüğüne sahip değildir. auditd çekirdek uzayında çalıştığı için, süreç tespiti kaçınmaya çalışsa bile sistem çağrılarını yakalar. systemd ile birleştirildiğinde, güvenilir ve müdahaleye karşı dayanıklı bir yanıt katmanı sağlar.

Not: Yanlış Pozitiflerden Kaçının

pwck, usermod veya yedekleme betikleri gibi meşru araçlar bu uyarıyı tetikleyebilir. Gürültüyü azaltmak için:

  • İzleyici betiğinizde bilinen PID'leri veya comm değerlerini beyaz listeye alın
  • Kritik ve rutin izlemeleri ayırmak için -k etiketlerini kullanın
  • Yedekleme ve kullanıcı yönetimi iş akışlarınızı önce test edin

İpucu: Uyarı ile birleştirin

Sadece süreci öldürmek yerine, yanıt hizmeti curl üzerinden Slack veya Telegram uyarısı göndermek veya bir PagerDuty eventi tetiklemek için yapılandırılabilir. Systemd üzerinden uyarı vermeyi önceki bir yazımda ele aldım — responsive hizmetlerin nasıl yapılandırılacağını öğrenmek için [systemd Slice ile Bellek ve IO Sınırlaması](https://furkanikkan.com/urun/systemd-slice-ile-bellek-ve-io-sinirlamasi-kaynak-izolasyonu-rehberi-88) rehberimi inceleyin.

Bu yaklaşım, pasif loglamayı aktif savunmaya dönüştürür. Bir kök kök kit'in (rootkit) etkili bir şekilde durdurulmasını garantilemez, ancak kimlik dosyalarını değiştirmeye çalışan nadir kullanım hataları, yanlış yapılandırmalar veya tehlikeye giren hizmetleri yakalar ve durdurur — ve bu kurulum süresi değeri vardır.

Kapak görseli: slee144 · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/197519814@N08/52656069487