Rund eine Million WordPress-Blogs wurden seit Beginn der Coronakrise 2020 fast unbemerkt mit Schadcodes infiziert. Wer keine Firewall vorgeschaltet und weitere Sicherheitsmaßnamen getroffen hat, durfte das Nachsehen haben. Es wird Zeit für Teil 2 meiner WordPress-Hilfe-Reihe. Heute gebe ich weitere Tipps mit an die Hand, wie man seine WordPress-Website vor Cyberangriffen schützen kann.
Hinweis: Die nachfolgenden Tipps richten sich wie bisher ausschließlich an WordPress.org-Nutzer (nicht: WordPress.com), die sich mit FTP-Programmen auskennen.
Wichtig: Zuerst WordPress und Plugins aktualisieren sowie Backup machen, bevor Sie starten (siehe Teil 1)!
Im ersten Teil meiner WordPress-Hilfe-Reihe habe ich bereits grundlegend erklärt, wie wichtig es ist, bereits beim Einrichten von WordPress einen ungewöhnlichen Benutzernamen und ein sicheres Passwort zu wählen, in der wp-config.php Sicherheitsschlüssel einzurichten und in der .htaccess Sicherheitsregeln anzulegen. Absolutes „Must-have“ ist auch, die PHP-Version auf dem neuesten Stand zu halten. Diese grundlegenden Maßnahmen dürften jedem bekannt sein, der bereits Einstellungen über den Account des Providers und über ein FTP-Programm vorgenommen hat.
In diesem Artikel, der sich nahtlos an den ersten anschließt, gebe ich weitere Tipps zur WordPress-Sicherheit. Los geht’s:
TIPP 6: SFTP – SSH File Transfer Protocol einrichten
Wer mit einem FTP-Programm, in meinem Beispiel „FileZilla“ (das man sich kostenlos auf der filezilla-project.org Downloadseite für Windows, Mac OS und Linux herunterladen kann), WordPress-Dateien von der Festplatte auf den Webserver überträgt oder umgekehrt herunterlädt, dem empfehle ich, dies über eine verschlüsselte Verbindung zu tun. Hierzu ist ein sogenannter „SSH-Zugang“ erforderlich.
Dazu muss man wissen, dass die Einrichtung bei einigen Providern nur funktioniert, wenn der SSH-Zugang über das Hauptverzeichnis (das oberste Verzeichnis „/“ der Internetpräsenz) abgerufen wird. Es nützt also nichts, im Servermanager von FileZilla das Protokoll einfach von „FTP“ auf „SFTP“ umzustellen, wenn im Servermanager die Website so angelegt wurde, dass sie auf ein Unterverzeichnis (z.B. „/meinedomain“) leitet. Klickt man auf „Verbinden“, würde in diesem Fall eine Fehlermeldung erscheinen, dass keine Verbindung möglich ist.
NACHTEIL: Verbindet man sich – mit verschlüsseltem SSH-Zugang (SFTP) – direkt über das Hauptverzeichnis, muss das entsprechende Unterverzeichnis bei jedem Änderungsvorhaben extra aufgerufen werden (z.B. durch Doppelklick auf das Unterverzeichnis „/meinedomain“). Aber die Sicherheit überwiegt in diesem Fall.
WordPress-Nutzer, die ihren Blog „ganz normal“ im Hauptverzeichnis und nicht in einem Unterverzeichnis angelegt haben, betrifft es natürlich nicht.
Soweit zur Theorie. Nun zur Praxis:
Liegen die WordPress-Daten im Hauptverzeichnis, braucht man im Servermanager von FileZilla einfach auf dem Reiter „Allgemein“ das „Protokoll:“ lediglich von „FTP – File Transfer Protocol“ auf „SFTP – SSH File Transfer Protocol“ umstellen. Fertig. Schon müsste es mit der verschlüsselten Verbindung klappen.
Wer seine WordPress-Daten in einem Unterverzeichnis zu liegen hat, gut so, kann auch so bleiben. Aber im Servermanager von FileZilla sollte der Server-Eintrag im linken Fenster gelöscht und anschließend ein „Neuer Server“ (dem man einen eigenen Namen vergeben sollte, in meinem Beispiel „Hauptverzeichnis“) angelegt werden.
Jetzt benötigt man folgende Daten, die man im Account des Providers bzw. Webhosters einsehen kann:
- Bezeichnung „Haupt-FTP-Verzeichnis“ (z.B. ftp00000-11111)
- Passwort des Haupt-FTP-Verzeichnisses (haben Sie selbst vergeben)
- Bezeichnung Server Host des Providers (z.B. strato.xxx.de)
Die Bezeichnung des Haupt-FTP-Verzeichnisses und die Bezeichnung des Servers bzw. Hosts überträgt man in den Servermanager von FileZilla, aber nicht das Passwort! Auf dem Reiter „Allgemein“ stellt man das „Protokoll:“ auf „SFTP – SSH File Transfer Protocol“ und die „Verbindungsart:“ auf „Nach Passwort fragen“. Alle anderen Einstellungen bleiben so, wie sie sind.
Zur Vereinfachung füge ich an dieser Stelle einen Screenshot ein:
Wenn man nun auf „Verbinden“ klickt, fragt der Servermanager von FileZilla nach dem Passwort des Haupt-FTP-Verzeichnisses. Und das jedes Mal, wenn man über das FTP-Programm auf die WordPress-Daten, die sich auf dem Webserver befinden, zugreifen will.
Neben der verschlüsselten SFTP-Verbindung greift somit eine zweite Sicherheitsmaßnahme. Sollte sich jemand unbefugt Zugriff zur Festplatte des Computers verschafft haben, braucht er das Passwort, um auf die Daten des Webservers zuzugreifen (welches selbstverständlich in einer geschützten Datei untergebracht sein sollte, worauf nur Sie Zugriff haben).
Apropos Datenübertrag:
TIPP 7: Fehlermeldung FileZilla „Datenübertrag nicht möglich“ beseitigen
Wenn beim Versuch, WordPress-Daten vom Webserver auf die Festplatte des Computers zu übertragen, im FTP-Programm FileZilla die Fehlermeldung erscheint „Datenübertrag nicht möglich“, liegt das oft daran, dass zu lange Dateinamen vergeben wurden (z.B. bei Bilddateien) und/oder UTF-8 Unicodezeichen „nicht richtig übersetzt“ werden beim Download.
Dieser Tipp hat zwar nichts mit Sicherheit zu tun, beugt aber Datenverlust vor, zum Beispiel bei Backups bzw. Sicherungen, die von Hand ausgeführt werden. Selbst habe ich letztes Jahr lange nach einer Lösung gesucht und bin im Netz fündig geworden. Einfach wie folgt vorgehen:
- Erstellen Sie ein Verzeichnis (einen Ordner) auf Ihrer Festplatte und vergeben Sie einen Namen, den Sie FileZilla zuordnen können, zum Beispiel „Standardverzeichnis_FileZilla“.
- Übertragen Sie den Namen des Verzeichnisses (Ordners) inklusive Laufwerksbuchstaben im Servermanager von FileZilla im Reiter „Erweitert“ unter „Lokales Standard-Verzeichnis“ (bzw. klicken Sie daneben auf „Durchsuchen“) und
- stellen Sie den Server-Typ auf „Standard (Automatische Erkennung)“ ein.
Zur Verdeutlichung hier ein Screenshot:
Sobald eingerichtet, springt FileZilla jedes Mal, sobald auf „Verbinden“ geklickt, automatisch auf das Standardverzeichnis der Festplatte.
VORTEIL: Jetzt können die Daten vom WordPress-Verzeichnis direkt ins Standardverzeichnis heruntergeladen werden – ohne Datenverlust und ohne Fehlermeldung!
Sollten Sie in FileZilla einmal ein anderes Verzeichnis auf der Festplatte ausgewählt haben, kein Problem. Wählen Sie einfach wieder das erstellte Standardverzeichnis aus und schon lassen sich die Daten in dieses Verzeichnis verlust- und fehlerfrei downloaden.
NACHTEIL: Die WordPress-Daten, die ins Standardverzeichnis heruntergeladen wurden, müssen im Anschluss an einen anderen Platz auf der Festplatte geschoben werden, damit sie beim nächsten Download mit FileZilla nicht überschrieben werden. Das macht man am besten mit Alles Auswählen / Ausschneiden / Einfügen, um wiederum Datenverlust zu vermeiden.
Jetzt geht’s aber weiter mit meinen WordPress-Sicherheitstipps:
TIPP 8: Alle Einstellungen, die in die .htaccess gehören
Ein paar Kniffe, wie man mithilfe der .htaccess-Datei Cyberangriffen bei WordPress-Blogs vorbeugen kann, hatte ich bereits im ersten Teil ausgeführt. Aufgrund der vermehrten Angriffe auf WordPress-Seiten in jüngster Zeit gehe ich nun sehr viel tiefer in die Materie und verrate Ihnen sämtliche Codes, die meines Erachtens aktuell in die .htaccess gehören (selbstverständlich alle Angaben ohne Gewähr – wenn Sie unsicher sind, lassen Sie dies bitte von einem Fachmann oder einer Fachfrau *gg* wie mich erledigen).
Kopieren Sie einfach die jeweiligen Codes in Ihre .htaccess-Datei (ohne die darüber befindlichen Erläuterungen!), beginnend UNTER der Zeile „# END WordPress“. Lassen Sie zwischen jedem Code nur eine Leerzeile Abstand in der .htaccess. Los geht’s:
Mit diesem Code schützen Sie die wp-config.php vor fremdem Zugriff:
# protect wpconfig.php
<files wp-config.php>
Order deny,allow
deny from all
</files>
Mit diesem Code schützen Sie die install.php vor fremdem Zugriff:
# protect install.php
<files install.php>
Order allow,deny
Deny from all
</files>
Mit diesem Code schützen Sie die readme.html vor fremdem Zugriff (diese wird bei jedem Update von WordPress automatisch neu ins Webverzeichnis geladen, löschen nützt nichts):
# protect readme.html
<files readme.html>
Order Allow,Deny
Deny from all
Satisfy all
</Files>
Mit diesem Code schützen Sie die liesmich.html vor fremdem Zugriff (auch diese Datei wird bei jedem Update der deutschen Version von WordPress automatisch ins Webverzeichnis geladen, löschen nützt nichts):
# protect liesmich.html for DE Edition
<Files liesmich.html>
Order Allow,Deny
Deny from all
Satisfy all
</Files>
Klingt komisch, ist aber so. Mit diesem Code schützen Sie die .htaccess vor fremdem Zugriff auf die .htaccess:
# protect .htaccess
<files ~ "^.*\.([Hh][Tt][Aa])">
order allow,deny
deny from all
satisfy all
</files>
Mit diesem Code schützen Sie den Ordner wp-includes vor fremdem Zugriff:
# protext wp-includes
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
Damit die Firewall (siehe TIPP 9) nicht laufend Fehler-logs erstellt, eignet sich dieser Code:
# No error log access
<files error_log>
Order allow,deny
Deny from all
</files>
Wie die Bezeichnung hinter der Raute vermuten lässt, mit diesem Code wird die „X-Powered-by“-Angabe im Header von WordPress entfernt (was der Angreifer nicht weiß, macht ihn nicht heiß):
# X-Powered Header entfernen
<IfModule mod_headers.c>
Header always unset x-powered-by
</IfModule>
Lästige Anfragen von „ReallyLongRequest“ – und davon gibt es viele – unterbindet man mit diesem Code. Positiver Nebeneffekt: Kann für etwas mehr Speed sorgen:
# Anfragen unterbinden von ReallyLongRequest
<IfModule mod_rewrite.c>
RewriteCond %{REQUEST_METHOD} .* [NC]
RewriteCond %{THE_REQUEST} (YesThisIsAReallyLongRequest|ScanningForResearchPurpose) [NC,OR]
RewriteCond %{QUERY_STRING} (YesThisIsAReallyLongRequest|ScanningForResearchPurpose) [NC]
RewriteRule .* - [F,L]
</IfModule>
Auch mit diesem umfassenden Code (Browser-Caching, Gzip-Kompression und alte Browser bugs eliminieren) kann etwas mehr Dampf rausgeholt werden. Wobei ich mir bei den Jahres- und Monatsangaben noch unsicher bin. Aber Probieren geht über Studieren:
#Browser-Caching aktivieren
<IfModule mod_expires.c>
ExpiresActive On
# Images
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType image/x-icon "access plus 1 year"
# Video
ExpiresByType video/mp4 "access plus 1 year"
ExpiresByType video/mpeg "access plus 1 year"
# Audio
ExpiresByType audio/mp3 "access plus 1 year"
ExpiresByType audio/mp4 "access plus 1 year"
ExpiresByType audio/mpeg "access plus 1 year"
# CSS, JavaScript
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
# Others
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
</IfModule>
## Gzip Kompression aktivieren
<IfModule mod_deflate.c>
# Compress HTML, CSS, JavaScript, Text, XML and fonts
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
AddOutputFilterByType DEFLATE application/x-font
AddOutputFilterByType DEFLATE application/x-font-opentype
AddOutputFilterByType DEFLATE application/x-font-otf
AddOutputFilterByType DEFLATE application/x-font-truetype
AddOutputFilterByType DEFLATE application/x-font-ttf
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE font/opentype
AddOutputFilterByType DEFLATE font/otf
AddOutputFilterByType DEFLATE font/ttf
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE image/x-icon
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/xml
# Remove old browser bugs
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
Header append Vary User-Agent
</IfModule>
## END Gzip Kompression aktivieren
Wer möchte, kann mit diesem Code noch verhindern, dass Nutzernamen ausgelesen werden:
# protect author
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} .*author=(.+.?) [NC]
RewriteRule (.*) /blog/?author= [NC,L,R=301]
In der letzten Zeile sollte dieser Code stehen, damit die .htaccess nicht etwa in irgendwelchen Suchmaschinen auftaucht (WICHTIG: hinter den Angaben darf kein Leerzeichen vorhanden sein und darunter keine Leerzeile!):
Options -Indexes
TIPP 9: Sehr wirksame Firewall für WordPress
Alle Blogs beziehungsweise Websites, die mit WordPress erstellt wurden, benötigen eine Firewall gegen unliebsame Cyberattacken. Eine Ausnahme können WordPress-Websites sein, die über sogenannte „Managed WordPress Hoster“ laufen – also Hosting-Anbieter, die Ihre installierte WordPress-Website gegen Gebühr im Hintergrund am Laufen halten (z.B. die Ladezeit verringern, Angreifer abwehren, bevor sie die Website erreichen, die Plugins aktualisieren und vieles mehr). Wenn Sie Ihre Website aber alleine mit WordPress erstellt haben und pflegen, ist das Installieren einer Firewall ein Muss. Doch welche ist die richtige, welche am wirksamsten?
Sparen Sie sich das mühsame Suchen und Ausprobieren von Firewall-Plugins! Nach jahrelangen Erfahrungen mit groß angepriesenen Plugins, die selten das bieten, was sie versprechen (und wenn, sind sie zu kostspielig), lautet meine Empfehlung: Installieren Sie die folgenden wirksamen Plugins von „Perishable Press“ (betrieben von dem geschätzten „Fullstack“-Entwickler Jeff Star – alle Infos siehe https://perishablepress.com):
- BBQ Firewall – einfach installieren und aktivieren. Keine Einstellungen erforderlich. Funktioniert mit allen WordPress-Plugins und Themes. BBQ Firewall ist ein leichtes, superschnelles Plugin, das Ihre Website vor einer Vielzahl von Bedrohungen schützt und die Website nicht unnötig belastet. Es überprüft den gesamten eingehenden Datenverkehr und blockiert stillschweigend fehlerhafte Anforderungen.
- Blackhole for Bad Bots – schützt Ihre Website vor schlechten Bots, Spammern, Scrapers, Scannern und anderen automatisierten Bedrohungen. Nach dem Installieren und Aktivieren des Plugins findet man unter dem Reiter „Settings“ einen Code, der in die robots.txt eingefügt werden muss, sofern Sie diese nicht von WordPress automatisch generieren lassen. Außerdem bietet das Plugin die Möglichkeit, einen jeweils umfassenden Bericht über die blockierten Bots an die eigene E-Mail-Adresse senden zu lassen (einfach „Enable email alerts“ auswählen und zwei Mal untereinander die gleiche Mailadresse eintragen. Unter „Message Display“ und „Message Custom“ können Sie auswählen, ob Sie die vorgegebene Warnmeldung an die Bots senden („Default Message“ – „You have been banned from this site“) oder eine eigene kreieren wollen. Als wichtigste Einstellung ist „Whitelisted Bots“ zu nennen. Hier tragen Sie – durch Komma getrennt – alle Bots ein, die Sie zulassen wollen (z.B. „Googlebot, Mediapartners-Google, twitterbot“ etc.). Somit werden alle Bots ausgesperrt, die Sie nicht in die Whitelist eingetragen haben. Auf den Button ÄNDERUNGEN SPEICHERN klicken, fertig. Jetzt arbeitet „Blackhole for Bad Bots“ für Sie. Unter dem Reiter „Bad Bots“ finden Sie ein Fenster, in dem die Bots aufgelistet werden, die geblockt wurden.
Beide WordPress-Firewall-Plugins sind kostenlos, arbeiten superschnell im Hintergrund, werden von „Perishable Press“ ständig aktualisiert und arbeiten nach Aussage des Betreibers DSGVO-konform. Andere Firewall-Plugins sind damit meines Erachtens unnötig.
Für diejenigen, die bemerkt haben, dass ich den „7G-Firefall“-Code aus der obigen .htaccess-Liste entfernt habe, ist anzumerken: Nachdem mir aufgefallen ist, dass Perishable Press den Code öfters aktualisiert, halte ich es für sinnvoller, das Plugin „BBQ Firewall“ zu installieren, da es bereits die Regeln aus der 6G- und 7G-Firewall enthält. So muss man nicht ständig auf der Website des Anbieters vorbeischauen, ob es eine neue Version gibt, und den Code in der .htaccess-Datei nicht jedes Mal entsprechend anpassen.
Last but not least: Unterstützen Sie Jeff Star in seiner täglichen Entwicklungsarbeit, indem Sie beispielsweise Pro-Plugins kaufen oder hilfreiche Bücher. Einziges Manko: Alle Informationen sind auf Englisch verfasst. Fortgeschrittene WordPress-Nutzer wird das nicht abschrecken, Anfänger und Semi-Professionals vielleicht schon. Aber dafür bin ich ja da. Fragen Sie mich einfach, wenn Sie etwas nicht verstehen.
Wie man das Hotlinking von Bildern verbietet (unter anderem mit einem Code in der .htaccess), habe ich bereits ausführlich in Teil 1 unter „TIPP 3: Einbetten von Bildern auf fremden Webseiten vereiteln“ erklärt. Auch im Übrigen empfehle ich, erst Teil 1 meiner WordPress-Hilfe-Artikel zu lesen, bevor Sie sich an Teil 2 heranwagen. 😉
So, das war’s für heute. Selbstverständlich habe ich noch zahlreiche weitere Tipps auf Lager. Sobald ich Zeit finde, geht’s an Teil 3.
Ich hoffe, ich konnte auf ein Neues zur Sicherheit Ihrer Website beitragen. Eine Garantie gegen Cyberangriffe ist auch dieser Inhalt nicht, aber ein weiterer guter Schritt, um es den Angreifern so schwer wie möglich zu machen, an Ihre Daten zu gelangen, was letztlich den Besuchern Ihres WordPress-Blogs und Ihren Kunden zugute kommen kann.
Alle WordPress-Tipps jetzt auf ROCK DEINEN PC!
Seit August 2021 blogge ich Tipps und Anleitungen zu WordPress.org sowie zu Microsoft Windows ausschließlich auf meinem neuen Blog www.rock-deinen-pc.de und freue mich über Ihren Besuch. 🙂