Wordpress vor Angriffen schützen

Jahrelang habe ich selber Wordpress eingesetzt, um meinen Blog zu betreiben und auch als Vorlage verwendet andere Blogs einzurichten. Wordpress ist ein solides Stück Software und meiner Meinung nach echt Klasse!

Ich meine es lassen sich Blogs, Foren und sogar Shops in wenigen Stunden aufsetzen. Funktionserweiterungen sind schnell gefunden und installiert. Designs gibt es wie Sand am Meer und im Falle eines Fehlers findet man an jeder Ecke Unterstützung!

Sicherheitsproblem Wordpress

Meiner Meinung nach hat Wordpress jedoch, ungeachtet der Möglichkeiten und des Komforts, als eins der beliebtesten CMS-Systeme, ein riesen großes Problem. Also wirklich ein großes Problem!

Das Root-Verzeichnis des CMS ist gleichzeitig auch das Home-Verzeichnis der Apache Konfiguration. Dadurch lassen sich alle Dateien und Skripte des CMS direkt aufrufen und ausführen.
Beispielweise können einzelne Konfigurationsbackups, wie die "wp-config.php"-Datei, ein Einfallstor für Hacker sein. Diese beinhaltet beispielsweise die Datenbankkonfiguration. Sollte ein Backup in der Form "wp-config.php.[suffix]" vorliegen, so wird Apache die Datei nicht mehr als PHP-Datei interpretieren und stattdessen den Inhalt der Datei, mit samt allen Passwörtern als Klartext ausgeben. Das ist vielen Betreibern nicht bewusst.

Schlecht programmierte Plugins

Viel schlimmer jedoch wäre ein Uploadskript eines schlecht geschriebenes WordPress Plugins oder Themes. Dieses könnte dementsprechend direkt per Adresszeile aufgerufen und ausgeführt werden. Wo wir wieder bei dem vorherigen Problem mit dem Root-Verzeichnis sind. Authentifizierungsroutinen von Wordpress werden dabei übersprungen oder von dem Plugin gar nicht erst verwendet.
Die Folge wäre, dass ein Angreifer hierüber beliebigen Code auf den Server laden und ausführen kann. - Der Supergau

In meinen Zugriffslogs des Servers finde ich beispielsweise Einträge, wie:

• /wp-content/plugins/complete-gallery-manager/frames/upload-images.php
• /wp-content/plugins/dzs-videogallery/admin/dzsuploader/upload.css
• /wp-content/plugins/jquery-html5-file-upload/readme.txt
• /wp-content/plugins/page-flip-image-gallery/upload.php
• /wp-content/plugins/Premium_Gallery_Manager/uploadify/uploadify.css
• ... und 69 weitere Einträge, die auf "/wp-content/plugins/[...]upload[...]" abzielen
  

Das Interessante daran: StaticFloat läuft seit mehr als einem Jahr ohne Wordpress und wurde komplett neu aufgesetzt!
Ich möchte den Entwicklern keines Falles Boswilligkeit oder Ähnliches vorwerfen, aber es wird schon einen Grund geben, warum Bots zufällig nach diesen Adressen suchen.

Ich möchte betonen keinen Entwickler/kein Entwicklerteam schlecht machen zu wollen, aber ein Hinweis MUSS sein und es mag Bugfixes oder Gründe zu diesen Sicherheitslücken geben, aber vereinzelt erhascht man Einträge in Datenbanken, wie diesen hier (übrigens ein Plugin, welches in meinen Logs auftaucht): https://www.exploit-db.com/exploits/28377 und das ist nun einmal sehr gefährlich. Ein jeder/jedes Entwickler(-team) sollte sich bewusst sein ein gewisses Maß an Verantwortung zu tragen.

Die Bots versuchen bei ihrer wahlosen Suche im Internet herauszufinden, ob ein entsprechendes Plugin installiert ist (bspw. über eine auffindbare und unscheinbare ".css"-Datei des Plugins) und im Anschluss könnten die eigentlichen Upload-Skripte ausgeführt werden.

Doch warum kann dies passieren? - In der Regel werden sinnhaft zusammengehörige Programmescodes aller Wahrscheinlichkeit nach eher in eine eigene Datei zusammengefasst. Beispielsweise wird der Code für die Bearbeitung eines Uploads in die Datei /wp-content/plugins/sample-plugin/upload.php verpackt. Diese upload.php-Datei behandelt dabei also den Upload und die Ablage einer hochgeladenen Datei. Sicherheitschecks wiederum werden möglicherweise ebenfalls im gesamten Prozess des Uploads ausgeführt, allerdings in der Datei, welche ihrerseits upload.php aufruft! Rufen wir also über den "normalen" Weg einen Dateiupload auf, so wird beispielsweise folgender Prozess durchlaufen:

1. Normale Wordpresslogik
2. Sicherheitschecks
3. Bei erfolgreichem Check: upload.php

Sollte ein Hacker also NUR die upload.php-Datei per Browser oder Bot aufrufen, so existiert diese Sicherheitsprüfung nicht in der upload.php-Datei selber, da diese Prüfung im normalen Prozess von einer anderen Datei ausgeführt werden würde. Upload.php führt diese Checks nicht selber durch. Diese Checks wurden immerhin in der Theorie bereits vorher durchgeführt. Selbstverständlich kann man nun die Plugin-Entwickler dafür verantwortlich machen und das stimmt auch so halb. Andererseits ist das Konzept von Ordnerstrukturen in Wordpress so gebaut, dass es überhaupt erst möglich ist solche Lücken auszunutzen. Wem man nun den schwarzen Peter zuschieben will sei Jedem selber überlassen. Fakt ist, dass Entwickler nun entsprechend handeln MÜSSEN!

Wordpress schützen

Kommen wir zum eigentlichen Teil dieses Artikels. Einer kurzen Anleitung, wie wir die Sicherheit unserer eigenen Wordpress Instanz zumindest verbessern können. Eine 100%ige Sicherheit gegenüber Angriffen kann und will ich mit dieser Anleitung nicht versprechen, aber wir können die gröbsten Sicherheitslücken stopfen und die Sicherheit zumindest verbessern!

Mir persönlich ist das Thema sehr wichtig, da ich bereits selber Fehler in diesem Bereich gemacht habe. Bitte seht mir deshalb meinen zu Wort gebrachten Nachdruck nach.

1. Dateileichen und Backups löschen:

Folgende Dateien und Verzeichnisse sollte man nach Möglichkeit löschen:

• /installer.php (Auch solche, wie Beispielsweise "/installer-backup.php")
• Ungenutzte und unsichere Unter-/Testinstanzen, welche in leicht zu erratenden Unterverzeichnissen liegen (bspw. "/site", "/blog", "/test", ...)
• Alte Konfigurationsdateien, wie wp-config.php_bak, wp-config.php.save, wp-config.php.old oder aber wp-config.php~
• readme.html
• license.txt
• wp-config-sample.php

Folgende Dateien können in den Zugriffslogs häufiger mal vorkommen, sind aber unbedenklich:

• wlwmanifest.xml

2. Ungenutzte Plugins und Themes deinstallieren:

Wie gesagt: Ich möchte den Entwicklern von Themes und Plugins keines Falles Boswilligkeit oder Ähnliches vorwerfen, vielleicht ist es schlichtweg schlampige Arbeit, Zeitdruck oder gar Unwissenheit.

Wie dem auch sei.
Wir wissen nun, dass Plugins und Themes beispielweise ungeschützte Upload-Skripte aufweisen können.
Wenn wir nun also Plugins installiert haben, die wir nicht nutzen/nutzen müssen, dann gehören diese DEINSTALLIERT. Es ist in der Regel unerheblich ob man die Themes und Plugins nun (de-)aktiviert hat oder nicht. Die Skripte sind auf dem Server und gehören da nicht hin!
Ich wiederhole es nochmal: Ein Skript auf dem Server, sei es nun auch "nur" ein deaktiviertes Theme, dass ungenutzt ist gehört da dort nicht hin und stellt per se ein Sicherheitsrisiko dar!

Ganz nebenbei kann man so etwas Speicherplatz auf dem Server sparen und unter Umständen Ladezeiten der Seite verbessern.

3. "Komplizierte" Plugins ohne Wartung ersetzen

Plugins welche eingestellt oder aber schlichtweg seit Jahren nicht geupdated wurden sind meist kein gutes Zeichen. Neue Funktionen von Wordpress werden nicht genutzt und "abschnittene Zöpfe" von neueren Wordpress-Versionen wurden nicht gepatched. Der Ärger mit Inkompatibilitäten und Sicherheitslücken ist vorprogrammiert.

Ich betone dabei die Einschränkung "kompliziert".
Bspw. könnte ein Plugin, welches einen Knopf lediglich rot färbt theoretisch auch 10 Jahre lang kein Update benötigen. Natürlich ohne auch nur ansatzweise ein Sicherheitsrisiko darstellen zu müssen.
Alles was jedoch Uploads ermöglicht oder tiefgreifende Einschnitte in den Workflow von Wordpress vornimmt sollte meiner Meinung nach ab und an mal "überprüft" und angepasst werden. Zumal -ich spreche hier aus Erfahrung- komplizierte Prozesse viele unendeckte Probleme bergen können.

4. Ausführungsrechte:

Um zu verhindern, dass unerlaubte Änderungen an bestimmten Ordnern oder in bestimmten Datei vorgenommen werden sollten folgende Rechte gesetzt zu werden:

• Für Ordner: 755
• Für Dateien: 644
  
• wp-config.php: 444

Das Ganze kann über euren präferierten FTP Client geschehen. Einfach mal im Client über Rechtsklick die Rechte ändern. Bitte achtet darauf auch die Unterordner zu setzen.

5. Updates immer mitnehmen:

Wie bereits eindrücklich erklärt können Plugins und Themes Sicherheitslücken aufweisen oder aber veraltete Funktionen (damit veraltete Konzepte) verwenden. Auch Wordpress selber ist nicht immer frei von Sicherheitslücken.
Updates mögen nicht immer angenehm sein (bspw. durch geänderte Bedienung) und möglicherweise sogar nerven, aber bitte bitte installiert sie nach Möglichkeit so schnell wie möglich.
Denkt dabei bitte an ein vorheriges Backup!

6. Backups richtig gemacht:

Das bringt uns auch schon zum nächsten Punkt. Den Backups!

Noch nerviger als das tägliche, wöchentliche oder monatliche Updaten aller Plugins, Themes und Wordpress selber kann das Erstellen von Backups sein. Diese muss man nämlich noch einmal zusätzlich erstellen.
Jedoch ist das Erstellen von regelmäßigen Backups essentiell. Sie schützen euch, falls doch einmal etwas passieren sollte. Sie ermöglichen einen Rücksprung bei Fehlern und sie Schützen vor fehlerhaften Updates.

Bitte nehmt also folgende Tipps mit:

• Macht regelmäßig Backups (mindestens einmal im Monat).
• Erstellt die Backups über euren Hoster und nicht über Plugins.
• Inkludiert in die Backups: Website-Daten, Datenbanken und E-Mails.
• Backups immer herunterladen!
  
• Verschlüsselt die Backups VOR dem Download, wenn möglich.
• Löscht die Backups vom Server. Ein erfolgreicher Angreifer kann auch diese "infizieren".
• Sichert die Backups mindestens auf zwei Festplatten.
• Haltet mehrere (min. 2) Backups vor (auch die können mal unbemerkt schieflaufen).
  

Und noch einmal mit Nachdruck:

Anleitungen im Netz, welche euch vorschlagen vor einer Änderung der wp-config.php-Datei eine Kopie á la wp-config.php.old zu erstellen solltet ihr unbedingt MEIDEN!!!
Eine gute Anleitung von einem Autoren, welcher sich sicherheitsrelevanten Themen gewahr ist, wird etwas vorschlagen, wie "old-wp-config.php" oder "wp-config-backup.php". Wichtig ist, dass die Endung der Datei immer bei .php verbleibt!

7. Sichere Passwörter wählen:

Es ist eigentlich trivial, jedoch erlebe ich es leider häufiger -vor allem bei Testseiten-, dass zu unsichere Passwörter verwendet werden.
Ein Administrationsaccount oder Datenbankaccount mit dem Passwort "12341234" ist einfach nicht sicher, selbst wenn es keine Plugins/Themes mit Sicherheitslücken innerhalb deiner Wordpress-Instanz gibt und auch alle weiteren Regeln befolgt wurden.

Übrigens: Das Verwenden von sicheren Passwörtern beginnt nicht mit Wordpress, sondern schon bei der genutzten E-Mail Adresse des Webhoster-Accounts (z.b. web.de, freenet.de, ....) und den unzähligen über die Domain erstellten E-Mail Adressen, dem Account bei eurem Webhoster (besonders relevant), erstreckt sich über FTP-Zugänge, den Datenbanken und endet erst bei Wordpress! Die sichersten Passwörter BEI eurem Anbieter und eurer Instanz bringen nichts, wenn das Passwort bei z.b. web.de, mit welchem ihr euch bei z.b. Strato registriert habt, unsicher ist.

8. Zwei-Faktor-Authentifizierung nutzen:

Und natürlich dürfen wir die Zwei-Faktor-Authentifizierung nicht vergessen!

Selbst das sicherste Passwort kann irgendwann geknackt werden und dann ist der Schaden unter Umständen sehr groß. Für eine zusätzliche Hürde bieten sich Zwei-Faktor-Authentifizierung an. Bei diesen Zwei-Faktor-Authentifizierungsmethoden (E-Mail, SMS, TOTP) wird direkt nach dem Eingeben eines korrekten Nutzernamens und Passworts zusätzlich nach einem bspw. sechsstelligen Code gefragt. Dieser Code kann dann von Wordpress beispielsweise per SMS oder E-Mail raus geschickt werden oder aber in einer beliebigen Apps auf dem Handy nach einer bestimmten Verfahrensweise generiert werden (TOTP) und sollte dann mit dem Code in unserer WordPress Instanz übereinstimmen. Erst wenn dies der Fall ist werden wir auch eingeloggt. Es handelt sich also um zufallsgenerierte Einmalpasswörter (SMS/E-Mail) oder zeitbasierte Passwörter nach Berechnungen aus einem Hashwert. 

Ja, auch diese können zufällig erraten werden, erhöhen die Sicherheit jedoch enorm.

Beispiele für entsprechenden Plugins:

• https://wordpress.org/plugins/miniorange-2-factor-authentication/
• https://wordpress.org/plugins/two-factor-authentication/

9. Name des Administratorenaccounts ändern:

Man mag es eigentlich gar nicht glauben, aber auch der Nutzername für den Login in Wordpress, die DB oder oder oder gehört eindeutig mit zu den sicherheitsrelevanten Identifikationsmerkmalen des Passworts. Was bedeutet das? In der Regel kann es theoretisch egal sein, ob das Passwort nun "12341234" oder "hdf?!#dfKGHK78Gfgou" lautet, wenn der Nutzername für den Login kryptisch ist. Ein Nutzername gehört somit zu dem Passwort dazu!

Wer den Nutzernamen für den Login nicht erraten kann, der kann sich auch nicht einloggen. Egal ob er/sie das Passwort kennt.
Nutzernamen wie admin, administrator, editor oder manager sind schlichtweg unsicher, da man diese nicht mal erraten muss.
Verlasst euch aber bitte NICHT darauf und wählt immer ein sicheres Passwort.

Wordpress trennt bereits zwischen einem Loginnamen und einem Anzeigenamen. Nutzt dieses Feature und vergebt beispielsweise als Anzeigenamen "Maria Mustermann" und als Loginnamen "user723admin" für den Administratoraccount.
Ich habe hier bei mir eine ganze Liste an fehlgeschlagenen Loginversuchen unter offensichtlichen Nutzernamen.

10. Honeypots, Firewall und Bruteforce-Protection einrichten:

Es ist ratsam den Login per Honeypots, Web Firewalls oder Bruteforce Protections zu sichern.

Bei Honeypots handelt es sich um zusätzliche Haken, Felder oder andere Fallstricke, die von Bots automatisch ausgefüllt werden und den Login dazu anweisen diese Anfrage automatisch abzulehnen. Beispielhaft dafür ist eine versteckte Checkbox, welche ein Bot automatisch ausfüllt, aber ein normaler Nutzer nicht sieht.

Bei Web Firewalls handelt es sich um Skripte, die den Zugriff auf bestimmte Funktionen oder Verzeichnisse nur dann erlauben, wenn bestimmte Regeln greifen. Dies könnte der Fall sein, wenn:

• Man eingeloggt ist
• Eine bestimmte IP Adresse hat
• Aus einem bestimmten Land kommt (Sprache des Browsers oder IP Adresse)
• Der Browser einen bestimmten Client (bspw. nur MacOS oder nicht Linux) aufweist

Unter Bruteforce Protections versteht man Plugins, die den Zugriff auf den Login verweigern, wenn man sich zu oft nicht einloggen konnte.

Es gibt hier namenhafte Plugins, die diese Funktionen mitbringen, viele Tipps aus diesem Artikel aufgreifen und sogar noch weitere Hinweise und Tipps zur Verfügung stellen:

• https://wordpress.org/plugins/better-wp-security/
• https://wordpress.org/plugins/all-in-one-wp-security-and-firewall/
  

11. Ändere die Login-URL:

Das Ändern der Url für einen Login ist keine Sicherheitsstrategie im eigentlichen Sinne, hilft jedoch es den Angreifern in erster Instanz schwieriger zu machen und schließt zumindest automatische Bots aus.

Sollte ein automatischer Bot versuchen eine Brutforce-Attacke auf unsere Wordpress Instanz zu starten, so wird dieser selbstverständlich die altbekannten Adressen /wp-login.php und /wp-admin aufrufen wollen. Sind diese nicht zu finden zieht er weiter. Erst ein manuelles ändern des Bots und damit eine spezielle Attacke auf DEINE Wordpress Instanz würde diese Hürde zunichte machen.

Dieser Tipp greift tatsächlich nur, wenn man -mit Ausnahme von ein paar eingeweihten Redakteuren- als einziger Account auf das Backend zugreift.

Genutzt werden kann bspw. dieses Plugin: https://de.wordpress.org/plugins/change-wp-admin-login/

12. SSL aktivieren:

Das aktivieren von SSL und das Installieren eines entsprechenden Zertifikats schließt im eigentlichen Sinne keine Sicherheitslücken, welche in Wordpress entstanden sind. Vielmehr dient ein Zertifikat dazu die übertragenen Daten zu verschlüsseln und damit das Risiko minimieren zu können, dass beispielsweise innerhalb von öffentlichen WLAN Access Point Daten abgegriffen werden können. Unter diesen Daten könnten beispielsweise Passwörter und Nutzernamen fallen. Als kleine Nebeneffekt wird Google eine Webseite mit SSL Verschlüsselung unter Umständen sogar noch mit einem besseren Ranking honorieren. 

Es muss sich dabei nicht immer unbedingt um das kostenpflichtige 50€/Monat Wildcardzertifikat eures Dienstleisters handeln, sondern kann auch ein einfaches und kostenloses Let's Encrypt Zertifikat sein. Wie dieses erstellt wird solltet ihr am besten bei eurem Anbieter nachfragen, da dies sehr unterschiedlich ausfallen kann. Wer Zugriff auf Plesk hat, der kann hier ein einfaches Plugin installieren, welches die gesamte Arbeit eigenständig erledigt.

13. Dateieditierung abschalten:

WordPress bietet euch von Haus aus die Möglichkeit über die Administrationsoberfläche Dateiinhalte zu bearbeiten. Unter diese Dateiinhalte fällt beispielsweise auch Programmcode. In der Regel ist dieses Feature super charmant und kann einem für schnellere Bearbeitungen mal eben den Allerwertesten retten.

Das Problem ist jedoch, dass wenn ein Nutzeraccount gehackt wurde, so ist es dem Hacker ebenfalls mögliche Änderungen am Programmcode vorzunehmen, welche wir ja eigentlich nicht haben wollen. Diese Bearbeitung von Dateien können wir und sollten wir deaktivieren. Ich möchte ganz kurz klarstellen dass das Deaktivieren dieser Funktion nicht davor schützt, dass ein Hacker über den Zugriff auf einen Administratorenaccount oder legitimierten Nutzeraccount Dateien auf dem Server bearbeiten kann, allerdings bietet man dem Hacker so weniger Angriffsfläche und das wollen wir erreichen.

Nehmen wir jetzt beispielsweise einmal an, dass wir diese Funktion deaktiviert haben und unser Administratorenaccount nichtsdestotrotz kompromittiert wurde. Der Hacker könnte nun nicht mehr mir nichts dir nichts Dateien auf dem Server bearbeiten, er müsste vorher ein Plugin installieren, welches ihm den Upload von weiterem Schadcode vielleicht auch aus der Ferne heraus ermöglicht. Dies würde dem Angreifer zwar ein weiteres Komfortfeature bieten, allerdings könnte er dadurch auch schneller und leichter von uns entdeckt werden, außerdem sind so für den Hacker weitere Schritte nötig. Durch das Deaktivieren dieser Funktion verhindern wir also nicht, dass ein Angreifer jedweden Code auf unserer Seite ausführen kann, wir machen es dem Hacker einfach nur ein bisschen schwieriger.

Für das Deaktivieren müssen wir in die Datei wp-config.php folgenden Code einfügen/folgende Zeile ändern:

define('DISALLOW_FILE_EDIT', true);

14. Deaktiviere Ordnerauflistung:

Ebenfalls hatte ich bereits im oberen Teil des Artikels erklärt, dass konzeptionell bei der Programmierung von WordPress ein meiner Meinung nach großer Fehler gemacht wurde. Das Root-Verzeichnis der Instanz liegt auch in dem Root-Ordner des Servers und dementsprechend können alle Unterordner und damit auch alle Dateien in allen Unterordnern einwandfrei und ohne zutun aufgerufen werden. Sollten wir beispielsweise eine PHP Datei aufrufen, so erhalten wir im besten Fall einfach nur eine Fehlermeldung, da für die Ausführung des Codes ein weiteres Codeschnipsel aus anderen Dateien fehlt. Sollten wir Bilder oder Javascript-Dateien aufrufen, so erhalten wir den Inhalt der Datei. Soweit ist das alles noch kein Problem. Zum Problem wird es einerseits, wenn Programmcode auch ohne zusätzliche Codeschnipsel ausgeführt werden kann. Dies hatte ich bereits in dem "Upload" Beispiel demonstriert. Als weiteres negatives Beispiel kann ein einfacher Dateiordner dienen, welcher nicht mit einer index.html oder index.php Datei ausgestattet ist. Der Server wird hier keine der entsprechenden Dateien vorfinden und kann die Inhalte dieser Dateien nicht anzeigen, stattdessen wird der Server einfach die Inhalte des Ordners auflisten. Dies kann sich als große Sicherheitslücke herausstellen, da wir so preisgeben welche Dateien in den entsprechenden Ordnern vorliegen und der Hacker kann in aller Seelenruhe alle Codeschnippsel auf Lücken überprüfen, bis er eine ausnutzbare Lücke auffindet. 

Um eine Auflistung zu verhindern reicht es die Datei ".htaccess" zu suchen und folgenden Schnippsel dort einzufügen, falls noch nicht vorhanden:

Options All -Indexes

15. XML-RPC deaktivieren:

XML-RPC ist eine Schnittstelle zur teilweisen Fernsteuerung deiner Instanz. Es gibt einige Plugins welche diese Schnittstelle nutzen (bspw. Jetpack). Unter anderem verwendet auch die offizielle App von WordPress diese Schnittstelle, damit Artikel innerhalb der App geschrieben und anschließend gepostet werden können. Nennen wir XML-RPC also ich der Einfachheit halber eine Fernbedienung für dein WordPress. 

Leider ist diese Schnittstelle auch häufiger Ziel von Bruteforce Angreifen gewesen, da diese Angriffsart einfacher zu implementieren ist. Es müssen keine Felder eingegeben und nicht auf Honeypots geachtet werden, außerdem liegt die Schnittstelle immer an der selben Stelle. Um sich vor solchen Angriffen zu schützen hilft nur eines: Die Schnittstelle deaktivieren!

Dies können wir bewerkstelligen, in dem wir eine kleine Datei auf unserem Server anpassen. Innerhalb des Rootverzeichnisses sollte ein Datei mit dem Namen ".htaccess" liegen. In diese müssen wir folgendes einfügen:

location ~* ^/xmlrpc.php$ {
    return 403;
}

Wer alternativ keine manuellen Anpassungen vornehmen möchte, dem kann ich folgendes Plugin empfehlen:

https://wordpress.org/plugins/disable-xml-rpc/

16. Verberge deine Wordpress-Version:

Jede Software die in irgendeiner Art und Weise Nutzerinteraktionen aufnimmt, Dateien einliest oder in sonstiger Art und Weise mit der ihr zur Verfügung stehenden Umgebung spielt wird früher oder später irgendwelche mehr oder minder großen Sicherheitslücken aufweisen. In dem Fall WordPress haben wir eine sehr bekannte und vor allen Ding sehr verbreitete CMS Software Lösung vor uns liegen. Aufgrund der hohen Verbreitung wird WordPress für Hacker attraktiv, da sie mit der Programmierung eines Hacks gleich mehrere (hunderte oder tausende) Instanzen von WordPress angreifen und infiltrieren können. Das bringt uns leider auch zu dem Problem, dass auch WordPress nicht frei von Fehlern ist. In einigen Versionen existieren Fehler und den anderen Versionen existieren diese nicht. Sie werden schlichtweg gestopft.

Um es möglichen Angreifer nicht allzu einfach zu machen herauszufinden ob die aktuell gefundene WordPresse Seite für eine ganz bestimmte Sicherheitslücke anfällig ist oder nicht sollten wir die Versionsnummer von WordPress verstecken. Dieser Vorgang verhindert natürlich nicht, das Hacker die Sicherheitslücken ausnutzen können, allerdings macht das Versteck der Versionsnummer den Hackern das Leben ein wenig schwieriger. 

Beispielsweise dieses Plugin kann die Versionsnummer verbergen (und im übrigen noch vieel mehr): https://wordpress.org/plugins/wp-security-hardening/ 

Wer selber Hand anlegen mag, der kann ein eigenes Plugin schreiben oder aber in eine vorhandene functions.php-Datei des aktuell aktivierten Themes folgendes einfügen:

function staticfloat_hide_version() { return ''; }
add_filter('the_generator', 'staticfloat_hide_version');

17. Datenbankverbindungen absichern

Über die Notwendigkeit ein sicheres Passwort zu nutzen haben wir ja inzwischen bereits ausgiebig gesprochen gehabt. Wir können unsere Datenbankverbindungen jedoch noch weiter sichern. Ein wichtiger Schritt auf dem Weg zur sicheren Datenbankanbindung ist es der Datenbank bei zu biegen, dass sie nur noch Verbindungen des lokalen Servers akzeptieren darf.

Was bedeutet das? - So eine Datenbank sollte auf mehrere Arten gesichert werden. Als Erstes ist es notwendig, dass sich der Root-User nicht mehr über externe Verbindungen mit der Datenbank verbinden darf. Dies ist sehr wichtig, denn wie der Name schon suggeriert hat der Root-User einen unbeschränkten Roo-Zugriff auf die Datenbank und darf dementsprechend alle Änderungen tätigen. Wenn wir nun also einen Root-User in unserer Datenbank haben und dieser hat die Möglichkeit sich von außen heraus auf die Datenbank zu schalten, so kann ein möglicher Angreifer ohne Probleme versuchen über Bruteforce das Passwort ist Users herauszufinden. Das Ganze gilt natürlich auch für alle anderen Nutzer der Datenbank. 

Was genau ich nun bezwecken will und warum sich diese Einschränkung nicht unbedingt positiv auf die Sicherheit der Datenbank auswirken muss erkläre ich in einem später folgenden Artikel.