Чек-лист харденинга сервера перед продакшеном

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

Пять шагов

1. Вход по SSH-ключу

Отключить парольную аутентификацию по SSH, оставить только вход по ключу. Это убирает саму возможность подбора пароля — атакующему нечего перебирать. Перед отключением обязательно проверить, что вход по ключу реально работает из свежей сессии, не полагаясь на уже открытое соединение.

2. Нестандартный порт SSH

Перенести SSH на нестандартный порт. Не защита от целевой атаки, но резко снижает объём фонового шума в логах — большинство ботов сканируют только порт 22.

3. fail2ban

Поставить fail2ban с banaction на SSH-джейл и разумным findtime/maxretry — например, бан на час после 5 неудачных попыток за 10 минут. Для серверов с историей повторных нарушителей добавить recidive-джейл с более длинным баном за повторные срабатывания.

4. Firewall

Настроить firewall (ufw/iptables) по принципу белого списка портов — открыто только то, что реально слушает и должно быть доступно снаружи. Всё, что биндится на 127.0.0.1 (админки, локальные сервисы), не должно даже проверяться — оно и так недоступно извне.

5. Автоматический HTTPS

Автоматический HTTPS через Caddy или certbot — не столько защита, сколько гигиена: без нормального TLS браузеры и клиенты будут ругаться, а трафик — идти в открытом виде.

Что дальше

Дальше — по ситуации: если серверов несколько, стоит унифицировать конфиг (одинаковый порт SSH, одинаковые правила fail2ban) и сделать ежедневную сводку банов одним сообщением, а не уведомление на каждый — иначе Telegram завалит алертами при первом же серьёзном скане. Если серверов больше одного и проходить этот чек-лист на каждом вручную не хочется, такая унификация — как раз часть работ по сетевой инфраструктуре.