Wie ich ja bereits vor kurzem mitteilte, laufen bei mir in letzter Zeit ziemlich viele seltsame 404 Seiten auf. Diesbezüglich habe ich die Tage bei Cywhale einen sehr interessanten Artikel gefunden Sicherheit / Wordpress absichern und gegen bekannte Angreifer einige Dinge auf meinem Blog implementiert. Unter anderem hat der bekannte libwww-perl* User Agent, der auch schon zahlreiche Angriffe gegen den Wordpress Coreblock gestartet hatte, bei mir in letzter Zeit sein Unwesen getrieben.
Klar wäre es weitaus schlimmer, wenn dieser bekannte Angreifer eine Sicherheitslücke bei mir gefunden hätte und statt laufender 404 Seiten von meinem Blog die Rückmeldung 200 erhalten hätte. Aber trotzdem muss ich ihn deswegen nicht weiter sein Unwesen treiben lassen, auch wenn derzeit noch keine Gefahr besteht, dass er mir etwas anhängt, einfügt, implementiert oder was auch immer er gerade so vor hat.
Aussperren ist da die Devise und Cywhale zeigt wie es geht. Ein paar der im Artikel genannten Sicherheitstipps für die htaccess habe ich vor Kurzem implementiert.
Der Artikel von Cywhale ist so umfangreich und interessant, dass ich an dieser Stelle einfach nur darauf verweisen möchte. Wer für seine Wordpress Applikation mehr Sicherheit wünscht, wer sich gegen bekannte Angreifer absichern möchte, dem sei dieser Artikel auf jedem Fall zu empfehlen. Ich denke es stört auch überhaupt nicht, dass dieser Artikel bereits vor über einem Jahr gepostet wurde, die Problematik Sicherheitslücken und Angreifer ist immer wieder aktuell.
Bezüglich der bösen Bots die in meinem Blog ihr Unwesen getrieben habe und nichts anderes veranstalten wollten als hunderte bis tausende 404 Seiten zu produzieren, habe ich aber eine etwas abgeänderte Lösung in meiner htaccess implementiert, die ich auf den User Agent Seiten gefunden habe. Mein entsprechender Eintrag in der htaccess, der die User Agents libwww-perl, Java und auch meinen besonderes aktiven Freund, den betaBot aussperrt, sieht wie folgt aus:
# böse Bots sperren
SetEnvIfNoCase user-agent "libwww-perl.*" bad_bot=1
SetEnvIfNoCase user-agent "Java/1.*" bad_bot=1
SetEnvIfNoCase user-agent "betaBot" bad_bot=1
<FilesMatch “(.*)”>
Order Allow,Deny
Allow from all
Deny from env=bad_bot
</FilesMatch>
Seitdem ich diese htaccess scharf geschalten habe, waren diese User Agent nicht mehr gesehen. Joachim stellt in seinem Artikel Bots und Spammer den Zugriff auf die eigene Webseite verweigern noch ein paar weitere Möglichkeiten vor, wie diesen Angreifern über die htaccess das Garaus bereitet werden kann. Von einer IP bzw. auch einer IP-Range Sperre rate ich aber ab, da hier schnell auch mal ganz andere User als nur der Angreifer gesperrt werden können. Abgesehen davon nutzen die “wirklich Bösen” wahrscheinlich eh eine gefakte IP, womit die IP Sperrung ins Leere läuft. User Agent Sperren, wie bei mir oben oder bei Joachim beschrieben sind die bessere Wahl.
[...] es also sinnvoll diese Angreifer an ihren Tätigkeiten zu hindern. Crazy Girl hat heute einen interessanten Beitrag darüber geschrieben, wie man seinen Blog vor bösen Bots schützen kann. Auch kann man [...]
[...] wurde ich auf den Artikel durch Tanja, die über den interessanten Artikel mit dem Namen Sicherheit / WordPress absichern [...]
[...] Sicherheitsvorkehrungen abwehren. Dazu haben diverse Blogger wie Michael, Thomas oder auch Tanja viele Tipps und Tricks erwähnt, wie man seinen Wordpress Blog absichern kann. Auch im [...]
Liebe Tanja,
erst mal möchte ich mich für die Erwähnung ganz herzlich bedanken.
Des Weiteren finde ich deinen Beitrag sehr informativ. Genau mit dem Problem, was Cywhale beschreibt, setze ich mich schon seit einiger Zeit auseinander. Mich stört es total, dass der WP-Admin Name bei allen gleich ist und man ihn nicht einfach so ändern kann. Das ist ein erhebliches Sicherheitsproblem, das hausgemacht ist!
Wenn nur jeder 5. WP-Benutzer etwas mehr Sicherheitsbewusstsein an den Tag legen würde, könnten so erheblich viele Hackerangriffe auf WordPress vermieden werden. Daher finde ich Artikel, die auf solche Gefahren hinweisen und Lösungswege aufzeigen hochinteressant.
Hallo Crazy Girl,
auch ich finde deinen Artikel interessant und wichtig! Ich selbst war von den angesprochenen Problemen bisher noch nicht betroffen, aber das kommt sicherlich auch noch auf mich zu, wenn mein Blog länger existiert und bekannter geworden ist. Allerdings habe ich russischen Spam bereits reichlich (zum Glück nur im Filter).
Jedenfalls baue ich die Regeln schon mal in meine .htaccess ein. Also, danke für die Infos!
Viele Grüße
Torsten
@Joachim Den Admin Namen kann man doch wunderbar ändern? Einfach einen neuen User anlegen, diesem Adminrechte geben. mit neuem User anmelden, alten Admin löschen. Oder hab ich dich jetzt falsch verstanden?
Zum Thema: Es gibt ja durchaus auch “legale” Perl Scripts die zugreifen. bzw. wie ist das wenn man selber Perl für manche Wartungsarbeiten auf dem Server einsetzt?
@ Markus
Kann sein, dass ich mich falsch ausgerückt habe. So wie du es schreibst, ist es richtig. Nur vermisse ich eine Option in WP, die es einem mit einem kleinen Handgriff ermöglicht seinen Einloggdaten zu verändern. Schließlich generiert WP bei allen Installationen den Standart Namen und ich möchte nicht wissen, wieviel 10.000 Benutzer den Einlognamen auf Standart lassen, weil sie: a.) zu faul sind ihn zu ändern und b.) nicht wissen, wie es geht.
Ich bin der Meinung, dass bei einer frischen WP Installation der User seinen Einloggnamen selber bestimmen sollte. Oder habe ich diese Option bei der WP Installation übersehen? Das kann vielleicht auch möglich sein…
@Joachim Ach okay jetzt^^ Ist richtig was Du sagst und Nein Du hast nichts übersehen, diese Möglichkeit bietet WP leider (noch?) nicht. Das einzigste was in diesem Fall bleibt ist, die User eben immer wieder darauf hinzuweisen.
Eigentlich stellt es auch kein Problem dar, die Installationsroutine dahingehend zu ändern. Zumindest sehe ich keine Grund warum man dies nicht fest in WP einbauen könnte seitens der Entwickler? Aber im neuen WP ist ja der “Hallo Welt” Artikel geändert worden und soll jetzt wohl als Art “erste Schritte Artikel” verwendet werden. Mal schauen ob wenigstens da ein Hinweis darauf zu finden ist.
@ Alle
Ich habe da eine Frage. Und zwar versuche ich seit Stunden meine wp-login.php hinter einer .htaccess zu verstecken. Möchte ich auf mein WP-Dashboard zugreifen, will ich es so haben, dass als erstes die .htaccess greift und ich erst nach Eingabe dieser Einloggdaten meine wp-login.php zu Gesicht bekomme. Ich mache andauernd was falsch. Irgendwie hocke ich heute total auf der Leitung, was Homepage betrifft. Kann mir vielleicht jemand helfen? PS: Den Artikel von Cywhale habe ich mir rein gezogen, aber alles, was ich für diese Sache unternehme, klappt leider nicht.
Sehr hilfreicher Artikel! – Werde ich wohl gleich in meinem Blog umsetzen
PS: (http://www.user-agents.de/get_htaccess.php) – Fertige .htaccess Datei gegen böse Bots.
@Torsten: Egal ob neu oder älter, ob klein oder groß, irgendwann finden die einen und da schon mal von Anfang an absichern ist nie verkehrt
@Markus und Joachim: Nette Diskussion
@Joachim: Bist Du mittlerweile fündig geworden? Ich wüßte jetzt leider auch keine Lösung für Dein Problem
@Jeffrey: Danke
Die user-agents Seite habe ich oben in meinem Artikel eh schon verlinkt. Aber der nochmalige Hinweis ist natürlich immer gut
Stecken hinter Java/1.* nicht auch gute Bots? Mir ist zwar bisher noch kein gutartiger mit diesem Useragent begegnet, aber lieber nochmal nachfragen, da kann man sich ja sehr viel zerhauen, wenn man einfach irgend was aussperrt…
@ Tanja
Nee habe nichts g´scheites mehr über dieses Thema gefunden. Aber ich habe in den letzten paar Tagen sehr wenig Zeit gehabt und konnte nicht so intensiv auf die Suche gehen. Aber ich werde das Thema spätestens am Wochenende wieder aufgreifen.
@alte Kiehvotz: Bei mir haben sämtliche Javas ausschließlich nur 404 Seiten produziert und das nicht gerade wenige. Also weg damit. Für die ausschließliche Produktion von 404 Seiten brauche ich keinen einzigen Bot, egal ob dieser als gut oder schlecht gilt
@Joachim: Halt mich bitte auf dem Laufenden. Ich bin zur Zeit zeitlich auch ziemlich eng