Безопасная настройка VPS: базовый минимум для сайта, бота и веб-приложения

Запустить сайт, Telegram-бота или небольшое веб-приложение на VPS стало проще, особенно с AI-помощниками. Модель может написать код, Dockerfile, nginx-конфиг и команды деплоя. Но безопасность от этого не появляется автоматически. Наоборот, человек без опыта может быстро выкатить наружу сервис с открытыми портами, секретами в репозитории и root-доступом по паролю.

Перед публикацией любого pet project, MVP или homelab-сервиса стоит пройти базовый минимум защиты VPS. Эти меры не заменяют полноценный security audit, но закрывают самые частые и грубые ошибки.

SSH: закрыть самый очевидный вход

Первое, что видит интернет, — SSH. Если оставить парольный вход для root, сервер быстро попадёт под brute force.

Минимальные шаги:

• создать отдельного пользователя;
• добавить SSH-ключ;
• отключить вход root по SSH;
• отключить password authentication;
• включить sudo только нужному пользователю;
• при необходимости ограничить доступ по IP;
• поставить fail2ban или аналог.

Менять порт SSH не является полноценной защитой, но может снизить шум в логах. Главное — ключи и запрет паролей.

Firewall и открытые порты

На VPS не должно быть открыто всё подряд. Типовой набор для веб-приложения:

• 22/tcp — SSH, лучше ограниченный;
• 80/tcp — HTTP для redirect и Let’s Encrypt;
• 443/tcp — HTTPS;
• остальные порты закрыты наружу.

Базы данных, Redis, internal API, debug endpoints и admin panels не должны торчать в интернет без необходимости. Если сервис нужен только контейнерам на том же сервере, пусть слушает localhost или внутреннюю Docker-сеть.

Обновления и минимизация

Свежий сервер быстро устаревает. Нужно настроить регулярные security updates или хотя бы процесс ручного обновления. Также полезно не ставить лишние пакеты. Чем меньше поверхность атаки, тем проще сопровождение.

Проверить стоит:

• обновления ОС;
• версии Docker и compose plugin;
• версии nginx/caddy/traefik;
• зависимости приложения;
• базовые утилиты мониторинга;
• отсутствие ненужных демонов.

Reverse proxy и TLS

Для сайта или API лучше использовать reverse proxy: nginx, Caddy или Traefik. Он принимает HTTPS, проксирует запросы в приложение и позволяет централизованно настроить заголовки, лимиты и сертификаты.

Минимум:

• автоматический TLS через Let’s Encrypt;
• redirect HTTP на HTTPS;
• корректные Host и proxy headers;
• ограничение размера body;
• таймауты;
• security headers там, где применимо;
• отдельные server blocks для разных доменов.

Caddy удобен для простых проектов, nginx даёт больше контроля, Traefik хорошо ложится на Docker-heavy окружение.

Секреты

AI-сгенерированные проекты часто грешат тем, что токены, пароли и ключи оказываются в .env, README, docker-compose или даже в коде. Секреты нельзя коммитить.

Практический минимум:

• .env в .gitignore;
• отдельные секреты для prod и dev;
• ротация токенов после случайной публикации;
• минимальные права у API-ключей;
• закрытые права на файлы с секретами;
• отсутствие секретов в логах.

Если проект растёт, стоит смотреть в сторону Vault, SOPS, Doppler, Infisical или cloud secret manager.

Docker без иллюзий

Docker не делает приложение безопасным автоматически. Контейнер может запускаться от root, иметь лишние capabilities, монтировать Docker socket или писать куда угодно.

Стоит проверить:

• запуск от non-root пользователя;
• минимальный образ;
• отсутствие --privileged;
• ограниченные volumes;
• healthcheck;
• restart policy;
• закрытые внутренние порты;
• регулярное обновление base image.

Особенно опасен проброшенный /var/run/docker.sock: получив доступ к такому контейнеру, атакующий часто получает контроль над хостом.

Логи, мониторинг и бэкапы

Без логов невозможно понять, что произошло. Без бэкапов невозможно восстановиться. Минимум для маленького VPS:

• логи приложения и reverse proxy;
• log rotation;
• алерты по падению сервиса;
• мониторинг диска, RAM и CPU;
• backup базы и пользовательских файлов;
• периодическая проверка восстановления;
• отдельное место хранения backup.

Бэкап, который ни разу не восстанавливали, — это надежда, а не механизм защиты.

AI-код нужно проверять

Если приложение написано с помощью AI, нужно особенно внимательно пройтись по базовым уязвимостям:

• SQL injection;
• небезопасная загрузка файлов;
• отсутствие rate limiting;
• слабая авторизация;
• CORS * без причины;
• debug mode в production;
• подробные ошибки наружу;
• SSRF при работе с URL;
• хранение паролей без hashing.

Модель может сгенерировать рабочий код, но не обязана сделать его безопасным.

Итог

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

Главное правило простое: если сервис доступен из интернета, он уже находится в зоне риска. Даже pet project стоит деплоить так, будто завтра его найдёт сканер. Потому что он найдёт.