После установки панели или CMS сервер нередко считают готовым: сайт открывается, сертификат работает, пароль записан. Но часть настроек относится к дальнейшей эксплуатации. Кто может войти по SSH, какие порты доступны снаружи, что произойдёт при утечке пароля сайта и где лежит независимая копия?
Проверять защиту нужно по фактической схеме размещения. Общедоступному магазину, закрытому кабинету и тестовой машине требуются разные сетевые правила. Ни один список настроек не гарантирует отсутствие взлома. Задача — уменьшить доступную поверхность атаки, ограничить последствия и сохранить возможность обнаружить проблему и восстановить работу.
Подготовьте безопасный административный вход
Используйте персональные учётные записи и ключи, а повышенные права выдавайте для необходимых действий. Уточните, кто способен восстановить доступ через консоль провайдера, если сетевой вход перестанет работать. Доступ к панели хостинга тоже защищайте вторым фактором: через неё часто можно управлять дисками и учётными данными сервера.
Изменять SSH нужно с сохранением проверенного резервного пути. Сначала проверьте новый способ входа во второй сессии и только затем ограничивайте прежний. Ошибка в настройке может закрыть доступ и владельцу. Смена стандартного порта сама по себе не заменяет проверку аутентификации, прав и сетевых ограничений.
Сверьте открытые сервисы с назначением сервера
Составьте список публичных портов и объясните необходимость каждого. Для обычного веб-сервера нужны одни соединения, для почты или VPN — другие. База данных, кеш и служебные панели не должны становиться общедоступными просто потому, что установщик открыл порт. Ограничивайте подключения по нужным адресам и интерфейсам.
Учитывайте правила на VPS и на стороне провайдера, а также IPv4 и IPv6. Если перед сервером работает защитный прокси, проверьте прямой доступ к исходному адресу. Сетевые ограничения тестируют с разрешённой и запрещённой стороны. Не меняйте их вслепую: внешние интеграции, мониторинг и выпуск сертификата тоже используют соединения.
Разделите права сайта и администратора
Процесс PHP не должен получать административные права ради удобства записи файлов. Определите, какие каталоги действительно требуют изменения: загрузки, кеш, временные данные. Код и конфигурацию по возможности отделите от этих каталогов. Конкретная схема владельцев и разрешений зависит от способа запуска приложения.
Не применяйте универсальные разрешения ко всему дереву. Нужно проверить, кто читает секреты, кто пишет код и какие файлы может выполнить веб-сервер. Для нескольких сайтов полезна изоляция процессов и учётных записей. Иначе уязвимость одного проекта способна повлиять на соседние приложения. Особенности WordPress рассматриваются в официальном руководстве по усилению защиты.
Учитывайте обновления и происхождение компонентов
Сверьте ОС, PHP, базу, веб-сервер, панель, CMS и расширения. У каждого компонента должен быть понятный источник обновлений и ответственный за установку. Используйте доверенные репозитории и проверяйте совместимость приложения. Обновление сервера не исправит заброшенный плагин, а обновление CMS не заменяет обслуживание системы.
Не откладывайте проверку подтверждённой уязвимости до очередного большого релиза. Оцените затронутую версию и доступность функции, затем выберите исправление или временное ограничение. Перед изменениями проверьте копию и возврат. Практическая последовательность есть в статье об уязвимости плагина.
Защитите секреты и резервные копии
Пароли базы, ключи API и токены не должны находиться в публичном каталоге, репозитории или диагностическом ответе. Разделяйте учётные данные production и тестовой среды. Для интеграций используйте отдельные реквизиты, которые можно отозвать без смены всех паролей проекта.
Храните хотя бы необходимую для восстановления копию независимо от рабочего сервера. Проверьте, может ли учётная запись сайта удалить архивы. Если ответ положительный, компрометация приложения угрожает и восстановлению. Подробнее этот риск разобран в защите копий от удаления. Доступ к ключу шифрования также должен переживать отказ VPS.
Сделайте подозрительные события заметными
Сохраняйте журналы входов, ошибок приложения и важных административных изменений. Настройте срок хранения и доставку туда, где данные останутся доступны при отказе сервера. В уведомлениях нужны время, узел и наблюдаемый симптом. Полное содержимое форм и секретные значения в технические логи не включают.
Проверяйте новых пользователей, неожиданные задания и изменения кода. Само отличие файла ещё не доказывает атаку: обновление или кеш тоже меняют данные. Наблюдение должно помогать расследованию, а не создавать поток тревог без понятного действия. Для подтверждённых признаков компрометации предусмотрите ограничение доступа и сохранение материалов.
Проверьте защиту как рабочий процесс
После настройки повторите вход администратора, работу сайта, интеграций и фоновых задач. Убедитесь, что ограничения не нарушили полезные функции. Сохраните схему, список разрешённых соединений, место секретов и порядок восстановления. Эти сведения понадобятся при следующем изменении сети или состава команды.
Возвращайтесь к проверке после установки нового сервиса и выдачи дополнительных прав. Безопасная исходная конфигурация не останется такой автоматически. Владелец проекта должен знать, кто следит за изменениями и как поступает сигнал, если обычное состояние нарушено.
Для проверки защиты вашего VPS напишите в HOMEWEB. Укажите провайдера, CMS и установленные панели. Пароли и закрытые ключи в первое сообщение прикладывать не нужно.
