Was zum Teufel ist “Snake Oil”? Schauen wir dazu auf die Begriffsdefinition in Wikipedia:
Schlangenöl (aus dem Englischen snake oil) ist die spöttische Bezeichnung für ein Produkt, das wenig oder keine echte Funktion hat, aber als Wundermittel zur Lösung vieler Probleme vermarktet wird.
Schaut man sich viele Ratgeber an, so greifen die meisten viel zu kurz. Es ist leider nicht mit der Installation eines Security-Plugins oder dem setzen einzelner Parameter getan. Auch Methoden wie z.B. das Login via Loging Atempt Limits abzusichern sind absolut nutzlos. Diese blockieren eine einzelne IP-Adresse, wenn sich diese zu oft falsch einloggt. Hacker greifen WordPress Systeme aber nicht mit einem System an, sondern mittels Botnetzen – da kommt jeder Login von einer anderen Adresse und dieser Mechanismus läuft ins Leere! Auch Security Plugins bieten keine echte Sicherheit. Diese können zwar bedingt helfen, indem Sie einfache Angriffe abwehren, aber sind allerhöchstens eine Ergänzung zu den wirklich wichtigen Maßnahmen. Echte WordPress Sicherheit baut auf zahlreiche einzelne Bausteinen auf!
In diesem Artikel möchte ich meine Strategie zum Thema Sicherheit in WordPress darstellen.
Am besten schaut man sich an, wie die meisten Einbrüche auf WordPress-Seiten vonstatten gehen – die häufigsten Gründe sind:
- Zu schwache Passwörter in Admin / User Accounts
- Veraltete WordPress-, Theme- oder Plugin-Versionen
- Von außen erreichbare WordPress Dateien
- SQL-Injektion (z.B. über Formulare)
- Brute-Force Attacken auf das WordPress Login
- Brute-Force Attacken auf die XMLRPC Schnittstelle
Gehen wir mal darauf ein, wie sich diese Probleme adressieren lassen, bzw. wie ich das handhabe.
- Administrative Zugriffe und Passwörter / Brute-Force Attacken auf den Login-Bereich
Der wichtigste Schutz überhaupt ist der des WordPress Login Bereiches! Generell vergebe ich keine Administrationsrechte an Kunden, es sei denn, es ist technisch nicht anders möglich. Jeder Adminzugang ist neben dem Zwang zu langen Passwörtern mindestens mit einer obligatorischen 2-Faktor Authentifizierung [1] abgesichert. Bei allen neuen Webseiten, bei denen keine Anmeldung normaler Besucher notwendig ist (z.B. bei Shop-Systemen oder Foren) setze ich das WebAuthn Plugin ein und konfiguriere dies so, dass eine Anmeldung ausschließlich mit einem Passkey [2] möglich ist. Weiterhin wird bei diesen Systemen die Login-URL auf einen anderen Pfad gesetzt. Letzteres erhöht die Sicherheit zwar nur marginal, ist aber ein valider Baustein zur Absicherung des Logins, auch wenn dies einen erfahrenen Hacker nicht wirklich abhält.
Zusätzlich unterbinde ich das Scannen nach Benutzernamen innerhalb von Seiten und Beiträgen durch entsprechende .htaccess Direktiven. - Veraltete WordPress Komponenten
Wichtig ist es, die WordPress-Komponenten (neben dem WordPress Kernsystem, vor allem die Plugins und Themes) aktuell zu halten. Dies geschieht bei mir zum einen über eine automatische Updatefunktion, die für alle Komponenten eingestellt ist, aber auch händisch, sollte dringender Updatebedarf bestehen. Letzteres kommt immer dann vor, wenn eine Sicherheitslücke bekannt wird, da möchte man nicht darauf warten, dass der automatische Update irgendwann einmal diesen durchführt. Die Benachrichtigung einer solchen kritischen Sicherheitslücke geschieht zum einen durch eine Alarmierung des eingesetzten Sicherheitsplugins Ninja Firewall, aber auch durch das Verfolgen einschlägiger Quellen im Internet. Die händische Installation erfolgt in einem solchen Fall zentral über die MainWP [3] Konsole. - Von außen erreichbare WordPress Dateien
Wichtig ist es, spezielle Dateien und Verzeichnisse von einem Zugriff von außen zu schützen. Dazu werden diese in der .htaccess Datei [4] mittels spezieller Direktiven geschützt. - SQL- Injections
Zur Vermeidung von SQL-Injections sollte in erster Line darauf geachtet werden, nur bekannte, solide und gut gewartete Plugins einzusetzen. Weitere Absicherung geschieht bei mir über spezielle Direktiven in der .htaccess Datei. - Abschaltung der XMLRPC Schnittstelle
Die WordPress XMLRPC Schnittstelle ist ein bekanntes Einfallstor in WordPress. Die XML-RPC wurde entwickelt, um die Kommunikation zwischen verschiedenen Systemen zu standardisieren. Anwendungen außerhalb von WordPress, wie z.B. Blogging-Plattformen und Desktop-Clients, können so mit WordPress Daten austauschen. Mittlerweile wurde diese durch eine Rest-API ersetzt und wird daher bei mir komplett deaktiviert
Zusätzlich zu den erwähnten Absicherungen werden noch weitere Maßnahmen zur Absicherung getroffen, wie z.B. das Setzen von HTTP-Security Headern sowie spezielle Absicherungen innerhalb der .htaccess Datei.
Fazit: Einen 100% Schutz vor erfolgreichen Angriffen kann es nicht geben, man kann aber durch geeignete Maßnahmen viel dazu beitragen, es den Hackern nicht allzu leicht zu machen!
