Read the Docs выдержал DDoS-атаку мощностью 5,5 млн запросов в минуту
Understanding the recent DDoS attack against Read the Docs
В июне 2026 года Read the Docs пережил крупнейшую в своей истории DDoS-атаку: пиковая нагрузка превысила 5,5 млн запросов в минуту — в 100 раз выше нормы. Атака длилась почти десять дней, задействовала миллионы IP по всему миру и обходила кэш, используя 404-е и 302-е ответы. Команда рассказывает, как точечные rate limiting, fingerprinting и агрессивное кэширование на edge помогли сохранить доступность без JavaScript-челленджей для всех пользователей.
Атакующие снижали темп, чтобы обнаружить пороги наших rate limit, а затем отступали, давая окнам лимитов истечь. Это называется паттерном йо-йо, и он предназначен для максимизации финансовых затрат на авто-масштабируемую инфраструктуру и создания периодической деградации сервиса.
- PinkSheep
Сочувствую стрессу, который команда испытала, отражая эту атаку. Но мне всегда интересно видеть признаки компетентности на стороне атакующих: целевая, адаптивная атака на уровне приложений (L7)? Вау!
Вот ещё одно предположение: DDoS, чтобы отвлечь ваше внимание и замаскировать другие попытки вторжения.
> Защита должна иметь более широкие ограничения скорости не только по IP (ASN, имена хостов и т.д.).
Описание/подход кажутся статичными и ограниченными? Почему бы не поддерживать «дырявое ведро», которое считает каждый запрос (тикеты/баллы) с более высокой стоимостью для дорогих запросов (404, редиректы). По мере ухудшения репутации IP (IPv4/32) оно начинает переполняться на более широкую подсеть, например IPv4/31, затем /30 и так далее. Боритесь с адаптивностью адаптивностью. // возможно, я описываю совершенно очевидные вещи, я не занимаюсь защитой от веб-DDoS.
> Злоумышленники активно ищут некэшируемые пути (например, динамические редиректы, поисковые эндпоинты и 404).
Продолжая свою предыдущую мысль. Пока ресурсы отдельного сервера позволяют (память, лимит сокетов), задерживайте запросы перед их обработкой. IP с низкой репутацией задерживаются дольше, а запросы, превышающие очередь, отбрасываются. Идея в плавной деградации:
IP с хорошей репутацией не будет задержан с помощью sleep(). IP с плохой репутацией будет задержан, но в конечном итоге получит свой ответ вместо какого-нибудь 429/403 (то есть пользователь, открывший много вкладок сразу). IP с ужасной репутацией будет замедлен временем ожидания + ограничениями скорости (очередь превышена), прежде чем полностью заблокирован […]
- Animats
Я хотел бы видеть больше юридического ответа.
Во-первых, выясните, кто находится на другом конце нескольких сотен IP-адресов. Начните с тех, что в США. Подайте иск о возмещении ущерба. Используйте discovery, чтобы выяснить, что находится на другом конце. Подайте в суд на производителя этого устройства. Если окажется, что это бытовой прибор или «умный» телевизор, возможно, удастся объединить дела в одно против производителя. Преступная халатность, деликтное вмешательство в договор, преследование, нарушение закона о компьютерном мошенничестве и злоупотреблениях...
Может быть, судебный запрет на продажу «умных телевизоров», о которых известно, что они могут быть источником атак. Конфискуйте импорт через Таможенную и пограничную службу. Это привлечёт внимание производителя.
EULA производителя не поможет производителю, потому что истец, сторона, подвергшаяся атаке, вообще не является стороной EULA.
- PinkSheep
> они перегружали жёстко закодированный редирект Nginx (простая директива rewrite с регулярным выражением)
1. Интересно, насколько оптимизирован ngx_http_rewrite_module? Компилирует ли он шаблоны заранее? LLM сказал, что да, этот ответ на SO [1] говорит, что должна быть включена опция JIT-конфигурации. Я считаю «Just in Time» полумерой, когда сама конфигурация статична.
2. Судя по документации NGINX, мне кажется, есть несколько подводных камней при написании таких правил. Например, нужно вручную убедиться, что rewrite-правила замыкаются, чтобы выйти раньше?
3. Подвох с regex в том, что катастрофически откатывающиеся регулярные выражения выглядят просто. Я не вижу, чтобы эту проблему обсуждали достаточно. См. ссылки, если вы, читатель, ещё не слышали об этом.
[1] https://stackoverflow.com/questions/59284921/how-much-impact...
[3.1] https://joshua.hu/nginx-directives-regex-redos-denial-of-ser...
[3.2] https://en.wikipedia.org/wiki/ReDoS
[3.3] https://infrafolks.com/blog/regex-backtracking-devops/
[3.4] https://www.regular-expressions.info/catastrophic.html
- fn-mote
Есть предположение, что включение режима Cloudflare «under attack» смягчило бы атаку.
Учитывая, насколько адаптивной была остальная часть атаки, мне было бы очень любопытно узнать, как она подошла бы к этому препятствию.
- bijowo1676
возможно, это атака под управлением ИИ, и readthedocs был просто тестовой целью.
Что меня удивило, так это то, как легко удалось обойти защиты Cloudflare. Я знаю, что обойти CF было легко, но я ожидал, что CF будет лучше справляться с блокировкой L7 DDoS.
CF действительно хорош в защите от L4 DDoS, но не от L7.
это означает, что Cloudflare на самом деле не очень полезен в эпоху агентных DDoS, управляемых тысячами агентов по всему миру