• 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?

Ich habe 3 Seiten Einträge im Admin-CP in den gesperrten IP-Adressen.
Wo genau hast Du die denn da und was bewirken die Einträge? Im Normalfall zielen die doch auf die Registrierung ab - da ein großteil der Bots, die über AWS kommen, aber Content scrapen ohne Registrierung sind die Einträge in diesem Fall wirkungslos. Ausser Du nutzt eine Option, die ich übersehen habe.
 
Wenn ich mir die Liste mit den aktiven Gästen anschaue, dann steht bei denen mit einer gesperrten IP immer so etwas wie „betrachtet gerade eine Fehlermeldung“.
 
Ich hab kein Stress schon Monate. Andy B VPN Reg zu. Registrierung Wartezeit ich glaube 3 Minuten.
Spamer / Bots haben keine 3 Minuten Lust zu warten. Sollte doch mal einer durchkommen, schaue ich mir manuell die Mail an.
Erst dann werden die freigeschaltet.
Selten Stopforum Spam Block.
Bei mir muss man sich erst vorstellen, um alles zu sehen. 1 Beitrag erstellen, dann schalten wir die frei.

Das Teil von AndyB
Block IP blockt Zugriffe welche über VPN, Proxy oder TOR erfolgen sowie Relay access per IP ab
Seit dem Tag der Installation habe ich merklich weniger Meldungen Stopforum Spawn.
 
Zuletzt bearbeitet:
Wenn ich mir die Liste mit den aktiven Gästen anschaue, dann steht bei denen mit einer gesperrten IP immer so etwas wie „betrachtet gerade eine Fehlermeldung“.
Das war jetzt nicht wirklich eine Antwort auf meine Frage. ;)
 
Ich habe 3 Seiten Einträge im Admin-CP in den gesperrten IP-Adressen. Die meisten dieser Bots kamen aus verschiedenen ausländischen Rechenzentren von Amazon AWS. Es waren meistens Rechenzentren im Ausland. Daher habe ich dann den ganzen IP-Bereich gesperrt, z.B. 3.14.*
Dürfte mit meiner aktuell eingesetzten Version (2.2) noch gar nicht umsetzbar sein via ACP?
 
Dem kann, nein...muss ich...leider zu 100% zustimmen...

Männers, bitte helft und unterstützt mich mal. :)

Seit einigen Tagen wird unser Forum wieder von Scharen von Bots heimgesucht...und ich schaffe es bis jetzt einfach nicht sie, zumindest größtenteils, auszusperren. Irgendwie kommen auch immer wieder neue IPs dazu.

Hier mal meine aktuelle htaccess:

Code:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (GPTBot/1.2|PetalBot|YandexBot/3.0|bingbot/2.0|BLEXBot/1.0) [NC]
RewriteRule .* - [F,L]


<Limit GET POST>
order allow,deny
allow from all
#Mehrere einzelne IPs
deny from 93.237.
deny from 146.174.
deny from 114.119.
deny from 52.167.144.0
deny from 40.77.167.0
deny from 157.55.39.0
deny from 207.46.13.0
deny from 87.78.108.0
deny from 134.96.225.0
deny from 176.198.202.0
deny from 88.130.218.0
deny from 80.187.87.0
deny from 20.171.207.0
deny from 80.187.85.0
deny from 217.247.124.0
deny from 79.229.12.0
deny from 95.91.249.0
deny from 109.43.51.0
deny from 79.232.219.0
deny from 82.192.47.0
deny from 207.46.13.0
deny from 157.55.39.0
deny from 185.177.72.0
</Limit>

Scheint, diesmal...warum auch immer...nichts zu bringen. Sehr Ihr eventuell Fehler?

Gerade dieser nervige, wohl FAKE Bingbot fällt mit zehntausenden Crawls auf...und lässt sich einfach nicht davon abhalten...

Unter den IPs sind wohl, sofern ich das auf die Schnelle überblicken kann, auch bspw. deutsche Telekom-IPs dabei. Das kann und darf ja wohl nicht der Weisheit letzter Schluss sein eben solche, und damit eventuell auch ECHTE User, auszusperren.

Btw - auch xenforo.com scheint aktuell betroffen zu sein. Gerade sind dort fast 10.000 (!) "Gäste" online...

Gruß,
Chris
Ich musste die IP-Sperren wieder rausnehmen, da darunter, leider, sehr viel DEUTSCHE IPs sind/waren...und ich somit einige Mitglieder ausgesperrt habe...

Das kann ja nicht Sinn der Sache...und schon gar nicht der Weisheit letzter Schluß sein! :(
 
  • Like
Reaktionen: ehd
JavaScript "Challenge" - Poor Man's Version ohne Garantie

challenge.php
Code:
<?php
header($_SERVER['SERVER_PROTOCOL'] . ' 403 Forbidden');
?><html>
<head>
<meta charset="utf-8" />
<title>Sicherheitsüberprüfung</title>
</head>
<body>
<script>
// Wie lange soll das Cookie gültig sein?
const days = 7;
const date = new Date();
date.setTime(date.getTime() + (days*86400 * 1000));
document.cookie="challenged=1; expires=" + date.toUTCString() + "; path=/";
location.reload();
</script>
<noscript>
Für den Zugriff auf diese Seite ist JavaScript erforderlich
</noscript>
</body>

.htaccess

Code:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{REQUEST_URI} !/challenge.php
# Hier alle UA erlaubter Bots rein, es gibt keine Garantie dass die nicht gefläscht sind - das zu prüfen ist aber komplexer
RewriteCond %{HTTP_USER_AGENT} !(Googlebot|bingbot) [NC]
RewriteCond %{HTTP:Cookie} !(^|;\s*)challenged=1
RewriteCond %{SERVER_PROTOCOL} HTTP/1 [OR]
RewriteCond %{HTTP:Accept-Language} !de
RewriteRule .* /challenge.php [L]

Was macht das ganze?
Clients die HTTP/1 nutzen (das tun ganz viele Dummbots, ein halbwegs aktueller Browser nicht) oder kein de in Accept-Language haben erhalten ein 403 und müssen das JS ausführen - dieses setzt ein Cookie um den Check außer Kraft zu setzen.

Pro
Easy
Impact für normale menschliche User dürfte recht gering sein

Contra
Im Grunde sehr leicht für einen Bot zu umgehen (macht aber +- kaum einer)
Menschliche User mit Uralt-Browser (d.h. kein HTTP/2+ Support) oder nicht-deutschsprachigem Browser kommen in die Challenge; haben sie kein JS aktiviert geht es nicht weiter; haben sie JS aber keine Cookies aktiviert gibt es eine Endlosschleife
 
JavaScript "Challenge" - Poor Man's Version ohne Garantie

challenge.php
Code:
<?php
header($_SERVER['SERVER_PROTOCOL'] . ' 403 Forbidden');
?><html>
<head>
<meta charset="utf-8" />
<title>Sicherheitsüberprüfung</title>
</head>
<body>
<script>
// Wie lange soll das Cookie gültig sein?
const days = 7;
const date = new Date();
date.setTime(date.getTime() + (days*86400 * 1000));
document.cookie="challenged=1; expires=" + date.toUTCString() + "; path=/";
location.reload();
</script>
<noscript>
Für den Zugriff auf diese Seite ist JavaScript erforderlich
</noscript>
</body>

.htaccess

Code:
RewriteEngine On
RewriteCond %{REQUEST_METHOD} GET
RewriteCond %{REQUEST_URI} !/challenge.php
# Hier alle UA erlaubter Bots rein, es gibt keine Garantie dass die nicht gefläscht sind - das zu prüfen ist aber komplexer
RewriteCond %{HTTP_USER_AGENT} !(Googlebot|bingbot) [NC]
RewriteCond %{HTTP:Cookie} !(^|;\s*)challenged=1
RewriteCond %{SERVER_PROTOCOL} HTTP/1 [OR]
RewriteCond %{HTTP:Accept-Language} !de
RewriteRule .* /challenge.php [L]

Was macht das ganze?
Clients die HTTP/1 nutzen (das tun ganz viele Dummbots, ein halbwegs aktueller Browser nicht) oder kein de in Accept-Language haben erhalten ein 403 und müssen das JS ausführen - dieses setzt ein Cookie um den Check außer Kraft zu setzen.

Pro
Easy
Impact für normale menschliche User dürfte recht gering sein

Contra
Im Grunde sehr leicht für einen Bot zu umgehen (macht aber +- kaum einer)
Menschliche User mit Uralt-Browser (d.h. kein HTTP/2+ Support) oder nicht-deutschsprachigem Browser kommen in die Challenge; haben sie kein JS aktiviert geht es nicht weiter; haben sie JS aber keine Cookies aktiviert gibt es eine Endlosschleife
Vielen Dank, Andreas! :)

Ich habe vorerst diese Conditon von AndyB in meine htaccess gepackt:

Code:
<IfModule mod_rewrite.c>
RewriteEngine On
#   Deny and Allow bots by User-Agent
SetEnvIfNoCase User-Agent "bot|crawler|fetcher|headlesschrome|inspect|search|spider|GPTBot|PetalBot|YandexBot|bingbot/2.0|BLEXBot" bad_bot
SetEnvIfNoCase User-Agent "bingbot|duckduckgo|googlebot|yahoo" good_bot
Deny from env=bad_bot
Deny from 47.76.
Deny from 146.174.
Allow from env=good_bot
</IfModule>

Seitdem hatte ich, bis auf den gestrigen Tag (heute passt es schon wieder), keine auffälligen "Besuche" mehr.

Allerdings habe ich gerade ein Problem festgestellt, weiß aber nicht, ob es eventuell mit dem obigen Code in Zusammenhang stehen könnte: Unser Forum ist, mit den gängigen, bekannten Schlagwörtern nicht mehr top gelistet (Google). Entweder ganz raus oder deutlich schlechter. Könnte aber auch nur der berühmte Google-Schluckauf sein. Muss das die Tage mal beobachten.
 
Was sagt den die GSC ???

Und ja - Google saugt unsere Foren erst für die eigene KI aus, und lässt uns nun fallen. Machst du dicht um die KI nicht zu füttern, wirst fallen gelassen, lässt du offen wirst du ausgesaugt (bzw. wurdest bereits) und wirst fallen gelassen. ;)
 
Und irgendwann gibt es nur noch KI-Antworten, denn viele User sind zu faul, um etwas nach unten zu blättern oder um die Quellen aufzurufen. Dann sterben wegen ausbleibender Werbeeinnahmen viele Seiten aus, und es gibt nichts mehr zum Abgrasen für das KI-Training. Über kurz oder lang gibt es dann für neue Themen oder Nischenthemen gar keine freie verfügbaren Infos mehr. Tolle neue Welt.

Jetzt müsste man nur noch einen Weg finden, wie man für die KI-Nutzung entschädigt werden kann.
 
Was sagt den die GSC ???

Und ja - Google saugt unsere Foren erst für die eigene KI aus, und lässt uns nun fallen. Machst du dicht um die KI nicht zu füttern, wirst fallen gelassen, lässt du offen wirst du ausgesaugt (bzw. wurdest bereits) und wirst fallen gelassen. ;)
Du kennst doch Google und die GSC, Otto. Lächerlich! Man erhält eigentlich so gut wie nie wirklich zielführende Hinweise...

Was mir halt aufgefallen ist, dass die Sitemap...angeblich...nicht gefunden wird. Aufrufbar ist sie natürlich...

Habe sie gerade eben einmal neu eingereicht...und den htaccess-Code von AndyB wieder entfernt...

Schaun mer mal, was die kommenden Tage passiert...

Ich befürchte fast, dass Deine Mutmaßung mit dem KI-Aussperren und der damit verbundenen Abstrafung von Google tatsächlich zutreffen könnte...

Eventuell entferne ich, zu Testzwecken, auch noch meine robots.txt...

Wobei man ja sagen muss, dass die meisten KI-Bots ohnehin auf diese Datei kacken...

Gruß,
Chris
 
Da ich nun - trotz bisher gut funktionierender Regeln, seit ein paar Wochen massive Bot Zugriffe habe, hab ich mich mit dem Thema noch mal neu beschäftigen müssen... mal wieder, leider.

Gegen Bots mit eindeutigen User Agents nutz ich nun Server seitig ModSecurity mit einer eigenen Filterregel, die ich beliebig um neue Bot User Agent strings erweitern kann:
Code:
# Schlechte Bots über User-Agent blockieren
SecRule REQUEST_HEADERS:User-Agent "@pm AhrefsBot SemrushBot MJ12bot GPTBot Amzn Turnitin" \
"phase:1,id:100001,deny,status:403,msg:'Bad Bot blocked by User-Agent'"

Denke diese ModSecurity Regel ist selbsterklärend...
Dennoch:
- User Aagents Leerzeichen getrennt
- id: 100001 ist nur eine custom Filterregel-ID
- deny > verweigern
- status 403 > der Bot bekommt nur eine 403 Meldung (Zugriff verweigert)
- msg > die Textnachricht welche ihr dann in den Mod Security logs findet, beliebig festlegbar


Wer eh Nginx verwendet, kann die bekannten Bots (also jene mit gescheitem User Agent) auch noch besser (benötigt weniger Serverleistung) mit einer zusätzlichen Nginx Anweisung direkt vor die Tür setzen (444) oder eine Fehlermeldung präsentieren (403):
Code:
if ($http_user_agent ~* (Amazonbot|Amzn|GPTBot|SemrushBot|ClaudeBot|Bytespider|CCBot|PerplexityBot|Turnitin)) {
    return 444;
}
Das ginge dann je Domain einzurichten - man könnte also auf verschiedene Wünsche schon besser eingehen.


Testen kann man seine Filter dann z.B. per curl auf der Commandozeile:
Code:
curl -I "https://yourdomain.com" -A "GPTBot"
In der Ausgabe sieht man dann den 403er Status (Zugriff verweigert) oder anderen und nicht den 301er (Zugriff erfolgreich).


Bekannte Botnetze mit nicht wechselnden IPs kann man auch über die Firewall entsprechend blocken. Was darüber aus geht - ganze GeoIP Zonen zu sperren/filtern wie z.B. "RU" für Russland oder "SG" für Singapor um mal zwei bekannte Bot-Schleudern anzuführen.



Die echten Problembots (ständig wechselnde IPs und unauffällifge Standard User Agents) kann man am Ende dann wohl nur noch einbremsen über Kniffe wie "limit_req" über Nginx wo man dann noch jene heraus fischen könnte welche zu viele Requests erzeugen.


Es kommt eben drauf an welche Wanze einen nervt die man los haben möchte... ;)
 
Zuletzt bearbeitet:
Hier so nen Kandidaten für die Sperrliste
1787650280447.png

Binnen 1 Stunde 1722 Zugriffe und das von einem Bot von nem Server bei Hetzner (nicht von Hetzner, denke ich, aber dort gehostet)

1787650442320.png

Alle 3 Sekunden dürften in 1 Stunde aber maximal 1.200 Zugriffe sein und nicht 1.722 ;)
 
und wenn's blöd läuft:
ja, bei Google...

Googles IPs kennt man, fangen fast alle mit ner 66 an, die sperrt man sich halt nicht. Und das die AI crawler nicht von Index-Crawlern unterscheiden ist halt auch Mist von Google. Kann man im Thema ja auch nachlesen, das man Cloudflare halt auch entsprechend einstellen kann und aktuell eben die Google AI crawler hinnehmen muss. Google missbraucht auch da mal wieder seine Marktmacht derbe.
 
Was haltet Ihr denn prinzipiell von XF Bot Guard 1.4.1 ?

Ich habe es jetzt einige Tage ausprobiert, mit durchaus gutem Erfolg. Zumindest laut den Logfile und XF-Bot-Guard Protokollen, welche ich ChatGPT zur genaueren Analyse zur Verfügung gestellt habe.

Leider hat sich bei meinem dämlichen Managed Server (Ionos) mal wieder herausgestellt, dass das Teil einfach nur bedingt etwas taugt...und so kam es heute zu massiven Fehlermeldungen wegen Cache-Problemen. Ergebnis: Light-DB deaktiviert und Addon deaktiviert.

Zum Glück steht in Kürze ein Umzug zu Hetzner an.

Alleine das DB-Speicherlimit von nur 15 GB (ursprünglich waren es sogar nur 5 GB...nach laaangen und zähen Verhandlungen, hat man mir dann 15 GB zugestanden!) ist eigentlich heutzutage schon ein No-Go und Ausschlusskriterium. Redis etc. war und ist ebenfalls nicht möglich. Usw. und so fort...
 
Oft kann man sagen - you get what you pay for. ;)

XF Bot Guard ist nicht schlecht - aber gefühlt ein schießen mit Kanonen auf Spatzen.
Wenn du einen eigenen Server hast, lass die Bad Bots gar nicht erst soweit kommen das der Bot Guard eingreifen müsste. Die Bad Boys besser direkt und nachhaltig mit ModSecurity, Firewall und Fail2Ban beglücken - wenn du dort gescheite Regeln aufstellst, hälst du dir einiges an Unkraut draußen.

Hab aber auch das Gefühl das alle im Hype um KI versuchen mit der Brechstange so schnell wie möglich an Trainingsdaten zu kommen - ohne Rücksicht auf die Serverlast, deine Nerven und dein Geld. ;)
 
Was haltet Ihr denn prinzipiell von XF Bot Guard 1.4.1 ?
Prinzipiell halte ich das für durchaus nützlich und hilfreich, allerdings nicht als einziges Tool. Und man sollte sich im Klaren sein, was das Ding tut und wie, denn natürlich hat es auch Limitierungen und ein paar Nachteile bzw. Konsequenzen, die man sich dadurch einhandelt. Ich nutze es, seit es das gibt und kann nicht klagen - es steht bei mir in dritter Reihe der Verteidigungslinien, entsprechend kommt vergleichsweise wenig Traffic dort an (grob zwischen 10 und 60% des kompletten Traffics, abhängig von der Botaktivität im jeweiligen Zeitraum) und was dort ankommt bekomme ich mit meinem derzeitigen Vorgehen auf anderen Wegen nicht weiter ausgefiltert.

Wie viel BotGuard filtert kann ich nicht genau sagen, da ich das Logging zwecks Verringerung der Datenbankgrösse limitiert habe. Mein Forum ist auch recht klein, im Normalfall habe ich am Tag ca 1.200 anfragende IPs, die die erste, recht schlichte Filterhürde überwunden haben, und an schlechten (botreichen) Tagen können das bis zu 7.000 sein. Von denen kommen an normalen Tagen 500-600 (und an botreichen Tagen bis zu 1.500) nach Passieren der zweiten Hürde bei Botguard an. Roundabout 300-600 davon sind "echter" Traffic, der Rest Bots, die man nicht haben will.

Im Vergleich zu dem, was bei anderen Foren auf Botguard einprasselt ist das bei mir also ziemlich wenig Load, durch geringen Traffic einerseits und durch ziemlich rabiates Filtern des Traffics, bevor er bei Botguard ankommt, andererseits. Dennoch hat die DB-Grösse durch Botguard deutlich zugenommen, in meinem Fall sind das nur einige 100MB. Bei großzügigerem Logging und sowieso bei mehr Traffic wäre es aber natürlich deutlich heftiger.

Was Botguard tut ist im Prinzip eine "on stereoids" Variante von dem Java-Script Test, den @Kirby weiter vorne in diesem Thread als einfachen Angang gepostet hat: Via Javascript versucht es, durch Fingerprinting und andere Maßnahmen Bots zu identifizieren und wenn ein Client kein grünes Licht bekommen hat wird er in ein Captcha geschickt.

Jetzt ist die Frage: Wie wirksam ist das? Was man wohl sagen kann: Wenn das Captcha nicht gelöst wird war es wohl ein Bot. Diese Quote lag bei mir lange bei 80-90% der Captchaabfragen. Im Moment ist sie eher bei 30-50%, es ist aber seit einigen Wochen botmässig auch ziemlich ruhig bei mir.

Wie viele Bots bereits im JavaScript Check verenden und gar nicht bis zum Captcha kommen weiss ich nicht - dazu müsste ich mehr loggen als ich tue. Ebenso unklar: Wie viele Bots erfolgreich Check und ggf. Captcha passieren. Die Zahl ist definitiv >0, aber eben deutlich kleiner als ohne BotGuard.

Im Moment sieht das bei mir so aus (es ist wie gesagt sehr ruhig im Forum derzeit):

Bildschirmfoto 2026-08-28 um 15.48.35.png


Das Dashboard ist meiner Meinung nach nicht ganz trivial zu interpretieren, mit am aussagekräftigsten dürfte diese Grafik sein:


Bildschirmfoto 2026-08-28 um 15.49.34.png

Das würde aktuell bedeuten: Von allem, was bei Botguard ankommt kommen ihm so grob 15% irgendwie verdächtig vor und davon wiederum bekommt 1/3 ein Captcha vorgesetzt, das wiederum aktuell gut die Hälfte erfolgreich meistert. Das aktuell ist der Baselayer bei wenig Bot-Aktivität. Bei mehr Bots verändern sich die Zahlen und Prozente ziemlich drastisch.

Mit anderen Worten: Kein Wundermittel, aber eben ein Element mehr als zuvor und bei mir der "Feinfilter". Als solcher funktioniert er gut, ohne Perfektionsanspruch. Im Sinne von: Nutzt was, richtet keinen Schaden an und mir der Load und den Beeinträchtigungen kann ich leben.

Die bestehen eben zum einen im Zuwachs der DB-Grösse (was in Grenzen per Konfiguration oder durch den mittlerweile eingeführten Light-DB-Mode, den ich selbst nie genutzt habe, verringerbar ist), zum anderen in etwas höherer Load, die bei mir (auf Shared Hosting) bislang kein Problem war und ist und zum Dritten in etwas langsameren Seitenladezeiten (die bei mir aber noch im zumutbaren Bereich sind) sowie natürlich der kurzen Störung der Nutzer während des Javascript-Checks (was hinreichend kurz ist).

Das kann (und wird) logischerweise deutlich anders aussehen, wenn jeglicher Traffic ungefiltert auf das AddOn einprasselt und auch, wenn das Forum standardmässig heftigen Traffic hat.

Insgesamt läuft das Ding nach den anfänglichen Updateorgien stabil und ohne Eingriffe von mir und die User haben sich auch nicht beklagt.

Was man im Thread drüben bei XF sieht ist, dass das Add On mittlerweile offenbar zunehmend von Leuten entdeckt und genutzt wird, die nicht die leiseste Ahnung haben was sie tun und was Bot Guard tut oder eben nicht tut (und nicht tun kann) und was die zwangsläufigen Konsequenzen aus dem Einsatz sind, und die auch zu faul sind, die Dokumentation zu lesen oder auch nur zu versuchen, zu verstehen, was da eigentlich passiert und stattdessen sich erfolgreich beim Einsatz in den Fuß schiessen und statt zu lernen oder versuchen zu verstehen irgendeine dämliche KI fragen und den davon ausgespuckten Slop dann dem AddOn Autor vor die Füße kippen als ob sie die weltbahnbrechendste Entdeckung gemacht hätten. Wäre ich er, würde ich ernsthaft überlegen, den kostenlosen Support einzustellen oder zumindest in diesen immer häufigeren Trottelfällen schlicht auf die Dokumentation zu verweisen, denn das, was da mittlerweile passiert ist unnötig, mißbräuchlich und respektlos, speziell bei einem kostenlosen AddOn. Diese Leute erwarten ein Wunder, das es nicht geben kann und eine Lösung des Botproblems mit einem Klick, ohne jede Eigeninitiative, ohne Konfiguration und ohne jedes eigene Wissen oder Lernen durch ein kostenloses AddOn. Das kann nur schief gehen.

"A fool with a tool is still a fool" bleibt also bestehen, dafür kann das AddOn allerdings nichts. In Summe finde ich es durchaus nützlich und würde dazu raten, durch sinnvolle Vorfilterung dafür zu sorgen, dass möglichst wenig überhaupt bei dem Add On ankommt und durch sinnvolle Konfiguration dafür zu sorgen, dass der Ressourenverbrauch im Rahmen bleibt. Und ggf. einzusehen, dass die eigene Situation, die eigene Konfiguration oder die eigenen Fähigkeiten den Einsatz des AddOns nicht sinnvoll erscheinen lassen. Das ist alles kein Hexenwerk und das Add On kein Wundermittel sondern eben ein kleines Element von mehreren bei der Botbekämpfung.
 
Zuletzt bearbeitet:
Zurück
Oben