auditd

Bu moduldagi hozirgacha ko'rilgan boshqa barcha vositalar yo kirish huquqini beradi (sudo, PAM), yo uni bloklaydi (firewall’lar, SELinux/AppArmor, fail2ban). auditd esa ikkalasini ham qilmaydi — u kernel darajasida kuzatadi va amalga haqiqatan ruxsat berilganmi yoki yo'qmi, qat’i nazar, kim qaysi fayl yoki syscall bilan nima qilganini aniq yozib boradi. Eng kam imtiyoz ishlamay qolganda, sudo qoidasi juda keng bo'lib chiqqanda yoki hodisalarga javob berish jamoasi buzib kirilgan akkaunt aynan nimaga tekkanini bilishi kerak bo'lganda, auditd log'i ko'pincha savolga javob berish uchun yetarlicha batafsil bo'lgan yagona yozuv bo'ladi.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• Linux Audit Framework nimani yozib borishini va u oddiy syslog/journald log yozishdan qanday farq qilishini tushuntirish;
• ma’lum fayl yoki syscall’ni kuzatadigan doimiy audit qoidasini yozish;
• yozib olingan hodisalarni ausearch bilan qidirish va ularni aureport bilan umumlashtirish;
• audit qoidasining o'zi nega hech narsani to'xtatmasligini va bu SELinux/AppArmor’dan qanday farq qilishini tushuntirish;
• auditd qoidalari jimgina kuchini yo'qotishining eng keng tarqalgan usulidan qochish.

auditd syslog yozmaydigan nimani yozib boradi

Oddiy ilova log'lari — journalctl, /var/log/auth.log — ilova yozishni tanlagan narsani, o'sha ilova mualliflari qaror qilgan formatda yozadi. Linux Audit Framework bundan bir daraja pastda ishlaydi: u bevosita kernel’ning syscall jadvaliga ulanadi va tegishli ilova bu haqda umuman biror narsa log'ga yozadimi yoki yo'qmi, qat’i nazar, "aynan shu fayl shu UID tomonidan, aynan shu vaqtda, aynan shu syscall yordamida yozish uchun ochildi" kabi hodisalarni yozib bora oladi.

sudo systemctl status auditd

● auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled)
     Active: active (running)

SELinux rad etishlari ilovaning o'z log faylida emas, audit log'ida AVC (Access Vector Cache) hodisalari sifatida yozilishining sababi aynan shu. Rad etish kernel’ning xavfsizlik moduli ichida, ilova urinish haqida biror narsa yozishga imkon topmasidan oldin sodir bo'ladi. SELinux va AppArmor maqolasida ausearch -m AVC aynan shu sababli ishlatilgan edi.

Qoida yozish

Qoidalarni auditctl bilan vaqtincha yoki /etc/audit/rules.d/audit.rules da doimiy qo'shish mumkin (qayta yuklanishdan keyin ham saqlanishi kerak bo'lgan har qanday narsa uchun tavsiya etiladi):

sudo nano /etc/audit/rules.d/audit.rules

-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/sudoers -p wa -k sudoers_changes

• -w <path> — aynan shu fayl yoki katalogni kuzatish;
• -p wa — qaysi turdagi kirish yozuvni ishga tushirishi: w (yozish), a (atribut o'zgarishi, masalan chmod/chown), r (o'qish), x (bajarish);
• -k <key> — bu qoida hosil qilgan har bir hodisaga biriktiriladigan qidiriladigan yorliq. U keyingi qidiruvlarni (ausearch -k passwd_changes) xom audit chiqishini grep qilishdan ancha osonlashtiradi.

sudo augenrules --load

No rules
enabled 1
failure 1

augenrules --load /etc/audit/rules.d/ ostidagi har bir faylni ishlab turgan kernel ruleset’iga kompilyatsiya qiladi. Qoidalar faylini tahrirlashning o'zi bu qadam (yoki qayta yuklanish) uni qo'llamaguncha hech qanday ta’sir qilmaydi.

Ma’lum yo'lni kuzatishdan tashqari, qoida bevosita syscall ni ham kuzata oladi. Bu amalni u qaysi aniq faylga qaratilganidan qat’i nazar ushlaydi:

-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_commands

Bu haqiqiy, tizimga kirgan foydalanuvchi tomonidan har bir dastur bajarilishini (execve) yozib boradi (auid>=1000 tizim akkauntlarini chiqarib tashlaydi, auid!=4294967295 esa ko'pchilik tizim servislari kabi umuman login sessiyasi bo'lmagan jarayonlarni chiqarib tashlaydi). Amalda bu buyruq kuzatilayotgan faylga tekkanmi yoki yo'qmi, qat’i nazar, inson akkaunti haqiqatan ishga tushirgan har bir buyruqning tizim bo'yicha yozuvi.

Yozib olingan hodisalarni qidirish: ausearch

sudo ausearch -k sudoers_changes

type=PATH msg=audit(1753776042.118:381): item=0 name="/etc/sudoers" inode=131094 dev=fd:00 mode=0100440 ouid=0 ogid=0 rdev=00:00
type=SYSCALL msg=audit(1753776042.118:381): arch=c000003e syscall=2 success=yes exit=3 a0=... auid=1000 uid=0 gid=0 euid=0

Bu yerdagi auid=1000 maydoni uid=0 bilan yonma-yon turib, syscall’ning o'zi root imtiyozlari bilan ishlagan bo'lsa ham (uid=0, euid=0), haqiqiy voqeani aytib beradi: /etc/sudoers ga bu yozishni oxir-oqibat UID 1000 sifatida tizimga kirgan kishi ishga tushirgan, katta ehtimol bilan sudo visudo orqali.

sudo ausearch -k sudoers_changes -ts today -i

-ts today qidiruvni bugungi hodisalar bilan cheklaydi. -i (interpret) esa imkon qadar xom raqamli UID’lar va syscall raqamlarini o'qilishi oson nomlarga tarjima qiladi:

type=SYSCALL msg=audit(07/29/2026 09:41:02.118:381) : arch=x86_64 syscall=open success=yes exit=3 a0=... auid=deploy uid=root gid=root euid=root

Umumlashtirish: aureport

Alohida hodisa yozuvlaridan yuqoriroq darajadagi ko'rinish uchun aureport ma’lumotlarni jamlaydi:

sudo aureport -au --summary

Authentication Summary Report
================================
# total  success  failed
================================
142      138      4

sudo aureport -x --summary

Executable Summary Report
================================
# total  file
================================
84       /usr/bin/sudo
19       /usr/bin/su

Savol "mos keladigan har bir hodisani ko'rsat" emas, "umumiy manzara qanday" bo'lganda birinchi navbatda aureport ga murojaat qilinadi. Ikkinchisi uchun ausearch, birinchisi uchun aureport.

auditd yozib boradi, bloklamaydi

Bu auditd va SELinux/AppArmor o'rtasidagi eng muhim farq va uni aniq aytishga arziydi: /etc/shadow ga yozishni kuzatadigan audit qoidasi unga har safar yozilganda yozuv hosil qiladi, lekin yozishning o'zining oldini olish uchun hech narsa qilmaydi. Ruxsatsiz kirishni bloklash — DAC va MAC ning vazifasi (Eng kam imtiyoz (least privilege), SELinux va AppArmor). auditd’ning vazifasi esa faqat ko'rinuvchanlik — voqeadan keyin aynan nima bo'lganini va buni kim qilganini isbotlash.

Aslida doimiy bo'lmagan qoida

To'g'ridan-to'g'ri auditctl -w ... bilan qo'shilgan qoidalar darhol qo'llaniladi, lekin qayta yuklanishda yo'qoladi. Bu juda oson tuziladigan tuzoq, chunki buyruq ishlayotgandek ko'rinadi va qoida keyingi qayta ishga tushirishgacha haqiqatan faol bo'ladi:

sudo auditctl -w /etc/shadow -p wa -k shadow_test
sudo auditctl -l

-w /etc/shadow -p wa -k shadow_test

Bu hozirgi paytda muhim bo'lgan har jihatdan doimiy qoidaga o'xshab ko'rinadi. Lekin faqat /etc/audit/rules.d/ ostidagi faylga yozilgan va augenrules --load bilan yuklangan qoida qayta yuklanishdan keyin saqlanib qoladi. auditctl tezkor, vaqtinchalik sinov uchun to'g'ri vosita, /etc/audit/rules.d/ esa amalda qolishi kerak bo'lgan har qanday narsa uchun to'g'ri joy.

Amaliy vaziyat: /etc/sudoers ni kim o'zgartirgan

Muammo. Muntazam ko'rib chiqish paytida mavjud bo'lmasligi kerak bo'lgan sudoers qoidasi topildi (sudo xavfsizligi maqolasida ko'rib chiqilgan o'sha vaziyat). auditd allaqachon /etc/sudoers ni kuzatish bilan sozlangan edi, endi esa savol — uni aslida kim va qachon qo'shgan.

Audit log'idan har bir yozib olingan o'zgarishni qidirish:

sudo ausearch -k sudoers_changes -i

type=SYSCALL msg=audit(03/14/2026 11:02:17.442:2201) : ... auid=admin_jane uid=root exe=/usr/sbin/visudo

Xulosa. Syscall’ning o'zi visudo orqali uid=root sifatida ishlaganiga qaramay, auid=admin_jane tizimga kirgan va o'zgarishni ishga tushirgan akkauntni aniqlaydi. Bu sudo bilan imtiyoz oshirilgan har bir amal aks holda bir xil ko'rinadigan noma’lum "buni root qilgan" o'rniga, murojaat qilish uchun aniq shaxs va vaqt belgisini beradi.

Keng tarqalgan xatolar

• auditctl bilan qoida qo'shib, uni doimiy deb o'ylash. Yuqorida ko'rib chiqilganidek, faqat augenrules --load orqali /etc/audit/rules.d/ dan yuklangan qoidalar qayta yuklanishdan keyin saqlanib qoladi.
• Amalni shaxsgacha kuzatishga urinayotganda auid o'rniga uid bo'yicha filtrlash. uid har bir sudo/su bilan o'zgaradi, auid esa o'zgarmaydi — uni hisobdorlik uchun foydali qiladigan narsa aynan shu.
• Audit qoidasi biror narsaning oldini oladi deb o'ylash. auditd faqat yozib boradi. Yozishni bloklash DAC yoki MAC ni (fayl ruxsatlari, SELinux/AppArmor) talab qiladi — bu alohida va bir-birini to'ldiruvchi himoya vositasi.
• Juda ko'p narsani, juda keng kuzatish. Filtrsiz syscall darajasidagi qoida (masalan, auid cheklovisiz -S execve) band serverda juda katta hajmdagi log hosil qiladi va haqiqatan muhim hodisalarni topishni osonlashtirish o'rniga qiyinlashtiradi. Qoidalarni haqiqatan hisobdorlik kerak bo'lgan narsalar bilan cheklang.

Mashqlar

1. /etc/passwd ni yozish va atribut o'zgarishi hodisalari uchun kuzatadigan doimiy qoida qo'shing, uni augenrules --load bilan yuklang, arzimas o'zgarish kiriting (masalan, matn muharriri bilan izoh qo'shing) va hodisani ausearch bilan tasdiqlang.
2. Aniq misol yordamida auid bo'yicha filtrlaydigan qoida hisobdorlik uchun nega uid bo'yicha filtrlaydiganidan foydaliroq ekanini tushuntiring.
3. Ma’lum autentifikatsiya tarixiga ega tizimda aureport -au --summary ni ishga tushiring va muvaffaqiyatli va muvaffaqiyatsiz urinishlar nisbatini talqin qiling.
4. Xavfsizlikka oid hodisani auditd yozib borishi va SELinux uni bloklashi, hatto ikkalasi ham bir xil asosiy amal tomonidan ishga tushirilganda ham, nega bir-birini takrorlamasligini tushuntiring.

Xulosa

auditd kernel’ga ulanib, xavfsizlikka oid hodisalarni — fayllarga kirish, syscall’lar, autentifikatsiya — biror alohida ilova nimani log'ga yozishni tanlashidan mustaqil ravishda yozib boradi. Uning auid maydoni imtiyoz oshirilgandan keyin ham oddiy uid kuzatuvi saqlay olmaydigan tarzda saqlanib qoladi. ausearch aniq yozib olingan hodisalarni topadi, aureport esa ko'plab hodisalar bo'yicha shablonlarni umumlashtiradi. Lekin auditd’ning o'zi hech qachon hech narsani bloklamaydi — u kirishni boshqarish vositasi emas, ko'rinuvchanlik vositasi. Qoidalar esa auditctl bilan tasodifiy qo'shilganda emas, faqat /etc/audit/rules.d/ ga yozilganda qayta yuklanishdan keyin saqlanib qoladi. Keyingi maqola, Ruxsatlar auditi, bu modul qayta-qayta qaytadigan davriy ko'rib chiqishni — kimda qanday kirish huquqi bor va u hali ham haqiqatan kerak bo'lgan narsaga mos keladimi — takrorlanadigan jarayonga aylantiradi.

Manbalar

• man7.org: auditd(8)
• man7.org: auditctl(8)
• man7.org: ausearch(8)
• man7.org: aureport(8)
• Red Hat: System Auditing