Просмотр кода страницы Защита от DDoS-атак прикладного уровня с помощью HAProxy

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

В этом посте описываются методы, использующие списки управления доступом, карты и таблицы привязки. Смотрите Следующие посты для ознакомления с этими темами.:

Введение в списки управления доступом HAProxy

Введение в карты HAProxy

Введение в таблицы HAProxy Stick

Запустите любой веб-сайт или приложение в наши дни, и вы гарантированно станете объектом широкого спектра проверок и атак. Ваш веб-сайт - это платформа, которая должна постоянно выдерживать шторм различных угроз, включая распределенные атаки типа "отказ в обслуживании" (DDoS), вредоносных ботов и попытки вторжения. С годами HAProxy адаптировалась к жизни в этих опасных водах благодаря разработке гибких стандартных блоков, которые можно комбинировать для смягчения практически любого типа угроз. Эти строительные блоки включают высокопроизводительные списки управления доступом и карты, отслеживание в реальном времени с помощью таблиц привязки, эффективный стек SSL / TLS, WAF и многое другое. Даже со всеми этими дополнительными возможностями он сохраняет лучшую в своем классе производительность, которой он известен.

Расширенные возможности безопасности HAProxy доступны для широкого спектра компаний - от небольших обычных магазинов до крупных предприятий, компаний, занимающихся управляемым хостингом, и платформ балансировки нагрузки как услуги, обслуживающих миллионы запросов в секунду. К числу ведущих веб-сайтов относятся GitHub, который использует HAProxy для защиты своей сети от DDoS-атак прикладного уровня, и StackExchange, который использует его для обнаружения бот-угроз и защиты от них. Кроме того, Booking.com компания выбрала HAProxy в качестве основного компонента своей пограничной инфраструктуры за его превосходную производительность после сравнения его с другими программными балансировщиками нагрузки, представленными на рынке.

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


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

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

Чтобы дольше оставаться незамеченным, атака может состоять из множества IP-адресов разных источников. Она может осуществляться ботами или группами реальных пользователей, работающих в унисон с целью отключения вашего сайта. Так было в случае с атаками Low Orbit Ion Cannon (LOIC) и High Orbit Ion Cannon (HOIC), осуществленными хактивистским коллективом Anonymous. Казалось бы, широкий диапазон исходных IP-адресов - это то, что характеризует распределенный характер атаки.

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


#
Укомплектование турелей
Идеальное место для остановки HTTP-потока находится на границе вашей сети. Остановка угроз здесь защищает ваши вышестоящие веб-приложения, сводя к минимуму трафик и системную нагрузку, которые могут повлиять на них, а также на другие сайты и службы, работающие на этих серверах. Это также предотвращает ненужную путаницу при идентификации атаки, проводя четкую линию фронта сражения.

image2
Вы можете классифицировать вредоносные запросы, отслеживая скорость, с которой пользователь выполняет запросы, или помечая HTTP-запросы с аномальными сигнатурами

Балансировщик нагрузки HAProxy получает запросы из Интернета и передает их на ваши веб-серверы. Это позволяет вам охранять периметр.

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

ЗНАЕТЕ ЛИ ВЫ?ALOHA, устройство HAProxy plug-and-play, может защитить вас от низкоуровневых атак на основе протоколов, таких как SYN-флуды, с линейной скоростью благодаря нашему решению для смягчения последствий под названием PacketShield. PacketShield работает на базе NDIV, платформы обработки сетевого трафика с открытым исходным кодом, над которой мы работаем с 2013 года. С тех пор мы тесно сотрудничаем с командой XDP, чтобы привнести в XDP некоторые функции NDIV и заставить NDIV работать поверх XDP.

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

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


#
Настройка ограничений скорости запросов
Для отслеживания действий пользователей по запросам требуется хранилище данных в памяти, которое может идентифицировать возвращающихся клиентов и сопоставлять их действия. Это ключ к установлению пороговых значений, ограничивающих скорость, - возможности отслеживать, сколько запросов кто-либо делает. HAProxy позволяет вам делать это с помощью чрезвычайно гибкого и высокопроизводительного хранилища данных под названием stick tables, уникальной функции HAProxy.

Таблицы привязки предоставляют общее хранилище ключей-значений и могут использоваться для отслеживания различных счетчиков, связанных с каждым клиентом. Ключ может быть основан на чем угодно, найденном в запросе. Обычно это IP-адрес пользователя, хотя это также может быть что-то более конкретное, например IP + UserAgent. Обычно отслеживаемые значения - это количество запросов и частота запросов за определенный период времени.

Таблицы Stick были разработаны в сотрудничестве со StackExchange, сетью сообществ вопросов и ответов, в которую входит Stack Overflow, которая изначально обратилась к HAProxy в 2010 году по поводу внедрения ограничения скорости на основе структуры трафика. Stick tables - это чрезвычайно зрелая и проверенная технология в HAProxy, обеспечивающая многие из ее передовых функций. Если вы новичок в stick tables, вы можете узнать больше, прочитав наш пост в блоге Введение в HAProxy Stick Tables.


#
Определение хранилища
Создайте таблицу stick, добавив stick-table директиву к backend or frontend. В следующем примере мы используем серверную часть-заполнитель с именем per_ip_rates. Выделение серверной части для хранения только stick-table определения позволяет ссылаться на него в нескольких местах по всей вашей конфигурации.

Рассмотрим следующий пример:

backend per_ip_rates
 stick-table type ip size 1m expire 10m store http_req_rate(10s)
view raw
Это настраивает хранилище, которое будет отслеживать ваших клиентов по их IP-адресам. Это инициализирует счетчик, который отслеживает частоту запросов каждого пользователя. Начните отслеживать клиента, добавив http-request track-sc0 директиву в frontend раздел, как показано на рисунке:

frontend fe_mywebsite
    bind *:80
    http-request track-sc0 src table per_ip_rates
view raw
При такой конфигурации все клиенты, посещающие ваш веб-сайт через HAProxy через интерфейс fe_mywebsite, будут храниться в stick-таблице per_ip_rates. Все счетчики, указанные в определении stick table, будут автоматически поддерживаться и обновляться HAProxy.

Далее давайте посмотрим, как эффективно использовать эти данные.


#
Ограничение частоты запросов
Допустим, вы хотели заблокировать любого клиента, выполняющего более 10 запросов в секунду. httpreqrate(10s)Добавленный вами счетчик сообщит о количестве запросов за 10 секунд. Итак, чтобы ограничить частоту запросов 10 в секунду, установите ограничение на 100.

В следующем примере мы добавляем http-request deny директиву для отклонения клиентов, превысивших пороговое значение:

frontend fe_mywebsite
    bind *:80
    http-request track-sc0 src table per_ip_rates
    http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }
view raw
Это правило предписывает HAProxy отклонять все запросы, поступающие с IP-адресов, счетчики stick table которых показывают частоту запросов более 10 в секунду. Когда какой-либо IP-адрес превышает это ограничение, он получит ответ HTTP 429 "Слишком много запросов", и запрос не будет передан ни на один внутренний сервер HAProxy.

Эти запросы будет легко обнаружить в журнале доступа HAProxy, поскольку они будут иметь состояние завершения, равное PR–, что означает, что сеанс был прерван из-за ограничения подключения:

Feb 8 17:15:07 localhost hapee-lb[19738]: 192.168.1.2:49528 [08/Feb/2018:17:15:07.182] fe_main fe_main/<NOSRV> 0/-1/-1/-1/0 429 188 - - PR-- 0/0/0/0/0 0/0 "GET / HTTP/1.1"
view raw
Если вы хотите определить пороговые значения ограничения скорости для каждого URI, вы можете сделать это, добавив файл карты, который связывает каждое ограничение скорости с URL-адресом. Смотрите наш пост в блоге Введение в карты HAProxy для примера.

Может быть, вы хотели бы ограничить скорость только POST-запросов? Это просто сделать, добавив инструкцию, которая проверяет встроенный ACL, METH_POST.

http-request track-sc0 src table per_ip_rates if METH_POST
http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }
view raw
Вы также можете отслеживать злоумышленников, чтобы их запросы отклонялись с помощью кода состояния HTTP 500 с настраиваемой задержкой. Продолжительность задержки устанавливается директивой timeout tarpit. Здесь вы задерживаете любой ответ на пять секунд:

timeout tarpit 5s
http-request tarpit if { sc_http_req_rate(0) gt 100 }
view raw
По истечении времени ожидания ответ, который клиент получает после блокировки, - это внутренняя ошибка сервера 500, что повышает вероятность того, что клиент подумает, что его атака удалась.


#
Атаки Slowloris
Прежде чем перейти ко второму пункту об обнаружении DDoS-атак, выявлении странных шаблонов среди пользователей, давайте быстро рассмотрим другой тип атаки прикладного уровня: Slowloris.

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

Балансировщик нагрузки HAProxy может поддерживать большее количество открытых соединений без замедления работы, чем большинство веб-серверов. Таким образом, первым шагом к защите от атак Slowloris является установка maxconn значений. Во-первых, установите maxconn в global разделе значение, оставляющее достаточно свободного пространства, чтобы на вашем сервере не заканчивалась память, даже если все соединения заполнены, согласно руководству по выбору размера. Затем внутри раздела frontend или a defaults установите значение maxconn немного ниже этого значения, чтобы, если атака поразит один интерфейс, остальные могли продолжать работать.

Далее добавьте две строки в свой defaults раздел:

timeout http-request 5s
option http-buffer-request

view raw
Первая строка заставляет HAProxy отвечать всем клиентам, которые тратят более пяти секунд от первого байта запроса до последнего, с ошибкой HTTP тайм-аут запроса 408. Обычно это относится только к HTTP-запросу и его заголовкам и не включает тело запроса. Однако с помощью option http-buffer-request HAProxy сохранит тело запроса в буфере и применит к нему http-request timeout.


#
Блокирование запросов по статическим характеристикам
Вы видели, как блокировать запросы, превышающие максимальное количество HTTP-запросов. Другой способ выявить и пресечь вредоносное поведение - это отслеживать сообщения, соответствующие шаблону. Шаблоны устанавливаются в HAProxy с помощью списков управления доступом (ACL). Прочитайте наш пост в блоге Введение в списки управления доступом HAProxy, если вы новичок в их использовании.

Давайте рассмотрим несколько полезных списков управления доступом для предотвращения DDoS-атак.


#
Использование списков управления доступом для блокирования запросов
В ряде атак в качестве версии протокола используется HTTP / 1.0, поскольку эта версия поддерживается некоторыми ботами. Эти запросы легко заблокировать с помощью встроенного ACL, HTTP_1.0:

http-request deny if HTTP_1.0
view raw
Вы также можете отклонять запросы, которые содержат заголовки пользовательского агента, не относящиеся к браузеру, такие как curl.

http-request deny if { req.hdr(user-agent) -i -m sub curl }
view raw
Эта строка отклонит запрос, если -m sub часть заголовка запроса агента пользователя содержит где-либо в нем строку curl. -i Делает ее нечувствительной к регистру. Вы также можете проверить наличие других строк, таких как phantomjs и slimerjs, которые представляют собой два безголовых браузера с возможностью написания сценариев, которые можно использовать для автоматизации атаки.

http-request deny if { req.hdr(user-agent) -i -m sub curl phantomjs slimerjs }
view raw
Если у вас есть много строк, которые вы проверяете, подумайте о том, чтобы сохранить их в файл — по одной строке на строку — и ссылаться на него следующим образом:

http-request deny if { req.hdr(user-agent) -i -m sub -f /etc/hapee-1.8/badagents.acl }
view raw
В других случаях злоумышленник, использующий автоматизированный инструмент, будет отправлять запросы, которые вообще не содержат заголовка User-Agent. Они также могут быть отклонены, как в следующем примере:

http-request deny unless { req.hdr(user-agent) -m found }
view raw
Еще более распространенным явлением для злоумышленников является рандомизация отправляемых строк пользовательского агента, чтобы дольше оставаться незамеченными. Часто они исходят из списка подлинных значений, которые использовал бы настоящий браузер, и затрудняют идентификацию злоумышленников.

Здесь пригодится HAProxy Enterprise модуль отпечатков пальцев. Он однозначно идентифицирует клиентов по запросам, даже когда они меняют строку своего пользовательского агента. Это работает путем триангуляции множества точек данных о клиенте для формирования специфичной для него подписи. Используя эту информацию, вы затем можете идентифицировать и динамически блокировать злоумышленников.


#
Черный и Серый списки
Еще одной характеристикой, которую вы могли бы использовать для фильтрации потенциально опасного трафика, является исходный IP-адрес клиента.

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

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

http-request deny if { src -f /etc/hapee-1.8/blacklist.acl }
view raw
Ваш файл blacklist.acl может выглядеть следующим образом:

1.0.1.0/24
1.0.2.0/23
1.0.8.0/21
1.0.32.0/19
1.1.0.0/24
1.1.2.0/23
1.1.4.0/22
# etc.
view raw
Чтобы упростить это, вы можете использовать базу данных GeoIP, такую как MaxMind или Digital Element. Прочитайте наш пост в блоге, используя базу данных GeoIP в HAProxy, чтобы узнать, как это настроить. В качестве альтернативы, эти запросы могут выполняться непосредственно внутри HAProxy Enterprise с использованием встроенного модуля, который обеспечивает оперативное обновление данных и не требует дополнительных скриптов для преобразования в файлы карт. Встроенные модули также обеспечивают меньшее потребление памяти в случаях, когда поиск должен быть детализированным, например, в масштабах города.

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

В следующем примере устанавливается более строгое ограничение скорости для клиентов, IP-адреса которых указаны в greylist.acl:

http-request deny if { src -f /etc/hapee-1.8/greylist.acl } { sc_http_req_rate(0) gt 5 }
view raw
Если вы используете два или более экземпляров HAProxy для резервирования, вам нужно убедиться, что у каждого из них есть список IP-адресов, которые вы внесли в черный список, и что каждый из них обновляется всякий раз, когда вы вносите изменения. Вот место, где использование HAProxy Enterprise дает вам преимущество. Используя модуль под названием lb-update, вы можете разместить свой ACL-файл по URL-адресу и заставить каждый экземпляр HAProxy получать обновления с определенным интервалом.

В следующем примере мы используем lb-update для проверки наличия обновлений каждые 60 секунд:

dynamic-update
    update id /etc/hapee-1.8/blacklist.acl url https://192.168.122.1/blacklist.acl delay 60s
view raw

#
Защита TCP (не-HTTP) сервисов
До сих пор мы в основном рассматривали защиту веб-серверов. Однако HAProxy также может помочь в защите других служб на основе TCP, таких как SSH, SMTP и FTP. Первым шагом является настройка stick-таблицы, которая отслеживает conn_cur и conn_rate:

frontend per_ip_connections
    stick-table type ip size 1m expire 1m store conn_cur,conn_rate(1m)
view raw
Затем создайте или измените frontend для использования этой таблицы, добавив правила отслеживания и отклонения:

frontend fe_smtp
    mode tcp
    bind :25
    option tcplog
    timeout client 1m
    tcp-request content track-sc0 src table per_ip_connections
    tcp-request content reject if { sc_conn_cur(0) gt 1 } || { sc_conn_rate(0) gt 5 }
    default_backend be_smtp
view raw
С помощью обычного backend:

backend be_smtp
    mode tcp
    timeout server 1m
    option tcp-check #For SMTP specifically smtpchk can be used
    server smtp1 162.216.18.221:25 maxconn 50 check
view raw
Теперь каждый клиент может устанавливать одно SMTP-соединение одновременно. Если он попытается открыть второе, пока первое еще открыто, соединение будет немедленно закрыто снова.


#
Задержка подключений
С электронной почтой и другими протоколами "сервер говорит первым" (где сервер отправляет сообщение, как только клиент подключается, вместо того, чтобы ждать, пока клиент что-то скажет, как в случае с HTTP) мы также можем задерживать соединения, добавив следующее после правил, которые мы добавили в block:

tcp-request inspect-delay 10s
tcp-request content accept if { sc_conn_rate(0) lt 2 }
tcp-request content reject if { req_len gt 0 }
view raw
Это немедленно подключит любого клиента, который установил только одно соединение в течение последней минуты. Используется порог менее двух, чтобы мы могли принять одно соединение, но это также позволяет легко увеличить этот порог. Другие подключения от этого клиента будут заблокированы в течение 10 секунд, если только клиент не отправит данные по второму каналу, который мы проверяем с помощью req_len. В этом случае HAProxy немедленно закроет соединение, не беспокоя серверную часть.

Этот тип трюка полезен против спам-ботов или SSH-ботов грубой силы, которые часто переходят прямо в атаку, не дожидаясь появления баннера. При этом, если они запускаются прямо сейчас, им отказывают, а если нет, им пришлось удерживать соединение в памяти еще 10 секунд. Если они откроют больше подключений, чтобы обойти это ограничение скорости, ограничения conn_cur из предыдущего раздела остановят их.


#
Агрегатор таблиц Stick
Использование активных балансировщиков нагрузки HAProxy перед вашими веб-сайтами увеличивает вашу избыточность, защищая вас в случае отключения одного балансировщика нагрузки. Это также обеспечивает дополнительную пропускную способность при отражении DDoS-атаки на основе приложений. Вы можете узнать, как ее настроить, посмотрев наш вебинар по запросу "Создание высокомасштабируемых кластеров АЦП с использованием многопутевой маршрутизации с равной стоимостью BGP".

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

Если вы используете HAProxy Enterprise, включение модуля Stick Table Aggregator решает эту проблему. Это позволяет серверам HAProxy агрегировать все свои показатели количества запросов и статистику и принимать решения на основе суммы данных.

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

изображение 1
Обмен информацией об активности пользователей с помощью пиринга с несколькими балансировщиками нагрузки


#
Модули reCAPTCHA и Antibot
HAProxy не ограничивается простой блокировкой запроса. Иногда вы сталкиваетесь с ситуациями, в которых нет полной уверенности: это бот или группа посетителей, которые появляются с одним и тем же IP только потому, что они находятся за NAT? Требуются более гибкие ответы.


#
Использование серверной части с более низким приоритетом
Если вы хотите разрешить подозрительные запросы к вашему сайту в обычном режиме, когда нагрузки низкие, но ограничить их, когда нагрузки начинают увеличиваться (или выделить дешевую виртуальную машину для подозрительных запросов, перенаправить трафик на статическую версию вашего сайта и т.д.), может помочь использование другого серверного модуля.

Для этого создайте серверную часть с новыми серверами, а затем используйте строку use_backend для направления к ней запросов:

use_backend be_website_bots if { sc_http_req_rate(0) gt 100 }
view raw
Обычно это выполняется в соответствии с http-request deny правилами, которые имеют более высокий порог, например 200, так что чрезмерно агрессивный бот по-прежнему будет получать прямые ответы об ошибках, в то время как боты с более низкой частотой запросов могут получать бэкенд bewebsitebots вместо этого. Если вас беспокоит возврат ошибок даже с более высокой частотой, вы можете добавить { beconn(bewebsite) gt 3000 } только запросы на прямое отклонение, если в настоящее время имеется более 3000 активных подключений к серверной части.


#
Отправка запроса на Javascript
Корпоративный модуль Antibot HAProxy предоставляет способ заставить клиентов генерировать ключ для входа на сайт, который поможет идентифицировать отдельных пользователей за NAT и отделить клиенты, поддерживающие Javascript, от тех, которые этого не делают.

Модуль Antibot запрашивает у клиента решение динамически генерируемой математической задачи. Он основан на идее, что многие автоматизированные DDoS-боты не способны анализировать JavaScript. Или, если это так, это замедляет их работу. Затраты процессорного времени на решение головоломки часто отнимают у злоумышленника ресурсы, за которые он поминутно платит, и, разочарованный, он часто уходит в другое место в поисках более легкой цели.

Просмотрите наш вебинар по запросу "Защита от DDoS-атак и ботов с помощью HAProxy Enterprise", чтобы узнать больше и увидеть демонстрацию модуля Antibot в действии.


#
Задача пользователя разгадать капчу
Модуль reCAPTCHA предоставляет клиенту задание Google reCAPTCHA v2, которое бот не сможет выполнить. Это полезно в случаях, когда бот использует преимущества полноценного браузера, такого как безголовый Chrome или Selenium. Это, как и модуль Antibot, отсеивает нелегитимных пользователей, либо останавливая их на полпути, либо замедляя их работу до такой степени, что им невыгодно продолжать атаку.

Просмотрите наш вебинар по запросу "Защита от DDoS-атак и ботов с помощью HAProxy Enterprise", чтобы узнать больше и увидеть демонстрацию модуля reCAPTCHA в действии.


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

Для отправки запросов боту необходимо отслеживать TCP-соединения, и обычно это делает HAProxy. Таким образом, оба варианта взаимосвязаны, за исключением того, что HAProxy должен одновременно отвечать и другим посетителям. С помощью silent-drop HAProxy скажет ядру забыть о соединении и удобно забудет уведомить клиента о том, что оно это сделало. Теперь HAProxy не нужно отслеживать это соединение. Это заставляет клиента ожидать ответа, который никогда не придет, и ему придется сохранять соединение в своей памяти, используя один из исходных портов, до истечения времени ожидания. Для этого добавьте http-request silent-drop, вот так:

http-request silent-drop if { sc_http_req_rate(0) gt 100 }
view raw
Основным недостатком этого является то, что, предполагая, что правила установлены таким образом, что ни один законный клиент не получит такого обращения, любые сетевые устройства с отслеживанием состояния (а именно брандмауэры) будут сбиты с толку этим, поскольку они тоже не получат уведомления о закрытии соединения. Это заставит эти устройства отслеживать соединения, о которых HAProxy больше не думает, и, кроме того, потреблять память брандмауэра с отслеживанием состояния. Помните об этом, если вы используете такое устройство.


#
Заключение
В этом блоге вы узнали, как защитить свои веб-сайты от атак прикладного уровня, таких как HTTP-флуды и Slowloris, используя встроенные в HAProxy функции для ограничения скорости и пометки подозрительных клиентов. Это защищает ваши веб-серверы и предотвращает попадание вредоносного трафика в вашу сеть.

HAProxy Enterprise предоставит вам несколько необходимых функций для агрегирования данных stick table и проверки подозрительных клиентов с помощью JavaScript или головоломок reCAPTCHA. Эти дополнительные функции гарантируют, что вы получаете полную картину вашего трафика и что обычные пользователи не будут заблокированы из-за ложных срабатываний.

*[https://translated.turbopages.org/proxy_u/en-ru.ru.13450ca9-65f786ff-b85a6c3c-74722d776562/https/www.haproxy.com/blog/application-layer-ddos-attack-protection-with-haproxy Источник]