Безопасность 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, но уменьшает шум от автоматических переборов.

Создайте локальную конфигурацию, чтобы обновление пакета не перезаписало настройки:

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 в бан-лист. Для постоянного исключения используйте в [DEFAULT] параметр ignoreip = 127.0.0.1/8 YOUR.PUBLIC.IP.

Шаг 6. Включите автоматические обновления

Автоматические обновления полезны для security-пакетов, но перезапуск ядра всё равно нужно контролировать:

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 и автоматические обновления. Затем добавьте резервные копии, журналирование и внешний мониторинг.

Эти шаги не делают сервер неуязвимым, но закрывают самые распространённые ошибки начальной настройки. Дальше профиль нужно адаптировать к конкретному приложению: обновлять зависимости, ограничивать права сервисов, защищать админ-панели и регулярно проверять открытые порты.

FAQ

Нужно ли менять стандартный порт SSH?

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

Что делать, если я потерял доступ после настройки UFW?

Используйте веб-консоль или rescue-консоль провайдера, проверьте правило SSH и конфигурацию sshd. Не удаляйте старый рабочий сеанс, пока новый вход не подтверждён.

Достаточно ли Fail2ban для защиты SSH?

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

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

Да, если адрес постоянный: добавьте в UFW правило allow from для этого IP. Заранее предусмотрите консоль провайдера или запасной доступ, потому что после смены IP подключение будет заблокировано.

Как часто нужно проверять безопасность VPS?

После каждого изменения SSH, firewall или Docker-публикации запускайте проверку портов и тест входа. Планово просматривайте обновления и журналы хотя бы раз в неделю, а резервное восстановление выполняйте регулярно.