Kernel.org усиливает защиту от AI-краулеров, генерирующих миллионы запросов в сутки
Инфраструктура Kernel.org столкнулась с резко возросшей активностью автоматизированных систем, которые массово собирают данные для обучения и работы ИИ. Ежедневно серверы проекта обрабатывают миллионы запросов к страницам коммитов, из-за чего значительная часть вычислительных ресурсов уходит не на обслуживание разработчиков, а на генерацию HTML для ск scraper-ботов.
Как рассказал Константин Рябицев, отвечающий за инфраструктуру Kernel.org, один только git.kernel.org получает около шести миллионов обращений в день к отдельным страницам коммитов. Примерно две трети запросов блокируются системой Anubis, однако оставшегося трафика достаточно, чтобы создать серьёзную нагрузку на серверы.
Kernel.org располагает примерно 90 процессорными ядрами, распределёнными между пятью площадками. При этом от 14 до 16 ядер постоянно заняты преобразованием Git-коммитов в HTML-страницы, которые преимущественно запрашивают автоматические сборщики данных. В результате проект тратит больше вычислительных циклов на отображение коммитов для краулеров, чем на все остальные легитимные сценарии доступа, включая обычное клонирование репозиториев.
Проблема усугубляется тем, что вся необходимая информация уже доступна через Git. Пользователь или программа может скачать репозиторий целиком и анализировать историю локально. Однако многие AI-краулеры действуют иначе: они последовательно запрашивают отдельные страницы коммитов, патчи, различия и текстовые представления файлов, создавая огромное количество практически одинаковых обращений.
Масштаб репозиториев Kernel.org делает такую модель особенно затратной. В основном дереве Linux насчитывается около 1,48 млн коммитов, а сама платформа размещает сотни ответвлений. Каждая запись может быть представлена в нескольких форматах, поэтому число потенциальных URL для автоматического обхода практически не ограничено.
Эта ситуация показывает, насколько важна защита сайта от AI-краулеров даже для некоммерческих и открытых проектов. Свободный доступ к данным не означает, что сервер обязан без ограничений обслуживать миллионы ресурсоёмких запросов. Для администраторов крупных платформ задача постепенно превращается в поиск баланса между открытостью информации и устойчивостью инфраструктуры.
Сначала Kernel.org пытался ограничивать трафик с помощью блокировки отдельных IP-адресов и сетей. Но такой подход потерял эффективность после того, как боты начали использовать распределённые residential- и мобильные прокси. Запросы стали поступать с большого числа адресов, принадлежащих реальным операторам связи и домашним пользователям, поэтому простое добавление IP в чёрные списки перестало давать нужный результат.
Следующим шагом стала система Anubis. Перед доступом к ресурсу посетителю предлагается выполнить небольшую задачу proof-of-work, требующую ограниченного количества вычислений. Для обычного пользователя такая проверка почти незаметна, зато массовый сбор данных становится дороже. Тем не менее автоматизированные системы быстро адаптировались и начали решать усложнённые задания в промышленных масштабах.
Опыт Kernel.org демонстрирует, почему одной технологии недостаточно. Защита веб-сайта от DDoS-атак обычно строится вокруг фильтрации сетевого трафика, но AI-краулеры могут генерировать запросы постепенно, распределять их по множеству адресов и имитировать поведение обычных пользователей. В результате формально это не всегда выглядит как классическая атака, хотя последствия для CPU, каналов связи и дисковой подсистемы могут быть сопоставимыми.
В подобных условиях администраторам приходится решать, как заблокировать AI-ботов или хотя бы существенно снизить их влияние, не закрывая доступ разработчикам и исследователям. Среди возможных мер - ограничение числа страниц, доступных для анонимного обхода, введение квот, кэширование результатов и запрет наиболее тяжёлых операций. Дополнительную роль играет настройка WAF для сайта: межсетевой экран может анализировать частоту запросов, характер URL, заголовки и подозрительные шаблоны поведения.
Kernel.org рассматривает именно такой более прямой сценарий. Команда может сократить количество URL, разрешённых для автоматического сканирования, а также ограничить ресурсоёмкие действия для анонимных посетителей. При этом Git-репозитории Linux, история разработки и связанные данные останутся публичными. Речь идёт не о закрытии проекта, а о переходе к более рациональному способу доступа.
Важным направлением становится и оптимизация нагрузки от поисковых роботов. Серверу не всегда нужно заново формировать одну и ту же HTML-страницу для каждого запроса. Кэширование, предварительная генерация популярных представлений, корректные лимиты API и предоставление удобных интерфейсов для пакетной выгрузки могут снизить количество обращений без ущерба для пользователей.
История Kernel.org также подчёркивает изменение характера интернет-нагрузки. Раньше основной проблемой считались поисковые индексы, вредоносные сканеры и сетевые атаки. Теперь инфраструктура вынуждена учитывать мощные ИИ-системы, которые собирают данные в огромных масштабах и способны быстро приспосабливаться к новым ограничениям. Подробное описание ситуации и решений, которые обсуждаются командой, опубликовано в материале о [миллионах ежедневных запросов AI-краулеров к Kernel.org](https://linuxiac.com/kernel-org-battles-ai-crawlers-generating-millions-of-daily-requests/).
Для открытых проектов это особенно чувствительная проблема. Их ценность основана на свободном обмене знаниями, но расходы на хранение, обработку и передачу данных несут конкретные сопровождающие. Если автоматические клиенты используют веб-интерфейс неэффективно, они фактически перекладывают стоимость массового сбора информации на владельцев инфраструктуры.
Вероятно, в дальнейшем Kernel.org будет сочетать несколько механизмов: ограничение анонимного доступа, проверку подозрительных клиентов, строгие лимиты, кэширование и более удобные каналы для легального получения больших массивов данных. Такой подход позволит сохранить публичность исходного кода Linux и одновременно защитить серверы от нагрузки, которая уже заметно влияет на повседневную работу проекта.
