WordPress-Seiten sind sehr beliebt, was Angriffe angeht. Das ist schon alleine deshalb so, weil WordPress (WP) auf sehr vielen Seiten genutzt wird. Laut kinsta.com liegt der Marktanteil von WP (Web-Seiten) bei derzeit 37%. Ein entsprechend hoher Marktanteil macht ein Produkt natürlich auch attraktiver für Angreifer.

Wenn du die Log-Dateien deiner Webseite durchsiehst, wirst du mit Sicherheit gescheiterte Login-Versuche, XML-Attacken und ähnliches finden. Angreifer gehen in der Regel so vor, dass sie Logins gleich mehrfach versuchen. Auf solche Mehrfach-Versuche, oder aber auch einzelne Versuche können wir reagieren: via Fail2Ban.

Was ist Fail2Ban?

Fail2Ban ist ein Linux-Tool, welches fortlaufend vordefinierte Log-Dateien prüft und auf Events reagieren kann. Das Tool überwacht die Log-Dateien mittels regulärer Ausdrücke und kann in der Folge mit IPTables- und Firewall-Regeln reagieren. Das bedeutet: erkennt das Tool beispielsweise drei Fehlerhafte Login-Versuche in Folge, wird die zugehörige IP-Adresse für eine bestimmte Zeit via IPTables gesperrt.

WordPress: Admin-Account und unbekannte Accounts

In der Default-Einstellung wirst Du einen Admin-Account namens admin in deiner WP-Installation haben. Dies ist bereits eine Information für Angreifer. Der Angreifer kennt nicht, welche Accounts auf deinem System vorhanden sind, wird aber bei den meisten WP-Systemen richtig legen, wenn er einen Benutzer admin vermutet. Daher ist es bei solchen Systemen grundsätzlich eine gute Idee, den eigenen Nickname zum Admin zu machen und auf den „admin“-Account zu verzichten, bzw. diesen zu löschen. Es ist sowieso bei fast allen Systemen besser, man verbindet nicht die Funktion (Administrator) mit dem Benutzernamen (admin).

WP-Fail2Ban: Voraussetzungen

Das WP-Plugin WP-Fail2Ban wird nur dann in deiner WP-Umgebung funktionieren, wenn die Basis-Software fail2ban auf dem Server installiert ist. Wenn auf dem Server bereits fail2ban installiert ist und für WP-Fail2Ban konfiguriert ist, reicht es aus, wenn du das Plugin einfach aktivierst.
Sollte dies nicht der Fall sein, musst Du (nach der Installation von fail2ban) die Filter-Dateien in das Standard-Verzeichnis /etc/fail2ban/filter.d kopieren (wordpress-soft.conf, wordpress-hard.conf, wordpress-extra.conf).

Das gewünschte Verhalten von WP-Fail2Ban passt du dann in der Datei jail.local an.

Um zu verhindern, dass bei Software-Updates die eigenen Anpassungen überschrieben werden, kopierst du die Datei /etc/fail2ban/jail.conf nach /etc/fail2ban/jail.local. Die Datei jail.local wird bei Updates nicht überschrieben, besitzt für das Programm allerdings eine höhere Gewichtung als jail.conf. Sprich: ist auf dem System eine Datei jail.local vorhanden, wird diese anstelle der jail.conf genutzt.

Hinweis zur Anpassung der Konfigurations-Datei jail.conf

Der Datei jail.local fügst du nun folgende Zeilen an:

[wordpress-hard]
enabled = true
filter = wordpress-hard
logpath = /var/log/auth.log
maxretry = 1
port = http,https
action  = %(action_mwl)s

[wordpress-soft]
enabled = true
filter = wordpress-soft
logpath = /var/log/auth.log
maxretry = 3
port = http,https
action  = %(action_mwl)s

Die Parameter maxretry kannst Du nach eigener Vorstellung anpassen. Diese Parameter bestimmen, wie oft sich der in den Filter-Regeln festgelegte Zustand wiederholen darf. Ein Beispiel: Ein existierender Benutzer (wordpress-soft) meldet sich am Admin-Interface mit einem falschen Passwort an: Er darf drei Mal ein falsches Passwort eingeben, bevor er geblockt wird. Versucht jemand, sich als Benutzer anzumelden, den es in der WordPress-Umgebung gar nicht gibt (wordpress-hard), so wird er gleich nach dem ersten Versuch geblockt. Die genauen Regeln sind in den o.g. Filter-Dateien beschrieben.

The post WP-Fail2Ban – Auf fehlerhafte Logins reagieren first appeared on NET73.

Kurz gesagt: Im Anschluss wirst Du Deine Projekt-Daten für Dein Template oder Plugin auf Gitlab.com ablegen und entwickelst dabei dein Projekt lokal auf Deinem Rechner. Der komplette WordPress-Code wird dabei natürlich nicht via git getrackt. PhpStorm eignet sich für die WordPress-Entwicklung sehr gut – Du kannst allerdings auch jeden anderen Editor verwenden. Dabei musst du eben die Docker-Befehle von Hand eingeben. Es ist allerdings so oder so eine gute Idee, die einzelnen Docker-Befehle manuell zumindest kennenzulernen.

Step 1: Anlegen des Gitlab-Projekts & Anlegen der Docker-Compose-Datei

Entweder nutzt Du ein neues Projekt auf https://gitlab.com oder Du legst ein neues Projekt auf Deiner selbstgehosteten Gitlab-Installation an. Im neu angelegten Gitlab-Projekt kannst Du jetzt eine neue Datei anlegen. Diese nennst Du docker-compose.yml.

Inhalt der Datei:

version: '3'

services:
  db:
    image: mysql:5.7
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: somewordpress
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  wordpress:
    depends_on:
      - db
    image: wordpress
    ports:
      - "666:80"
    restart: always
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
    working_dir: /var/www/html
    volumes:
      - ./:/var/www/html
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
volumes:
  db_data:

Erklärung:

image: Es werden hier zwei Docker-Container definiert und verbunden. Für diesen Test habe ich das Standard-Wordpress-Image genutzt. Das bedeutet, dass jeweils die aktuellste WordPress-Version gezogen wird. In den allermeisten Fällen ist dies auch am sinnvollsten – es sei denn, man möchte ein Plugin oder Theme für eine ältere WP-Version testen oder entwickeln.

volumes: Mit Volumes können Verzeichnisse aus den Docker-Containern in das lokale Verzeichnis gemountet werden. Ich lade i.d.R. das komplette WordPress-Verzeichnis in die Projekt-Root, so dass ich auch später die WordPress-Erweiterungen von PHP-Storm nutzen kann (und bei Bedarf Zugriff auf WP-Core-Dateien habe).
Es ist allerdings auch denkbar, dass Du Dir hier _nur_ Dein Plugin oder Theme in die Projekt-Root lädst, oder gar die WordPress-Installation in ein anderes Verzeichnis in der Projekt-Root lädst. Folgende Alternativen wären hier denkbar:
– ./wordpress:/var/www/html – Die WordPress-Installation ins lokale Verzeichnis wordpress laden.
– ./:/var/www/html/wp-content/plugins/myplugin – nur „myplugin“ wird in die lokale Projekt-Root geladen

Step 2: PhpStorm-Projekt anlegen, Code aus Git holen

Beim Start von PhpStorm legst Du jetzt ein neues Projekt über den Listen-Eintrag „Get from Version Control“ an. Hierbei benötigst Du die Clone-URL aus gitlab.com. Außerdem sollte dein lokaler SSH-Schlüssel in deinem Repository eingetragen sein. Alternativ fragt PhpStorm beim clonen aber auch nach Benutzernamen und Passwort – die SSH-Verbindung ist allerdings m.E. die einfachere Methode.
Im Anschluss wird das Projektverzeichnis automatisch erstellt und die Projektdatei (docker-compose.yml) in dieses Verzeichnis geladen. Nach dem Clone-Vorgang kannst Du auf „yes“ klicken – das Projekt wird jetzt via PhpStorm geöffnet („Would you like to open the directory…?“).

Als nächstes definieren wir Docker für das Projekt (Docker für Windows, Linux oder Mac solltest Du natürlich bereits installiert und gestartet haben – Standard-Einstellungen).
Über das Plus-Zeichen (siehe Screenshot oben) kannst du eine neue Docker-Konfiguration hinzufügen. Die obigen Einstellungen werden schon so automatisch ausgefüllt (funktioniert entsprechend auch unter Linux und Mac OS). Nachdem die Einstellungen wie oben passen, kannst Du den Settings-Dialog auch schon wieder per Klick auf „OK“ schließen.

Step 3: Docker-Setup starten

In den Projekt-Dateien kannst Du jetzt automatisch via Rechtsklick auf die docker-compose.yml das Docker-Setup starten. Wenn Du dies machst, passiert folgendes: Die beiden definierten Docker-Container werden gestartet und eine WordPress-Installation wird durchgeführt. Je nach Einstellung in der docker-compose.yml-Datei werden hierbei auch automatisch die notwendigen Ports gemappt. Sprich: WordPress läuft über den Webserver-Container innerhalb des Docker-Netzes. Da wir nur jeweils einen Port 80 zur Verfügung haben, aber ggf. mehrere Webservices via Docker laufen lassen, mappen wir den Port 80 einfach auf einen alternativen Port. Im Beispielsfall von oben ist dies Port 666. Die vorläufige WordPress-Grundinstallation erreichst du ab jetzt also über die URL http://localhost:666 in deinem Browser.

Wenn das Setup geklappt hat, siehst du im unteren Bereich von PhpStorm die Erfolgsmeldung „Compose: docker-compose.yml has been deployed successfully“ im Abschnitt Deploy Log. Natürlich bemerkst Du es auch dann, wenn du im Browser die WordPress-Einrichtungs-Seite unter http://localhost:666 erreichst.

Was ist noch passiert? Je nachdem, wie die Volumes-Config (siehe Step 1) aussehen, werden nun auch sämtliche WordPress-Dateien in der Projekt-Root angezeigt. Im Settings-Dialog von PhpStorm kann man jetzt also auch den WordPress-Support aktivieren.

Step 4: Was wird getrackt, was wird ignoriert?

Bereits weiter oben hatte ich schon erwähnt, dass es nicht sehr sinnvoll ist, irgendwelchen WordPress-Core-Code via git zu tracken, da dieser natürlich kontinuierlich weiterentwickelt wird und sich ggf. auch hier und da verändert.

Wichtig ist an dieser Stelle auch, dass Du am Besten gar keine WordPress-Core-Updates über das Web-Interface installierst, sondern stattdessen immer gleich ein neues Docker-Image ziehst (einfach das Setup erneut ausführen – die bestehenden Docker-Container entfernen).

An dieser Stelle kommt jetzt die Datei „.gitignore“ ins Spiel. Mit dieser Datei kannst Du Dateien aus dem Git-Tracking ausschließen. Im Grunde wollen wir alles ignorieren, außer die Verzeichnisse für unser Plugin und/oder Theme. Hinweis: Die .gitignore sollte natürlich mit ins GIT-Repository aufgenommen werden (git add .gitignore).

# filename: .gitignore
# IntelliJ project files
.idea
*.iml
out
gen
# Alles ignorieren
/*
.*
# Ausnahmen definieren
!.gitignore
!README.md
/wp-content/*
!/wp-content/themes/powermetal/

Zusatz

Für die lokale Docker-Entwicklung wird früher oder später das Problem auftauchen, dass du entweder die lokal gemounteten Dateien nicht bearbeiten kannst, oder dass du Plugins in WordPress (Docker) nicht ohne FTP-Zugang hinzufügen kannst, weil die Dateirechte nicht passen. Im Docker-Container werden die Dateirechte vom Image aus dem Benutzer und der Gruppe www-data zugewiesen. Dies kann, muss aber nicht dieselbe Benutzer-ID wie auf deinem lokalen System sein. Die Berechtigungen kannst du Anpassen, in dem du direkt auf eine Shell in den Docker-Container verbindest. Dies passiert mit dem folgenden Kommando:

docker exec -u root -it [DOCKER-ID] /bin/bash

Die [DOCKER-ID] erhältst du über das folgende Kommando:

eggi@arche ~/PhpstormProjects/pmwp $ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                  PORTS                  NAMES
4867c885db42        wordpress           "docker-entrypoint.s…"   32 hours ago        Up Less than a second   0.0.0.0:666->80/tcp    pmwp_wordpress_1
bd78c4dbe73d        mysql:5.7           "docker-entrypoint.s…"   32 hours ago        Up Less than a second   3306/tcp, 33060/tcp    pmwp_db_1

Die Docker-ID ist die Zeichenfolge in der ersten Tabellen-Spalte. In meinem Fall würde das Kommando für die Shell zum Docker-Container (wordpress) also wie folgt lauten:

docker exec -u root -it 4867c885db42 /bin/bash 

In der Shell können dann die Dateirechte beispielsweise via chmod und chown angepasst werden. WordPress befindet sich im Standard-Image im Verzeichnis /var/www/html.

The post DEV-Umgebung für WordPress mit Docker, Gitlab & PhpStorm first appeared on NET73.