SSH hardening

Bu modulda avvalroq alohida ko'rib chiqilgan bir nechta mavzu — kalit autentifikatsiyasi (SSH kalit autentifikatsiyasi), root login’ini cheklash (SSH konfiguratsiyasi) va host shaxsini tekshirish (SSH-agent va host tekshiruvi) — har biri production serverni himoyalashning bir bo'lagi. Bu maqola ularni bitta izchil hardening (kuchaytirish) yondashuviga birlashtiradi va faqat shu umumiy kontekstda ma’noga ega bo'lgan bir nechta sozlamani qo'shadi.

Nega sukut bo'yicha konfiguratsiya yetarli emas

Internetga ochiq har qanday IP manzildagi 22-port avtomatlashtirilgan botlar tomonidan doimiy skanerlanadi; ular keng tarqalgan foydalanuvchi nomlarini (root, admin, test) parol taxminlari bilan sinab ko'radi. Bu maqsadli hujum emas — bu uzluksiz fon shovqini va har qanday yangi yaratilgan server bu skanerlash trafigini bir necha daqiqa ichida his qiladi. Sukut bo'yicha OpenSSH konfiguratsiyasi — parol bilan kirish yoqilgan, root kirishiga ruxsat berilgan — bunday muhitda ancha yumshoq nishon.

Hardening bitta "sehrli" sozlama emas; bu bir nechta mustaqil himoyani bir-birining ustiga qatlamlash — defense in depth (chuqur himoya): har biri o'z holicha oddiy, lekin birgalikda hujum yuzasini sezilarli kamaytiradi.

Asosiy tekshiruv ro'yxati

1. Faqat kalit autentifikatsiyasiga o'tish

SSH kalit autentifikatsiyasi maqolasida ko'rilganidek, kirishi kerak bo'lgan har bir foydalanuvchi uchun avval kalit sozlanadi va faqat shundan keyin parol bilan kirish butunlay o'chiriladi:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

KbdInteractiveAuthentication no ayrim tizimlarda PasswordAuthentication o'chirilgandan keyin ham boshqa kod yo'li orqali parolga o'xshash so'rovni ochiq qoldirishi mumkin bo'lgan mexanizmni yopadi.

2. To'g'ridan-to'g'ri root kirishini butunlay o'chirish

PermitRootLogin no

Ma’muriy vazifalar oddiy foydalanuvchi va sudo orqali bajariladi — bu Root va sudo maqolasidagi eng kam huquq tamoyilining amaliy qo'llanishi bo'lib, auditni ham ta’minlaydi: har bir ma’muriy amal umumiy root identifikatsiyasi ostida emas, sudo log'ida muayyan foydalanuvchi nomi bilan qayd qilinadi.

3. Kirishni muayyan foydalanuvchilar bilan cheklash

AllowUsers alice deploy

yoki guruh darajasida:

AllowGroups sshusers

Bu tizimda mavjud, lekin SSH’ga qonuniy ehtiyoji bo'lmagan xizmat hisoblari (www-data, postgres va shunga o'xshashlar) uchun himoya qatlamini qo'shadi: ular qandaydir yo'l bilan mos kalitga ega bo'lsa ham kira olmaydi, chunki shunchaki ro'yxatda yo'q.

4. Autentifikatsiya urinishlarini cheklash

MaxAuthTries 3
LoginGraceTime 30

• MaxAuthTries — bitta ulanish ichida nechta muvaffaqiyatsiz autentifikatsiya urinishiga ruxsat berilishi;
• LoginGraceTime — ulanish autentifikatsiyani yakunlashi uchun qancha vaqt (soniyalarda) borligi; undan oshsa, ulanish avtomatik uziladi va harakatsiz, yarim ochiq ulanishlar resurslarni band qilishining oldi olinadi.

5. Harakatsiz sessiyalarni avtomatik uzish

ClientAliveInterval 300
ClientAliveCountMax 2

Server har 300 soniyada klientdan javob so'raydi; ketma-ket ikki tekshiruvga javob kelmasa, sessiya uziladi. Bu unutilgan, hali ochiq turgan terminal sessiyasining cheksiz qolib ketishining oldini oladi.

6. Portni o'zgartirish — u nima qiladi va nima qilmaydi

Port 2222

Portni o'zgartirish firewall qoidasini ham yangilashni talab qiladi — bu Firewall va UFW maqolasida ko'rilgan mantiqning to'g'ridan-to'g'ri davomi:

sudo ufw allow 2222/tcp
sudo ufw delete allow 22/tcp

Kriptografik konfiguratsiyani audit qilish

Yuqoridagi ro'yxat kim kira olishi va necha marta urinishi mumkinligini kuchaytiradi; alohida o'lchov — server qaysi kriptografik algoritmlar bo'yicha kelishishi. Zamonaviy OpenSSH haqiqatan buzilgan algoritmlarni (eski ssh-rsa/SHA-1 imzosi, CBC rejimidagi shifrlar, zaif DH guruhlari) sukut bo'yicha allaqachon o'chirib qo'ygan, shuning uchun joriy Ubuntu/RHEL relizida bu odatda qayta yozish emas, audit vazifasi. Eski blog postidan olingan tasodifiy Ciphers/KexAlgorithms ro'yxatini nusxalash esa serverni eskirgan tanlovlarga bog'lab, ko'pincha uni zaiflashtiradi.

Amaliy yondashuv — avval ssh-audit vositasi bilan o'lchash:

sudo apt install ssh-audit    # or: pipx install ssh-audit
ssh-audit localhost

U server hali ham taklif qilayotgan har qanday zaif key-exchange, cipher, MAC yoki host-key algoritmini belgilaydi va nimani olib tashlashni tavsiya qiladi. Faqat u zaif narsa haqida xabar bersagina, uni aniq cheklaysiz — SSH konfiguratsiyasi maqolasiga mos ravishda drop-in faylda:

# /etc/ssh/sshd_config.d/99-crypto.conf
KexAlgorithms curve25519-sha256,[email protected]
Ciphers [email protected],[email protected]
MACs [email protected],[email protected]

Zaif algoritmlar yo'qolganini va qonuniy hech narsa kesib tashlanmaganini tasdiqlash uchun keyin ssh-audit ni qayta ishga tushiring, so'ng odatdagidek sudo sshd -t va reload qiling.

Fail2ban: takroriy muvaffaqiyatsiz urinishlarni avtomatik to'sish

MaxAuthTries bitta ulanish ichidagi urinishlarni cheklaydi, lekin xuddi shu IP manzil shunchaki yangi ulanish ochib, qayta urinishiga to'sqinlik qilmaydi. Bu vazifa Fail2ban ga tegishli: u SSH log'larini kuzatadi va agar muayyan IP manzil vaqt oralig'ida sozlangan sondan ko'p muvaffaqiyatsiz urinish qilsa, o'sha manzilni firewall darajasida vaqtincha to'sib qo'yadi. Fail2ban’ni o'rnatish va sozlash fail2ban maqolasida alohida ko'rib chiqiladi — SSH hardening uchun muhimi shuki, yuqoridagi kalitga asoslangan autentifikatsiya bilan birga u ruxsat berilmagan kalitlar bilan qayta-qayta sinab ko'rayotgan manzillarni ham avtomatik izolyatsiya qiladi.

Ikki faktorli autentifikatsiya (2FA): qachon kerak

Kalit autentifikatsiyasi allaqachon "sizda bor narsa" — private key fayliga asoslangan kuchli himoyani ta’minlaydi. Lekin ayniqsa yuqori xavfli muhitlarda — moliyaviy ma’lumotlarni saqlaydigan yoki qattiq compliance talablariga bo'ysunadigan serverlarda — buni "siz biladigan narsa" yoki biometrik omil bilan, masalan libpam-google-authenticator orqali TOTP kodi bilan birlashtirish yana bir qatlam qo'shadi. Bu oddiy ichki laboratoriya yoki kichik loyiha uchun talab emas, lekin kattaroq production muhitda standart talab bo'lishi mumkin; haqiqiy ehtiyoj tashkilotning xavfsizlik siyosati va himoya qilinayotgan narsaning maxfiylik darajasiga bog'liq.

Hardening'ni tartib bilan joriy qilish

O'zgarishlar hammasi birdaniga emas, birma-bir qo'llanishi va tasdiqlanishi kerak:

1. kirishi kerak bo'lgan har bir foydalanuvchi uchun kalit autentifikatsiyasini sozlang va tasdiqlang;
2. AllowUsers/AllowGroups bilan kirish qamrovini cheklang, tasdiqlang;
3. PermitRootLogin no ni yoqing, tasdiqlang;
4. PasswordAuthentication no ni yoqing, tasdiqlang;
5. MaxAuthTries, LoginGraceTime, ClientAliveInterval kabi qo'shimcha cheklovlarni qo'shing;
6. (ixtiyoriy) portni o'zgartiring, firewall qoidasini yangilang, tasdiqlang;
7. Fail2ban’ni o'rnating va sozlang.

Har bir qadamdan keyin: sudo sshd -t bilan sintaksisni tekshiring, sudo systemctl reload ssh bilan qayta yuklang va joriy sessiyani yopmasdan yangi terminalda sinab ko'ring — bu SSH konfiguratsiyasi maqolasida batafsil ko'rilgan xavfsiz o'zgartirish tartibi.

Amaliy vaziyat: yangi serverni production’ga tayyorlash

Muammo: yangi yaratilgan Ubuntu Server VM’ida hali ham sukut bo'yicha OpenSSH konfiguratsiyasi turibdi va parol bilan root kirishi yoqilgan; uni ishga tushirishdan oldin kuchaytirish kerak.

1-qadam — joriy holatni qayd qilish:

sudo sshd -T | grep -iE 'permitrootlogin|passwordauthentication|port|allowusers'

2-qadam — ma’muriy foydalanuvchi va uning kalitini sozlash:

sudo adduser deploy
sudo usermod -aG sudo deploy

SSH kalit autentifikatsiyasi maqolasiga ko'ra keyin ssh-copy-id deploy@server ishga tushiriladi va kirish yangi terminalda tasdiqlanadi.

3-qadam — tekshiruv ro'yxatidagi sozlamalarni bosqichma-bosqich qo'llash:

sudo sed -i \
  -e 's/^#*PermitRootLogin.*/PermitRootLogin no/' \
  -e 's/^#*PasswordAuthentication.*/PasswordAuthentication no/' \
  -e 's/^#*MaxAuthTries.*/MaxAuthTries 3/' \
  /etc/ssh/sshd_config
echo "AllowUsers deploy" | sudo tee -a /etc/ssh/sshd_config
sudo sshd -t

4-qadam — qayta yuklash va eski sessiya ochiq turgan holda yangi terminalda sinash:

sudo systemctl reload ssh

ssh deploy@server "whoami && sudo -l"
ssh root@server

root@server Permission denied qaytarishi, deploy esa muvaffaqiyatli kirib, sudo dan foydalana olishi kerak.

5-qadam — Fail2ban’ni o'rnatish (fail2ban maqolasida batafsil ko'rib chiqiladi):

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

6-qadam — yakuniy tasdiqlash va hujjatlashtirish:

sudo sshd -T | grep -iE 'permitrootlogin|passwordauthentication|maxauthtries|allowusers'
sudo fail2ban-client status sshd

Qaysi sozlamalar, qachon va kim tomonidan qo'llanganini qayd qiling — bu kelajakdagi audit yoki hodisani tekshirish uchun foydali.

Keng tarqalgan xatolar

Barcha o'zgarishlarni sinamasdan birdaniga qo'llash

Kalit autentifikatsiyasi haqiqatan tekshirilmasdan oldin PasswordAuthentication no va PermitRootLogin no ni bitta o'tishda yoqish serverga kirish imkonini butunlay yo'qotish xavfini keskin oshiradi.

O'zgartirilgan portni yagona himoya deb hisoblash

Yuqorida ta’kidlanganidek, bu faqat shovqinni kamaytiradi; u haqiqiy autentifikatsiya kuchini oshirmaydi.

Kalit autentifikatsiyasisiz Fail2ban’dan yagona himoya sifatida foydalanish

Fail2ban parolga asoslangan brute-force’ni sekinlashtiradi, lekin parollar hali ham yoqilgan bo'lsa, yetarli vaqt va turli IP manzillar bilan haqiqiy xavf saqlanib qoladi. Fail2ban kalit autentifikatsiyasining o'rnini bosuvchi emas, qo'shimcha qatlam.

Hardening'dan keyin zaxira kirish yo'lini tekshirmaslik

Agar biror sababga ko'ra (masalan, noto'g'ri sozlangan firewall qoidasi tufayli) SSH orqali kirishning barcha yo'llari ishlamay qolsa, hosting provayderining konsoli yoki rescue mode kabi muqobil kirish yo'li bor-yo'qligini oldindan bilishga arziydi.

Mashqlar

1. Yuqoridagi tekshiruv ro'yxatini laboratoriya serverida bosqichma-bosqich qo'llang va har bir qadamdan keyin yangi terminalda tekshiring.
2. Hardening'dan oldingi va keyingi sudo sshd -T chiqishlarini solishtiring va qaysi qiymatlar o'zgarganini jadval ko'rinishida yozing.
3. Sinov uchun MaxAuthTries 2 ni o'rnating, so'ng ataylab uch marta noto'g'ri kalit bilan ulanishga urinib, ulanish qanday uzilishini kuzating.
4. fail2ban maqolasiga ko'ra uni o'rnating, holatni fail2ban-client status sshd bilan tasdiqlang, so'ng ataylab bir necha marta parol bilan kirishni muvaffaqiyatsiz qiling (agar hali yoqilgan bo'lsa) va IP manzilingiz vaqtincha to'silishini kuzating.

Mashqni bajardim deyish uchun: 1-mashqdagi yakuniy holat PermitRootLogin no va PasswordAuthentication no ni ko'rsatishi, belgilangan root bo'lmagan foydalanuvchi esa kalit bilan kira olishi va sudo dan foydalana olishi kerak — bu birikmaning biror qismi yetishmasa, joriy qilish to'g'ri yakunlanmagan.

Yakun

SSH hardening — bitta sozlama emas: u kalit autentifikatsiyasi, cheklangan kirish qamrovi, root ni o'chirish, urinishlarni cheklash va Fail2ban kabi vositalarning bir-biri ustiga qatlamlanishi. Har bir qatlam o'z holicha oddiy, lekin birgalikda ular serverni ko'p avtomatlashtirilgan, ommaviy hujumlardan va maqsadli urinishlarning ham sezilarli qismidan himoya qiladi. Bu bilan SSH va masofaviy boshqaruv moduli yakunlanadi — keyingi modul Linux saqlash qatlamiga o'tadi va Disklar va block qurilmalar maqolasidan boshlanadi.

Manbalar

• man7.org: sshd_config(5)
• OpenSSH — serveringizni himoyalash
• Ubuntu Server — OpenSSH: hardening
• NIST SP 800-123 — Guide to General Server Security
• Fail2ban — rasmiy hujjatlar