Как проверить безопасность VPS или выделенного сервера

Безопасность VPS нельзя определить одной оценкой сканера. Сервер может не иметь известных критических уязвимостей и при этом принимать SSH по забытым паролям, публиковать административную панель, запускать лишнюю службу или не сохранять журналы. Полезный аудит связывает четыре вопроса: что установлено, что доступно из сети, кто может войти и как обнаружить нежелательное изменение. NIST рекомендует рассматривать защиту сервера как непрерывный цикл безопасной установки, настройки, эксплуатации и обслуживания [1].

Перед проверкой: сохранить доступ и границы

Начните с письменного разрешения и списка адресов. Внешнее сканирование чужого диапазона или нагрузочные тесты недопустимы без согласования. До любых исправлений создайте проверенную резервную точку конфигурации и убедитесь, что есть альтернативный доступ через консоль провайдера. Изменения SSH и firewall способны отрезать администратора, поэтому сначала собирают факты, затем готовят план и откат, и только после этого применяют настройки по одной.

Зафиксируйте назначение сервера: какие сайты и API он обслуживает, где находится база, кто управляет DNS и TLS, какие агенты мониторинга и резервирования установлены. Сравнивать конфигурацию нужно не с абстрактным «идеально безопасным Linux», а с минимальным набором функций, необходимым конкретному сервису.

Шаг 1. Инвентаризация системы

Запишите дистрибутив, поддерживаемую ветку, версию ядра, виртуализацию, часовой пояс и источники пакетов. Для Ubuntu или Debian полезны чтение /etc/os-release, список установленных пакетов и доступных обновлений. Отдельно найдите ПО, установленное вручную: бинарники в /usr/local, сторонние репозитории, контейнеры, панели управления и агенты. Именно такие компоненты часто выпадают из штатного обновления.

Составьте перечень активных служб. Команды systemctl --type=service --state=running и ss -lntup помогают сопоставить процессы с сетевыми портами; их вывод нужно интерпретировать с правами администратора и с учётом контейнеров. Для каждой службы ответьте: нужна ли она, кто её обновляет, на каком адресе она слушает и должна ли быть доступна из интернета.

Шаг 2. Учётные записи и SSH

Проверьте локальных пользователей, группы с административными правами, ключи в authorized_keys, правила sudo и технические аккаунты. Удалять неизвестную запись сразу опасно: сначала установите владельца и зависимые задания. У бывших сотрудников доступ отзывают, общие аккаунты заменяют персональными, а административные действия связывают с конкретным пользователем.

Для SSH предпочтительна аутентификация ключами с защищённым закрытым ключом. Официальная документация Ubuntu описывает пары открытого и закрытого ключей и обращает внимание на права записи к authorized_keys [2]. Отключать парольный вход и вход root следует только после успешной проверки нового канала в отдельной сессии и наличия консольного доступа. Дополнительную защиту дают ограничение источников, MFA там, где она поддерживается, и журналирование попыток входа.

Шаг 3. Сеть и firewall

Сверьте открытые TCP- и UDP-порты с архитектурой. База, кеш, панели, метрики и отладочные интерфейсы обычно не должны быть доступны всему интернету. Проверьте правила как для IPv4, так и для IPv6: закрытая служба по одному протоколу может остаться публичной по другому.

В Ubuntu стандартным интерфейсом для простых правил является ufw, работающий поверх механизмов фильтрации ядра; документация также показывает просмотр статуса и ограничение доступа по сети-источнику [3]. В аудите важен не выбор оболочки, а фактический результат: политика по умолчанию, разрешённые направления, журналирование и сохранение правил после перезагрузки. Облачный security group и локальный firewall дополняют друг друга, но их расхождение усложняет диагностику.

Шаг 4. Обновления и уязвимости

Проверьте, поддерживается ли версия ОС и получает ли она исправления. Затем изучите обновления веб-сервера, PHP, СУБД, панели и контейнерных образов. Автоматическая установка может быть уместна для части security-обновлений, но перезапуск сервисов и совместимость приложения всё равно требуют контроля. Ubuntu документирует работу unattended-upgrades и источники, из которых разрешено брать пакеты [4].

Не сортируйте задачи только по числу CVSS. Приоритет повышают доступность компонента из интернета, наличие рабочего способа эксплуатации, привилегии процесса и ценность данных. Каталог CISA KEV содержит уязвимости, для которых подтверждена эксплуатация в реальных атаках, и может служить одним из входов в приоритизацию [5]. Результат сканера нужно сверять с фактически установленной версией и патчами дистрибутива: номер пакета не всегда совпадает с версией исходного проекта.

Шаг 5. Приложение, файлы и секреты

Проверьте владельцев и права каталогов сайта, отсутствие записи у веб-процесса там, где она не нужна, и запрет исполнения в каталогах пользовательских загрузок, если приложение это допускает. Ищите резервные архивы, дампы, .env, журналы и репозитории в публичном корне. Секреты не должны попадать в ответы веб-сервера или храниться в общедоступной истории кода.

Сверьте TLS-конфигурацию, перенаправление на HTTPS и заголовки, но не ограничивайте серверный аудит только внешним тестом сертификата. Ошибка в приложении, устаревший модуль или лишние права остаются опасными даже при современной криптографии.

Шаг 6. Журналы и обнаружение

Убедитесь, что сохраняются входы SSH, административные действия, ошибки веб-сервера и приложения, решения firewall, задания резервного копирования и события провайдера. Проверьте время на сервере: без синхронизации трудно сопоставлять события. Журналы должны иметь ограниченный доступ, понятный срок хранения и, для критичных систем, выноситься за пределы узла, который может быть уничтожен атакующим.

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

Шаг 7. Резервирование и восстановление

Проверьте свежесть копий, их состав, отдельное хранение и доступ к ключам. Затем выполните восстановление выбранного файла или сервиса в изолированной среде. CISA рекомендует держать критичные копии офлайн и регулярно проверять их доступность и целостность [6]. Снапшот панели провайдера удобен, но не заменяет отдельную копию с другим контуром доступа.

Как оформить результат и исправления

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

После изменений повторите инвентаризацию портов, вход с новой учётной записью, проверку сайта и API, запуск фоновых заданий, доставку журналов и восстановление. Сохраните конфигурационный diff. Если исправление нельзя применить сразу, зафиксируйте временную компенсирующую меру — например, сетевое ограничение — и срок окончательного устранения.

Источники

[1] NIST — SP 800-123: Guide to General Server Security.

[2] Ubuntu Server — OpenSSH server.

[3] Ubuntu Server — Firewall.

[4] Ubuntu Server — Automatic updates.

[5] CISA — Known Exploited Vulnerabilities Catalog.

[6] CISA — #StopRansomware Guide.