Language: ka

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-პროქსის გამოყენება და შიდა პორტის დამალვა.

ნაბიჯი 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. პირადი გასაღები არასდროს გაგზავნოთ ჩატში, არ განათავსოთ რეპოზიტორიაში და 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-კლიენტი გასაღებს ვერ პოულობს, მიუთითეთ ის ცალსახად: 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-ის ქსელური წესების მოსახერხებელი გარსია. ჯერ უსაფრთხო ნაგულისხმევი წესები დააყენეთ, შემდეგ კი დაუშვით 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-ისა და პროვაიდერის კონსოლზე წვდომის შემთხვევაში გამოიყენეთ: მისამართის შეცვლისას საკუთარ თავს გარეთ ჩაიკეტავთ.

როგორ გავხსნათ აპლიკაციის პორტი დროებით

თუ სერვისის პირდაპირ შემოწმება გჭირდებათ, შეზღუდული წყაროს მისამართით შექმენით წესი:

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 ლოგებს აანალიზებს და რამდენიმე წარუმატებელი შესვლის მცდელობის შემდეგ დროებით ბლოკირების წესს ამატებს. ის 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. ჩართეთ ავტომატური განახლებები

ავტომატური განახლებები უსაფრთხოების პაკეტებისთვის სასარგებლოა, თუმცა ბირთვის გადატვირთვები მაინც სამართავია:

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, მაგრამ დაასკანერეთ მხოლოდ საკუთარი სერვერი: სხვისი ინფრასტრუქტურის ნებართვის გარეშე შემოწმებამ შეიძლება კანონი და პროვაიდერის წესები დაარღვიოს.

სარეზერვო ასლები და აღდგენა

SSH-ის დაცვა წაშლილი მონაცემებისგან, ადმინისტრატორის შეცდომისგან ან გატეხილი აპლიკაციისგან არ იცავს. მონაცემთა ბაზის, კონფიგურაციისა და მომხმარებლის ფაილების ასლები VPS-ისგან ცალკე შეინახეთ. მინიმალური სქემაა ყოველდღიური სარეზერვო ასლი, წინა დღეების რამდენიმე ვერსია და აღდგენის პერიოდული ტესტები.

პაროლები და ტოკენები ღია ტექსტის სკრიპტებში არ ჩაწეროთ. თუ საიდუმლო გამჟღავნდა, დაუყოვნებლივ გააუქმეთ ის და ახალი შექმენით.

როგორ ავირჩიოთ VPS დაცული პროექტისთვის

უსაფრთხოება ინფრასტრუქტურაზე კონტროლით იწყება. VPS-ზე თავად ირჩევთ ოპერაციულ სისტემას, firewall-ის წესებს, წვდომის მეთოდს, სარეზერვო ასლებსა და სერვისების განთავსებას. მცირე ვებსაიტის ან API-ისთვის სტაბილური ქსელი, SSD-საცავი და აღდგენის კონსოლი ვირტუალური ბირთვების სიჭარბეზე მნიშვნელოვანია.

როცა პროექტს tropic.host-ის VPS-ზე უშვებთ, წინასწარ განსაზღვრეთ მისი საჯარო წვდომის წერტილები: უმეტეს შემთხვევაში საკმარისია SSH, HTTP და HTTPS. მონაცემთა ბაზა და მართვის პანელები შიდა ქსელში დატოვეთ. პროექტის ზრდასთან ერთად ცალკე VPS-ინსტანციები აპლიკაციისთვის, მონაცემთა ბაზისა და მონიტორინგისთვის ხელს უწყობს მარცხის ზონების იზოლირებას.

გავრცელებული შეცდომები

• პაროლების გათიშვა გასაღებით შესვლის გამოცდამდე. მიმდინარე სესია ღია დატოვეთ და ახალი შესვლა ცალკე შეამოწმეთ.
• 22/tcp-ის მთელი მსოფლიოსთვის ღია დატოვება, როცა მისი დაშვება მხოლოდ სანდო მისამართებიდან შეიძლებოდა.
• Docker-ის პორტების პირდაპირ გამოქვეყნება. ჯერ Docker-ისა და UFW-ის წესები შეამოწმეთ.
• Fail2ban-ის დაყენება და ლოგების აღარასდროს შემოწმება. ცვლილებების შემდეგ გადაამოწმეთ journalctl -u ssh და jail-ის სტატუსი.

დასკვნა

VPS-ის საბაზისო დაცვას დიდი დრო არ სჭირდება, თუ ნაბიჯებს სწორი თანმიმდევრობით შეასრულებთ: შექმენით ცალკე მომხმარებელი, დააყენეთ SSH-გასაღები, დაადასტურეთ წვდომა, გათიშეთ root-ით შესვლა და პაროლები, ჩართეთ UFW, მოაწესრიგეთ Fail2ban და დააყენეთ ავტომატური განახლებები. შემდეგ დაამატეთ სარეზერვო ასლები, ლოგირება და გარე მონიტორინგი.

ეს ნაბიჯები სერვერს დაუცველს არ გახდის, თუმცა საწყისი კონფიგურაციის ყველაზე გავრცელებულ შეცდომებს აღმოფხვრის. შემდეგი ნაბიჯია უსაფრთხოების პროფილის კონკრეტულ აპლიკაციაზე მორგება: განაახლეთ დამოკიდებულებები, შეზღუდეთ სერვისების უფლებები, დაიცავით ადმინისტრაციული პანელები და რეგულარულად შეამოწმეთ ღია პორტები.

FAQ

საჭიროა ნაგულისხმევი SSH-პორტის შეცვლა?

აუცილებელი არ არის. პორტის შეცვლა ავტომატურ ხმაურს ამცირებს, მაგრამ გასაღებებს, გათიშულ პაროლებს, UFW-ს ან Fail2ban-ს ვერ ანაცვლებს. თუ პორტს შეცვლით, განაახლეთ firewall-ის წესი და Fail2ban-ის jail-ში port პარამეტრი.

რა გავაკეთო, თუ UFW-ის კონფიგურაციის შემდეგ წვდომა დავკარგე?

გამოიყენეთ პროვაიდერის ვებ ან rescue-კონსოლი, შემდეგ შეამოწმეთ SSH-ის წესი და sshd-ის კონფიგურაცია. ძველი მოქმედი სესია არ დახუროთ, სანამ ახალი შესვლა დადასტურებული არ იქნება.

საკმარისია Fail2ban SSH-ის დასაცავად?

არა. Fail2ban იმ შესვლის წარუმატებელ მცდელობებზე რეაგირებს, რომლებიც უკვე მოხდა. საფუძველი უნდა იყოს SSH-გასაღებები, პაროლით ავთენტიფიკაციის გათიშვა, მომხმარებლის მინიმალური უფლებები და შეზღუდული firewall.

შემიძლია SSH მხოლოდ ერთი IP-მისამართიდან დავუშვა?

დიახ, თუ მისამართი მუდმივია: დაამატეთ UFW-ის allow from წესი ამ IP-სთვის. წინასწარ მოაწყვეთ პროვაიდერის კონსოლზე წვდომა ან სხვა სათადარიგო გზა, რადგან IP-ის შეცვლის შემდეგ კავშირი დაიბლოკება.

რამდენად ხშირად უნდა შევამოწმო VPS-ის უსაფრთხოება?

SSH-ის, firewall-ის ან Docker-ის პორტების გამოქვეყნების ყოველი ცვლილების შემდეგ გაუშვით პორტების შემოწმება და გამოცადეთ შესვლა. რუტინული მოვლისას განახლებები და ლოგები კვირაში ერთხელ მაინც გადახედეთ, ხოლო სარეზერვო ასლიდან აღდგენა რეგულარულად გამოცადეთ.