⚠️ Achtung — Risiko bei öffentlichen Dev-Hosts

Wenn du Entwicklungs- oder Testserver (z. B. per DynDNS / no‑ip + Portforward) öffentlich erreichbar machst, laufen automatisierte Scanner und Bots dauerhaft durchs Netz. Wird deine WordPress‑Instanz kompromittiert (fremde Plugins, Webshells, Backups im Webroot), handle sofort: isolieren, Beweise sichern, Schlüssel rotieren, bereinigen.

Dieses How‑To ist für eigene Systeme gedacht. Führe Befehle nur auf Geräten aus, die du kontrollierst.

Kurz-Einleitung (1‑Satz)

Dieses Dokument fasst Schnellmaßnahmen (Contain, Collect, Clean), forensische Prüfungen, WordPress‑Cleanup, Firewall‑ & Fail2Ban‑Basics und langfristige Härtung zusammen — copy & paste‑fähig für MarsEdit.

Sofortmaßnahmen (Containment)

1. Isolieren: Portforwarding im Router sofort deaktivieren; Maschine vom Netz trennen oder UFW/Firewall hart schließen.

# Beispiel: alle eingehenden Verbindungen sperren (Linux/UFW)
sudo ufw default deny incoming
sudo ufw enable

1. Wichtige Schlüssel & Passwörter rotieren

• SSH‑Keys erneuern (Clients & Server).
• WP‑Admin, DB‑Benutzer, Hosting‑Passwörter ändern.

1. Beweise sichern (offline)

# Beispiel: gesamtes Webroot archivieren (auf externes Laufwerk)
cd /Users/andy/Programmierung
tar -czf /Volumes/BackupDrive/codekeks-infected-$(date +%F).tgz codekeks.test
# Apache / MAMP Logs sichern
cp /Applications/MAMP/logs/* /Volumes/BackupDrive/codekeks-logs-$(date +%F)/ || true

1. Kein Neustart/kein Aufräumen, bevor gesicherte Kopien erstellt sind (für Forensik).

Erste Forensik-Checks (Copy/Paste)

Auf dem Mac mini (MAMP Pro):

tail -n 200 "/Applications/MAMP/logs/apache_error.log"
tail -n 200 "/Applications/MAMP/logs/apache_ssl_error.log"
lsof -i -nP | grep LISTEN
openssl s_client -connect 127.0.0.1:443 -servername codekeks.test </dev/null | openssl x509 -noout -subject -issuer -dates

Auf Linux‑Server (falls vorhanden):

sudo grep "Accepted publickey" /var/log/auth.log || true
sudo ss -tulpen
awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -n 40

Suche nach typischen Backdoors / Patterns:

grep -RIn --exclude-dir=node_modules -e "eval(" -e "base64_decode" -e "shell_exec(" /path/to/site || true

WordPress Cleanup (Schrittfolge)

1. Plugins prüfen & entfernen (besonders File‑Manager‑Plugins und unbekannte Tools):

ls -la wp-content/plugins
rm -rf wp-content/plugins/file-manager-advanced wp-content/plugins/filester

1. Core neu aufspielen

cd /tmp
curl -O https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
# Backup & ersetze wp-admin + wp-includes
mv /path/to/site/wp-admin /path/to/site/wp-admin.bak
mv /path/to/site/wp-includes /path/to/site/wp-includes.bak
cp -a wordpress/wp-admin /path/to/site/
cp -a wordpress/wp-includes /path/to/site/

1. DB: Admin‑Passwort / Users prüfen (MySQL Beispiel):

USE your_wp_db;
UPDATE wp_users SET user_pass = MD5('SehrSicheresPasswort!') WHERE user_login = 'admin';
DELETE FROM wp_users WHERE user_login = 'unbekannter_user';

1. Dateirechte korrigieren:

cd /path/to/site
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

1. Zugriff auf /wp-admin einschränken (temporär)

# Beispiel .htaccess / VirtualHost
<Directory "/path/to/site/wp-admin">
    Require ip 123.123.123.123
    Require ip ::1
</Directory>

Firewall, Fail2Ban & Basis-Härtung

UFW Basis:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp    # Beispiel SSH-Port
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Fail2Ban (einfach):

sudo apt update && sudo apt install fail2ban -y
# /etc/fail2ban/jail.local anlegen und sshd aktivieren
sudo systemctl restart fail2ban

Langfristig: 2FA für WP, regelmässige Updates, nur notwendige Plugins, Backups extern.

Wie Scanner/Bots arbeiten (kurze Erklärung)

• Netzweite Scanner schicken massenhaft Requests an IP‑Räume und bekannte Hostnamen (z. B. .test nicht relevant, aber public DynDNS ist Ziel).
• Sie testen Pfade wie /wp-login.php, /xmlrpc.php, bekannte Plugin‑URLs (z. B. File‑Manager), versuchen Brute‑Force auf Logins, oder uploaden Webshells über unsichere Upload‑Funktionen.
• Portscanner prüfen offene Ports (80, 443, 21, 22, 3306, 10000 etc.).
• Erkennbare Muster: viele 404/POST‑Versuche, ungewöhnliche User‑Agents, viele Request/sec von einer IP.

# scan_safe.py -- nur für eigene Geräte
import socket, sys, time
target = sys.argv[1] if len(sys.argv)>1 else '127.0.0.1'
for port in range(1,1025):
    s = socket.socket()
    s.settimeout(0.3)
    try:
        if s.connect_ex((target, port)) == 0:
            print(f"OPEN {port}")
    except:
        pass
    s.close()
    time.sleep(0.02)

# Suchen nach verdächtigen Patterns
grep -RIn -e "eval(" -e "base64_decode" -e "shell_exec(" /path/to/site || true
# Häufige IPs aus access.log
awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -nr | head -n 40
# Zertifikat prüfen
openssl s_client -connect 127.0.0.1:443 -servername codekeks.test </dev/null | openssl x509 -noout -subject -issuer -dates

Erstellt für codekeks — sichere Bastelpraktiken & bessere Defaults für Hobby‑DevOps.*