WordPress Security-Maßnahmen erweitern

Immer wieder stoße ich bei Kunden auf WordPress Installationen, die überhaupt keine Sicherheitsmaßnahmen erfahren haben. Vor einiger Zeit habe ich einen umfassenden Artikel veröffentlicht, der die wichtigsten Security-Maßnahmen abdeckt. In der Zwischenzeit habe ich noch einige weitere Möglichkeiten entdeckt, die eigene WordPress-Seite (und durchaus auch andere Webseiten) abzusichern. (Aktualisiert am 21.06.2017).

erweiterte-wordpress-security

 

Können Webseiten 100% sicher sein?

Achtung: Es wird bei den folgenden Maßnahmen sicher wieder den einen oder anderen Leser geben, der diese infrage stellt. Ich möchte daher gleich hier auf Folgendes aufmerksam machen: Alle Maßnahmen, die in vernünftigem, wirtschaftlichem Umfang von normalen Webseitenbetreibern getroffen werden können, stellen niemals eine 100%-ige Sicherheit dar. Ist ein Profi am Werk, ist es unglaublich schwer, ein System wasserdicht abzusichern. Sicherheitslücken verstecken sich nicht nur in Webseiten, sondern können auch vom Webhoster unfreiwillig geliefert werden. Die hier gelisteten Maßnahmen machen es aber den allerhäufigsten Angreifern schwer: Script-Kiddies und automatisch agierende Botsysteme, die systematisch Sicherheitslücken suchen um Schadsoftware oder SPAM-Mails zu verteilen.

Ein sehr gutes WordPress Plugin für Security verwenden

Mit einem Security Plugin lassen sich Sicherheitsrisiken bei WordPress relativ schnell und bequem minimieren. Natürlich können auch Plugins nicht alles abfangen, aber sie geben schon eine große Grundsicherheit. Wenn ich WordPress-Webseiten meiner Kunden absichere, dann nutze ich ebenso Plugins. Hier ein paar, die ich absolut empfehlen kann:

Hide my WP

Der Name ist etwas irreführend. Dieses Securityplugin der Spitzenklasse bringt viele Features mit wie das stopfen von Sicherheitslöchern, dem Verstecken von WP als System ansich (was einen großen Vorsprung gegenüber automatisierten Hackerangriffen bedeutet), Firewall, Anti-SPAM, … Das Plugin ist zwar kostenpflichtig, die Sicherheit der eigenen Webseite sollte aber jedem Webseitenbetreiber ein paar Euro wert sein.

iThemes Security

iThemes liefert viele Einstellungen wie das Absichern des Logins, 404 Angriffsblockierung, Aussperrung von Angreifern bei mehrfachen Versuchen in das System einzudringen, Umbenennung von Datenbank und Erstellung neuer Salts, … Ein Muss für Security!

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.

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.

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 Email-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 Email

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.

53 Kommentare

  1. Manuel sagt:

    Danke! Muss man denn die Änderungen nach jedem Update von WordPress erneut vornehmen oder bleiben die so bestehen?

Kommentar schreiben

* Notwendige Angaben

Netzgänger Webdesign | Schlehenweg 7 in Büchenbach | Bayern
Kontakt: info@netz-gaenger.de |
↑ oben
Inhalt