Разработчик Ян Эспозито представил простой пример стратегии защиты в Nginx своего экземпляра открытой платформы совместной разработки Forgejo от веб-краулеров с ИИ. При этом обеспечивается должный уровень обслуживания платформы 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..»

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

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

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

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

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

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

Вот и всё.

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

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

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

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

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