Sehr viele Zugriffe auf "http://domain.de/wp-login/*

    Moin Moin,
    ich habe auf einer Seite sehr viele Zugriffe (seid Jahresbeginn über 2000) mit immer demselben Schema. Ich bekomme eine Meldung von den Admin Tools / myjoomla, das versucht wurde ein Datei hochzuladen, und das eben geblockt wurde (UploadShield)
    Es kommt dabei immer von unterschiedliche IP, und sehr viel verschiedenen. Die Versuche haben allerdings immer eins gemeinsam: Es wird immer versucht, bestimmte URLs aufzurufen, praktisch als Luckypunsch mit sehr viel verschieden (WP) Komponenten. Die Domain hat immer ein /wp-login/ dazwischen.
    Kann ich das irgendwie von vornherein unterbinden, bzw alle URLs mit dem Inhalt wp-Login ausschließen?
    Geo Blocking in den Admin Tools hat nichts gebracht.


    Vielen Dank und viele Grüße,
    deltapapa

    WBR from DE-de

    "Hier könnte Ihre Werbung stehen"

  • Zum hilfreichsten Beitrag springen

    Hast du schon eine .htaccess Regel Probiert?


    Code
    RedirectMatch 301 (.*)wp-admin(.*) https://example.org


    Zitat

    Geo Blocking in den Admin Tools hat nichts gebracht.


    An sich ist die Funktion auch sinnlos:) Da Admin Tools eh erst eingreifen kann wenn dein Joomla getriggert wird. Bei wp-admin URLs wird es das aber logischerweise nicht => keine Auswirkung.

    Moin,
    erst mal vielen dank für die Infos. Ich habe noch einmal nachgeschaut, es sieht so aus:

    also wp-admin bzw wp-Content.
    So sieht es in der Übersicht aus:


    Und es sind sehr viele verschiedene URLs aus allen Ländern der Welt....
    Wie setze ich so eine fail2ban Regel? Kann ich sowas auch in Plesk machen?


    Viele Grüße,
    deltapapa

    WBR from DE-de

    "Hier könnte Ihre Werbung stehen"

    Hi deltapapa,


    ich meinte jetzt nicht was dir das komische admintools ;) anzeigt sonder ausserhalb deiner Joomlawelt :) "Mal auch in den Logs des Servers geschaut ?" Also das normale Log vom Server.


    Eine eigene fail2ban Regel schreiben ist nicht so einfach da man den richtigen failregex schreiben muss.


    Sende mir einmal eine Anfrage in mein Ticketsystem. Ich schaue mir an ob es sich überhaupt lohnt wegen diesen Zugriffen eine Regel zu schreiben. Ich glaube die tun sowieso nichts ausser 404 und 403 erzeugen.


    Gruß
    Micha

    Moin Moin,
    sorry das die Rückmeldung so lange gedauert hat.
    Nach meinem Post hier gingen zeitgleich die Zugriffe fast gegen 0, nichts in den Server Logs und auch nichts in den Admin Tools Logs.
    Daher habe ich erst einmal abgewartet, aber es bleibt auch im Moment sehr ruhig.
    Kurze Frage Christiane, wie kann ich das als Umleitungsregel definieren? Ich habe darüber irgendwie nichts gefunden. Ich hätte jetzt gedacht vllt in etwas so:
    /wp-admin* auf zB blöd.de umleiten oder sowas.


    Viele Grüße,
    Dirk

    WBR from DE-de

    "Hier könnte Ihre Werbung stehen"

    Ich habe ganz ähnliche Zugriffe.


    @Christiane, @Schwarzkünstler ist ein redirect 301 oder 303 ebenso ein Zeichen, dass die Angriffe ins Leere laufen, wie 404, 403 oder 410?


    Oder sind redirects 301 per .htaccess ungünstig fürs SEO?


    Ok, wenn man feststellt, der redirect sollte zu einer Spam-Seite gehen, ist das natürlich nicht harmlos. Das könnte man per script und wget $URL -O - | head - ; ja überprüfen, oder gibt es dazu bessere Methoden?

    Diese Bruteforce-Attacken auf ein WordPress-Login würde ich keinesfalls über Umleitungsregeln innerhalb des Joomla "abfangen". Das hat dann nur den Efffekt, das bei solchen Aufrufen viel mehr Last entsteht (PHP+MySQL werden ausgeführt). Eine effektive Methode das _vor_ irgendeiner Scriptausführung zu stoppen ist eine .htaccess-Regel wie z.B. derartiges:


    Code
    <Files wp-login.php>
Order Deny,Allow
Deny from all
</Files>

    Danke!

    Was aber mit den ganzen Spam-Links, die infolge eines abgewehrten Hacks von den bots nachgegangen werden wie bing und googlebot?

    Ich habe eine relativ komplexe regular Expression dazu geschrieben, die allerdings (noch) nicht optimal ist weil sie z.B. auch /robots.txt, /ads.txt, /sitemap.xml etc. erfasst. Das könnte ich aber denke ich noch anpassen. Bislang habe ich die nur zur Log-Auswertung verwendet und konnte mit egrep diese Ausnahmen herausfiltern. Die Frage wäre auch ob rewrite rules Gruppen unterstützen wie z.B. sed -E.

    Ok, caputring groups und backreferences werden wohl unterstützt.

    Ich denke aber ich sollte diese dann, um unnötige Last zu vermeiden zwar auf die Seite umleiten, aber die selben Anfragen, wenn diese zusätzlich von searchengine-bots kommen mit 410 beantworten, oder?

    Ok, ich glaube das wäre wahrscheinlich doch zu Umfangreich und ich mache vielleicht einen eigenen Thread dazu auf.

    So ganz verstehe ich die Rückfrage nicht ehrlich gesagt. Links die ungültig sind einfach abwehren wie im .htaccess-Beispiel gezeigt. Ich kann dabei keine Nachteile erkennen.

    Zitat


    Was aber mit den ganzen Spam-Links, die infolge eines abgewehrten Hacks von den bots nachgegangen werden wie bing und googlebot?

    bitte mal erläutern was damit gemeint ist.

    Hallo Flotte,
    Es gab einen Hack, in dem eine Sitemap.xml und der dazugehörige Googlecode in die Site geladen wurden, mit >8000 Spamlinks, die sich wohl mittels einer manipulierten index.php und weiteren Dateien weiter vervielfältigen ließen. Es fanden sich auch eine phpmailer.php, erweitert um benötigte Klassen zum Versandt, eine askitmet.php mit einer webshell etc. Das habe ich alles entfernt, Aber ich konnte etwa 50.000 japanische Seiten im google Index per redleg aw-snap Spam-Suche ausfindig machen (dupes möglich). Deren Spam-Inhalt ist zwar noch imj google-cache aufrufbar, aber wegen der Säuberung nicht mehr direkt über die betroffene domain.

    Da bekomme ich 301 und 404, die 301 sind redirects durch die .htaccess auf die index.php.

    Nun wird die Seite massenhaft immer noch 10.000 mal am Tag nach diesen injezierten Spam-Links durch den Google-Bt abgecrawlt. Dabei entsteht Last, da ich diese teilweise auf die index.php oder auch auf die 404 Error-Seite umleite.

    Nun war die Säuberung der Seite zwar erfolgreich, und wir haben auch nun über die Google-Search-Konsole eine eigene sitemap.xml hochgeladen, die anderen Spamlinks beanstandet und eine Überprüfung der Seite durch google beantragt. Von 35.000 ist der bot auch auf 10.000 Besuche etwas zurückgegangen.

    Ich habe auch wp-Angriffe in den logs, aber verschwindend gering.

    Nun war die Idee, den Googlebot zu identifizieren und falls ein Regex-Pattern zusätzlich auf die Spam-Links in der Form hier zutrifft, diesen Aufruf mit de Statuscode 410 für Gone zu beantworten.

    access.log

    Code
    66.249.64.17 - - [09/Mar/2018:00:01:04 +0100] "GET /3enf30g+6z9aq6_7xt3-3059561i0/ HTTP/1.1" 301 271 www.my-joomla-3.8.5-site.com "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "-"
66.249.64.18 - - [09/Mar/2018:00:01:05 +0100] "GET /3enf30g+6z9aq6_7xt3-3059561i0/ HTTP/1.1" 410 325 www.my-joomla-3.8.5-site.com "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "-"
66.249.64.17 - - [09/Mar/2018:00:01:08 +0100] "GET /mi1789e+3w5wf4_8it2-1629935c7/ HTTP/1.1" 301 271 www.my-joomla-3.8.5-site.com "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "-"
66.249.64.18 - - [09/Mar/2018:00:01:08 +0100] "GET /mi1789e+3w5wf4_8it2-1629935c7/ HTTP/1.1" 410 325 www.my-joomla-3.8.5-site.com "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "-"


    Dazu habe ich nun eine .htaccess mit den zusätzlichen Zeilen im Custom-Bereich.


    Apache Configuration
    RewriteCond %{HTTP:X-FORWARDED-FOR} ^66\.249\.(6[4-9]|[78][0-9]|9[0-5])\.
RewriteCond %{HTTP_USER_AGENT} Googlebot
RewriteCond %{REQUEST_URI} (/index\.php/de/|/)[a-z0-9+%\/]{6,21}[_/+]{0,1}[0-9a-z+%\=]{4,9}[-/+]{0,1}[0-9a-z+%.]{0,14}[/]{0,1}$
RewriteRule ^ - [R=410,G]


    Damit funktioniert die Beantwortung des Crawlings der Spamlinks durch den Google-Bot mit dem Statuscode 410, wie man sehen kann. Ich erhoffe mir davon, dass google diesen Spam schneller aus seinem Index entfernt. Die anderen Seiten werden weiterhin normal gecrawlt, also nicht mit 410 beantwortet, da sie nicht matchen.


    Ich teste mit dem htaccess Tester hier: https://htaccess.mwl.be/


    Hier ein Artikel zu dieser Art „japanese SEO hack“.
    Behebung von Hacking durch japanische Keywords | Google Developer

    Sorry, wenn das hier zu weit vom Thema wegführte. Meine ursprüngliche Frage in diesem Zusammenhang bezog sich auch eher darauf, ob Status-Codes im access.log wie 3.x, 4.x oder 5.x ein sicheres Indiz sein könnten, dass ein Hackversuch nicht erfolgreich ist. Bei 301 mit der Einschränkung, dass nicht auf eine nicht vorgesehene Seite (also durch Hacker) weitergeleitet wird, was man zusätzlich testen müsste, z.B. mit wget --spider und entsprechendem Filter, oder halt mit Stichproben.