Linux xavfsizligi asoslari

Ishga tushadigan, trafikka xizmat qiladigan, lekin hech qachon yangilanmaydigan server "yaxshi ishlayapti" degani emas. U jimgina xavf to'playapti, chunki yangilanmagan har bir servis va haddan tashqari keng berilgan har bir ruxsat — oxir-oqibat kimdir topib oladigan eshik. Bu modul bitta vosita haqida emas. U birgalikda hujumchining ichkariga kirishini sezilarli darajada qiyinlashtiradigan, biror narsa noto'g'ri ketganda esa sizga buni tezroq payqash va javob berish imkonini beradigan qatlamlar to'plami haqida. Bu maqola modulning qolgan qismi tayanadigan atamalar va fikrlash modelini bayon qiladi.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

• autentifikatsiya (authentication) va avtorizatsiya (authorization) o'rtasidagi farqni va ularning har biri qayerda buzilishi mumkinligini tushuntirish;
• DAC va MAC farqini hamda Linux tizimida odatda nega ikkalasi ham bo'lishini tushuntirish;
• defense in depth (ko'p qatlamli himoya) tushunchasini tasvirlash va uni aniq serverga qo'llash;
• Linux xavfsizlik vositalarining asosiy toifalarini va ularning har biri bu kursning qayerida ko'rib chiqilishini sanab o'tish;
• attack surface (hujum yuzasi) haqida uni passiv himoya qilinadigan narsa sifatida emas, faol qisqartiriladigan narsa sifatida fikr yuritish.

Autentifikatsiya va avtorizatsiya

Bu ikki so'z kundalik suhbatda deyarli bir-birining o'rnida ishlatiladi, lekin ular turli savollarga javob beradi. Ularni chalkashtirish xavfsizlik sozlamalaridagi xatolarning keng tarqalgan manbalaridan biri:

• Autentifikatsiya "siz kimsiz?" degan savolga javob beradi — parol tekshiruvi, SSH kalit, TOTP kodi.
• Avtorizatsiya "kimligingizni bilganimdan keyin, sizga nima qilishga ruxsat bor?" degan savolga javob beradi — fayl ruxsatlari, sudoers qoidalari, firewall qoidasi, SELinux siyosati.

Tizim kimnidir to'g'ri autentifikatsiya qilishi, lekin unga haddan tashqari keng avtorizatsiya berishi mumkin. sudo ALL=(ALL) NOPASSWD: ALL huquqiga ega qonuniy foydalanuvchi — to'g'ri autentifikatsiya qilingan, lekin avtorizatsiya muammosi bor foydalanuvchi. Bu moduldagi deyarli hamma narsa yo autentifikatsiyani kuchaytiradi (PAM, parol siyosati, oldingi moduldagi kalitga asoslangan SSH), yo avtorizatsiyani kuchaytiradi (least privilege, sudo doirasini cheklash, ACL’lar, SELinux/AppArmor), yoki ularning biri ishlamay qolganini aniqlash imkonini beradi (auditd, log tahlili).

DAC va MAC: kirishni boshqarishning ikki qatlami

Linux’ning an’anaviy ruxsatlar modeli — rwx bitlari, egalik, chmod — Discretionary Access Control (DAC). Bunda faylga kim kira olishini faylning egasi hal qiladi, kernel esa shu qarorni amalga oshiradi. U "discretionary" (ixtiyoriy) deb ataladi, chunki qaror tizim bo'yicha umumiy siyosatga emas, resurs egasining ixtiyoriga bog'liq.

Mandatory Access Control (MAC) — RHEL oilasida SELinux, Ubuntu’da AppArmor — DAC ustida joylashadi va resurs egasi bekor qila olmaydigan, tizim belgilagan alohida siyosatni majburiy qo'llaydi. Jarayon root bo'lishi, faylga to'liq egalik qilishi va barcha DAC tekshiruvlaridan o'tishi mumkin, lekin MAC baribir amalni rad etishi mumkin. Chunki ma’lum turdagi jarayon nimaga tegishi mumkinligini fayl egasi emas, xavfsizlik siyosati hal qiladi.

getenforce        # SELinux: reports Enforcing, Permissive, or Disabled
aa-status         # AppArmor: reports loaded profiles and their mode

Bu ikki qatlamli tuzilma ataylab shunday qilingan. Faqat DAC bo'lsa, qonuniy foydalanuvchi nomidan ishlayotgan bitta buzib kirilgan jarayon (masalan, ekspluatatsiya qilingan web server) o'sha foydalanuvchi qila oladigan hamma narsani qila oladi: /home dagi SSH kalitlarini o'qiydi, foydalanuvchiga tegishli istalgan faylga yozadi. MAC esa oddiy Linux ruxsatlari nimaga ruxsat berishidan qat’i nazar, bu jarayonni faqat uning siyosati ruxsat bergan aniq fayllar, portlar va imkoniyatlar (capabilities) bilan cheklaydi. Ikkalasi ham shu modulning keyingi qismida, SELinux va AppArmor maqolasida chuqur ko'rib chiqiladi.

Defense in depth (ko'p qatlamli himoya)

Hech bir vosita mukammal emas: firewall qoidasi noto'g'ri sozlanishi, parol oshkor bo'lishi, yangilanish kechikishi mumkin. Defense in depth bitta muvaffaqiyatsizlik to'liq buzib kirishga teng bo'lmasligi uchun bir-biridan mustaqil himoya vositalarini ustma-ust qo'yishni anglatadi. Qatlamlarning tashqaridan ichkariga qarab taxminiy modeli:

Network        -> firewall (ufw/nftables), fail2ban, exposed ports minimized
Authentication -> SSH keys, PAM, password policy, MFA where warranted
Authorization  -> least privilege, sudo scoping, file permissions, ACLs
Mandatory access control -> SELinux/AppArmor confining what a process can do even as root
Detection      -> auditd, centralized logging, log analysis
Recovery       -> patching cadence, backups (covered in the automation module), incident response

Attack surface: siz haqiqatan qisqartira oladigan narsa

Attack surface — hujumchi potensial ravishda ta’sir o'tkazishi mumkin bo'lgan hamma narsaning yig'indisi: tinglayotgan har bir port, tarmoqqa qaragan daemon’i bor har bir o'rnatilgan paket, tizimga kira oladigan har bir akkaunt, har bir sudo qoidasi, buzib kirilgan jarayon yeta oladigan har bir yoziladigan fayl. Asosan sizning nazoratingizdan tashqarida bo'lgan "tahdidlar"dan farqli o'laroq, attack surface’ni siz bevosita qisqartira olasiz:

ss -tulpn                                   # what's actually listening
systemctl list-unit-files --state=enabled   # what starts automatically
dpkg -l | wc -l                             # how much is installed at all

Faqat kerakli narsalarni ishga tushiradigan server — sozlash paytidan qolib ketgan namuna web ilovalarsiz, ommaviy interfeysda hamon tinglayotgan ishlatilmaydigan ma’lumotlar bazasi dvigatelisiz, unutilgan test akkauntisiz — "har ehtimolga qarshi" to'liq desktop darajasidagi paketlar to'plamini ishga tushirgan serverga qaraganda himoya qilinishi kerak bo'lgan narsalarga tubdan kamroq ega. Modulning yakunlovchi maqolasi, Serverni mustahkamlash (hardening), bu tamoyilni aniq checklist’ga aylantiradi.

Modulning qolgan qismi qanday tuzilgan

Bu modul bitta serverning avtorizatsiya modelidan butun aniqlash (detection) zanjirigacha bosqichma-bosqich kengayib boradi:

1. Eng kam imtiyoz (least privilege) — bu yerdagi deyarli boshqa barcha maqolalar ortidagi asosiy tamoyil.
2. sudo xavfsizligi — oddiy foydalanuvchilarning root bo'lishining eng keng tarqalgan usulini mustahkamlash va audit qilish. U foydalanuvchilar va ruxsatlar modulidagi Root va sudo maqolasiga tayanadi.
3. PAM asoslari — sudo, login va SSH ustida turadigan ulanadigan (pluggable) autentifikatsiya framework’i.
4. Parol siyosatlari — parol kuchliligi va almashtirilishini bitta akkaunt sozlamalaridan tashqari, butun tizim bo'yicha majburiy qilish.
5. SELinux va AppArmor — majburiy kirish nazorati (MAC) chuqur.
6. Firewall va UFW hamda iptables va nftables — hostga umuman nima yetib kelishini boshqarish.
7. fail2ban — takroriy hujum urinishlariga avtomatik javob berish.
8. auditd — kernel ko'radigan xavfsizlikka oid hodisalarni yozib borish.
9. Ruxsatlar auditi — tasodifiy ruxsat tekshiruvlarini takrorlanadigan jarayonga aylantirish.
10. Xavfsizlik loglarini tahlil qilish — auditd, PAM va sshd haqiqatda nimani yozib qo'yganini o'qish.
11. Serverni mustahkamlash (hardening) — yuqoridagilarning hammasini bitta tartibli checklist’ga yig'ish.

Server xavfsizligi — holat emas, jarayon

Bir marta mustahkamlanib, keyin qayta ko'rib chiqilmagan server asta-sekin yana xavfsiz bo'lmagan holatga qaytadi: paketlar eskiradi, debug sessiyasidan qolgan "vaqtinchalik" firewall qoidasi unutiladi, pudratchi uchun qo'shilgan akkaunt hech qachon olib tashlanmaydi. Bu moduldagi har bir maqola himoya vositasini uning hali ham o'z ishini bajarayotganini tekshirish usuli bilan birga beradi — systemctl status, journalctl, getenforce, ufw status verbose. Chunki hech kim tekshirmaydigan himoya vositasi hech kim sezmagan holda jimgina ishlashdan to'xtaydi.

Keng tarqalgan xatolar

• Xavfsizlikka bir martalik sozlash vazifasi sifatida qarash. Yangilash (patching), log'larni ko'rib chiqish va akkauntlar auditi dastlabki sozlash paytida bir marta emas, jadval bo'yicha takrorlanishi kerak.
• "Xato yo'q" ni "xavfsiz" bilan chalkashtirish. Server hech qanday shikoyatsiz ishlab turgan holda ham yangilanmagan servisni, haddan tashqari keng sudo qoidasini yoki hamma yoza oladigan (world-writable) katalogni ochiq qoldirishi mumkin. Ko'rinadigan muammolarning yo'qligi haqiqiy audit bilan bir xil narsa emas.
• Bitta vositani "yagona" xavfsizlik yechimi deb bilish. Kalitga asoslangan SSH’siz fail2ban yoki ortida yangilanmagan servislar turgan firewall — har biri faqat bitta qatlamni yopadi, qolganlarini esa ochiq qoldiradi.

Mashqlar

1. O'zingiz boshqaradigan server yoki lab VM uchun hozirning o'zida olib tashlansa yoki o'chirilsa, uning attack surface’ini qisqartiradigan uchta aniq narsani va ko'proq vaqtingiz bo'lsa, uni yanada qisqartiradigan yana uchta narsani sanab chiqing.
2. getenforce ni (yoki Ubuntu’da aa-status ni) ishga tushiring va natija faylga to'g'ri DAC ruxsatlari bo'lgan jarayon uchun nimani anglatishini bir jumlada tushuntiring.
3. Bitta xavfsizlik hodisasi vaziyatini tanlang (oshkor bo'lgan parol, noto'g'ri sozlangan sudoers yozuvi, ochiq qolgan ma’lumotlar bazasi porti) va defense in depth’ning qaysi qatlami uni ushlashi kerak edi, birinchisi ishlamay qolsa, qaysi qatlam zararni cheklagan bo'lardi, tasvirlab bering.

Xulosa

Linux serverda xavfsizlik autentifikatsiyani avtorizatsiyadan ajratishga, DAC ustiga MAC qatlamini qo'yishga, hech bir yagona muvaffaqiyatsizlik halokatli bo'lmasligi uchun mustaqil himoya vositalarini ustma-ust qo'yishga va faqat tahdidlarga javob berish o'rniga ochiq qolgan narsalarni faol qisqartirishga tayanadi. Modulning qolgan qismi har bir qatlamni navbatma-navbat ko'rib chiqadi va ularning deyarli hammasini bog'lab turadigan tamoyildan boshlaydi: eng kam imtiyoz (least privilege).

Manbalar

• NIST SP 800-53: Security and Privacy Controls for Information Systems
• Red Hat: Using SELinux
• Ubuntu Server hujjatlari: Xavfsizlik
• CIS Benchmarks: Distribution Independent Linux