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

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

Это не было обучением роботов. Если бы его скопировали для обучения ИИ, весь сайт можно было бы скопировать за считанные минуты. Поведение было ближе к атаке на истощение ресурсов, но не имело четкого мотива или единой идентифицируемой сигнатуры. Хуже того, я был далеко не один. В Reddit, группах Slack и сообществах WordPress бесчисленное количество владельцев сайтов сообщали о почти одинаковых закономерностях, часто ссылаясь на одни и те же географические источники.

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

Почему это движение было так трудно остановить?

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

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

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

Почему кэширования ресурсов CDN недостаточно?

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

Поворотный момент наступил, когда я понял, что мне нужен CDN, который действовал бы как настоящий внешний межсетевой экран, а не просто уровень производительности. Я потратил часы, пытаясь настроить Банни, но безрезультатно. Я уверен, что люди с большим опытом работы с NGINX и инфраструктурой могли бы это понять, но это было выше моего понимания. А если вы эксперт по инфраструктуре, есть несколько отличных ресурсов, которые ее отслеживают. точные IP-адреса, которые следует заблокировать.

FlyWP, где я управляю WordPress на Linode, предлагает глубокую интеграцию с Cloudflare, которая ставит Cloudflare прямо перед сайтом, обеспечивая правила брандмауэра, защиту от ботов и проблемы до того, как трафик попадет в PHP или MySQL. Это различие имеет значение. В этом разница между поглощением атаки и ее отражением.

Идентификация географической закономерности

Когда Cloudflare была полностью интегрирована, сама видимость открыла глаза. Большая часть вредоносного трафика сконцентрировалась вокруг двух стран: Китая и Сингапура. Это не означает, что весь трафик из этих регионов является вредоносным. У меня есть законные читатели и партнеры по всему миру. Однако характер злоупотреблений был очевидным, постоянным и совершенно непропорциональным реальному поведению пользователей.

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

Почему интерактивные задачи работали, когда блоки терпели неудачу

Cloudflare предлагает несколько вариантов смягчения последствий, но полная блокировка — грубый инструмент. Я никогда не хотел полностью отказывать в доступе на основании географии. Вместо этого я использовал интерактивный вызов.

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

Этот единственный шаг изменил все. После того, как вчера вечером я начал испытание, я заметил устойчивое падение. Однако количество запросов в течение 24 часов просто поражает!

Через несколько минут после включения правила нагрузка на сервер вернулась к норме. Подключения к базе данных стабилизировались. Стоимость CDN перестала расти. Боты не адаптировались.

Как настроить правило Cloudflare

Само правило удивительно простое. Внутри Cloudflare Безопасность > Правила безопасностисоздайте новое правило со следующей логикой.

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

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

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

Почему это наконец решило проблему

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

Не менее важно и то, что это решение масштабировалось. Ротация IP больше не имела значения. Структура спроса больше не имела значения. Даже если трафик немного изменился в географическом отношении, аналитика Cloudflare сделала корректировку правила тривиальной.

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

Более широкое предупреждение издателям

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

Речь идет не о SEO, индексировании или обучении искусственному интеллекту. Речь идет об автоматизированных системах, которые широко используют открытость Интернета. Если вы видите внезапные всплески трафика, которые не приносят конверсий, не привлекают внимания и не имеют смысла, доверьтесь своей интуиции. Посмотрите на географическое распределение. Посмотрите пути запроса. Посмотрите на аномалии затрат.

Вы, вероятно, не одиноки.

Заключительные мысли

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

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