Serverni mustahkamlash (hardening)

Bu moduldagi har bir maqola bitta himoya vositasini chuqur ko'rib chiqdi: tamoyil sifatida eng kam imtiyoz, autentifikatsiya va imtiyozni oshirish qatlami sifatida sudo va PAM, majburiy kirish nazorati sifatida SELinux/AppArmor, tarmoq chegarasi sifatida firewall’lar, aniqlash vositalari sifatida fail2ban va auditd. Ularning hech biri yolg'iz o'zi "serverni mustahkamlash" emas. Hardening — bularning hammasini oqilona tartibda bitta aniq serverga qo'llash intizomi. Bunga o'z alohida maqolasi bo'lmagan bir nechta band ham qo'shiladi: keraksiz narsalarni olib tashlash, yangilanishlarni avtomatlashtirish va natijani tekshirish. Bu yakunlovchi maqola aynan shu checklist.

Nimalarni o'rganasiz

Bu maqola oxirida siz quyidagilarni qila olasiz:

hardening qadamlari nega birdaniga emas, tartib bilan qo'llanilishi va tekshirilishi kerakligini tushuntirish;
serverdagi paketlar va servislar hajmini haqiqatan kerak bo'lgan darajagacha qisqartirish;
avtomatik xavfsizlik yangilanishlarini sozlash va ular nimani qamrab olmasligini bilish;
bir nechta kernel darajasidagi (sysctl) hardening sozlamalarini qo'llash va ularning har biri nima qilishini tushuntirish;
server hardening holati haqida mustaqil, avtomatlashtirilgan ikkinchi fikr olish uchun lynis dan foydalanish.

Nega tartib muhim

Ehtiyotsizlik bilan bajarilgan hardening autentifikatsiyaga, firewall’ga va tizim servislariga birdaniga tegadi. Ulardan birortasi noto'g'ri qo'llanilsa, ishni bajarayotgan sessiyaning o'zini qulflab qo'yishi mumkin. Xavfsiz ketma-ketlik bu kurs davomida ishlatilgan "keyingi qaytarib bo'lmaydigan qadamdan oldin tasdiqla" shablonini takrorlaydi:

masofaviy kirish ishlashini va uning zaxira yo'li borligini tasdiqlash (server masofaviy bo'lsa, SSH’dan mustaqil konsol sessiyasi);
paketlar va servislar hajmini qisqartirish;
autentifikatsiyani berkitish (SSH, sudo, PAM, parol siyosati);
majburiy kirish nazoratini qo'llash;
avval SSH kirishini tasdiqlab, firewall’ni qo'llash;
aniqlash vositalarini qo'shish (fail2ban, auditd, log'larni ko'rib chiqish);
yangilanishlarni avtomatlashtirish;
butun natijani mustaqil tekshirish.

Quyidagi har bir raqamlangan qadam uni chuqur ko'rib chiqadigan maqolaga havola qiladi. Bu maqolaning vazifasi — tartib va boshqa hech qayerga tegishli bo'lmagan bandlar.

1-qadam: biror narsaga tegishdan oldin zaxira yo'lni tasdiqlash

Har qanday boshqa qadamdan oldin serverga kiritilmoqchi bo'lgan o'zgarishga bog'liq bo'lmagan qaytish yo'li borligini tasdiqlang: hosting provayderining konsol kirishi yoki butun hardening jarayoni davomida ochiq saqlanadigan ikkinchi, allaqachon ochilgan SSH sessiyasi. Quyidagi buzuvchi xususiyatga yaqin har bir qadam (ufw enable, PAM o'zgarishi, SSH konfiguratsiyasini qayta yuklash) o'z maqolasida xuddi shu ogohlantirishni takrorlaydi. Bu yerda bir marta aytilgan holda u faqat bitta qadamga emas, butun checklist’ga tegishli.

2-qadam: hajmni qisqartirish

Eng arzon va eng ko'p o'tkazib yuboriladigan hardening qadami — serverga umuman kerak bo'lmagan narsalarni olib tashlash. Linux xavfsizligi asoslari maqolasida bu attack surface’ni qisqartirish sifatida tanishtirilgan edi.

ss -tulpn

Netid  State   Local Address:Port
tcp    LISTEN  0.0.0.0:22
tcp    LISTEN  0.0.0.0:3306

Ma’lumotlar bazasiga faqat mahalliy ilovalar murojaat qilishi kerak bo'lgan hostda 0.0.0.0:3306 da tinglayotgan MySQL serveri darhol savol tug'dirishi kerak. Yo u faqat 127.0.0.1 ga bog'lanishi (bind) kerak, yo uning uchun firewall qoidasi boshidanoq ilova subnet’idan tashqaridan kirishga hech qachon ruxsat bermasligi kerak edi (qarang: Firewall va UFW).

systemctl list-unit-files --state=enabled

bluetooth.service         enabled
cups.service              enabled
ssh.service               enabled

Monitorsiz (headless) serverda yoqilgan bluetooth va cups (chop etish) — talablar emas, standart o'rnatishdan qolgan qoldiqlar. Ularning har biri o'z attack surface’iga ega va bu mashinada hech qanday qonuniy maqsadi bo'lmagan ishlab turgan daemon:

sudo systemctl disable --now bluetooth cups
sudo apt purge cups bluez

sudo apt autoremove --purge

autoremove --purge faqat allaqachon olib tashlangan narsaning bog'liqligi sifatida o'rnatilgan paketlarni ularning konfiguratsiya fayllari bilan birga tozalaydi. O'rnatilgan hajm qanchalik kichik bo'lsa, nazariy jihatdan xavfsizlik yangilanishiga muhtoj bo'lishi mumkin bo'lgan paketlar shunchalik kam bo'ladi.

3-qadam: autentifikatsiyani berkitish

Modulning oldingi maqolalarining ko'pchiligi aynan shu yerda, quyidagi tartibda bevosita qo'llaniladi:

SSH — faqat kalit bilan autentifikatsiya, root login yo'q, cheklangan AllowUsers — qarang: SSH hardening. U to'liq checklist’ni va xavfsiz joriy qilish tartibini allaqachon qamrab olgan.
sudo — cheklangan qoidalar, umumiy NOPASSWD: ALL yo'q, sezgir akkauntlar uchun I/O logging — qarang: sudo xavfsizligi.
PAM — pam_faillock yoqilgan, pam_unix dan nullok olib tashlangan — qarang: PAM asoslari va Root va sudo.
Parol siyosati — murakkablik, tarix va muddat distributiv standartlarida qoldirilmasdan, ongli ravishda o'rnatilgan — qarang: Parol siyosatlari.

Bu yerda yangi buyruqlar yo'q. Ularni birga sanab o'tishning ma’nosi — tartibda: firewall va MAC qatlamlari ustiga qo'yilishidan oldin autentifikatsiya mustahkam bo'lishi kerak. Chunki bu ikkisi autentifikatsiyasi allaqachon ishonchli deb hisoblangan tizimni himoya qiladi.

4-qadam: majburiy kirish nazoratini qo'llash

SELinux yoki AppArmor shunchaki o'rnatilgan emas, haqiqatan majburlayotganini tasdiqlang:

getenforce         # expect: Enforcing
aa-status | head -n 3   # expect: profiles in enforce mode

SELinux o'rnatilgan, lekin Permissive da qoldirilgan yoki AppArmor profillari complain da qoldirilgan server MAC’ning bloklash foydasisiz faqat log yozish foydasini oladi. Buni alohida tekshirishga arziydi, chunki aks holda Permissive tizim rejimni maxsus tekshirmaydigan har bir buyruqda Enforcing tizimdan farq qilmaydi. Rejimlarni xavfsiz almashtirish va standart siyosat qamrab olmagan har qanday narsa uchun profillar qurish SELinux va AppArmor maqolasida ko'rib chiqilgan.

5-qadam: firewall’ni qo'llash

sudo ufw allow 22/tcp    # or the confirmed alternate SSH port
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Firewall va UFW maqolasida ko'rib chiqilganidek, SSH allow qoidasi ufw enable ishga tushishidan keyin emas, oldin mavjud bo'lishi va tasdiqlanishi kerak. Bu bu yerda takrorlanmoqda, chunki tartib buzilsa, hardening sessiyasini qulflangan server bilan yakunlash ehtimoli eng yuqori bo'lgan qadam aynan shu.

6-qadam: aniqlash vositalarini qo'shish

sudo systemctl enable --now fail2ban auditd

Ularning har birini sozlash fail2ban va auditd maqolalarida chuqur ko'rib chiqilgan. Hardening checklist’ining vazifasi shunchaki ikkalasi haqiqatan ishlayotganini tasdiqlash. Chunki o'rnatilgan, lekin yoqilmagan servis umuman himoya bermaydi. Paket daemon’ni o'rnatib, uni standart holatda o'chiq qoldirganda bu xatoni qilish oson.

7-qadam: yangilanishlarni avtomatlashtirish

unattended-upgrades Production’da yangilanishlar maqolasida to'liq ko'rib chiqilgan. Hech qachon xavfsizlik yangilanishlarini olmaydigan mustahkamlangan server faqat kechagi zaifliklarga qarshi mustahkamlangan bo'ladi:

sudo dpkg-reconfigure --priority=low unattended-upgrades

grep -A2 'Unattended-Upgrade::Allowed-Origins' /etc/apt/apt.conf.d/50unattended-upgrades

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";

Avtomatik yangilash — avtomatik tekshirish emas

unattended-upgrades xavfsizlik yangilanishlarini qo'llaydi. U servislar keyin to'g'ri qayta ishga tushganini tasdiqlamaydi va asosiy versiya yangilanishlarini qamrab olmaydi. Production’da yangilanishlar maqolasida aynan shu bo'shliqni yopadigan vosita — needrestart ko'rib chiqilgan. Yangilangan, lekin qayta ishga tushirilmagan servis xotirada hali ham zaif kodni ishlatib turadi.

O'z maqolasi bo'lmagan bir nechta band

Ikkita kichik, mustaqil hardening bandi to'liq maqolaga arzimaydi, lekin har qanday checklist’da bo'lishi kerak.

Login banneri — autentifikatsiyadan oldin ko'rsatiladigan, kirish kuzatilishini va ruxsatsiz foydalanish taqiqlanganini bildiradigan xabar. Bu texnik himoya vositasi emas, ko'plab yurisdiksiyalarda va tashkilot siyosatlarida huquqiy va ogohlantiruvchi chora:

sudo nano /etc/issue.net

Authorized access only. All activity is monitored and logged.

sudo grep Banner /etc/ssh/sshd_config

Banner /etc/issue.net

sysctl orqali kernel tarmog'ini mustahkamlash — internetga qaragan har qanday serverda yoqishga arziydigan kichik sozlamalar to'plami:

sudo nano /etc/sysctl.d/99-hardening.conf

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1

tcp_syncookies kernel’ga har bir yarim ochiq ulanish uchun to'liq holatni saqlamasdan ulanishlar navbatini (backlog) boshqarishga imkon berib, SYN-flood ta’sirini kamaytiradi;
accept_redirects = 0 va accept_source_route = 0 ICMP redirect’larni va source-routed paketlarni rad etadi. Aks holda ikkalasidan ham bu host trafigini hujumchi nazorat qiladigan yo'l orqali qayta yo'naltirish uchun suiiste’mol qilish mumkin;
icmp_echo_ignore_broadcasts hostning Smurf uslubidagi kuchaytirish (amplification) hujumida ishtirok etishining oldini oladi.

sudo sysctl -p /etc/sysctl.d/99-hardening.conf

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1

8-qadam: `lynis` bilan mustaqil tekshirish

Checklist qo'lda qo'llangandan keyin mustaqil audit vositasi hardening'ni hozirgina bajargan kishi bilan bir xil ko'r nuqtalarga ega bo'lmagan ikkinchi fikrni beradi:

sudo apt install lynis
sudo lynis audit system

[+] System Tools
------------------------------------
  - Scanning available tools...
  - Checking present vendor and tools...

[+] Kernel
------------------------------------
  - Checking default run level                             [ RUNLEVEL 5 ]
  - Checking CPU support (NX/PAE)                           [ FOUND ]
...
Hardening index : 68 [############        ]

Warning: Access to audit log is not restricted
Suggestion: Consider hardening SSH configuration [CIS-CAT: 5.2.11]

lynis o'zi hech narsani tuzatmaydi. U tizimning haqiqiy konfiguratsiyasini ma’lum hardening benchmark’larining katta to'plami bilan solishtiradi va aniq, amaliy takliflar bilan birga ball haqida hisobot beradi. Ballning o'zi uning ostidagi aniq takliflar ro'yxatidan kamroq muhim. Har bir taklifni aynan shu server uchun o'z mohiyatiga ko'ra ko'rib chiqish o'rniga "100 ga yetish"ni maqsad qilib qo'yish Linux xavfsizligi asoslari maqolasida ko'rib chiqilgan o'sha "katakchalarni belgilash" xatosini keltirib chiqaradi. Yuqori ball xavfsizlikning isboti emas, faqat vositaning aniq tekshiruvlari hozir o'tayotganining dalili.

Amaliy vaziyat: yangi Ubuntu Server LTS’ni production’dan oldin mustahkamlash

Muammo. Yangi tayyorlangan Ubuntu Server LTS instansini standart o'rnatishdan production’ga tayyor holatga keltirish kerak.

Checklist’ga tartib bilan amal qilish:

# Step 1: fallback already confirmed — provider console access verified before starting

# Step 2: footprint
sudo systemctl list-unit-files --state=enabled | grep -v -E 'ssh|systemd|cron|networkd|resolved'
sudo apt autoremove --purge

# Step 3: authentication (see linked articles for full detail)
# SSH keys confirmed, PasswordAuthentication no, sudoers scoped, pam_faillock enabled

# Step 4: MAC
aa-status | head -n 3

# Step 5: firewall — SSH confirmed first
sudo ufw allow 22/tcp
sudo ufw enable

# Step 6: detection
sudo systemctl enable --now fail2ban auditd

# Step 7: patching
sudo dpkg-reconfigure --priority=low unattended-upgrades

# Step 8: verify
sudo lynis audit system

Natija. Checklist qo'llangandan keyin lynis ning hardening indeksi yangi o'rnatmaning bazaviy qiymatidan (odatda 50-lar atrofida) 70-larning yuqori qismi yoki 80-larga ko'tariladi. Uning qolgan takliflari esa bir martalik o'tish emas, keyingi iteratsiya uchun kirish ma’lumotiga aylanadi.

Xulosa. Bu yerdagi birorta ham qadam yangi emas edi — har bir buyruq shu modulda yoki undan oldingi modulda allaqachon ko'rib chiqilgan maqolaga borib taqaladi. Bu yakunlovchi maqolaning qiymati biror alohida usulda emas, ro'yxatning tartibi va to'liqligida.

Keng tarqalgan xatolar

Barcha hardening qadamlarini oralarida sinab ko'rmasdan birdaniga qo'llash. Bu modul davomida ta’kidlanganidek, qadamlar birma-bir qo'llanilib, tekshirilganda istalgan bitta qadamdagi xatoni (yomon PAM qatori, SSH qoidasisiz yoqilgan firewall) ajratib olish va tuzatish ancha oson.
Autentifikatsiya va firewall’ni mustahkamlab, hajmni qisqartirish qadamini o'tkazib yuborish. Kamroq servis ishlayotgan serverda boshidanoq mustahkamlash kerak bo'lgan narsalar kamroq bo'ladi. Bu qadamni o'tkazib yuborish keyingi har bir qadam qamrab olishi kerak bo'lgan yuzani kattalashtiradi.
lynis ballini marra chizig'i deb hisoblash. Yuqorida ko'rib chiqilganidek, ball — taxminiy signal. Muhimi — aynan shu serverga haqiqatan nima kerakligiga qarab baholangan aniq takliflar ro'yxati.
unattended-upgrades ni yoqib, yangilash endi to'liq avtomatlashtirildi deb o'ylash. Production’da yangilanishlar maqolasida ko'rib chiqilgan kernel yangilanishlari uchun qayta yuklashlar va kutubxona yangilanishidan keyingi servislarni qayta ishga tushirish shunchaki paketning standart konfiguratsiyasini emas, faol jarayonni talab qiladi.
Checklist’ni tayyorlash paytida bir marta ishga tushirib, boshqa hech qachon qaytmaslik. Ruxsatlar auditi va bu modulning umumiy g'oyasi bu yerda ham amal qiladi: bir marta mustahkamlanib, keyin qayta ko'rib chiqilmagan server vaqt o'tishi bilan asta-sekin mustahkamlanmagan standart holatiga qaytadi.

Mashqlar

Lab VM’da faqat 2-qadam (hajmni qisqartirish) va 8-qadamni (lynis) bajaring, hardening indeksini yozib qo'ying, keyin 3-7-qadamlarni qo'llang va lynis ni qayta ishga tushiring. Ikki ballni taqqoslang va qaysi aniq takliflar yo'qolganini aniqlang.
Bu checklist’dagi tartib nega hajmni qisqartirishni firewall sozlashdan oldin qo'yishini, teskarisini emas, tushuntiring.
Haqiqiy skanerlashdan uchta lynis taklifini tanlang va har biri uchun uni ko'z oldingizdagi aniq serverga qo'llashga arziydimi yoki yo'qmi, hal qiling va har ikki holatda ham fikringizni asoslang.
Bu serverni sizdan qabul qilib oladigan kishi birinchi bo'lib o'qishini xohlaydigan, uning hardening holatini va hali nimaga e’tibor kerakligini umumlashtiradigan bitta jumlani yozing.

Xulosa

Serverni mustahkamlash alohida usul emas — bu modulda ko'rib chiqilgan har bir himoya vositasini intizomli, tartibli qo'llash: hajmni qisqartirish, autentifikatsiyani berkitish, majburiy kirish nazoratini qo'llash, avval kirishni tasdiqlab firewall’ni qo'llash, aniqlash vositalarini qo'shish, yangilanishlarni avtomatlashtirish va natijani lynis kabi vosita bilan mustaqil tekshirish. Tartib muhim, chunki aks holda har bir qadam keyingisiga xalaqit berishi yoki sizni undan qulflab qo'yishi mumkin. Jarayonning o'zi esa tayyorlash paytida bir marta bajarilib unutilmasdan, jadval bo'yicha takrorlanishi kerak.