Schlagwort-Archive: WP

htaccess und Dynamische IP Adressen

Der Apache Webserver ermöglicht die Zugriffsteuerung über htaccess, auch um Autorisierten Zugang auf Webseiten zu ermöglichen. Mit der Apache direktive Allow from ist es möglich eine bestimmte IP von der Anmeldeaufforderung auszuschliessen. Dabei ist die Übergabe von Hostnamen und FQDN leider nicht möglich. Anhand des folgenden Scriptes wird die Dynamische IP eines Hostname ausgelesen und in die htaccess-Datei eingetragen.

Der Shell Script zur Auflösung der IP Adresse und schreiben in die htaccess-Datei. Die folgenden Zeilen in der Konsole mit copy & paste einfügen, dies erzeugt den Shell Script.

 Copy Paste

Der Script schreibt hier auf einem CentOS Host die htaccess-Datei um. Bei Zeile Allow from mit der Marke #DDNS wird der Hostname ausgelesen, auf der nächsten Zeile mit der Marke #DDNS-IP wird die aufgelöste IP des Host geschrieben. Die Pfad Variable htpath kann DocumentRoot oder ein Unterverzeichnis sein, dabei bearbeitet der Script alle vorkommenden .htaccess-Dateien rekursive ab htpath.

Die htaccess-Datei wird im Webverzeichnis gespeichert dieses geschützt werden soll. Mit cd in das gewünschten Verzeichnis wechseln und die folgenden Zeilen mit copy & paste in der Konsole einfügen, dies erzeugt die .htaccess-Datei.

 Copy Paste

Die Zeilen mit #DDNS und #DDNS-IP (mit #) dienen zur Markierung.

Der Script muss noch  ausführbar gemacht werden.

Damit die Auflösung der Dynamischen IP laufend aktualisiert wird, kann mit crontab -e ein Cron job erstellt werden.

Nach restart des Cron Daemon ist der job aktive.

Hinweis:
Ab Apache 2.4 lautet die direktive von zuvor Allow from nun Require.
Apache 2.x mod_access_compat

Apache 2.4 mod_authz_host

Die von mod_access_compat bereitgestellten Allow-, Deny- und Order-Direktiven sind veraltet und werden in den zukünftigen Version nicht mehr unterstützt. Es wird empfohlen die neuen Direktiven zu verwenden.

Schütze dein WordPress vor unerwünschten Login Versuche

Ein Botnet greift derzeit WordPress-Blogs weltweit an.
Der Angriff selbst ist dabei denkbar einfach, es wird versucht, sich mit „admin“ einzuloggen. Um das Passwort herauszufinden, wird schlichtweg eine entsprechende Vorlage aus tausenden Einträgen sehr schnell abgearbeitet. Es kommt deshalb bei den betroffenen Blogs in der Folge zu einer massiv erhöhten Anzahl von Login-Versuchen – „Brute Force Attack“. Was die Angriffswelle in diesem Fall so problematisch macht, ist die riesen Menge an infizierten PCs, die zum Einsatz kommt.

Gemäss Experten geht es am Ende darum, aus den Servern ein neues Botnet aufzubauen. Das wäre dann um ein Vielfaches mächtiger als das jetzige, weil die Server beispielsweise eine wesentlich bessere Internetanbindung haben als infizierte PCs.

Die wichtigsten Massnahmen um ein WordPress-Blog zu schützen.

Den Account „admin“ nach Möglichkeit ganz vermeiden. Er ist bei WordPress-Blogs so verbreitet, dass er – so wie auch in diesem Fall – als Hebel für den Angriff genutzt wird. In diesem Blog wird ebenfalls aufgezeigt, wie man den „admin“-Loginname ändert.

Eine weitere Möglichkeit ist es, den Admin-Bereich von WordPress selbst mit einem Passwort zu schützen. Ohne dieses „Master-Passwort“ kommt man gar nicht erst auf die Login-Seite fürs back-end. Das kann gerade bei Brute-Force-Attacken sehr sinnvoll sein, da der automatische Angriff sehr früh abgefangen wird und den Server dadurch weniger belastet. Auch sollte das MySQL front-end nicht über „phpMyAdmin“ oder „MyAdmin“ in der URL abrufbar sein, hier sollte ein Apache Alias oder ein Symlink, z.B. „db_manager“ angelegt werden, damit ist man aus der Schusslinie von Brute-Force-Attacken, zusätzlich schützt auch ein htaccess-Passwort.

Noch effizienter und den Server nicht belastend, wirkt sich das abfangen der Angriffe durch den Einsatz von fail2ban aus.

Dazu wird fail2ban installiert, hier bei CentOS 5.x.

Nach der Installation wird die Filter Definition für WordPress-„wp-login.php“ erstellt.

vi /etc/fail2ban/filter.d/wp-auth.conf

Und nun die jail-Konfiguration hinzufügen.

vi /etc/fail2ban/jail.conf

Die Änderungen aktivieren mit service fail2ban restart

Es wird nun die Brute Force Attacke nach 6 fehlerhaften Login-Versuche, den Zugang für eine Stunde von der Firewall blockiert, geht die Attacke nach einer Stunde weiter, beginnt die Blockierung erneut.

Denial of Service Angriff auf xmlrpc.php

Blogger und System Administratoren ist es bekannt, Bruteforce-Angriffe auf den Admin-Bereich sind sich die meisten schon gewohnt und behelfen sich mit Security-Plugins oder durch Restriktionen in der .htaccess Datei. Dabei sollte man die XMLRPC-Schnittstelle nicht ausser acht lassen, die zwei Hauptfunktionen ermöglicht: Pingback-API ermöglicht eine Vernetzung zwischen den Blogs und dient gleichzeitig als Schnittstelle, um WordPress über externe Programme verwalten zu können.

Aufgrund ihres Funktionsumfangs ist xmlrpc.php nicht nur beliebt bei den Blogger, sondern stellt auch für Angreifer ein attraktives Ziel dar, Angreifer fokussieren ihre Attacken daher zunehmend auf xmlrpc.php. Dabei kann ein DDOS-Angriff durch eine Vielzahl an Anfragen pro Sekunde den Server zur Überlastung bringen, oder durch hohe Datentraffic die dabei entsteht, das Netzwerk zum erliegen bringen.

Denial of Service Datatraffic
Denial of Service Datatraffic

Die vollständige Deaktivierung der WordPress XMLRPC-Schnittstelle geschieht über functions.php:

Wer die Deaktivierung über den Apache Webserver vornehmen will, kann dies in der /etc/httpd/conf/httpd.conf (Red Hat), bei debian /etc/apache2/apache2.conf vornehmen:

Danach den Webserver neu starten mit service httpd restart, die Überprüfung geschieht in dem die Blog-URL mit anstehender xmlrpc.php aufgerufen wird, Beispiel:

Es wird nun 403 Forbidden ausgegeben.

Wer die XMLRPC-Schnittstelle nutzen möchte, ohne auf eine Schutzmassnahme verzichten zu müssen, für den eignet sich fail2ban, das Tool untersucht und filtert Attacken aus dem Apache Protokoll und blockiert die IP-Adresse des angreifenden Host für einige Zeit, die dauer der Blockierung kann bestimmt werden, fail2ban steuert die Kernel-Firewall, in dem iptables angewiesen wird die Angreifer IP zu blockieren (DROP) und verhindert so das keine schädliche Traffic und Systemauslastung entsteht. fail2ban verhindert nicht nur das der Angreifer kein Zugriff auf die xmlrpc.php hat, vielmehr wird der Host ganz blockiert und der POST durch DROP ins leere läuft, dadurch werden auch andere mögliche Attacken verhindert, was bei den zuvor geschilderten Schutzmassnahmen nicht zutrifft.

Die Installation von fail2ban auf CentOS 5.x (Red Hat) läuft wie folgt:

Nun die fail2ban Konfiguration für das logging vornehmen mit vi /etc/fail2ban/fail2ban.conf

Die Filter Definition geschieht mit dem erstellen einer neuen Datei unter /etc/fail2ban//filter.d/apache-xmlrpc.conf und fügt dabei folgende Zeilen ein:

In der Konfigurationsdatei jail.conf den Filter unten am Dateiende einfügen, vi /etc/fail2ban/jail.conf

Nun die Änderungen aktivieren mit service fail2ban restart

Überprüfen wie fail2ban arbeitet, lässt sich anhand der Logdatei ermitteln mit tail -f /var/log/fail2ban.log, falls bereits DDOS-Angriffe stattgefunden haben, wird die Eingabe iptables -vnL | grep fail2ban die Source-IP der geblockten Hosts ausgeben.

WordPress-Blog vor Attacken schützen

WordPress erfreut sich grösster Beliebtheit bei Bloggern. Aufgrund der hohen Verbreitung im Web ist es auch gleichzeitig ein beliebtes Angriffsziel. Aktuell vermehren sich Hinweise und Meldungen über Botnetze welche WordPress-Blogs weltweit attackieren.

Dieser Beitrag beschreibt die Absicherung der WordPress-Installation um gegen Angriffe zu schützen, einige einfache Massnahmen die jeder umsetzen kann.

Angreifer gehen fast immer nach dem selben Muster vor. Anhand von automatisierten Tools wird versucht Zugang in schlecht geschützte Bereiche zu erlangen oder nutzt Schwachstellen in WordPress und Plugins um Schadcode einzuschleusen.

logwatch - httpd brute-force attachs
logwatch – httpd brute-force attacks

Brute-Force Angriffe werden vom Webserver geloggt und durch Logwatch ausgewertet.

WordPress 4 bietet die Möglichkeit bei einer Neuinstallation einen individuellen Benutzernamen anzulegen. Frühere WordPress Versionen legten noch automatisch den Benutzer Admin an. Damit hatte man bereits schon das erste Sicherheitsleck.

Möchte ein Angreifer Zugang zum System erlangen verwendet er meist Benutzernamen wie admin, Administrator oder root, Namen die üblicherweise für Logins die über erhöhte Rechte verfügen. Ändert man Standard Benutzernamen, erschwert dies einem Angreifer den Zugriff. Er benötigt neben dem korrekten Passwort nun auch noch den Benutzername. Dieser Umstand gilt nicht nur für WordPress sondern für alle Systeme die Authentifizierung aus dem Internet ermöglichen.

Benutzt Du den Admin für deine Postings ?

Folgende schritte helfen ein WordPress-Blog vor Angreifer zu schützen. An dieser stelle sei noch erwähnt das jetzt der richtige Zeitpunkt ist ein aktuellen Backup anzulegen.

  1. Im WordPress Dashboard unter Benutzer legt man ein zusätzlichen Admin an. Verwendet dabei einen Benutzername wie zum Beispiel superadm-blog14.
  2. Danach wieder abmelden.
  3. Mit diesem soeben erstellen Admin wieder anmelden.
  4. Zusätzlich legen wir einen weiteren Benutzer an, dieser mit der Rolle Autor.
  5. Anschliessend löscht man den Benutzer mit dem Name Admin. Beim Löschvorgang fragt WordPress was mit den Beiträgen des Benutzers Admin passieren soll, jetzt überträgt man alle Beiträge an den neu angelegten Benutzer mit der Rolle Autor.

WordPress Benutzer Loeschen

Von nun an erstellt man alle Beiträge mit dem neu angelegten Autor. Der Admin-Account „superadm-blog14“ dient lediglich für die Wartung und Verwaltung von WordPress.

Die jetzt publizierten oder kommentierten Beiträge erscheinen lediglich mit dem Benutzername des Autors. Es wird damit vermeiden dass der Admin-Account irgendwo auf der Seite erwähnt wird oder über einen Link abgreifbar ist, ein Angreifer soll keine Informationen finden. Nun muss er neben dem Passwort auch noch alle möglichen Kombinationen von Benutzernamen durchprobieren, bevor er sich Zugriff in den Admin-Bereich verschaffen kann. Somit laufen die meisten Angriffsversuche ins Leere, der Benutzer admin existiert nicht.

Damit nun bei Brute-Force Attacken der Benutzername des Autors in den Beiträgen und in den Links nicht preisgegeben wird, muss noch eine Anpassung in der SQL-DB vorgenommen werden, da WordPress standardmässig der Name bei user_login auch bei user_nicename verwendet, wird hier der Name im SQL geändert, der Name der bei user_login steht, soll nicht der selbe wie bei user_nicename sein, da dieser in den Links vorkommt, somit wird mit phpMyAdmin unter wp_user der Name im Feld user_nicename editiert und mit dem Name des Feldes display_name ersetzt, dies bedeutet auch das man als display_name nicht jener von user_login verwendet.

wp_users _ phpMyAdmin

Weiter sichert das LockDown Plugin vor Angriffe, dieses blockiert IP-Adressen von diesen eine erhöhte Anzahl fehlgeschlagene Logins gemacht wurde.

lockdown_1

Standardmässig lässt WordPress bei fehlerhaften Anmeldeversuche einem nicht im ungewissen, ob man gerade das Passwort für ein existierenden Benutzer eingegeben hat, mit der LockDown Option Mask Login Errors lässt sich verhindern das bei fehlerhaften Anmeldeversuche sich das Passwort nicht auf den Benutzername in der Error Meldung bezieht. Invalid username or incorrect password resultiert unabhängig von falschen Benutzer oder Passwort.

invalid username or incorect password
invalid username or incorrect password
LockDown Option Mask Login Errors
LockDown Option Mask Login Errors

Natürlich wurde hier nicht alles ausgeschöpft was zur Absicherung von WordPress nötig wäre, es sol vielmehr als Arbeitsgrundlage und zur Sensibilisierung dienen, dabei wird ein Blog mit höherem Ranking und guter Bekanntheit die meisten Angriffe abwehren können. Auch spielt eine wichtige rolle wie der Webserver selbst abgesichert ist, und welche WordPress Plugins und Themes installiert sind. Das ein sicheres Passwort verwendet wird braucht an dieser stelle nicht weiter erwähnt zu werden. Zu viele Gimmicks und nicht wirklich benötigte features sollten nicht auf kosten der Sicherheit gehen, auch hier gilt, weniger ist oft mehr.

Ein weiter wichtiger Punkt abschliessend. Halte die WordPress-Installation stehts auf dem neusten Stand. WordPress macht es hier einem besonders einfach. Sicherheitsupdates für den WordPress-Core werden automatisch eingespielt, die Plugins und Themes sollten ebenfalls regelmässig aktualisiert werden.