Что сделать в первую очередь на новом VPS?

Зайти по SSH-ключу и отключить вход по паролю. Боты начинают долбить порт 22 перебором паролей через минуты после появления сервера; ключ делает эти попытки бессмысленными. Всё остальное вторично по сравнению с этим.

Нужен ли файрвол, если сервис всего один?

Да. Файрвол (ufw) означает, что снаружи доступны только порты, которые вы явно открыли — и сервис, про который вы забыли, или который открыла зависимость, не торчит наружу молча. Две команды закрывают целый класс ошибок.

Нужен ли fail2ban, если пароль уже отключён?

Опционально, когда ключи обязательны — с выключенным паролем перебор всё равно не сработает. fail2ban в основном чистит шум в логах и рано банит абьюзные IP. Приятно иметь, но не критично на key-only сервере.

Менять ли SSH-порт?

Это косметика — уход с 22 снижает шум от тупых ботов, но не останавливает упорного атакующего. Делайте, если шум раздражает, но не путайте с реальной защитой. Важны ключи + отключённый пароль.

Как держать VPS обновлённым автоматически?

Включите unattended-upgrades (Debian/Ubuntu) — патчи безопасности ставятся сами. Это привычка №1 по ценности после SSH-ключей: большинство взломов — это известный, уже залатанный баг на сервере, который никто не обновлял.

Защита нового VPS: чек-лист, который реально важен

Первые десять минут на свежем VPS тихо решают многое. Новый публичный IP начинают сканировать боты почти сразу — целятся не в вас, просто шарят всё подряд. Ничего не сделать — и вы надеетесь на удачу. Сделать четыре-пять мелочей — и вы закрыли двери, которые реально вышибают. Вот список по приоритету, с командами.

1. SSH-ключи и отключить вход по паролю

Самое важное. Если вы заходите по паролю — то же может и бот, который его подберёт, а пробуют они тысячами в минуту.

С ноутбука, если ключа ещё нет:

ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id root@айпи-сервера

Затем на сервере выключаем пароль:

# /etc/ssh/sshd_config.d/99-hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password

sudo systemctl reload ssh

⚠️ Проверьте вторую SSH-сессию до закрытия первой — если вход по ключу работает, отлично; если нет, у вас остаётся открытая сессия всё починить. Запереть самого себя — классический промах здесь.

2. Файрвол — запрет по умолчанию

Открывайте только то, что нужно. На Ubuntu/Debian:

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH        # или ваш SSH-порт
sudo ufw enable

Теперь случайный сервис не достать снаружи, пока вы его не откроете. Это ловит то, про что вы неизбежно забудете.

Нюанс для NAT-тарифов: ваш SSH приходит на проброшенный порт, не на 22, и произвольные входящие порты не открыть — изоляция делает часть работы за вас. На тарифе с выделенным IP у вас все порты, и файрвол берёт на себя больше.

3. Автоматические обновления безопасности

Большинство взломанных серверов — не хитрые цели, а известный баг, который патч уже починил, на машине, которую никто не обновлял. Сделайте патчинг автоматическим:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Поставил и забыл. Привычка №1 по ценности после SSH-ключей.

4. fail2ban (опционально, но дёшево)

С уже выключенным паролем перебор не победит — так что это про чистку шума и ранний бан абьюзных IP, а не базовую защиту:

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban

Стоит того ради тихих логов; без угрызений пропустите, если держите минимализм.

Что можно пропустить

Смена SSH-порта — режет шум ботов, не останавливает реального атакующего. Косметика. Не путайте с защитой.
Навороченные IDS/SELinux — перебор для односервисной машины под бота или агента. Убывающая отдача.

Честный итог

Если делать одно — делайте SSH-ключи + отключённый пароль. Добавьте файрвол и авто-обновления — и вы закрыли подавляющую часть реального риска меньше чем за десять минут. Всё дальше — шлифовка.

Держите на сервере постоянного агента или бота? Сочетайте это с запуском под systemd, чтобы он переживал перезагрузки и падения, а не только атакующих.