Serwisy internetowe korzystające z proxy oferowanego przez Cloudflare mogą zastosować nową funkcję zapewniającą blokowanie różnych crawlerów używanych do treningu modeli sztucznej inteligencji. Ochrona nie działa wyłącznie na podstawie filtrowania nagłówka User-Agent, bo niektóre modele „przedstawiają się” jako standardowe przeglądarki internetowe właśnie w celu uniknięcia wykrycia przez administratorów czy różne usługi WAF. Cloudflare opisuje, że zastosowali ochronę opartą na machine learningu, który z kolei skuteczne rozpoznaje narzędzia używane przez modele do indeksowania zawartości witryn WWW. Funkcjonalność dostępna jest także w bezpłatnym planie, a jej aktywacji dokonamy po wejściu w zakładkę Security -> Bots i zaznaczeniu checkbox’a przy opcji Block AI Scrapers and Crawlers.
Zastosowanie wydaje się oczywiste i może mieć duże znaczenie w kontekście ochrony własności intelektualnej. Podany przez Cloudflare przykład wartej około 60 milionów USD umowy pomiędzy Google a Reddit dotyczącej udostępniania danych z tej platformy do trenowania AI od Google świadczy, że takowe usługi są cenne z biznesowego punktu widzenia. Nie widać więc uzasadnienia w bezpłatnym udostępnianiu naszych informacji nawet zaawansowanym botom. Wiadomo oczywiście, że nie każdy serwis zawiera jakkolwiek użyteczne dane, natomiast kwestia ochrony wspomnianej własności intelektualnej powinna być absolutnie kluczowa.
Mimo wszystko warto zwrócić uwagę na inny trend, czyli korzystanie ze „sztucznej inteligencji” do wyszukiwania informacji. Niektóre modele podają źródła, w oparciu o które została wygenerowana odpowiedź, szczególnie gdy prompt dotyczy pewnych statystyk, konieczności przeprowadzania szerszej analizy czy zwyczajnego wyszukiwania treści w Internecie. W tym przypadku ChatGPT poprzez zapytanie do wyszukiwarki Bing podał jako przykład mój artykuł dotyczący GitLab.
Z tego względu dostęp do naszych treści przez różne modele ma także pozytywny aspekt, bo w teorii może mieć wpływ na zwiększenie liczby odwiedzin w docelowym serwisie.
Blokadę botów możemy przeprowadzić także we własnym zakresie, o ile znamy ich źródłowe adresy IP bądź zawartość wysyłaną w nagłówku User-Agent. Druga metoda jest używana częściej i dzięki temu można m.in. zablokować na poziomie serwera WWW dostęp dla crawlerów wyszukiwarek, jeśli chcemy możliwie skutecznie uniknąć indeksowania publicznie dostępnej witryny. Przykłady konfiguracji takiej blokady dla serwerów Apache, NGINX i IIS podano poniżej. User-Agent wykorzystywany przez Googlebot został podany na tej stronie.
Apache
Do pliku .htaccess lub w konfiguracji virtual host wystarczy dodać regułę rewrite.
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^.*(googlebot) [NC]
RewriteRule .* - [F,L]
Odpowiedź serwera:
curl -I -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36" apache.home.local
HTTP/1.1 403 Forbidden
Date: Wed, 10 Jul 2024 14:21:17 GMT
Server: Apache/2.4.52 (Ubuntu)
Content-Type: text/html; charset=iso-8859-1
curl -I apache.home.local
HTTP/1.1 200 OK
Date: Wed, 10 Jul 2024 14:26:04 GMT
Server: Apache/2.4.52 (Ubuntu)
X-UA-Compatible: IE=edge
Link: ; rel="https://api.w.org/"
Content-Type: text/html; charset=UTF-8
NGINX
W location / należy dodać warunek zwracający odpowiedź HTTP 403, gdy w nagłówku znajdzie się fraza pasująca do wzorca.
if ($http_user_agent ~* "googlebot") { return 403;}
Odpowiedź serwera:
curl -I -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36" nginx.home.local
HTTP/1.1 403 Forbidden
Server: nginx/1.18.0 (Ubuntu)
Date: Wed, 10 Jul 2024 14:27:17 GMT
Content-Type: text/html
Content-Length: 564
Connection: keep-alive
curl -I nginx.home.local
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Wed, 10 Jul 2024 14:27:59 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Link: ; rel="https://api.w.org/"
IIS
W pliku web.config pozostaje dodać odpowiednią regułę. Wymagany jest zainstalowany URL Rewrite.
Przykładowa zawartość:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<rewrite>
<rules>
<rule name="Google_block" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_USER_AGENT}" pattern="^.*(googlebot)" />
</conditions>
<action type="CustomResponse" statusCode="403" />
</rule>
</rules>
</rewrite>
</system.webServer>
</location>
</configuration>
Odpowiedź serwera:
curl -I -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36" iis.home.local
HTTP/1.1 403
Content-Length: 1233
Content-Type: text/html
Server: Microsoft-IIS/10.0
Date: Wed, 10 Jul 2024 15:14:02 GMT
curl -I iis.home.local
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
Date: Wed, 10 Jul 2024 15:14:40 GMT
Użycie Cloudflare jako reverse proxy w ogólnych przypadkach jest dobrym rozwiązaniem. Często nie istnieje wtedy możliwość rozpoznania właściwego adresu IP serwera hostującego daną witrynę, ponieważ ruch w pierwszej kolejności zostaje obsłużony przez serwery Cloudflare, które przekażą zapytania klienta do docelowej maszyny — z zewnątrz nasza domena kieruje na adresy należące do Cloudflare. Natomiast jeśli na jednym serwerze hostujemy kilka domen (co jest standardową praktyką) mogących zostać z nami powiązanych (np. inna domena najwyższego poziomu dla tej samej firmy), które nie są dostępne poprzez Cloudflare, to tym sposobem każdy będzie w stanie poznać prawdziwy adres IP serwera.
Należy też mieć świadomość, że istnieją usługi pozwalające na sprawdzenie historii rekordów DNS dla dowolnej domeny. Jeśli wcześniej nie była obsługiwana przez Cloudflare, to możliwe będzie odkrycie np. poprzednich wpisów dla rekordu A (zawierającego adres IPv4), więc także poprzedniego adresu IP. Rozwiązaniem jest migracja witryny na nową maszynę przed dodaniem proxy Cloudflare.
Nie potrzebujemy oczywiście zewnętrznych usług w celu realizacji podobnej do Cloudflare architektury — popularny serwer NGINX bardzo dobrze sprawdza się w roli reverse proxy i z jego użyciem także istnieje możliwość „ukrycia” adresów IP właściwych maszyn, m.in. tych niedostępnych publicznie, a działających wyłącznie w sieci lokalnej. Z drugiej strony Cloudflare zapewnia szereg innych przydatnych funkcjonalności, jak ochrona przed atakami DDoS czy rozwiązanie WAF. Nie jest to oczywiście kompleksowa metoda zabezpieczenia naszej infrastruktury.
Z perspektywy administracji IT pojawia się konieczność dodatkowej konfiguracji. W standardowych sytuacjach, gdy nie korzystamy z żadnego reverse proxy, przez serwer WWW logowany jest faktyczny adres IP klienta, więc stosunkowo szybko można sprawdzić m.in. skąd pochodzą odwiedziny danej domeny, zweryfikować zgłoszone błędy działania aplikacji, jak również zebrać dowody ewentualnych ataków. W przypadku Cloudflare adres klienta także jest ukrywany i do logów zapisany zostaje tak naprawdę adres jednego z serwerów Cloudflare. Rzeczywisty adres klienta można sprawdzić w panelu Cloudflare bądź skonfigurować serwer WWW zgodnie z dokumentacją.
