info@netz-gaenger.de       📞 +49 151 / 28859057

WordPress konfigurieren für mehr Sicherheit

Firmen kümmern sich bei ihrer ersten Webseite um günstige Anbieter, ein gutes Konzept, Suchmaschinenoptimierung, Konversionen und viele andere wichtige Dinge. Oft geht allerdings das vermeintlich wichtigste Thema unter: Wie optimiere ich die Sicherheit meiner Webseite? Ich möchte hier die wesentlichen Maßnahmen darstellen, die eine WordPress-Installation sicherer machen können.

Wordpress Sicherheitsmaßnahmen

Hinweis: Kein System ist 100% sicher! Die aufgeführten Maßnahmen sind nötig um eine System von Grund auf zu härten und gegen die gängigsten Angriffe von Script-Kiddies zu schützen. Bots sind die häufigsten Gegner einer WordPress-Installation und agieren eher zufällig, automatisiert, Schwachstellen ausnützend. Das jemand tatsächlich vor seinem Gerät sitzt und sagt, „ja, ich möchte jetzt die Webseite von XY hacken“, passiert seltener, ist aber auch deutlich schwieriger zu verhindern. Es sei ganz klar gesagt: Wenn jemand es tatsächlich darauf anlegen möchte und die Mittel hat, sind die Chancen trotz aller Maßnahmen gegeben, dass er oder sie auch einen Angriffspunkt und somit einen Einstieg findet.

Absichern lassen von einem Profi

Auch wenn das gleich zu Beginn dieses Artikels etwas entmutigend ist: Am besten lässt man seine WordPress Webseite vom Profi absichern. Nur wer sicher ist auf dem Gebiet, weiß wo er hinlangen muss und was wirklich getan werden muss, damit eine Webseite weitestgehend abgesichert wird. Ich versuche im folgenden die Schritte zur Absicherung auch für Nicht-Profis nachvollziehbar zu halten. Aber wer hier ein wenig unsicher ist, sollte dann am Ende doch lieber jemanden fragen, der sich damit auskennt.

Warum WordPress Security-Maßnahmen?

Wordfence, Hersteller eines der bekanntesten WordPress Security Plugins, zeigt in aktuellen Statistiken, dass stündlich allein in deren abgesicherten Netzwerk 3 Mio. Angriffe auf WP Webseiten stattfinden. Das sind pro Tag ca. 80 Mio. Angriffe. Die Dunkelziffer muss um ein Vielfaches höher sein, weil ja A) nicht jede Webseite Wordfence nutzt und B) viele Webseiten gar nicht abgesichert sind. Allein die schiere Masse an Attacken zeigt, dass es sich bei den meisten Angriffen um hauptsächlich automatisierte handelt. Diese gilt es zu verhindern bzw. abzublocken.

WP, Plugins und Theme aktuell halten

Zuallererst die wichtigste Empfehlung von allen: WordPress, Plugins und installierte Themes sollten IMMER aktuell gehalten werden. D.h. ich empfehle mindestens monatlich Updates einzuspielen. Über veraltete Software entstehen über die Zeit Sicherheitslücken, die ausgenutzt werden können. Ein gepflegtes, aktuelles System ist die halbe Miete gegen Angriffe von Außen!

Sicherheits-Plugins für WordPress

Es gibt eine ganze Reihe Sicherheits-Plugins für WordPress, die die wichtigsten Sicherheitsproblematiken abfangen oder zumindest checken und darauf hinweisen. Welches verwendet wird, muss jeder für sich entscheiden. Da ich etwas paranoid beim Thema Sicherheit bin, verwende ich alle aufgelisteten Plugins, auch wenn sich manche Features überschneiden.

iThemes Security installieren

Ein tolles tool, welches Sicherheitseinstellungen checkt und Verbesserungsvorschläge macht. Neben der Absicherung des Upload Ordners lassen sich unter anderem 404 Angriffsversuche blockieren, Angriffe auf das Backend unterbinden und die Datenbank umbenennen. So werden Hackversuche wirksam gestört.
In der Pro Version erhält man noch mehr Sicherheitsebenen. Hier findest du einen detaillierteren Bericht zu iThemes.

Block Bad Queries

BBQ blockiert verdächtige Anfragen an die Webseite und die Datenbank und stellt somit eine große erste Hürde für Angreifer dar. Absolute Empfehlung.

Hide My WP installieren

Spitzenmäßiges Plugin, dass nicht nur Firewall-Funktionalität liefert, sondern vor allem vor den automatisierten Angreifern das System WordPress als solches versteckt. So gerät die Site erst gar nicht in das Visier der Angreifer. Das Plugin ist auf Themeforest Platz 1 und somit das meistverkaufte Security Plugin für WordPress.

Wordfence

Wordfence ist neben iThemes das Security Plugin meiner Wahl. Vor allem, wenn der Hack schon passiert ist, ist Wordfence super geeignet um A) die Malware aufzuspüren B) die Website zu bereinigen (zB kompromittierte Core Files) C) abzusichern mit Hilfe einer effektiven Firewall. Hier findest du Wordfence in der Review.

Login Versuche in WordPress mit Plugin verhindern

Viele Angriffe auf WordPress finden am Login statt. Mit Limit Login Attempts kann man diesen so einstellen, dass zum Beispiel maximal 5 Login-Versuche erlaubt sind, bevor der Angreifer für eine bestimmte Zeit ausgesperrt wird. Diese Funktion ist in Plugins wie iThemes Security bereits enthalten. Wer kein umfangreiches Plugin einsetzen will, kann dieses verwenden.

Sucuri nutzen

Sucuri ist der bekannteste und beste Dienst, den es für WordPress gibt um eine Webseite abzusichern. Das Prinzip ist folgendes: Der Webseite wird eine Web Application Firewall (WAF) vorgeschalten. D.h. jede Anfrage an die WordPress Webseite leitet erstmal durch den Sucuri Server und wird gefiltert und geprüft. Ist die Anfrage verdächtig (zum Beispiel ein versuchter Hack), wird sie blockiert. Securitymaßnahmen in WordPress selber sind dadurch theoretisch erstmal nicht mehr nötig, weil Sucuri schon durch die WAF alles neutralisiert, was gefährlich werden könnte.

Und wird man doch mal gehackt, entfernt Sucuri den Hack innerhalb weniger Stunden.

Ich selber nutze den Service bei einigen meiner Projekte und auch bei Kunden und war immer sehr zufrieden. Hier nochmal die Vorteile/Features von Sucuri:

  • Malware und Hack Repair
  • Ständige Hack-Überwachung
  • Schutz vor Blacklisting
  • Stop von Hackversuchen
  • Schutz vor DDoS Attacken
  • Schnellere Performance durch CDN
  • Firewall
  • 30 Tage Geld zurück Garantie

Der Dienst ist nicht kostenlos, aber sicher sein Geld wert, wenn man von seinem Webauftritt abhängig ist. Es gibt nichts geschäftsschädigenderes im Netz, als wenn man an seine Kunden Viren verteilt, weil diese auf der verseuchten Firmenwebseite gesurft sind.

Preislich beginnt Sucuri bei 199,-$ pro Jahr.

Manuelle Sicherheitsmaßnahmen in WordPress

Wer kein Plugin verwenden möchte, kann die wichtigsten WordPress Sicherheits-Maßnahmen auch manuell durchführen. Wer ebenso paranoid ist wie ich, führt diese manuell durch und verwendet parallel noch zusätzlich die WordPress Sicherheits-Plugins. So kann man auf Nummer sicher gehen.

Neuen Administrator anlegen, alten löschen

Erstellen Sie sich direkt nach der Installation einen neuen Administrator-Benutzer. Loggen Sie sich mit diesem ein und löschen sie den Standard-Benutzer „admin“. Somit schützen Sie sich schon gegen die Standard-Angriffe, bei denen versucht wird für Ihr Backend Administrator-Anmeldedaten herauszufinden. Zu finden im WordPress-Menü „Benutzer“.

Verwenden Sie sichere Passwörter

Ein Passwort sollte ausreichend lang sein, nicht zu erraten (also keine richtigen Wörter, Namen, Geburtsdaten, …) und mindestens eine Zahl und ein Sonderzeichen beinhalten (!“§$%&/()=@+*#-). Ein gutes Beispiel wäre zum Beispiel: P@ssssw0rt1! Durch Sicherheits-Plugins, wie zum Beispiel Better WP Security kann man sichere Passwörter für Benutzergruppen als Pflicht einstellen.

Umbenennen des wp-content Ordners

Diese Maßnahme sollten Sie durchführen, bevor Sie irgendetwas installiert (mit Außnahme ggf. des Plugins Better WP Security, welches bei dieser Maßnahme behilflich sein kann) oder Content erstellt haben. Sie benennen den wichtigsten Ordner einer WordPress-Installation (wp-content) um, damit Angreifer gar nicht erst wissen, wo sie die meisten Schwachstellen suchen müssen. Das können Sie entweder selber machen, indem Sie die Anleitung auf folgender Seite befolgen http://www.gutestun.org/how-to/wp-content-wordpress-umbenennen-1898/ oder aber Sie verwenden das Plugin Better WP Security und lassen von diesem den Ordner umbenennen.

Neue Sicherheitsschlüssel in der wp-config.php

Erstellen Sie auf der folgenden Seite neue Sicherheitsschlüssel, welche für die Authentifizierung zuständig sind und überschreiben die, die Sie in Ihrer wp-config.php stehen haben. https://api.wordpress.org/secret-key/1.1/salt/

Verschieben der wp-config.php eine Ebene höher

Insofern Sie die administrativen Rechte dazu haben: verschieben Sie die wp-config.php eine Ebene höher als das Root Verzeichnis Ihrer Worpress-Installation, um auch hier Standard-Angriffen vorzubeugen. Wenn Sie keine Rechte haben, fragen Sie bei Ihrem Webhoster an.


wp-admin durch .htaccess mit Passwort schützen

Das Administratoren-Login muss eigentlich nicht frei verfügbar sein. Daher empfiehlt es sich, den Ordner wp-admin mit folgendem Snippet in einer .htaccess Datei im root-Verzeichnis zu schützen. Fügen Sie folgenden Code in die .htaccess Datei. Zuvor müssen Sie allerdings eine .htpasswd Datei anlegen, in der die Zugangsdaten verschlüsselt abgelegt sind. Ein .htpasswd Passwort können Sie hier erstellen. So muss die .htpasswd Datei aussehen (einfach mit ins root legen)

benutzername: $apr1$EsEZBC8a$2mY1lsyM1WjdoctUMmWU30

So muss der Eintrag in der .htaccess Datei aussehen

# protect /wp-admin
AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile /pfadzur/.htpasswd
require valid-user

Achtung: Manche Plugins greifen auf die admin-ajax.php im wp-admin Ordner zu. Dann wird durch den folgenden Code die Darstellung ggfs. negativ beeinflusst. In diesem Fall muss man noch in der .htaccess des Ordners wp-admin den folgenden Code speichern:

<Files admin-ajax.php>
    Order allow,deny
    Allow from all
    Satisfy any 
</Files>

Fehlermeldungen bei Login weniger aussagekräftig machen

Mit dem folgenden Code kann man verhindern, dass bei Login-Versuch eine Fehlermeldung à la „Das Passwort“ ist falsch erscheint. Ansonsten weiß der Angreifer nämlich schon, dass zumindest der Benutzername gestimmt hat. In die functions.php

function explain_less_login_issues(){ return 'ERROR: Entered credentials are incorrect.';}
add_filter( 'login_errors', 'explain_less_login_issues' );

Böse Codeeinschleusung verhindern – Block Bad Queries

Mit dem folgenden Plugin schützt man WordPress vor der Einschleusung von Schadcode vor bösartigen URL Anfragen. Einfach das folgende Snippet in einer PHP Datei unter wp-content/plugins ablegen und das Plugin dann im Backend aktivieren.

/*Plugin Name: Block Bad Queries
Plugin URI: http://perishablepress.com/
Description: Protect WordPress Against Malicious URL Requests
Author URI: http://perishablepress.com/
Author: Perishable Press
Version: 1.0
*/
if (strpos($_SERVER['REQUEST_URI'], "eval(") ||
strpos($_SERVER['REQUEST_URI'], "CONCAT") ||
strpos($_SERVER['REQUEST_URI'], "UNION+SELECT") ||
strpos($_SERVER['REQUEST_URI'], "base64"))
{
@header("HTTP/1.1 400 Bad Request");
@header("Status: 400 Bad Request");
@header("Connection: Close");
@exit;
}

Backend-Editieren verbieten

Mit dem folgenden Code in der functions.php wird verhindert, dass im Backend Themes und Plugins geändert werden können. So kann das auch kein Hacker, der in das Backend eingebrochen ist.

define('DISALLOW_FILE_EDIT', true);

Die Versionsnummer von WordPress verstecken

Hackern ist es natürlich sehr lieb, wenn sie schnell checken können, welche Version die WordPress-Installation hat. Somit können sie leichter Sicherheitslücken erkennen. Mit dem folgenden Code in der functions.php wird diese Information versteckt.

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

Man sollte übrigens auch die Readme.html und Liesmich.html im Installationspfad löschen. Achtung: können bei einem Update wieder auftauchen.

wp-config.php und .htaccess Rechte einschränken

Die Rechte der wp-config.php (die hoffentlich im Ordner über der Bloginstallation liegt (siehe Punkt 4)) sollte auf 400 gesetzt werden. Die der .htaccess auf 644 (oder besser 444, wenn WordPress keine automatischen Änderungen vornehmen muss).

Generelle Verzeichnis- und Dateirechte

Auch wenn manchmal die Rede davon ist, dass zum Beispiel der Ordner wp-content mit 777 Rechten versehen sein sollte, ist das nicht nötig. Am besten die Dateirechte auf 644 und die Verzeichnisrechte auf 755 setzen.

Ein anderes Präfix für die Datenbank wählen

Um auch Angriffen auf die WordPress MySQL Datenbank zu erschweren, macht es Sinn ein anderes Präfix als wp_ für die Datenbanktabellen zu verwenden. Zum Beispiel wp32ng_TABELLENNAME.

Das Uploadsverzeichnis vor Auflistung der Files sichern

Speichern Sie eine leere index.php in das Uploads Verzeichnis. So kann niemand den Inhalt des Ordners im Browser ausgeben.

WordPress, Themes und Plugins aktuell halten

Alle Sicherheitsmaßnahmen nützen nichts, wenn man ein uraltes System mit veralteten Plugins oder Themes betreibt. Daher muss!!! man darauf achten, alles auf dem neuesten Stand zu halten. Aber WordPress macht es einem hier ja ziemlich einfach.

Einschlägige Exploit Datenbanken beobachten

In bestimmten Portalen kann man nachverfolgen, welche Sicherheitslücken für WordPress und verwendete Plugins bestehen und dann ggf. reagieren. Ich weiß nicht ob man das posten sollte, aber hier wäre eine Datenbank: http://www.exploit-db.com/.

Fazit: WordPress ist nicht weniger sicher als andere Content Management Systeme, wenn man bestimmte Sicherheitsregeln einhält. Diese Tipps liefern eine gute Grundhärtung von WordPress Blogs. Ich weiß, ich habe evtl. 1 oder 2 Plugins mehr installiert als nötig. Aber das liegt daran, dass ich bei Sicherheitsrisiken sehr sehr vorsichtig bin. 100%-ige Garantie auf Sicherheit ist natürlich nicht möglich, da dass System, auf welchem WordPress installiert wurde, ebenso abgesichert sein muss und die Vielzahl an fremd entwickelten Plugins auch immer mit einem gewissen Risiko behaftet sind. Aber wie gesagt, besteht dieses Problem bei allen Open Source Content Management Systemen gleichermaßen. Und brauchen Sie Hilfe um Ihre Webseite abzusichern oder Ihre Webseite wurde gehackt? Ich helfe gerne.


WordPress Sicherheitsmaßnahmen erweitern

Über die Zeit haben sich noch weitere Securitymaßnahmen für WordPress als wirksam bewährt. Ich hänge daher hier auch gleich meinen anderen Artikel an, den ich eine Zeit lang separat in meinem Blog stehen hatte. Ich denke es macht Sinn, beide Artikel auf einer Seite darzustellen:

 

Verzeichnisrechte massiv einschränken

Die aufwändigste und extremste Variante der Absicherung einer Seite, ist meiner Ansicht nach die Entfernung von ALLEN Schreibrechten auf Ordner und Dateien, wo es nur möglich ist. Wenn selbst der Webserver keine Schreibrechte hat, ist es für Angreifer deutlich schwerer Scripts auf den Webserver hochzuladen. Meine Empfehlung für Hardcore-User: Schreibrechte nur auf die folgenden Ordner und Dateien geben

  • upload-Ordner in wp-content
  • Bestimmte Ordner von Caching-Plugins
  • Sitemap-Files

ALLE anderen Ordner und Dateien kommen für den Betrieb einer WordPress-Seite ohne Schreibrechte aus, da sie ja nur geöffnet und gelesen werden müssen vom Webserver. Der Nachteil: Bei Änderungen am Theme oder der wp-config.php, der .htaccess oder aber auch an Plugins (Updates, Installationen, Löschungen, etc.) müssen die Rechte vorrübergehend wieder gelockert werden (Achtung: upgrade-Ordner bei Updates nicht vergessen). Das halte ich für einen vertretbaren Aufwand verglichen mit dem Plus an Sicherheit.

PHP Ausführung in Upload Ordner verhindern

Da man dem Webserver nicht die Schreibrechte im Upload-Ordner nehmen kann, ist dieser Ordner besonders gefährdet. Daher macht es Sinn, in diesem Ordner (und allen Unterordnern) die Ausführung von PHP zu verhindern. Am einfachsten geht das mit dem folgenden Befehl in einer .htaccess Datei im Upload-Ordner

<Files *.php>
Deny from All
</Files>

Das gleiche kann man übrigens auch mit Pearl-Scripts machen:

<Files *.pl>
Deny from All
</Files>

Uploads dieser Dateien sind somit wirkungslos. In folgenden Ordnern macht es ebenfalls Sinn die Ausführung von PHP und Pearl Skripten zu verhindern:

  • wp-content (Achtung: manche Plugins machen das nicht mit)
  • wp-includes

Schreibrechte von .htaccess-Dateien entfernen

Wenn man nicht generell Schreibrechte entfernen möchte, sollte man zumindest den wichtigsten Dateien die Schreibrechte nehmen. Bei der wp-config.php ist das klar. Die .htaccess vergessen viele. Dabei werden auch diese Files des öfteren kompromittiert, so dass zum Beispiel automatische Weiterleitungen der eigenen Webseite auf Virenschleudern stattfinden. Von daher sollte man von .htaccess Dateien die Schreibrechte entfernen.

install.php und upgrade.php entfernen

Die Dateien install.php und upgrade.php sollten aus dem Verzeichnis /wp-admin entfernt werden. Diese haben in einer laufenden Installation eigentlich nichts mehr verloren. Man verliert hiermit auch keine Updatefähigkeit. Jedoch muss man diese Maßnahme nach jedem Update wiederholen, da die Files ansonsten wieder neu angelegt werden.

Loginbereich in WordPress verstecken

Gerade der Login von WordPress wird häufig angegriffen um Adminzugänge zu hacken. Neben einem Plugin, welches Loginversuche blockt wenn diese zu häufig geschehen, kann man auch den Loginbereich verstecken. Ein Plugin, welches dafür gut geeignet ist, ist Stealth Login Page.

WordPress Login per SSL absichern

Nicht nur Sicherheitslücken der Webseite sind ein Problem. Was, wenn das eigene Heimnetzwerk oder WLAN ausspioniert wird und Passwörter „mitgehört“ werden? Das passiert durchaus häufiger. Eingegebene Passwörter in Login-Formulare, die nicht SSL verschlüsselt sind, sind im Klartext mit Network-Sniffern lesbar. Um das zu verhindern kann man den Login oder auch den kompletten Adminbereich in WordPress per SSL verschlüsseln. Das geht mit Hilfe eines SSL Zertifikats und folgendem Code in der wp-config.php.

//for just the login
define('FORCE_SSL_LOGIN', true);
//for the whole admin
define('FORCE_SSL_ADMIN', true);

Bestimmte Dateiformen sperren

Es gibt Dateien, die Infos über die Version von WordPress und Plugins verraten. Zum Beispiel liesmich.html oder Textdateien. Diese müssen nicht geöffnet werden können. Daher nimmt man ihnen am besten die Leseberechtigung. So vermeidet man es auch, diese Dateien löschen zu müssen. Durch Updates und Neuinstallation kann das ziemlich lästig sein.

Options All -Indexes
<files readme.html>
Order allow,deny
Deny from all
</files>
<files *.sql>
Order allow,deny
Deny from all
</files>
<files *.zip>
Order allow,deny
Deny from all
</files>
<files liesmich.html>
Order allow,deny
Deny from all
</files>
<files .htaccess>
order allow,deny
deny from all
</files>
<files *.txt>
Order allow,deny
Deny from all
</files>
<files license.txt>
Order allow,deny
Deny from all
</files>
<files error_log>
Order allow,deny
Deny from all
</files>

WordPress Version verstecken

Zudem kann man verhindern, dass die WordPress-Version im Header der Seite ausgegeben wird. Folgender Befehl gehört in die functions.php

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

Server-Signatur deaktivieren

Ganz paranoide können auch Infos über den Webserver deaktivieren. Folgender Befehl gehört in die .htaccess

ServerSignature Off

SQL Injections verhindern

Gerne werden auch Codes in die WordPress-Datenbank geschleust. Das passiert über ungesicherte Formulare oder alte und unsichere Plugins. Der folgende .htaccess Block verhindert einige SQL Injections (ggfs. können diese Anweisungen Probleme bei normaler Funktionalität verursachen):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteRule ^(.*)$ - [F,L]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} tag\= [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(&#x22;|&#x27;|&#x3C;|&#x3E;|&#x5C;|&#x7B;|&#x7C;).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|insert|union|declare|drop).* [NC]
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteRule ^(.*)$ - [F,L]
</IfModule>

Überwachen von WordPress

Es gibt Möglichkeiten Eindringlinge auf einem Webserver zu erkennen. Richtige Profis verwischen ihre Spuren. Aber die meisten legen ihre PHP Dateien ab und scheren sich nicht darum. Es gibt Shell-Befehle, mit denen man auf einem Linux Server seine Webseite nach geänderten Dateien durchsuchen kann. Die, die einem komisch vorkommen, sollte man prüfen. Diese Überwachung baut man am besten in eine .sh Datei, die per Cronjob einmal täglich ausgeführt wird und das Ergebnis an eine E-Mail-Adresse schickt. Haben Sie nämlich einen Eindringling, der auf Ihrer Webseite Malware verteilt, WOLLEN Sie das schnellstmöglich wissen. Bekommt Google nämlich Wind davon, kann es Ihnen passieren, dass Ihre Seite deindexiert wird. Unter Umständen der absolute Super-GAU.

Suchen nach geänderten Dateien

Der folgende Befehl sucht nach PHP-Dateien, die in den letzten 24 Stunden geändert wurden und schreibt das Ergebnis in eine Temp-Datei.

find /absolutepath/towebsite/public_html -mtime -1 -name "*.php" -printf '%TY-%Tm-%Td %TT\t%p\n' >> file.tmp

Das Gleiche macht man mit .js Dateien (und evtl. auch mit .pl Dateien)

Suche nach verdächtigem Code in PHP Dateien

Eindringlinge schleusen auch gerne bösartigen Code in wichtige PHP Dateien, wie die index.php. Sie können zum Beispiel alle in den letzten Tagen geänderten PHP Files auf bestimmten Code durchsuchen.

find /absolutepath/towebsite/public_html -mtime -7 -name "*.php" | xargs grep -l -i "eval\|base64_decode\|iframe\|pharma\|viagra\|file_get_contents" >> file.tmp

Den Upload Ordner von WordPress nach PHP Dateien durchsuchen

PHP Files haben im Upload-Ordner nichts zu suchen. Daher sucht man am besten täglich danach um Einbrüche zu erkennen.

find /absolutepath/towebsite/public_html/wp-content/uploads -name "*.php" -print >> file.tmp

Datei- und Verzeichnisrechte im Auge behalten

Wenn man viel an seiner Webseite ändert, sollte man die Rechte im Auge behalten. Ordner, die mit 777 offen wie ein Scheunentor sind, sollte man schleunigst schließen. Da das sehr anstrengend sein kann, macht man das am besten automatisiert. Folgende Abfragen durchsuchen alle Files und Ordner und geben die aus, die evtl. eine zu lockere Sicherheit aufweisen. Achtung: die hier angegebenen Werte müssen an die jeweilige Webserver und Benutzerrecht-Umgebung angepasst werden. Auf 777 sollte man allerdings immer prüfen.

find /home -type d -perm 0777 >> file.tmp
find /home -type f -perm 0777 >> file.tmp
find /home -type d -perm 0007 >> file.tmp
find /home -type f -perm 0007 >> file.tmp
find /home -type d -perm 0407 >> file.tmp
find /home -type f -perm 0407 >> file.tmp
find /home -type d -perm 0607 >> file.tmp
find /home -type f -perm 0607 >> file.tmp
find /home -type d -perm 0707 >> file.tmp
find /home -type f -perm 0707 >> file.tmp
find /home -type d -perm 0747 >> file.tmp
find /home -type f -perm 0747 >> file.tmp
find /home -type d -perm 0767 >> file.tmp
find /home -type f -perm 0767 >> file.tmp
find /home -type d -perm 0757 >> file.tmp
find /home -type f -perm 0757 >> file.tmp
find /home -type d -perm 0557 >> file.tmp
find /home -type f -perm 0557 >> file.tmp
find /home -type d -perm 0577 >> file.tmp
find /home -type f -perm 0577 >> file.tmp
find /home -type d -perm 0177 >> file.tmp
find /home -type f -perm 0177 >> file.tmp
find /home -type d -perm 0077 >> file.tmp
find /home -type f -perm 0077 >> file.tmp

Verschicken der Ergebnisse per E-Mail

Die Ergebnisse verschickt man dann zum Beispiel über den Befehl

mailx -s "Webserver File-Changes" email@tome.de <file.tmp

Prüfen, ob eine WordPress Seite bereits gehackt wurde

Es gibt Anbieter wie Sucuri, die die eigene Webseite auf Malware, bösartigen Code, SPAM, Blacklisteinträge, etc. testen können. Eine Seite, die bereits verseucht ist, kann man absichern wie man will. Bevor man also die hier gelisteten Maßnahmen betreibt, sollte man erstmal checken, ob die WordPress Webseite zum aktuellen Zeitpunkt noch sauber ist. Sonst ist eine Neuinstallation ggfs. vorab nötig. Noch besser als der Online Scanner von Sucuri, ist das Plugin für WordPress. Es testet nicht nur das Theme und die WordPress Core Files auf Schadcode und Veränderungen? Es gibt dem Seitenbetreiber auch die Chance eine Web Application Firewall einzurichten, die letzten veränderten Dateien anzuzeigen, sowie die uploads-, wp-content- und wp-includes-Ordner vor direktem PHP Zugriff zu schützen. Ein extrem guter Helfer vor und nach dem Hack.

Absoluten Pfad verstecken

Achtung: Kommt bei Sucuri eine Warnung bezüglich eines offenen absoluten Pfades, ist dieser scheinbar relativ einfach auslesbar. Von daher sollte man in der .htaccess mit folgendem Befehl die Ausgabe von Fehlern unterbinden, die den absoluten Server-Pfad Ihrer WordPress-Installation mitgeben:

php_flag display_errors off

Zugriffe auf XML-RPC abstellen

Die XML-RPC-Schnittstelle ist dafür da, 3rd Party Programme oder Geräte mit WordPress zusammenarbeiten zu lassen. Meistens benötigt man das nicht, außer man möchte von Unterwegs per iPad etc. mit WordPress arbeiten oder möchte nicht auf TrackBack-Benachrichtigungen verzichten. Die Datei xmlrpc.php im WordPress Root Verzeichnis ist häufiger Angriffspunkt für DDOS-Attacken. Man kann den Zugriff entweder auf Serverebene deaktivieren oder tut dies in der .htaccess-Datei im root-Verzeichnis der WordPress-Installation.

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

REST API  schließen

Aktuell geisterte die Sicherheitslücke Rest API durchs Netz. Wie man diese schließen kann, liest man hier. Allerdings wird sie durch WP 4.7.2 automatisch geschlossen. Ist also nur für Betreiber früherer Versionen relevant.

Einsetzen der 7G Blacklist

Die 7G Blacklist ist eine Sammlung von einfachen, aber wirksamen .htaccess-Direktiven, die auf Serverebene verdächtige Anfragen blockiert. Dadurch werden Ressourcen für PHP und MySQL gespart. Kann auch auf Nicht-WordPress-Webseiten eingesetzt werden. Diese Direktiven am besten in der .htaccess-Datei vor den WordPress-Permalink-Direktiven einführen. Man kann testen, ob die Firewall greift, indem man eine beliebige Seite der eigenen Webseite mit dem Zusatz „?eval(“ öffnet. Zum Beispiel:

http://www.meinedomain.de/?eval( 

öffnet. Kommt dann eine „Forbidden“ Meldung, greift die Firewall.

Hier bekommt man die 7G Firewall

Blockieren von großen Attacken auf Upload-Ziele

Ende 2019 und Anfang 2020 konnten Sicherheitsexperten Massen-Angriffe auf Upload-Ziele feststellen. Im Endeffekt werden typische Upload-Ziele in WP Seiten gescannt in der Hoffnung offene Tore zu finden. Diese Angriffe sind nicht nur gefährlich, sondern belasten auf den Webserver. Der Anbieter der 7G Firewall hat hierfür Direktiven für die .htaccess veröffentlicht, die dem Spuk ein Ende bereiten. Diese werden einfach zu den 7G Firewall Regeln dazugestellt.

# 7G Addon: Stop Aggressive Scanning for Uploads-Related Targets
# https://perishablepress.com/stop-aggressive-scanning-uploads/


	# RewriteCond %{REQUEST_URI} /php(unit)?/ [NC,OR]
	# RewriteCond %{REQUEST_URI} \.(aspx?|env|git(ignore)?|phtml|rar|well-known) [NC,OR]
	# RewriteCond %{REQUEST_URI} /(cms|control_panel|dashboard|home_url=|lr-admin|manager|panel|staff|webadmin) [NC,OR]
	# RewriteCond %{REQUEST_URI} /(adm(in)?|blog|cache|checkout|controlpanel|ecommerce|export|magento(-1|web)?|market(place)?|mg|onli(n|k)e|orders?|shop|tmplconnector|uxm|web?store)/ [NC,OR]
	
	RewriteCond %{REQUEST_URI} (_timthumb_|timthumb.php) [NC,OR]
	RewriteCond %{REQUEST_URI} /(install|wp-config|xmlrpc)\.php [NC,OR]
	RewriteCond %{REQUEST_URI} /(upload|uploadify|uploadbg|up__uzegp)\.php [NC,OR]
	RewriteCond %{REQUEST_URI} /(clipboard\.min\.js|comm\.js|mysql-date-function|simplebootadmin|vuln\.htm|www\.root\.) [NC,OR]
	RewriteCond %{REQUEST_URI} /(admin-uploadify|fileupload|jquery-file-upload|upload_file|upload|uploadify|webforms)/ [NC,OR]
	RewriteCond %{REQUEST_URI} /(ajax_pluginconf|apikey|connector(.minimal)?|eval-stdin|f0x|login|router|setup-config|sssp|vuln|xattacker)\.php [NC]
	
	RewriteRule .* - [F,L]
	

Mehr Infos, wie man das einbindet findet ihr hier:
https://perishablepress.com/stop-aggressive-scanning-uploads/

Fazit: Je mehr Maßnahmen getroffen werden, die es Angreifern erschweren, Infos über WordPress-Installationen oder Zugänge zu diesen zu erhalten, desto besser. Security by Oscurity wird von manchem in Frage gestellt, weil es Profihacker nicht gänzlich behindert. Ich sehe das anders und vergleiche gerne mit Häusern: Nur weil ein Einbrecher auch eine Fensterscheibe einschlagen könnte um in ein Haus einzubrechen, lässt man nicht die Haustür sperrangelweit offen. Und brauchen Sie Hilfe um Ihre Webseite abzusichern oder Ihre Webseite wurde gehackt? Ich helfe gerne.

Hat dir mein Beitrag geholfen?

Klicke auf die Sterne um zu bewerten!

Durchschnittliche Bewertung 0 / 5. Anzahl Bewertungen: 0

Letzte Version vom 29. Januar 2020 von Netzgänger
Jetzt WordPress Newsletter in dein Postfach

Melde dich jetzt für meinen Newsletter an und du erhältst regelmäßig Tipps und Tricks zu WordPress in dein Postfach. Natürlich kannst du ihn jederzeit abbestellen.


  • Steffanie

    Ihr Artikel über ist lobenswert. Der Leser erfährt alle wichtigen Informationen, um Sicherheitsschwachstellen seiner WordPress-Website so gut wie möglich zu beseitigen oder sie zu vermindern, auch ich habe Ihren Artikel genauer angeschaut und auch einige Konfigurationen in meine Website eingefügt.

    Reply

  • Sven

    Hallo Rene,
    danke für die vielen Sicherheitstipps – da hab ich ja noch „Arbeit“ vor mir.
    Aber eine „Verständnisfrage“ habe ich bzgl. „wp-admin durch .htacces … schützen“ – dies habe ich auch auf anderen Seiten gelesen und habe da so meine PRobleme … die schreibst ja auch dass die .htaccess-Datei im root liegen soll – aber dann ist doch die ganze seite geschützt ? ODer verstehe ich das falsch und Du meinst im wp-admin Verzeichnis ? Aber egal wie ich es mache, nach eingabe des Namen und Kennworts kommt eine Server-Error:
    „“Internal Server Error

    The server encountered an internal error or misconfiguration and was unable to complete your request.

    Please contact the server administrator at to inform them of the time this error occurred, and the actions you performed just before this error.

    More information about this error may be available in the server error log.

    Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request.““

    Ich bin bei 1&1 – liegt es evtl. daran ? Weil über das Control-Center kann man ja einen Verzeichnis-Schutz anlegen – und die PAsswort-Datei liegt dann in einem für mich nicht erreichbaren Bereich ….

    Ich hatte das schon getestet – aber „Limit Login Attempts “ registriert trotzdem Anmeldeversuche über ausländische IP’s …. oder ist es „zu spät“ weil evtl. schon irgendwo Schadcode eingeschleust wurde ?

    Es ist nur eine kleine private Seite und nicht „lebensnotwendig“ – Ich könnte die auch nochmal neu aufsetzen – habe aber auch die Betreuung einer Vereinsseite (bei Domainfactory) übernommen, wo die .httaccess im wp-admin verzeichnis auch keine Wirkung zu haben scheint – oder ich falsch mache…. Und wollte einer kleinen Firma ebenfalls eine WOrdpress-Seite einrichten – da wollte ich schon wissen, wie ich diese absichern kann

    Ich werde jetzt versuchen, WordPress mit empfohlenen Plugins abzusichern, würde aber schon gern verstehen, wieso das mit der .htacces bei mir nicht zu greifen scheint …

    Danke und Grüße
    Sven

    Reply

    • René Dasbeck Post author

      Ist schwer zu sagen aus der Ferne. Aber wenn ein internal server error auftritt, dann ist sicher ein Fehler in der .htaccess. Diese arbeitet im Übrigen rekursiv, d.h. was dort definiert wird, schleust sich durch in die letzte Verzeichnisebene. Man kann aber in Unterverzeichnissen weitere .htaccess-Dateien anlegen, die diese Direkten aus dem root-Verzeichnis aufheben oder erweitern.

      Reply

  • Paul

    Hallo Rene,

    toller Artikel.

    Welche Themeshops kannst Du empfehlen?Themeforest??

    Gibt es eine Einstellung/Code mit welchem man verschleiern kann, dass man das System WordPress benutzt?
    Und wie kann ich den Theme Namen verstecken, sodass Theme Detectoren das Theme nicht preisgeben und somit auf WordPress verweisen?

    Gruß Paul

    Reply

    • René Dasbeck Post author

      Themeforest ist super. Da bin ich auch sehr häufig unterwegs. WP generell zu verschleiern geht vermutlich kaum, da der Quellcode einiges preisgibt. Bezüglich Theme fällt mir gerade leider nichts ein.

      Reply

  • Katsu

    Hier ist immer wieder die Rede von der „functions.php“ um z.B. die Fehlermeldung beim falschen Login zu verändern. In welcher der vielen „functions.php“ Dateien, die WordPress beseitzt, muss das eingetragen werden?

    Reply

  • Gustl

    guten morgen!

    ich möchte für ein firmenprojekt eine wordpress seite erstellen und den zugang für diese auf 450 personen beschränken. ziel ware es dass sich diese personen nur mit username und passwort auf die seite einloggen können.

    ist eine zugangsbeschränkung mit username und passwort in dieser form mit wordpress websites möglich?

    Vielen dank für die auskunft und den guten artikel!

    LG aus österreich

    Reply

  • Ralph

    Hallo René,

    schöner Beitrag, vielen Dank für die Anregungen. Übrigens gibt es Block Bad Queries inzwischen als Plugin, das auch regelmäßige Updates erfährt.

    Ich habe ein ähnliches Problem wie sara, das Verschieben der wp_config.php führt bei mir zu PHP-Fehlern. Irgendwie mache ich einen Aussetzer /Denkfehler. Ich habe WP in einen Ordner installiert, auf den auch die Domain geroutet ist. Verschiebe ich nun die Config eine Ebene höher, liegt sie ja nicht mehr im Bereich der Domain. Ich möchte WP aber auch nicht extra in einen Unterordner installieren.

    Kannst du mir vielleicht einen Tipp geben, um den Knoten in meinem Hirn zu lösen?

    Reply

  • sara

    Verschieben der wp-config.php eine Ebene höher

    hallo,
    wenn ich die wp-config.php eine Ebene höher verschiebe, dann verlangt wordpress das ich die samle-confiq.php hochlade und verlangt dann wie bei der neuinsalation , die datenbank usw. daten.

    hab ich das falsch gemacht. wordpress im ordner MUSIK
    und die wp-config.php höher verschoben in einen neu erstellten ordner ABC.
    ?

    danke im voraus

    Reply

  • Nadine

    Hallo Renè,

    ich hab mich mit ithemes security auch selbst ausgesperrt, bzw. war kein Login mehr möglich. Bei einigen Einstellungen ist mir auch nicht klar, was genau ich machen soll (kann zwar englisch, aber so fachbezogen wird es teilweise schwer). Leider finde ich nirgendwo eine Anleitung in Deutsch. Eine deutsche Sprachdatei für das Plugin gibt es wohl auch nicht? Wäre für Tipps sehr dankbar!

    Reply

  • Voxs

    was ich mich schon lange frage – warum konstruiert WP seither diese typische Directories-Dateistruktur, deren Namen mit wp- beginnen etc.? Und versieht zudem CSS etc. zusätzlich mit Versionsnummern-Ergänzungen, sodass wir User dann an allen Enden und Ecken 1000 Tricks und/oder Plugins einsetzen müssen, um zu verschleiern was niemanden was angeht! Würde das o. Genannte entfallen, wären z.B. die Pfade doch auf den ersten Blick eher ununterscheidbar von anderen CMS. Liegt das etwa nur an der “proud to publish with WP” – Kultur und Absicht unbenommen der Risiken immer weiter und weitreichend Werbung für die eigene Software machen zu wollen?

    Reply

  • Renate

    Vielen Dank für die ausführliche Auflistung. Einige Vorschläge setze ich schon länger um, muss aber immer mal wieder nachschlagen.

    Dabei viel mir auf, dass im Eintrag zu „Backend editieren verbieten“ ein Fehler steckt. Der Code gehört in die wp-config.php nicht in die functions.php. Könnte vielleicht irritieren.

    Reply

  • ConnieM

    ich sehe im Beispiel für den Schutz der wp-login.php keinen Schutz dieser Datei.

    Der Dateiname muss doch in einer Direktive genannt werden, oder?

    # protect wp-login.php
    AuthName „Admin-Bereich“
    AuthType Basic
    AuthUserFile /pfadzur/.htpasswd
    require valid-user

    wenn ich das ins Hauptverzeichnis lege, wo die Datei wp-login.php liegt, dann geht gar nichts mehr, das kann doch wohl nicht ernst gemeint sein, oder?

    Reply

    • René Dasbeck Post author

      Hallo ConnieM. Diese Direktive legt man in einer .htaccess-Datei am besten in den Ordner wp-admin/ um diesen und das Login zu schützen. Bei den allermeisten WordPress-Installationen macht das keine Probleme und es ist eine weitere Hürde für Hacker an das Loginformular zu kommen. Das Einfallstor Nr. 1 in WP. Ich schreib das mal noch dazu.

      Reply

  • wilmi

    Hallo,

    vielen Dank für die Anleitungen! Sehr hilfreich. Bei dem Schutz der wp-login.php durch .htaccess habe ich allerdings bei mir festgestellt, dass die zusätzliche PW-Abfrage nur erscheint, wenn ich über Proxy ins Internet gehe. Schalte ich den aus, erscheint die Abfrage nicht.
    Vielleicht habe ich auch einen wesentlichen Denkfehler, aber ist das so richtig?

    Gruß, Wilmi

    Reply

  • RolandStumpp

    Hi,
    ich bin einigermaßen erstaunt über den Vorschlag die wp.login.php mit einem Passwortschutz zu sichern. Bis zu diesem Punkt bin ich dabei. Aber dann in einen ungeschützten Passwortgenerator die eigens kreierten Benutzernamen einzugeben um sich dann ebenso ungeschützt ein Passwort generieren zu lassen halte ich für sträflich. Am meisten muss ich dann über den Satz lachen der nach der Erzeugung des Passwortes erscheint!
    I do NOT log ANY data entered in this form.

    Echt geil…man erfindet Benutzernamen und Passwörter und schickt die dann ungeschützt ins Nirwana. Starke Nummer.

    Reply

    • René Dasbeck Post author

      Hier geht es darum, eine doppelte Hürde zu schaffen. Und wenn man das Passwort in einem ungeschützten Passwortgenerator erstellt, weiß dieser Generator noch lange nicht, für welche Webseite dieses Passwort generiert wurde. Von daher ist das durchaus legitim. Vor allem benötigt man ja für die Authentifizierung ja noch den Benutzernamen. Diesen muss man ja nicht real angeben…

      Reply

      • Roland Stumpp

        Passwörter, die man ungeschützt ins Netz bläst sind eine willkommene Gelegenheit eine Passwortliste zu ergänzen. Außerdem wird im offenen Formular die IP Adresse übertragen. Man muss sich nicht wundern wenn immer mehr Computer und Websites von Hackern benutzt werden. Das geheimste Passwort wird durchs Netz geblasen und jeder der es gerne sammeln möchte kann es tun. Ich denke, man sollte die Leute die Böses im Schilde führen nicht für blöde halten.

        Reply

        • René Dasbeck Post author

          Du hast sicher Recht, dass theoretisch ein Restrisiko bleibt. Aber wie groß ist dieses? Meine IP Adresse nützt dem Hacker herzlich wenig, da diese meistens flexibel zugewiesen wird und sich ändert und keine direkt Verbindung zu einem Webserver zeigt. Zudem ist ein Passwort allein kaum etwas wert und kann allerhöchstens Brute-Force-Passwort-Listen erweitern. Das klingt zwar kritisch, ist es aber nicht wirklich, wenn die Benutzername-Passwort-Kombination nicht bekannt ist. Von daher kann ich deine Bedenken irgendwo nachvollziehen, sehe es aber persönlich anders.

          Reply

  • Daniel

    Danke für die vielen und vorallem guten Tipps! Ich hab bisher mit Better WP Security sehr gute Erfahrungen gemacht, aber ab und zu musste ich das Plugin deaktivieren oder die erstellen .htaccess Dateien löschen, damit ich bestimmte Änderungen am System machen kann. Außerdem verträgt es sich nicht so gut mit BackWPUp, zumindest werden bei mir gelegentlich Fehler angezeigt..

    Reply

  • WPFreak

    Wow, dass nenn ich mal umfangreich das Tutorial. Hat jemand generell Erfahrungen mit WordPress Sicherheit? Man hört ja manchmal, dass es nicht so sicher sein soll. Fragt man sich ja schon, ob es so ist, oder ob es auch nicht unsicherer ist als andere CMS!?

    Reply

  • Stephan

    Hi René,

    schöne Auflistung, die du da zusammengestellt hast. Bei den Plugins sollte aber auch gesagt sein, dass Secruity-Plugins selbst auch Sicherheitslücken mitbringen können und man sie immer auf dem aktuellen Stand halten sollte.

    Grüße Stephan

    Reply

    • René Dasbeck Post author

      Hallo Stephan,

      danke für den Hinweis. Hatte ich allerdings schon drin im Artikel (keine Panik, ich verurteile niemanden, der den ellenlangen Text nicht gänzlich gelesen hat 😉

      Reply

  • stefan aus dresden

    Hi. Knaller Tutorial 🙂 Ich glaub, wenn man immerhin ein Viertel davon beherzigt, muss man sich keine Sorgen mehr machen. Gleich mal gebookmarkt. Beste Grüße!

    Reply

  • Peter

    Das ist ja eine Mega Anleitung. Das gibt für mich jede Menge todos, denn ich denke, es ist sinnvoll diese mal umzusetzen.

    Reply

  • Marcus

    Danke für diese sehr ausführliche Auflistung. Jetzt weiß ich, wie viel es bei meinem Blog noch zu tun gibt. Es ist immer schön, auch nach Jahren noch neue nützliche Seiten zu finden. Mach weiter so!

    Reply

  • Daniela

    Wow, endlich mal ein Artikel der gefühlt alles beinhaltet, was im Rahmen der Sicherheit von WordPress möglich ist.

    Ich werd in Zukunft diese Sicherheitsmaßnahmen umzusetzen, man weiß ja nie.

    Gruß
    Dani

    Reply

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.