Methoden, um einige Bots zu blockieren

 (nochan.net)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Eine Zusammenstellung von Methoden, um ohne CDN durch die Kombination von HTTP-Protokoll/IP-Bereichen/Client-Signalen/TCP-Eigenschaften/TLS-Fingerprints/Content-Komprimierung die meisten Bots mit mangelhafter Implementierung oder Konfiguration zu blockieren
  • Alle Methoden müssen selektiv angepasst werden; ohne vorherige Analyse von 1–3 Jahren Access-Logs könnten VPN-Nutzer/Suchmaschinen/CDNs/Schulen/Bibliotheken/Nutzer bestimmter Sprachen mit blockiert werden
  • Das Blockieren von HTTP/1.1-Clients und AS-/CIDR-Bereichen von Rechenzentren kann viele Bots entfernen, kann aber auch Suchmaschinen einschließlich GoogleBot sowie legitime Nutzer in Rechenzentren ausschließen
  • Nginx-Headerprüfungen und nftables-Filter für TCP-Fenstergröße/MSS/TTL reduzieren einfache Crawler und Scanner, können aber in legitimen Umgebungen wie LTE/VPN/Windows False Positives erzeugen
  • Langfristig werden JA4-TLS-Fingerprint-Erkennung und ausschließlich Brotli-Antworten als Alternativen vorgeschlagen; vollständiges Blockieren wird jedoch nicht garantiert, und vor dem Einsatz bei umsatzgenerierenden Diensten wird gewarnt

Blockierumfang und Voraussetzungen für den Einsatz

  • Zuerst sollte entschieden werden, ob das Ziel einige Bots, die meisten Bots oder alle Bots sind
    • Die hier behandelten Ansätze zielen nicht auf sämtliche ausgefeilte Automatisierungstools, sondern darauf, die meisten Bots mit mangelhafter Implementierung oder Konfiguration relativ einfach zu blockieren
    • Für jede Methode wird auch das Risiko angegeben, legitime Nutzer und Suchmaschinen zu blockieren
  • Nachdem der Beitrag am 26. Juli 2026 auf Hacker News geteilt wurde, sollen die meisten Blockierfunktionen vom Blog auf eine separate Demo-Site verlagert werden, sodass daraus ein Puzzle wird, bei dem Leser nach dem Lesen der Methode selbst Zugriffe versuchen
  • Alle Einstellungen können selektiv angepasst oder weggelassen werden; vor einem realen Einsatz sind ausreichende Recherche und Tests nötig
  • Da legitime Nutzer, interne Systeme einer Organisation oder abhängige externe Dienste blockiert werden können, liegt die Verantwortung für den Einsatz vollständig beim Betreiber
  • Nicht in produktiven Umgebungen einsetzen, die Umsatz generieren

Methode 1: Unterscheidung nach HTTP-Protokoll

  • Das Risiko, legitime Nutzer zu blockieren, ist niedrig; das Risiko, einige Suchmaschinen zu blockieren, ist mittel
  • Genutzt wird der Unterschied, dass normale Browser HTTP/2.0 verwenden, viele Bots jedoch HTTP/1.1
    • GoogleBot wird als Nutzer von HTTP/1.1 betrachtet und durch diese Methode blockiert
    • Crawler von Bing und Facebook verwenden HTTP/2.0
    • Dienste, die per HTTP/1.1 Linktitel oder kurze Vorschauen abrufen, können ebenfalls blockiert werden
    • Opera Mini wird ebenfalls ausgeschlossen
  • In Nginx wird konfiguriert, dass bei $server_protocol ungleich HTTP/2.0 auf eine andere Seite umgeleitet oder 200, 403 beziehungsweise 444 zurückgegeben wird
if ($server_protocol != HTTP/2.0) {  
    return 403 'Upgrade your client';  
}
  • Bei Rückgabe von 444 kann die Verbindung ohne separate Antwort geschlossen werden
  • Ob der Nutzen größer ist als der Verlust durch das Blockieren von Google-Suchtraffic, muss jede Organisation selbst beurteilen

Methode 2: IP-Bereiche von Rechenzentren blockieren

  • Das Blockierrisiko für normale Heim- und LTE-Nutzer ist niedrig, für VPN-Nutzer mittel; Suchmaschinen, die in Rechenzentren laufen, haben ein hohes Blockierrisiko
  • In den Access-Logs der letzten 1–2 Jahre werden folgende Signale kombiniert, um verdächtige Requests zu finden
    • HTTP-Protokoll
    • User-Agent
    • Accept-Language
    • Sec-Fetch-Mode
    • Accept
  • Verdächtige IPs werden in BGP Tools oder im Hurricane Electric BGP Toolkit nachgeschlagen, um das zugehörige AS und die angekündigten Prefixe zu prüfen
  • Die bereitgestellte Liste von Netzwerk-Blackholes kann auch CDN- und Suchmaschinen-Bereiche enthalten und muss daher selektiv angewendet werden
  • Vor separaten Listen wird bereits eine Konfiguration genutzt, die die Bereiche 3/8, 10/8, 11/8, 25/8, 26/8, 38/8, 41/8, 60/8, 61/8, 200/8, 224/3 als Blackholes behandelt
  • Nachdem die Prefix-Seite eines AS kopiert wurde, werden per Shell-Funktion nur die CIDRs extrahiert und anschließend sortiert, dedupliziert und zusammengeführt
    • Verwendet wird sum_cidr.pl; dafür ist das Perl-Modul Net::CIDR::Lite erforderlich
    • Das erzeugte Ergebnis wird nach Prüfung in Dateien unter /usr/local/etc/*.netset verschoben
  • Beim Serverstart wird jede CIDR als Blackhole-Route hinzugefügt
for CflIP in $(grep -E ^[1-9] /usr/local/etc/_cloudflare.netset); do  
    /sbin/ip route add blackhole "${CflIP}" 2>/dev/null  
done
  • Im Beispiel wird der gesamte Cloudflare-Bereich blockiert, um keine Requests über Workers und Ähnliches anzunehmen
  • Statt ipset-Regeln in der Firewall wird Routing gewählt, weil Linux-Blackhole-Routing weniger CPU verbraucht
  • Auch der IP-Bereich des Hosting-Anbieters, in dem der aktuelle Server liegt, kann blockiert werden
    • DNS, Konfiguration und interne Dienste dürfen denselben Adressraum nicht verwenden
    • Direkt verbundene Gateway-Routen haben Vorrang vor Blackhole-Routen

Methode 3: Länder/Proxys/Tor/bösartige IPs blockieren

Methode 4: HTTP-Client-Signale prüfen

  • User-Agent und Header können gefälscht werden, aber die Annahme ist, dass einfache Bots, die auf Geschwindigkeit optimiert sind, dies oft nicht korrekt tun
  • Für Requests mit Curl oder Wget wird Klartext zurückgegeben; für Requests mit Bot, GPT, LLM oder Spider wird 410 Gone zurückgegeben
if ($http_user_agent ~* Curl)   { return 200 '\nGNU Terry Pratchett\n\n'; }  
if ($http_user_agent ~* Wget)   { return 200 '\nGNU Terry Pratchett\n\n'; }  
if ($http_user_agent ~* Bot)    { return 410 '1000101'; }  
if ($http_user_agent ~* GPT)    { return 410 '1000101'; }  
if ($http_user_agent ~* LLM)    { return 410 '1000101'; }  
if ($http_user_agent ~* Spider) { return 410 '1000101'; }
  • Einige beobachtete User-Agent-Teilstrings werden mit einem langen regulären Ausdruck geprüft, um Crawler, Scanner und Sammeltools zu blockieren
    • Enthalten sind Teilstrings wie Go-http, Java, libwww, okhttp, urllib, python, nmap, zgrab, semrush, shodan, rss, scrap, crawler, headless, github, facebook, google, bing
  • Vor dem Einsatz sollten 2–3 Jahre User-Agents aggregiert werden, um zu prüfen, ob echte legitime Clients auf den regulären Ausdruck passen
sort access-user-agents.txt | uniq -c | sort
  • Wenn ein passender Request HTTP/1.1 nutzt, wird er mit hoher Wahrscheinlichkeit als Bot behandelt; GoogleBot ist jedoch als Ausnahme zu berücksichtigen
  • Bei HTTP/2.0-Requests wird zusätzlich die IP-Zugehörigkeit mit BGP-Tools geprüft

Sec-Fetch-Mode

  • Sec-Fetch-Mode wird den Access-Logs hinzugefügt; wenn der Wert nicht cors, no-cors oder navigate ist, wird blockiert
if ($http_sec_fetch_mode !~ (cors|no-cors|navigate)) {  
    return 410 '1000101';  
}

Referer-Prüfung

  • Um Requests zu verhindern, die Inhalte von anderen Sites einbetten oder scannen, wird blockiert, wenn der Referer bestimmte Zeichenketten enthält
    • Geprüft werden Zeichenketten rund um Admin-Seiten, Suchmaschinen, soziale Netzwerke, Kryptowährungen, Erwachsenen-Inhalte, Scanner und WordPress
  • Bestimmte Bot-Typen, die die Google-Root-Seite https://www.google.com/ als Referer behaupten, werden ebenfalls separat blockiert
    • Dieses Muster wurde bei Requests beobachtet, die sich als altes Android ausgeben

HTTP-Methoden einschränken

  • Erlaubt werden nur die für normale Browser-Requests nötigen Methoden GET und POST; andere Methoden werden blockiert
if ($request_method !~ (^GET$|^POST)) {  
    return 410 '1000101';  
}
  • In der realen Anwendung können Pfade, die POST benötigen, genauer eingeschränkt werden; falls nicht benötigt, kann POST komplett ausgeschlossen werden

Prüfung auf Proxys und Browser-ähnliches Verhalten

  • Ist der Header X-Forwarded-For vorhanden, wird der Request als Proxy-Request betrachtet und blockiert
    • Auch legitime Shared-Proxy-Umgebungen wie Schulen oder Bibliotheken können dadurch blockiert werden
  • Wenn der User-Agent keines von Linux, BSD, Macintosh, Windows, Mozilla oder WhatsApp enthält, wird der Request als nicht browserähnlich betrachtet
  • Es wird auch eine Regel genutzt, die blockiert, wenn Accept-Language weder en noch es enthält
    • Die Wahrscheinlichkeit ist hoch, dass dadurch einige Browser und legitime Nutzer blockiert werden, die kein Englisch oder Spanisch verwenden
  • Außerdem wird eine optionale Regel vorgestellt, die Spracheinstellungen mit br oder sy separat blockiert

Scans sensibler Pfade blockieren

  • Werden folgende Dateien oder Pfade angefordert, gilt dies als automatischer Scan und wird blockiert
    • .git
    • .yml
    • .db
    • .sql
    • .conf

Methode 5: TCP-Scanner mit nftables blockieren

  • In der PREROUTING-Chain der raw-Tabelle von nftables werden Eigenschaften von TCP-SYN-Paketen geprüft
  • Die Beispiel-Serveradresse 172.238.221.88 wird explizit als Ziel angegeben, um False Positives zu reduzieren, die bei Paketverlust entstehen können
  • Unter den auf Port 80/443 eingehenden SYN-Paketen werden folgende Bedingungen blockiert
    • TCP-Fenstergröße unter 12.288 Byte
    • MSS außerhalb des Bereichs 1.220–1.460
  • Als Kriterium wird genutzt, dass echte Clients größere Fenstergrößen verwenden und MSS-Werte außerhalb dieses Bereichs mit geringer Wahrscheinlichkeit zu legitimen Clients gehören
  • Eine exakte Beschränkung der MSS auf 1460 wäre strenger, kann aber die meisten LTE- und VPN-Nutzer blockieren

Optionale Einschränkung nach TTL

  • Wenn die TTL eines TCP-SYN größer als 128 ist, lassen sich die meisten LTE-Geräte blockieren
  • Wenn die TTL größer als 64 ist, werden auch die meisten Windows-Systeme blockiert
  • Die Standard-TTL-Werte werden wie folgt beschrieben
    • Linux/Mac/BSD: 64
    • Windows: 128
    • LTE: noch größer

Connection Tracking ausschließen

  • Ports 80/443 werden als notrack markiert, sodass Web-Traffic nicht in die conntrack-Tabelle gelangt
  • In diesem Fall müssen auch in der filter-Tabelle zustandslose Regeln für Ein- und Ausgangsrichtung direkt konfiguriert werden
  • Im Beispiel wird Traffic zwischen Client-Quellports 1000-65535 und den Server-Ports 80/443 erlaubt

Methode 6: Erwachsenen-Inhalte und Robots-Header

  • Für Zugangsbeschränkungen bei Erwachsenen-Inhalten wird der Header RTA: Restricted To Adults verwendet
  • Altersverifikationsmethoden außer RTA werden als Mechanismen für Nutzer-Tracking und Monetarisierung betrachtet
  • In Nginx-Antworten werden folgende Header immer hinzugefügt
add_header Rating 'RTA-5042-1996-1400-1577-RTA' always;  
add_header adult 'porn, sex, politics, religion, philosophy' always;  
add_header X-Robots-Tag "none,noindex,nofollow,nosnippet,noai" always;
  • Gewöhnliche Bots können diese Header ignorieren, sie können aber Suchmaschinen oder Bots beeinflussen, die darauf ausgelegt sind, Erwachsenen-Inhalte zu meiden

Methode 7: TLS-Fingerprint-Erkennung

  • Die vorherigen Methoden 1–6 sind allesamt grobe Heuristiken; langfristig kann TLS-Fingerprint-Analyse die bessere Wahl sein
  • JA4 kann genutzt werden, sofern Bots ihren TLS-Fingerprint nicht so ändern, dass er normalen Browsern entspricht
  • Zunächst wird empfohlen, die Deployment-Methode in Deploying JA4 zu prüfen und anschließend FoxIO JA4 einzusetzen

Methode 8: Nur Brotli-komprimierte Inhalte ausliefern

  • Site-Inhalte werden vorab mit Brotli komprimiert, und der Webserver wird so konfiguriert, dass er nur die komprimierten Dateien zurückgibt
  • Dabei wird ausgenutzt, dass viele Bots Brotli-komprimiertes HTML nicht interpretieren können
  • Nach der Anwendung wurde festgestellt, dass mehrere Bots Seitenlinks nicht mehr folgten und HTML offenbar nicht tatsächlich parsen konnten
  • In Nginx wird konfiguriert, statische Brotli-Dateien immer auszuliefern
brotli_static always;
  • HTML-Dateien werden wie folgt vorab komprimiert
cat ./i.html | brotli --best -fncv > ./i.html.br

Methode 9: Scanner zur Selbstidentifikation verleiten

  • Eine separate Methode, um unerfahrene Angreifer und Scanner zu reduzieren, die wiederholt nach Schwachstellenpfaden suchen, wird in Help Attackers Self Report behandelt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Meinungen auf Hacker News

  • Aus der Perspektive von jemandem, der mehrere öffentliche Websites betreibt und andere Websites scrapt, um sie in Tools zu nutzen, frage ich mich, warum Bots die Leute so sehr beschäftigen.
    Selbst ein WordPress mit Cache verarbeitet auf dem billigsten VPS etwa 1.000 Anfragen pro Sekunde, und eine ordentlich gebaute statische Website dürfte das Zehnfache schaffen. Ich frage mich, ob Blogs mit etwas wie Lambda ausgeliefert werden, oder ob es Zwanghaftigkeit ist, Abwehr von Schwachstellen oder eine Gewohnheit aus Zeiten, in denen Crawling echte Dienste beeinträchtigt hat.

    • In meinem Fall ist die Forgejo-Instanz das Problem. Beim Blog ist es in Ordnung, weil es sich um statische Dateien mit begrenzter Seitenzahl handelt, aber Forgejo ist ein dynamischer Dienst, bei dem Bots praktisch unbegrenzt Seiten finden können und bei dem beim Erzeugen mancher Seiten im Hintergrund sogar Git ausgeführt wird; ein kleiner Server ist dadurch schnell überlastet.
      Die Repositories sind Open Source und deshalb absichtlich öffentlich. Derzeit wehre ich mich mit einer einfachen Cookie-Prüfung, durch die nur wenige Bots kommen, aber das ist ein Kompromiss, bei dem ich Sichtbarkeit in Suchmaschinen opfern muss.
    • Meine persönliche Website auf Shared Hosting wurde kürzlich gesperrt, weil ständiges Crawling durch KI-Bots die CPU übermäßig beanspruchte. Nicht das Crawling an sich ist das Problem, sondern dass es zu viele Bots sind und sie ineffizient arbeiten.
    • Es ist ein Experiment aus Spaß daran, gemeinsame Eigenschaften wie JavaScript zu finden, die Bot-Betreiber nur schwer vermeiden oder umgehen können. Dieses Blog besteht aus vorab komprimierten statischen Inhalten auf einer RAM-Disk und dürfte wohl Hunderttausende Anfragen pro Sekunde verarbeiten können.
      Es soll zeigen, wie man das auf Foren, Imageboards, Chatserver usw. anwenden kann; alle Optionen lassen sich anpassen oder abschalten. Vor dem echten Einsatz sollte man es auf einem Testserver prüfen, und es ist auch völlig in Ordnung, einfach darüber zu lachen und weiterzugehen.
    • Zu Hause kann ich keinen 40-Gbit-Anschluss und keinen dazu passenden Server bereitstellen. Wenn ein paar Google-Cloud-VPS nmap und diverse Web-Schwachstellenscans laufen lassen und damit einen Distributed-Denial-of-Service-Angriff auslösen, bricht die Leistung schwacher Hardware leicht ein.
      Dass ich ein paar Sekunden länger brauche, um meinen lokalen IMAP-Server zu prüfen, weil die DMZ blockiert ist, ist kein Weltuntergang; trotzdem gibt es keinen Grund, das gutzufinden oder dauerhaft zuzulassen.
    • Das größte Problem ist, dass mir die Bot-Abwehr Zeit für nützlichere Dinge raubt.
      Am Wochenende habe ich die Weboberflächen viewvc (CVS/Subversion) und hgweb (Mercurial), die ich 10 bis 20 Jahre lang betrieben hatte, abgeschaltet. Von Residential-Proxy-IPs kamen 2,7 Millionen Anfragen pro Tag, im Schnitt 30 pro Sekunde, was alte uWSGI/CGI-Programme und andere Websites auf demselben Server belastete; außerdem näherte sich der Traffic dem VPS-Limit von 1 TB pro Monat.
      Da es Millionen dynamischer VCS-URL-Kombinationen geben kann, ist auch der Cache-Effekt ungewiss, und es lohnte sich nicht, noch mehr Zeit in Server-Tuning zu stecken. Am Ende habe ich mich also für einen Schritt näher in Richtung zentralisiertes Internet entschieden.

  • Wenn man alles außer „zugelassenen“ User-Agents blockiert, hilft man dem bestehenden Browser-Monopol und beschleunigt die Dystopie. Genau vor solchen Problemen warnt RMS seit Jahrzehnten.
    Wenn es ein Problem gibt, sollte man anhand von Traffic-Menge und Anfragefrequenz blockieren. Auch ich kann die Seite nicht aufrufen, werde mein Verhalten aber nicht daran anpassen; wie bei DRM kommen entschlossene Gegenparteien am Ende ohnehin durch.

    • Diese Kritik kann ich akzeptieren. Ich war ein paar Mal mit RMS zusammen; er ist ein interessanter und sehr kluger Mensch, und wenn wir uns wegen dieses Problems getroffen hätten, hätte ich mir vermutlich endlos Vorträge anhören müssen.
      Unabhängig von der Behauptung, man könne jeden Browser verwenden, sollte man jedoch besonders vorsichtig sein bei Browsern, die spontan generierter Code sind oder nicht ausreichend gegen bösartige Websites geprüft wurden. Auch Reader-Apps können gegenüber bösartigen Servern anfällig sein, wenn sie nicht von Penetrationstest-Experten einer umfassenden Drittcode-Prüfung unterzogen wurden.
    • Man kann auch nach Verhalten urteilen. go-away prüft, ob Bilder und CSS geladen werden und ob Meta-Refresh-Weiterleitungen befolgt werden; Anubis prüft, ob einige Sekunden lang JavaScript-Ausführung möglich ist.
    • User-Agent-Strings selbst sind im Großen und Ganzen schädlich. Wenn es ein neuer Browser ist, ist es besser, einfach den Chrome-User-Agent zu kopieren.

  • Mir gefällt die Idee, eine gefälschte cpanel-Subdomain hinzuzufügen, die auf 169.254.169.254 zeigt: Anfänger-Angreifer bringen damit ihren eigenen Hoster dazu, Portscans auszuführen, und können so erkannt oder blockiert werden.

    • Als ich es zum ersten Mal ausprobierte, dachte ich, es würde nichts passieren. Innerhalb weniger Tage versuchte jemand auf Amazon EC2 in Deutschland, Zonentransfers für Teile meiner Domain durchzuführen, offenbar um Records zu finden, die er meiden sollte; danach nahm er meine Domain vollständig aus und die Scans hörten bald auf.
      Die Quell-IPs waren über die ganze Welt verteilt, aber der eigentliche Scan-Lärm kam letztlich von einer einzigen Person.
    • Ich verstehe nicht, warum AWS fail2ban auf dem Instance Metadata Service (IMDS) laufen lassen sollte. Ich frage mich, ob sie ihrer Implementierung nicht trauen oder ob sie Klagen großer Kunden provozieren wollen.

  • IP-basiertes Blockieren sollte mit Vorsicht erfolgen. IP-Bereiche werden gelegentlich neu zugewiesen, sodass man die falschen Leute aussperren kann; ich habe auch mehrfach gesehen, dass Bereiche, die man wegen einer Region oder eines Rechenzentrums blockiert hatte, später an private ISPs übergingen.
    Auch das Blockieren von HTTP/1.1 birgt ein hohes Risiko, echte Nutzer mit alten Browsern auszusperren. Außerdem gibt es Browser, die bei Cross-Origin-Requests nicht die vollständige URL senden; kommt der Traffic über die Google-Suche, kann der Referrer daher nur auf die Google-Startseite zeigen. Wer das vorschnell als Lüge eines Bots wertet und blockiert, kann sich auch den Traffic aus der Google-Suche abschneiden.

    • Leider gibt es auch viele Menschen, deren Netzwerk ohne ihr Wissen an Residential-VPNs weiterverkauft wird.
      Dagegen halte ich das Blockieren von HTTP/1.1 für vertretbar. Seit mehr als zehn Jahren unterstützen fast alle Browser Protokolle darüber hinaus, und ein so alter Browser dürfte ohnehin auf weiten Teilen des Mainstream-Webs kaputtgehen; dass dann noch eine private Website nicht funktioniert, wäre keine Ausnahme, sondern Alltag.
    • Auf Hobby- und Experimentierseiten blockiere ich alle ASNs von Google vollständig. In letzter Zeit habe ich von dort keinen nützlichen Traffic erhalten, und die Suchqualität halte ich ebenfalls für ruiniert.
      Auch wenn dadurch alte Browser und API-Tools außen vor bleiben, werde ich das HTTP/1.1-Blocking beibehalten. Bei proprietärem Code in veralteten Finanzsystemen hätte ich Verständnis, aber das öffentliche Internet muss sich um seiner selbst willen aktualisieren.
      Da ich Google schon seit Langem blockiere, sind alle Requests, die behaupten, von Google zu kommen, gelogen. Ich lasse mein Blog über mehrere zufällige Domains rotieren, um Zuordnungen und Snapshots zu durchbrechen, und versuche zu kontrollieren, über welche Wege Menschen meine Texte finden.
    • Vor ein paar Jahren habe ich Traffic von AWS blockiert und darüber geschrieben. Normalerweise habe ich nur ein paar Dutzend echte Besucher pro Woche, aber diesen Beitrag sahen über etwa drei Monate hinweg 15.000 echte Menschen, und trotzdem war er schnell wieder vergessen.
      Nebenbei bekam ich auch einen kostenlosen Penetrationstest und kam zu dem Schluss, dass meine Abwehrmaßnahmen und die Verarbeitungspipeline robust sind. Durch den Überlebensdruck sind 90 % des Bot-Traffics zu VPNs abgewandert, sodass VPN-Endpunkte wie Weihnachtsbäume aufleuchten.
      Ich könnte auch einen Feed mit Einmal-Zugriffs-IPs anbieten, aber Nutzer müssten ordentlich verifiziert und ihr Einsatzzweck genehmigt werden. Dieser Prozess macht an sich schon Spaß.
    • Der Autor hat ausdrücklich gesagt, dass es für ihn in Ordnung ist, verschiedene Arten echter Nutzer zu blockieren; daher werde ich diesen Rat nicht befolgen.

  • Wenn es nicht lesbar ist, kann man es im Archiv unter https://archive.ph/d3236 ansehen.

    • Für normale iOS-Safari-Nutzer ist das leider eine schlechte Implementierung: https://i.ibb.co/vCDH79d0/IMG-0303.png
      Ich bin kein Bot, möchte aber nicht iCloud Private Relay abschalten, nur um etwas zu lesen. Nach anderen Antworten des Autors ist es als Testseite eine gute Implementierung, aber andere Webadmins sollten möglichst nicht alle Methoden unverändert übernehmen.
    • Interessant ist, dass ich selbst keinen Zugriff hatte, der archive.ph-Crawler aber problemlos durchkam.

  • Da im Antworttext nur 410 und der String Sec-Fetch-Mode: auftauchen, scheint man mich für einen Bot gehalten zu haben. Es gibt nichts zu lesen oder zu sehen, also geht man einfach wieder; das moderne Web ist furchtbar.

    • Echte Browser senden diesen Header, aber manche Reader-Apps und die meisten Bots, die nicht Chrome Headless verwenden, tun das nicht.
      Den Support-Stand sieht man unter https://caniuse.com/?search=sec-fetch-mode, einige Header unter https://nochan.net/.env.
    • Ich kam nicht einmal so weit und bekam PR_END_OF_FILE_ERROR, also kam ich nicht einmal durch den TLS-Handshake.

  • Ich vermute, dass über 99 % des Web-Traffics Bots oder Agents sind, und überlege, die Anzeige der Besucherzahlen zu entfernen. Die Zahlen sind bedeutungslos und lassen die Seite viel stärker frequentiert erscheinen, als sie ist; ich zögere aber mit Gegenmaßnahmen, weil ich befürchte, dass echte Menschen dann meine Texte nicht lesen oder Bücher nicht herunterladen können.

    • Techno-Thriller, Sci-Fi- und Mystery-Romane – das möchte ich mir später einmal ansehen.

  • Wenn Blockieren nötig ist, ist eine Allowlist in der Regel wirksamer als eine Denylist; wenn man keine Allowlist einsetzen kann, ist auch diese Methode möglicherweise keine gute Lösung.
    Tools wie Cloudflare und Anubis können erhebliche Barrierefreiheitsprobleme verursachen, daher bevorzuge ich Rate-Limiting. Es ist sauber, ohne die Zugänglichkeit zu beeinträchtigen, und bei vorübergehenden Problemen funktionieren auch kurze IP-Sperren gut.
    Persönlich analysiere ich mit fail2ban HTTP-Logs und blockiere IPs für N Stunden, wenn sie URLs anfordern, die in robots.txt verboten sind, Pfade wie wp-login.php aufrufen oder zu häufig das Rate-Limit überschreiten. In der Git-Web-UI teste ich derzeit Anubis.

    • In der Kommunikation zwischen Unternehmen haben wir die Allowlist über ein Site-to-Site-VPN umgesetzt. Außerhalb des VPNs ist der Server nicht erreichbar, und Mitarbeitende können über das Firmen-VPN darauf zugreifen.

  • Schon mit fail2ban allein lässt sich ziemlich viel abwehren, allerdings muss man die ersten Monate die Regeln sorgfältig an die eigene Umgebung anpassen.
    Zunächst habe ich mit dem Filter failregex = ^ - \S+ \[\] ".*?" 40[034] erkannt und die Treffer dann in spezifischere Listen übernommen; inzwischen blockiere ich den gesamten Traffic mit rund 80 regulären Ausdrücken, sodass seit Langem keine Requests mehr bis zum allgemeinen 40[034]-Filter durchkommen.
    Hinter einem Load Balancer oder Proxy braucht man allerdings eine Möglichkeit, die echte IP zu bekommen, was sowohl fail2ban als auch die Methode aus dem Original umständlich macht.

    • Die meisten Layer-7-Load-Balancer bieten die Möglichkeit, einen Header mit der echten IP hinzuzufügen. Man muss den Webserver nur so konfigurieren, dass er diesen Header protokolliert; das ist sehr ähnlich dazu, wie CDNs die echte IP weiterreichen.

  • Nach diesen Kommentaren und meinem eigenen Zugriffsversuch sieht es so aus, als würde nicht nur Bot-, sondern auch der gesamte legitime Traffic blockiert.

    • Aus den Kommentaren allein kann leicht ein falscher Eindruck entstehen. Bislang konnten etwa 2.600 Personen und einige Bots den Beitrag sehen.
      Sonntags sieht man am häufigsten die ungewöhnlichen Browser und Apps, mit denen Menschen im Web unterwegs sind; an Wochentagen gibt es mehr normale Mainstream-Browser, was einen guten Test ergibt.