Базовая защита веб-сервера: Nginx, PHP, SSH, права и резервные копии
Безопасность сайта зависит не только от CMS. Даже полностью обновлённый 1С-Битрикс может работать на сервере с открытым SSH, лишними сервисами, неправильными правами на файлы или устаревшим PHP. Поэтому защита проекта должна охватывать всю среду: операционную систему, веб-сервер, PHP, доступы, резервные копии и мониторинг.
Ниже — базовый набор мер, который не заменяет полноценный аудит, но закрывает много типовых ошибок конфигурации.
Обновления должны быть плановыми
Операционная система, PHP, Nginx/Apache, база данных и сама CMS должны получать security-обновления. Но обновлять production «в один клик» тоже рискованно: сначала проверяется совместимость и резервная копия.
Полезно иметь график регулярных обновлений и отдельную процедуру для критических уязвимостей.
SSH не должен быть доступен всем одинаково
- используйте отдельные учётные записи вместо общего root-доступа;
- предпочитайте SSH-ключи паролям;
- ограничивайте доступ по необходимости;
- отключайте неиспользуемые учётные записи;
- фиксируйте, у кого есть административный доступ.
Смена нестандартного порта может сократить шум от автоматических сканеров, но сама по себе не является серьёзной мерой защиты.
Права на файлы важнее, чем кажется
Веб-процессу не нужно право записи во все директории проекта. Если PHP может изменять любой файл приложения, успешная эксплуатация одной уязвимости даёт атакующему слишком много возможностей.
Права лучше настраивать по принципу минимально необходимого доступа: отдельно код, пользовательские загрузки, кеш и временные директории.
Закрывайте служебные файлы
Конфигурации, резервные копии, дампы базы, временные архивы и служебные скрипты не должны открываться по HTTP. Особенно опасно оставлять резервную копию в публичной директории сайта.
Проверяйте правила Nginx/Apache и регулярно сканируйте web-root на случайно загруженные файлы.
PHP должен быть настроен под production
Подробные ошибки не должны показываться посетителям. Логи нужно записывать в защищённое место и ротировать. Опасные значения лимитов и временные режимы отладки после диагностики нужно возвращать в рабочее состояние.
Также важно использовать поддерживаемую версию PHP с актуальными исправлениями безопасности.
Резервная копия — часть безопасности
При атаке или ошибке администратора важно иметь возможность восстановить состояние проекта. Бэкап должен храниться отдельно от основного сервера, а процесс восстановления нужно периодически проверять.
Если копия лежит на том же диске, что и сайт, она не защищает от большого класса аварий.
Мониторинг помогает увидеть проблему раньше
Следить стоит не только за доступностью главной страницы. Полезны уведомления о заполнении диска, росте ошибок 5xx, падении PHP-FPM, проблемах с базой, сроке SSL и подозрительных всплесках запросов.
Не забывайте о секретах
API-ключи, пароли базы, SMTP и токены ботов должны храниться так, чтобы не попадать в публичный репозиторий, логи и сообщения об ошибках. При увольнении сотрудника или завершении работы подрядчика доступы нужно отзывать.
Практический минимум
- Обновить поддерживаемые версии ПО.
- Проверить SSH и список администраторов.
- Пересмотреть права на файлы.
- Закрыть служебные файлы из web-доступа.
- Проверить PHP production-настройки.
- Настроить внешние резервные копии.
- Добавить мониторинг ключевых метрик.
- Регулярно проверять журналы безопасности и ошибок.
Безопасность сервера — это не одна настройка, а набор небольших ограничений, которые вместе уменьшают последствия каждой отдельной ошибки.
Проверку серверного окружения, обновлений и резервирования можно включить в техническую поддержку сайта.