Разработчик показал, как в Nginx можно просто защитить свой экземпляр Forgejo от веб-краулеров с ИИ

Разработчик Ян Эспозито представил ^[1] простой пример стратегии защиты в Nginx своего экземпляра открытой платформы совместной разработки Forgejo ^[2] от веб-краулеров с ИИ. При этом обеспечивается должный уровень обслуживания платформы Forgejo для обычных пользователей.

«Желательно выполнить замену строки Yogsototh_opens_the_door на ваше собственное имя Cookie. Главное преимущество в том, что это практически незаметно для пользователей моего веб‑сайта по сравнению с другими решениями, такими как Anubis», — пояснил Эспозито.

Put that in your nginx config:

location / {
  # needed to still allow git clone from http/https URLs
  if ($http_user_agent ~* "git/|git-lfs/") {
        set $bypass_cookie 1;
  }
  # If we see the expected cookie; we could also bypass the blocker page
  if ($cookie_Yogsototh_opens_the_door = "1") {
        set $bypass_cookie 1;
  }
  # Redirect to 418 if neither condition is met
  if ($bypass_cookie != 1) {
     add_header Content-Type text/html always;
     return 418 '<script>document.cookie = "Yogsototh_opens_the_door=1; Path=/;"; window.location.reload();</script>';
  }
  # rest of your nginx config

«Не так давно я начал размещать свой код на Forgejo. Проект Forgejo придерживается принципов независимого управления и подконтрольности сообществу. На использование Forgejo перешёл Git‑хостинг Codeberg.org ^[3]..»

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

Но вскоре, через несколько часов, она снова перестал работать. Причина оказалась очевидна: тысячи запросов, которые просматривали каждый коммит, создавали чрезмерную нагрузку на систему. Кому могло быть так интересно использовать веб‑API для просмотра каждого коммита вместо того, чтобы… ну, вы понимаете, клонировать репозиторий локально и изучать его? Быстро, да, как и многие из вас, я обнаружил, что множество веб‑краулеров, не соблюдающих robots.txt, сканируют мой экземпляр Forgejo до тех пор, пока он не выйдет из строя.

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

Затем я установил Anubis, но он мне не подошел. Он слишком ресурсоемкий для моих нужд, и его настройка и установка оказались не такими простыми, как я надеялся.

Затем я увидел статью «Вам не нужен Anubis на lobste.rs ^[4], используйте простую конфигурацию в Caddy, которая должна блокировать этих надоедливых краулеров». Я внёс некоторые корректировки, чтобы адаптировать её к Nginx. Пока что это работает отлично, мои пользователи перенаправляются всего один раз, практически не замечая этого. И они могут использовать Forgejo, как и раньше. И это отгоняет краулеров.

Стратегия довольно простая; на самом деле, гораздо менее продвинутая, чем стратегия, используемая Anubis. При каждом посещении моего веб‑сайта я просто проверяю, установлен ли у пользователя определённый cookie. Если нет, я перенаправляю пользователя на HTML‑страницу с ошибкой ^[5] 418, содержащую некоторый код JavaScript для установки этого конкретного cookie и перезагрузки страницы.

Вот и всё.

Я также пытался вернуть 302 и добавить cookie из ответа без JavaScript, но краулеры невосприимчивы к этой второй стратегии. К сожалению, это означает, что мой веб‑сайт будет виден только при включённом JavaScript в браузере. Я считаю это приемлемым. Думаю, когда‑нибудь этой очень простой защиты будет недостаточно, и мой экземпляр Forgejo снова сломается, и мне придётся использовать более продвинутую систему, такую ​​как Anubis или, возможно, даже iocaine.

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

— пояснил Эспозито.

Ранее инженер пожаловался ^[6], что его новый сайт Brain Baking, который размещался на небольшом сервере, вывели из строя боты, занимающиеся парсингом. Когда разработчик попытался получить доступ к сайту, то столкнулся с необычной задержкой, которая побудила его войти в систему и посмотреть, что происходит. Он выяснил, что экземпляр Gitea и сервер Fail2ban поглощают почти все ресурсы процессора. Закрытие Gitea не повлияло на Fail2ban, поскольку журналы доступа Nginx были переполнены с активными попытками ИИ-ботов сделать своё дело.

Между тем другой разработчик ранее выпустил ^[7] специальный лабиринт с открытым исходным кодом, чтобы заманивать в ловушку обучающих ИИ веб-сканеров в бесконечно и случайно генерируемую серию страниц. Программу под названием Nepenthes могут развернуть владельцы ресурсов.