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. (Stand 22.06.2018)

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.

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.

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.

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.

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. Link

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.

Anti-Malware Security and Brute-Force Firewall installieren

Ein weiteres Security Plugin, welches als Helfer fungiert. Der Vorteil dieses Plugins ist der Scan nach bereits gehackten Dateien. Abseits dieses Scan-Features bietet das Plugin noch diverse gute Sicherheitsstandards, wie das Unterbinden der Hackversuche in das WP Dashboard. Die Installation ist eher sinnvoll nach einem Hack oder als Alternative für iThemes und Hide My WP. Wenngleich mit weniger Funktionsumfang. Link

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 6G Blacklist

Die 6G 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.

# 6G FIREWALL/BLACKLIST
# @ https://perishablepress.com/6g/

# 6G:[QUERY STRINGS]

	RewriteEngine On
	RewriteCond %{QUERY_STRING} (eval\() [NC,OR]
	RewriteCond %{QUERY_STRING} (127\.0\.0\.1) [NC,OR]
	RewriteCond %{QUERY_STRING} ([a-z0-9]{2000}) [NC,OR]
	RewriteCond %{QUERY_STRING} (javascript:)(.*)(;) [NC,OR]
	RewriteCond %{QUERY_STRING} (base64_encode)(.*)(\() [NC,OR]
	RewriteCond %{QUERY_STRING} (GLOBALS|REQUEST)(=|\[|%) [NC,OR]
	RewriteCond %{QUERY_STRING} (<|%3C)(.*)script(.*)(>|%3) [NC,OR]
	RewriteCond %{QUERY_STRING} (\\|\.\.\.|\.\./|~|`|<|>|\|) [NC,OR]
	RewriteCond %{QUERY_STRING} (boot\.ini|etc/passwd|self/environ) [NC,OR]
	RewriteCond %{QUERY_STRING} (thumbs?(_editor|open)?|tim(thumb)?)\.php [NC,OR]
	RewriteCond %{QUERY_STRING} (\'|\")(.*)(drop|insert|md5|select|union) [NC]
	RewriteRule .* - [F]


# 6G:[REQUEST METHOD]

	RewriteCond %{REQUEST_METHOD} ^(connect|debug|delete|move|put|trace|track) [NC]
	RewriteRule .* - [F]


# 6G:[REFERRERS]

	RewriteCond %{HTTP_REFERER} ([a-z0-9]{2000}) [NC,OR]
	RewriteCond %{HTTP_REFERER} (semalt.com|todaperfeita) [NC]
	RewriteRule .* - [F]


# 6G:[REQUEST STRINGS]

	RedirectMatch 403 (?i)([a-z0-9]{2000})
	RedirectMatch 403 (?i)(https?|ftp|php):/
	RedirectMatch 403 (?i)(base64_encode)(.*)(\()
	RedirectMatch 403 (?i)(=\\\'|=\\%27|/\\\'/?)\.
	RedirectMatch 403 (?i)/(\$(\&)?|\*|\"|\.|,|&|&?)/?$
	RedirectMatch 403 (?i)(\{0\}|\(/\(|\.\.\.|\+\+\+|\\\"\\\")
	RedirectMatch 403 (?i)(~|`|<|>|:|;|,|%|\\|\s|\{|\}|\[|\]|\|)
	RedirectMatch 403 (?i)/(=|\$&|_mm|cgi-|etc/passwd|muieblack)
	RedirectMatch 403 (?i)(&pws=0|_vti_|\(null\)|\{\$itemURL\}|echo(.*)kae|etc/passwd|eval\(|self/environ)
	RedirectMatch 403 (?i)\.(aspx?|bash|bak?|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rar|rdf)$
	RedirectMatch 403 (?i)/(^$|(wp-)?config|mobiquo|phpinfo|shell|sqlpatch|thumb|thumb_editor|thumbopen|timthumb|webshell)\.php


# 6G:[USER AGENTS]

	SetEnvIfNoCase User-Agent ([a-z0-9]{2000}) bad_bot
	SetEnvIfNoCase User-Agent (archive.org|binlar|casper|checkpriv|choppy|clshttp|cmsworld|diavol|dotbot|extract|feedfinder|flicky|g00g1e|harvest|heritrix|httrack|kmccrew|loader|miner|nikto|nutch|planetwork|postrank|purebot|pycurl|python|seekerspider|siclab|skygrid|sqlmap|sucker|turnit|vikspider|winhttp|xxxyy|youda|zmeu|zune) bad_bot
	
		Order Allow,Deny
		Allow from All
		Deny from env=bad_bot
	


# 6G:[BAD IPS]

	Order Allow,Deny
	Allow from All
	# uncomment/edit/repeat next line to block IPs
	# Deny from 123.456.789

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.

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.


46 Kommentare

    // Dieses Template wird später in der functions.php definiert

Kommentar schreiben

Mit Absenden deines Kommentars erklärst du dich mit der Verarbeitung deiner hier angegebenen Daten einverstanden (Datenschutzerklärung). Diese werden nur zur Verwaltung der Kommentare verwendet und keinem anderen Zweck zugefügt. Du kannst jederzeit per E-Mail an info@netz-gaenger.de der Speicherung deiner Daten widersprechen.

* Notwendige Angaben

Netzgänger Webdesign | Rohrersmühlstraße 22 in Schwabach | Bayern
Kontakt: info@netz-gaenger.de
↑ oben
Inhalt