Neu Sprunghafte Zunahme von Visits bei JTL Shops

[lj-shadow]

...oder Plesk Obsidian hat erweiterte Filterregeln...

Nö - hat's nicht

 

[_simone_]

Also am aktivsten aktuell ist bei mir:

114.119.128.0/18, wobei der Block nicht ganz voll ist. Bei 114.119.167.X ist ende.
Der Block allein macht 3/4 der gesperrten etwas über mittlerweile 7300 IPs aus

Dann gehts weiter mit
159.138.144.0/20

Dann ist im 159.138er Block noch kleinkram

Ist ja lustig; genau die Range 114.119.*.* hat vor ein paar Tagen ein Forum lahmgelegt, welches ich betreue. Das ist ja noch vergleichsweis gut zu regeln, aber gestern kamen jede Menge unterschiedliche IPs, auch aus dem Huawei-Umfeld, die für kurze Zeit den Server gefloodet haben, dann waren sie wieder weg. Das Spielchen ging so lange, bis ich über 10.000 IPs +IP-Ranges aus so einer Chinaliste (https://www.countryipblocks.net/acl.php) gesperrt habe. Seit dem ist Ruhe.

 

[lj-shadow]

Naja, ich habe

114.119.128.0/18 und 159.138.144.0/20

jetzt per Firewall gekickt und im F2B wieder aus der Sperrliste genommen, damit ich etwas Überblick habe.
Die beiden Ranges waren bei mir der Quell des Übels. Seitdem die in der FW drin sind, ist Ruhe und von >6000 gesperrten IPs sind jetzt noch ~175 enthalten.

 

[css-umsetzung]

Bei einem Kunden der vor längerer Zeit massive Fake Anmeldungen aus den Asiatischen Gebieten hatte habe ich im letzten Jahr auf dem Server direkt das mod geoip installiert gehabt welches die auch blockt und das dann wieder mit Fail2Ban verknüpft

<FilesMatch "(registrieren\.php|bestellvorgang\.php)">
    SetEnvIf GEOIP_COUNTRY_CODE JP  BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE KP  BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE KH  BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE KR BlockCountry
    SetEnvIf GEOIP_COUNTRY_CODE HK  BlockCountry
    Deny from env=BlockCountry
</FilesMatch>

da ist es auch ruhig

 

[Groundhog]

Tjo, auch hier ebenfalls das gleiche Verhalten. Die Sache begann im Dezember und weist immer wieder hohe Ausschläge aus. Dashbar zeigt aktuell 208% Besucherzuwachs innerhalb der letzten 30 Tage.

Wir hosten unseren Shop auf einem Managed Server und aktuell ist es leistungsmäßig noch kein Thema. Mal abgesehen von ein paar HTTP Error 500 im Bestellprozess...und da bin ich nicht sicher ob die damit zu tun haben.

Ich hab jetzt all 9 Seiten hier durchgeackert....versteh aber echt nur Bahnhof. Kann mir jemand mal eine Anleitung durchgeben was, wo und wie einzutragen ist, damit man hier wieder Ruhe hat. Ich hab zwar auch Zugriff auf das access. log, aber da hörts dann mit meinen Serverfähigkeiten auch schon wieder auf.

Wär hier über Hilfe echt dankbar...vielleich kann mal jemand zusammenschreiben welche Schritte, von der Analyse bis zum Aussperren und Prüfung ob das auch funktioniert, nötig sind, damit das auch für Noobs wie mich nachvollziehbar ist.

 

[hula1499]

@Groundhog
Ich würd nur mal mit einer kleinen Bot-Sperre anfangen:

Shop:
/includes/config.JTL-Shop.ini.php

dort rein:

if(preg_match("/Mb2345Browser|LieBaoFast|zh-CN|MicroMessenger|zh_CN|Kinza|MJ12bot|AhrefsBot/",$_SERVER['HTTP_USER_AGENT'])) {
    header('HTTP/1.0 403 Forbidden');
    die("zugriff nicht erlaubt");
}

wenn das nicht für ruhe sorgt (schau nach einem Tag oder 2), dann tragst VOR dem obigen Code in der shop.ini.php noch ein:

    if($fp = fopen(PFAD_ROOT."jtllogs/zugriffslog_".date("d-m-Y").".log","a+")) {
        fwrite($fp,$_SERVER['REMOTE_ADDR']."                ".$_SERVER['HTTP_USER_AGENT']."\n");
        fclose($fp);
    }

In deinem Shop findest den Ordner jtllogs und darunter die datei zugriffslog_DATUM dort schaust dann rein was noch so alles kommt und vergleichst mit den Posts hier im Beitrag.

Sollte nicht Ruhe danach sein, kannst ja danach noch IP/Länder/Kontinente/Universum sperren

 

[css-umsetzung]

auf dem einem Server wird es nun langsam echt etwas viel, dadurch braucht Fail2Ban auch schon recht viel Ressourcen

 

[lj-shadow]

Ich hab's so gemacht, dass ich F2B laufen lasse und wenn eine Range auffällig wird, schau ich nach, was sich dahinter verbirgt.
Ist's irgendein Rechenzentrum, also großer Cloudanbieter, wird die Range gekillt.

Neben der Huawei-cloud ist's bei mir noch das Amazonaws. Ich sehe keinen Grund, was das in fremden Shops zu suchen hat.
Amazon veröffentlicht seine Ranges, sodass ich die komplett gesperrt hab.

 

[der_Martin]

Moin,

habe das Problem seit Oktober beobachtet.... Die Seite wurde dabei merklich langsamer. Aber wirklich schlimm wurde es zum Ende des letzten Jahres und Anfang dieses Jahr. Die Bots belegten 100% des Prozessors für die PHP Ausführung und die Maschine geht komplett in die Knie. Ich meine KOMPLETT weg, wie bei einem DDoS Angriff!
Habe den Code auf Seite 4 verwendet und die 3 Shops auf der Maschine laufen nun wieder erheblich schneller. Habe aber anders als im Code auf Seite 4 Bots wie SISTRIX, AHREF oder BAIDU (die ich selbst hin und wieder mal benötige) erlaubt die Seite zu crawlen....

Mag allerdings die Bots grundsätzlich nicht gern ausschließen - egal was sie tun!! Abgesehen davon, dass es zum Schluss eh ein aussichtsloses Unterfangen wie bei Igel und Hase ist.

Die Frage wäre: Wie kann ich die Bots bedienen, ohne dass meine Maschine in die Knie geht??? Wäre die Auslieferung einer rein statischen Seite für Bots denkbar???? Eine statische Seite die nur minimalst bis gar kein PHP und Datenbank benötigt und die sich alle 3-4 Stunden erneuert?? Das Ausliefern von Bildern könnte ich dann noch an ein CDN auslagern um den Server maximal zu schonen....

Ist das denkbar bzw. möglich??

Grüßle
Martin

 

[bitshaker]

Hallo Community,

auch uns hat's erwischt. Angefangen hatte es am 29.12.2019. Nach Neujahr war eine kurze Pause, bis es dann ab dem 07.01.2020 so richtig los ging:



Wir haben übrigens normal so um die 1000 Besucher/Tag und aktuell 60.000 und mehr pro Tag. Wäre schön, wenn sich das auch mit einem Umsatzanstieg verzeichnen lassen würde ... aber leider nicht

Noch eine Anmerkung zu Fail2Ban. Standardmäßig sind dort keine Regeln für NGINX. Wenn man also statt dem Apache NGINX verwendet, muss man entsprechende Regeln noch händisch anlegen. Eine gute Anleitung hierfür findet Ihr hier beschrieben: https://support.plesk.com/hc/en-us/...rotect-nginx-with-Fail2Ban-in-Plesk-for-Linux

Vielen Dank schon mal an alle, die sich hier beteiligen! Eine tolle Hilfe!

VG, Thorsten

 

[zttom]

Hallo zusammen,

mit etwas Verspätung gibt es nun eine Rückmeldung von uns. Wir haben die Zwischenzeit genutzt, um die Zugriffe auf unsere Server innerhalb der letzten 30 Tage auszuwerten, verschiedene Ansätze zur Abwehr zu testen und das Verfahren zu implementieren, woran wir Euch gerne teilhaben möchten. Die detaillierten Diagramme und Statistiken unserer Auswertung findet Ihr unter https://badbots.zitro.black (die Seite ist nur aus Deutschland aus aufrufbar).

Wie man der zweiten Auswertung auf der Webseite entnehmen kann, unterscheidet sich die China-Problematik von den herkömmlichen BadBots, da das Verhältnis zwischen den Zugriffen und den verwendeten IP-Adressen genau umgedreht ist. Das chinesische Botnetz greift direkt (und sekündlich) mit neuen IP-Adressen zu, sobald eine IP-Adresse blockiert wird. Somit kommen herkömmliche Verfahren leicht an ihre Grenzen:

auf dem einem Server wird es nun langsam echt etwas viel, dadurch braucht Fail2Ban auch schon recht viel Ressourcen

An den Punkt waren wir leider auch gekommen. Die Ursache liegt hierbei in der Verwaltung von iptables durch fail2ban. Iptables funktioniert auch mit vielen IP-Adressen performant, aber fail2ban muss jede Sekunde in den Log-Dateien nach neuen Einträgen suchen (fail2ban-server) und sekündlich IP-Adressen zu iptables hinzufügen oder entfernen (fail2ban-client).

Wir werden die nächsten Tage noch detailliert der Frage nachgehen, wie oft das Botnetz versucht, mit einer gesperrten IP-Adresse auf die Server zuzugreifen. Anhand der jetzigen Daten vermuten wir, dass es keine erneuten Zugriffe mit verbrauchten IP-Adressen macht (die Zugriffe teilen sich auf 457.746 dynamische IP-Adressen und 36.486 statische IP-Adressen auf). Das Botnetz schafft es, täglich mit ca. 30.000-60.000 vorher unbekannten IP-Adressen wiederzukommen. Ab dem 20.01. benutzt es dafür sogar noch IP-Adressen aus Singapur (Top 3: China, Singapur, Hongkong).

Kleine Übersicht der verwendeten Pattern im User Agent bei den Zugriffe der knapp 8.000 IP-Adressen aus Singapur am 20.01.:

58481x LieBaoFast
58254x Mb2345Browser
57570x zh-CN
56901x MicroMessenger,zh_CN
160x BuiltWith
155x masscan
101x zgrab
66x Kinza
57x ZmEu
4x Nmap
2x MSIECrawler

Man erkennt anhand der Top 4 Pattern, dass es sich wieder um das alte bekannte Botnetz handelt.

Das bringt mich zum nächsten Punkt: Wir haben die verwendeten User-Agents analysiert und wie man in der Auflistung der Singapur-Pattern erkennt, gibt es einen Anteil an User-Agents, die wir nur über die Spracheinstellung "zh-CN" dem Botnetz zuordnen können. "zh-CN" ist ein offizieller Sprachcode (https://www.metamodpro.com/browser-language-codes). Unsere Kunden haben keine Kunden in China und sind daher ein guter Honey-Pot. Wenn man aber wie @lahr-net auf Baidu angewiesen ist, sollte man keinen so grobes Pattern verwenden, um die Chinesen, die man mit Baidu erreichen möchte, nicht wieder auszusperren.

Wir werden weiterhin versuchen einen Fingerabdruck aus den User-Agent abzuleiten. Was wir schon sagen können und was hier in dem Forum auch schon thematisiert wurde: Das Botnetz unterteilt sich in Geräte mit dynamischer IP-Adresse mit User-Agent-Strings von Mobilgeräten und auf Geräte mit fester IP-Adresse diverser Cloud-Anbieter (Huawai und Amazon), die identische Mobile-User-Agent-Strings verwenden (Linux, Android, ...). Insgesamt verwendete das Botnetz bei uns 48 verschiedene User-Agent-Strings für 2.184.834 Zugriffe (ausgehend von ca. 500.000 unique IP-Adressen).

Aufgrund der hohen Dynamic in den verwendeten IP-Adressen haben wir einen verteilten Ansatz zur Botnetz-Abwehr entwickelt. Eine lokale Erkennung und Abwehr auf einem einzelnen Server - so wie sie hier in dem Forumsbeitrag beschrieben ist (htaccess, fail2ban) - ohne Informationsaustausch zu anderen Servern, nimmt zwar die Last von den PHP-Skripten und der Datenbank , verlagert aber die Last in andere Bereiche (fail2ban (Extraktion der Informationen aus den Logs) und apache (Prüfung des User-Agents oder Land bei jedem Request)).

Wir führen daher vorselektiert(!) IP-Adresse, User Agent und Zeitstempel an einer zentralen Stelle zusammen und verteilen die IP-Adressen dann wieder zurück auf alle Server. So profitieren alle Server von den Erkenntnissen, die ein anderer Server gesammelt hat. Wir verwenden für das Sperren weiterhin fail2ban und iptables, aber fail2ban muss sich nicht mehr um die Extraktion der Informationen aus den Log-Files kümmern. Mit iptables hat man weiterhin den Vorteil, dass nicht bei jedem Request ein Suchpattern auf den User-Agent-String angewendet werden muss. Die von uns verwendeten Pattern könnt Ihr öffentlich hier als JSON abrufen: https://badbots.zitro.black/api/v1/BadBots/Patterns. Die Pattern stammen aus dem apache-badbot-Filter von fail2ban, https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker und u.a. den Erkenntnissen aus dem Forum.

Wir haben zwei PHP-Programme geschrieben (der Code liegt offen vor und ist nicht verschlüsselt), die sich gegen unsere RESTful-API verbinden. Das eine Programm extrahiert periodisch anhand der o.g. Pattern IP-Adresse, User Agent und Zeitstempel aus den Access-Logs des Webservers und sendet das Tripple an die API. Das andere Programm ruft periodisch die neuen zu sperrenden IP-Adressen mit vom Backend angereicherten Zusatzinformationen an der API ab und schreibt Zeitstempel und IP-Adresse in ein Log-File, was wiederum von fail2ban überwacht wird. So muss sich fail2ban nur noch um 1 Log-File kümmern und kein aufwendiges Pattern-Matching der Badbots-Pattern vornehmen. Es können je nach Zusatzinformation die IP-Adressen auch in verschiedene Log-Files mit unterschiedlichen fail2ban-Sperrzeiträumen geschrieben werden. Bspw. verwenden wir 3 Dateien mit einer Sperrzeit von 1 Tag (dynamische IP-Adressen ausser China, Singapur, Hongkong), 1 Woche (statische IP-Adressen ausser China, Singapur, Hongkong) und 4 Wochen (China, Singapur, Hongkong). Man kann auch wie von @lahr-net gewünscht IP-Adressen mit Pattern (bspw. SISTRIX, AHREF und BAIDU) überspringen. Die Programme können im Benutzerkontext des Webspaces ausgeführt werden und benötigen lediglich Leserechte am Access-Log, was i.d.R. immer der Fall ist.

Das ganze wendet sich aktuell noch nicht an Noobs (@Groundhog), sondern an eher technisch versiertere Personen. Unsere Idee ist es, dass sich interessierte Service-Partner finden (@css-umsetzung ?), die Ihre Kunden an das Backend anbinden möchten, um Daten zu liefern und mit der Gesamtmenge der Daten die Kunden besser zu schützen. Die Verwendung der API ist kostenfrei. Falls ein Service-Partner Interesse hat, bitte einfach eine PM senden. Ihr erhaltet dann einen Auth-Token für die API und die Skripte. Wir sehen das ganze momentan noch als Beta an und werden voraussichtlich erst einmal mit einer begrenzten Menge an Interessenten arbeiten. Eine offizielle Registrierungsmöglichkeit über eine fancy Webseite und Einsicht in eigene Statistiken wird noch kommen. Für Noobs entwickeln wir aktuell ein Plugin, welches vor BadBots und zusätzlichen Bedrohungen schützen wird...

Viele Grüße

Tom

 

[css-umsetzung]

@zttom vielen Dank für deine sehr Ausführliche Ausarbeitung des Problems.
Ich bin jetzt für ein paar Tage nur bedingt aktiv, würde mich aber nächste Woche dann Mal bei dir melden.

 

[lj-shadow]

@zttom

Das unter dem github-link, war das, was ich neulich fand...

Könntest du mir mal Daten schicken? Ich würde mir das gern mal ansehen und gucken, ob ich DAAD implementieren kann

 

[lj-shadow]

Ich bin jetzt für ein paar Tage nur bedingt aktiv, würde mich aber nächste Woche dann Mal bei dir melden.

Du schreibst jetzt sicher mein plugin...

 

[Groundhog]

Das ganze wendet sich aktuell noch nicht an Noobs (@Groundhog), sondern an eher technisch versiertere Personen. Unsere Idee ist es, dass sich interessierte Service-Partner finden (@css-umsetzung ?), die Ihre Kunden an das Backend anbinden möchten, um Daten zu liefern und mit der Gesamtmenge der Daten die Kunden besser zu schützen. Die Verwendung der API ist kostenfrei. Falls ein Service-Partner Interesse hat, bitte einfach eine PM senden. Ihr erhaltet dann einen Auth-Token für die API und die Skripte. Wir sehen das ganze momentan noch als Beta an und werden voraussichtlich erst einmal mit einer begrenzten Menge an Interessenten arbeiten. Eine offizielle Registrierungsmöglichkeit über eine fancy Webseite und Einsicht in eigene Statistiken wird noch kommen. Für Noobs entwickeln wir aktuell ein Plugin, welches vor BadBots und zusätzlichen Bedrohungen schützen wird...

Ja, das liest sich auch so...der Vorstoß ein Plugin anzuregegen ist aber sehr gut. Es würde schon Sinn machen IPs & Crawler aus dem Backend heraus zu verweigern. Andere Frage: Fail2Ban ist dann die Voraussetzung?

Ich für meinen Teil, hab jetzt erstmal wieder Ruhe. Das Schnippsel aus post-688334 von @hula1499 (Fettes Danke nochmal an dieser Stelle), funktioniert sehr gut und hat den Besucherstrom wieder normalisiert.

 

[Point13]

Da ich bereits einige Anfragen hatte hier mal die Filter die ich verwende:
Wenn ich diesen Filter bei mir aktiviere dann sehe ich sofort das sich etwas tut, da man ja eigentlich ständig von nicht gewollten Bots besucht wird.

Plesk Bad Bot Filter:

[Definition]
badbotscustom = EmailCollector|WebEMailExtrac|TrackBack/1\.02|sogou music spider|(?:Mozilla/\d+\.\d+ )?Jorgee|MJ12bot
badbots = Atomic_Email_Hunter/4\.0|atSpider/1\.0|autoemailspider|bwh3_user_agent|China Local Browse 2\.6|ContactBot/0\.2|ContentSmartz|DataCha0s/2\.0|DBrowse 1\.4b|DBrowse 1\.4d|Demo Bot DOT 16b|Demo Bot Z 16b|DSurf15a 01|DSurf15a 71|DSurf15a 81|DSurf15a VA|EBrowse 1\.4b|Educate Search VxB|EmailSiphon|EmailSpider|EmailWolf 1\.00|ESurf15a 15|ExtractorPro|Franklin Locator 1\.8|FSurf15a 01|Full Web Bot 0416B|Full Web Bot 0516B|Full Web Bot 2816B|Guestbook Auto Submitter|Industry Program 1\.0\.x|ISC Systems iRc Search 2\.1|IUPUI Research Bot v 1\.9a|LARBIN-EXPERIMENTAL \(efp@gmx\.net\)|LetsCrawl\.com/1\.0 \+http\://letscrawl\.com/|Lincoln State Web Browser|LMQueueBot/0\.2|LWP\:\:Simple/5\.803|Mac Finder 1\.0\.xx|MFC Foundation Class Library 4\.0|Microsoft URL Control - 6\.00\.8xxx|Missauga Locate 1\.0\.0|Missigua Locator 1\.9|Missouri College Browse|Mizzu Labs 2\.2|Mo College 1\.9|MVAClient|Mozilla/2\.0 \(compatible; NEWT ActiveX; Win32\)|Mozilla/3\.0 \(compatible; Indy Library\)|Mozilla/3\.0 \(compatible; scan4mail \(advanced version\) http\://www\.peterspages\.net/?scan4mail\)|Mozilla/4\.0 \(compatible; Advanced Email Extractor v2\.xx\)|Mozilla/4\.0 \(compatible; Iplexx Spider/1\.0 http\://www\.iplexx\.at\)|Mozilla/4\.0 \(compatible; MSIE 5\.0; Windows NT; DigExt; DTS Agent|Mozilla/4\.0 efp@gmx\.net|Mozilla/5\.0 \(Version\: xxxx Type\:xx\)|NameOfAgent \(CMS Spider\)|NASA Search 1\.0|Nsauditor/1\.x|PBrowse 1\.4b|PEval 1\.4b|Poirot|Port Huron Labs|Production Bot 0116B|Production Bot 2016B|Production Bot DOT 3016B|Program Shareware 1\.0\.2|PSurf15a 11|PSurf15a 51|PSurf15a VA|psycheclone|RSurf15a 41|RSurf15a 51|RSurf15a 81|searchbot admin@google\.com|ShablastBot 1\.0|snap\.com beta crawler v0|Snapbot/1\.0|Snapbot/1\.0 \(Snap Shots, \+http\://www\.snap\.com\)|sogou develop spider|Sogou Orion spider/3\.0\(\+http\://www\.sogou\.com/docs/help/webmasters\.htm#07\)|sogou spider|Sogou web spider/3\.0\(\+http\://www\.sogou\.com/docs/help/webmasters\.htm#07\)|sohu agent|SSurf15a 11 |TSurf15a 11|Under the Rainbow 2\.2|User-Agent\: Mozilla/4\.0 \(compatible; MSIE 6\.0; Windows NT 5\.1\)|VadixBot|WebVulnCrawl\.unknown/1\.0 libwww-perl/5\.803|Wells Search II|WEP Search 00|.*AhrefsBot.*|.*seoscanners.*|.*MJ12bot.*
failregex = ^<HOST> -.*"(GET|POST|HEAD).*HTTP.*"(?:%(badbots)s|%(badbotscustom)s)"$
ignoreregex =
datepattern = ^[^\[]*\[({DATE})
    {^LN-BEG}

Danke für den Filter! LieBaoFast und Mb2345Browser komme darin noch gar nicht vor. Muss ich dann am Ende nur ein |.*LieBaoFast.*|.*Mb2345Browser.* hinzufügen?
Laut meinen Logs kommt auch noch der Seekport Crawler vor. Ist sogar auf Platz 1 der Zugriffe (knapp 28.000 Zugriffe innerhalb von 8 Stunden). LieBaoFast und Mb2345Browser "nur" jeweils knapp 12.000.

 

[Point13]

Hab es jetzt hinzugefügt. Ebenso den zh_CN

 

[zttom]

Hab es jetzt hinzugefügt. Ebenso den zh_CN

Da jetzt öfters noch mal die Frage aufkam, welcher Ansatz nun der richtige sei und ob es eine Anleitung gibt: Die Erkennung des chinesischen Botnetzes (Mb2345Browser|LieBaoFast|zh\-CN|MicroMessenger|zh_CN) über die Fail2ban-Filter kann zu einer hohen Last durch die fail2ban-Prozesse auf dem Server führen, da das Botnetz mit einer hohen Anzahl von unterschiedlichen IP-Adressen zugreift. Fail2ban kann dann bei ungünstiger Konstellation zu sehr mit der Extraktion der IP-Adressen aus den Log-Files und der Verwaltung der IP-Adressen beschäftigt sein. Dies konnten wir sowohl auf unseren Servern als auch @css-umsetzung bei seinen Servern beobachten.

Hier mal ein Bild mit der durch fail2ban verursachten Prozessor-Last auf einem Kunden-Server bis zum 23. und der anschliessenden Prozessor-Last nach der Anbindung an unsere API:



Wenn Ihr aktuell betroffen seid und eine schnelle Lösung sucht, reicht es vorerst aus, folgenden Code an den Anfang(!) der .htaccess einzufügen:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond "%{HTTP_USER_AGENT}" "(MJ12bot|AhrefsBot|Semrush|Mb2345Browser|LieBaoFast|zh\-CN|MicroMessenger|zh_CN|DotBot|SEOkicks|MegaIndex\.ru)"
RewriteRule .* - [F,L]
</IfModule>

Der Code vergleicht nur 11 Pattern und schützt vor den Top 10 der BadBots und damit vor ungefär 90% aller Badbots-Zugriffe (siehe auch die Diagramme auf https://badbots.zitro.black).

Wir werden Euch aufgrund der vielen Anfragen schon in den nächsten Tagen eine öffentliche Registrierungsseite für die API mit den Skripten und einer Token-Generierung bereitstellen. Die Idee unserer Lösung ist es, ein großes Netzwerk mit den Servern aller Betroffenen und Interessierten aufzuspannen, welches BadBots durch die angeschlossenen Satelliten (=Kundenserver) und Kombination von zentraler Logik frühzeitig erkennt. Somit wissen alle angeschlossenen Server direkt, welche IP-Adressen bösartig sind und welche nicht. Das Verfahren ist vergleichbar mit den Blacklists zur Spamvermeidung, wo jeder Mailserver die IP-Adressen der Spammer an die Blacklist meldet und somit alle Mailserver direkt wissen, woher Spam kommt.

Der Vorteil der Lösung ist, dass auch die in dem Beitrag beschriebenen Botnetze, die für jeden Zugriff eine neue IP-Adresse benutzen, direkt oberhalb der Netzwerkkarte blockiert werden können, ohne den Webserver zusätzlich durch die Verwaltung und Analyse durch fail2ban zu belasten. Wir schützen aktuell ca. 100 Server mit ca. 700 Domains mit unserer API und haben seit Dezember schon sehr viele Daten gesammelt.

Ja, das liest sich auch so...der Vorstoß ein Plugin anzuregegen ist aber sehr gut. Es würde schon Sinn machen IPs & Crawler aus dem Backend heraus zu verweigern. Andere Frage: Fail2Ban ist dann die Voraussetzung?

Für das spätere Plugin wird kein Fail2ban mehr auf Euren Servern benötigt. Bei der direkten Anbindung über die API wird die Extraktion der IP-Adressen aus den Log-Dateien durch unsere Programme vorgenommen und fail2ban braucht sich nur noch um die Verwaltung der iptables kümmern.

 

[Inge]

Wer mit nginx unterwegs ist kann das Problem mit https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker lösen
Für die Pflege der User-Agents braucht es ein automatisches System, was bereits seit Jahren dort etabliert ist.

 

[lj-shadow]

Das gleiche gibts auch dort für Apache.
Nur geht's nicht ganz so einfach