Безопасность VPS: практическая настройка и защита сервера
Новый VPS подключён к интернету сразу после выдачи IP-адреса, поэтому автоматические сканеры находят его раньше, чем владелец успевает развернуть приложение. Надёжная защита начинается не с одного «секретного» параметра, а с короткого повторяемого процесса: минимальные права, своевременные обновления, закрытая сеть, резервные копии и наблюдаемость.
Сначала определите, что именно защищаете
Универсальной «идеально безопасной» конфигурации нет. Сервер со статическим сайтом, VPN-шлюз и база данных имеют разные открытые порты, пользователей и последствия отказа. Запишите четыре вещи: какие данные хранятся, кто должен иметь доступ, какие внешние сервисы нужны приложению и сколько простоя допустимо. Такой мини-аудит не требует сложной методологии, но не даёт бездумно копировать настройки из случайной инструкции.
Для публичного сайта наиболее вероятны перебор паролей, эксплуатация устаревшего приложения, кража токена из репозитория, уязвимый плагин и перегрузка запросами. Для внутреннего сервиса добавляются ошибочно открытая база данных и чрезмерные права сотрудников. Защита должна снижать вероятность атаки и одновременно ограничивать ущерб: отдельный пользователь приложения, изолированная база, резервная копия вне сервера и возможность быстро заменить скомпрометированный узел.
Что сделать в первый час после получения VPS
| Действие | Зачем | Как проверить |
|---|---|---|
| Обновить систему | Закрыть уже известные уязвимости образа | Менеджер пакетов не предлагает критических обновлений |
| Создать администратора | Не работать постоянно от root | Команды через sudo выполняются, прямой вход root отключён |
| Добавить SSH-ключ | Убрать зависимость от перебираемого пароля | Новый сеанс открывается ключом до отключения пароля |
| Настроить firewall | Оставить доступными только нужные службы | С внешней сети видны лишь разрешённые порты |
| Включить резервирование | Иметь точку восстановления до изменений | Тестовый файл восстанавливается из копии |
Не закрывайте текущий SSH-сеанс, пока не проверили вход в отдельном окне. Большинство аварий на старте происходит не из-за атаки, а из-за правила firewall или SSH, которое отрезало администратора. Полезно заранее знать, предоставляет ли хостер веб-консоль или rescue-режим: это запасной вход, если сеть настроена неверно.
Безопасный доступ по SSH
Создайте отдельного пользователя, добавьте его в административную группу и перенесите публичный ключ в authorized_keys. После проверки отключите вход root и парольную аутентификацию. Ключ защищайте парольной фразой; на рабочем компьютере храните его в системном хранилище или аппаратном токене. Один ключ на всю команду лишает вас возможности отозвать доступ конкретному человеку, поэтому каждому нужен собственный.
Перенос SSH на нестандартный порт уменьшает шум в журналах, но не является границей безопасности: сканер найдёт службу и там. Гораздо важнее ключи, ограничение адресов через firewall или VPN, а также защита от частых попыток входа. Fail2ban полезен как дополнительный слой, но не заменяет запрет паролей. Для автоматизации создавайте отдельные ключи с минимальными правами и не разрешайте CI-процессу интерактивный административный вход.
Firewall и минимальная поверхность атаки
Начинайте с запрета входящих соединений и разрешайте только необходимое. Для обычного сайта с внешним администрированием это SSH, HTTP и HTTPS; база данных, Redis, панель метрик и внутренний API не должны слушать публичный интерфейс. Если сервисы находятся на нескольких узлах, соединяйте их через приватную сеть или WireGuard и ограничивайте правила конкретными адресами.
- проверьте список слушающих сокетов и сопоставьте каждый порт с владельцем;
- удалите демонстрационные приложения, старые панели и неиспользуемые сетевые службы;
- не публикуйте Docker-порт на
0.0.0.0, если доступ нужен только соседнему контейнеру; - закройте административные панели дополнительной аутентификацией и ограничением IP;
- проверьте IPv6 отдельно: правила IPv4 не всегда автоматически действуют для него;
- уточните у провайдера условия и объём защиты от DDoS.
После изменения правил просканируйте сервер с внешнего адреса. Проверка с самого VPS не показывает, что действительно видит интернет. Для веб-приложения обратный прокси должен завершать TLS, добавлять безопасные заголовки и передавать приложению только ожидаемые маршруты. Но он не исправит SQL-инъекцию или слабую авторизацию в самом коде.
Обновления без неожиданного простоя
Операционная система, веб-сервер, язык программирования, контейнерные образы и зависимости приложения обновляются независимо. Назначьте владельца каждого слоя и понятный график. Критические исправления безопасности устанавливайте быстро, обычные обновления — в регулярное окно с резервной копией и планом отката. Автоматическая установка security-пакетов полезна, если вы получаете уведомление о требуемой перезагрузке.
Контейнер с тегом latest не гарантирует свежесть и делает откат непредсказуемым. Фиксируйте версию или digest, пересобирайте образ из обновлённой базы и проверяйте его в тестовой среде. Сканер зависимостей помогает расставить приоритеты, однако найденный CVE ещё нужно сопоставить с используемой функцией и доступностью компонента извне.
Права, секреты и защита приложения
Приложение не должно работать от root. Создайте системного пользователя без интерактивного входа, выдайте ему доступ только к каталогу приложения и нужным сокетам. Базе данных назначьте отдельного пользователя с правами на конкретную схему. Если веб-процессу удастся выполнить чужой код, минимальные права не позволят сразу изменить всю систему.
Пароли, API-ключи и токены нельзя хранить в репозитории, Dockerfile, истории команд или публичных переменных клиентского JavaScript. Используйте секреты оркестратора либо файл, читаемый только сервисным пользователем. Настройте ротацию: секрет, который невозможно заменить без простоя, однажды станет проблемой. При подозрении на утечку сначала отзовите ключ на стороне внешнего сервиса, затем выпустите новый; простого удаления из последнего коммита недостаточно, потому что значение остаётся в истории.
Для сайта включите HTTPS и автоматическое продление сертификата. Добавьте безопасные cookie с флагами Secure, HttpOnly и подходящим SameSite, ограничьте размер загрузки, валидируйте входные данные и включите защиту от CSRF там, где используется cookie-сессия. Административные действия журналируйте, но не записывайте в логи пароли, токены, номера карт и полные персональные данные.
Как понять, что защита работает
Минимальный мониторинг охватывает доступность сайта, срок TLS-сертификата, заполнение диска, загрузку CPU, память, количество ошибок приложения и состояние резервных копий. Настройте уведомление во внешний канал: сообщение на том же сервере исчезнет вместе с сервером. Базовый журнал входов и административных команд храните достаточно долго, чтобы расследовать событие, но задайте ротацию, иначе логи сами заполнят диск.
Сигналом атаки могут быть новые пользователи и ключи SSH, незнакомые процессы, исходящий трафик, резкий рост нагрузки, изменённые системные файлы или входы из необычных сетей. При серьёзном подозрении не пытайтесь «вылечить» узел на месте. Ограничьте сеть, сохраните необходимые данные для расследования, смените внешние секреты и разверните чистый сервер из проверенной конфигурации. Скомпрометированной системе нельзя полностью доверять.
Типичные ошибки владельцев VPS
- Открытая база данных. PostgreSQL, MySQL, Redis или MongoDB доступны всему интернету ради удобства. Используйте приватную сеть, VPN или SSH-туннель.
- Один root-пароль на годы. Пароль попадает в историю, менеджер задач или переписку. Перейдите на персональные ключи и sudo.
- Снимок считают резервной копией. Снимок в том же аккаунте может исчезнуть вместе с сервером или аккаунтом. Нужна независимая копия и тест восстановления.
- Обновления откладывают до инцидента. Публичный сервис с известной уязвимостью сканируется автоматически; малый проект не становится невидимым.
- Устанавливают лишнюю панель. Каждый компонент добавляет код, порты и собственный цикл обновлений.
- Нет плана восстановления. В момент атаки команда впервые ищет контакты, пароли и копии, теряя критическое время.
Итоговый чек-лист
- система и зависимости обновлены;
- root-вход и парольный SSH отключены после проверки ключей;
- firewall разрешает только обоснованные порты, включая IPv6;
- приложение и база работают с минимальными правами;
- секреты вынесены из кода и могут быть быстро заменены;
- TLS продлевается автоматически;
- мониторинг отправляет внешние уведомления;
- резервные копии находятся вне VPS и регулярно восстанавливаются;
- у ответственного есть короткий план действий при инциденте.
Частые вопросы
Нужен ли антивирус на Linux VPS?
Он может быть полезен для файлового обмена, почты или проверки загружаемого контента, но не заменяет обновления, минимальные права и сетевые ограничения. Решение зависит от данных и модели угроз.
Достаточно ли сменить порт SSH?
Нет. Это уменьшает количество автоматических записей в логе, но не мешает обнаружить службу. Основные меры — ключи, запрет root и паролей, firewall и контроль доступа.
Как часто делать резервные копии?
Частота зависит от допустимой потери данных. Если можно потерять не более часа заказов, копия базы раз в сутки не подходит. Определите RPO и RTO, затем настройте расписание и тест восстановления.
Можно ли полностью защититься от DDoS самостоятельно?
Нет, если атака забивает канал раньше вашего firewall. Нужна защита на сети провайдера или внешнего прокси. Локальные лимиты всё равно полезны против прикладной перегрузки.
Продолжите настройку: резервное копирование VPS, выбор конфигурации и выбор европейской локации.