• Skip to main content
  • Zur Haupt-Sidebar springen
  • Zur Fußzeile springen

Wordpress Agentur

  • Home
  • Know-how & Referenzen
  • Dienstleistungen
  • Agentur
    • WordPress Agentur und mehr
    • Unternehmens-Historie
    • Pressemitteilungen
  • Kontakt
  • Blog
  • Jobs
Aktuelle Seite: Start / Archiv für WP-Security

WP-Security

26. April 2016 von Webdev Kommentar verfassen

DDOS Atacke bei best-bottles.de erfolgreich abgewehrt

Heute konnten wir einen Kunden, den Spirituosen Versand best-bottles.de erfolgreich von einer DDOS-Atacke befreien. Seine WordPress-Installation wurde anfänglich von einem russischem BOT-Netzwerk, später noch von einem litaunischem BOT-Netzwerk angegriffen.

DDOS Angriff abgewehrt
DDOS Angriff abgewehrt

Zeitlicher Verlauf des DDOS Angriff

2016-04-26, 16:39:34 : erster Request des BOT-Netzwerkes
2016-04-26, 16:51:54 : Das BOT-Netz startet den Angriff
2016-04-26, 17:39:10 : Die Infrastruktur gerät ins straucheln. Anfragen dauern sehr lange (>30s)
2016-04-26, 18:02:05 : Die Infrastruktur bricht zusammen, Anfragen werden teilweise nicht mehr beantwortet (502, Bad Gateway)
2016-04-26, 18:02:05 : Das Überwachungssystem meldet uns einen Serverausfall
2016-04-26, 18:07:22 :Wir beginnen mit der Analyse des Angriffes
2016-04-26, 18:15:07 : Wir haben das Problem erkannt und stellen eine Liste von BOTs zusammen
2016-04-26, 18:17:02 : Die Firewall wird neu konfiguriert, das bisher identifizierte BOT-Netzwerk wurde ausgesperrt

FAZIT des DDOS Angriff

Gegen einen DDOS Angriff ist kein Kraut gewachsen. Wenn die Angreifer genügen Resourcen zur Verfügung haben, kann ein DDOS Angriff nicht verhindert werden. Wir haben aber gut und schnell reagiert und den Ausfall auf ein Minimum reduziert. Es sei an dieser Stelle erwähnt, dass der Angriff auf das System „nicht erfolgreich“ gewesen ist. Die Kundendaten in dem System waren zu keiner Zeit gefährdet. Wichtige Zahlungsdaten (wie z.B. Kreditkarteninformationen oder Kontotransaktionen) werden eh nicht auf dem Kunden-Webserver gespeichert.

Update 2016-04-26, 21:37:05

Neben dem russischem BOT-Netzwerk kam nun noch ein Litaunisches BOT-Netzwerk dazu. Wir waren aber auf der Hut und es ist nicht zu einem Ausfall gekommen.

 

Kategorie: Blog Stichworte: Angriff, DDOS, WP-Security

5. März 2015 von Webdev Kommentar verfassen

WordPress Security Teil #2, Sicherheitslücken im Core

Im ersten Teil meiner WordPress Security Serie ging es darum das Backend gegen Brute Force Angriffe abzusichern. Im heutigen Teil soll es darum gehen die WordPress Sicherheitslücken im Core zu sichern.

WordPress Sicherheitslücken im Core absichern

Viele werden sich nun sicherlich Fragen: „Was kann ich denn gegen Sicherheitslücken im WordPress Core machen?“. Das ist auch tatsächlich eine gar nicht so leicht zu beantwortende Frage. Der „Enduser“ von WordPress oder der reine Blog-User kann sicherlich nichts gegen Sicherheitslücken im WordPress Core anrichten. Auch wir als WordPress Profis haben da nur eingeschränkte Mittel.

Der reguläre WordPress User schaut in den Core in der Regel gar nicht rein. Er wird also möglicherweise erst durch die Medien von einer Sicherheitslücke in Kenntnis gesetzt. Wenn ein User erfolgreich angegriffen wurde, werden meist wir Profis gerufen und dann geht es in erster Linie um Schadensbegrenzung.

  • Lücke finden
  • Lücke schließen
  • Lücke melden
  • auf Update warten

Das sind für uns Profis die begrenzten Werkzeuge die wir haben. Der Core ist und bleibt heilig. Er darf auf keinen Fall angepasst werden (dafür ist das Core Team zuständig).

Nun gut, warum schreibe ich heute einen zweiten Teil über ein Thema, wo man so wenig machen kann? Wie bereits erwähnt können wir an den Sicherheitslücken im WordPress Core sehr wenig machen. Wir können aber verhindern dass die Sicherheitslücken größeren Schaden anrichten.

Security vs. Usability

Ich muss mal einen kurzen Abschnitt zur WordPress Security einwerfen. Security vs. Usability ist immer ein großes Thema. Ich bin schon in „WordPress Security Teile #1“ bei den sicheren Passwörtern auf diese Problematik eingegangen.

Je sicherer ein System ist, je schlechter ist die Usability!

Spätestens morgen werden einige Kommentare auf mich hereinprasseln, wie ich so was in die Welt setzen kann. Es gibt auch sichere benutzerfreundliche Systeme werden andere Blogger sagen. Nein wird meine Antwort sein, die gibt es nicht. Es ist immer eine individuelle Meinung. Es wird sicherlich hunderte von Menschen geben, die ein 12 Zeichen langes Passwort mit Sonderzeichen für benutzerunfreundlich halten; Und die die am lautesten schreien, werden spätestens nach dem 10 mal eintippen auf dem iPad meiner Meinung sein.

Also um es kurz zu fassen.
Wir müssen uns zwischen Sicherheit und Benutzerfreundlichkeit entscheiden oder einen guten Kompromiss finden.

WordPress Schreib- & Leserechte

Ich werde ganz häufig gefragt wie ich die Schreib- & Leserechten des Dateisystems einer WordPress Installation handhabe. Das kann so global nicht beantwortet werden und hängt sehr von dem Kunden und dessen Anforderungen an Komfort und Usability ab. Am liebsten würde ich Allen alle Schreibrechte entziehen. Geht aber leider nicht immer. Schauen und diskutieren wir die einzelnen Verzeichnisse mal durch:
Anmerkung: Ich gehe in den Beispielen davon aus, dass der Web-Server-User ein anderer ist, als der SFTP (FTPS-User).

/wp-admin/*, /wp-includes/*

Es gibt nur eine einzige Situation, wo ins wp-admin Verzeichnis geschrieben werden muss. Nämlich beim Update. Wenn der Webserver-Prozess in das Verzeichnis schreiben darf, kann ein Angreifer Dateien modifizieren oder neue anlegen. Wenn wir die WordPress Installation via FTPS oder SFTP auf den Webserver kopiert haben, dann kann man dem Ordner also eine 7-5-5 Berechtigung geben (so der FTPS/SFTP User ein anderer ist, wie der Webserver-User).

Vorteil:

Ein potentieller Angreifer kann keine Dateien im wp-admin-Ordner verändern oder neue anlegen.

Nachteil:

Das automatische Update funktioniert nicht mehr, weil eben der Web-Prozess die Dateien selber nicht überschreiben darf. Hier ist ein kurzer Klick zum Update notwendig, sowie die Eingabe des SFTP/FTPS User / Passwortes. (Sicherheit vs. Usability)

/wp-content/uploads/*, /wp-content/cache/

Der Webserver muss in diese beiden Verzeichnisse rein schreiben dürfen. Wir müssen Ihm (leider) ein Schreibrecht einräumen. Diese beiden Ordner bekommen also eine 7-7-5 Berechtigung. Nun haben wir hier einen potentiellen Angriffspunkt geschaffen. Ein Angreifer könnte in Zusammenhang mit einer Sicherheitslücke PHP-Dateien in diesen Ordner ablegen und ausführen. Wir verbieten deshalb gleichzeitig den direkten Zugriff auf die .php Dateien.

Dazu legen wir eine .htaccess Datei mit folgendem Inhalt in die betreffenden Ordner:


<Files *.php>
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</Files>

Die Zeile „Allow from 127.0.0.1“ ist übrigens dafür, damit z.B. CRON-Jobs in den Ordnern vom localhost dort ausgeführt werden dürfen.

Alle anderen Ordner

Alle anderen Ordner benötigen meines Erachtens keinen Schreibzugriff. Auch der Theme-Ordner oder die Plugin-Ordner nicht! Natürlich das Update muss jetzt von Hand durchgeführt werden. Aber dafür ist es sicherer. (Security vs. Usability)

Was haben jetzt die Schreibrechte mit dem WordPress Core absichern zu tun?

Es passte gerade an diese Stelle. Es hat nicht direkt etwas mit dem WordPress Core absichern zu tun. Es verhindert aber, dass sich ein Angreifer unkontrolliert im selbigen ausbreitet.

Updates

Das wichtigste sind Updates. Sehen Sie zu, dass Sie zeitnah alle Updates installieren. Gerade solche, die als „Kritisch“ getagt sind. In der Regel ist es so, dass wenn Sicherheitslücken bekannt werden, diese im Security Team besprochen und so lange „geheim gehalten“ werden. Es wird ein fix entwickelt und mit der Veröffentlichung der Sicherheitslücke steht auch ein Update bereit.

Es währe ja Wahnsinn alle Sicherheitslücken von WordPress zu veröffentlichen, ohne vorher einen FIX anzubieten. Das wäre ja eine Einladung an alle Hacker, nach dem Motto:

Ihr braucht keine Lücken zu suchen, wir sagen Euch wo die sind!

WordFence

Durch die Installation und richtige Konfiguration von Plugins wie z.B. WordFence wird auch im WordPress Core ein großer Bereich überprüft. Das WordFence Plugin prüft die WordPress Installation gegen das WordPress Repository und meldet veränderte Dateien. So werden zumindest erfolgreiche Angreife sehr schnell erkannt und können bekämpft werden. Das Plugin prüft aber noch viel mehr, darauf gehe ich aber in den einzelnen Teilen weiter drauf ein.

Natürlich prüft WordFence auch die Version der Core-Files und meldet via Mail ob Updates zur Verfügung stehen.

So, genug für heute, im nächsten Teil geht es um die Absicherung der Themes.

 

Kategorie: Blog, Wordpress sichern Stichworte: Wordpress absichern, WordPress Sicherheit, Wordpress sichern, WP-Security

29. Januar 2015 von Chriss Gebbing Kommentar verfassen

WordPress Security Teil #1, Brute Force verhindern

Zurzeit häufen sich wieder die Angriffe auf WordPress Installationen. Dabei gibt es ganz unterschiedliche Gründe, für einen Angriff. Zu den 5 häufigsten Gründen gehören wohl:

  • Angriffe auf den Sitebetreiber (um tatsächlich Schaden anzurichten, Daten zu zerstören)
  • Angriffe zur Verbreitung von Schadcode (meist Javascript, Flash oder Java-Applets)
  • Angriffe zur Übernahme des Servers in ein Zombie-Netzwerk
  • Page-Rank Diebstahl (Link-Building)
  • Hacker-Kids (die es aus Spaß machen, aber möglicherweise trotzdem Schaden anrichten)

Aber es gibt auch unterschiedliche Angriffsarten:

  • Brute Force auf das WordPress Login Formular
  • Ausnutzen von Sicherheitslücken im WordPress Core-Code
  • Ausnutzen von Sicherheitslücken im Theme (in den Themes)
  • Ausnutzen von Sicherheitslücken im Plugin (in den Plugins)
  • Angriffe auf den Server selber (z.B. FTP oder SSH Login)
  • Ausnutzen von Sicherheitslücken des Servers/der Serversoftware

Wie bei vielen anderen Themen, muss auch bei der WordPress Security jedes Angriffs-Szenario einzeln betrachtet, aber im Gesamten angegangen werden.
Es hilft überhaupt nicht, wenn man ein sicheres Passwort wählt, aber die Plugins unbeachtet veralten lässt. Auch muss unterschieden werden zwischen Präventivmaßnahmen und Sofort-Notfall-Maßnahmen.
Im Klartext:
„Will ich mich davor schützen, dass ich angegriffen werde“
oder
„Ich wurde bereits angegriffen und muss den Schaden minimieren“.
Dieser Beitrag handelt nun davon, wie man sich vor Brute-Force Angriffen auf das WordPress Login Formular schützen kann. Dabei gilt aber der Grundsatz: „Es gibt keine 100%ige Sicherheit“. Mann kann es dem Angreifer nur so schwer wie möglich machen mich anzugreifen.

Brute Force auf das WordPress Login Formular

An vielen Stellen liest man, dass es wichtig ist einen sicheren Benutzernamen und einen sicheres Passwort zu wählen. Grundsätzlich stimmt das natürlich, ist aber an vielen Stellen auf WordPress nicht übertragbar.

Sicherer Benutzername in WordPress

In der Standardinstallation erlaubt WordPress keine echten sicheren Benutzernamen. Tatsächlich sind nur Buchstaben, Zahlen, das AT-Zeichen (@), der Punkt, der Bindestrich und der Unterstrich im Benutzernamen erlaubt. Aber auch damit sind bereits einigermaßen sichere Benutzernamen möglich.
@chriss-2015@admin.amenotec@_@ liest sich für den Menschen zwar ganz normal, ist aber für ein Angreifer (Script, Bot) deutlich schwieriger zu erraten wie „admin“, „chriss.gebbing“ oder „chriss-gebbing“.
Aber was ist mit bestehenden unsicheren Benutzernamen?
Wordpress erlaubt es nicht den Benutzernamen zu ändern!
Entweder man nimmt ein Tool wie phpMyAdmin und ändert den Benutzernamen direkt in der Datenbank oder man erstellt erst den neuen „sicheren“ Benutzer, löscht den alten und während des Löschvorgangs fragt WordPress nach, wer den Content des alten Benutzers übernehmen soll.

Sicheres Passwort in WordPress

Natürlich ist es einfach sich ein sicheres Passwort für WordPress zu vergeben. Aber es hilft der WordPress Security nicht, wenn man sich das Passwort nicht merken kann und irgendwo aufschreibt. Die meisten User wissen gar nicht was ein sicheres Passwort ist. Die Frage ist auch gar nicht so leicht zu beantworten. Wikipedia geht davon aus, dass ein Passwort mit 8 Zeichen das nur aus Groß- und Kleinbuchstaben besteht innerhalb von 15 Stunden gehackt werden kann. Das ist aber eine rein theoretische Zahl die darauf basiert, dass eine Software 1 Milliarde Schlüssel pro Sekunde ausprobieren kann. Haben Sie keine Angst, das lässt Ihr Webserver nicht zu. Es würde viele Tage und Wochen brauchen ein 8 Zeichen langes sicheres Passwort zu knacken. Das Problem an dieser Stelle ist tatsächlich die Menschlichkeit. Die User versuchen sich das Passwort zu merken und nehmen deshalb ein leichtes. Vielleicht den Namen der Frau oder Freundin, der Name des Haustiers oder das Geburtsdatum. Zeichenfolgen auf der Tastatur „qwertz“ (Und für alle die es besser meinen, „qayxsw“ ist genauso) in wenigen Sekunden geknackt.
Nun gut, nehmen wir im Besten Fall an, der Admin nutzt ein sicheres Passwort. Steigert das die WordPress Security? Was ist wenn Sie im Team arbeiten? Wie wollen Sie als Sitebetreiber garantieren, dass jeder ein sicheres Passwort benutzt?
Klar, ein Plugin muss her: Password Policy Manager ist so ein Plugin. Man kann selber Regeln festlegen wie ein Passwort aufgebaut werden muss. So haben auch Team-Mitglieder keine Chance sich „einfache“ Passwörter zu merken. Sie müssen sich dann aber mit Ihren Team-Mitgliedern auseinandersetzen. Wenn der Unmut wächst, werden irgendwann die Regeln wieder gelockert und dann hat alles vorher gemachte keinen Sinn.

Logins limitieren

Die Logins zu limitieren kann auf unterschiedliche Weise erreicht werden.

  • Limit der Login-Versuche
  • Limit der Login-IP’s
  • zusätzliche Limitierung
Limit der Login Versuche

Wenn sich nun einige den Wikipedia-Eintrag zum Thema Passwort angesehen haben, so wird mancher erschreckt denken:
„Was ist denn mit meinem Bank-Pin. 4 Stellig, nur Zahlen, also in unter 1ms zu knacken?“
Ja, das wäre theoretisch möglich. Es gibt ja eben nur 10.000 Kombinationen (eigentlich noch weniger, weil einige Kombinationen herausfallen). Das ist relativ schnell ausprobiert. Aber der potentielle Angreifer hat keine 10.000 Versuche. Die Karte wird nach drei fehlerhaften Versuchen einbehalten oder gesperrt. Genau hier setzen derlei Plugins wie Limit Login Attempts an. Sie erlauben nur wenige Versuche das Passwort zu erraten und sperren den Account, die IP-Adresse oder ähnliches.
Aber Vorsicht: Mann sollte immer mehrere User anlegen und im Zweifel einen Admin-User unbenutzt in der Ecke liegen lassen. Wenn ein Robot Ihren Admin-Account errät und sperrt, so kommen Sie selber auch nicht mehr ohne FTP- oder Datenbankzugriff in Ihre WordPress Installation.

Limit der Login-IP’s

Sie haben eine feste IP bei Ihrem Provider? Schön, dann verbieten Sie doch einfach allen anderen IP-Adressen das WordPress Backend. Der Vorteil liegt klar auf der Hand: Nur Ihr Anschluss darf ins Backend. Der Nachteil ist aber auch gravierend: Nur Ihr Anschluss darf ins Backend. Sie können also nicht von unterwegs „mal eben“ etwas posten.
Nur eine einzige IP im Backend zu erlauben ist recht einfach. Tragen Sie folgende drei Zeilen in Ihre .htaccess-Datei im WordPress Root-Path ein.

RewriteCond %{REQUEST_URI} !^/wp-admin/admin-ajax.php.*
RewriteCond %{REMOTE_ADDR} !=1.2.3.4
RewriteRule ^wp-admin/.* - [F]

1.2.3.4 ist dabei natürlich ein Platzhalter für Ihre feste IP-Adresse. Die erste Zeile schließt übrigens die Datei admin-ajax.php aus, da diese auch aus dem Frontend heraus benötigt wird.
Aber Achtung: Manche Provider erlauben das einschalten der RewriteEngine nicht. Da es aber hier eh spätestens bei den SEO- oder den Cache-Plugins Probleme gibt, sollten Sie hier über einen Providerwechsel nachdenken.

Zusätzliche Limitierungen

Wir selber nutzen ein Plugin, dass dem User bei jedem Login-Versuch per Request erst einen Security-Code auf sein SMS schickt. Erst durch zusätzliche Eingabe dieses Codes kann man sich am Backend von WordPress anmelden. Das Plugin befindet sich gerade in der Testphase und wird voraussichtlich im Sommer veröffentlicht. Es verbindet drei Sicherheitsmechanismen

  • Single Passwort (Ein Passwort ist nur einmal gültig),
  • Zwei-Faktor-Authentifizierung (Authentifizierung über zwei getrennte Kanäle)
  • Disallow Account Sharing

Der letzte Punkt „Disallow Account Sharing“ wird oft vernachlässigt. Es gibt einen Admin-Account und 10 Personen kennen und nutzen den Account und dessen Passwort. Das wird durch dieses Plugin unterbunden, weil in der Regel nicht alle zehn Personen sich das gleiche Handy teilen, auf dem der Security-Code gesendet wird.

Wir halten dies aktuell für das sicherste Verfahren um das WordPress Backend abzusichern, dass mobil von unterschiedlichen Rechnern aus einsetzbar ist.

Die Sicherung des Backends durch HTTPS und selber ausgestellten Zertifikaten ist technisch möglich) bedingt aber, dass ich mein Zertifikat immer dabei habe und dies womöglich auf einem PC in einem Internet-Caffee installiere, womit es wieder „unsicher“ wird.

Der nächste Beitrag wird davon handeln, wie man das Ausnutzen von Sicherheitslücken im WordPress Core-Code verhindert.

Kategorie: Blog, Wordpress sichern Stichworte: Brute Force, Wordpress absichern, WordPress Sicherheit, WP-Login, WP-Security

Haupt-Sidebar (Primary)

Nächste Schritte

Rufen Sie uns doch einfach an!

Viele Dinge lassen sich in einem ersten Telefonat klären.

Ihre zentrale Ansprechpartnerin

agentur für wordpress Kerstin Venus

Kerstin Venus
+49(0)2871 489530-0

Footer

Wordpress Agentur und mehr

Wir sind die WordPress Agentur, bei der die Arbeit mit dem Design und der Installation von ein paar Plugins nicht beendet ist. Wir können unsere Kunden insbesondere immer dann begeistern, wenn es etwas komplizierter wird. Was nicht heißt, dass wir die Web-Projekte kompliziert machen. [weiter lesen...]

Letzte Beiträge

  • DDOS Atacke bei best-bottles.de erfolgreich abgewehrt
  • WordPress 4.4 RC1 veröffentlicht
  • WordPress 4.3 BETA 3 veröffentlicht
  • WordPress 4.3 BETA 2 veröffentlicht
  • WordPress 4.3 BETA 1 veröffentlicht

Rechtliches

  • Impressum
  • Datenschutzerklärung
  • Kontakt
  • Sitemap

© Copyright 2013 amenotec evolution GmbH · All Rights Reserved