• Wenn du hier im Forum ein neues Thema erstellst, sind schon Punkte aufgeführt die du ausfüllen musst. Das dient im Allgemeinen dazu die notwendigen Informationen direkt mit der Frage bereitzustellen.
    Da in letzter Zeit immer wieder gerne das Formular gelöscht wurde und erst nach 3 Seiten Nachfragen die benötigten Infos für eine Hilfe kommen, werde ich nun jede Fragestellung die nicht einmal annähernd das Formular benutzt, sofort in den Sondermüll schicken.
    Füllt einfach die abgefragte Daten aus und alle können euch viel schneller helfen.

XF2.2 Extreme Zugriffe ... was ist da los? Wie Bots aussperren?

.. kann man auch ganze URLs ausschließen
wo kann man das?
das hier zum Beispiel:
a.jpg

mit *
also sperre alles mit *.bl.bot.semrush.com
oder direkt
*.semrush.com
das ist keine URL sondern ein Hostname des anfragenden Clients. Das kannst Du in der .htaccess konfigurieren. In den meisten Fällen würde bei sowas alternativ das Blocken des ASNs, zu dem die IP gehört, wirksamer sein - der Hostname ist ein ziemlich windiges Kriterium, da er von der Clientseite konfiguriert werden kann und so einer gewissen Beliebigkeit unterliegt. Die IP in Deinem Beispiel gehört in der Tat zum Netzblock von Semrush:

Bildschirm­foto 2026-10-18 um 11.56.51.png

Den kompletten ASN AS209366 zu blockieren ist also gewiss kein Fehler. Falls die mehrere Netzblöcke haben oder aber auch Hosts in anderen Netzblöcken nutzen ist das nicht hinreichend - das merkst Du dann aber schon.
 
Die neueste Version von IP Threat Monitor (1.0.49) kann nun auch Captchas für ausgewählte Länder und ASNs ausspielen, damit ist dieses Problem gelöst und der dadurch bedingte Anlass auf Cloudflare zu wechseln entfallen. Leider führt das zu einem Konflikt mit dem Bot-Guard Add On, da nun im Captcha Fall beide Add Ons gleichzeitig versuchen einen Redirekt auf unterschiedliche Seiten zu machen - Deadlock. Ist aber wohl eine Frage der Zeit, bis das gelöst ist.
Ist nun in 1.0.50 gelöst. Allerdings funktioniert in meiner Konfiguration IP Threat Monitor nun so gut, dass ich überlege, ob ich auf Bot Guard nicht künftig ohnehin verzichten kann:
• zahlreiche Länder und böse ASNs sind ohnehin blockiert, kommen also gar nicht bis zu Bo Guard
• Länder bzw. ASNs in denen eine Mischung von residential Proxies und echten Gästen gegeben ist (also bei mir z.B. der DACH Raum, aber auch Benelux, Frankreich, Spanien und diverse andere Europäische Länder) bekommen nun standardmässig ein forced Captcha für Gäste. Also das, was Botguard nach eingehender Untersuchung ggf. auch ausspielen würde. Falls die Bots das nicht lösen können kommen sie nicht bis zu Bot Guard, können sie es lösen können sie auch das von Bot Guard lösen. Echte Gäste bekämen hingegen 2 mal hintereinander ein Captcha - ziemlich nervig. Und einen Mehrwert bzw. mehr Sicherheit erzeugt es auch nicht.

Bot Guard zusätzlich zu IP Threat Manager hätte also aktuell in zwei Situationen einen Vorteil:

• Für Länder/ASNs/Besucher, die in IP Threat Manager weder hart geblockt noch mit einer Challenge belegt sind. Aus denen bekomme ich aber kaum Besucher, ergo kein Problem.
• Falls man in Bot Guard ein anderes Captcha einstellt als in IP Threat Manager. Das it möglich: IP Threat Manager nutzt das Captcha, das in XF für die Registrierung eingestellt ist. Bot Guard kann hingegen unabhängig davon ein beliebiges der in XF grundsätzlich vorhandenen Captcha Optionen nutzen. Man könnte also nun z.B. in Bot Guard ein Text Captcha (Frage-Antwort) definieren und damit ggf. Bots abfangen, die in der Lage sind CF Turnstile zu lösen (das bei mir in IP Threat Manager genutzt wird). Ist aber vielleicht etwas over the top.

On another note: Es gibt mittlerweile ein weiteres Add On, das in die gleiche Kerbe schlägt wie IP Threat Manger und Bot Guard und eine Alternative dazu ist: Bot Schilde von XenCustomize:


Das ist gestern erschienen, also brandneu. Erfahrungen damit gibt es entsprechend noch nicht. Da ich mit meiner bisherigen Lösung sehr zufrieden bin und bei dem Neuen keinen Vorteil sehe werde ich es btw auch nicht ausprobieren.
 
Erzeugt der Robot Meta External Agent, IP aus dem Bereich 57.141.22.x bei euch auch eine Menge Traffic? Er versucht auch viele gesperrte Dinge aufzurufen.
 
Erzeugt der Robot Meta External Agent, IP aus dem Bereich 57.141.22.x bei euch auch eine Menge Traffic? Er versucht auch viele gesperrte Dinge aufzurufen.
Das ist der Netzbereich von Facebook AS32934. Ist bei mir schon lange gesperrt. Im XF Forum berichten einige, dass das Teil Amok läuft. Der Bot ist der KI-Trainings-Bot von Facebook/Meta - rausschmeissen ist also mehr als sinnvoll.

Meta-ExternalAgent​


Der Meta-ExternalAgent-Crawler durchsucht das Web nach Anwendungsfällen wie dem Trainieren von KI-Modellen oder der Verbesserung von Produkten durch die direkte Indizierung von Inhalten.
Der spezifische UA-String, der in deinen Protokolldateien angezeigt wird, ähnelt einem der folgenden:
  • meta-externalagent/1.1 (+/documentation/sharing/webmasters/web-crawlers)
  • meta-externalagent/1.1

Die Google KI-Übersicht sagt:

Bildschirm­foto 2026-10-21 um 13.53.36.png
 
  • Like
Reaktionen: mph
Ein XenForo Add-on zur Bot-Abwehr klingt nach einer einfachen Lösung - zunächst, hat aber einen entscheidenden Nachteil: Es greift erst, wenn die Anfrage bereits bei XenForo angekommen ist.

Bis dahin hat der Server schon einiges an Arbeit geleistet. Die Anfrage wurde vom Webserver verarbeitet, PHP gestartet und Teile von XF geladen. Das kostet Rechenleistung, Arbeitsspeicher und vor allem wertvolle PHP Prozesse.

Bei wenigen Bots fällt das kaum ins Gewicht. Wenn aber hunderte oder tausende Anfragen gleichzeitig eintreffen, können diese Prozesse schnell ausgelastet sein. Das Ergebnis: Das Forum wird langsam oder ist im schlimmsten Fall nicht mehr erreichbar obwohl das Add-on die Bots erfolgreich blockiert!

Deshalb ist es wesentlich sinnvoller, unerwünschte Anfragen möglichst früh abzufangen, beispielsweise über die Firewall, nginx oder einen vorgeschalteten Botschutz wie Anubis. So erreichen viele dieser Anfragen XF erst gar nicht und verbrauchen auch keine PHP-Ressourcen.

Ein Add-On kann durchaus eine sinnvolle Ergänzung sein, etwa beim Schutz vor Spam oder unerwünschten Registrierungen. Als Schutz gegen massenhaften Bot-Traffic ist es aber die falsche Stelle und unwirksam.

Vereinfacht gesagt: Es ist effizienter, unerwünschte Besucher bereits an der Eingangstür abzuweisen, als sie erst durch das ganze Haus laufen zu lassen, um ihnen dann zu sagen, dass sie nicht willkommen sind. :)
 
Ein XenForo Add-on zur Bot-Abwehr klingt nach einer einfachen Lösung - zunächst, hat aber einen entscheidenden Nachteil: Es greift erst, wenn die Anfrage bereits bei XenForo angekommen ist.
Architektonisch ist das natürlich nicht optimal. Das ist auch nicht neu sondern steht bereits mehrfach hier im Thread. Die Frage ist, wie praxisrelevant das im Einzelfall ist.
Bis dahin hat der Server schon einiges an Arbeit geleistet. Die Anfrage wurde vom Webserver verarbeitet, PHP gestartet und Teile von XF geladen. Das kostet Rechenleistung, Arbeitsspeicher und vor allem wertvolle PHP Prozesse.

Bei wenigen Bots fällt das kaum ins Gewicht. Wenn aber hunderte oder tausende Anfragen gleichzeitig eintreffen, können diese Prozesse schnell ausgelastet sein. Das Ergebnis: Das Forum wird langsam oder ist im schlimmsten Fall nicht mehr erreichbar obwohl das Add-on die Bots erfolgreich blockiert!
Hast Du denn Erfahrungen mit Bot Guard? Hört sich nicht so an. Das ist also Mäkeln auf Basis grauer Theorie. Das Add On geht ziemlich sparsam mit Ressourcen um. Natürlich schützt es nicht gegen DDOS - das ist aber ja auch gar nicht das Ziel. Wer sich dagegen schützen will sollte Cloudflare oder Änliche Lösungen nutzen. Aus der eigenen Erfahrung: Auf meinem etwas performanteren Shared Hosting Account fängt bei ca. 3.000 Anfragen/Minute XF an merkbar langsamer zu werden, funktioniert aber noch im zumutbaren Bereich. Das war eine Botwelle aus dem Rechenzentrum von Hetzner zu einem Zeitpunkt, bevor ich IP Threat Monitor installiert hatte. Ohne IP Threat Monitor sind die Anfargen alle auf XF durchgeschlagen und mussten entsprechend bedient werden. Mit IP Threat Monitor werden diese Anfragen nahezu komplett vorher abgefangen und zwar im Vergleich deutlich ressourcenschonender. Vergleichbare Peaks hatten keinen Effekt auf die Seitenperformance.

Jetzt gibt es natürlich noch deutlich grössere Wellen und irgendwann kommen aus einem shared hosting so oder so Rauchwölkchen. Die Frage ist also, wovor Du Dich schützen möchtest und welchen Kompromiss Du dafür bereit bist einzugehen. Cloudflare kann guten Schutz bieten, die Konfiguration ist aber komplex, Du lässt eine amerikanische Firma die Verschlüsselung zwischen User und Forum brechen, CF selbst explodiert bekanntlich auch immer mal wieder und dann ist da noch das CF Problem mit der deutschen Telekom... Zudem ist der Schutz eben verlässlich gegen Load, aber nur begrenzt verlässlich gegen Inhaltsklau und CF ist am Ende eine große Blackbox, die Du vor das Forum hängst.

Deshalb ist es wesentlich sinnvoller, unerwünschte Anfragen möglichst früh abzufangen,
Natürlich, architektonisch ist das sinnvoll. Übrigens nicht nur wegen Load. Es ist immer Problematisch, wenn eine Schutzsoftware auf dem zu schützenden System selbst läuft. D.h. konzeptionell sind aus security architektonischen Aspekten eine Firewall auf dem Server oder Nginx nicht wirklich dramatisch besser als ein Add On, auch wenn sie performancevorteile bieten.
Ein AddOn hat dafür den unschlagbaren Vorteil, dass es Forenmitglieder erkennen kann und auch was über die Inhalte des Forums weiss. Dinge, bei denen Deine Lösungen dumm dastehen.

Wie gesagt: Machen kann man das alles und alles hat seine Vor- und Nachteile. So, wie Du das beschreibst ist das aber noch nicht mal die halbe Wahrheit.
beispielsweise über die Firewall, nginx oder einen vorgeschalteten Botschutz wie Anubis. So erreichen viele dieser Anfragen XF erst gar nicht und verbrauchen auch keine PHP-Ressourcen.
Kann man alles machen, ist für jemanden, der shared Hosting nutzt, aber keine Option. Um den ganzen Kram ordentlich zu konfigurieren muss ein wenig mindestens halbsolides IT-Wissen vorhanden sein und das haben viele Forenbetreiber nicht (und wollen es auch nicht erwerben). Die Frage ist, ob das nötig ist. Man kann auch mit dem Sattelschlepper zum Bäcker fahren, falls man mal mehr Brötchen kaufen möchte. Für die meisten ist das Overkill.
Ein Add-On kann durchaus eine sinnvolle Ergänzung sein, etwa beim Schutz vor Spam oder unerwünschten Registrierungen. Als Schutz gegen massenhaften Bot-Traffic ist es aber die falsche Stelle und unwirksam.
Das ist schlicht kompletter Blödsinn. Ich mache das schon eine ganze Weile und es funktioniert wunderbar. Offenbar sogar besser, als bei vielen die Variante über Cloudflare, wenn man den entsprechenden Thread drüben mit liest. Du scheinst auch zu den Leuten zu gehören, die Bot-Traffic ausschliesslich mit "Load" gleichsetzen und dabei das Ziel, Scrapen zu verhindern zwecks Vermeiden von Contentklau und Schutz der Privatsphäre der Forenmitglieder komplett zu ignorieren.
Vereinfacht gesagt: Es ist effizienter, unerwünschte Besucher bereits an der Eingangstür abzuweisen, als sie erst durch das ganze Haus laufen zu lassen, um ihnen dann zu sagen, dass sie nicht willkommen sind. :)
Schlechte Metapher. Du willst potentielle Besucher schon am Flughafen in einem anderen Land abweisen oder allerspätestens am Ortsschild. Im Normalfall reicht Abweisen am Gartentor oder der Haustür und das ist deutlich einfacher umzusetzen.
 
Zurück
Oben