WordPress gegen Hacker schützen

WordPress gehört mittlerweile zu den beliebtesten CMS Systemen in Internet und ist demzufolge sehr stark verbreitet. Durch die einfache Installation, Verwaltung, Administration und die vielen wunderschönen (kostenlosen) Webseitentemplates wird WordPress von vielen bevorzugt. Durch die weit verbreiteten WordPress Installationen werden aber auch Angreifer aufmerksam und versuchen dieses CMS System zu infiltrieren, um dadurch auf der gehackten Webseite schädlichen Code, Malware, Spam, Viren und sonstiges Geschehen zurückzulassen und die Homepage dadurch zu infizieren und im schlimmsten Falle als Weiterverbreitung dieser Viren / Spam zu verwenden.

Jedoch ist nicht nur die Webseite selbst das primäre Angriffsziel, sondern in vielen Szenarien eher der dahinterliegende Server. Wurde dieser erfolgreich kompromittiert (dies bedeutet: Daten verändert / manipuliert – worüber der Eigentümer / Administrator keine Kontrolle über die korrekte Funktionsweise bzw. den korrekten Inhalt mehr hat), so kann der Angreifer diesen Server dazu nutzen um dadurch seinen Spam und seine Viren weiterzuverbreiten bzw. den Server für DDOS Attacken (Distributed Denial-of-Service-Attacken) oder Ähnliches zu missbrauchen.

All dies möchte logischerweise keiner und von daher ist es sehr wichtig nicht nur die eigene WordPress Installation gegen Angreifer zu beschützen, sondern auch den Server sicher und solide aufzusetzen.

Nützliche Tipps um den Server stets sicher zu halten

Viele Personen, welche einen WordPress Blog betreiben haben im Regelfall wenig Ahnung von Servern, Linux und Co., sodass diese meistens auf ein Hosting von großen Anbietern wie beispielshalber 1&1, Host Europe, Strato usw. zurückgreifen. Hier erhält der Kunde ein Webpaket und der Anbieter kümmert sich um die Sicherheit des Servers. Auch besteht die Möglichkeit einen Managed Server zu bestellen, in dem auch der Dienstleister der für die Administration zuständig ist.

Für diejenigen, die sich ein wenig mit Linux bzw. Windowssystemen und den dazugehörigen Servern auskennen, so sind Root Server generell die richtige Wahl. Eine Einrichtung ist sehr komplex und sollte nicht auf die leichte Schulter genommen werden. Hier empfiehlt es sich auf gute Freunde zurückzugreifen, welche im Idealfall als ein Linux Administrator tätig sind. Optional hierzu können auch Webseitenagenturen oder der Hoster selbst kontaktiert werden, um etwaige Fragen zu klären und nützliche Hinweise zu erhalten. Andernfalls dienen umfangreiche Installationsanleitungen Internet, welche euch peu à peu durch die Installation führen.

Wurde der Server erfolgreich aufgesetzt, so können wir das eine oder andere Tool empfehlen, welches auf dem Laufenden Root Server essenziell ist und keinesfalls fehlen sollte. Zuzüglich möchten wir erwähnen, dass auch auf dem Server selbst regelmäßige Updates durchgeführt werden sollten, sodass die darauf befindlichen Dateien nicht veraltet und dadurch leichter angreifbar sind.

Nützliche Tools sind zum Beispiel:

ISP Config

Dies wird zum Verwalten vieler Webseiten hinzugezogen und ist ein gerngesehener Knotenpunkt für viele Administratoren und Webseitenbetreiber. Durch diese Plattform kann über eine webseitenbasierte Anwendung mit wenigen Klicks eine neue Webseite, Datenbank, ein Datenbank Benutzer, DNS Einträge, E-Mail Accounts und sonstiges Geschehen angelegt werden, ohne dabei mit Shell und Linux Befehlen zu hantieren.

Gerade für Laien ist ISP Config die clevere Wahl. So könnte zum Beispiel euer Webseitenadministrator euch das ISP Config richtig aufsetzen, sodass ihr nachfolgend nur noch über das Backend neue Webseiten, Kunden, E-Mail Accounts, Datenbanken und ähnliches hinzufügt bzw. entfernt. Zuzüglich sollte der standardmäßige Port 8080 auf einen anderen geändert werden, sodass die Angreifer nicht über den regulären Link www.eure-webseite.de:8080 verschiedene Logins versuchen. Ebenfalls ist es sehr ratsam in ISP Config auch die weiter unten folgende IP-Sperre und den Passwortschutz einzubauen.

Fail2ban

Ein weiteres nützliches Tool stellt Fail2ban dar. Durch dieses werden die Login Versuche auf euren Root Server geloggt / protokolliert und bei mehrfach falsch eingegebenen Benutzerdaten wird die IP-Adresse für eine gewisse Zeit vom Server ausgegrenzt / gebannt. In der Konfigurationsdatei von Fail2ban kann der Zeitraum und die vielen möglichen Login Versuche angepasst werden. Zeitgleich ist es sogar möglich verschiedene IP-Adressen auszugrenzen, sodass ihr euch im schlimmsten Fall dadurch nicht selber aussperrt.

Gerade für einen eigenen Root Server ist Fail2ban signifikant und kann im Idealfall vor einer möglichen Kompromittierung schützen. Der Angreifer hat dadurch nicht ewig viele Möglichkeiten diverse Passwörter in kürzester Zeit „auszuprobieren“. Durch die schnelle Sperre (zum Beispiel nach 5 gescheiterten Login Versuchen) muss der Angreifer entweder warten oder seine IP-Adresse wechseln.

SSH Server Ports ändern

Definitiv ist es überaus wichtig die zu lauschenden Ports des Servers anzupassen, sodass der standardmäßige SSH Port (22) auf einen individuellen geändert wird. Um einige Hilfestellungen zu gewährleisten, so dient das unten eingeblendete Material.

Die Datei in der ihr den SSH Server Port ändern könnt befindet sich beim Debian Server zum Beispiel hier:

/etc/ssh/sshd_config

Diese Datei editiert ihr und ändert den Port von 22 auf einen Port eurer Wahl ab. Bitte nicht Port 80 oder 443 verwenden. Auch solltet ihr darauf achten, dass ihr keinen festen Port verwendet, welchen bereits andere Dienste benutzen. Nach der erfolgreichen Änderung muss lediglich der SSH Dienst neu gestartet werden, welches mit diesem Befehl funktioniert:

/etc/init.d/ssh restart

So begrenzt ihr bereits mit dieser kleinen Änderung die Angriffswut immens, denn im Regelfall versuchen Angreifer meistens durch den standardmäßigen Port (22) euren Server zu infiltrieren. Da der neue SSH Port nicht für Außenstehende direkt ersichtlich ist, so müssen diese diesen erst erraten, sodass die standardmäßigen Bots / Angreifer, welche die herkömmlichen 22er Ports auf Schwachstellen prüfen bereits hier Versagen.

IPs-Sperre, htaccess und htpasswd für WordPress Login

Nachdem wir auf einige wichtige nützliche serverseitige Eigenschaften hingewiesen haben, so widmen wir uns nun WordPress selbst und verkünden den einen oder anderen Tipp, wie ihr WordPress gegen Angreifer und Hacker absichern könnt. Selbstverständlich existieren auch viele WordPress Plugins, welche unter anderem auch gern hinzugezogen werden können. Meistens ist es leider nicht ersichtlich, was genau diese Plugins wirklich tun und vieles ist sehr ungewiss. Um wirklich auf Nummer sicher zu gehen, so sind händische Anpassungen empfehlenswerter.

Die Angreifer, Bot Netzwerke und sonstige Halunken versuchen meistens über „xmlrpc.php“ | „wp-login.php“ | „wp-admin“ in den Adminbereich zu gelangen. Natürlich ist hier vorab ein Benutzername und ein Passwort einzugeben. Hat der Webseitenbetreibende jedoch keine Sicherheitsmaßnahmen vorgenommen, so kann der Angreifer stundenlang diverse Passwörter ausprobieren, um irgendwann die Webseite zu hacken. Hier existieren optional einige Plugins, welche zukünftige Login Versuche nach drei gescheiterten Fehlversuchen für eine gewisse Zeit blockieren. Auch sind 2-step verification Plugins sehr nützlich und können eventuell in Erwägung gezogen werden.

IP-Adressen und .htpasswd Sperre

Hier empfehlen wir zum Beispiel eine IP-Adressen Sperre, sodass lediglich eure IP-Adresse für das Backend und den Login Bereich freigegeben ist. Personen, welche eine statische IP-Adresse besitzen haben in dieser Konstellation definitiv viel Glück, denn es muss lediglich eure IP-Adresse in der .htaccess oder Nginx Konfigurationsdatei angegeben und freigegeben werden. Alle anderen IP-Adressen sollten auf „deny all“ stehen. Zeitgleich empfiehlt sich eine htpasswd Vergabe, sodass beim Betreten ein Benutzername und Passwort eingegeben werden muss.

Es besteht auch die Möglichkeit dies mit „satisfy any“ zu lösen, sodass entweder die richtige IP-Adresse die URL aufruft und ihr somit in das Backend gelangt, oder falls ihr nicht die IP-Adresse besitzt, so solltet ihr den Benutzernamen und das Passwort wissen (htpasswd). Quasi entweder oder. Dies ist euch überlassen. Simultan empfehlen wir den Zugriff auf die „xmlrpc.php“ zu verweigern, da diese sehr gern von Angreifern zur Erforschung von Passwörtern bzw. als Login dienlich ist. Solltet ihr nicht über das Handy bloggen bzw. die Dienste von der „xmlrpc.php“ nicht benötigen, so ist eine Deaktivierung wärmstens zu empfehlen.

Hier ein Beispiel wie das Ganze für eine Nginx Konfiguration aussehen kann:

#### /wp-admin gegen unbefugte Besucher sichern
location ~ ^/(wp-admin) {

auth_basic "Nur Admins";
auth_basic_user_file /pfad-zu-eurer-htpasswd-datei/.htpasswd;
allow xx.xx.xxx.xx; #die xx mit eurer eigenen IP-Adresse austauschen
deny all;
error_page 403 = @goaway;
}

#### /wp-login.php gegen unbefugte Besucher sichern
location = /wp-login.php {

auth_basic "Nur Admins";
auth_basic_user_file /pfad-zu-eurer-htpasswd-datei/.htpasswd;
allow xx.xx.xxx.xx; #die xx mit eurer eigenen IP-Adresse austauschen
deny all;

### Hier müssen nun zusätzlich eure Php variablen folgen, ansonsten kann die login.php nicht korrekt aufgerufen werden.

error_page 403 = @goaway;
}

location @goaway {
return 444;
}

# XML-RPC deaktivieren
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
return 444;
}

Hier ein Beispiel wie das Ganze für eine Apache (.htaccess) Konfiguration aussehen kann:

Diese .htaccess Datei sollte im Ordner /wp-admin liegen.

AuthType Basic
AuthName "Admin Bereich"
AuthUserFile /pfad-zu-eurer-htpasswd-datei/.htpasswd
Require valid-user

Order deny,allow
Deny from all
Allow from xx.xx.xxx.xxx - hier folgt wieder eure IP-Adresse


Diese .htaccess Datei sollte im Hauptverzeichnis liegen.

# Passwortgeschützte wp-login.php
files wp-login.php>
AuthType Basic
AuthName "Admin Bereich "
AuthUserFile /pfad-zu-eurer-htpasswd-datei/.htpasswd
Require valid-user

Order deny,allow
Deny from all
Allow from xx.xx.xxx.xxx - hier folgt wieder eure IP-Adresse
/files>

# XML-RPC deaktivieren
files xmlrpc.php>
IfModule mod_authz_core.c>
Require all denied
/IfModule>
/files>

* files und IfModule müssen mit < beginnen, welches wir enfternen mussten, da dies sonst nicht im Code erscheinen würde.

Ganz gewiss kann das eine oder andere hinzugefügt werden. Dies ist lediglich eine grobe Basis auf der aufgebaut werden kann. In den kommenden Tagen werden wir noch ergänzende Impressionen rund um das Thema Sicherheit ergänzen. Zuzüglich möchten wir jedoch noch darauf hinweisen, dass nach der Erstellung in einer Nginx Konfiguration der Nginx Dienst neu zu starten ist, da ansonsten die Änderungen vermutlich nicht greifen.

Im selben Atemzug können wir erwähnen, dass die Dienste von Cloudflare zeitgleich sehr nützlich sind und eurer WordPress Installation zusätzlichen Schutz (sofern korrekt konfiguriert) gewähren. In punkto Cloudflare werden wir eine gesonderte News zurücklassen und sämtliche Einstellungen und Konfigurationen detailliert erörtern.

Zusätzlicher PHP Code in der Functions.php

Um noch einige Daten und Fakten im Quellcode von WordPress zu verschleiern, so sollten diese unten eingeblendeten PHP Funktionen in die Functions.php hinzugefügt werden. Dadurch ist zum Beispiel die aktuelle WordPress Version nicht mehr aus dem Quellcode ersichtlich, sowie andere interessante Eigenschaften der Skripte und Dateien, welchen niemanden außer euch etwas angehen.

// WordPress Meta Generator entfernen
remove_action('wp_head', 'wp_generator');

// Hide WordPress Version Info
function hide_wordpress_version() {
return '';
}

add_filter('the_generator', 'hide_wordpress_version');

// WordPress Versions Nummer In URL Parameters From JS/CSS entfernen
function hide_wordpress_version_in_script($src, $handle) {
$src = remove_query_arg('ver', $src);
return $src;
}

add_filter( 'style_loader_src', 'hide_wordpress_version_in_script', 10, 2 );
add_filter( 'script_loader_src', 'hide_wordpress_version_in_script', 10, 2 );

// WP EMOJI entfernen
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');

remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
remove_action( 'admin_print_styles', 'print_emoji_styles' );

Zugriffsrechte der Dateien

Auch sollten die Rechte der jeweiligen Dateien noch einmal überprüft werden. Die /wp-admin/install.php, wp-config.php, Nginx und .htaccess Dateien sollten maximal 444 Rechte besitzen und auch in der Nginx bzw. in der.htaccess Konfiguration mit „deny all; return 444;“ deklariert werden, sodass der Zugriff von externen nicht gelingt.

Anfragemethoden filtern

Auch das Filtern der Abfragemethoden kann sehr hilfreich sein, sodass keinen Schadcode durch das Eingeben in der URL erfolgen kann. Sehr gern sind wir von Fevarus Design behilflich und können in all diesen Punkten tatkräftige Unterstützung bieten, sodass die WordPress Instanz schwer angreifbar ist. Das zuzügliche Hinzuziehen der Cloudflare Dienste ist wie bereits erwähnt sehr nützlich, da dieser Cloud-Dienst bereits viele Abfragen in der URL filtert und verdächtige Verhaltensweisen schnell erkennt und gar nicht erst zu eurem Server durchlässt.

Bots via robots.txt den Zugriff verweigern

Auch sollte die „robots.txt“ dazu genutzt werden, um einige Robots von der Seite fernzuhalten, sodass eure Seite erst gar nicht auf irgendwelchen dubiosen Seiten erscheint. Wie eine Beispiel robots.txt aussehen könnte, haben wir hier drunter dargestellt.

User-agent: *
Allow: /
Disallow: /cgi-bin/
Disallow: /wp-admin/
Disallow: /trackback/
Disallow: /feed/
Disallow: /comments/
Disallow: */trackback/
Disallow: */feed/
Disallow: */comments/
Allow: /wp-admin/admin-ajax.php

# diese Robots sperren
User-agent: *thunderstone*
User-agent: 4SeoHuntBot
User-agent: 008
User-agent: AdvBot
User-agent: Afilias Web Mining Tool
User-agent: AhrefsBot
User-agent: aiHitBot
User-agent: archive.org_bot
User-agent: BacklinkCrawler
User-agent: Baiduspider
User-agent: Baidu
User-agent: Baiduspider+
User-agent: baiduspider
User-agent: bdbrandprotect
User-agent: betaBot
User-agent: BLEXBot
User-agent: BPImageWalker*
User-agent: CatchBot
User-agent: CCBot
User-agent: Cliqzbot
User-agent: COMODO SSL Checker
User-agent: Comodo-Certificates-Spider
User-agent: Content Crawler
User-agent: crawler4j
User-agent: curl
User-agent: DCPbot
User-agent: deepcrawl
User-agent: DeuSu
User-agent: discobot
User-agent: DoCoMo/2.0
User-agent: DomainCrawler
User-agent: dotbot
User-Agent: drupact
User-agent: EC2LinkFinder
User-agent: EdisterBot
User-agent: Exabot
User-agent: ExB Language Crawler
User-agent: Experibot
User-agent: Ezooms
User-agent: findlinks
User-agent: GigablastOpenSource
User-agent: Go 1.1 package http
User-agent: gonzo
User-agent: GSLFbot
User-agent: htdig
User-agent: httpget
User-agent: HuaweiSymantecSpider
User-agent: ia_archiver
User-agent: iCjobs
User-agent: Infohelfer
User-agent: ips-agent
User-agent: ipsAgent
User-agent: it2media-domain-crawler
User-agent: Java
User-agent: Jobboerse
User-agent: KaloogaBot
User-agent: larbin
User-agent: lb-spider
User-agent: lex
User-agent: libwww-perl
User-agent: linkdex.com
User-agent: LinkpadBot
User-agent: Linkpad
User-agent: LinkStats
User-agent: LSSRocketCrawler
User-agent: ltx71
User-agent: magpie-crawler
User-agent: Mail.RU_Bot
User-agent: meanpath
User-agent: meanpathbot
User-agent: megaindex
User-agent: mfibot
User-agent: MIA
User-agent: mindUpBot
User-agent: MJ12bot
User-agent: MLBot
User-agent: MojeekBot
User-agent: MSIECrawler
User-agent: netEstate NE Crawler
User-agent: Nutch
User-agent: oBot
User-agent: OpenindexSpider
User-agent: OpenLinkProfiler
User-agent: OpidooBOT
User-agent: PagePeeker
User-agent: picmole
User-agent: Pixray-Seeker
User-agent: Plukkie
User-agent: psbot
User-agent: publiclibraryarchive
User-agent: Qualidator*
User-agent: Qwantify
User-agent: ReverseGet
User-agent: Riddler
User-agent: SafeDNS
User-agent: SafeDNSBot
User-agent: savetheworldheritage
User-agent: savetheworldheritage.org
User-agent: schrein
User-agent: Scooter
User-agent: ScreenerBot
User-agent: semanticbot
User-agent: Semantic Health Web Crawler
User-agent: SemrushBot
User-agent: senderproof
User-agent: SEOdiver
User-agent: SEOkicks
User-agent: SEOkicks-Robot
User-agent: seoscanners
User-agent: SeznamBot
User-agent: SheerExplorer
User-agent: SheerSEO
User-agent: sistrix
User-agent: SISTRIX
User-agent: SiteExplorer/1.0b
User-agent: SiteExplorer
User-agent: SlySearch
User-Agent: SolomonoBot
User-Agent: SolomonoLinkChecker
User-agent: Sosospider
User-agent: spbot
User-agent: Spiderlytics
User-agent: ssearch
User-agent: suggybot
User-agent: SurveyBot
User-agent: SWEBot
User-agent: TinEye
User-agent: TurnitinBot
User-agent: Unister*
User-agent: UnisterBot
User-agent: Updownerbot
User-agent: Uptimebot
User-agent: vebidoobot
User-agent: waybackarchive.org/1.0
User-agent: waybackarchive.org
User-agent: waybackarchive
User-agent: WBSearchBot
User-agent: Webinator
User-agent: Webliste.ch
User-agent: Webliste
User-agent: WebmasterCoffee
User-agent: webmeup-crawler
User-agent: WebofantBot
User-agent: WeViKaBot
User-agent: Wget
User-Agent: wotbox
User-Agent: Wotbox
User-Agent: WWW-Mechanize/1.73
User-Agent: WWW-Mechanize
User-agent: x28-job-bot
User-agent: XoviBot
User-agent: yacybot
User-agent: YandexBot/3.0
User-agent: YandexBot
User-agent: Yandex
User-agent: YandexImages/3.0
User-agent: YandexImages
User-agent: Yeti
User-agent: Yeti-Mobile
User-agent: YisouSpider
User-Agent: YoudaoBot
Disallow: /

Sollte der eine oder andere Bot trotz dieser Aufforderung immer noch eure Webseite betreten, so könnt ihr diesen beispielshalber in eurer Nginx oder .htaccess Konfiguration mit einem „return 403;“ Adieu sagen.

Keine Backupdateien anlegen, welche zum Beispiel nicht auf .php enden

Standardmäßig ist die „wp-config.php“ für eure WordPress Konfiguration zuständig, in der die Zugangsdaten zur MySQL Datenbank hinterlegt sind. Eine .php Datei kann so nicht leicht von einem externen Angreifer ausgelesen werden. Endet diese Datei jedoch beispielshalber auf „wp-config.php.bak“ oder „wp-config.php.txt“ so hat der Angreifer hier ein leichtes Spiel und kann eure Zugangsdaten auslesen. Hat der Angreifer eure MySQL Zugänge erschlichen, so wird dieser vermutlich versuchen sich mit diesem in eure Datenbank einzuloggen.

phpMyAdmin URL ändern

Hat der Hacker eure MySQL Zugangsdaten, so wird dieser versuchen eure Datenbank zu infiltrieren. In den meisten Szenarien ist der Standardzugang www.deine-webseite.de/phpMyAdmin. Damit auch in diesem Szenario ein wenig Sicherheit präsent ist, ist es sehr wichtig auch den Pfad des phpMyAdmin Interfaces zu ändern und eventuell auch mit einer IP-Adressen Sperre bzw. mit einer .htaccess / .htpasswd zu schützen.

Starke und sichere Passwörter verwenden

Dies gilt nicht nur für euren WordPress Login, sondern auch für euren SSH Zugang, FTP Zugang, den MySQL Zugang und sonstiges Geschehen. Lange und sichere Passwörter sind essenziell und sollten viele Sonderzeichen erhalten. Ein kurzes dreistelliges oder sechsstelliges Passwort, welches lediglich aus kleingeschriebenen Buchstaben besteht, ist höchstwahrscheinlich leichter zu knacken, als ein zwölfstelliges mit diversen Sonderzeichen, sowie großen und kleinen Buchstaben.

Quintessenz

Sollten all diese Fakten Rücksicht worden sein, so ist eure Webseite relativ sicher und nicht mehr so kinderleicht anzugreifen. Natürlich kann das gesamte Geschehen noch weiter ausgebaut werden und noch viele weitere Dateien und Regeln lassen sich in die Php, Nginx oder .htaccess Dateien einbinden. Unsere aufgeschlüsselten Hinweise bieten eine gute Basis und einen leichten Schutz gegen diverse Angreifer.

Niemand kann garantieren, dass euer System nicht irgendwann einmal doch kompromittiert wird. Es können wie bereits erwähnt einige dieser vorgeschlagenen Hinweise eingebaut werden, sodass der Angreifer ein schwieriges Spiel mit eurer Webseite / eurem Server hat. Sollte es doch einmal passieren, dass ein Angreifer durchdringt und euer System übernehmen kann, so ist ein sauberes Back-up essenziell. Es kann dann ganz unproblematisch wieder eingespielt werden und es ist dann sehr wichtig zu wissen, wie der Eindringling euer System übernehmen konnte, sodass diese Schwachstelle sofort repariert und gefixt wird, da ihr ansonsten der Gefahr ausgesetzt seid, dass das Ereignis erneut eintrifft.

Wir hoffen, dass wir die eine oder andere Lösung bzw. einen nützlichen Tipp zurücklassen konnten, sodass eure WordPress Instanzen nun ein wenig mehr Sicherheit gegen etwaige Angreifer und Hacker bietet. Selbstverständlich existieren im Internet auch diverse Plugins, welche diese Funktionen teilweise bereitstellen. Hier ist es sehr empfehlenswert sich gründlich zu belesen und gegebenenfalls in die Dateien hereinzuschauen, um zu sehen was diese wirklich blockieren und was nicht.

Ebenfalls können wir noch einmal die Dienste von Cloudflare wärmstens empfehlen, da dieser Cloud-Dienstleister sehr effektive Mechanismen entwickelt hat, sodass die Angreifer rechtzeitig erkannt werden und gar nicht erst bis hin zur Webseite durchdringen.

Das Team von Fevarus Design.