Gegen Spam, Bots, Referrer die htaccess absichern

- htaccess
- spam
0 Rolf B
2 Ryuno-Ki
0 Robert B.
0 Rolf B
0 failxontour
0 Mitleser 2.00 Robert B.
0 Ryuno-Ki
0 failxontour
Hey erster Beitrag, ich buhle direkt nach hilfe. Denke hier bin ich richtig. Lese seit Jahren immer mal wieder als Referenz den Wiki. Kenne das ganze seit meiner Ausbildung 2016 das Projekt , erstmal super Ding hat mir sehr weitergeholfen. Wie kann ich über die .htaccess korrekt gegen Bots mich absichern. Ist jetzt wohl eher eine Frage an Systemadministratoren, Admins, Leute die eigene lokale Webserver noch betreiben. Die Datei ist für einen JTL-Shop den ich mit verwalte. Also eigentlich meine Arbeit. Eigentlich dachte ich verstehe es, doch nach Internet Recherche, ChatGPT befragen bin ich ratlos. Habe meinen Access Log heute früh erneut geprüft nur um festzustellen das weiterhin Anfragen durchgewunken werden. Vielleicht herrscht von meiner Seite aus auch ein Verständnis Fehler was diese Meldungen im Log sind. Nur bräuchte ich eine Erklärung.
Es gibt hierfür natürlich mehrere Plugins, LilFOOT SpamProtector Lite, BotBlock PHP 8.2 Leitfäden von Hosting-Anbietern, nur kann und möchte ich nicht unbedingt dafür jetzt direkt einen Drittentwickler ins Boot holen. Der mit dem Plugin noch die Ladezeit im Frontend auf dem Shop verschlechtert. Gründe finden hierzu sind vielfältig. Wie auch einfach. Die Blacklist der Bots in die robots.txt hereinzuschreiben wirkt ein wenig primitiv auf mich. Da es auch kein anderer der genannten Entwickler scheinbar so macht.
Zum Problem: Ich habe trotz der Regel noch im access log viele Anfragen von KI Scrappern wie GPTbot, Claudebot. Obwohl ich explizit bestimmte User Agents blockiere. Diese denke ich zerren an der Performance von der Seite, Webserver. Verzerren natürlich jegliche Statistik. Gut ich nutze Browserfingerprinting. Doch die Anzahl an echten Anfragen, würde mich schon interessieren. Wenn ich das richtig gesehen haben von im Webalizer sind wir bei ca. ~800.000 Seiten. Ich habe mich ein wenig belesen und mitbekommen, wenn eine Webseite über einen CDN Anbieter wie Cloudflare gehostet wird besteht die Möglichkeit von Region, Bot Blockierung. Das wäre eine mögliche Lösung. Alternativ lässt sich diese Regeln performanter über SetEnvIf definieren. Nur diese Lösung(en) habe ich noch nicht probiert.
Root-Access/SSH-Zugang zum Webserver habe ich an sich nicht, würde mich da auch erstmal nicht ran trauen. Provider für den Webserver ist All-Inkl. Habe einen Kontakt zu denjenigen der wohl als Mittelsmann für uns die Web Server Verwaltung übernimmt. Wir selben haben also direkt keinen Vertrag mit All-Inkl.
Habe 2 Screenshots angehängt. Da ich leider nicht die komplette .htaccess hochladen kann. Aus beachtet gerne die zweite mod_rewrite.c in welcher die Bedingungen festgelegt sind. Ich nutze zum anderen hier die vorgeschriebenen Bedingungen von Apache Ulimate Bad Bot Blocker.
Freue mich und bedanke mich vor ab schon mal für die Aufmerksamkeit und jegliche Hilfestellung. Denke mal der Schwarm wird schon gute Ideen, Vorschläge haben.
Access Log (eingekürzt aus Datenschutz Gründen)
20.171.207.3 - - [13/May/2025:23:59:55 +0200] "GET /120_52__45_5__90_4__50_9__75_66?af=20 HTTP/2.0" 200 48332 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)" "Traffic IN:193 OUT:48803" "ReqTime:0 sec"
40.77.167.255 - - [13/May/2025:23:59:57 +0200] "GET /120_6::marken/vormann__45_5__80_8__120_6__45_84__30_7__gerollt-breit HTTP/2.0" 200 48251 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36" "Traffic IN:299 OUT:48714" "ReqTime:0 sec"
3.145.115.135 - - [13/May/2025:23:59:58 +0200] "GET /T-5__WIHA_1__2-Komponentengriff__T-25__T-30__T-8 HTTP/2.0" 200 48943 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)" "Traffic IN:201 OUT:49265" "ReqTime:0 sec"
Hinweis an den Moderationsrufer: Ich sehe in diesem Beitrag eine legitime Hilfeanfrage. Die Links sind kein Spam, sondern Links zur Shopsoftware, zum Hoster und zu Mitchells Botblocker-Ressourcen. Der Name des Fragestellers führt nach etwas Suche auch zu einem plausiblen Arbeitgeber. Ich habe die Meldung deshalb als unbegründet entfernt.
Hallo Felix,
wenn Du was hinzugefügt hast, sehe ich es nicht. Die beiden Bilder scheinen mir identisch zu sein.
Welche Regel konkret hast Du hinzugefügt?
Irgendwie scheint auch generell dein UserAgent-Blocker unwirksam. ClaudeBot ist in Mitchells Datei drin, und wenn Du die bis zum Ende übernommen hast, dann sollte dafür ein RewriteRule ^(.*)$ – [F,L]
ausgelöst werden und HTTP 403 kommen. Aber es gibt eine 200. Das ist verdächtig.
Das Problem mit den KI-Lutschern haben wir in unserem Wiki übrigens auch. Bisher reicht unsere Serverbandbreite, deswegen haben wir das noch nicht aktiv bekämpft.
Zur Frage nach dem CDN: Ein CDN liefert meines Wissens nur statischen Content, den dafür aber schnell und für hohe Bandbreiten. Du hast einen PHP Shop, den kann ein CDN nicht liefern.
Rolf
upps. Ja fällt mir auch jetzt erst auf. Hier ist der 2. Screenshot. Die Rewrite Rule wird entsprechend angewendet.
Mir ist nicht ganz bewusst, welche Apache Version wir ganz genau benutzen aus <?phpinfo> im Shop selber mir nicht ersichtlich gewesen. Daher hatte ich beide <IfModule> mit in die htaccess genommen.
Danke für den Hinweis mit dem CDN. Das war mir gar nicht klar.
Hallo failxontour,
ich habe übrigens gerade einmal die access.log-Datei für unser Wiki ausgewertet. Wenn ich darin nach "Bot" suche, was ja typisch für Bots ist die sich im Useragent-String zu erkennen geben, bekomme ich ca 5% der Logdatei als Treffer. D.h. die Anfragen zu sperren, die sich explizit als Bot zu erkennen geben, bringt kaum etwas.
Log-Ketten wie diese nerven da mehr:
[15/May/2025:03:41:07 +0200] "GET /api.php?action=opensearch&...&search=di&... [15/May/2025:03:41:07 +0200] "GET /api.php?action=opensearch&...&search=dime&... [15/May/2025:03:41:12 +0200] "GET /api.php?action=opensearch&...&search=dimen&... [15/May/2025:03:41:14 +0200] "GET /api.php?action=opensearch&...&search=dimens&... [15/May/2025:03:41:14 +0200] "GET /api.php?action=opensearch&...&search=dimensi&... [15/May/2025:03:41:15 +0200] "GET /api.php?action=opensearch&...&search=dimensio&... [15/May/2025:03:41:15 +0200] "GET /api.php?action=opensearch&...&search=dimension&... [15/May/2025:03:41:16 +0200] "GET /index.php?search=dimension&title=Spezial%3ASuche&...
Diese Requests sind absolut legitim. Es ist "bloß" ein Besucher, der im Suchfeld des Wiki nach "dimension" sucht. Jeder Tastendruck löst einen Server-Request aus, der bis auf die Datenbank muss.
Nicht legitim ist hingegen die IP 52.169.115.167, die gestern morgen in 4 Sekunden 450 mal die Adresse wiki/Museum/Selfhtml-aktuell abgerufen hat. Und zwar ohne UA-String. Das ist einfach nur Vandalismus, oder vielleicht ein Test auf DoS-Empfindlichkeit, ich weiß es nicht. Aber solche Blödmänner findest Du automatisiert kaum heraus.
Rolf
Moin Rolf,
ich habe übrigens gerade einmal die access.log-Datei für unser Wiki ausgewertet. Wenn ich darin nach "Bot" suche, was ja typisch für Bots ist die sich im Useragent-String zu erkennen geben, bekomme ich ca 5% der Logdatei als Treffer. D.h. die Anfragen zu sperren, die sich explizit als Bot zu erkennen geben, bringt kaum etwas.
… außer die Bots rufen bevorzugt große oder „schwere“ Ressourcen ab und erzeugen so eine hohe Serverlast.
Log-Ketten wie diese nerven da mehr:
[15/May/2025:03:41:07 +0200] "GET /api.php?action=opensearch&...&search=di&... [15/May/2025:03:41:07 +0200] "GET /api.php?action=opensearch&...&search=dime&... [15/May/2025:03:41:12 +0200] "GET /api.php?action=opensearch&...&search=dimen&... [15/May/2025:03:41:14 +0200] "GET /api.php?action=opensearch&...&search=dimens&... [15/May/2025:03:41:14 +0200] "GET /api.php?action=opensearch&...&search=dimensi&... [15/May/2025:03:41:15 +0200] "GET /api.php?action=opensearch&...&search=dimensio&... [15/May/2025:03:41:15 +0200] "GET /api.php?action=opensearch&...&search=dimension&... [15/May/2025:03:41:16 +0200] "GET /index.php?search=dimension&title=Spezial%3ASuche&...
Diese Requests sind absolut legitim. Es ist "bloß" ein Besucher, der im Suchfeld des Wiki nach "dimension" sucht. Jeder Tastendruck löst einen Server-Request aus, der bis auf die Datenbank muss.
Kann man das in MediaWiki tunen? Aus Sicht der Performance braucht man solche Vorschläge üblicherweise erst anzufordern, wenn
Viele Grüße
Robert
Hallo Robert B.,
Kann man das in MediaWiki tunen?
Mutmaßlich ja, aber wir wollen eigentlich vermeiden, in MW-Code einzugreifen. Ob opensearch ein MW-Zentralbestandteil oder eine Extension ist, weiß ich gerade nicht. Wenn Du Lust hast, kannst Dir das Offline-Wiki herunterladen und nach Herzenslust im Code stöbern.
Rolf
Ich betreibe noch ein VPS und nutze Nginx als Reverse-Proxy vor meinen Diensten.
Gerade mein Forgejo bekommt auch regelmäßig „Besuch” von AI-Crawlern, die ich mittlerweile recht zuverlässig über den UserAgent weggeblockt bekomme. Darüberhinaus habe ich auch einige Routen blockieren müssen, weil Werbeanbieter wohl App-SDKs zum Crawlen missbrauchen.
Als Startpunkt bin ich dabei von ai.robots.txt ausgegangen. Persönlich blocke ich aber auch User-Agents, die nicht zwingend ein LLM füttern. Das kann aus SEO-Sicht kontraproduktiv sein (wobei der Suchmaschinenmarkt wegen dieser eh gerade in sich zusammenfällt).
Auf dem Radar habe ich auch Nginx Ultimate Bad Bot Blocker, wobei ich diesen nicht wie beschrieben auszurollen gedenke, sondern mir eher die erstellten Listen von UserAgents anschauen mag.
Robots.txt ist ein Nice-to-have, dass auch befüllt werden sollte (ich denke nicht, dass sich alle Marktteilnehmer daran halten werden).
Neben Webalizer taugt vielleicht auch GoAccess zur Auswertung.
Moin,
Wie kann ich über die .htaccess korrekt gegen Bots mich absichern. […] Habe meinen Access Log heute früh erneut geprüft nur um festzustellen das weiterhin Anfragen durchgewunken werden. Vielleicht herrscht von meiner Seite aus auch ein Verständnis Fehler was diese Meldungen im Log sind. Nur bräuchte ich eine Erklärung.
Hier gibt es in der Tat gleich ein paar Fragen:
robots.txt
, welche nicht?Die Blacklist der Bots in die robots.txt hereinzuschreiben wirkt ein wenig primitiv auf mich.
Die Datei gehört zum Robots Exclusion Protocol, d.h. zumindest „gute“ Bots halten sich daran; das hat den Vorteil, dass Du mit denen sogar „zusammenarbeiten kannst“.
Zum Problem: Ich habe trotz der Regel noch im access log viele Anfragen von KI Scrappern wie GPTbot, Claudebot. Obwohl ich explizit bestimmte User Agents blockiere.
Also zumindest der GTPBot von OpenAI hält sich an die robots.txt
: Auf meinen Seiten ruft der regelmäßig nur diese Datei auf, sieht, dass er nichts indizieren darf und macht das anscheinend dann auch nicht.
Diese denke ich zerren an der Performance von der Seite, Webserver.
Das müssten dann schon sehr viele Zugriffe sein. Sofern sie nur die robots.txt
abrufen und sich an die Regeln dort halten, ist das nur das Ausliefern einer statischen Ressource, das ist nicht teuer.
Verzerren natürlich jegliche Statistik.
Das können „menschliche“ Nutzer doch auch.
Gut ich nutze Browserfingerprinting.
Datenschutzkonform?
Doch die Anzahl an echten Anfragen, würde mich schon interessieren.
Dafür müsstest Du erst einmal definieren, was „echte Anfragen“ sind.
Wenn ich das richtig gesehen haben von im Webalizer sind wir bei ca. ~800.000 Seiten. Ich habe mich ein wenig belesen und mitbekommen, wenn eine Webseite über einen CDN Anbieter wie Cloudflare gehostet wird besteht die Möglichkeit von Region, Bot Blockierung.
Dafür müsstest Du darauf vertrauen, dass diese Anbieter zuverlässig von Dir unerwünschte Zugriffe identifizieren kann. Und diese Anbieter sollten nicht auf Grund eines Ratelimits oder vermuteten Service-Missbrauchs einfach den Dienst für Dich einstellen.
Nach Region zu blockieren ist meiner Erfahrung nach viel zu ungenau:
Das wäre eine mögliche Lösung. Alternativ lässt sich diese Regeln performanter über SetEnvIf definieren. Nur diese Lösung(en) habe ich noch nicht probiert.
SetEnvInf
setzt lediglich eine Umgebungsvariable. Wofür soll das die Lösung sein?
Root-Access/SSH-Zugang zum Webserver habe ich an sich nicht, würde mich da auch erstmal nicht ran trauen. Provider für den Webserver ist All-Inkl. Habe einen Kontakt zu denjenigen der wohl als Mittelsmann für uns die Web Server Verwaltung übernimmt. Wir selben haben also direkt keinen Vertrag mit All-Inkl.
Ihr habt für euren Shop also einen Dienstleister dazwischen, der seinerseits für euch das Hosting über All-Inkl anbietet.
robots.php
statt einer robots.txt
? Diese Ressource muss doch gar nicht dynamisch generiert werden, sondern kann statisch sein.\b
bei den RewriteCond
auf sichAccess Log (eingekürzt aus Datenschutz Gründen)
Das ist lustig, wenn dann die kompletten IP-Adressen wiedergegeben werden 😉 Ich habe die hier mal entfernt:
<…> - - [13/May/2025:23:59:55 +0200] "GET /120_52__45_5__90_4__50_9__75_66?af=20 HTTP/2.0" 200 48332 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)" "Traffic IN:193 OUT:48803" "ReqTime:0 sec"
Wie oben schon beschrieben, hält sich dieser Bot an die robots.txt
<…> - - [13/May/2025:23:59:57 +0200] "GET /120_6::marken/vormann__45_5__80_8__120_6__45_84__30_7__gerollt-breit HTTP/2.0" 200 48251 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/116.0.1938.76 Safari/537.36" "Traffic IN:299 OUT:48714" "ReqTime:0 sec"
Bing ist doch die Suchmaschine von Microsoft. Im Zweifelsfall „findet“ die neue Kunden für Dich.
<…> - - [13/May/2025:23:59:58 +0200] "GET /T-5__WIHA_1__2-Komponentengriff__T-25__T-30__T-8 HTTP/2.0" 200 48943 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)" "Traffic IN:201 OUT:49265" "ReqTime:0 sec"
OK, den müsste ich mir mal genauer anschauen.
Viele Grüße
Robert
Hallo Robert,
den zweiten Screenshot hat er nachgeliefert - der bringt nur nicht viel, weil man den Inhalt auch findet, wenn man dem genannten Link zu Mitchell Krogs Bad Bot Blocker folgt.
Ich bin ganz guter Dinge, die Homepage des TO eruiert zu haben. Nennen wir sie mal... example.org. Indiz ist das dbeS Verzeichnis und der Umstand, dass ich an diese Homepage die im Log gezeigten Pfade anhängen kann und eine sinnvolle Antwort bekomme.
In der robots.txt steht:
User-agent: *
Disallow: /navi.php
Disallow: /druckansicht.php
Disallow: /suche.php
Disallow: /bestellabschluss.php
Disallow: /bestellvorgang.php
Disallow: /jtl.php
Disallow: /pass.php
Disallow: /registrieren.php
Disallow: /warenkorb.php
Disallow: /admin
Disallow: /admin/*
Disallow: /dbeS/*
Disallow: ./well-known/*
Disallow: ./well-known/
Sitemap: https://example.org/sitemap_index.xml
Und das erklärt für mich, warum auch die Bots, die die robots.txt berücksichtigen, fleißig Produktseiten aufrufen. Alle drei gezeigten Log-Einträge werden durch die robots.txt nicht verboten.
Die Frage, wie sie überhaupt an die Produktseiten 'rangekommen sind, beantwortet sich durch die Sitemap. Die ist über 2 MB groß und listet jede Menge Produktseiten auf.
GPTBot und ClaudeBot sollte man, soweit sie compliant sind, durch
User-Agent: gptbot
User-Agent: claudebot
Disallow: /
am Anfang der robots.txt abhalten können (der Bot-Name ist laut RFC 9309 case-insensitive und man kann durch Wiederholen der User-Agent Line eine Zugriffsgruppe für mehrere Bots bauen).
Dieses Git-Repo hilft bei der Liste der AI-Bots. Inwieweit die robots.txt compliant sind, weiß man natürlich nicht.
Rolf
Moin,
sorry das ich erst so spät antworte.
Die Datei gehört zum Robots Exclusion Protocol, d.h. zumindest „gute“ Bots halten sich daran; das hat den Vorteil, dass Du mit denen sogar „zusammenarbeiten kannst“.
Das war mir nicht so ganz Schlüssig und klar, danke für die Erklärung!
Also zumindest der GTPBot von OpenAI hält sich an die
robots.txt
: Auf meinen Seiten ruft der regelmäßig nur diese Datei auf, sieht, dass er nichts indizieren darf und macht das anscheinend dann auch nicht.Das müssten dann schon sehr viele Zugriffe sein. Sofern sie nur die
robots.txt
abrufen und sich an die Regeln dort halten, ist das nur das Ausliefern einer statischen Ressource, das ist nicht teuer.Das können „menschliche“ Nutzer doch auch.
Datenschutzkonform?
Gut ich werde, dann mal wie du geschrieben hast mal die robot.txt
aktualisieren. Claudebot, ChatGPT sollten sich ja daran hoffentlich halten.
Plaudere zu viel. Laut Trackboxx Anbieter selber und unserer doch fragwürdigen momentan aktualisierten Datenschutzerklärung durch meinerseits aus. Ja schon 50%, zum anderen Nutze ich die gratis Variante von Hotjar um Nutzer Ihr Verhalten auf der Webseite auszuwerten. Welche leider naja... eher nicht der Fall ist.
Eventuell die UX zu verbessern. Zu sehen, wo es momentan „Produktiv” zu Fehlern, Abbrüchen kommt. Wobei hier wenig bis nix passiert. Da ich bis Dato vorher, fast komplett blind unterwegs war. Hier im Shop weder UTM - Links noch bisher kaum Ref Links eingebaut sind noch sonst was in die Richtung, da mir dafür bis vor zuletzt Marketing Sachverständnis fehlte.
Ich einfach mit GA nicht um Umfang zurecht kam und es mir Sketchy vorkam. Bei GA4 habe ich, dann die Reißleine gezogen. Das ganze nicht wirklich Zielführend für mich und das Unternehmen denke ich war. Nur für etwas besser, diese ganze Daten-/Rechtsschutzbedenken da ist Google wirklich ein Graus mittlerweile. Don't be evil. Ja klar.. gibt einen Grund warum sie nicht mehr diese Richtlinie für sich benutzen. Wenn ich kann will ich zukünftig hier weniger von Google verwenden und mehr Codebasis von anderen.
Früher mal waren wir Mitglied im Händlerbund müssen dringend mal einen RA für IT-Recht mal kontaktieren um etwaige nicht abgedeckte Tools vielleicht noch mit aufzunehmen. Falls dir was auffallen sollte gerne uns kontaktieren. Ich selber versuche nach bestem Wissen, Gewissen die Datenschutzerklärung aufrecht zu erhalten und zu aktualisieren in Verbindung mit dem Consent-Manager. Das Plugin von DZM lädt er mittlerweile auch so wie man das kennen sollte nach DSGVO nur das was auch notwendig ist nach Zustimmung. Fast nur 8 Jahre später.
Doch die Anzahl an echten Anfragen, würde mich schon interessieren.
Dafür müsstest Du erst einmal definieren, was „echte Anfragen“ sind.
Für mein Verständnis wären Nutzer, von einem User Agent wie Chrome der eine Tatsächliche Seite versucht aufzurufen ein echter Zugriff eines Nutzers. Nicht nur auf eine Mediendatei, versucht irgendwie Daten zu Scrappen, Directory hopping probiert. Um auf versteckte Verzeichnisse zugreifen zu wollen.
SetEnvInf
setzt lediglich eine Umgebungsvariable. Wofür soll das die Lösung sein?
Mir war nur in Gedanken geschnellt, dass eventuell die eine Abfrage Methode vielleicht nicht ganz greift.
Ihr habt für euren Shop also einen Dienstleister dazwischen, der seinerseits für euch das Hosting über All-Inkl anbietet.
Korrekt
Bing ist doch die Suchmaschine von Microsoft. Im Zweifelsfall „findet“ die neue Kunden für Dich.
Bin ich bei dir, möchte auch Bing an sich nicht rausfiltern. Der Zugriff stand nur mit im Access Log. War nicht wirklich einer den ich blockieren wollen würde.
Mit freundlichen Grüßen
Failx
Vielleicht interessierst Du dich einfach für Lösungen wie z.B. https://www.cloudflare.com/?
Moin,
Vielleicht interessierst Du dich einfach für Lösungen wie z.B. https://www.cloudflare.com/?
oder auch nicht 😉
Viele Grüße
Robert
Fefe ist manchmal ganz schön bissig …
Ich würde da eher auf den Wikipedia-Artikel oder Netzpolitik.org verweisen.
Wieviel über das CDN läuft, sehen wir jedes Mal, wenn es gestört ist.
Fefes Blog wirft definitiv berechtigte bedenken auf, egal ob man jetzt bei Wikipedia/Netzpolitik Kritik liest. Wobei ich von Fefe Blog Standpunkt die Bedenken und die harschen Worte relativ gut nachvollziehen kann.
Da Privat alles was ich an Spam/Phishing co. im Web so gesehen, gemeldet, erhalten immer auf Cloudflare lief. Diese halt auch super, reagieren wenn man Inhalte meldet. Nicht. Meist nur mit einer Laschen automatisierten E-Mail, dass man nicht für die Inhalte der Nutzer verantwortlich ist.
Halte ich selber Hands-on nicht viel von Cloudflare. Nach der Kritik, nur noch weniger.