Yangi VPS qo'lga tegdi: birinchi soatda qilinadigan ishlar

Server sotib oldingiz, pochtangizga IP manzil va root parol keldi. Ko'pchilik shu zahoti loyihasini yuklashga oshiqadi, sozlashni esa "keyin qilamiz" deb qoldiradi. Keyin esa hech qachon kelmaydi — server yillab root paroli bilan, firewall'siz ishlab yuraveradi. Internetga ochilgan har qanday server esa birinchi daqiqadanoq skanerlar nishoniga aylanadi: log'ni ochsangiz, tanimagan IP'lar parol terib ko'rayotganini o'z ko'zingiz bilan ko'rasiz.

Shuning uchun kelishib olaylik: loyiha serverga birinchi soatdan keyin chiqadi. Avval quyidagi beshta ish qilinadi. Men bularni o'z serverlarimda necha marta takrorlaganman, tartib ham shunga yarasha joylashgan — har qadam keyingisiga zamin tayyorlaydi. Misollar Ubuntu 24.04 uchun, boshqa distributivlarda buyruqlar ozgina farq qilishi mumkin.

1-qadam: yangilash va vaqt mintaqasi#

Birinchi ulanish hali root bilan bo'ladi — boshqa foydalanuvchi yo'q:

ssh root@SERVER_IP

# paketlarni yangilaymiz — yangi serverda deyarli har doim eskirgan paketlar bo'ladi
apt update && apt upgrade -y

# vaqt mintaqasini to'g'rilaymiz — loglar va cron o'z vaqtida yashasin
timedatectl set-timezone Asia/Tashkent

apt upgrade paytida terminalda ko'k yoki binafsha fonli oyna chiqib, biror sozlama faylini almashtirish yoki qaysi xizmatlarni qayta ishga tushirishni so'rashi mumkin. Tanlovni o'zgartirmay, shunchaki Enter bosing — standart javob (mavjud sozlamani saqlash) yangi server uchun to'g'ri. Yangilanish tugagach ls /var/run/reboot-required fayl borligini ko'rsatsa, yadro yangilangan: reboot qilib, bir daqiqadan keyin qayta ulaning.

Vaqt mintaqasi mayda ishday tuyuladi, lekin keyin log o'qiganda "bu xato soat 3 da bo'lganmi yoki 8 dami" deb bosh qotirmaysiz.

2-qadam: alohida foydalanuvchi#

Root bilan kundalik ishlash — xatoning bir buyruqlik masofasida yurish degani. Bitta noto'g'ri rm yoki xatolik bilan qo'yilgan probel butun tizimni olib ketishi mumkin, chunki root'dan hech kim ruxsat so'ramaydi. O'zimizga oddiy foydalanuvchi ochamiz va kerak bo'lganda sudo bilan ko'tarilamiz:

adduser deploy            # parol so'raydi — kuchli parol qo'ying
usermod -aG sudo deploy   # sudo guruhiga qo'shamiz

adduser paroldan keyin to'liq ism, xona raqami kabi ma'lumotlarni ham so'raydi — ularni Enter bilan o'tkazib, oxirida Y deysiz.

Endi tekshirib ko'ramiz — yangi terminalda:

ssh deploy@SERVER_IP
sudo whoami   # parol so'raydi, javob: root

Agar ssh deploy@... parol so'ramay Permission denied (publickey) bilan rad etilsa, provayder serverni SSH kalit bilan yaratgan va parol bilan kirish boshidanoq o'chiq. Bunda root'ning kalitini deploy'ga ko'chirib qo'yamiz (root sessiyasida), keyingi qadamdagi ssh-copy-id esa kerak bo'lmaydi:

rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

3-qadam: SSH kalit va parolni butunlay o'chirish#

Parol bilan kirish qulay, lekin parolni terib topish mumkin — butun dunyo bo'ylab botlar kechayu kunduz shu ish bilan band. SSH kalit esa amalda terib topilmaydi. Kalitni o'z kompyuteringizda yasab, serverga ko'chiramiz:

# o'z kompyuteringizda (agar kalitingiz hali bo'lmasa):
ssh-keygen -t ed25519 -C "deploy uchun"

# public key'ni serverdagi deploy foydalanuvchisiga yuboramiz:
ssh-copy-id deploy@SERVER_IP

# tekshiramiz — endi parol so'ramasligi kerak:
ssh deploy@SERVER_IP

Kalit ishlayotganiga to'liq ishonch hosil qilgach, parol bilan kirishni va root'ning SSH orqali kirishini o'chiramiz. Bu ikkisi yangi serverdagi eng katta ikki eshikni yopadi:

Sozlamani asosiy /etc/ssh/sshd_config ga emas, alohida faylga yozamiz. Sababi bor: Ubuntu 24.04 da asosiy fayl boshida Include /etc/ssh/sshd_config.d/*.conf qatori turadi va ko'p VPS obrazlarida u yerda 50-cloud-init.conf fayli PasswordAuthentication yes bilan yotadi. sshd har sozlamaning birinchi uchragan qiymatini oladi — asosiy faylga no yozsangiz ham, parol bilan kirish jimgina ochiq qolaveradi. Nomi 00- bilan boshlangan fayl hammasidan oldin o'qiladi:

sudo nano /etc/ssh/sshd_config.d/00-xavfsizlik.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Qayta ishga tushirishdan oldin sintaksisni va sshd amalda qaysi qiymatlarni olishini tekshiramiz:

sudo sshd -t     # hech narsa chiqmasa — sintaksis to'g'ri
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication)'
# permitrootlogin no
# passwordauthentication no
# kbdinteractiveauthentication no

sudo systemctl restart ssh

KbdInteractiveAuthentication — parol so'rashning ikkinchi yo'li; u yoqilgan qolsa, PasswordAuthentication no bo'lsa ham ba'zi tizimlarda parol so'ralishi mumkin.

4-qadam: firewall — faqat kerakli eshiklar#

Serverda qaysi portlar ochiqligini bilmaslik — eng keng tarqalgan holat. Ubuntu'da buning uchun ufw bor, mantiq juda sodda: hammasini yopamiz, keraklisini ochamiz.

sudo ufw default deny incoming    # kiruvchi hamma narsa yopiq
sudo ufw default allow outgoing   # chiquvchi ochiq (apt, API chaqiruvlar...)

sudo ufw allow OpenSSH            # SSH'siz qolib ketmaslik uchun BIRINCHI shu
sudo ufw allow 80/tcp             # http
sudo ufw allow 443/tcp            # https

sudo ufw enable
sudo ufw status

Ro'yxatda uchta qoida ko'rinadi: SSH, 80 va 443 (har biri yana bir marta (v6) belgisi bilan — IPv6 uchun nusxasi). Boshqa hech narsa. Keyinroq biror xizmatga port kerak bo'lsa (masalan tashqi Postgres ulanishi), ongli ravishda ochasiz — "qaysi portim ochiq ekan o'zi" degan savol endi bo'lmaydi.

5-qadam: swap — kichik serverning sug'urtasi#

1-2 GB xotirali arzon VPS'da xotira to'lib qolsa, Linux'ning OOM-killer'i kelib eng "semiz" jarayonni o'ldiradi — odatda bu sizning ilovangiz yoki bazangiz bo'ladi. Swap fayl bunga arzon sug'urta: tezlik pasayadi, lekin jarayonlar tirik qoladi.

Avval serverda swap allaqachon bormi, tekshiramiz — ba'zi provayderlar uni o'zi qo'yib beradi:

swapon --show

Hech narsa chiqmasa — swap yo'q, davom etamiz. /swapfile ko'rinsa, yangisini yaratmang: band fayl ustiga fallocate xato beradi. Uning hajmini SIZE ustunidan ko'ring va yetarli bo'lsa, bu qadamni o'tkazib yuboring.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile          # swap faylni faqat root o'qiy olishi kerak
sudo mkswap /swapfile
sudo swapon /swapfile

# reboot'dan keyin ham ishlashi uchun fstab'ga yozamiz:
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

free -h   # Swap qatorida 2.0Gi ko'rinishi kerak

Shu joyda o'zimning saboqlarimdan biri: yaqinda bir serverda 2021-yildan qolgan 40 MB'lik swap faylni topdim — o'sha paytda test uchun yaratilgan-u, kattalashtirish esdan chiqqan. Server yillab amalda sug'urtasiz ishlagan. Sozlaganda free -h bilan tekshirib qo'yish bir soniya oladi.

Yakuniy tekshiruv#

Birinchi soat tugadi. Endi serverni shu ro'yxat bilan bir aylanib chiqamiz:

# o'z kompyuteringizda:
ssh deploy@SERVER_IP      # kalit bilan kiradi, parol so'ramaydi
ssh root@SERVER_IP        # rad etilishi kerak: Permission denied (publickey)
ssh -o PubkeyAuthentication=no deploy@SERVER_IP   # parol bilan ham rad etilishi kerak

# serverda (deploy sessiyasida):
sudo ufw status           # faqat SSH, 80, 443
free -h                   # swap ko'rinadi
timedatectl               # Asia/Tashkent

Uchinchi buyruq kalitni ataylab ishlatmay, faqat parol bilan kirishga urinadi — parol so'ralsa, parol bilan kirish hali ochiq, 3-qadamdagi sshd -T tekshiruviga qayting.

Hammasi to'g'ri bo'lsa, server loyiha qabul qilishga tayyor. E'tibor bering, hali nginx ham, baza ham, ilova ham yo'q — ular keyingi qismlarning ishi. Lekin ana shu yalang'och holatida ham server endi tasodifiy hujumlarga ochiq emas.

Keyingi qismda serverga birinchi xizmatni joylaymiz: systemd unit'ini chuqur tushunish — web-ilovani xizmat sifatida ishga tushirish, bog'liqliklar va ishga tushish tartibi.