WordPress / IT-Sicherheit

Schützt WordFence meine WordPress-Seite so gut, wie alle behaupten?

Aktualisierung: 20. Februar 2019 | 14:06 Uhr

WordFence und die WordPress-Sicherheit: Vor einigen Tagen wurde im Hisox-Blog der dieser Artikel veröffentlicht. Das Thema ist grob WordFence als Schutzmaßnahme für Corporate Blogs, also für Unternehmensseiten (was in der Regel bedeutet, dass da keine kleinen Blogger dahinter stehen). Sich aus Sicht eines Unternehmens auf WordFence und Co. zu verlassen sehe ich als grob fahrlässig.

Bei meiner täglichen Arbeit begegnen mir immer wieder Kunden, die sich zu sehr auf WordFence und Co. verlassen haben. Hier fehlt das Verständnis, dass man obwohl man alles super abgesichert hat, trotzdem gehackt wurde, denn „WordFence sollte ja davor schützen“. Die Marketing-Abteilungen der Unternehmen hinter WordFence machen eben sehr gute Arbeit.

Daher denke ich, dass es an der Zeit ist dem Thema einen längeren Artikel zu widmen, dessen Inhalt sich folgendermaßen aufbaut:

  • Was ich teste
  • Exkurs: Datenübertragung in PHP
  • Schützt WordFence vor XSS-Angriffen?
  • Schützt WordFence vor SQL Injections?
  • Schützt WordFence vor PHP Object Injections?
  • Exkurs: PHP Object Injection? Was ist das?
  • Exkurs: PHP Object Injection an konkreten Beispielen
  • Allgemeine Hinweise zu WordFence und Co.
  • WordFence Scanner umgehen – eine kleine Anleitung
  • Einfache Schutzmechanismen
  • Augen auf bei der Hoster-Wahl
  • Fazit
  • Ninja Firewall als Alternative

Vorab: WordFence und Co. haben ihre Daseinsberechtigung und sind durchaus sinnvoll. Was mich allerdings stört, dass felsenfest behauptet wird, dass diese PHP-Plugins Angriffe auf die eigene PHP-Seite verhindern und nahezu perfekte Sicherheit bieten. Der eine oder andere meint sogar, wer WordFence installiert, sich keine Sorgen um Sicherheit machen muss. Solche Aussagen kommen meist von Menschen, die quasi NICHTS mit IT-Sicherheit zu tun haben, eine Sicherheitslücke im Code nicht erkennen könnten und sich nicht mit dem Thema allgemein beschäftigen und Dinge nachplappern, die sie irgendwo gehört haben – oder dafür bezahlt werden.

Was also tun? Was bietet sich also besseres an, als mal WordFence zu installieren und einfach mal durchzuprobieren, welche Arten von Sicherheitslücken effektiv blockiert werden?

Wir brauchen verschiedene Arten von Sicherheitslücken

Ich habe mir ein simples WordPress-Plugin programmiert, das verschiedene beliebte und bekannte Sicherheitslücken aufweist. Hierzu zählen:

  • Cross Site Scripting (XSS)
  • SQL Injections
  • PHP Object Injection

Das Plugin erlaubt es, jede dieser Sicherheitslücken über $_GET, $_POST, $_COOKIE oder $_SERVER auszunutzen (siehe dazu den Exkurs weiter unten). $_REQUEST und $_FILE habe ich ausgelassen, da $_REQUEST die gesamten Daten der drei erstgenannte Methoden beinhaltet. Zur Demonstration waren reine Uploadvorgänge für mich ebenfalls nicht von Interesse, daher wurde $_FILE ebenfalls ausgelassen.

Exkurs – Datenübertragung in PHP:

In einer PHP-Webapplikation gibt es einige Wege, Daten/Informationen an den Server zu senden. Dazu zählen u.a. die oben erwähnten. Im Folgenden eine kurze Erläuterung der einzelnen Wege/Möglichkeiten:

  1. $_GET: URL-Parameter sind in diesem Array zu finden, d.h. ein index.php?var=123&test=1337 ist in diesem Array unter $_GET[‚var‘] bzw. $_GET[‚test‘] zu finden.
  2. $_POST: Formulardaten – wenn du ein Formular ausfüllst, z.B. E-Mail oder Passwort-Felder, sind diese Eingaben in diesem Array abgespeichert
  3. $_COOKIE: Wie der Name schon sagt, die Cookies, die die Seite setzt, sind in $_COOKIE gespeichert. Ein Cookie hat in der Regel einen Gültigkeitsbereich sowie ein Ablaufdatum.
  4. $_SERVER: Serverangaben und bestimmte Teile des Requests landen hier. Hierzu zählt z.B. deine IP, der angefragte Pfad, der User-Agent und dutzende andere Informationen
  5. $_FILE: Uploadformulare – Daten, die mit dem Uploadvorgang an ein PHP-Script zu tun haben, wird man hier finden
  6. $_REQUEST: Über dieses Array kann man auf alles zugreifen, was in $_GET, $_POST oder $_COOKIE ebenfalls zu finden ist.

Die drei ausgewählten Methoden, Websites aller Art – unabhängig von WordPress – anzugreifen, sieht man extrem häufig. XSS und SQLi sind vermutlich die beiden Angriffe, die man am häufigsten sieht. Hierzu lohnt mal der Blick auf z.B. exploit-db und eine Stichwort-Suche nach WordPress. Die letzte Art von Sicherheitslücke ist wohl die spannendste. Die wenigsten kennen diese Art von Sicherheitslücke. Auch sie ist alles andere als trivial auszunutzen und hängt vor allem vom System ab, in dem man sie findet.

Schützt WordFence vor XSS-Angriffen?

Bedingt. Der Filter von WordFence ist relativ gut. Wird der Payload (HTML-Code, Javascriptcode) über $_GET (URL-Paramter z.B.) oder $_POST (meist Eingabefelder, Suchen, …) schützt WordFence recht effizient. Spannend wird es, wenn der Payload aber über einen Cookie oder über eine Server-Variable übertragen wird. Dann nämlich schützt euch WordFence gar nicht. Ich habe zum Testen den folgenden Code verwendet, wer den etwas ausschmückt, der wird damit beispielsweise den Cookie klauen können:

"><script>alert(document.cookie)</script>
XSS, trotz WordFence

Jetzt wird man sagen können: Aber XSS funktionieren doch NIE über $_SERVER/$_COOKIE. Das ist falsch, und das witzige ist, dass WordPress bzw. ein Plugin den Gegenbeweis liefert. Und das ist sogar recht bekannt – User Login-Log hatte Anfang 2017 eine XSS-Lücke. Zum Ausnutzen musste man einfach den eigenen User-Agent manipulieren und sich anschließend versuchen (egal ob erfolgreich oder nicht) einzuloggen. Der Wert wurde übernommen und abgespeichert. Im WP-Admin wurde der Payload dann in der Tabelle ausgeführt. Man könnte so die Zugangsdaten eines eingeloggten WP-Administrators stehlen (und noch viele andere schöne Sachen machen). Auch Plugins, wie etwa All in One SEO waren betroffen.

Fazit für mich: Wenn es um Schutz vor XSS geht, ist WordFence alles andere als schlecht. Aber es schützt eben nicht perfekt.

Schützt WordFence vor SQL Injections?

SQL Injections sind sehr spannend und treten häufig auf. Vor allem dann, wenn die Entwickler nicht mit $wpdb vertraut sind und selbst eigene Queries schreiben. Bei dieser Angriffsart hat der Entwickler erlaubt, das Nutzereingaben ungefiltert in eine Datenbankabfrage kommen. Als Beispiel sei zu nennen:

SELECT option_name FROM options WHERE option_id = [Nutzereingabe]

Mit dem Injizieren von „-1 UNION SELECT CONCAT(‚,‘,email,password) FROM nutzertabelle WHERE id=1“ an der Stelle, an der sich [Nutzereingabe] befindet, sorgt man dafür, dass statt „option_name“ eben die Kombination von E-Mail und Passwort des Nutzers mit der ID 1 ausgegeben werden. Und selbst wenn man keine Ausgabe hat, kann man über blindes Injizieren indirekt auf das Ergebnis kommen. In freier Wildbahn sieht das in etwa so aus: SQL Injection im Plugin Mail Masta

Auch für diesen Fall hab ich mir eine simple Query gebaut und erlaubt, über die vier oben genannten Methoden eigene Daten in die Query zu schleusen. Das ganze sieht in etwa exemplarisch für $_GET so aus:

 global $wpdb;
 $results = $wpdb->get_results('SELECT option_id FROM wp_options WHERE option_id = ' . $_GET['damian-2'], OBJECT);
 echo '<pre>';
 print_r($results);
 echo '</pre>';

Im Grunde eine Abfrage nach der ID der Option auf Basis der ID selbst. Unsinnig, aber vollkommen ausreichend. Als Ausgabe erwarte ich die ID.

Hier wird es durchaus spannend. Ohne in den Quellcode von WordFence zu schauen, habe ich einiges ausprobiert und konnte feststellen, dass komplexere Angriffe immer abgewehrt werden, wohingegen simple Informationsabfragen problemlos durchkommen. Beispielsweise so etwas:

-1 union select version()

Hier spielt auch die Methode keine Rolle. Simple Abfragen gehen immer durch. WordFence wird hier vermutlich eine Art Punktesystem haben, ab wann sicherheitshalber blockiert wird.

Folgende Abfrage wird ebenfalls abgewehrt.

-1 union select 2 from wp_options

Das ist schon mal gut. Getestet wurde auch hier erst $_GET, dann $_POST. Jetzt mal wieder der Klassiker. Injection via $_COOKIE. Auch das kommt hin und wieder in freier Wildbahn vor. Und siehe da… nichts wird blockiert. Das gleiche gilt für $_SERVER.

SQL Injection trotz WordFence

Im Bild sieht man meinen Usernamen sowie den Passworthash, den ich unkenntlich gemacht habe. Außerdem sieht man im rechten Teil des Browserfensters, welchen Inhalt der Testcookie hatte.

Fazit für mich: Der Großteil wird via POST/GET übertragen und vermutlich recht erfolgreich abgewehrt. Lässt sich via Cookie oder Server-Variable etwas in eine Query schleusen, hilft einem auch WordFence nicht weiter. Man könnte hier noch weiter versuchen, das Passwort auch via GET/POST zu bekommen. Mich würde nicht wundern, wenn es einen Weg gäbe, die Sicherheitsvorkehrungen zu umgehen. Wichtig ist auch zu wissen, dass es sehr stark auf die Art der SQL Injection ankommt. In meinem Fall habe ich eine gewählt, bei der nach „WHERE“ eigene Daten dazu kommen. Für den äußerst seltenen Fall, dass man die Tabelle selbst verändern kann, d.h. kein „FROM“ und kein „UNION“ nötig ist, wird man wohl auch via GET/POST erfolgreich sein.

PHP Object Injection? Was ist das?

Ich könnte hier viel schreiben, aber ein Link ist einfach und es gibt tolle Quellen zu dem Thema: https://www.owasp.org/index.php/PHP_Object_Injection

Schützt WordFence mich vor PHP Object Injections?

Der eine oder andere wird sich jetzt sagen, dass er noch nie eine dieser Lücken in WordPress gesehen hat. Aktuell findet man keinen Eintrag in Exploit-DB. Das liegt nicht daran, dass sie nicht existieren. Das liegt eher daran, dass sie so gefährlich sind, dass jeder vernünftige Pentester sie meldet und keinen Exploit schreibt und veröffentlicht. Wenn überhaupt werden diese Angriffsmöglichkeiten nur sehr grob beschrieben. Ein schönes Beispiel ist eine solche Lücke in Piwik: Piwik <= 2.16.0 (saveLayout) PHP Object Injection Vulnerability

Konkret im Fall von WordPress kann ich berichten, dass eine solche Lücke in einem recht bekannten Theme in sehr naher Zukunft geschlossen wird. Details verrate ich natürlich nicht, aber bei einem Kunden, der gehackt wurde, konnte ich mir den Quellcode genauer anschauen und habe eben eine POI Lücke gefunden und gemeldet. Obwohl ich es umsonst gemacht habe und nichts verlangt habe, will das Unternehmen eine vierstellige „Bug Bounty“ zahlen. Das zeigt nicht, wie toll ich bin, es zeigt, dass die Unternehmen wissen, was so eine Lücke bedeutet – vor allem in einer Software, die Tausende verwenden.

In dem Sinne schauen wir mal, wie gut sich WordFence bei dem Thema schlägt. Auch hier nehme ich eine triviale Lücke:

class poi
{
    public $test;

    public function __destruct()
    {
        eval($this->test);
    }
}

Man sieht ein simples Objekt, das im Destructor in der Lage ist, Code auszuführen. Wenn ich also auf $test Zugriff habe und es irgendwie schaffe, den Destructor aufzurufen, dann wird der Code in $test ausgeführt. Hört sich einfach an, ist es aber in der Realität nicht. Meine Klasse ist super simpel und dient der Veranschaulichung. Im richtigen Leben wird sie in der Form nicht vorkommen (hoffentlich). Typische Anwendungsbeispiele sind z.B. Loggingfunktionen, die man gerne in den Destructor packt. Beim Zerstören des Objekts wird diese Methode aufgerufen.
Um eine POI auszunutzen, kann man bei der Funktion „unserialize“ ansetzen. Sie hat einige interessante Eigenschaften. Ich zitiere aus der PHP Dokumentation:

Warnung: Unvertrauenswürdige Benutzereingaben sollten nicht an unserialize() übergeben werden. Die Deserialisierung kann durch Objektinstanziierung und Autoloading dazu führen, dass Code geladen und ausgeführt wird, und ein böswilliger Anwender kann in der Lage sein das auszunutzen. Es ist ein sicheres, standardisiertes Austauschformat wie JSON (per json_decode() und json_encode()) zu verwenden, wenn serialisierte Daten an den Nutzer übergeben werden müssen.

Wird dummerweise meist ignoriert.

Tipp: Wer lustig ist, der kann in seinen Plugins und Themes nach „unserialize“ oder konkreter „maybe_unserialize“ suchen. Wer so eine Stelle findet, der kann versuchen weiter zu schauen und rausfinden, ob es irgendwie möglich ist dort eigene Eingaben reinzubringen. ABER: das alleinige Vorhandensein der Funktion ist noch keine Sicherheitslücke, man kann sie auch recht sicher verwenden (hierzu sei auf den zweiten Parameter der Funktion verwiesen).

Um so etwas auszunutzen müssen wir also nach unserialize suchen und zusehen, dass wir dorthin unsere Daten übertragen können. Das sieht in meinem Fall ganz stupide so aus:

$test = unserialize($_GET['data']);

Long story short:

deinewpseite.de/index.php?data=O%3A3%3A"poi"%3A1%3A%7Bs%3A4%3A"test"%3Bs%3A10%3A"phpinfo%28%29%3B"%3B%7D

In sauber sieht das dann so aus:

deinewpseite.de/index.php?data=O:3:"poi":1:{s:4:"test";s:10:"phpinfo();";}

Die Daten werden offensichtlich via URL an PHP übertragen und landen dann in unserialize. Dann wird das Script beendet und kurz davor wird das Objekt eben zerstört/gelöscht. Das ist der Punkt, an dem die Destruktor-Methode aufgerufen wird.

WordFence ist nicht in der Lage so einen Angriff (aktuell) zu erkennen und abzuwehren.

Das Problem ist/war, dass man im CMS/System eine andere Klasse haben muss, die eben eine magische Funktion hat und deren Inhalt von „Interesse“ ist. Wer findig ist, wird da eigentlich immer etwas finden. Hier am Beispiel einer uralten WordPress-Version. Man kann natürlich auch Plugins und Themes verwenden (bzw. deren Klassen). Da hat man eigentlich immer Glück.

Exkurs: PHP Object Injection an konkreten Beispielen

Die Funktionsweise dieses Angriffs bzw. die Möglichkeiten hängen sehr stark davon ab, mit welcher PHP-Version man unterwegs ist. Je älter desto schlechter. Neu bringt allerdings auch nicht so viel, wie diese verlinkte Analyse recht schön zeigt. In dem Zusammenhang sei ein Artikel eines langjährigen Kumpels (von dem ich viel gelernt habe :P) verwiesen: How we broke PHP, hacked Pornhub and earned $20,000

Oder man lässt es komplett und schaut sich folgenden Beitrag vom letzten CCC an. Dann sieht man, was mit unserialize alles möglich ist. Dabei ist es egal, was für Klassen das angegriffene System so bietet.

Fazit für mich: Vor komplexen Angriffsmethoden schützt WordFence euch nicht. Da darf man sich nichts vormachen!

Allgemeine Hinweise zu WordFence und Co.

Diese „Firewalls“ schützen euch vor bestimmten Angriffsszenarien. Sie schützen euch, weil sie konkrete Angriffe kennen. Neue Angriffe oder untypische Wege sind meist ungeschützt. Man muss auch verstehen, dass WordFence ein Plugin innerhalb von WordPress ist. Wenn ihr auf eurem Server ein Script habt, das gehackt werden kann, dann wird WordFence euch an der Stelle nicht schützen. WordFence schützt ebenfalls keine Komponenten, die von Plugins und Themes verwendet werden, aber nicht unmittelbar im System sind. Beispiele wären hierfür z.B. Uploadscripte (immer eine dumme Idee) oder so etwas, wie das gute alte Timthumb.

WordFence und externe Upload/Download-Scripte

Exkurs: Vor allem Entwickler von „Premium-Plugins“ neigen dazu, sämtliche Authentifizierungsmaßnahmen, die WordPress anbietet, zu ignorieren. Das Ergebnis sind dann Plugins, die irgendwelche Upload-Funktionalitäten mitbringen. Diese werden dann über eine externe Datei in das Plugin gehangen. Das Problem dabei ist, dass diese Datei eben von allen erreichbar ist und dazu verwendet werden kann, Dateien hochzuladen. Ein Uploadformular muss man hierzu nicht sehen. Diese Art von „Sicherheitslücke“ erwähne ich, weil sie ein Klassiker ist und ein gutes Beispiel dafür, warum WordFence hier eben nicht ansetzen kann. Diese Upload-Dateien hängen eben nicht im WordPress-System. Einige Beispiele:

Hiergegen würde aber sinnvolle Dateirechte helfen. Wenn der Angreifer nirgendswo schreiben kann, dann bringt ihm so etwas reichlich wenig. Dazu gibt es im nächsten Abschnitt einige Worte.

Das Gegenteil solcher Lücken sind Plugins, die es erlauben Dateien herunterzuladen. Sowas kommt recht selten vor, aber die bekannten Fälle haben die Eigenschaft, dass die Scripte ebenfalls nicht im System hängen. Daher hat WordFence auch hier keine Chance zu schützen.

Je nach Entwickler eines Plugins oder Themes wird euch WordFence auch GAR NICHT schützen. Man sieht regelmäßig, dass Entwickler mit $_REQUEST arbeiten. Warum ist das so interessant? Oben habe ich gezeigt, dass WordFence quasi nichts in den Cookies prüft. Der Inhalt eines Cookies lässt sich auch in $_REQUEST finden. Super, oder? 😉 Mehr muss ich da eigentlich nicht sagen.

Weiß man das, dann ist WordFence nicht schlecht. Meine Intention ist nicht, so etwas schlecht zu reden – auch wenn es anfangs so klingt. Ich will nur aufzeigen, dass WordFence seine Grenzen hat. Ihr sollt das jetzt nicht deaktivieren und löschen. Es hat richtig gute Monitoring-Funktionen und ist allemal besser als nichts. Aber es schützt euch eben nicht so, wie es gerne die eine oder andere Marketing-Abteilung behauptet.

Es gibt viel bessere und effizientere Wege euch zu schützen.

WordFence Scanner findet ja alles gefährliche…

Sicher? Wer Spaß an der Sache hat, findet HIER eine .mo-Datei. Diese Datei ist eine deutsche Binärsprachdatei für WordPress. Dort ist ein Backdoor drin, der reinen WP Core-Code ausnutzt, um Code auszuführen. Ihr müsst es nur herunterladen. Anschließend reicht es die Datei in den wp-content/languages-Ordner hochzuladen und dann die neue Sprache als Standardsprache auszuwählen. Die Datei erzeigt im System mit Absicht Fehler und man sieht sofort, dass etwas nicht stimmt. Das habe ich mit Absicht so gemacht! Wenn die neue Sprache aktiviert ist, könnt ihr über eureseite.de/index.php?d=[EUER CODE] beliebigen PHP Code ausführen.
Ich habe den Backdoor in der Form gebaut, dass er die Eingabe via $_GET entgegen nimmt. Damit würde es WordFence (hoffentlich) einfacher den Angriff entdecken. Wer will, kann mit dem Hexeditor allerdings auch statt $_GET einfach $_COOKIE verwenden und hat damit:

  1. einen Backdoor, den WordFence mit dem normalen Scan nicht findet (versucht es mal!)
  2. eine Möglichkeit an WordFence vorbei (sofern aktiviert) Code auszuführen

Das ganze ist dem WordPress Security Team bereits gemeldet worden und wird in einem der kommenden Updates behoben werden. Ich veröffentliche das hier nur, weil man zum Ausnutzen ohnehin Zugriffsrechte auf dem Server braucht. Wenn das der Fall ist, hat man meist noch ganz andere Probleme.

Außerdem: Schon in freier Wildbahn gesehen. Allgemein gibt es noch die ein oder andere nicht triviale Methode Backdoors so zu verstecken, dass sie meist unentdeckt bleiben – selbst nach dem ein „System komplett neu“ aufgesetzt wurde „mit Datenübernahme“. System komplett neu, ist eben kein Garant für „auf jeden Fall jetzt sichert“!

Der Klassiker – Dateirechte, Nutzerrechte, gute Passwörter

Auch wenn es nicht so komfortabel ist. Trennt man PHP und FTP-Nutzer und erlaubt dem PHP-Nutzer nur zu lesen (bis vielleicht bestimmte Ordner) und dem FTP Nutzer zu schreiben, muss man zwar bei der Systemaktualisierung immer das FTP-Passwort eingeben, aber stellt so sicher, dass kein erfolgreicher Angriff z.B. über eine RCE auf das Dateisystem schreiben kann. Wer ein gutes Passwort hat, braucht sich keine Sorgen vor Brute Force-Angriffen zu machen. Wer will, der packt ins WP-Admin noch eine htaccess und freut sich über zusätzliche Performance, weil keine Bots mehr versuchen sich einzuloggen.
Die Spezialisten unter uns können auch innerhalb der beschreibbaren Ordner (wp-content/uploads z.B.) PHP deaktivieren. Dann wird man dort vielleicht schreiben können, aber nie wirklich etwas ausführen können. Hierzu habe ich in meinem Artikel „WordPress gehackt“ schon einiges geschrieben.

Wer außerdem seine Seiten nicht aktualisiert, der wird früher oder später gehackt – mit oder ohne WordFence.

Natürlich schützen Datei-/Nutzerrechte nicht vor Zugriffen auf die Datenbank, daher ist es durchaus nicht verkehrt, wenn man WordFence verwendet. Man muss aber beachten, dass WordFence hier eben seine kleinen Schwächen hat. Ist die Sicherheitslücke „ungünstig“ wird es ein Angreifer trotz WordFence schaffen an eure Daten in der Datenbank zu kommen.

Gute Webhoster auswählen!

Daher umso wichtiger: Die Wahl eines guten Hosters. Meine Empfehlung an Kunden ist aktuell All Inkl*. für normale Webspaces. Dort sind Unteraccounts samt Datei/Nutzerrechte problemlos möglich. Ein weiterer Pluspunkt ist, dass SSH möglich ist. Das bedeutet, das Leute, wie ich, die die Wartung einer Seite übernehmen über SSH deutlich effizienter arbeiten können. Dateiänderungen, Updates, Logverarbeitung/analyse machen da mehr Spaß. Wer einen Managed Server braucht, der sollte sich die Angebote von DomainFactory* und Webgo anschauen. Beide bieten Quotas an – das ist im Grunde eine Möglichkeit einzelne Websites voneinander zu trennen. Der häufigste Fehler, den viele machen (Beispiel Felix Beilharz), ist dass sie solche Server mieten, aber nicht von den Möglichkeiten Gebrauch machen. In Folgen wird dann eine Seite gehackt und die Malware breitet sich im gesamten System aus. Unnötig und fahrlässig.

Fazit

Ich hab in wenigen Stunden simple Angriffsmethoden auf eine produktive WordPress Seite mit WordFence getestet. Primitive Angriffe werden gut abgewehrt. Sobald die Lücke etwas komplexer ist, scheitert WordFence. Sich nur auf WordFence zu verlassen – vor allem als Unternehmen – ist schon durchaus riskant. In meiner täglichen Arbeit begegnen mir eben diese Fälle, in denen man den Verantwortlichen eingeredet hat, dass WordFence das Gelbe vom Ei ist und die dann bitter merken, dass dem eben nicht so ist.
Zusätzlich hab ich hier eine (!) Methode gezeigt, wie man den Scanner von WordFence austricksen kann. Das habe ich gemacht, weil viele denken, dass WordFence mit einem Scan alle Backdoors und Malware findet und man dann sicher ist. Es gibt interessanterweise immer mehr Leute, die diese Dienstleistungen anbietet ohne wirklich zu wissen, was alles möglich ist. Das Ergebnis sind dann Kunden, die sich wundern, dass sie nonstop wieder gehackt werden, obwohl die Seite doch jetzt sicher ist.

Ich habe mir die kleineren Konkurrenten von WordFence nicht angeschaut. Dort wird aber das gleiche stellvertretend gelten. WordFence wurde gewählt, weil es eben das bekannteste Plugin in dem Bereich ist.

Du machst doch nur Eigenwerbung

Ja! Wenn man gehackt wurde, kann man mich buchen. Ich helfe in Form von Beseitigung des Angriffs sowie in Form von präventiven Maßnahmen. Bisher wurde keiner meiner Kunden wieder gehackt. Wichtig ist, dass man aus Fehlern lernt und sie in Zukunft vermeidet. Das ist mitunter unbequem, aber nötig. Sicherheit gibt es nicht auf Knopfdruck und schon gar nicht mit einem PHP-Plugin.
Besonderen Spaß habe ich Sicherheitslücken zu finden, hierfür kann man mich ebenfalls buchen.

An die Techies

Der Artikel richtet sich an den Laien, daher wurde auf ausführliches Beschreiben allzu technischer Details verzichtet. Wer Interesse am Demo-Plugin hat, kann sich gerne melden. Damit kann man selbst testen, was „Firewalls“ erlauben und was nicht.

Testsytem:

  • Nginx 1.10 mit PHP 7 und MySQL 5.7
  • WordPress 4.7.3
  • WordFence 6.3.4
  • Produktive Seite auf einem NetCups-Server

Ninja Firewall

Ich hab – nachdem ich gefragt wurde – die gleichen Angriffe auf Ninja Firewall durchgeführt und konnte feststellen, dass über alle genannten Wege die Angriffe erfolgreich blockiert wurden. Einzige Ausnahme auch hier die PHP Object Injections. Man kann allerdings in den Einstellungen auch das Blockieren serialisierter Strings aktivieren. Neben dieser Einstellung gibt es noch viele andere, die eher für die Profis geeignet sind. Anders gesagt – man muss wissen, was man macht und wenn man dort alles aktiviert, sollte man das System gründlich prüfen. WordPress arbeitet recht viel mit serialisierten Strings – es kann also sein, dass man zwar „sicher“ ist, aber die Website eben nicht funktioniert.
Wenn ich etwas empfehlen soll, dann würde ich jetzt ganz klar „Ninja Firewall“ empfehle. Da hat man auf jeden Fall mehr von. Im Grunde gilt aber das gleiche, wie bei WordFence. Für (in dem Fall) sehr viele Szenarien bietet das Plugin sehr guten Schutz. In einigen speziellen Angriffen wird man enttäuscht sein. Beispielsweise prüft das Plugin $_SERVER, hier allerdings nicht jede Variable (nur die bekanntesten). Das wäre so ein Punkt, wo man „ansetzen“ könnte. Je nach Art der SQL-Injection wird man auch hier nicht wirklich geschützt – im Grunde sind die XSS und SQL Injection Filter eben nur Wordfilter. Wenn man kreativ ist und es schafft Wörter, wie „script“ oder „FROM“ zu vermeiden, dann kommt man durch. Hört sich einfach an, wird es aber in der großen Zahl von Angriffsszenarien bzw. Sicherheitslücken nicht sein. Auch hier gilt allerdings, dass das Plugin vor allem das schützt, was im WordPress-System ist.

Der kleinste Fehler kann diese Art von Schutz schnell zunichte machen. Beispiel. Ihr habt mehrere Seiten, mal ein Drupal, mal WordPress, mal Piwik. Keine Rechteverwaltung. WordPress und Drupal sind durch irgendeine Art von Plugin/Firewall geschützt, aber Piwik nicht. Piwik wird gehackt und eine Shell deaktiviert auf allen Seiten alle Sicherheitsplugins und versteckt sich sau gut. Ihr habt verloren. Daher predige ich so oft, dass man einen guten Hoster samt Nutzer- und Dateirechten braucht!

Was ich sehr gut fand, ist, dass Ninja Firewall die Änderungen in der Binärdatei einordnen konnte. Der Malwarescanner hat angeschlagen (funktioniert aber eher unzuverlässig, man muss ihn mehrmals starten). Die allgemeine Änderung wurde ebenfalls erkannt.

Zusammenfassend: Nehmt Ninja Firewall und stellt es gut ein, da habt ihr mehr von!

Mit „*“ markierte Links in diesem Beitrag: Dabei handelt es sich um Partnerlinks für die ich „Provision“ bekomme, falls ich einen Kunden werbe. Sowohl AI als auf DF verwende ich selbst und bin damit aktuell sehr zufrieden. Wer den Artikel gut fand, kann mich gerne unterstützen, in dem er – falls er es ohnehin vorhatte – bei einem der beiden Anbieter ein Paket bestellt.

Lass uns mal zusammen was machen!

Dafür musst du mich allerdings schon noch kontaktieren!