Как защитить сайт от ботов, сканеров, взлома и сетевых атак

Владелец сайта часто узнаёт об атаке не из уведомления системы безопасности, а по косвенным признакам. Страницы начинают открываться медленнее, процессор сервера загружен на 100%, база данных создаёт аномально высокую нагрузку, в формах появляется спам, а в журналах фиксируются тысячи однотипных запросов.

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

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

Какие угрозы получает обычный сайт

Автоматический вредоносный трафик может выглядеть по-разному. Часть запросов легко заметить, но более сложные программы стараются имитировать действия обычного посетителя.

Сканеры уязвимостей

Сканеры последовательно проверяют типовые адреса административных панелей, резервных копий, конфигурационных файлов, журналов, служебных каталогов и компонентов популярных CMS.

В логах можно увидеть обращения к адресам, которых никогда не было на сайте:

• административным панелям;
• файлам конфигурации;
• старым версиям скриптов;
• резервным копиям;
• открытым API;
• служебным каталогам;
• известным уязвимым плагинам;
• файлам с паролями и ключами доступа.

Большинство таких запросов завершается ошибкой 404, однако их обработка всё равно расходует ресурсы веб-сервера и приложения.

Если сканирование выполняется интенсивно, серверу приходится постоянно обрабатывать заведомо бесполезные запросы. На слабом виртуальном хостинге или VPS это может привести к замедлению сайта даже без успешной эксплуатации уязвимости.

Парсеры и сборщики контента

Парсеры копируют каталог товаров, цены, фотографии, характеристики, статьи, контактные данные и другую информацию.

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

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

Простая блокировка по User-Agent не обеспечивает надёжной защиты. Заголовок User-Agent легко изменить, а современные боты могут представляться обычными браузерами.

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

Подбор паролей и поиск точек входа

Автоматические программы могут отправлять большое количество запросов к формам авторизации, административным панелям, API и формам восстановления пароля.

Даже когда пароль подобрать не удаётся, такие запросы могут:

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

Особенно опасны административные разделы, доступные по стандартным адресам. Автоматические программы непрерывно проверяют панели управления популярных CMS, системы управления базами данных и известные служебные интерфейсы.

Поведенческие боты

Наиболее сложные боты поддерживают JavaScript, сохраняют cookie, переходят по ссылкам и пытаются воспроизводить поведение обычного человека.

По одному IP-адресу или заголовку браузера определить такой трафик практически невозможно. Один бот может использовать множество адресов, а с одного адреса могут одновременно работать реальные пользователи и автоматические программы.

Для выявления поведенческих ботов приходится анализировать совокупность признаков:

• последовательность запросов;
• частоту переходов;
• наличие и корректность cookie;
• прохождение проверочных этапов;
• выполнение JavaScript;
• особенности HTTP-соединения;
• характер запрашиваемых страниц;
• реакцию клиента на действия защитной системы;
• повторяемость поведения с разных IP-адресов.

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

Атаки на уровень веб-приложения

При L7-атаке злоумышленник обращается не просто к серверу, а к конкретным страницам, которые требуют значительных вычислительных ресурсов.

Это могут быть:

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

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

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

Почему плагина безопасности может быть недостаточно

Защитный плагин, установленный внутри CMS, начинает работать только после того, как запрос уже дошёл до сайта.

К этому моменту веб-сервер мог запустить PHP, создать подключение к базе данных, загрузить компоненты системы и выполнить часть логики приложения. Даже если плагин впоследствии заблокирует запрос, сервер уже потратил на него ресурсы.

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

У плагинов есть и другие ограничения:

• зависимость от работоспособности самой CMS;
• дополнительная нагрузка на сервер;
• отсутствие контроля до запуска приложения;
• ограниченные возможности анализа сетевого трафика;
• невозможность скрыть настоящий IP-адрес сервера;
• отсутствие централизованной фильтрации нескольких сайтов;
• риск конфликта с другими компонентами сайта.
• Более эффективная архитектура предполагает фильтрацию запросов до их передачи на основной сервер.

Обратный прокси как внешний защитный контур

Защищаемый домен можно направить на отдельный обратный прокси-сервер. Он принимает входящие соединения, проверяет запросы и передаёт на исходный сервер только разрешённый трафик.

Схема обработки выглядит следующим образом:

Посетитель → защитный прокси → WAF и правила фильтрации → основной сервер сайта

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

Обратный прокси может выполнять несколько задач:

• завершать TLS-соединения;
• проверять HTTP-запросы;
• применять правила WAF;
• ограничивать частоту обращений;
• блокировать подозрительные сети и адреса;
• проводить проверку браузера;
• выдавать CAPTCHA;
• регистрировать события безопасности;
• передавать разрешённые запросы на исходный сервер.

В результате значительная часть автоматического трафика отсекается до запуска CMS, PHP и запросов к базе данных.

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

Зачем нужен WAF

Web Application Firewall анализирует структуру HTTP-запросов и применяет правила безопасности.

WAF может выявлять:

• попытки SQL-инъекций;
• межсайтовый скриптинг;
• обход каталогов;
• подозрительные параметры запросов;
• обращения к закрытым файлам;
• попытки эксплуатации известных уязвимостей;
• нетипичные HTTP-методы;
• аномальные заголовки;
• сканирование служебных адресов;
• повторяющиеся вредоносные запросы.

При обнаружении угрозы WAF может заблокировать запрос, вернуть специальный код ответа, записать событие в журнал или направить клиента на дополнительную проверку.

Однако установка стандартного набора правил сама по себе не решает все проблемы.

Каждый сайт имеет собственную структуру, API, формы, административные разделы и особенности работы. Слишком строгие правила могут блокировать реальных посетителей, а слишком мягкие — пропускать вредоносный трафик.

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

Почему недостаточно блокировать IP-адреса

Блокировка отдельных IP-адресов может быть полезна как вспомогательный инструмент, но не должна быть единственным механизмом защиты.

Современные боты используют:

• прокси-серверы;
• VPN;
• заражённые устройства;
• облачные платформы;
• мобильные сети;
• динамические адреса;
• распределённые сети из тысяч узлов.

После блокировки одного адреса запросы могут продолжиться с другого.

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

Более надёжный подход заключается в оценке самого поведения клиента и фактических результатов проверок.

Многоступенчатая проверка вместо CAPTCHA для всех

Постоянная CAPTCHA на каждой странице раздражает посетителей и может снижать конверсию. Более разумный вариант — применять несколько уровней проверки.

Например:

1. Заведомо вредоносные запросы блокируются сразу.
2. Подозрительные клиенты получают автоматическую JavaScript-проверку.
3. Клиенты, прошедшие первый этап, но сохранившие признаки автоматизации, получают CAPTCHA.
4. После успешной проверки браузеру выдаётся доверенная cookie.
5. Обычный посетитель продолжает работу с сайтом без повторных проверок.

Такой подход позволяет отделить примитивные сканеры от более сложных поведенческих ботов и при этом не показывать CAPTCHA каждому пользователю.

Примитивные сканеры часто не умеют выполнять JavaScript, сохранять корректное состояние или повторять последовательность действий браузера. Они отсеиваются на первом этапе без участия человека.

Более сложные программы могут пройти JavaScript-проверку, но не всегда способны корректно пройти следующий уровень или воспроизвести нормальное поведение посетителя.

Важно, чтобы защитная система не принимала решение только по одному признаку. Страна, ASN, IP-адрес, версия HTTP, заголовки, cookie и User-Agent могут использоваться при анализе, но каждый из этих параметров по отдельности способен дать ошибочный результат.

Ограничение частоты запросов

Rate limiting ограничивает количество запросов, которое клиент может выполнить за определённый период.

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

Поэтому ограничения целесообразно задавать отдельно:

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

При настройке также необходимо учитывать NAT, корпоративные сети, мобильных операторов и прокси. За одним IP-адресом может находиться большое количество реальных посетителей.

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

Защита ресурсоёмких страниц

Не все страницы сайта одинаково важны с точки зрения безопасности и нагрузки.

Особого внимания требуют:

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

Для таких адресов можно использовать отдельные ограничения, проверку наличия доверенной cookie, анализ последовательности действий и дополнительные правила WAF.

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

Защита от массового сканирования несуществующих страниц

Автоматические сканеры часто перебирают тысячи URL, рассчитывая найти резервную копию, старую административную панель, уязвимый плагин или забытый служебный файл.

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

Защитная система может учитывать:

• количество ошибок 404 от одного клиента;
• скорость перебора адресов;
• характер проверяемых файлов;
• последовательность запросов;
• обращение к адресам разных CMS;
• попытки найти конфигурационные файлы и резервные копии.

Если клиент за короткое время проверяет адреса, относящиеся к WordPress, Joomla, Bitrix, phpMyAdmin и другим системам, это с высокой вероятностью является автоматическим сканированием, а не действиями обычного посетителя.

Мониторинг важнее разовой установки

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

Журналы должны позволять определить:

• какие адреса создают основную нагрузку;
• из каких сетей поступают запросы;
• какие страницы чаще всего атакуют;
• сколько клиентов прошло проверку;
• сколько запросов было заблокировано;
• какие правила вызывают ложные срабатывания;
• как изменился трафик после включения защиты;
• какие запросы дошли до основного сервера;
• какие типы угроз преобладают.

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

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

Почему защиту необходимо настраивать индивидуально

Универсального набора правил, одинаково подходящего каждому сайту, не существует.

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

При индивидуальной настройке учитываются:

• используемая CMS;
• структура сайта;
• рабочие API;
• административные разделы;
• поисковые системы;
• платёжные сервисы;
• интеграции;
• мобильные приложения;
• особенности аудитории;
• допустимая частота запросов;
• ресурсоёмкие функции;
• нормальные сценарии поведения посетителей.

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

От каких DDoS-атак защищает веб-фильтрация

Необходимо различать объёмные сетевые атаки и атаки на веб-приложение.

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

WAF не может обработать трафик, который физически не помещается в канал сервера.

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

Именно против L7-атак эффективны:

• обратный прокси;
• WAF;
• ограничение частоты запросов;
• фильтрация сканеров;
• поведенческие проверки;
• JavaScript-челленджи;
• CAPTCHA;
• индивидуальные правила для ресурсоёмких страниц;
• блокировка аномальных последовательностей запросов.

Хорошая система защиты не обещает остановить абсолютно любую атаку. Она должна разделять угрозы по уровням и применять подходящий механизм для каждого типа трафика.

Объёмные сетевые атаки требуют возможностей оператора связи или центра очистки. Атаки на уровне HTTP и веб-приложения требуют анализа запросов, поведения клиентов и особенностей защищаемого сайта.

Что должно входить в услугу защиты сайта

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

Обычно работы включают:

• анализ текущей инфраструктуры;
• изучение журналов веб-сервера;
• подключение сайта через защищённый обратный прокси;
• установку и настройку WAF;
• создание индивидуальных правил фильтрации;
• защиту от сканеров, парсеров и автоматических запросов;
• защиту форм и административных разделов;
• настройку JavaScript-проверок и CAPTCHA;
• ограничение частоты обращений;
• скрытие адреса исходного сервера;
• мониторинг событий безопасности;
• корректировку правил при изменениях на сайте.

Для проектов, которым требуется внешний защитный контур и индивидуальная фильтрация трафика, доступна услуга защиты сайта от ботов, сканеров, сетевых атак и попыток взлома.

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

Такое решение особенно актуально для:

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

Как подключается внешний защитный контур

В большинстве случаев переносить сам сайт на другой сервер не требуется.

Домен направляется на защитный прокси, а прокси передаёт разрешённые запросы на действующий сервер или хостинг. Для посетителя адрес сайта не меняется.

При подключении необходимо:

1. Настроить защищённый прокси.
2. Выпустить или подключить SSL-сертификат.
3. Настроить передачу запросов на исходный сервер.
4. Изменить DNS-записи домена.
5. Ограничить прямой доступ к исходному серверу.
6. Проверить работу сайта и внешних интеграций.
7. Проанализировать первые события безопасности.
8. Скорректировать правила фильтрации.

После подключения основной сервер продолжает обслуживать сайт, но получает уже отфильтрованный трафик.

Может ли защита мешать реальным посетителям

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

Например, реальный пользователь может:

• работать через VPN;
• использовать корпоративный прокси;
• отключить JavaScript;
• заблокировать cookie;
• открыть много страниц за короткое время;
• использовать необычный браузер;
• находиться за общим IP-адресом мобильного оператора.

Поэтому нельзя безусловно считать подозрительным любой отдельный признак.

Задача индивидуальной настройки состоит в том, чтобы объединять несколько факторов, разделять разные уровни риска и не применять максимальную блокировку ко всем нестандартным клиентам.

Вместо немедленного запрета подозрительному посетителю можно показать автоматическую проверку или CAPTCHA. Если проверка пройдена успешно, доступ к сайту восстанавливается.

Как оценить результат работы системы защиты

Эффективность защиты нельзя измерять только общим количеством заблокированных запросов.

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

Полезно оценивать:

• снижение нагрузки на основной сервер;
• уменьшение количества вредоносных запросов;
• стабильность работы сайта;
• количество ложных срабатываний;
• доступность сайта для поисковых систем;
• прохождение реальных пользователей;
• сокращение спама и автоматических обращений;
• уменьшение количества тяжёлых запросов к приложению;
• изменение нагрузки на процессор и базу данных.

Основной результат — не максимальное количество запретов, а стабильная работа сайта при сохранении доступа для нормальных посетителей.

Заключение

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

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

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

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