Безпека 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 недоступний, покажіть публічний ключ командою 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: таке правило перетворює 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-адресу до списку блокування. Для постійного винятку використовуйте 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 і консоль відновлення важливіші за надлишок віртуальних ядер.

Запускаючи проєкт на VPS у tropic.host, заздалегідь визначте його публічні точки входу: у більшості випадків достатньо SSH, HTTP і HTTPS. Базу даних і панелі керування тримайте у внутрішній мережі. У міру зростання проєкту окремі VPS для застосунку, бази даних і моніторингу допоможуть ізолювати домени відмови.

Поширені помилки

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

Висновок

Базовий захист VPS не займає багато часу, якщо виконувати кроки в правильному порядку: створити окремого користувача, встановити SSH-ключ, перевірити доступ, вимкнути вхід root і паролі, увімкнути UFW, налаштувати Fail2ban і автоматичні оновлення. Потім додайте резервні копії, журналювання та зовнішній моніторинг.

Ці кроки не роблять сервер невразливим, але усувають найпоширеніші помилки початкової конфігурації. Наступний крок — адаптувати профіль безпеки до конкретного застосунку: оновлювати залежності, обмежувати права сервісів, захищати панелі адміністрування та регулярно перевіряти відкриті порти.

Поширені запитання

Чи потрібно змінювати стандартний порт SSH?

Не обов'язково. Перенесення порту зменшує автоматичний шум, але не замінює ключі, вимкнені паролі, UFW або Fail2ban. Якщо ви змінюєте порт, оновіть правило firewall і параметр port у jail Fail2ban.

Що робити, якщо після налаштування UFW втрачено доступ?

Скористайтеся вебконсоллю або rescue console провайдера, а потім перевірте правило SSH і конфігурацію sshd. Не закривайте стару робочу сесію, доки не підтвердите новий вхід.

Чи достатньо Fail2ban для захисту SSH?

Ні. Fail2ban реагує на невдалі входи, які вже відбулися. Основою мають бути SSH-ключі, вимкнена автентифікація паролем, мінімальні права користувачів і обмежений firewall.

Чи можна дозволити SSH лише з однієї IP-адреси?

Так, якщо адреса постійна: додайте правило UFW allow from для цієї IP. Заздалегідь забезпечте доступ до консолі провайдера або інший резервний шлях, оскільки після зміни адреси з'єднання буде заблоковано.

Як часто перевіряти безпеку VPS?

Після кожної зміни SSH, firewall або публікації Docker-порту запускайте перевірку портів і тестуйте вхід. У межах регулярного обслуговування переглядайте оновлення та журнали щонайменше раз на тиждень, а відновлення резервних копій перевіряйте регулярно.