Zum Inhalt

Fehlerbehebung

BunkerWeb Panel

Wenn Sie Ihr Problem nicht lösen können, können Sie uns direkt über unser Panel kontaktieren. Dies zentralisiert alle Anfragen zur BunkerWeb-Lösung.

Protokolle

Bei der Fehlerbehebung sind Protokolle Ihre besten Freunde. Wir geben unser Bestes, um benutzerfreundliche Protokolle bereitzustellen, damit Sie verstehen, was passiert.

Bitte beachten Sie, dass Sie LOG_LEVEL auf info (Standard: notice) setzen können, um die Ausführlichkeit von BunkerWeb zu erhöhen.

Hier erfahren Sie, wie Sie je nach Integration auf die Protokolle zugreifen können:

Container auflisten

Um die laufenden Container aufzulisten, können Sie den folgenden Befehl verwenden: 

docker ps

Sie können den Befehl docker logs verwenden (ersetzen Sie bunkerweb durch den Namen Ihres Containers): 

docker logs bunkerweb

Hier ist das Docker-Compose-Äquivalent (ersetzen Sie bunkerweb durch den Namen der in der docker-compose.yml-Datei deklarierten Dienste): 

docker-compose logs bunkerweb

Container auflisten

Um die laufenden Container aufzulisten, können Sie den folgenden Befehl verwenden: 

docker ps

Sie können den Befehl docker logs verwenden (ersetzen Sie bunkerweb und bw-autoconf durch die Namen Ihrer Container): 

docker logs bunkerweb
docker logs bw-autoconf

Hier ist das Docker-Compose-Äquivalent (ersetzen Sie bunkerweb und bw-autoconf durch die Namen der in der docker-compose.yml-Datei deklarierten Dienste): 

docker-compose logs bunkerweb
docker-compose logs bw-autoconf

Container-Name

Der Standard-Container-Name für das All-in-one-Image ist bunkerweb-aio. Wenn Sie einen anderen Namen verwendet haben, passen Sie den Befehl bitte entsprechend an.

Sie können den Befehl docker logs verwenden: 

docker logs bunkerweb-aio

Veraltet

Die Swarm-Integration ist veraltet und wird in einer zukünftigen Version entfernt. Bitte erwägen Sie stattdessen die Verwendung der Kubernetes-Integration.

Weitere Informationen finden Sie in der Swarm-Integrationsdokumentation.

Dienste auflisten

Um die Dienste aufzulisten, können Sie den folgenden Befehl verwenden: 

docker service ls

Sie können den Befehl docker service logs verwenden (ersetzen Sie bunkerweb und bw-autoconf durch die Namen Ihrer Dienste): 

docker service logs bunkerweb
docker service logs bw-autoconf

Pods auflisten

Um die Pods aufzulisten, können Sie den folgenden Befehl verwenden: 

kubectl get pods

Sie können den Befehl kubectl logs verwenden (ersetzen Sie bunkerweb und bunkerweb-controler durch die Namen Ihrer Pods): 

kubectl logs bunkerweb
kubectl logs bunkerweb-controler

Bei Fehlern im Zusammenhang mit BunkerWeb-Diensten (z. B. wenn sie nicht starten) können Sie journalctl verwenden: 

journalctl -u bunkerweb --no-pager

Allgemeine Protokolle befinden sich im Verzeichnis /var/log/bunkerweb: 

cat /var/log/bunkerweb/error.log
cat /var/log/bunkerweb/access.log

Berechtigungen

Vergessen Sie nicht, dass BunkerWeb aus offensichtlichen Sicherheitsgründen als unprivilegierter Benutzer ausgeführt wird. Überprüfen Sie die Berechtigungen von Dateien und Ordnern, die von BunkerWeb verwendet werden, insbesondere wenn Sie benutzerdefinierte Konfigurationen verwenden (weitere Informationen hier). Sie müssen mindestens RW-Rechte für Dateien und RWX für Ordner festlegen.

IP-Entsperrung

Sie können eine IP manuell entsperren, was bei Tests nützlich ist, damit Sie die interne API von BunkerWeb kontaktieren können (ersetzen Sie 1.2.3.4 durch die zu entsperrende IP-Adresse):

Sie können den Befehl docker exec verwenden (ersetzen Sie bw-scheduler durch den Namen Ihres Containers): 

docker exec bw-scheduler bwcli unban 1.2.3.4

Hier ist das Docker-Compose-Äquivalent (ersetzen Sie bw-scheduler durch den Namen der in der docker-compose.yml-Datei deklarierten Dienste): 

docker-compose exec bw-scheduler bwcli unban 1.2.3.4

Container-Name

Der Standard-Container-Name für das All-in-one-Image ist bunkerweb-aio. Wenn Sie einen anderen Namen verwendet haben, passen Sie den Befehl bitte entsprechend an.

Sie können den Befehl docker exec verwenden: 

docker exec bunkerweb-aio bwcli unban 1.2.3.4

Veraltet

Die Swarm-Integration ist veraltet und wird in einer zukünftigen Version entfernt. Bitte erwägen Sie stattdessen die Verwendung der Kubernetes-Integration.

Weitere Informationen finden Sie in der Swarm-Integrationsdokumentation.

Sie können den Befehl docker exec verwenden (ersetzen Sie bw-scheduler durch den Namen Ihres Dienstes): 

docker exec $(docker ps -q -f name=bw-scheduler) bwcli unban 1.2.3.4

Sie können den Befehl kubectl exec verwenden (ersetzen Sie bunkerweb-scheduler durch den Namen Ihres Pods): 

kubectl exec bunkerweb-scheduler bwcli unban 1.2.3.4

Sie können den Befehl bwcli (als Root) verwenden: 

sudo bwcli unban 1.2.3.4

Falschmeldungen

Nur-Erkennen-Modus

Zu Debugging-/Testzwecken können Sie BunkerWeb in den Nur-Erkennen-Modus versetzen, sodass Anfragen nicht blockiert werden und es sich wie ein klassischer Reverse-Proxy verhält.

ModSecurity

Die Standardkonfiguration von ModSecurity in BunkerWeb lädt das Core Rule Set im Anomalie-Bewertungsmodus mit einer Paranoia-Stufe (PL) von 1:

  • Jede übereinstimmende Regel erhöht eine Anomalie-Punktzahl (so können viele Regeln auf eine einzelne Anfrage zutreffen)
  • PL1 enthält Regeln mit geringerer Wahrscheinlichkeit von Falschmeldungen (aber weniger Sicherheit als PL4)
  • der Standardschwellenwert für die Anomalie-Punktzahl beträgt 5 für Anfragen und 4 für Antworten

Nehmen wir die folgenden Protokolle als Beispiel für eine ModSecurity-Erkennung mit der Standardkonfiguration (zur besseren Lesbarkeit formatiert):

2022/04/26 12:01:10 [warn] 85#85: *11 ModSecurity: Warning. Matched "Operator `PmFromFile' with parameter `lfi-os-files.data' against variable `ARGS:id' (Value: `/etc/passwd' )
    [file "/usr/share/bunkerweb/core/modsecurity/files/coreruleset/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf"]
    [line "78"]
    [id "930120"]
    [rev ""]
    [msg "OS File Access Attempt"]
    [data "Matched Data: etc/passwd found within ARGS:id: /etc/passwd"]
    [severity "2"]
    [ver "OWASP_CRS/3.3.2"]
    [maturity "0"]
    [accuracy "0"]
    [tag "application-multi"]
    [tag "language-multi"]
    [tag "platform-multi"]
    [tag "attack-lfi"]
    [tag "paranoia-level/1"]
    [tag "OWASP_CRS"]
    [tag "capec/1000/255/153/126"]
    [tag "PCI/6.5.4"]
    [hostname "172.17.0.2"]
    [uri "/"]
    [unique_id "165097447014.179282"]
    [ref "o1,10v9,11t:utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase"],
    client: 172.17.0.1, server: localhost, request: "GET /?id=/etc/passwd HTTP/1.1", host: "localhost"
2022/04/26 12:01:10 [warn] 85#85: *11 ModSecurity: Warning. Matched "Operator `PmFromFile' with parameter `unix-shell.data' against variable `ARGS:id' (Value: `/etc/passwd' )
    [file "/usr/share/bunkerweb/core/modsecurity/files/coreruleset/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"]
    [line "480"]
    [id "932160"]
    [rev ""]
    [msg "Remote Command Execution: Unix Shell Code Found"]
    [data "Matched Data: etc/passwd found within ARGS:id: /etc/passwd"]
    [severity "2"]
    [ver "OWASP_CRS/3.3.2"]
    [maturity "0"]
    [accuracy "0"]
    [tag "application-multi"]
    [tag "language-shell"]
    [tag "platform-unix"]
    [tag "attack-rce"]
    [tag "paranoia-level/1"]
    [tag "OWASP_CRS"]
    [tag "capec/1000/152/248/88"]
    [tag "PCI/6.5.2"]
    [hostname "172.17.0.2"]
    [uri "/"]
    [unique_id "165097447014.179282"]
    [ref "o1,10v9,11t:urlDecodeUni,t:cmdLine,t:normalizePath,t:lowercase"],
    client: 172.17.0.1, server: localhost, request: "GET /?id=/etc/passwd HTTP/1.1", host: "localhost"
2022/04/26 12:01:10 [error] 85#85: *11 [client 172.17.0.1] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `10' )
    [file "/usr/share/bunkerweb/core/modsecurity/files/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"]
    [line "80"]
    [id "949110"]
    [rev ""]
    [msg "Inbound Anomaly Score Exceeded (Total Score: 10)"]
    [data ""]
    [severity "2"]
    [ver "OWASP_CRS/3.3.2"]
    [maturity "0"]
    [accuracy "0"]
    [tag "application-multi"]
    [tag "language-multi"]
    [tag "platform-multi"]
    [tag "attack-generic"]
    [hostname "172.17.0.2"]
    [uri "/"]
    [unique_id "165097447014.179282"]
    [ref ""],
    client: 172.17.0.1, server: localhost, request: "GET /?id=/etc/passwd HTTP/1.1", host: "localhost"

Wie wir sehen können, gibt es 3 verschiedene Protokolle:

  1. Regel 930120 stimmte überein
  2. Regel 932160 stimmte überein
  3. Zugriff verweigert (Regel 949110)

Eine wichtige Sache zu verstehen ist, dass Regel 949110 keine "echte" Regel ist: Es ist diejenige, die die Anfrage verweigert, weil der Anomalie-Schwellenwert erreicht ist (in diesem Beispiel 10). Sie sollten die Regel 949110 niemals entfernen!

Wenn es sich um eine Falschmeldung handelt, sollten Sie sich auf die Regeln 930120 und 932160 konzentrieren. Das Tuning von ModSecurity und/oder CRS liegt außerhalb des Rahmens dieser Dokumentation, aber vergessen Sie nicht, dass Sie benutzerdefinierte Konfigurationen vor und nach dem Laden des CRS anwenden können (weitere Informationen hier).

Schlechtes Verhalten

Ein häufiger Fall von Falschmeldungen ist, wenn der Client aufgrund der Funktion "schlechtes Verhalten" gesperrt wird, was bedeutet, dass innerhalb eines Zeitraums zu viele verdächtige HTTP-Statuscodes generiert wurden (weitere Informationen hier). Sie sollten damit beginnen, die Einstellungen zu überprüfen und sie dann entsprechend Ihrer Webanwendung(en) zu bearbeiten, z. B. einen verdächtigen HTTP-Code entfernen, die Zählzeit verringern, den Schwellenwert erhöhen usw.

Whitelisting

Wenn Sie Bots (oder Administratoren) haben, die auf Ihre Website zugreifen müssen, ist die empfohlene Vorgehensweise, um Falschmeldungen zu vermeiden, sie mit der Whitelisting-Funktion auf die Whitelist zu setzen. Wir empfehlen nicht, die Einstellungen WHITELIST_URI* oder WHITELIST_USER_AGENT* zu verwenden, es sei denn, sie sind auf geheime und unvorhersehbare Werte gesetzt. Gängige Anwendungsfälle sind:

  • Healthcheck / Status-Bot
  • Callback wie IPN oder Webhook
  • Social-Media-Crawler

Häufige Fehler

Upstream hat zu großen Header gesendet

Wenn Sie den Fehler upstream sent too big header while reading response header from upstream in den Protokollen sehen, müssen Sie die verschiedenen Proxy-Puffergrößen mit den folgenden Einstellungen anpassen:

  • PROXY_BUFFERS
  • PROXY_BUFFER_SIZE
  • PROXY_BUSY_BUFFERS_SIZE

Konnte server_names_hash nicht erstellen

Wenn Sie den Fehler could not build server_names_hash, you should increase server_names_hash_bucket_size in den Protokollen sehen, müssen Sie die Einstellung SERVER_NAMES_HASH_BUCKET_SIZE anpassen.

Zeitzone

Bei Verwendung von containerbasierten Integrationen kann die Zeitzone des Containers von der des Host-Rechners abweichen. Um dies zu beheben, können Sie die Umgebungsvariable TZ auf die Zeitzone Ihrer Wahl in Ihren Containern setzen (z. B. TZ=Europe/Paris). Eine Liste der Zeitzonen-Identifikatoren finden Sie hier.

Web-UI

Falls Sie Ihre UI-Anmeldeinformationen vergessen haben oder Probleme mit 2FA haben, können Sie sich mit der Datenbank verbinden, um wieder Zugriff zu erhalten.

Auf die Datenbank zugreifen

Installieren Sie SQLite (Debian/Ubuntu):

sudo apt install sqlite3

Installieren Sie SQLite (Fedora/RedHat):

sudo dnf install sqlite

Holen Sie sich eine Shell in Ihren Scheduler-Container:

Docker-Argumente

  • die Option -u 0 ist, um den Befehl als Root auszuführen (obligatorisch)
  • die Optionen -it sind, um den Befehl interaktiv auszuführen (obligatorisch)
  • <bunkerweb_scheduler_container>: der Name oder die ID Ihres Scheduler-Containers
docker exec -u 0 -it <bunkerweb_scheduler_container> bash

Installieren Sie SQLite:

apk add sqlite

Holen Sie sich eine Shell in Ihren All-in-one-Container:

Docker-Argumente

  • die Option -u 0 ist, um den Befehl als Root auszuführen (obligatorisch).
  • die Optionen -it sind, um den Befehl interaktiv auszuführen (obligatorisch).
  • bunkerweb-aio ist der Standard-Container-Name; passen Sie ihn an, wenn Sie einen benutzerdefinierten Namen verwendet haben.
docker exec -u 0 -it bunkerweb-aio bash

Greifen Sie auf Ihre Datenbank zu:

Datenbankpfad

Wir gehen davon aus, dass Sie den Standard-Datenbankpfad verwenden. Wenn Sie einen benutzerdefinierten Pfad verwenden, müssen Sie den Befehl anpassen. Für All-in-one gehen wir davon aus, dass die Datenbank db.sqlite3 im persistenten /data-Volume (/data/db.sqlite3) liegt.

sqlite3 /var/lib/bunkerweb/db.sqlite3

Sie sollten etwas Ähnliches wie das Folgende sehen:

SQLite version <VER> <DATE>
Enter ".help" for usage hints.
sqlite>

Nur MariaDB / MySQL

Die folgenden Schritte sind nur für MariaDB / MySQL-Datenbanken gültig. Wenn Sie eine andere Datenbank verwenden, lesen Sie bitte die Dokumentation Ihrer Datenbank.

Anmeldeinformationen und Datenbankname

Sie müssen dieselben Anmeldeinformationen und denselben Datenbanknamen verwenden, die in der Einstellung DATABASE_URI verwendet werden.

Greifen Sie auf Ihre lokale Datenbank zu:

mysql -u <user> -p <database>

Geben Sie dann das Passwort des Datenbankbenutzers ein, und Sie sollten auf Ihre Datenbank zugreifen können.

Greifen Sie auf Ihren Datenbankcontainer zu:

Docker-Argumente

  • die Option -u 0 ist, um den Befehl als Root auszuführen (obligatorisch)
  • die Optionen -it sind, um den Befehl interaktiv auszuführen (obligatorisch)
  • <bunkerweb_db_container>: der Name oder die ID Ihres Datenbankcontainers
  • <user>: der Datenbankbenutzer
  • <database>: der Datenbankname
docker exec -u 0 -it <bunkerweb_db_container> mysql -u <user> -p <database>

Geben Sie dann das Passwort des Datenbankbenutzers ein, und Sie sollten auf Ihre Datenbank zugreifen können.

Das All-in-One-Image enthält keinen MariaDB/MySQL-Server. Wenn Sie das AIO so konfiguriert haben, dass es eine externe MariaDB/MySQL-Datenbank verwendet (indem Sie die Umgebungsvariable DATABASE_URI setzen), sollten Sie sich direkt mit dieser Datenbank mit Standard-MySQL-Client-Tools verbinden.

Die Verbindungsmethode wäre ähnlich wie im Tab "Linux" (wenn Sie sich vom Host verbinden, auf dem AIO läuft, oder von einem anderen Rechner) oder indem Sie einen MySQL-Client in einem separaten Docker-Container ausführen, der auf den Host und die Anmeldeinformationen Ihrer externen Datenbank abzielt.

Nur PostgreSQL

Die folgenden Schritte sind nur für PostgreSQL-Datenbanken gültig. Wenn Sie eine andere Datenbank verwenden, lesen Sie bitte die Dokumentation Ihrer Datenbank.

Anmeldeinformationen, Host und Datenbankname

Sie müssen dieselben Anmeldeinformationen (Benutzer/Passwort), denselben Host und denselben Datenbanknamen verwenden, die in der Einstellung DATABASE_URI verwendet werden.

Greifen Sie auf Ihre lokale Datenbank zu:

psql -U <user> -d <database>

Wenn sich Ihre Datenbank auf einem anderen Host befindet, geben Sie den Hostnamen/die IP und den Port an:

psql -h <host> -p 5432 -U <user> -d <database>

Geben Sie dann das Passwort des Datenbankbenutzers ein, und Sie sollten auf Ihre Datenbank zugreifen können.

Greifen Sie auf Ihren Datenbankcontainer zu:

Docker-Argumente

  • die Option -u 0 ist, um den Befehl als Root auszuführen (obligatorisch)
  • die Optionen -it sind, um den Befehl interaktiv auszuführen (obligatorisch)
  • <bunkerweb_db_container>: der Name oder die ID Ihres Datenbankcontainers
  • <user>: der Datenbankbenutzer
  • <database>: der Datenbankname
docker exec -u 0 -it <bunkerweb_db_container> psql -U <user> -d <database>

Wenn die Datenbank an anderer Stelle gehostet wird, fügen Sie die Optionen -h <host> und -p 5432 entsprechend hinzu.

Das All-in-One-Image enthält keinen PostgreSQL-Server. Wenn Sie das AIO so konfiguriert haben, dass es eine externe PostgreSQL-Datenbank verwendet (indem Sie die Umgebungsvariable DATABASE_URI setzen), sollten Sie sich direkt mit dieser Datenbank mit Standard-PostgreSQL-Client-Tools verbinden.

Die Verbindungsmethode wäre ähnlich wie im Tab "Linux" (wenn Sie sich vom Host verbinden, auf dem AIO läuft, oder von einem anderen Rechner) oder indem Sie einen PostgreSQL-Client in einem separaten Docker-Container ausführen, der auf den Host und die Anmeldeinformationen Ihrer externen Datenbank abzielt.

Maßnahmen zur Fehlerbehebung

Tabellenschema

Das Schema der Tabelle bw_ui_users ist wie folgt:

Feld Typ Null Schlüssel Standard Extra
username varchar(256) NO PRI NULL
email varchar(256) YES UNI NULL
password varchar(60) NO NULL
method enum('ui','scheduler','autoconf','manual','wizard') NO NULL
admin tinyint(1) NO NULL
theme enum('light','dark') NO NULL
language varchar(2) NO NULL
totp_secret varchar(256) YES NULL
creation_date datetime NO NULL
update_date datetime NO NULL

Führen Sie den folgenden Befehl aus, um Daten aus der Tabelle bw_ui_users zu extrahieren:

SELECT * FROM bw_ui_users;

Sie sollten etwas Ähnliches wie das Folgende sehen:

username email password method admin theme totp_secret creation_date update_date
*** *** *** manual 1 light *** *** ***

Zuerst müssen Sie das neue Passwort mit dem bcrypt-Algorithmus hashen.

Installieren Sie die Python-bcrypt-Bibliothek:

pip install bcrypt

Generieren Sie Ihren Hash (ersetzen Sie meinpasswort durch Ihr eigenes Passwort):

python3 -c 'from bcrypt import hashpw, gensalt ; print(hashpw(b"""meinpasswort""", gensalt(rounds=10)).decode("utf-8"))'

Sie können Ihren Benutzernamen / Ihr Passwort aktualisieren, indem Sie diesen Befehl ausführen:

UPDATE bw_ui_users SET password = '<password_hash>' WHERE admin = 1;

Wenn Sie Ihre Tabelle bw_ui_users nach diesem Befehl erneut überprüfen:

SELECT * FROM bw_ui_users WHERE admin = 1;

Sie sollten etwas Ähnliches wie das Folgende sehen:

username email password method admin theme totp_secret creation_date update_date
*** *** *** manual 1 light *** *** ***

Sie sollten nun in der Lage sein, die neuen Anmeldeinformationen zu verwenden, um sich in der Web-UI anzumelden.

Sie können 2FA deaktivieren, indem Sie diesen Befehl ausführen:

UPDATE bw_ui_users SET totp_secret = NULL WHERE admin = 1;

Wenn Sie Ihre Tabelle bw_ui_users nach diesem Befehl erneut überprüfen:

SELECT * FROM bw_ui_users WHERE admin = 1;

Sie sollten etwas Ähnliches wie das Folgende sehen:

username email password method admin theme totp_secret creation_date update_date
*** *** *** manual 1 light NULL *** ***

Sie sollten sich nun nur mit Ihrem Benutzernamen und Passwort ohne 2FA in der Web-UI anmelden können.

Die Wiederherstellungscodes können auf Ihrer Profilseite der Web-UI unter dem Tab Sicherheit aktualisiert werden.

Verwenden Sie die Support-Seite in der Web-UI, um schnell Konfigurationen und Protokolle zur Fehlerbehebung zu sammeln.

  • Öffnen Sie die Web-UI und gehen Sie zur Support-Seite.
  • Wählen Sie den Geltungsbereich: Exportieren Sie die globale Konfiguration oder wählen Sie einen bestimmten Dienst aus.
  • Klicken Sie, um das Konfigurationsarchiv für den ausgewählten Geltungsbereich herunterzuladen.
  • Laden Sie optional Protokolle herunter: Die exportierten Protokolle werden automatisch anonymisiert (alle IP-Adressen und Domains werden maskiert).

Plugin hochladen

Es ist möglicherweise nicht möglich, ein Plugin in bestimmten Situationen von der Benutzeroberfläche hochzuladen:

  • Fehlendes Paket zur Verwaltung komprimierter Dateien in Ihrer Integration, in diesem Fall müssen Sie die erforderlichen Pakete hinzufügen
  • Safari-Browser: Der "Sicherheitsmodus" kann Sie daran hindern, ein Plugin hinzuzufügen. Sie müssen die erforderlichen Änderungen auf Ihrem Computer vornehmen