Чек-лист безопасности VPS: полное руководство

Почему нужен чек-лист, а не одно решение

Ни одна отдельная мера не защищает VPS сама по себе, потому что злоумышленнику достаточно найти один слабый уровень, тогда как защитникам нужно, чтобы держались все уровни сразу. Усиленный файрвол бесполезен, если SSH всё ещё принимает слабые пароли, а усиленный SSH бесполезен, если веб-приложение за ним содержит непропатченную уязвимость. Безопасность сервера работает как набор уровней, каждый из которых закрывает конкретный путь атаки, и этот чек-лист построен вокруг этих уровней в том порядке, в котором большинству операторов VPS стоит их проходить.

Это важнее для малого и среднего бизнеса, чем предполагает маркетинг вокруг «безопасности корпоративного уровня». Большинство атак на серверы, доступные из интернета, направлены не на конкретную компанию — это автоматизированные сканирования, непрерывно работающие против всего интернета в поисках любого сервера, который откликается на известную уязвимость. Небольшой VPS с сайтом клиента виден этим сканированиям точно так же, как крупный корпоративный сервер, и, по данным отчёта Verizon 2025 Data Breach Investigations Report, украденные или неправомерно использованные учётные данные фигурировали примерно в 32% всех утечек, поэтому чек-лист ниже начинается с контроля доступа, а не с более экзотических мер защиты.

Усиление защиты SSH-доступа

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

Как минимум сгенерируйте пару ключей Ed25519, отключите PasswordAuthentication, установите PermitRootLogin no и ограничьте подключающиеся учётные записи с помощью AllowUsers. Полный набор директив sshd_config, рекомендуемые наборы шифров и обоснование каждой настройки мы разбираем в отдельном руководстве Усиление защиты SSH: лучшие практики против brute-force атак.

Настройка файрвола

Файрвол обеспечивает политику «запрещено по умолчанию» на сетевом уровне, так что доступными остаются только конкретные порты, действительно нужные вашим приложениям — например, SSH, HTTP и HTTPS. Весь остальной трафик должен отклоняться ещё до того, как он достигнет запущенной службы.

В Ubuntu и Debian ufw — самый простой способ управлять этим; он транслируется либо в правила iptables, либо в правила nftables, в зависимости от вашей системы. Для более сложных наборов правил, нескольких серверов или более тонкого контроля nftables — современный, активно развиваемый преемник iptables. Оба подхода могут обеспечить одну и ту же политику «запрещено по умолчанию»; правильный выбор зависит от того, насколько детальный контроль вам нужен. Мы напрямую сравниваем все три варианта, включая заметки по миграции с iptables, в руководстве Файрвол в Linux: iptables vs nftables vs ufw.

Предотвращение вторжений с fail2ban

Fail2ban отслеживает файлы логов на предмет повторяющихся неудачных попыток входа и автоматически блокирует IP-адрес нарушителя на заданный период, что останавливает распределённые brute-force атаки, которые иначе бесконечно долбились бы в SSH, веб-формы входа или почтовые службы. Это второй уровень защиты, который работает вместе с аутентификацией по ключу и файрволом, а не заменяет их.

Разумная стартовая конфигурация блокирует IP на один час после трёх неудачных попыток входа по SSH в течение десятиминутного окна, с увеличивающимся временем блокировки для повторных нарушителей. Fail2ban также может защищать nginx, страницы входа WordPress и почтовые серверы, используя ту же модель jail. Полную настройку jail, добавление собственных IP в белый список и интеграцию fail2ban с файрволом мы разбираем в Руководстве по настройке Fail2ban: автоматическое предотвращение вторжений.

Управление обновлениями

Управление обновлениями означает своевременную и последовательную установку обновлений безопасности операционной системы и программного обеспечения — в идеале через автоматизацию, а не по ручному графику, который кто-то должен помнить. Непропатченное программное обеспечение — одна из самых распространённых первопричин утечек: исследование Ponemon Institute, проведённое по заказу ServiceNow, показало, что 60% жертв утечек сообщили о взломе через известную уязвимость, для которой существовал патч, но он не был установлен.

Для большинства дистрибутивов Linux включение автоматических обновлений безопасности закрывает этот пробел почти без каких-либо постоянных усилий. В Debian и Ubuntu за это отвечает пакет unattended-upgrades; в системах на базе RHEL ту же роль выполняет dnf-automatic. Сложнее обстоит дело с обновлением приложений и зависимостей, которые находятся вне менеджера пакетов ОС, и с определением того, когда патч требует перезапуска или технического окна. Обе стороны этого вопроса мы разбираем в Руководстве по управлению обновлениями сервера: почему непропатченные серверы взламывают.

Усиление защиты веб-сервера

Усиление защиты веб-сервера означает настройку nginx (или другого веб-сервера) так, чтобы скрыть лишнюю информацию о версии, обеспечить современные настройки TLS, установить защитные заголовки ответа и не отдавать файлы или каталоги, которые не должны быть доступны. Большая часть данных, которые на самом деле интересуют злоумышленников, находится за веб-сервером, а не за SSH, что делает этот уровень не менее важным, чем меры на уровне операционной системы, описанные выше.

Ключевые пункты включают отключение server_tokens, чтобы nginx не раскрывал точную версию, принудительное использование TLS 1.2 и выше с современными наборами шифров, установку заголовков вроде X-Content-Type-Options и Content-Security-Policy, а также применение ограничения частоты запросов к формам входа и API-эндпоинтам, чтобы затруднить credential-stuffing атаки. Полный разбор конфигурации — в статье Лучшие практики безопасности nginx.

Защита от DDoS

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

Нужный уровень защиты от DDoS сильно зависит от того, что именно вы запускаете и во сколько простой обходится вашему бизнесу. Мы разбираем практичные, соразмерные по стоимости варианты для сайтов малого и среднего бизнеса, включая бесплатные и недорогие тарифы, в статье Защита от DDoS для сайтов малого бизнеса.

Мониторинг и анализ логов

Мониторинг сервера означает непрерывное наблюдение за системными логами, логами аутентификации, использованием ресурсов и сетевой активностью, чтобы необычное поведение обнаруживалось сразу, а не спустя недели. Усиленно защищённый сервер, за которым никто не наблюдает, всё равно может быть незаметно скомпрометирован — особенно в результате медленной атаки, которая остаётся ниже любого отдельного порога срабатывания оповещения.

Как минимум централизуйте логи аутентификации, логи веб-сервера и системные логи там, где их не сможет удалить злоумышленник, получивший доступ к самому серверу, и настройте оповещения на такие аномалии, как всплеск неудачных попыток входа, неожиданные исходящие соединения или новые учётные записи пользователей. Источники логов, их хранение и практическую настройку оповещений мы разбираем в статье Мониторинг сервера и анализ логов.

Реагирование на инциденты

Реагирование на инциденты — это план действий на случай, если, несмотря на все перечисленные уровни защиты, вы обнаружите признаки компрометации сервера: как подтвердить взлом, локализовать его, сохранить улики и восстановить чистую работу службы. Наличие такого плана, составленного заранее, до того как что-то случится, — это то, что отличает локализованный сбой на несколько часов от затяжного и дорогостоящего инцидента.

Тревожные признаки, которые стоит немедленно проверить, включают незнакомые задания cron, неожиданные исходящие сетевые соединения, новые SSH-ключи, которые вы не добавляли, и необъяснимые всплески нагрузки на CPU или сетевого трафика. Пошаговый процесс подтверждения и локализации взлома, включая то, какие улики нужно сохранить, описан в статье Как обнаружить взлом сервера и отреагировать на него.

Управляемая безопасность или самостоятельная защита

Честный выбор между управляемой безопасностью и самостоятельной защитой — это вопрос не о том, работают ли меры из этого чек-листа, а о том, хватает ли у вашей команды времени и последовательности, чтобы применять их каждую неделю — особенно установку обновлений и круглосуточный мониторинг, которые быстро теряют эффективность без непрерывного внимания. Разовое усиление защиты ценно, но злоумышленники не перестают искать новые методы после того, как вы его завершите.

У некоторых компаний есть внутренние ресурсы, чтобы поддерживать этот чек-лист бессрочно. Другие обнаруживают, что внешняя команда, которая проверяет, настраивает и непрерывно отслеживает те же меры, надёжнее, чем полагаться на того, у кого в последний раз нашлось время проверить сервер. Мы разбираем реальные компромиссы, включая случаи, когда самостоятельная защита действительно работает хорошо, в статье Управляемая безопасность или самостоятельная защита: что нужно знать малому и среднему бизнесу.

Полный чек-лист в одном месте

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

• SSH: только аутентификация по ключу, вход под root отключён, sshd_config усилен, применяются современные шифры.
• Файрвол: политика «запрещено по умолчанию» для входящих соединений, открыты только необходимые порты, правила пересматриваются после подключения каждой новой службы.
• Fail2ban или аналог: jail для SSH включён, разумные bantime и maxretry, защита распространена на веб-формы входа.
• Установка обновлений: автоматические обновления безопасности включены для ОС, есть процесс обновления приложений вне менеджера пакетов.
• Веб-сервер: раскрытие версии отключено, применяется современный TLS, установлены заголовки безопасности, включено ограничение частоты запросов на чувствительных эндпоинтах.
• Защита от DDoS: CDN или обратный прокси перед исходным сервером, ограничение частоты запросов, провайдер с базовой сетевой фильтрацией.
• Мониторинг: централизованные, защищённые от подмены логи, оповещения об аномалиях аутентификации и неожиданном исходящем трафике.
• Реагирование на инциденты: письменный план подтверждения, локализации и восстановления после взлома, проверенный заранее.
• Резервные копии: регулярные, проверенные и хранящиеся там, где скомпрометированный сервер не сможет их удалить.
• Принцип наименьших привилегий: никаких общих учётных записей root, права sudo ограничены тем, что реально нужно каждой учётной записи.