WordPress Sicherheit Teil 2 – Tipps, wie man den Blog vor Angreifern schützt

Mit ein paar Codes kann man WordPress (.org) auch ohne Plugins sicherer machen – Symbolbild: Collage von pixabay-Bildern CC0

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:

Beispiel zur Einrichtung eines SSH-Zugangs in FileZilla – Screenshot: Namira McLeod

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:

Beispiel zur Einrichtung eines Standardverzeichnisses in FileZilla – Screenshot: Namira McLeod

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:


Bei dem ersten Code handelt es sich um eine sehr wirksame Firewall von Perishable Press (betrieben von keinem geringeren als Jeff Star), die ohne Plugins auskommt. Alle Informationen in englischer Sprache findet man unter https://perishablepress.com. Sollten Sie bereits eine wirksame Firewall in WordPress installiert haben, lassen Sie den Code bitte weg oder deinstallieren Ihre Firewall und fügen die folgenden Zeilen in die .htaccess ein:

# 7G Addon: Stop Aggressive Scanning for Uploads-Related Targets

# https://perishablepress.com/stop-aggressive-scanning-uploads/

<IfModule mod_rewrite.c>

 

            # 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} /(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]

           

</IfModule>

 

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


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.

Brauchen Sie Hilfe?

Gern unterstütze ich Sie auf dem Weg zu mehr Sicherheit Ihrer WordPress.org-Website. Voraussichtlich in der Zeit vom 1. Juli bis 31. Dezember 2020 darf ich von Gesetzes wegen sogar nur 16 Prozent Mehrwertsteuer (statt bisher 19 Prozent) berechnen – ein echter Vorteil für Privatkunden!

Kontaktieren Sie mich!