Language: bg

Сигурност на VPS от нулата: SSH ключове, защитна стена и 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, за да запазите ключа в файла по подразбиране, след което задайте парола за ключа. Никога не изпращайте частния ключ в чат, не го слагайте в хранилище и не го копирайте на VPS. На сървъра трябва да бъде прехвърлен само файлът с разширение .pub:

ssh-copy-id alex@SERVER_IP

Ако ssh-copy-id не е налична, покажете публичния ключ с Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub в PowerShell, след което го добавете на сървъра:

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: такова правило превръща защитната стена във формалност.

Стъпка 5. Активирайте Fail2ban за SSH

Fail2ban анализира логовете и добавя временно блокиращо правило след няколко неуспешни опита за вход. Той не заменя SSH ключовете или защитната стена, но намалява шума от автоматизираните опити за груба сила.

Създайте локална конфигурация, за да не бъдат настройките ви презаписани при актуализация на пакета:

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 в списъка за блокиране. За постоянно изключение използвайте 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 можете сами да изберете операционната система, правилата на защитната стена, метода за достъп, резервните копия и разположението на услугите. За малък уебсайт или API стабилната мрежа, SSD хранилището и конзолата за възстановяване са по-важни от излишъка от виртуални ядра.

Когато стартирате проект на VPS в tropic.host, предварително определете публичните му входни точки: в повечето случаи са достатъчни SSH, HTTP и HTTPS. Дръжте базата данни и контролните панели във вътрешната мрежа. С разрастването на проекта отделни VPS инстанции за приложението, базата данни и мониторинга помагат да изолирате отказите.

Често срещани грешки

• Изключване на паролите преди тест на входа с ключ. Оставете текущата сесия отворена и тествайте новия вход отделно.
• Оставяне на 22/tcp отворен за целия свят, когато може да бъде разрешен само от доверени адреси.
• Директно публикуване на Docker портове. Първо проверете правилата на Docker и UFW.
• Инсталиране на Fail2ban и повече непроверяване на логовете. След промените прегледайте journalctl -u ssh и състоянието на jail-а.

Заключение

Базовата защита на VPS не отнема много време, когато стъпките се изпълняват в правилния ред: създайте отделен потребител, инсталирайте SSH ключ, проверете достъпа, изключете входа като root и паролите, активирайте UFW, настройте Fail2ban и включете автоматичните актуализации. След това добавете резервни копия, логване и външен мониторинг.

Тези стъпки не правят сървъра неуязвим, но премахват най-честите грешки при първоначалната конфигурация. Следващата стъпка е да адаптирате профила за сигурност към конкретното приложение: актуализирайте зависимостите, ограничете разрешенията на услугите, защитете административните панели и редовно проверявайте отворените портове.

FAQ

Трябва ли да променя стандартния SSH порт?

Не е задължително. Преместването на порта намалява автоматизирания шум, но не заменя ключовете, изключените пароли, UFW или Fail2ban. Ако промените порта, актуализирайте правилото на защитната стена и параметъра port в jail-а на Fail2ban.

Какво да направя, ако загубя достъп след настройване на UFW?

Използвайте уеб или rescue конзолата на доставчика, след което проверете правилото за SSH и конфигурацията на sshd. Не затваряйте старата работеща сесия, докато не потвърдите новия вход.

Достатъчен ли е Fail2ban за защита на SSH?

Не. Fail2ban реагира на вече настъпили неуспешни входове. Основата трябва да бъде SSH ключове, изключено удостоверяване с парола, минимални потребителски разрешения и ограничена защитна стена.

Мога ли да разреша SSH само от един IP адрес?

Да, ако адресът е постоянен: добавете UFW правило allow from за този IP. Предварително осигурете достъп до конзолата на доставчика или друг резервен начин, защото връзката ще бъде блокирана след промяна на IP адреса.

Колко често трябва да проверявам сигурността на VPS?

След всяка промяна по SSH, защитната стена или публикуването на Docker портове направете проверка на портовете и тествайте входа. Като редовна поддръжка преглеждайте актуализациите и логовете поне веднъж седмично и редовно тествайте възстановяването от резервно копие.