Xavfsizlik loglarini tahlil qilish

Loglarni tahlil qilish maqolasida grep, awk va journalctl yordamida log'lardan ma’lumot ajratib olish va ularni o'zaro bog'lashning umumiy mexanikasi ko'rib chiqilgan edi. Bu usullar sekin ishlayotgan endpoint’ni debug qilishga ham, xavfsizlik bilan bog'liq savolga ham birdek qo'llaniladi. Bu maqola o'sha mexanikani torroq, xavfsizlikka xos manbalar to'plamiga qo'llaydi: autentifikatsiya log'lari, sudo'dan foydalanish, fail2ban’ning ban tarixi va auditd yozuvlari. Maqsad boshqacha turdagi savolga javob berish: "bu endpoint nega sekin" emas, "kimdir haqiqatan ichkariga kirishga urindimi va agar urinib ko'rgan bo'lsa, nimaga erishdi".

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• Debian/Ubuntu va RHEL oilasidagi tizimlarda xavfsizlik tekshiruvi uchun muhim bo'lgan aniq log manbalarini aniqlash;
• brute-force urinishi, muvaffaqiyatsizliklardan keyingi muvaffaqiyatli login va imtiyozni oshirishning log'dagi izini tanib olish;
• fail2ban’ning ban tarixini uni ishga tushirgan autentifikatsiya log yozuvlari bilan bog'lash;
• ilova darajasidagi log'lar bo'lmaganda yoki yetarli bo'lmaganda o'sha ma’lumotni auditd’dan olish;
• vaqt oralig'i bo'yicha bir-biriga mos keladigan bir nechta manbadan hodisaning taxminiy xronologiyasini (timeline) qayta tiklash.

Xavfsizlikka oid hodisalar aslida qayerda saqlanadi

Noto'g'ri fayldan boshlash haqiqiy tekshiruv paytida vaqt yo'qotishning keng tarqalgan sababi. RHEL oilasidagi tizimda auth.log ni grep qilish hech narsa topmaydi, chunki u yerda bu fayl umuman mavjud emas — xuddi shu ma’lumot /var/log/secure da. Linux loglari maqolasida umumiy tarzda ko'rib chiqilganidek, birorta ham grep yozishdan oldin birinchi qadam — ma’lum distributiv qaysi log oilasidan foydalanishini tasdiqlash.

SSH brute-force shablonini tanib olish

grep 'Failed password' /var/log/auth.log | tail -n 5

Jul 29 03:14:02 web01 sshd[4021]: Failed password for root from 198.51.100.7 port 51422 ssh2
Jul 29 03:14:03 web01 sshd[4023]: Failed password for admin from 198.51.100.7 port 51430 ssh2
Jul 29 03:14:04 web01 sshd[4025]: Failed password for oracle from 198.51.100.7 port 51438 ssh2

Bir xil manbadan, bir necha soniya oraliqda bir nechta foydalanuvchi nomiga (root, admin, oracle) qarshi muvaffaqiyatsizliklar — keng tarqalgan akkaunt nomlarini sinab ko'rayotgan avtomatik skanerlashning klassik izi. Bu o'z parolini noto'g'ri kiritayotgan inson emas, chunki bunday holatda bitta, o'zgarmas foydalanuvchi nomiga qarshi takroriy muvaffaqiyatsizliklar ko'rinardi. Har bir manba manzil bo'yicha muvaffaqiyatsizliklarni sanash bu ikkisini tezda ajratadi:

grep 'Failed password' /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -n 5

 847 198.51.100.7
  312 203.0.113.44
   3 192.0.2.19

Bir kunda 847 ta muvaffaqiyatsizlikka ega manzil va 3 ta muvaffaqiyatsizlikka ega manzil butunlay turli darajadagi e’tiborni talab qiladi. 3 ta muvaffaqiyatsizlik oddiy noto'g'ri kiritilgan parolga mos keladi, 847 tasi esa yo'q.

Muvaffaqiyatsizliklardan keyingi muvaffaqiyatli loginni topish

Haqiqatan muhim hodisa muvaffaqiyatsiz urinishlarning o'zi emas — fail2ban va pam_faillock allaqachon ularni cheklash uchun mo'ljallangan. Muhimi — ulardan biridan keyin oxir-oqibat o'sha manbadan muvaffaqiyatli login bo'lganmi:

grep -E 'Failed password|Accepted (password|publickey)' /var/log/auth.log | grep -A1 -B0 '198.51.100.7' | tail -n 10

Jul 29 03:14:59 web01 sshd[4099]: Failed password for root from 198.51.100.7 port 51899 ssh2
Jul 29 03:15:02 web01 sshd[4101]: Accepted password for root from 198.51.100.7 port 51910 ssh2

Xuddi shu manzildan kelgan Failed password qatorlari to'plamidan darhol keyin kelgan Accepted password qatori, ayniqsa root kabi imtiyozli akkaunt uchun, oddiy shovqin emas, haqiqiy hodisa belgisi. Aynan shu shablon "bizni skanerlashdi, internetga qaragan har bir server doimo shunday bo'ladi" holatini "o'sha sessiya aslida nima qilganini tekshirishimiz kerak" holatiga aylantiradi.

fail2ban tarixi bilan bog'lash

Agar fail2ban ishlayotgan bo'lsa (qarang: fail2ban), uning o'z log'i aybdor manzil allaqachon ma’lum bo'lgan va ban qilinganmi, aynan qachon, buni tasdiqlaydi:

grep '198.51.100.7' /var/log/fail2ban.log

2026-07-29 03:14:10,442 fail2ban.actions [812]: NOTICE  [sshd] Ban 198.51.100.7
2026-07-29 03:22:47,105 fail2ban.actions [812]: NOTICE  [sshd] Unban 198.51.100.7

Agar o'sha manzildan muvaffaqiyatli login (yuqorida topilgan) Ban vaqt belgisidan oldin sodir bo'lgan bo'lsa, fail2ban to'g'ri javob bergan, lekin o'sha bitta sessiyaning oldini olish uchun juda kech qolgan. Buni hodisa hisobotida qayd etishga arziydi, chunki bu tavsiya etiladigan tuzatishni "fail2ban ishlamayapti" dan "fail2ban chegarasini sozlash kerak" ga o'zgartiradi (fail2ban konfiguratsiyasida qisqaroq findtime/pastroq maxretry bilan qat’iylashtiriladi).

Sudo va imtiyozni oshirishni audit qilish

Buzib kirilgan past imtiyozli akkaunt sudo huquqiga ham ega bo'lgan buzib kirilgan akkauntdan kichikroq muammo. Akkaunt yuqori imtiyozlar bilan aslida nima qilganini tekshirish:

grep 'sudo:.*COMMAND' /var/log/auth.log | grep 'compromised_user'

Jul 29 03:16:04 web01 sudo:  compromised_user : TTY=pts/1 ; PWD=/home/compromised_user ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow

Bu bitta qator alohida olingan "akkaunt buzib kirildi" degan ma’lumotdan ancha ko'proq narsa aytadi. U hujumchi aynan nima qilishga uringanini aniqlaydi (/etc/shadow ni o'qish, deyarli aniq mashinadagi har bir akkaunt parolini oflayn buzib ochishga urinish uchun) va aniq, ustuvorligi belgilangan keyingi qadamni beradi: dastlab buzib kirilgan bitta akkauntnikini emas, tizimdagi har bir credential’ni almashtirish. Agar oldindan sudo I/O logging yoqilgan bo'lsa, sudoreplay faqat buyruq qatorini emas, butun sessiyani qayta tiklaydi.

Ilova log'lari yetarli bo'lmaganda: auditd

Ilova darajasidagi log'lar faqat ilova yozishni tanlagan narsani yozadi. Agar savol ko'proq narsani talab qilsa — "qaysi jarayon qilganidan qat’i nazar, aynan shu fayl haqiqatan o'qilganmi" — auth.log/secure javob bera olmaganda, auditd maqolasida ko'rib chiqilgan auditd’ning kernel darajasidagi yozuvi javob bera oladigan manba bo'ladi:

sudo ausearch -f /etc/shadow -ts today -i

type=SYSCALL msg=audit(07/29/2026 03:16:04.201:5521) : ... auid=compromised_user uid=root exe=/usr/bin/cat

Bu /etc/shadow haqiqatan o'sha sessiya tomonidan ochilganini kernel darajasida mustaqil tasdiqlaydi. Tekshiruvga bardosh berishi kerak bo'lgan hodisa hisoboti uchun xronologiya tuzayotganda bu qimmatli qo'shimcha dalil.

Taxminiy xronologiyani qayta tiklash

Hodisa tekshiruviga kamdan-kam hollarda alohida olingan bitta log qatori javob beradi. Unga hodisalar ketma-ketligi bo'yicha bir-biriga mos keladigan bir nechta mustaqil manba javob beradi. Har bir manbadan mos vaqt belgilarini bitta tartiblangan ko'rinishga yig'ish:

{
    grep '198.51.100.7\|compromised_user' /var/log/auth.log
    grep '198.51.100.7' /var/log/fail2ban.log
} | sort -k1,3 -M

Jul 29 03:14:02 web01 sshd[4021]: Failed password for root from 198.51.100.7 ...
Jul 29 03:14:10,442 fail2ban.actions [812]: NOTICE  [sshd] Ban 198.51.100.7
Jul 29 03:15:02 web01 sshd[4101]: Accepted password for root from 198.51.100.7 ...
Jul 29 03:16:04 web01 sudo:  compromised_user : ... COMMAND=/usr/bin/cat /etc/shadow

Bu birlashtirilgan ketma-ketlikni yuqoridan pastga o'qish haqiqiy voqeani aytib beradi: muvaffaqiyatli login (03:15:02) oldingi muvaffaqiyatsizliklar asosida fail2ban ban’i kuchga kirishidan oldin sodir bo'lgan. Ya’ni hujumchi aynan fail2ban chegarasi hali yopilmagan oynada ichkariga kirgan. Bu istalgan bitta log'ni alohida o'qish o'tkazib yuborgan bo'lardi, aniq va amaliy topilma.

Keng tarqalgan xatolar

• RHEL oilasidagi tizimda /var/log/auth.log ni tekshirish. U yerda bu fayl mavjud emas. Uning ekvivalenti /var/log/secure, yoki har ikki oilada journalctl -u sshd.
• Har bir muvaffaqiyatsiz loginga bir xil darajada ahamiyatli deb qarash. Bitta o'zgarmas foydalanuvchi nomiga qarshi bir nechta muvaffaqiyatsizlik — oddiy holat. Bitta manbadan ko'plab foydalanuvchi nomlariga qarshi to'plam — skanerlash. Va har ikki shablondan keyin kelgan muvaffaqiyat — haqiqatan shoshilinch harakatni talab qiladigan hodisa.
• Faqat akkauntni tekshirib, u sudo bilan nima qilganini tekshirmaslik. Hech qachon imtiyozni oshirmagan buzib kirilgan past imtiyozli akkaunt /etc/shadow ni o'qigan yoki /etc/sudoers ni o'zgartirgan akkauntga qaraganda ancha kichik hodisa. Ikkalasini ajratib beradigan narsa — sudo log qatori.
• Hodisa xronologiyasi uchun bitta log manbasiga tayanish. Xronologiya misoli ko'rsatganidek, auth.log ning o'zi ban va muvaffaqiyatli login o'rtasidagi vaqt bog'liqligini o'tkazib yuborgan. Uni yuzaga chiqargan narsa — manbalarni birlashtirish.
• Ilova log'lari barcha tegishli narsalarni yozadi deb o'ylash. Yuqorida ko'rib chiqilganidek, ba’zi savollarga (aynan shu fayl o'qilganmi, qaysi jarayon tomonidan) faqat auditd’ning kernel darajasidagi yozuvi javob bera oladi.

Mashqlar

1. Lab tizimidagi auth.log da (yoki namuna log faylida) har bir manba IP bo'yicha muvaffaqiyatsiz SSH login urinishlarini sanaydigan va ularni son bo'yicha kamayish tartibida saralaydigan buyruq yozing.
2. Bu maqolada ko'rsatilgan shablondan foydalanib, avtomatik foydalanuvchi nomlarini skanerlash hujumini o'z parolini qayta-qayta noto'g'ri kiritayotgan oddiy foydalanuvchidan qanday farqlashni tushuntiring.
3. Bir xil IP’dan fail2ban ban vaqt belgisi va muvaffaqiyatli login vaqt belgisi berilgan holda, login ban’dan oldin yoki keyin sodir bo'lgani xavfsizlik holati uchun nimani anglatishini tushuntiring.
4. auth.log javob bera olmaydigan, lekin ausearch javob bera oladigan xavfsizlik savolini o'z so'zlaringiz bilan tasvirlab bering va nega shunday ekanini tushuntiring.

Xulosa

Xavfsizlik log'larini tahlil qilish umumiy log tahlilidagi o'sha grep/awk/journalctl mexanikasidan foydalanadi, lekin u torroq manbalar to'plamiga — autentifikatsiya log'lari, sudo yozuvlari, fail2ban tarixi va auditd’ning kernel darajasidagi iziga — hamda aniq maqsadga qaratilgan: hujum shablonlarini tanib olish, urinish muvaffaqiyatli bo'lganmi, tasdiqlash va hodisalar ketma-ketligi bo'yicha bir-biriga mos keladigan bir nechta manbadan xronologiyani qayta tiklash. Bu modulning yakunlovchi maqolasi, Serverni mustahkamlash (hardening), eng kam imtiyozdan log tahlilgacha hozirgacha ko'rib chiqilgan barcha himoya vositalarini serverni production’ga tayyorlash uchun bitta tartibli checklist’ga yig'adi.

Manbalar

• man7.org: sshd(8) — log xabarlari formatlari
• man7.org: ausearch(8)
• Fail2ban rasmiy hujjatlari
• Red Hat: Reviewing Audit Records