Linux auditd Rehberi: auditctl Kuralları, ausearch ve Güvenlik İzleme

Linux Audit sistemi, bir Linux sunucusunda güvenlik açısından önemli olayları çekirdek seviyesinde kaydetmek için kullanılan denetim altyapısıdır. Kullanıcı oturumlarını, dosya değişikliklerini, sistem çağrılarını, yetki yükseltmelerini ve politika ihlallerini kurallara göre izler. Kullanıcı alanındaki auditd servisi bu olayları disk günlüğüne yazar; auditctl kuralları ve çekirdek durumunu yönetir; ausearch olay arar; aureport ise özet rapor üretir.

Auditd bir EDR, antivirüs veya engelleme motoru değildir. Varsayılan olarak saldırıyı durdurmaz; olayın kim, ne zaman, hangi programla ve hangi sonuçla gerçekleştiğini kaydederek tehdit avcılığı, olay müdahalesi ve uyumluluk için kanıt üretir. Yanlış kurgulanırsa ya hiç gerekli olayı toplamaz ya da çok fazla kayıt üreterek sistemi ve analistleri boğar.

Bu rehber Debian/Ubuntu ve RHEL türevlerinde kurulumdan kalıcı kural yazımına; auid yorumlamadan performans ayarına; ausearch/aureport sorgularından merkezi SIEM aktarımına kadar üretim odaklı bir auditd uygulamasını anlatır.

Linux Audit mimarisi nasıl çalışır?

Linux Audit iki ana katmandan oluşur. Çekirdek tarafı, kurallarla eşleşen sistem çağrıları ve güvenlik olayları için denetim kaydı üretir. Kullanıcı alanındaki auditd bu kayıtları Netlink üzerinden alır, genellikle /var/log/audit/audit.log dosyasına yazar ve etkin eklentilere dağıtabilir.

Bir insanın tek eylemi audit.log içinde birden fazla kayda bölünebilir. Aynı zaman damgası ve seri numarasını taşıyan SYSCALL, EXECVE, CWD, PATH ve PROCTITLE kayıtları birlikte tek olayı anlatır. Bu nedenle ham dosyada bir satır görüp karar vermek yerine ausearch veya libauparse tabanlı araçlarla olay grubu olarak ayrıştırmak gerekir.

Bileşen	Görevi	Yaygı kullanım
Çekirdek Audit altyapısı	Sistem çağrılarını ve denetim olaylarını kurallara göre üretir	execve, dosya erişimi, kimlik ve yetki olayları
auditd	Olayları disk günlüğüne yazar ve eklentilere dağıtır	/var/log/audit/audit.log
auditctl	Çekirdek durumunu ve çalışan kuralları yönetir	auditctl -s, auditctl -l
augenrules	rules.d dosyalarını sıralayıp tek kalıcı kurala derler	augenrules --check, --load
ausearch	Ham denetim olaylarında anahtar, kimlik, zaman ve olay türü arar	ausearch -k identity -ts today -i
aureport	Kullanıcı, kimlik doğrulama, çalıştırılabilir dosya ve anomali raporu üretir	aureport --summary
audisp eklentileri	Olayları gerçek zamanlı tüketicilere iletir	merkezi log/SIEM aktarımı

Auditd ile syslog/journald arasındaki fark

Syslog ve systemd-journald çoğunlukla uygulamanın veya servisin göndermeyi seçtiği mesajları toplar. Linux Audit ise çekirdek ve güvenlik alt sistemi tarafından, önceden tanımlanan kurallara göre olay üretebilir. Bir saldırgan uygulama logunu kapatsa bile çekirdek seviyesindeki execve veya dosya değişikliği kuralı ayrı kanıt oluşturabilir.

Bu ayrım mutlak koruma sağlamaz. Root yetkisini tamamen ele geçiren saldırgan günlükleri silmeye, auditd'yi bozmayı veya çekirdek durumunu değiştirmeyi deneyebilir. Kalıcı kurallar, immutable mod, ayrı log bölümü ve uzak merkezi toplama savunma derinliği sağlar; güvenilir önyükleme, dosya bütünlüğü ve EDR gibi kontrollerin yerini tutmaz.

Kurulum: Debian ve Ubuntu

Debian/Ubuntu ailesinde paket adı genellikle auditd ve eklentiler için audispd-plugins olur:

CODE TERMINAL

sudo apt update
sudo apt install auditd audispd-plugins
sudo systemctl enable auditd
sudo systemctl status auditd --no-pager

Bazı dağıtımlarda auditd servisinin durdurma/yeniden başlatma davranışı denetim zincirini korumak için systemd tarafından kısıtlanmış olabilir. Yapılandırma değişikliğinde doğrudan systemctl restart auditd komutuna güvenmek yerine dağıtım belgesindeki service auditd reload/restart veya auditctl sinyal akışı kullanılmalıdır.

Kurulum: RHEL, Rocky Linux ve AlmaLinux

RHEL uyumlu dağıtımlarda paket audit adıyla sunulur:

CODE TERMINAL

sudo dnf install audit
sudo systemctl enable auditd
sudo service auditd start
sudo auditctl -s

Kurulumdan sonra yalnız servisin active olması yeterli değildir. Çekirdek Audit durumunu, yüklü kuralları ve kayıp olay sayacını kontrol edin:

CODE TERMINAL

sudo auditctl -s
sudo auditctl -l
sudo ausearch -m DAEMON_START -ts boot -i
sudo tail -n 20 /var/log/audit/audit.log

auditctl -s çıktısında enabled, failure, pid, rate_limit, backlog_limit, lost ve backlog alanları görülür. lost sıfırdan büyükse denetim zinciri eksik kanıt üretiyor olabilir; sadece sayacı sıfırlamak yerine yük, kural hacmi, backlog ve disk/eklenti gecikmesi araştırılmalıdır.

Boot başlamadan önce olayları yakalamak: audit=1

Auditd kullanıcı alanı servisi başlamadan önce oluşan süreçlerin de denetlenebilir olarak işaretlenmesi için çekirdek komut satırına audit=1 eklenebilir. Upstream auditd belgesi, bu parametre olmadan erken başlayan bazı süreçlerin sonradan tam olarak denetlenemeyeceğini belirtir.

GRUB tabanlı bir sistemde değişiklik dağıtıma göre farklı dosyaya yazılır. Üretimde körlemesine dosya düzenlemek yerine mevcut önyükleme yöneticisi ve geri dönüş prosedürü doğrulanmalıdır. Değişiklik yeniden başlatma gerektirir ve şu komutla kontrol edilebilir:

CODE TERMINAL

cat /proc/cmdline

Temel yapılandırma dosyaları

/etc/audit/auditd.conf: Log dosyası, format, yazma/flush davranışı, döndürme, disk doluluk eylemi ve eklenti ayarları.
/etc/audit/rules.d/*.rules: Kalıcı, parçalı denetim kuralları. Dosya adı sırası kural sırasını belirler.
/etc/audit/audit.rules: Başlangıçta çekirdeğe yüklenen birleşik kural dosyası. Augenrules bunu rules.d içeriğinden üretebilir.
/var/log/audit/audit.log: Varsayılan ham olay günlüğü.
/etc/audit/plugins.d/: Gerçek zamanlı olay tüketen eklenti yapılandırmaları.
/run/audit/auditd.state: Desteklenen yeni sürümlerde auditd iç durum ve kuyruk istatistikleri.

Kural dosyalarının sahipliği ve izinleri korunmalıdır. Upstream auditctl belgeleri, -R ile okunan dosyanın root tarafından sahiplenilmesini ve başkalarınca yazılamamasını bekler. Otomasyon, geçici dünya-yazılabilir dosyadan kural yüklememelidir.

auditd.conf güvenli ve dengeli nasıl ayarlanır?

Varsayılanlar çoğu genel ortam için başlangıç noktasıdır; sayılar sunucu rolüne, olay hacmine ve saklama gereksinimine göre ölçülmelidir. Örnek bir profil:

CODE TERMINAL

log_file = /var/log/audit/audit.log
write_logs = yes
log_format = ENRICHED
flush = incremental_async
freq = 50
max_log_file = 100
num_logs = 10
max_log_file_action = rotate
space_left_action = syslog
admin_space_left_action = suspend
disk_full_action = suspend
disk_error_action = syslog

Bu değerler evrensel öneri değildir. Örneğin sıkı uyumluluk politikası log kaybında single veya halt gibi fail-closed davranış isteyebilir; ancak bu ayar gerçek bir disk doluluğunda hizmet kesintisine neden olur. Risk sahibi, iş sürekliliği ve kanıt bütünlüğü arasındaki kararı belgelemelidir.

ENRICHED format UID, GID, syscall ve mimari gibi alanları yazma sırasında yorumlayarak merkezi analizde kolaylık sağlar; RAW format ise çekirdek kaydını olduğu gibi korur. Dağıtık filoda yorumlanan isimlerin zamanla değişmesi ve olay hacmi dikkate alınmalıdır.

Audit kurallarının üç türü

Linux Audit kuralları genel olarak kontrol, dosya sistemi ve sistem çağrısı kurallarına ayrılır.

Kural türü	Amaç	Örnek
Kontrol	Kural listesini, backlog'u, failure modunu ve immutable durumunu ayarlar	-D, -b 8192, -f 1, -e 2
Dosya/dizin	Belirli yol altındaki okuma, yazma, çalıştırma ve nitelik değişikliğini izler	-F path=/etc/sudoers -F perm=wa
Syscall	Mimari, sistem çağrısı, kullanıcı ve başarı durumuna göre olay seçer	-S execve -F euid=0

Kurallar çekirdekte ilk eşleşme mantığına tabi olabilir. Üstteki geniş bir never kuralı, alttaki özel always kuralını susturabilir. Bu nedenle dosya adları ve kural sırası tasarımın parçasıdır.

Kalıcı kural dosyası ve augenrules

Dağıtıma özgü tek /etc/audit/audit.rules dosyasını doğrudan büyütmek yerine, kuralları amaca göre /etc/audit/rules.d/ altında ayırmak daha yönetilebilirdir:

CODE TERMINAL

/etc/audit/rules.d/10-base-config.rules
/etc/audit/rules.d/30-identity.rules
/etc/audit/rules.d/31-privileged.rules
/etc/audit/rules.d/40-network.rules
/etc/audit/rules.d/70-local.rules
/etc/audit/rules.d/99-finalize.rules

Upstream örnekler 10'u temel çekirdek ayarları, 30'u ana kurallar, 70'i yerel kurallar ve 90/99'u sonlandırma için kullanır. Dosya adları doğal sırada birleştirilir. Değişikliği yüklemeden önce:

CODE TERMINAL

sudo augenrules --check
sudo augenrules --load
sudo auditctl -l

Dağıtım/sürüm augenrules yerine yeni audit-rules.service kullanıyorsa upstream sürüm notu ve paket birimi izlenmelidir. Hangi mekanizmanın etkin olduğu varsayılmamalıdır.

Temel kontrol kuralları

Upstream 10-base-config örneğinde mevcut kurallar temizlenir, backlog büyütülür, patlama anında bekleme süresi belirlenir ve failure modu syslog/printk davranışına alınır:

CODE TERMINAL

-D
-b 8192
--backlog_wait_time 60000
-f 1

-D mevcut bütün kuralları siler; birleşik dosyanın başında anlamlıdır ama etkileşimli terminalde gelişigüzel uygulanmamalıdır. Backlog değeri daha büyük oldukça her zaman daha iyi değildir. Olay hacmi, bellek ve auditd'nin olay boşaltma hızı izlenerek ayarlanmalıdır.

Dosya ve dizin değişikliklerini izleme

Eski -w /yol -p wa biçimi yaygın olsa da upstream audit.rules belgesi daha iyi performans için syscall tabanlı path/dir kurallarını önerir. Örneğin kimlik ve sudo yapılandırması:

CODE TERMINAL

-a always,exit -F arch=b64 -F path=/etc/passwd -F perm=wa -k identity
-a always,exit -F arch=b64 -F path=/etc/group -F perm=wa -k identity
-a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa -k identity
-a always,exit -F arch=b64 -F path=/etc/gshadow -F perm=wa -k identity
-a always,exit -F arch=b64 -F path=/etc/sudoers -F perm=wa -k privileged_scope
-a always,exit -F arch=b64 -F dir=/etc/sudoers.d/ -F perm=wa -k privileged_scope

perm alanı r=read, w=write, x=execute ve a=attribute değişikliğini ifade eder. Her hassas dosyada r toplamak çok yüksek hacim oluşturabilir. Parola veritabanı veya özel anahtar gibi gerçekten kritik yollarda okuma ihtiyacı risk analiziyle seçilmelidir.

Bir dir kuralı dizin ağacını izler; ancak farklı mount point altına geçmeyebilir. Bind mount, container ve ayrı dosya sistemi kullanan ortamlarda kapsam test edilmelidir.

Yetki yükseltme ve root komutlarını izleme

auid, kullanıcının oturum açarken aldığı login UID'dir ve sudo ile etkin UID değişse bile normalde korunur. uid/euid ise olay anındaki kimliği anlatır. Bu ayrım, “hangi insan sudo ile root komutu çalıştırdı?” sorusunun temelidir.

CODE TERMINAL

-a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k privileged_exec

Bu kural, insan kullanıcı aralığının 1000'den başladığını varsayar. Gerçek değer /etc/login.defs içindeki UID_MIN ile doğrulanmalıdır. Servis hesapları ve merkezi kimlik sistemleri farklı aralık kullanabilir.

auid!=unset filtresi oturum kimliği atanmamış kernel/daemon olaylarını ayırır. Bazı eski örneklerde unset değeri sayısal 4294967295 olarak yazılır; isimsel unset daha okunabilir ve mimari ayrıntıyı gizler.

32 bit ve 64 bit syscall kuralı tuzağı

64 bit bir sistem 32 bit uyumluluk ABI'sini destekliyorsa syscall numaraları mimariye göre farklı olabilir. arch alanı -S alanından önce belirtilmeli ve kapsama göre b64 ile b32 kuralları ayrı yazılmalıdır:

CODE TERMINAL

-a always,exit -F arch=b64 -S sethostname,setdomainname -k system_locale
-a always,exit -F arch=b32 -S sethostname,setdomainname -k system_locale

Sistem gerçekte b32 ABI desteklemiyorsa gereksiz kural eklenmemelidir. ausyscall --dump ve auditctl -l ile çözümleme doğrulanabilir. Arch filtresi olmadan syscall kuralı yazmak hem yanlış eşleşme hem performans sorunu yaratabilir.

Kritik örnek kurallar

Aşağıdaki örnekler bir kuruma doğrudan uygulanacak hazır uyumluluk paketi değildir. Dağıtım, mimari, UID aralığı, iş yükü ve olay hacmiyle test edilmelidir.

Sistem zamanı ve saat dilimi değişikliği:

CODE TERMINAL

-a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change
-a always,exit -F arch=b32 -S adjtimex,settimeofday,clock_settime -k time_change
-a always,exit -F arch=b64 -F path=/etc/localtime -F perm=wa -k time_change

Kernel modülü yükleme ve silme:

CODE TERMINAL

-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -F auid>=1000 -F auid!=unset -k kernel_modules

Ağ kimliği ve temel yapılandırma dosyaları:

CODE TERMINAL

-a always,exit -F arch=b64 -F path=/etc/hosts -F perm=wa -k network_config
-a always,exit -F arch=b64 -F path=/etc/hostname -F perm=wa -k network_config
-a always,exit -F arch=b64 -F dir=/etc/NetworkManager/ -F perm=wa -k network_config

SSH sunucu yapılandırması ve anahtarlar:

CODE TERMINAL

-a always,exit -F arch=b64 -F path=/etc/ssh/sshd_config -F perm=wa -k ssh_config
-a always,exit -F arch=b64 -F dir=/etc/ssh/sshd_config.d/ -F perm=wa -k ssh_config
-a always,exit -F arch=b64 -F dir=/root/.ssh/ -F perm=wa -k root_ssh_keys

Kullanıcıların bütün home dizinlerindeki .ssh dosyalarını tek geniş recursive kuralla izlemek olay hacmi ve mount davranışı nedeniyle önce test edilmelidir. Kimlik yönetimiyle kritik hesapların yolları üretilebilir.

Başarısız erişimleri izlemek

Belirli bir dizin altında EACCES ve EPERM ile sonuçlanan erişimler, keşif veya yetki sorunlarını gösterebilir. Ancak bütün dosya sistemini kapsayan kurallar oldukça gürültülü olabilir:

CODE TERMINAL

-a always,exit -F arch=b64 -S openat,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k denied_access
-a always,exit -F arch=b64 -S openat,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k denied_access

Gerçek sistem çağrıları kernel ve uygulamaya göre farklılaşabilir; open, openat ve openat2 gibi yollar gözlemlenmelidir. Önce DetectionOnly benzeri bir pilot yaklaşımla olay hacmi ölçülmeli, sonra dizin/UID/servis filtresiyle daraltılmalıdır.

io_uring olaylarını unutmayın

Modern Linux uygulamaları bazı I/O işlemlerini io_uring üzerinden gerçekleştirebilir. Auditctl yeni sürümlerde io_uring filtre listesini destekler. Yalnız klasik exit/syscall kuralına güvenilen bir politika, kullandığı kernel ve audit userspace sürümüne bağlı olarak beklenmeyen görünürlük boşluğu bırakabilir.

Dağıtımın desteklediği filtreler auditctl -h, paket man sayfası ve laboratuvar testiyle doğrulanmalıdır. Eski sürümlere yeni sözdizimi zorla uygulanmamalıdır.

Kurallara anlamlı key vermek

-k veya -F key= alanı, olayı teknik syscall numarası yerine iş amacıyla aramayı sağlar. identity, privileged_exec, ssh_config ve kernel_modules gibi tutarlı anahtarlar SIEM korelasyonunu kolaylaştırır.

Anahtar adları kısa, ASCII ve kararlı olsun.
Ortam/hostname bilgisini key'e gömmeyin; bu alanlar olay zarfında ayrı taşınmalı.
Bir anahtar tek bir güvenlik amacını temsil etsin.
Kural değiştiğinde key'i gereksiz yere değiştirmeyin; tarihsel sorgular bozulur.
Her key için sahip, veri kaynağı, beklenen hacim ve alarm kullanımı belgelensin.

ausearch ile olay arama

Ausearch'e verilen farklı filtreler genellikle AND mantığıyla birleşir. -i sayısal UID, syscall ve adresleri okunabilir biçime yorumlar:

CODE TERMINAL

sudo ausearch -k identity -ts today -i
sudo ausearch -k privileged_exec -ts recent -i
sudo ausearch -m USER_AUTH,USER_LOGIN -ts today -i
sudo ausearch -x /usr/bin/sudo -ts this-week -i
sudo ausearch -ua 1001 -ts 09/01/2026 -te now -i
sudo ausearch -sv no -ts today -i

-ua etkin kullanıcı kimliğiyle, -ul login UID/auid ile aramayı ifade edebilir; kullandığınız sürümün man sayfasından alanı doğrulayın. Olayı insan kullanıcıya bağlamak için auid, son yetkiyi anlamak için uid/euid birlikte incelenmelidir.

Bir olayın seri numarası biliniyorsa -a ile aynı olaya ait bütün kayıtlar çekilebilir. Ham olay SIEM'e aktarılırken timestamp+serial bileşimi korelasyon kimliği olarak korunmalıdır.

aureport ile hızlı durum özeti

Aureport, ham olayları operasyonel özete dönüştürür:

CODE TERMINAL

sudo aureport --summary
sudo aureport --auth --success --interpret
sudo aureport --login --failed --interpret
sudo aureport --executable --summary --interpret
sudo aureport --anomaly --summary --interpret
sudo aureport --file --failed --interpret

Rapor, olay müdahalesinin son kararı değildir. Örneğin yüksek başarısız oturum sayısı bir saldırı kadar hatalı otomasyondan da kaynaklanabilir. Özet satırları ausearch ile ham olaylara geri bağlanmalı ve kaynak IP, auid, executable, session ve zaman bağlamı birlikte incelenmelidir.

Log bütünlüğü ve merkezi SIEM aktarımı

Yerel audit.log, cihaz tamamen ele geçirilirse değiştirilebilir veya silinebilir. Olayları düşük gecikmeyle ayrı bir güvenlik alanına aktarmak kanıt dayanıklılığını artırır. Audit userspace, /etc/audit/plugins.d/ altındaki eklentilerle gerçek zamanlı tüketici ve uzak aktarım destekler.

Güvenli aktarım tasarımında:

Taşıma şifrelenmeli ve alıcı kimliği doğrulanmalıdır.
Ağ kesintisinde yerel kuyruk/yeniden deneme ve disk davranışı tanımlanmalıdır.
Eklenti yavaşlığı auditd ana kuyruğunu boğmamalıdır.
SIEM ayrıştırıcısı bir olayın çok kayıtlı yapısını korumalıdır.
Hostname yerine değişmez varlık kimliği ve güvenilir zaman senkronizasyonu kullanılmalıdır.
Kuyruk doluluğu, eklenti yeniden başlaması ve iletim hatası ayrı alarm olmalıdır.

Auditd 4.x ile gelen TLS ve periyodik durum raporu gibi yetenekler eski 3.x dağıtımlarında bulunmayabilir. Yapılandırma anahtarları kurulu auditd --version ve yerel man sayfasıyla doğrulanmalıdır.

Performans ve kayıp olay sorunu

En pahalı politika, geniş kapsamda her syscall veya her dosya okumasını toplamaktır. Linux Audit projesi de örnek kuralların tamamını aynı anda kullanmayı önermez; bunlar ihtiyaca göre seçilecek politika parçalarıdır.

Önce amaç: Her kuralın yanıtladığı güvenlik sorusunu yazın.
Dar filtre: arch, path/dir, syscall, auid, euid, exit ve key alanlarıyla kapsamı sınırlayın.
Pilot: Temsilî sunucuda olay/saniye, log MB/gün ve sorgu faydasını ölçün.
Kuyruk: auditctl -s içindeki lost/backlog ve yeni sürümlerde /run/audit/auditd.state değerlerini izleyin.
Disk: Ayrı bölüm, döndürme, saklama ve merkezi aktarım kapasitesini hesaplayın.
İyileştirme: Alarm veya avcılıkta hiç kullanılmayan yüksek hacimli kuralları kaldırın ya da daraltın.

Auditd 4.0.5 ve sonrasında auditctl --signal state komutu iç durumu /run/audit/auditd.state dosyasına yazdırabilir; auditd.conf içindeki report_interval ile periyodik rapor desteklenebilir. Bu özellik sürüm koşulludur.

Kurallar neden olay üretmiyor?

En yaygı nedenlerden biri, üst sırada bulunan geniş -a never,task veya başka bir never kuralıdır. Çekirdek kural motorunda sıra önemli olduğu için sonraki always kuralına ulaşılmayabilir.

Sorun giderme listesi:

CODE TERMINAL

sudo auditctl -s
sudo auditctl -l
sudo augenrules --check
sudo ausearch -m CONFIG_CHANGE -ts recent -i
sudo ausearch -m DAEMON_ABORT,DAEMON_END,DAEMON_START -ts boot -i

Kural gerçekten çekirdeğe yüklenmiş mi?
Yanlış arch veya syscall adı kullanılmış mı?
Path dosya oluşmadan önce mi yükleniyor veya farklı mount altında mı?
Test edilen işlem openat2/io_uring gibi başka yol mu kullanıyor?
auid filtresi servis hesabını veya unset oturumunu bilerek dışlıyor mu?
Immutable mod nedeniyle yeni kural yüklenemiyor mu?
Olay üretiliyor fakat eklenti/SIEM ayrıştırmasında mı kayboluyor?

Immutable mod: -e 2

Kural dosyasının sonunda -e 2 kullanılırsa Audit yapılandırması kilitlenir ve yeniden başlatmaya kadar kural değişikliği reddedilir. Bu, root saldırganın auditctl ile kuralları kapatmasını zorlaştırır; aynı zamanda hatalı kuralı uzaktan düzeltmeyi de zorlaştırır.

CODE TERMINAL

# /etc/audit/rules.d/99-finalize.rules
-e 2

Immutable mod yalnız laboratuvarda ve kontrollü yeniden başlatma/console geri dönüşü test edildikten sonra uygulanmalıdır. Kural seti önce -e 1 ile gözlemlenmeli; performans, disk ve olay doğruluğu kanıtlandıktan sonra kilitlenmelidir.

Container ve Kubernetes ortamlarında auditd

Auditd host çekirdeğiyle çalıştığı için container içinde ayrı bir daemon başlatmak genellikle doğru mimari değildir. Host audit sistemi container süreçlerinin syscall olaylarını görebilir; ancak container kimliği, namespace, cgroup ve pod meta verisini SIEM tarafında zenginleştirmek gerekir.

Node imajında auditd servisinin desteklendiğini doğrulayın.
Kubernetes audit logu ile Linux host audit logunu ayrı veri kaynakları olarak tutun.
Container runtime ve cgroup alanlarını varlık envanteriyle eşleştirin.
Ephemeral pod adları yerine workload UID, image digest ve node kimliğini koruyun.
Tüm container execve olaylarını toplamanın hacmini ölçmeden filo geneline yaymayın.
Privileged container, hostPath ve namespace paylaşımını ayrı alarm bağlamına ekleyin.

Kubernetes API denetimi “kim deployment oluşturdu?” sorusunu, Linux Audit “node'da hangi süreç hangi dosya/syscall eylemini yaptı?” sorusunu yanıtlar. İkisi birlikte daha güçlü olay zaman çizelgesi sağlar.

Gizlilik ve veri minimizasyonu

EXECVE ve PROCTITLE kayıtları komut satırı argümanlarını içerebilir. Kullanıcı veya otomasyon parolayı, tokenı ya da kişisel veriyi komut satırına yazıyorsa audit log bu sırrı da kaydedebilir. Bu nedenle:

Sırları komut satırı argümanı olarak geçirmeyin; dosya tanımlayıcı, secret store veya standart girdi gibi uygun mekanizma kullanın.
Audit log ve SIEM indekslerine en az ayrıcalıklı erişim uygulayın.
Saklama süresini uyumluluk ve olay müdahale ihtiyacına göre sınırlayın.
Test verisinde gerçek token veya kişisel veri kullanmayın.
Dışa aktarılan loglarda bütünlük, şifreleme ve erişim kaydını zorunlu tutun.

Güvenlik görünürlüğü, sınırsız veri toplama yetkisi değildir. Her kuralın veri alanı, saklama gerekçesi ve erişim sahibi belirlenmelidir.

Uyarı kuralına dönüştürülecek sinyaller

Normal kullanıcı auid'siyle root euid altında beklenmeyen executable
/etc/sudoers, /etc/passwd, /etc/shadow veya sshd_config değişikliği
Yeni kernel modülü yüklenmesi veya modül silinmesi
Audit kuralı değişikliği, auditd durması veya lost sayacı artışı
Kısa sürede aynı auid'den çok sayıda EPERM/EACCES olayı
Nadir kullanılan ağ/yönetim aracının root tarafından çalıştırılması
Sistem saati veya saat diliminin değiştirilmesi
Merkezi audit aktarım eklentisinin durması ya da kuyruk taşması

Alarm yalnız key değerine dayanmamalıdır. Auid, uid/euid, executable, command line, cwd, path, success/exit, terminal, session, container ve varlık rolü bir arada kullanılmalıdır. Bakım pencereleri ve onaylı otomasyon kimlikleri bastırma değil, bağlam zenginleştirmesi olarak ele alınmalıdır.

Üretime geçiş kontrol listesi

Toplanacak güvenlik sorularını ve uyumluluk gereksinimini yazılı hale getirin.
Sunucu rollerine göre ayrı kural profilleri oluşturun; her sunucuya aynı dev kural setini vermeyin.
UID_MIN, mimari, mount, container ve dağıtım farklarını envanterleyin.
Kuralları canlıya almadan önce augenrules --check ve laboratuvar olay testlerini geçirin.
Bir hafta pilotta EPS, MB/gün, CPU, I/O, lost ve backlog ölçümlerini toplayın.
Her key için en az bir ausearch sorgusu ve bir SIEM kullanımı tanımlayın.
Disk döndürme, space_left, admin_space_left ve disk_full davranışını masa başı tatbikatıyla test edin.
Merkezi aktarım kesintisinde kuyruk ve yeniden gönderim davranışını doğrulayın.
Immutable modu ancak geri dönüş ve yeniden başlatma prosedürü kanıtlandıktan sonra açın.
Kural değişikliklerini kod inceleme, test ve sürüm kontrolünden geçirin.
Aylık olarak yüksek hacimli fakat kullanılmayan kuralları ve sessiz kalan kritik kuralları inceleyin.
Olay müdahale ekibine ausearch/aureport sorgu kartı ve saat senkronizasyonu bağlamı sağlayın.

Sık sorulan sorular

Auditd saldırıyı engeller mi?

Hayır. Ana işlevi politika eşleşmelerini kaydetmek ve kanıt üretmektir. SELinux, AppArmor, seccomp, dosya izinleri, EDR ve ağ kontrolleriyle birlikte kullanılır.

auditctl ile eklenen kurallar kalıcı mı?

Etkileşimli auditctl kuralları genel olarak yeniden başlatmada kaybolur. Kalıcı politika /etc/audit/rules.d/*.rules altında tutulup augenrules veya dağıtımın kural servisiyle yüklenmelidir.

-w kuralları kullanılabilir mi?

Geriye uyumluluk için kullanılabilir; fakat upstream belge, performans için arch ve path/dir alanlı syscall kurallarını tercih eder.

lost=0 neyi gösterir?

Çekirdek tarafında raporlanan kayıp olay olmadığını gösterir. Eklenti, ağ, SIEM ayrıştırma veya saklama katmanında hiç kayıp olmadığını tek başına kanıtlamaz.

-e 2 neden dikkatli kullanılmalı?

Yapılandırmayı reboot'a kadar kilitler. Saldırgana karşı direnç sağlarken hatalı kuralı uzaktan düzeltmeyi de engelleyebilir.

Sonuç

Linux auditd, doğru kural tasarımıyla “sunucuda ne oldu?” sorusuna çekirdek destekli ve ayrıntılı yanıt verir. Başarılı kurulumun anahtarı her şeyi kaydetmek değil; kimlik dosyası, root komutu, kritik yapılandırma, kernel modülü ve Audit sisteminin kendi bütünlüğü gibi yüksek değerli olayları dar ve test edilmiş kurallarla toplamaktır.

Kalıcı rules.d dosyaları, anlamlı key adları, auid/euid ayrımı, mimari filtresi, ausearch/aureport sorguları, lost/backlog izlemesi ve güvenli merkezi aktarım birlikte uygulanmalıdır. Immutable mod en son adımdır; önce doğruluk, hacim, disk davranışı ve geri dönüş akışı kanıtlanmalıdır.

Kaynaklar

TR Siber Ekibi Yazar · X

Kaynak bağlantısı ← Ana sayfaya dön