Tropic Host

VPS-ի անվտանգությունը զրոյից․ SSH բանալիներ, firewall և Fail2ban

2 րոպե կարդալ
Tropic
VPS-ի անվտանգությունը զրոյից․ SSH բանալիներ, firewall և Fail2ban

Language: hy

VPS-ի անվտանգությունը զրոյից․ SSH բանալիներ, firewall և Fail2ban

Նոր VPS-ը Ubuntu-ի տեղադրումից անմիջապես հետո անվտանգ համարել չի կարելի։ Մուտքը կարգավորելուց առաջ սերվերն արդեն տեսանելի է սկաներներին․ նրանք փորձում են SSH գաղտնաբառեր, փնտրում են բաց կառավարման վահանակներ և ստուգում տարածված խոցելիությունները։ Այս ուղեցույցում կանցնենք VPS-ը զրոյից պաշտպանելու հիմնական քայլերով՝ առանձին օգտատեր ստեղծել, SSH բանալիով նույնականացում կարգավորել, UFW-ով ցանցային պորտերը սահմանափակել և Fail2ban ավելացնել։ Բոլոր քայլերն աշխատում են Ubuntu 22.04 և 24.04 տարբերակներում, երբ հրամանները կատարվում են sudo արտոնություններով։

Սկսելուց առաջ․ կազմեք պորտերի ցանկ

Մի բացեք պորտեր «ամեն դեպքում»։ Սովորական վեբ-սերվերին անհրաժեշտ են՝

  • 22/tcp — SSH․ ցանկալի է սահմանափակել ըստ IP-ի կամ տեղափոխել այլ պորտ՝ միայն որպես լրացուցիչ միջոց,
  • 80/tcp — HTTP․ սովորաբար պետք է HTTPS-ին ուղղորդելու և վկայականը ստուգելու համար,
  • 443/tcp — HTTPS։

3000, 8080 կամ 9000 պորտերի նման հավելվածային պորտը չպետք է հասանելի լինի ինտերնետից, եթե դրա առջև աշխատում է Nginx կամ Caddy։ Հավելվածը կապեք 127.0.0.1 հասցեին կամ թույլատրեք պորտը միայն ներքին ցանցում։ Նախ պարզեք, թե ինչ է լսում սերվերում՝

sudo ss -tulpn

Docker-ը տեղադրելուց հետո առանձին ստուգեք դրա iptables կանոնները․ -p 3000:3000 հրապարակումը կարող է պորտը բացել սպասված կարգավորումից դուրս։ Հանրային ծառայության համար ավելի անվտանգ է օգտագործել HTTPS proxy և ներքին պորտը թաքցնել։

Քայլ 1․ թարմացրեք համակարգը և ստեղծեք ադմինիստրատոր

Միացեք VPS-ին ստացված տվյալներով և տեղադրեք թարմացումները՝

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ufw fail2ban unattended-upgrades

Ստեղծեք անձնական օգտատեր։ alex-ը փոխարինեք ձեր անունով՝

sudo adduser alex
sudo usermod -aG sudo alex

Մի հեռացրեք սկզբնական մուտքը, քանի դեռ առանձին տերմինալում չեք փորձարկել նոր հաշիվը։ Սա կարևոր կանոն է․ SSH-ի սխալը ավելի հեշտ է ուղղել, քանի դեռ ընթացիկ նիստը բաց է։

Քայլ 2․ ստեղծեք SSH բանալի և տեղադրեք այն սերվերում

Ձեր Linux, macOS կամ Windows PowerShell համակարգչում կատարեք՝

ssh-keygen -t ed25519 -C "alex@my-computer"

Սեղմեք Enter՝ բանալին լռելյայն ֆայլում պահելու համար, ապա սահմանեք passphrase։ Երբեք մի ուղարկեք մասնավոր բանալին չաթով, մի տեղադրեք այն repository-ում և մի պատճենեք VPS։ Սերվեր պետք է փոխանցվի միայն .pub ընդլայնմամբ ֆայլը՝

ssh-copy-id alex@SERVER_IP

Եթե ssh-copy-id հասանելի չէ, հանրային բանալին PowerShell-ում ցուցադրեք Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub հրամանով, ապա ավելացրեք այն սերվերում՝

sudo install -d -m 700 -o alex -g alex /home/alex/.ssh
sudo nano /home/alex/.ssh/authorized_keys
sudo chown alex:alex /home/alex/.ssh/authorized_keys
sudo chmod 600 /home/alex/.ssh/authorized_keys

Բանալին տեղադրեք մեկ տողով և գաղտնաբառերն անջատելուց առաջ ստուգեք մուտքը՝

ssh alex@SERVER_IP
sudo whoami

Վերջին հրամանի ակնկալվող արդյունքը root է։ Եթե SSH client-ը չի գտնում բանալին, այն հստակ նշեք․ ssh -i ~/.ssh/id_ed25519 alex@SERVER_IP։

Քայլ 3․ անջատեք root մուտքը և գաղտնաբառով նույնականացումը

Կատարեք SSH-ի կազմաձևի պահուստավորում՝

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

Համոզվեք, որ ֆայլում կան հետևյալ պարամետրերը՝

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
MaxAuthTries 3

Ubuntu-ում կարգավորումները կարող են գտնվել նաև /etc/ssh/sshd_config.d/*.conf ֆայլերում, ուստի ստուգեք գործող կազմաձևը՝

sudo sshd -t
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|maxauthtries'

Եթե sshd -t սխալ է հայտնում, մի վերագործարկեք ծառայությունը, քանի դեռ շարահյուսությունը չեք ուղղել։ Ստուգումը հաջող լինելուց հետո կիրառեք կարգավորումները՝

sudo systemctl reload ssh

Հին SSH կապը բաց պահեք և նոր պատուհանում ստուգեք բանալիով մուտքը։ Հաստատված բանալի չունենալու դեպքում գաղտնաբառերն անջատելը սերվերի հասանելիությունը կորցնելու ամենատարածված պատճառն է։

Քայլ 4․ կարգավորեք UFW-ն՝ SSH-ը չարգելափակելով

UFW-ն Linux-ի ցանցային կանոնների հարմար wrapper է։ Նախ սահմանեք անվտանգ լռելյայն արժեքները, ապա թույլատրեք SSH և վեբ պորտերը՝

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw enable

Ակտիվացումը հաստատեք միայն SSH կանոնը ավելացնելուց հետո։ Ստուգեք արդյունքը՝

sudo ufw status verbose
sudo ufw status numbered

Մշտական գրասենյակային IP-ի դեպքում կարող եք SSH-ը սահմանափակել այդ հասցեով՝

sudo ufw delete allow 22/tcp
sudo ufw allow from YOUR.PUBLIC.IP to any port 22 proto tcp comment 'SSH office'

Այս տարբերակն օգտագործեք միայն մշտական IP-ի և provider-ի կոնսոլին հասանելիության դեպքում․ հասցեն փոխվելու դեպքում կարող եք ինքներդ ձեզ արգելափակել։

Ինչպես ժամանակավորապես բացել հավելվածային պորտը

Եթե պետք է ծառայությունն ուղղակիորեն ստուգել, ստեղծեք սահմանափակ աղբյուրով կանոն՝

sudo ufw allow from YOUR.PUBLIC.IP to any port 8080 proto tcp

Ստուգումից հետո ջնջեք այն՝ օգտագործելով ufw status numbered-ի ցուցադրած համարը՝

sudo ufw delete RULE_NUMBER

Մի օգտագործեք sudo ufw allow 1:65535/tcp․ այդպիսի կանոնը firewall-ը վերածում է ձևականության։

Քայլ 5․ միացրեք Fail2ban-ը SSH-ի համար

Fail2ban-ը վերլուծում է log-երը և մի քանի ձախողված մուտքից հետո ժամանակավոր արգելափակման կանոն է ավելացնում։ Այն չի փոխարինում SSH բանալիներին կամ firewall-ին, բայց նվազեցնում է ավտոմատ brute-force փորձերի աղմուկը։

Ստեղծեք տեղական կազմաձև, որպեսզի փաթեթների թարմացումները չվերագրեն ձեր կարգավորումները՝

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

[DEFAULT] բաժնում սահմանեք ողջամիտ արժեքներ՝

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
backend = systemd
banaction = ufw

[sshd]
enabled = true
port = 22

Սկսեք ծառայությունը և ստուգեք jail-ը՝

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

sshd ելքում ստուգեք ձախողված փորձերի և արգելափակված հասցեների քանակը։ Ձեր IP-ն մի ավելացրեք ban ցուցակում։ Մշտական բացառության համար ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP-ը օգտագործեք [DEFAULT] բաժնում։

Քայլ 6․ միացրեք ավտոմատ թարմացումները

Ավտոմատ թարմացումները օգտակար են անվտանգության փաթեթների համար, սակայն kernel-ի վերագործարկումները դեռ պետք է կառավարել՝

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades

Շաբաթը մեկ ստուգեք՝ արդյոք վերագործարկում է պահանջվում՝

test -f /var/run/reboot-required && echo 'Требуется перезапуск'

Ձեռքով վերագործարկելուց առաջ համոզվեք, որ աշխատող բանալի և VPS-ի կոնսոլին հասանելիություն ունեք։ Վերագործարկումից հետո ստուգեք հավելվածների ծառայությունները, Nginx-ը, UFW-ն և Fail2ban-ը։

Քայլ 7․ ստուգեք արդյունքը դրսից

Պաշտպանությունը ստուգեք մեկ այլ համակարգչից, ոչ միայն կազմաձևը կարդալով՝

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no alex@SERVER_IP

Հրամանը պետք է ավարտվի մերժմամբ։ Աշխատող բանալիով մուտքը ստուգեք առանձին՝

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 alex@SERVER_IP

VPS-ում ստուգեք լսող հասցեներն ու կանոնները՝

sudo ss -lntup
sudo ufw status numbered
sudo fail2ban-client status sshd

Եթե հավելվածային պորտը նախատեսված չէ ուղղակի հասանելիության համար, այն պետք է լսի 127.0.0.1 հասցեի վրա։ Արտաքին համակարգչից կարող եք օգտագործել nmap SERVER_IP, բայց սկանավորեք միայն ձեր սերվերը․ ուրիշի ենթակառուցվածքը առանց թույլտվության ստուգելը կարող է խախտել օրենքը և provider-ի կանոնները։

Պահուստավորում և վերականգնում

SSH-ի պաշտպանությունը չի պաշտպանում ջնջված տվյալներից, ադմինիստրատորի սխալից կամ վարակված հավելվածից։ Տվյալների բազայի, կազմաձևի և օգտատիրոջ ֆայլերի պատճենները պահեք VPS-ից առանձին։ Նվազագույն տարբերակն է ամենօրյա պահուստավորումը, նախորդ օրերի մի քանի տարբերակ և պարբերական վերականգնման փորձարկումներ։

Գաղտնաբառերն ու token-ները մի գրեք պարզ տեքստով script-երում։ Գաղտնիքի բացահայտման դեպքում անմիջապես չեղարկեք այն և ստեղծեք նորը։

Ինչպես ընտրել VPS անվտանգ նախագծի համար

Անվտանգությունը սկսվում է ենթակառուցվածքի նկատմամբ վերահսկողությունից։ VPS-ում ինքներդ եք ընտրում օպերացիոն համակարգը, firewall-ի կանոնները, մուտքի եղանակը, պահուստավորումը և ծառայությունների տեղադրումը։ Փոքր կայքի կամ API-ի համար կայուն ցանցը, SSD պահեստը և վերականգնման կոնսոլը ավելի կարևոր են, քան վիրտուալ միջուկների ավելցուկը։

Նախագիծը tropic.host VPS-ում գործարկելիս նախապես որոշեք դրա հանրային մուտքի կետերը․ շատ դեպքերում SSH, HTTP և HTTPS-ը բավական են։ Տվյալների բազան և կառավարման վահանակները պահեք ներքին ցանցում։ Նախագծի աճին զուգընթաց առանձին VPS-երը հավելվածի, տվյալների բազայի և մոնիտորինգի համար օգնում են մեկուսացնել խափանման տիրույթները։

Տարածված սխալներ

  • Գաղտնաբառերն անջատել նախքան բանալիով մուտքը ստուգելը։ Ընթացիկ նիստը բաց պահեք և նոր մուտքը փորձարկեք առանձին։
  • 22/tcp-ը թողնել ամբողջ աշխարհի համար բաց, երբ այն կարելի էր թույլատրել միայն վստահելի հասցեներից։
  • Docker-ի պորտերը ուղղակիորեն հրապարակել։ Նախ ստուգեք Docker-ի և UFW-ի կանոնները։
  • Տեղադրել Fail2ban և այլևս չստուգել log-երը։ Փոփոխություններից հետո վերանայեք journalctl -u ssh-ը և jail-ի վիճակը։

Եզրակացություն

VPS-ի հիմնական պաշտպանությունը շատ ժամանակ չի պահանջում, եթե քայլերը կատարվում են ճիշտ հերթականությամբ․ ստեղծեք առանձին օգտատեր, տեղադրեք SSH բանալի, ստուգեք մուտքը, անջատեք root մուտքն ու գաղտնաբառերը, միացրեք UFW-ն, կարգավորեք Fail2ban-ը և միացրեք ավտոմատ թարմացումները։ Այնուհետև ավելացրեք պահուստավորումը, log-ավորումն ու արտաքին մոնիտորինգը։

Այս քայլերը սերվերը անխոցելի չեն դարձնում, բայց վերացնում են սկզբնական կազմաձևի ամենատարածված սխալները։ Հաջորդ փուլը անվտանգության պրոֆիլը կոնկրետ հավելվածին հարմարեցնելն է․ թարմացրեք կախվածությունները, սահմանափակեք ծառայությունների իրավունքները, պաշտպանեք ադմինիստրատիվ վահանակները և պարբերաբար ստուգեք բաց պորտերը։

FAQ

Պե՞տք է փոխել SSH-ի լռելյայն պորտը

Պարտադիր չէ։ Պորտը տեղափոխելը նվազեցնում է ավտոմատ աղմուկը, բայց չի փոխարինում բանալիներին, անջատված գաղտնաբառերին, UFW-ին կամ Fail2ban-ին։ Եթե փոխեք պորտը, թարմացրեք firewall-ի կանոնը և port պարամետրը Fail2ban-ի jail-ում։

Ի՞նչ անել, եթե UFW-ի կարգավորումից հետո կորցրել եմ մուտքը

Օգտագործեք provider-ի վեբ կամ rescue կոնսոլը, ապա ստուգեք SSH-ի կանոնն ու sshd-ի կազմաձևը։ Հին աշխատող նիստը մի փակեք, քանի դեռ նոր մուտքը հաստատված չէ։

Fail2ban-ը բավարար է SSH-ը պաշտպանելու համար

Ոչ։ Fail2ban-ը արձագանքում է արդեն տեղի ունեցած մուտքի ձախողումներին։ Հիմքը պետք է լինեն SSH բանալիները, գաղտնաբառով նույնականացման անջատումը, նվազագույն օգտատիրոջ իրավունքները և սահմանափակ firewall-ը։

Կարո՞ղ եմ SSH-ը թույլատրել միայն մեկ IP հասցեից

Այո, եթե հասցեն մշտական է․ այդ IP-ի համար ավելացրեք UFW-ի allow from կանոնը։ Նախապես ապահովեք provider-ի կոնսոլի կամ այլ պահուստային մուտք, քանի որ IP-ի փոփոխությունից հետո կապը կարգելափակվի։

Որքա՞ն հաճախ պետք է ստուգել VPS-ի անվտանգությունը

SSH-ի, firewall-ի կամ Docker պորտերի հրապարակման յուրաքանչյուր փոփոխությունից հետո կատարեք պորտերի ստուգում և փորձարկեք մուտքը։ Ընթացիկ սպասարկման ժամանակ առնվազն շաբաթը մեկ վերանայեք թարմացումներն ու log-երը և պարբերաբար ստուգեք պահուստից վերականգնումը։