WordPress ist mittlerweile eins der beliebtesten und meist installiertesten CMS weltweit. Dieser Umstand stellt Webseitenbetreiber vor ein Problem. Denn je beliebter eine Software ist, desto interessanter wird diese für Hacker. Um so wichtiger ist es dann, dass man sich dem Thema Sicherheit widmet.
Wie schützt man sich vor Hackern / Angreifern?
Eines muss jedoch klar sein. 100% Sicherheit gibt es nicht. Man kann es jedoch Angreifern schwer machen. Je mehr Zeit ein Angreifer investieren muss, um eine Webseite zu knacken, desto wahrscheinlicher ist es, dass der Angreifer sich ein anderes Opfer sucht.
Ziel sollte es also sein, so viel Information wie möglich vorzuenthalten, die ein potentieller Angreifer sich erst hart erarbeiten muss. Aber auch potentielle Hintertüren müssen entdeckt und beseitigt werden.
Dazu gelten folgende Faustregeln:
- Nicht benötigte Plugins und Themes gehören deinstalliert! Durch fehlerhafte Programmierung in Plugins und Themes können Angreifer sich Zugang zur Webseite verschaffen.
- Wenige bis keine Plugins verwenden! So bequem Plugins auch sind und das Leben eines Webmasters erleichtern, sollte man jedoch immer versuchen, auf Plugins zu verzichten. Viele Funktionen liefert WordPress bereits von Haus aus mit. Hier empfiehlt es sich die Dokumentation, Forenbeiträge und Codebeispiele auf WordPress.org zu lesen.
- Geizig mit Rechten von Benutzern sein! Können Webseitenbesuchern sich bei einer Webseite registrieren, sollten die Rechte der Benutzer die niedrigste Stufe haben. Die Standardrolle für registrierte Benutzer sollte daher in WordPress bei den Einstellungen -> Allgemein auf Abonnent voreingestellt sein.
- Standardbenutzer „admin“ löschen! Den Benutzer Admin sollte man – nachdem man einen neuen Benutzer mit Adminrechten eingerichtet hat – deaktivieren und löschen. Vorher sich als Benutzer Admin abmelden und mit dem neuen Benutzer anmelden. Sonnst kann man den Benutzer admin nicht löschen!
- Präfix für Datenbank ändern! Standardmäßig wird von WordPress der Präfix wp_ genutzt. Da dieser Umstand bekannt ist, sollte man diesen nicht verwenden und einen anderen benutzen.
- UPDATES! UPDATES! Halten Sie ihre Software auf den aktuellen Stand und Updaten Sie regelmäßig! Updates beinhalten nicht nur neue Funktionen sondern können auch Fehler und Sicherheitslücken beheben / schließen.
- Gesonderte Mailadresse für Benutzer verwenden! Da WordPress die Anmeldung auch mittels der hinterlegten Mailadresse erlaubt, sollten Sie in Ihrem Benutzerprofil keine Mailadresse verwenden, die irgendwo auf der eigenen Webseite öffentlich zu sehen ist (z.B. im Impressum, Profil oder Kontaktseite -formular. Ansonsten liefern Sie 50% der benötigten Informationen, die ein Angreifer benötigt, frei Haus.
- Sichere Passwörter einsetzen! Wem man hier das Thema sichere Passwörter nahelegen muss, sollte es sich noch mal überlegen, eine eigene Webseite zu betreiben. :-)
- Machen Sie regelmäßig Sicherungen ihrer Webseite und der Datenbank! Das muss ich jetzt nicht wirklich weiter ausführen, welche Vorteile Backups / Sicherungen haben. Oder doch? ;-)
In den nächsten Abschnitten werden wir die funktiosn.php des genutzten Themes verändern / bearbeiten. Damit diese Änderungen bei einem Update des Themes nicht verloren gehen, sollten Sie ein sogenanntes Child-Theme des genutzten Themes erstellen.
Hierzu gibt es ausreichende Anleitungen im Netz. Hier will ich mal zwei aufzählen:
1. http://www.elmastudio.de/ein-wordpress-child-theme-anlegen-so-gehts-richtig/
2. https://die-netzialisten.de/wordpress/anleitung-childtheme-anlegen-update/
Keine Lieferung von Informationen frei Haus
Wie eingangs erwähnt, sollte man wenig Informationen liefern. Dazu zählen Informationen zur Versionsnummern der eingesetzten Software, sowie die Steuerung von Fehlermeldungen wie sie z.B. auf der Loginseite angezeigt werden.
WordPress gibt im Header der Webseite Informationen über das Verwendete CMS sowie deren Versionsnummer heraus. Diese Infos sollte man vorenthalten. Um diese Ausgabe zu unterdrücken fügen Sie folgenden Code in die functions.php ihres Themes ein:
/** Entfernen der WordPressversionsnr im Header */
remove_action('wp_head', 'wp_generator');
fertig!
Fehlermeldungen der Login-/Anmeldeseite deaktivieren
Ehrlich gesagt, habe ich nie verstanden, warum WordPress auf der Loginseite Angreifern so behilflich ist. Gibt man einen falschen Benutzernamen ein, erscheint die Fehlermeldung:
„FEHLER: Ungültiger Benutzername.“
Gibt man ein falsches Passwort ein, erscheint die Fehlermeldung:
„FEHLER: Das Passwort, das du für den Benutzernamen XYZ eingegeben hast, ist nicht korrekt.“
Wieso macht man so etwas nur? Wieso ist man Angreifern so behilflich und liefert die benötigten Informationen, die man für einen Angriff benötigt.
Auch dies lässt sich mit einem simplen Code in der functions.php abstellen. Einfach folgenden Code dort einfügen:
/** Abschalten von Fehlermeldungen auf der Loginseite */
add_filter('login_errors', create_function('$a', "return null;"));
Und noch so ein Unding hat WordPress. Die Profilseite der Autoren setzt sich aus domain.de/author/LOGINNAME zusammen. Was hat man sich dabei nur gedacht? Auch hier wird mit sensiblen Informationen leichtfertig umgegangen. Diese Funktion hätte schon vor einigen Versionen abgeändert gehört. Aber auch das lässt sich in der funktions.php abändern. Dazu sind jedoch mehrere Zeilen Code nötig.
/** Author-Slug verschleiern und UserNick für Profil nutzen */
add_filter( 'request', 'wiksec_request' );
function wiksec_request( $query_vars )
{
if ( array_key_exists( 'author_name', $query_vars ) ) {
global $wpdb;
$author_id = $wpdb->get_var( $wpdb->prepare( "SELECT user_id FROM {$wpdb->usermeta} WHERE meta_key='nickname' AND meta_value = %s", $query_vars['author_name'] ) );
if ( $author_id ) {
$query_vars['author'] = $author_id;
unset( $query_vars['author_name'] );
}
}
return $query_vars;
}
add_filter( 'author_link', 'wiksec_author_link', 10, 3 );
function wiksec_author_link( $link, $author_id, $author_nicename )
{
$author_nickname = get_user_meta( $author_id, 'nickname', true );
if ( $author_nickname ) {
$link = str_replace( $author_nicename, $author_nickname, $link );
}
return $link;
}
add_action( 'user_profile_update_errors', 'wiksec_set_user_nicename_to_nickname', 10, 3 );
function wiksec_set_user_nicename_to_nickname( &$errors, $update, &$user )
{
if ( ! empty( $user->nickname ) ) {
$user->user_nicename = sanitize_title( $user->nickname, $user->display_name );
}
}
/** Ende ** Author-Slug verschleiern und UserNick für Profil nutzen */
Mit diesem Code wird der Eintrag verwendet, der bei Spitzname eingegeben wurde. Dort können Sie einen beliebigen Namen eintragen (ausgenommen Leer- und Sonderzeichen). Zudem tauscht dieser Code die Verlinkung zu den Autorenseiten aus, bevor die Seite an den Browser der Besucher ausgeliefert wird. Diese Verlinkung finden Sie (je nach Theme) meist unter einem Beitrag beim Namen des Beitragsautors.
– Denkbeispiel bevor Sie den Code verwenden –
Gehen wir mal davon aus, Benutzer Admin ist noch vorhanden. Benutzer Admin schreibt einen Blogbeitrag. So ist der Beitragsautor admin. Der Name des Autors „Admin“ wurde bisher wie folgt mit dem Autorenprofil verlinkt:
domain.de/author/admin
Nachdem Sie nun den obigen Code eingefügt haben, gehen sie im Backend / Adminbereich zur Benutzerverwaltung und wählen dort den Benutzer „Admin“ aus. Dort tragen Sie dann bei Spitznamen z.B. „mann-fuer-alles“ ein (Leer- und Sonderzeichen sollen ja nicht benutzt werden!).
Ab sofort wird der Name des Autors „Admin“ wie folgt mit dem Autorenprofil verlinkt:
domain.de/author/mann-fuer-alles
Für die bisherige Verlinkung domain.de/author/admin wird ab sofort eine Fehlermeldung „Seite nicht gefunden“ herausgegeben. Angreifer gehen dann davon aus, dass der Benutzer „admin“ nicht mehr existiert. So können Sie nun mit allen Benutzern verfahren. Einfach dort bei Spitznamen einen Wert eintragen, der nicht auf den Benutzer-/Anmeldenamen hindeutet.
Deaktivieren des Dateieditors im Adminbereich
Ganz ehrlich? Ich habe diesen Editor noch nie verwendet. Ich habe auf meine Webseiten direkten Zugriff mit SFTP und gesicherten WebDAV. Daher habe ich diesen Editor deaktiviert.
Mit dem Dateieditor kann man im Adminbereich Dateien des Themes bearbeiten. Angreifer könnten diese Funktion nutzen, um Schadcode in einer dieser Dateien einzuschleusen.
Dazu müssen wir die wp-config.php im Hauptverzeichnis / -ordner unserer WordPressinstalltion bearbeiten. Also in der wp-config.php fügen Sie folgende Zeilen hinzu:
/** Deaktivierund des Datei-Editor im WordPress Dashboard */
define('DISALLOW_FILE_EDIT', true);
Am besten unter den anderen define(‘yx‘) -Anweisungen.
Sicherheitsrisiko xmlrpc.php
Seit der Version 3.5 ist die XMLRPC-Schnittstelle standardmäßig in WordPress aktiviert. Für sich gesehen wäre das nicht weiter schlimm, wäre WordPress nicht das meist eingessetzte Content Management System der Welt. Die XMLRPC-Sschnittstelle stellt nicht nur nützliche Funktionen bereit, sondern ist auch ein beliebtes wichtiges Angriffsziel für Hacker. Immer mehr Angreifer nutzen die xmlrpc.php für ihre Angriffe., da ein Angriff gegen diese Schnittstelle wesentlich effizienter und mit weniger Aufwand als andere Methoden verbunden ist. Die Schnittstelle ist schon ein sehr nützliches Werkzeug. Über ihr lassen dich externe Anwendungen mit WordPress verbinden. Da immer mehr Webmaster ihr WordPress gegen Angriffe absichern, ist die xmlrpc.php ein beliebtes Angriffsziel. Über diese Schnittstelle lassen sich in nur einer Abfrage bis zu 500 Passwörter abfragen. Da die xmlrpc.php auch entsprechende Rückmeldungen herausgibt, ob Benutzername oder Passwort korrekt sind, ist diese Schnittstelle eine sehr bequeme Möglichkeit, schnelle Abfragen abzufragen. Daher stellt die xmlrpc.php ein Sicherheitsrisiko dar.
Um die XMLRPC-Schnittstelle zu deaktivieren muss folgender Code in die funktions.php des Themes hinzugefügt werden:
/* XMLRPC-Schnittstelle deaktivieren */
add_filter( 'xmlrpc_enabled', '__return_false' );
Die Schnittstelle ist nun deaktiviert. Allerdings erscheinen noch Verweise zur Schnittstelle im HTTP-Header der Website. Die Verweise zur xmlrpc.php können wir mit folgenden Code in der funktions.php des Themes deaktivieren:
/* Verweise zur Schnittstelle im HTTP-Header -Eintrag bereinigen */
remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');
Sicher und am besten schützt man die xmlrc.php durch blocken per .htaccess.
Dazu einfach folgende Anweisung in die .htaccess der WordPressinstalltion hinzufügen:
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
Das ist die radikale Methode. Nutz man jedoch Apps oder Plugins von WordPress, kann die Nutzung der xmlrpc.php statt mit den vorherigen Anweisungen mit folgenden Zeilen in die .htaccess beschränkt werden (Beispiele mit den meist genutzten Anwendungen):
<IfModule mod_setenvif.c>
<Files xmlrpc.php>
BrowserMatch "Poster" allowed
BrowserMatch "WordPress" allowed
BrowserMatch "Windows Live Writer" allowed
BrowserMatch "wp-iphone" allowed
BrowserMatch "wp-android" allowed
BrowserMatch "wp-windowsphone" allowed
Order Deny,Allow
Deny from All
Allow from env=allowed
</Files>
</IfModule>
Jetzt haben Sie ihre Webseite soweit etwas sicherer und für Angreifer aufwendiger gemacht. ;-)
-
Von Heiko Philippski am
16.05.2017 | Aktualisiert am 22.06.2022
Permalink: https://www.phindie.de/?p=6588
Kategorien: Software, Topthemen
Schlagwörter: Blog, Sicherheit, Tipps, WP, Webentwicklung, Webseite, WordPress