1. Sicherheit durch Plugins?
Im ersten und zweiten Teil der Artikelserie WordPress absichern habe ich euch Tipps vorgestellt, um die Wahrscheinlichkeit eines erfolgreichen Angriffs deutlich zu reduzieren. Die dargestellten Maßnahmen hatten alle etwas gemeinsam: Sie mussten händisch vom Anwender durchgeführt werden – was wiederum ein gewisses Maß an technischem Verständnis erforderte.
Doch es geht auch anders. Sogenannte Security Plugins versprechen WordPress gegen allerlei Angriffe abzusichern. Dabei reicht die Palette vom »Rundum-Sorglos-Paket«, bis hin zu Einzellösungen für bestimmte Angriffsszenarien. Je nach Anwendungsfall und technischen Kenntnissen stehen dem Anwender also eine ganze Reihe von Security Plugins zur Verfügung.
Wie sinnvoll bzw. nützlich sind diese Plugins? Welche bieten einen wirklichen Mehrwert? Anhand von Beispielen versuche ich euch eine Idee bzw. ein Gefühl zu vermitteln, was sinnvoll sein kann und welche Plugins ihr euch sparen könnt.
- Basisschutz – WordPress absichern Teil1
- Schutzmaßnahmen – WordPress absichern Teil2
- Security Plugins – WordPress absichern Teil3
- .htaccess Schutz – WordPress absichern Teil4
- Serverseitiger Schutz – WordPress absichern Teil5
- Spam-Bot Protection – WordPress absichern Teil6
- Parasitenabwehr von Bots – WordPress absichern Teil7
- Neu 2016: Der richtige Hoster – WordPress Sicherheit Teil1
- Neu 2016: Eierlegende Wollmilchsau – WordPress Sicherheit Teil2
- Neu 2016: Schwachstellen in Plugins und Themes – WordPress Sicherheit Teil3
Update
März 2016: Die Artikelserie wurde das letzte Mal im März 2016 aktualisiert.2. Schutz gegen Bots und Co.
Viele Security Plugins werben mit dem Schutz gegen Bots. Automatisierte Login-Versuche mittels Wörterbuch-Angriff oder das Ausnutzen von Sicherheitslücken in WordPress, sollen durch dein Einsatz von diesen Plugins verhindert werden. Schutz gegen Bots also – was genau ist ein Bot eigentlich? Dahinter verbirgt sich ein Computerprogramm, welches vollautomatisch besimmte Aufgaben abarbeitet. Es wurde also ursprünglich von jemandem programmiert und verrichtet anschließend autonom seinen Dienst.
Ein gutes Beispiel ist bspw. der Botnetz-Angriff vom April 2013. Ziel dieses Bots bzw. Botnetzwerks ist es, das Administrator-Passwort durch einen Wörterbuch-Angriff zu ermitteln und anschließend eine Backdoor auf dem System zu installieren. Im Prinzip kann man sich das Folgendermaßen vorstellen:
- Jemand (Master) entwickelt in einem kleinen, verruchten Hinterzimmer einen Bot. Sein Ziel sind diesmal WordPress-Installationen weltweit.
- Zunächst überlegt sich Master eine Strategie wie er seinen teuflischen Plan umsetzen kann. Sein Entschluss steht schnell fest: Der Bot soll in WordPress eindringen und anschließend Schadcode verankern. Durch die Infektion von möglichst vielen WordPress-Installationen soll dann ein wesentlich größeres, schlagkräftigeres Botnetz entstehen.
- Master implementiert seinem Bot folgende Logik:
- (1) Open »domain.com/wp-admin/index.php« OR »domain.com/wp-login.php«
- (2) Insert username »admin«
- (3) Insert password »Wörterbuch-Angriff«.
- (4) Login successful? -> Install bad code OTHERWISE Return to 3
- (5) Response: »Congratulations – It’s done master«
- Bereits vor dem Angriff verfügt Master über ein Botnetzwerk mit 90.000 unterschiedlichen IP-Adressen bzw. Bots. Über eine zentrale Schaltstelle (Command-and-Control-Server) steuert Master seine Bots und überträgt ihnen den neuen Schadcode. Anschließend startet er die Angriffswelle auf WordPress und legt seine Füße hoch.
- Stündlich infizieren die Bots anschließend vollkommen autonom tausende von WordPress-Installationen. Masters Arme wächst und wächst. Beim nächsten Angriff auf neue Ziele stehen ihm dann schon knapp 700.000 Bots zu Verfügung. Ausgezeichnet!
Das dargestellte Szenario ist nur ein Beispiel von vielen. Über Foren und Underground-Seiten lassen sich Bots für bestimmte Einsatzzwecke sogar mieten bzw. kaufen. Abhängig vom Ziel, Zweck und Zeit schwanken die Preise zwischen 50 $ und einigen Tausend Dollar. Gibt es gegen solche Bot-Angriffe einen wirkungsvollen Schutz? Und wenn ja, finden wir diesen wirklich in WordPress-Plugins?
Du kannst den Blog aktiv unterstützen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Maßnahme (1): Verstecken der Versionsnummer bzw. von Meta-Daten
Entwickler von Security Plugins versuchen solchen Bot-Angriffen mit verschiedenen Maßnahmen entgegenzuwirken. Äußert beliebt ist das Verstecken der Versionsnummer bzw. sonstige Rückschlüsse (Meta-Daten) auf eine WordPress-Installation zu kaschieren. Der Nutzen von Security by Obscurity ist leider äußert gering:
- Es ist nahezu unmöglich den Betrieb einer Webseite mit WordPress zu verschleiern. Allein im Sourcecode existieren viele Stellen. Selbst wenn diese Informationen alle von einem Security Plugin gefunden und unkenntlich gemacht werden, verrät eines der installierten Plugins die verwendete WordPress-Versionsnummer.
- Des Weiteren agieren Bots meist nach einem simplen Muster: Vor einem Angriff lesen sie im Normalfall nicht die WordPress Versionsnummer aus oder machen sich die Mühe die Webstruktur zu untersuchen. Sie greifen einfach alles an und gehen davon aus, es handelt sich um ein verwundbares System. Existiert beispielsweise eine Lücke im mailpoet Newsletter Plugin wird ein Bot direkt versuchen das Plugin anzugreifen (»domain.com/wp-content/plugins/wysija-newsletters«). Ebenso verhält es sich mit Schwachstellen in WordPress selbst. Vor einem Angriff findet in der Regel also keine gezielte Suche nach der Versionsnummer statt. Es gilt das Motto: Angriff ohne Rücksicht auf Verluste.
2.2 Maßnahme (2): Limitierung der Login-Versuche
Weiterhin beliebt sind Security Plugins zur Limitierung von Login-Versuchen in den Admin-Bereich. Dazu werden von jedem fehlgeschlagenen Anmeldeversuch die IP-Adresse und Zeit protokolliert. Falls es innerhalb einer definierten Zeitspanne zu wiederholten Login-Versuchen von der selben IP-Adresse kommt, wird diese für einen gewissen Zeitraum gesperrt. Damit sollen Brute-Force- bzw. Wörterbuch-Angriffe verhindert werden. Gegen groß angelegte Angriffe wie das Botnetz von Master (siehe Beispiel oben) hat dieser Schutz allerdings einen geringen Nutzen:
- Insgesamt verfügt das Botnetzwerk über 90.000 unterschiedliche IP-Adressen. Für jede WordPress-Installation hat der Bot theoretisch also 90.000 Mal die Möglichkeit sich Zugang zu verschaffen – wenn er es pro IP-Adresse einmal versucht. Tatsächlich agiert der Bot in der Praxis nach diesem Muster. Nach zwei fehlgeschlagenen Login-Versuchen wird der Angriff von einer anderen IP-Adresse fortgesetzt.
- Insgesamt stehen ihm also sogar 180.000 Versuche zur Verfügung. Angriffen dieser Größenordnung hat das Plugin also nichts entgegenzusetzen.
2.3 Maßnahme (3): Änderung der Standard-Pfade
Security Plugins verändern auch gerne die Standardpfade zu Ordnern wie »wp-content« oder »wp-admin«. Auch hier ist das Ziel wieder Sicherheit durch Unklarheit. Leider lösen solche Maßnahmen langfristig gesehen keine Probleme, sondern erschweren dem Anwender die Bedienung von WordPress. Der messbare Nutzen ist auch hier wieder äußert gering.
Im Übrigen ist der Quellcode von WordPress Security Plugins ebenfalls für Angreifer einsehbar. Es ist denkbar einfach den Programmcode um ein paar zusätzliche Zeilen zu erweitern. Anschließend sind Bots in der Lage auch Nicht-Standardpfade bzw. Adressen aufzurufen – die Infos dazu erhalten sie aus den Plugins.
WordPress auf Schwachstellen und Konfigurationsfehler prüfen
Für Deine WordPress-Installation habe ich ein spezielles Leistungspaket im Angebot:- Scan Deiner WordPress-Installation auf Schwachstellen
- Auswertung und Beurteilung der gefundenen Schwachstellen
- Auf Basis der Ergebnisse erhälst Du von mir individuelle Maßnahmenempfehlungen zur Behebung und Absicherung
Wenn du Deine WordPress-Installation nachhaltig absichern möchtest, kannst Du mich gerne kontaktieren.
Gut zu wissen: Sicherheit erlangst Du nicht durch die Installation unzähliger Security-Plugins, sondern durch eine saubere Konfiguration, stetige Updates und proaktive Maßnahmen zur Absicherung. Kontakt aufnehmen
3. iThemes Security – Die Eierlegende Wollmilchsau
Ein sehr bekanntes und weit verbreitetes Security Plugin ist iThemes Security (ehemals Better WP Security). Beworben wird das Plugin mit dem folgendem Slogan:
The easiest, most effective way to secure WordPress. Improve the security of any WordPress site in seconds.
Sozusagen die eierlegende Wollmilchsau zur Absicherung einer jeden WordPress Installation. Und tatsächlich – auf kaum einer Webseite zum Thema »Top WordPress Security Plugins« darf das Plugin fehlen. Es wird unzählige Male im Zusammenhang mit der Steigerung der Sicherheit von WordPress-Installationen genannt. Welche Funktionen bietet das Plugin und weshalb wird es so oft empfohlen?
3.1 Funktionsvielfalt
iThemes Security besteht im Kern aus vier Schutzmodulen. Diese bauen im Prinzip aufeinander auf. Im Folgenden werden die vier Bereiche kurz vorgestellt:
- (1) Obscure – iThemes Security hides common WordPress security vulnerabilities, preventing attackers from learning too much about your site and away from sensitive areas like your site’s login, admin, etc.
Sozusagen Security by Obscurity. Dazu hatte ich mich schon im zweiten Teil Schutzmaßnahmen – WordPress absichern Teil2 geäußert. Neben wenig nützlichen Maßnahmen wie das Verstecken der Versionsnummer und Änderung von Pfaden, nimmt iThemes Security auch ein paar sinnvolle Modifikationen vor. Dazu zählen die Umbennennung des Administrator Accounts und die Anpassung des Tabellenprefix wp_.
- (2) Protect – Just hiding parts of your site is helpful but won’t stop everything. After we hide sensitive areas of the sites we’ll protect it by blocking users that shouldn’t be there and increasing the security of passwords and other vital information.
Das Modul soll schwache Passwörter vermeiden, kann eine SSL-verschlüsselte Verbindung zum Dashboard erzwingen und bietet Schutz gegen Bots. Fehlgeschlagene Login-Versuche werden erkannt und führen zu einer Sperrung der anfragenden IP-Adresse. Als Zusatzfunktion wird sogar die Server Sicherheit verbessert – jedenfalls ist dies Teil der Auflistung. »Strengthen server security« – eine Marketing-Aussage ohne Inhalt.
- (3) Detect – Should all the protection fail iThemes Security will still monitor your site and report attempts to scan it (automatically blocking suspicious users) as well as any changes to the filesystem that might indicate a compromise.
Bots und andere Eindringlinge werden bei Auffälligkeiten erkannt und in einer Datenbank registriert. Über das WordPress-Dashboard hat der Administrator Zugriff auf diese Informationen. Des Weiteren wird das Dateisystem auf unberechtigte Änderungen hin untersucht.
- (4) Recover – Finally, should the worst happen iThemes Security will make regular backups of your WordPress database (should you choose to do so) allowing you to get back online quickly in the event someone should compromise your site.
iThemes Security unterstützt ebenfalls eine Backup-Funktion – für den Ernstfall.
Auf den ersten Blick bietet iThemes Security eine beeindruckende Feature-Liste. Vor allem auf WordPress-Anfänger und technisch weniger versierte Anwender muss dies den Eindruck einer »Rundum-Sorglos-Lösung« vermitteln. Und tatsächlich – ein Teil der Maßnahmen sind nützlich und erhöhen die Sicherheit einer WordPress-Installation. Rechtfertigt dies allerdings die Installation eines so umfangreichen Plugins?
3.2 Insgesamt wenig Nutzen
Im ersten Absatz der Plugin-Beschreibung gibt iThemes Security im Prinzip schon selbst die Antwort auf die dringendsten Sicherheitsprobleme in WordPress:
As most WordPress attacks are a result of plugin vulnerabilities, weak passwords, and obsolete software.
An Schwachstellen in Plugins und veralteter Software (WordPress Core, Plugins) kann auch iThemes Security nichts ändern. Ein Teil der durchgeführten Maßnahmen sind sinnvoll, können aber von (fast) jedem Anwender innerhalb weniger Minuten selbst erledigt werden. Dazu genügt es die beschriebenen Tipps in Basisschutz – WordPress absichern Teil1 und Schutzmaßnahmen – WordPress absichern Teil2 umzusetzen.
Was dann noch übrig bleibt sind ein paar wenig sinnvolle Maßnahmen, Security by Obscurity, ein Bot-Schutz, Bot-Monitor, Dateisystem-Schutz und eine Backup Lösung. Insgesamt zu wenig was die Installation und dauerhafte Nutzung des Plugins rechtfertigen würde. Das können andere Plugins besser. Als »Rundum-Sorglos-Lösung« scheidet iThemes Security jedenfalls aus.
Auch das Geld für die Pro Version von iThemes Security ist an einer anderen Stelle besser angelegt. Beispielsweise bei einem zuverlässigen und auf Sicherheit fokussierten WordPress-Hoster.
3.3 Schwachstellen im Plugin
iThemes Security soll WordPress eigentlicht schützen. Doch hin und wieder wird auch in iThemes Security eine Schwachstelle entdeckt, die sich wiederum negativ auf die Sicherheit der WordPress-Installation auswirken kann. Von daher gilt: Schafft euch nicht zusätzliche Schwachstellen, indem ihr Security-Plugins installiert.
4. Login LockDown – Spezielle Schutzvorrichtung
Immer wieder gerne empfohlen und äußert beliebt ist das Plugin Login LockDown bzw. Limit Login Attempts. Es protokolliert fehlgeschlagene Login-Versuche. Falls ein Anmeldeversuch innerhalb von 5 Minuten dreimal hintereinander fehlschlägt blockiert das Plugin die anfragende IP-Adresse für eine Stunde. Über ein Optionsmenü können die Parameter an die eigenen Bedürfnisse angepasst werden. Leider tendiert der Nutzen gegen professionelle Angriffswellen von Botnetzwerken gegen Null. Nach zwei fehlgeschlagenen Login-Versuchen ändert der Bot seine IP. In der Standardeinstellung registriert Login Lockdown die Anmeldeversuche – mehr allerdings auch nicht. Dem gigantischen IP-Adresspool des Botnetzwerks hat das Plugin nichts entgegenzusetzen.
Login LockDown bzw. Limit Login Attempts mag gegen nervige Script-Kiddies helfen und auch den ein oder anderen penetranten Login-Versuch unterdrücken, gegen professionelle Angriffe auf den Admin-Bereich hilft es wenig (jedenfalls mit den Standard-Settings). Falls es euer Hoster erlaubt ist ein Schutz des Anmeldebereichs mittels .htaccess Passwortschutz die bessere Lösung. Dies werde ich im nächsten Beitrag erklären.
Leider bietet nicht jeder Hoster einen Zugriffsschutz via .htaccess. Wer also tatsächlich keine Chance hat einen .htaccess Schutz auf seinem Webserver zu aktiveren, dem kann Login LockDown mit angepassten Einstellungen helfen.
5. Empfehlenswerte Security Plugins
Bisher habe ich zwei beliebte und weit verbreitete Security Plugins vorgestellt. Über den Nutzen dieser Plugins lässt sich streiten – ich sehe jedenfalls (fast) keinen. Allein beim Lesen der Beschreibung kann ich viele Security Plugins aus den oben genannten Gründen nicht empfehlen. Außer einer Menge Speicherverbrauch und einem zusätzlichen Angriffsvektor ist der Sicherheitsgewinn gering bis nicht vorhanden.
Doch wie lässt sich der zusätzliche Sicherheitsgewinn durch ein Plugin überhaupt messen? Subjektiv betrachtet kann ich nur wenige Security Plugins empfehlen. Folgende Plugins können durch ihre Zusatzfunktionalität zu mehr Sicherheit beitragen:
5.1 AntiVirus
AntiVirus [nicht mehr verfügbar] für WordPress bietet Schutz gegen Schadsoftware, die über Sicherheitslücken in WordPress, Plugins oder Themes eingeschleust wurde. Überprüft werden aktive Templates bzw. deren Funktionserweiterungen (zb. functions.php) nach verdächtigen Code-Manipulationen. Wird AntiVirus fündig schlägt das Plugin mittels E-Mail Alarm.
Seit Version 1.3.4 verfügt das Plugin über eine sinnvolle Erweiterung: Es greift bei der Suche nach manipuliertem bzw. eingeschleusten Code auf Googles Datenbestand Safe Browsing zurück. Die implementierten Prüfmechanismen von AntiVirus werden also um eine Datenbank erweitert. Insgesamt wird dadurch die Erkennungsrate vermutlich gesteigert – auf der anderen Seite halte ich die Verwendung von Google Services aus Datenschutzssicht für bedenklich.
Natürlich ist auch AntiVirus nicht unfehlbar. Ab und zu werden False-Positives generiert. Es werden also Alarme generiert, die in Wirklichkeit keine darstellen. Dann muss sich der Anwender die betroffene Stelle im Quellcode anschauen und den Fund beurteilen. False-Positives werden meist durch selbst hinzugefügte Code-Fragmente hervorgerufen. Weiterhin bleibt die Gefahr, dass eine Code-Manipulationen unentdeckt bleibt. Insgesamt stellt AntiVirus allerdings eine sinnvolle Ergänzung dar, die dabei helfen kann, Schadcode zu identifizieren.
5.2 Snitch
Snitch ist ein weiteres Plugin von Sergej Müller. Es ist eine Art Datenwächter für WordPress-Plugins. Jede ausgehende Verbindung wird protokolliert und in einer Übersicht visuell dargestellt. Sergej beschreibt das Plugin folgendermaßen:
Netzwerkmonitor für WordPress. Mit Verbindungsübersicht zur Überwachung und Steuerung des Datenverkehrs im Blog.
Egal ob WordPress selbst, ein Plugin oder Theme – jegliche Anfrage über die WordPress-API wird aufgezeichnet. So lassen sich mit Hilfe von Snitch verdächtige Verbindungen zu externen Zielen identifizieren.
Snitch ist in seiner Funktionalität auf WordPress-Verbindungen beschränkt. Schickt ein Plugin beispielsweise Anfragen ab und nutzt dabei nicht die WordPress eigene HTTP-API wird Snitch dies nicht registrieren. Dennoch kann es dabei helfen das ein oder andere »schwarze Schaf« ausfindig zu machen.
5.3 AntispamBee
Bei WordPress zählt die Anti-Spam Abwehr ebenfalls zur Kategorie Security Plugins. Sehr gute Erfahrungen habe ich auch hier mit einem Plugin von Sergej Müller gemacht. Es nennt sich AntispamBee und bietet durch seine Optionsvielfalt Schutz gegen jegliche Art von Spam. Datenschutz wird bei diesem Plugin auch groß geschrieben. Während Askimet jede IP-Adresse eine Kommentators an amerikanische Server überträgt verhält sich AntispamBee in seiner Standardkonfiguration datenschutzkonform.
6. Fazit
Durch Security Plugins möchte der Anwender die Sicherheit seiner WordPress-Installation erhöhen – ein löblicher Gedanke. In der Realität bieten eine Vielzahl der Plugins wenig zusätzlichen Schutz. Sie sind oft komplex, überfordern den Anwender mit unnötigen Funktionen und lassen beim ihm ein falsches Sicherheitsgefühl entstehen. Dabei gilt in der Praxis: Weniger ist oft mehr.
Sicherheit erlangt man nicht zwingend durch die Installation unzähliger Security Plugins, sondern durch eine saubere Konfiguration, stetige Updates und gesundem Menschenverstand. Wer sich an die Grundregeln hält hat schon einen Teil seiner Hausaufgaben erledigt. Durch weitere Maßnahmen kann die Wahrscheinlichkeit für eine feindliche Übernahme weiter reduziert werden. Plugins wie AntiVirus [nicht mehr verfügbar] oder Snitch bieten durchaus einen Zusatznutzen und helfen bei der Identifikation von befallenen WordPress-Installationen. Als Präventionsmaßnahme gegen Eindringversuche eignen sie sich aufgrund ihrer Ausrichtung allerdings nicht.
Im kommenden Beitrag werde ich dann weitere Maßnahmen für die Absicherung von WordPress vorstellen. Wir verlassen dann das WordPress Front-End und widmen uns der verborgenen Server-Ebene.
Über den Autor | Kuketz
In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.
Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.
Unterstützen
Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
Schwachstellen in Plugins und Themes – WordPress Sicherheit Teil3
Parasitenabwehr von Bots – WordPress absichern Teil7
Eierlegende Wollmilchsau – WordPress Sicherheit Teil2
Schutzmaßnahmen – WordPress absichern Teil2
Serverseitiger Schutz – WordPress absichern Teil5
27 Ergänzungen zu “Security Plugins – WordPress absichern Teil3”
Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Klasse Artikelserie! Das Thema hatte ich seit Ewigkeiten auf der To-Do-Liste. Streiche es jetzt gern und verweise auf deine Artikel.
Hallo
Da kann ich mich dem Vorredner Matthias Pabst nur anschließen.
Die Artikelserie ist super und klar strukturiert.
Bei manchen Plugins wege ich ab, weil Du ja nicht auf alle eingehen kannst.
Ich werde auf meiner Seite ebenfalls ein paar Zeilen schreiben und dann auf deine Artikelserie verlinken.
Gruß
Ralph
Danke euch beiden! :-)
Backup-Plugins könnte man noch grob zu den Security-Plugins zählen, oder so etwas File Monitor Plus, was einfach alle Code-Änderungen überwacht.
Spannend fände ich deine Einschätzung zu einer weiteren eierlegenden Wollmilchsau: Wordfence https://wordpress.org/plugins/wordfence/.
Und als Alternative zu dem für manche nicht möglichen htaccess-Schutz könnte man noch den Google Authenticator nehmen: https://wordpress.org/plugins/google-authenticator/ (auch auf WordPress.com möglich) – definitiv eine weitere Schranke beim Login (allerdings auch *nur* für den Login).
Und das Versionsnummer verstecken kann man sich definitiv sparen (Stichwort: Fingerprinting):
http://codeseekah.com/2012/02/20/the-wordpress-meta-generator-tag-paranoia/
(via https://konstantin.blog/2013/dont-hide-the-fact-that-youre-using-wordpress/ )
Deine Einschätzung zu dem von Torsten erwähnte Wordfence würde mich auch sehr interessieren.
Ich hatte es schon mal genutzt, aber das Plugin scheint ein großer Ressourcenfresser (Arbeitsspeicher) zu sein.
Hallo,
eine schöne Artikelserie und auch für den halbschlauen Laien wie mich verständlich.
Was mich noch interessieren würde: Kannst Du mal was schreiben zu scheinbar willkürlichen Seitenaufrufen, also Versuche, Seiten aufzurufen, die definitiv nicht da sein können, wie z.B. http://www.meinedomain.de/thing/iulsjasldjposaeiuldsjfj78wosfaj. Ich denke, da soll irgendeine Server-Antwort provoziert werden, aber was ist der Zweck?
Ich könnte mir vorstellen, dass ich nicht der Einzige bin, der so etwas in letzter Zeit verstärkt feststellt.
Schöne Grüße,
Thomas
Danke für die Kommentare.
Ich notiere mir mal:
– Wordfence anschauen (ein erster Blick lässt ein homöopathisches Allheilmittel vermuten…)
– Willkürliche Seitenaufrufe. Warum?
Weitere Fragen gerne als Kommentar oder per E-Mail. Ich sammle alles und beantworte es dann in einem speziellen Beitrag.
Hey Mike, erstmal danke für deinen Beitrag. Aber mal zum Punkt 2.2, du schreibst es zwar nicht explizit, aber ich nehme an, du meinst das Limit Login Attempts Plugin. Mir stellt sich die Frage, wie du darauf kommst, dass dieses Plugin „Angriffen von einer Größenordnung 90.000 respektive 180.000 IP’s nichts entgegen zu setzen“ hat? Ich nutze das Teil auch, habe ein Passwort mit 18 Zeichen, alles dabei, Groß/Klein, Ziffern, Sonderzeichen usw. und das Plugin ist so eingestellt, dass exakt ein Versuch erlaubt ist, danach wird die IP 4 Tage gesperrt und bei jedem weiteren Versuch wird weitere 6 Tage gesperrt.
Ich bin jetzt gerade nicht groß in Rechenlaune ;-), aber ich denke, die Zahl der Möglichkeiten lässt sich über Fakultätsrechnung ermitteln und die Zahl der im IPv4 Protokoll maximal möglichen Adressen auch. Es müsste doch demnach zu ermitteln sein, mit welcher Einstellung bei welcher Passwortlänge das Plugin den Versuchen einen Riegel vorschieben kann?!
Natürlich gibt es keine 100%ige Sicherheit und jedes Plugin erhöht sicher die Zahl der möglichen Angriffspunkte und Schwachstellen, aber mir klingt das in dem besagten Topic 2.2 einfach ein wenig zu pauschal.
Vielleicht liest ja hier ein Mathematik Spezialist mit, der das ausrechnen kann. Dürfte doch eine interessante Erweiterung deines Artikels sein….
Bastie
Hallo Bastie,
schau dir Punkt 4 an. Da bin ich darauf eingegangen. Nimmt man die Standardeinstellungen des Plugins (und das tun die Meisten nunmal) hat das Plugin Angriffen dieser Größenordnung nichts bzw. wenig entgegenzusetzen.
Du hast es richtig gemacht. Ein fehlgeschlagener Login –> Sperre. Dein Passwort ist auch sehr gut gewählt. Die Wahrscheinlichkeit, dass sich jemand bei dir per Brute-Force einloggt ist sehr gering.
Mike
Eigentlich könnte ein Plugin wie Limit Login Attempts doch nach 1, 2, x Fehlversuchen komplett dichtmachen (nicht nut die eine IP), WENN nur eine Person sich in den Admin-Bereich einloggen muss, Oder mache ich da einen Denkfehler?
Ansonsten Danke für Deine Artikel, Mike.
viele Grüße aus Kölle
joachim
P.S.: In der oberen Auswahl „… Teil einer Artikelserie“ ist der dritte Teil falsch verlinkt …
Hallo Joachim,
du könntest eine Sperre nach zwei oder weniger fehlgeschlagenen Login-Versuchen forcieren. Dann sperrt das Plugin eben früher. Gegen die Masse an IP-Adressen bringt das aber leider wenig. Das Botnetzwerk unternimmt lediglich einen Versuch und wechselt dann die IP-Adresse.
Besser ist es, dass Bots die Login-Seite überhaupt nicht aufrufen können. Das schont Server Ressourcen, da nicht jedesmal der PHP-Interpreter und die Datenbank arbeitet. Kannst du mit einem .htaccess Zugriffsschutz erreichen: https://www.kuketz-blog.de/htaccess-schutz-wordpress-absichern-teil4/
Ansonsten interessant: https://mkln.org/2013/05/7262-login-versuche-trotz-limit-login-attempts/
Gruß Mike
„Limit Login Attempts“ hat mir jedenfalls gezeigt, dass die Seiten überhaupt angegriffen werden. Ohne so ein Tool merkt man ja erst einmal gar nichts davon.
Das stimmt schon – ohne solche Tools würden viele WordPress-Betreiber überhaupt nicht wissen, was da im „Hintergrund“ eigentlich täglich passiert.
Lieber Mike,
vielen Dank für die gelungene Artikelreihe!
Was Deine Einschätzung bezüglich der „Limitierung der Login-Versuche“ angeht, so verstehe ich Dich so, dass Du empfehlen würdest auf ein Plugin zu verzichten. Statt dessen empfiehlst Du im nächsten Artikel dieser Serie die Verwendung eines zusätzlichen Passwortschutzes über eine Server-Konfigurationsdatei.
Hierzu stellen sich mir die folgenden Fragen:
1.) Welchen zusätzlichen Schutz bietet der .htaccess Schutz gegen Wörterbuchangriffe?
Wenn ein Botnetzwerk die WordPress-Loginseite angreifen kann, dann kann es doch genauso einen weiteren Passwort-Schutz angreifen. Sind Nutzername und Passwort schlecht gewählt, dann sind beide Passwort-Hürden doch ähnlich angreifbar.
2.) Ist eine Limitierung auf Nutzerbasis nicht eine wirkungsvolle Alternative zu einer Limitierung auf IP-Basis?
Das von Dir beschriebene Plugin „Better WP Security“ biete eine zusätzliche Limitierung auf Nutzerbasis. Wenn das Anmelden für einen Benutzer in einem Zeitraum zu häufig scheitert, dann wird der Zugriff für diesen Nutzer für einen Zeitraum gesperrt (unabhängig von der verwendeten IP). Durch diese Vorgehen lässt sich doch die Geschwindigkeit mit der ein Wörterbuchangriff durchgeführt werden kann enorm verringern und so die Sicherheit deutlich steigern.
Ist daher eine Limitierung der Zugriffe auf Nutzerebene nicht viel effektiver gegen Wörterbuchangriffe als ein weiterer Passwortschutz?
Grüße
Florian
Hallo Florian,
danke für dein Feedback! :-)
zu deinen Fragen:
1.) Das ist korrekt. Theoretisch sind auch Brute-Force Angriffe auf htaccess Passwortzugänge möglich. Bisher konnte ich allerdings noch keine verzeichnen, ganz im Gegensatz zu den ständigen Bot-Anfragen, welche sich mittels Brute-Force einen Zugriff auf den Admin-Bereich verschaffen wollen. Aber im Prinzip sind beide gleichermaßen angreifbar. Dennoch hat ein Zugriffssschutz auf Serverebene Vorteile:
– Kein ständiges Auffrufen des PHP-Interpreters. Einsparung von Ressourcen.
– Aktuelle und auch vergangene Bot-Angriffe zielen meist direkt auf den Admin-Bereich ab. Mit einer Sperre auf Server-Ebene minimierst du die Wahrscheinlichkeit ein Opfer solcher Angriffe zu werden.
2.) Eine Limitierung auf IP-Basis inklusive einem Zugriffsschutz ist einer Limitierung auf Nutzerebene klar vorzuziehen. Aber dabei kommt es immer stark darauf an, wie WordPress genutzt wird. Reden wir von einer Community-Seite oder einem Blog mit mehreren Autoren? Dann wird es mit einer IP-Limitierung schon schwierig, aber nicht unmöglich. Im Einzelfall sind also Limitierungen auf Nutzerbasis der serverseitigen Lösung vorzuziehen – abhängig eben vom Einsatzzweck und Umfeld. Im Übrigen kann ich auch serverseitig Maßnahmen ergreifen, die so etwas realisieren.
Insgesamt sind wir bei der Serie erst bei Teil 5 angelagt. Ich möchte noch detaillierter darauf eingehen, wie sich der htaccess Zugriffsschutz mit einer serverseitigen Absicherung kombinieren lässt. Da finden sich dann noch ein paar mehr Antworten. Dann bewegen wir uns allerdings schon auf einem sehr technischem Level, dass nicht mehr von jedem einfach mal so umgesetzt werden kann.
Hi Mike,
danke für Deine Artikelserie; Spitze! Ich werden jetzt .htaccess-Schutz einführen.
Bisher läuft limit Login Attempts, allerdings mit „verschärften“ Einstellungen: 2 erlaubte Versuche, danach Sperrung für 48 Std.; 3 Sperrungen (6 Fehlversuche) –> Sperrung für 30 Tage.
Was mir das Plugin gebracht hat ist: Zuerst gab es nur die üblichen Versuche mit admin etc. Neuerdings verwenden die „Einbrecher“ für ihre Anmeldeversuche Vor- und Nachnamen von Personen, die bei uns (=in der Ökologischen Plattform) aktiv sind. Das interpretiere ich jetzt als gezielte Angriffe auf unsere Seite – wie hätte ich die ohne das Protokoll des Plugins festgestellt?
Falls Zugriff auf den Server besteht, sieht man (fehlgeschlagene) Anmeldeversuche in den Log Files des Webservers. Daraus lassen sich im Allgemeinen eine Großzahl von potenziellen Angriffen bzw. Versuchen herauslesen.
Vielen Dank für den Artikel.
Ich habe auch eine .htaccess mit IP-Adressen Sperre drin.
Alle IPs außerhalb Europas und den USA / Kanada sind gesperrt.
Ich suche eh nur Klienten aus D-A-CH
Grüße
Ulrich
Hello,
bin jetzt mit der Serie durch, schön zu lesen, gutes Zeug dabei. Ein Security-Plugin kenne ich aber noch, bei dem ich viel zu wenig lese und mich eine weitere Meinung interessiert:
BulletProofSecurity PRO von ait-software (ait-pro.com).
Das Teil hatte ich früher auf meinen Webseiten im Einsatz und ist ein Monster. Mich würde eine Einschätzung interessieren, wie das abschneidet. Meine eigenen Erfahrungen waren positiv, freue mich aber über fachlich bessere Meinungen als meine.
Schon mal genutzt das Teil? Da wäre ein Artikel sicher auch super. Ich kann für einen Test auch behilflich sein und einen Schlüssel für eine Installation erstellen, wenn dies gewünscht ist.
Hi Mike,
hast du dir eigentlich auch mal die NinjaFirewall angeschaut? Was hälst du davon?
Teste das Plugin gerade und finde einige Features ganz interessant. Für einige Einstellungen muss man aber auch etwas tieferes Fachwissen mitbringen um nichts falsch zu machen. Gerade die Definition der Policies wird wohl den einen oder anderen Nutzer abschrecken.
Moin Matthias,
wer Zugriff auf seinen Server hat, der bildet eine WAF besser auf Webserver-Ebene ab. Dafür eignet sich bspw. NAXSI.
Das Problem mit Security-Plugins ist immer das selbe: Sie beinhalten zusätzlichen Code, der die Angriffsfläche unnötig erhöht. Besser sind »einfache« Mittel wie bspw. htaccess, wenig Plugins, ein ausgewähltes Theme und NAXSI. Security-Plugins bei WordPress sind ein Paradoxon: Sie benötigen WordPress um zu funktionieren, wollen es aber gleichzeitig schützen. Das ist der falsche Weg.
Die NinjaFirewall gibt es auch als Standalone WAF. Das WP-Plugin basiert darauf und soll auch bereits vor WordPress aktiv werden. WordPress dient wohl lediglich zur Installation und Konfiguration. Hier scheint es tatsächlich einen Unterschied zu den üblichen WP-Security-Plugins zu geben.
NAXSI werde ich mir mal anschauen. Danke für den Tipp.
Hallihallo!
Vielen Dank für diese interessanten Einblicke!
Wie sieht es denn mit einem Login-Schutz durch Captcha aus? Das ist doch zumindest gegen automatisierte Angriffe gedacht? Macht das Sinn?
Danke und viele Grüße!
Kann je nach Qualität des Captchas Sinn machen. Besser ist es aber den Login-Bereich mit einem .htaccess Passwortschutz abzusichern.
Wordfence an sich ist schon wuchtig. Aber die Fähigkeit, Dateiveränderungen zu erkennen und schnell zu melden gefällt mir. Es ist kein vollwertiges Intrusion Detection System, aber wenn ich einen Angreifer schon nicht ohne weiteres heraushalten kann, dann möchte ich eine Nachricht, wenn er anfängt meine WordPress Dateien zu editieren.
Unrechtmäßige Dateiveränderungen zu erkennen ist immer gut. Allerdings sollte dies bereits auf Server-Ebene stattfinden und nicht über ein Plugin in WordPress. Zugegeben, nicht jeder hat dazu die Möglichkeit – aber professionell betriebene Blogs vertrauen (hoffentlich) nicht dem Integrity-Check eines Wordfence. ;-)