Защита сайта от ботов-сканеров: что настроить на сервере в первый день

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

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

Что ищут сканеры

• Файлы настроек с паролями и ключами: /.env, /config.php.bak.
• Папку системы контроля версий: /.git/config — по ней можно восстановить исходный код.
• Архивы и дампы: /backup.zip, /site.tar.gz, /dump.sql.
• Формы входа: /wp-login.php, /admin, /administrator.
• Служебные интерфейсы: /phpmyadmin/, /xmlrpc.php.
• Файлы старых плагинов и тем, по которым можно определить версию.

Большинство таких запросов получают 404 и ни к чему не приводят. Опасен тот один адрес, который ответит 200.

1. Закрыть служебные файлы

Лучшее решение — не хранить их в публичной папке сайта: бэкапы и дампы — вне корня сайта, .env — уровнем выше. Если что-то всё же лежит в корне, закройте доступ на уровне веб-сервера:

# скрытые файлы и папки, кроме .well-known
location ~ /\.(?!well-known) {
    deny all;
}

# архивы, дампы и резервные копии
location ~* \.(sql|zip|tar|gz|bak|old|swp)$ {
    deny all;
}

Проверьте снаружи, что адреса не отдаются:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/.env
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/.git/config

Нормальный ответ — 403 или 404. Ответ 200 означает, что файл доступен любому.

2. Ограничить попытки входа

Форму входа перебирают тысячами паролей. Ограничьте частоту запросов к ней. В nginx для этого есть модуль limit_req (документация nginx):

limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;

server {
    location = /wp-login.php {
        limit_req zone=login burst=5 nodelay;
        limit_req_status 429;
        # дальше — обычная передача запроса в PHP
    }
}

Здесь один адрес может отправить в среднем десять запросов в минуту с запасом в пять. По умолчанию nginx отвечает на лишние запросы кодом 503; директива limit_req_status меняет его на 429 — «слишком много запросов».

Вместе с ограничением частоты:

• двухфакторная защита для всех учётных записей с правами администратора;
• уникальные логины — без общего admin;
• если команда работает с постоянных адресов, доступ к админке только с них.

3. Обновить и убрать лишнее

• Обновите систему управления, тему и плагины до актуальных версий.
• Удалите неиспользуемые плагины и темы — даже отключённые, их файлы остаются на сервере.
• Отключите интерфейсы, которыми не пользуетесь, например XML-RPC в WordPress, если он не нужен вашим интеграциям.
• Удалите установочные скрипты, тестовые страницы и файлы вроде phpinfo.php.

4. HTTPS и заголовки

Перенаправьте все запросы с http на https и добавьте заголовок Strict-Transport-Security. Он сообщает браузеру, что сайт открывается только по HTTPS, и запрещает обходить ошибки сертификата (MDN):

add_header Strict-Transport-Security "max-age=31536000" always;

Директиву includeSubDomains добавляйте, только если все поддомены уже работают по HTTPS: иначе браузеры перестанут открывать те, что без сертификата.

5. Логи и мониторинг

• Смотрите всплески ответов 401, 403 и 404 — так выглядит перебор.
• Настройте автоматическую блокировку адресов, которые перебирают вход или служебные пути: для этого используют fail2ban и аналоги или правила на уровне хостинга и CDN.
• Подключите мониторинг доступности: вы должны узнать о падении сайта раньше клиентов.
• По возможности отслеживайте изменения файлов сайта: неожиданный новый PHP-файл в папке загрузок — повод для проверки.

6. Резервные копии вне сервера

Если что-то всё же случится, восстановление занимает часы, а не дни, только при одном условии: копия хранится вне сервера сайта и её восстановление проверено. Копия на том же сервере пропадёт вместе с сайтом.

Таблица проверки первого дня

В поддержку сайтов PIP после запуска входят регулярное резервное копирование, мониторинг доступности и небольшие обновления — так указано на странице цен. Хотите проверить, что можно найти на вашем сервере? Расскажите о задаче.

Короткие подсказки о сайтах и автоматизации — в Telegram-канале @pip_kz.