Укрепление нового VPS
Ответ
Укрепление нового VPS занимает около двадцати минут: отключите вход по паролю и под root, включите аутентификацию только по ключам, настройте nftables на запрет входящих по умолчанию, включите автоматические обновления безопасности и установите fail2ban. Эти пять шагов устраняют подавляющее большинство реальных компрометаций.
Что на самом деле компрометирует серверы
Не zero-day. На практике: перебор паролей SSH против слабых учетных данных, незапатченные сервисы, работающие месяцами, открытые админ-панели с паролями по умолчанию и уязвимости приложений, установленных оператором. Список скучен и не менялся пятнадцать лет.
Чек-лист ниже упорядочен по тому, сколько риска устраняет каждый шаг на потраченную минуту. Делайте их по порядку и остановитесь, когда закончится терпение, — вы все равно устраните большую часть риска.
Шаг 1 — только ключи SSH
Это единственное изменение полностью устраняет наиболее распространённую атаку. Сгенерируйте ключ Ed25519, скопируйте его открытую часть на сервер, затем отредактируйте /etc/ssh/sshd_config, установив PasswordAuthentication no, PermitRootLogin prohibit-password и KbdInteractiveAuthentication no.
Проверьте ключ во втором терминале, прежде чем закрывать первый. Запереть себя снаружи — неловко, и на машине с консольным доступом это полностью поправимо, но лучше соблюдать правильный порядок.
Шаг 2 — межсетевой экран с запретом по умолчанию
nftables на современных Debian и Ubuntu, или firewalld на производных RHEL. Запретить входящие по умолчанию, разрешить установленные и связанные соединения, разрешить ваш SSH-порт, разрешить то, что действительно нужно рабочей нагрузке, и ничего больше.
Важная дисциплина — «ничего больше» и есть суть. Межсетевой экран с разрешающим правилом, добавленным при отладке и не удалённым, — это экран, который ничего не делает.
- Политика по умолчанию: сбрасывать входящие, принимать исходящие
- Принимать установленные и связанные
- Принимать loopback
- Принимать ваш SSH-порт, желательно с ограничением частоты
- Принимать порты рабочей нагрузки, явно перечисленные
- Принимать ICMP echo — не ломайте обнаружение MTU пути
Шаг 3 — автоматические обновления безопасности
unattended-upgrades на Debian и Ubuntu, dnf-automatic на производных RHEL, настроенные только на обновления безопасности. Большинство компрометаций используют уязвимости, пропатченные месяцами ранее.
Включите автоматическую перезагрузку в окне обслуживания, если ваша рабочая нагрузка это допускает. Обновления ядра ничего не дают, пока машина не перезагрузится, а сервер с 400 днями аптайма и одиннадцатью неисправленными CVE ядра — это не повод для гордости.
Шаг 4 — fail2ban и что он даёт на самом деле
При отключённой парольной аутентификации fail2ban предотвращает относительно немного реальных компрометаций. Что он действительно делает — резко снижает шум в логах; это важно, потому что лог с тысячами неудачных попыток — это лог, который никто не читает, а непрочитанные логи — причина того, что реальные вторжения остаются незамеченными неделями.
Стандартного джейла sshd достаточно. Добавьте джейлы для всего остального, что вы открываете в интернет.
Шаг 5 — уменьшаем поверхность атаки
Выполните ss -tlnp и посмотрите, что слушает порты. При стандартной установке обычно там есть сервисы, о которых вы не знали и которые вам не нужны. Удаляйте их, а не закрывайте файрволом — у неустановленного ПО нет уязвимостей.
Сервисы, которым нужен только локальный доступ, привязывайте к 127.0.0.1, а не к 0.0.0.0. База данных, слушающая все интерфейсы за файрволом, — в одной неправильной настройке от публичности.
Что можно пропустить
Смена SSH-порта уменьшает шум в логах и не останавливает ровно ноль целевых атак. Делайте, если хотите, но не считайте это защитой. Port knocking добавляет хрупкости ради минимальной выгоды. Системы обнаружения вторжений генерируют алерты, которые никто не триажит на одиночном сервере.
Если после пяти шагов вам нужен ещё один осмысленный — это зашифрованные внешние резервные копии в другой юрисдикции, проверенные реальным восстановлением. Способность восстановиться стоит больше, чем ещё один уровень защиты.
Часто задаваемые вопросы
01 Стоит ли менять SSH-порт?
Для уменьшения шума в логах — да. Для безопасности — нет: это останавливает случайные сканеры и ноль целевых атак. Делайте, если хотите более тихие логи, но не считайте это контрмерой.
02 Нужен ли fail2ban при использовании SSH-ключей?
Для прямой безопасности — едва ли. Для гигиены логов — да: тысячи неудачных попыток делают логи нечитаемыми, а нечитаемые логи — причина того, что реальные вторжения остаются незамеченными.
03 Стоит ли включать автоматические перезагрузки?
Если рабочая нагрузка это допускает — да, в окне обслуживания. Патчи ядра ничего не дают до перезагрузки. Долгий аптайм с неисправленными CVE ядра — это ответственность, а не достижение.
Похожее