Loglar va hodisaga javob: kichik jamoa uchun asoslar

Kichik jamoada xavfsizlik bo'yicha alohida bo'lim yo'q: dasturchi ham, server administratori ham, hodisaga javob beruvchi ham ko'pincha bir xil odamlar. Shuning uchun hodisa sodir bo'lganda eng ko'p vaqt "nima bo'ldi?" degan savolga javob qidirishga ketadi. Agar loglar yo'q, qisqa muddat saqlangan yoki buzg'unchi ularni o'chirib qo'ygan bo'lsa, bu savolga javob topilmasligi mumkin.

Bu maqolada nimani loglash, loglarni qanday saqlash, qachon ogohlantirish yuborish va hodisaning birinchi soatida qanday harakat qilishni ko'rib chiqamiz. Maqsad — katta SOC emas, balki kichik jamoa haqiqatda bajara oladigan minimal tartib.

Muammo nimada

Odatda loglar bilan bog'liq holat quyidagicha:

• veb-server va ilova loglari bor, lekin hech kim ularni o'qimaydi;
• muhim voqealar (kirish, parol almashtirish, rol o'zgarishi) umuman yozilmaydi;
• loglar bir necha kundan keyin aylanib (rotation) o'chib ketadi;
• loglar faqat o'sha serverda turadi — server buzilsa, buzg'unchi ularni tahrirlashi yoki o'chirishi mumkin;
• aksincha, loglarga parollar, tokenlar va shaxsiy ma'lumotlar yozilib qoladi.

Oxirgi holat ham xavfli: log fayli o'zi ma'lumot oqishi manbaiga aylanadi.

Nega bu ekspertiza uchun muhim

OWASP Top 10 (2021) ro'yxatida alohida toifa bor: A09 "Security Logging and Monitoring Failures". OWASP ASVS ham xavfsizlik voqealarini loglash, loglarda maxfiy ma'lumot bo'lmasligi va loglarni himoyalash bo'yicha talablarni o'z ichiga oladi. Ekspertizada bu ikki tomondan ko'rinadi:

1. Ma'lumot ochiqlanishi. Tashqaridan ochiladigan storage/logs/laravel.log, error_log yoki debug.log fayllari, xato sahifalaridagi stack trace — bularning barchasi topilma sifatida yoziladi. Bu haqda batafsil: debug rejim va ma'lumot ochiqlanishi.
2. Kuzatuv yo'qligi. Login himoyasi, parol tanlash urinishlari va ruxsatsiz kirish urinishlari aniqlanmasa va qayd etilmasa, hujum sezilmay qoladi.

Printsip: log — bu hodisadan keyin savollarga javob beradigan yagona guvoh. U to'liq, himoyalangan va maxfiy ma'lumotlardan toza bo'lishi kerak.

Nimani loglash kerak

Ilova darajasida

Har bir yozuvda kamida: vaqt (UTC yoki aniq vaqt zonasi bilan), foydalanuvchi identifikatori, IP manzil, voqea turi, natija (muvaffaqiyatli yoki yo'q), so'rov identifikatori.

Loglanishi kerak bo'lgan voqealar:

• muvaffaqiyatli va muvaffaqiyatsiz kirishlar, chiqish, bloklanish;
• parol, email, telefon raqamini o'zgartirish, parolni tiklash;
• rol va huquqlarning o'zgarishi, yangi administrator qo'shilishi;
• ruxsat rad etilgan so'rovlar (403) — ayniqsa boshqa foydalanuvchi obyektlariga urinishlar;
• muhim biznes amallari: to'lov, hujjat imzolash, ma'lumot eksporti;
• validatsiya va CSRF xatolari ko'p takrorlanganda.

Nimani loglamaslik kerak

Parollar, tokenlar, sessiya identifikatorlari, to'liq karta raqamlari, bir martalik kodlar, shaxsiy ma'lumotlarning to'liq matni. So'rov tanasini butunlay yozib qo'yish ko'pincha shunday ma'lumotlarni logga tushiradi.

Server darajasida

• veb-server kirish va xato loglari (nginx access.log, error.log);
• PHP-FPM va ilova xatolari;
• SSH kirishlar (/var/log/auth.log yoki journalctl -u ssh);
• boshqaruv paneli kirishlari;
• firewall rad etgan ulanishlar;
• paket o'rnatish va tizim o'zgarishlari.

Laravel va Node uchun misollar

Laravel'da xavfsizlik voqealari uchun alohida kanal ochish qulay (config/logging.php):

'security' => [
    'driver' => 'daily',
    'path' => storage_path('logs/security.log'),
    'level' => 'info',
    'days' => 90,
],

Kirish voqealarini tinglash:

Event::listen(\Illuminate\Auth\Events\Failed::class, function ($e) {
    Log::channel('security')->warning('login.failed', [
        'login' => $e->credentials['email'] ?? null,
        'ip' => request()->ip(),
        'ua' => substr((string) request()->userAgent(), 0, 200),
    ]);
});

E'tibor bering: credentials massivining o'zi emas, faqat login yoziladi — parol logga tushmaydi.

Node.js (pino) misolida maxfiy maydonlarni avtomatik yashirish:

const logger = require('pino')({
  redact: ['req.headers.authorization', 'req.headers.cookie', '*.password', '*.token'],
});
logger.info({ userId: user.id, ip: req.ip, event: 'login.success' });

Strukturalangan (JSON) loglar keyinchalik qidirish va tahlil qilishni ancha osonlashtiradi.

O'zingiz tekshiring

Loglar tashqaridan ochilmasligini tekshiring (faqat o'z saytingizda):

for p in storage/logs/laravel.log error_log debug.log wp-content/debug.log logs/error.log; do
  printf "%s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://example.uz/$p"
done

Loglarda maxfiy ma'lumot bor-yo'qligini qidiring:

grep -riE "password|passwd|authorization: bearer|api_key|secret" /var/www/app/storage/logs | head

Loglar qancha saqlanishini ko'ring: /etc/logrotate.d/ dagi sozlamalar va journalctl --disk-usage. Va oddiy savol: kecha soat 03:00 da administrator paneliga kim kirganini besh daqiqada aniqlay olasizmi?

Saqlash muddati va himoya

Saqlash muddati tashkilot talablariga bog'liq, lekin kichik jamoa uchun amaliy yo'l: tezkor qidiruv uchun kamida bir necha hafta, arxivda esa bir necha oy. Ba'zi sohalar uchun me'yoriy talablar bo'lishi mumkin — ularni o'z yuristingiz bilan aniqlang.

nginx loglari uchun logrotate misoli:

/var/log/nginx/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
    sharedscripts
    postrotate
        [ -f /run/nginx.pid ] && kill -USR1 $(cat /run/nginx.pid)
    endscript
}

Log fayllari faqat kerakli foydalanuvchilar uchun o'qiladigan bo'lsin (0640), veb-papkadan tashqarida tursin.

Loglarni markazlashtirish

Agar loglar faqat o'sha serverda bo'lsa, serverni buzgan odam izlarini o'chirishi mumkin. Shuning uchun loglarni real vaqtda boshqa joyga yuborish kerak. Kichik jamoa uchun variantlar:

• rsyslog orqali alohida log serveriga yuborish:

# /etc/rsyslog.d/90-remote.conf
*.* @@logs.internal.example:514

• Grafana Loki + Promtail yoki Vector kabi yengil yechimlar;
• bulut provayderining log xizmati.

Muhim jihat: asosiy server log serveriga faqat yoza olsin, o'chira olmasin. Server vaqtini NTP (timedatectl, chrony) bilan sinxronlashtiring — aks holda turli manbalardagi voqealarni solishtirib bo'lmaydi.

Ogohlantirishlar

Hamma narsa uchun ogohlantirish yuborish — hech narsa uchun yubormaslik bilan teng: jamoa tezda ularga e'tibor bermay qo'yadi. Kam, lekin aniq qoidalardan boshlang:

• qisqa vaqt ichida bitta IP yoki bitta akkauntga ko'p muvaffaqiyatsiz kirish;
• yangi administrator qo'shilishi yoki rol o'zgarishi;
• administrator paneliga yangi mamlakat yoki noma'lum IP dan kirish;
• 5xx xatolarining keskin ko'payishi;
• veb-papkada yangi .php fayl paydo bo'lishi (ayniqsa uploads ichida);
• zaxira nusxa olish jarayonining muvaffaqiyatsiz tugashi.

Ogohlantirish bir kanalga (Telegram guruh, email) borsin va kim navbatchi ekanini hamma bilsin. SSH uchun fail2ban takroriy urinishlarni avtomatik bloklaydi.

Hodisaning birinchi soati

Hodisa belgisi topildi: notanish administrator, g'alati fayl, loglarda kutilmagan so'rovlar. Shoshilib serverni o'chirish yoki fayllarni o'chirib tashlash eng ko'p uchraydigan xato — dalillar yo'qoladi. Taxminiy tartib:

1. Qayd eting. Kim, qachon, nimani ko'rdi — vaqt bilan yozib boring. Bu keyin hisobot uchun asos bo'ladi.
2. Dalillarni saqlang. Loglar, shubhali fayllar va konfiguratsiya nusxasini boshqa joyga oling va xeshini yozing:

tar -czf /root/ir/evidence_$(date +%F_%H%M).tar.gz /var/log/nginx /var/www/app/storage/logs
sha256sum /root/ir/evidence_*.tar.gz > /root/ir/evidence.sha256
ps auxf > /root/ir/processes.txt
ss -tunap > /root/ir/connections.txt
find /var/www -type f -mtime -7 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort > /root/ir/recent_files.txt

3. Cheklang, lekin yo'q qilmang. Shubhali akkauntni bloklang, backdoor yo'liga veb-server darajasida kirishni yoping, kerak bo'lsa saytni texnik xizmat rejimiga o'tkazing. Shubhali fayllarni o'chirmang — karantin papkasiga ko'chiring.
4. Kalitlarni almashtiring. Ma'lumotlar bazasi paroli, API tokenlar va ilova sirlari, administrator parollari — ularni toza muhitdan almashtiring.
5. Kirish nuqtasini toping. Yangilanmagan plagin, zaif kutubxona, sizib chiqqan parol? Kirish nuqtasi yopilmaguncha tozalash vaqtinchalik bo'ladi.
6. Xabar bering. Rahbariyatga, kerak bo'lsa mijozlarga va vakolatli organlarga. Davlat tizimlari va jiddiy hodisalar uchun milliy kiberxavfsizlik markaziga xabar berish talab qilinishi mumkin.

Real misolni WordPress backdoor tahlili maqolasida ko'rishingiz mumkin: u yerda dalillar avval saqlanib, keyin zararli fayllar karantinga olingan va o'zak fayllar rasmiy nazorat qiymatlari bilan solishtirilgan.

Qisqa checklist

• Kirish, parol, rol o'zgarishi va 403 voqealari loglanadi
• Loglarda parol, token va to'liq shaxsiy ma'lumot yo'q
• Log fayllari veb-papkadan tashqarida va tashqaridan ochilmaydi
• Saqlash muddati belgilangan, logrotate sozlangan
• Loglar boshqa joyga real vaqtda yuboriladi
• Server vaqti NTP bilan sinxronlangan
• Bir nechta aniq ogohlantirish qoidasi va navbatchi bor
• Hodisaga javob tartibi yozma ko'rinishda mavjud, dalil to'plash buyruqlari tayyor

Xulosa

Yaxshi log tizimi hodisani oldini olmaydi, lekin uni tez sezish va to'g'ri javob berish imkonini beradi. Bizning jarayonda Claude AI agenti ilova kodidagi loglash nuqtalarini, log konfiguratsiyasini va loglarga tushayotgan maxfiy ma'lumotlarni ko'rib chiqadi, mutaxassis esa saqlash, markazlashtirish va ogohlantirish qoidalarini sozlaydi.

Loglaringiz va hodisaga javob tartibingiz ekspertizaga tayyorligini tekshirmoqchi bo'lsangiz, skanerlash uchun ariza qoldiring. Rasmiy tekshiruvdan oldin teshiklarni yopishga yordam beramiz.