Funktionen
Dieser Abschnitt enthält die vollständige Liste der von BunkerWeb unterstützten Einstellungen. Wenn Sie mit BunkerWeb noch nicht vertraut sind, lesen Sie zuerst den Abschnitt Konzepte der Dokumentation. Befolgen Sie anschließend die Anweisungen für Ihre Integration, um die Einstellungen anzuwenden.
Globale Einstellungen
STREAM-Unterstützung
Das Allgemein-Plugin stellt das zentrale Konfigurations-Framework für BunkerWeb bereit und ermöglicht es Ihnen, wesentliche Einstellungen zu definieren, die steuern, wie Ihre Webdienste geschützt und bereitgestellt werden. Dieses grundlegende Plugin verwaltet fundamentale Aspekte wie Sicherheitsmodi, Server-Standardeinstellungen, Protokollierungsverhalten und kritische Betriebsparameter für das gesamte BunkerWeb-Ökosystem.
So funktioniert es:
- Beim Start von BunkerWeb lädt und wendet das Allgemein-Plugin Ihre zentralen Konfigurationseinstellungen an.
- Sicherheitsmodi werden entweder global oder pro Website festgelegt und bestimmen das angewendete Schutzniveau.
- Standard-Servereinstellungen legen Fallback-Werte für alle nicht spezifizierten Multisite-Konfigurationen fest.
- Protokollierungsparameter steuern, welche Informationen aufgezeichnet und wie sie formatiert werden.
- Diese Einstellungen bilden die Grundlage, auf der alle anderen BunkerWeb-Plugins und -Funktionen aufbauen.
Multisite-Modus
Wenn MULTISITE
auf yes
gesetzt ist, kann BunkerWeb mehrere Websites hosten und schützen, jede mit ihrer eigenen einzigartigen Konfiguration. Diese Funktion ist besonders nützlich für Szenarien wie:
- Hosten mehrerer Domains mit unterschiedlichen Konfigurationen
- Betreiben mehrerer Anwendungen mit unterschiedlichen Sicherheitsanforderungen
- Anwenden maßgeschneiderter Sicherheitsrichtlinien auf verschiedene Dienste
Im Multisite-Modus wird jede Website durch einen eindeutigen SERVER_NAME
identifiziert. Um Einstellungen spezifisch auf eine Website anzuwenden, stellen Sie den primären SERVER_NAME
dem Einstellungsnamen voran. Zum Beispiel:
www.example.com_USE_ANTIBOT=captcha
aktiviert CAPTCHA fürwww.example.com
.myapp.example.com_USE_GZIP=yes
aktiviert die GZIP-Komprimierung fürmyapp.example.com
.
Dieser Ansatz stellt sicher, dass die Einstellungen in einer Multisite-Umgebung der richtigen Website zugeordnet werden.
Mehrfacheinstellungen
Einige Einstellungen in BunkerWeb unterstützen mehrere Konfigurationen für dieselbe Funktion. Um mehrere Einstellungsgruppen zu definieren, hängen Sie ein numerisches Suffix an den Einstellungsnamen an. Zum Beispiel:
REVERSE_PROXY_URL_1=/subdir
undREVERSE_PROXY_HOST_1=http://myhost1
konfigurieren den ersten Reverse-Proxy.REVERSE_PROXY_URL_2=/anotherdir
undREVERSE_PROXY_HOST_2=http://myhost2
konfigurieren den zweiten Reverse-Proxy.
Dieses Muster ermöglicht es Ihnen, mehrere Konfigurationen für Funktionen wie Reverse-Proxys, Ports oder andere Einstellungen zu verwalten, die für unterschiedliche Anwendungsfälle unterschiedliche Werte erfordern.
Sicherheitsmodi
Die Einstellung SECURITY_MODE
bestimmt, wie BunkerWeb erkannte Bedrohungen behandelt. Diese flexible Funktion ermöglicht es Ihnen, je nach Ihren spezifischen Bedürfnissen zwischen der Überwachung oder dem aktiven Blockieren verdächtiger Aktivitäten zu wählen:
detect
: Protokolliert potenzielle Bedrohungen, ohne den Zugriff zu blockieren. Dieser Modus ist nützlich, um Falsch-Positive auf sichere und unterbrechungsfreie Weise zu identifizieren und zu analysieren.block
(Standard): Blockiert aktiv erkannte Bedrohungen und protokolliert Vorfälle, um unbefugten Zugriff zu verhindern und Ihre Anwendung zu schützen.
Das Umschalten in den detect
-Modus kann Ihnen helfen, potenzielle Falsch-Positive zu identifizieren und zu beheben, ohne legitime Clients zu stören. Sobald diese Probleme behoben sind, können Sie für vollen Schutz getrost in den block
-Modus zurückwechseln.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
SERVER_NAME |
www.example.com |
multisite | Nein | Primäre Domain: Der Hauptdomainname für diese Website. Im Multisite-Modus erforderlich. |
BUNKERWEB_INSTANCES |
127.0.0.1 |
global | Nein | BunkerWeb-Instanzen: Liste der BunkerWeb-Instanzen, durch Leerzeichen getrennt. |
MULTISITE |
no |
global | Nein | Mehrere Websites: Auf yes setzen, um das Hosten mehrerer Websites mit unterschiedlichen Konfigurationen zu ermöglichen. |
SECURITY_MODE |
block |
multisite | Nein | Sicherheitsstufe: Steuert die Stufe der Sicherheitsdurchsetzung. Optionen: detect oder block . |
SERVER_TYPE |
http |
multisite | Nein | Servertyp: Definiert, ob der Server vom Typ http oder stream ist. |
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_API |
yes |
global | Nein | API aktivieren: Aktivieren Sie die API, um BunkerWeb zu steuern. |
API_HTTP_PORT |
5000 |
global | Nein | API-Port: Lauschportnummer für die API. |
API_HTTPS_PORT |
5443 |
global | Nein | API-HTTPS-Port: Lauschportnummer (TLS) für die API. |
API_LISTEN_HTTP |
yes |
global | Nein | API-HTTP-Lauschen: HTTP-Listener für die API aktivieren. |
API_LISTEN_HTTPS |
no |
global | Nein | API-HTTPS-Lauschen: HTTPS (TLS)-Listener für die API aktivieren. |
API_LISTEN_IP |
0.0.0.0 |
global | Nein | API-Lausch-IP: Lausch-IP-Adresse für die API. |
API_SERVER_NAME |
bwapi |
global | Nein | API-Servername: Servername (virtueller Host) für die API. |
API_WHITELIST_IP |
127.0.0.0/8 |
global | Nein | API-Whitelist-IP: Liste der IP/Netzwerke, die die API kontaktieren dürfen. |
API_TOKEN |
global | Nein | API-Zugriffstoken (optional): Wenn gesetzt, müssen alle API-Anfragen Authorization: Bearer <token> enthalten. |
Hinweis: Aus Bootstrap-Gründen müssen Sie, wenn Sie API_TOKEN
aktivieren, es in der Umgebung SOWOHL der BunkerWeb-Instanz als auch des Schedulers setzen. Der Scheduler fügt den Authorization
-Header automatisch hinzu, wenn API_TOKEN
in seiner Umgebung vorhanden ist. Wenn es nicht gesetzt ist, wird kein Header gesendet und BunkerWeb erzwingt keine Token-Authentifizierung. Sie können die API über HTTPS bereitstellen, indem Sie API_LISTEN_HTTPS=yes
setzen (Port: API_HTTPS_PORT
, Standard 5443
).
Beispieltest mit curl (Token und Host ersetzen):
curl -H "Host: bwapi" \
-H "Authorization: Bearer $API_TOKEN" \
http://<bunkerweb-host>:5000/ping
curl -H "Host: bwapi" \
-H "Authorization: Bearer $API_TOKEN" \
--insecure \
https://<bunkerweb-host>:5443/ping
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
HTTP_PORT |
8080 |
global | Ja | HTTP-Port: Portnummer für HTTP-Verkehr. |
HTTPS_PORT |
8443 |
global | Ja | HTTPS-Port: Portnummer für HTTPS-Verkehr. |
USE_IPV6 |
no |
global | Nein | IPv6-Unterstützung: IPv6-Konnektivität aktivieren. |
DNS_RESOLVERS |
127.0.0.11 |
global | Nein | DNS-Resolver: DNS-Adressen der zu verwendenden Resolver. |
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
LISTEN_STREAM |
yes |
multisite | Nein | Stream lauschen: Lauschen für Nicht-SSL (Passthrough) aktivieren. |
LISTEN_STREAM_PORT |
1337 |
multisite | Ja | Stream-Port: Lauschport für Nicht-SSL (Passthrough). |
LISTEN_STREAM_PORT_SSL |
4242 |
multisite | Ja | Stream-SSL-Port: Lauschport für SSL (Passthrough). |
USE_TCP |
yes |
multisite | Nein | TCP lauschen: TCP-Lauschen (Stream) aktivieren. |
USE_UDP |
no |
multisite | Nein | UDP lauschen: UDP-Lauschen (Stream) aktivieren. |
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
WORKER_PROCESSES |
auto |
global | Nein | Worker-Prozesse: Anzahl der Worker-Prozesse. Auf auto setzen, um verfügbare Kerne zu verwenden. |
WORKER_CONNECTIONS |
1024 |
global | Nein | Worker-Verbindungen: Maximale Anzahl von Verbindungen pro Worker. |
WORKER_RLIMIT_NOFILE |
2048 |
global | Nein | Dateideskriptor-Limit: Maximale Anzahl offener Dateien pro Worker. |
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
WORKERLOCK_MEMORY_SIZE |
48k |
global | Nein | Workerlock-Speichergröße: Größe des lua_shared_dict für Initialisierungs-Worker. |
DATASTORE_MEMORY_SIZE |
64m |
global | Nein | Datastore-Speichergröße: Größe des internen Datastores. |
CACHESTORE_MEMORY_SIZE |
64m |
global | Nein | Cachestore-Speichergröße: Größe des internen Cachestores. |
CACHESTORE_IPC_MEMORY_SIZE |
16m |
global | Nein | Cachestore-IPC-Speichergröße: Größe des internen Cachestores (ipc). |
CACHESTORE_MISS_MEMORY_SIZE |
16m |
global | Nein | Cachestore-Miss-Speichergröße: Größe des internen Cachestores (miss). |
CACHESTORE_LOCKS_MEMORY_SIZE |
16m |
global | Nein | Cachestore-Locks-Speichergröße: Größe des internen Cachestores (locks). |
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
LOG_FORMAT |
$host $remote_addr - $request_id $remote_user [$time_local] \"$request\" $status $body_bytes_sent \"$http_referer\" \"$http_user_agent\" |
global | Nein | Protokollformat: Das Format, das für Zugriffsprotokolle verwendet werden soll. |
LOG_LEVEL |
notice |
global | Nein | Protokollstufe: Ausführlichkeitsstufe für Fehlerprotokolle. Optionen: debug , info , notice , warn , error , crit , alert , emerg . |
TIMERS_LOG_LEVEL |
debug |
global | Nein | Timer-Protokollstufe: Protokollstufe für Timer. Optionen: debug , info , notice , warn , err , crit , alert , emerg . |
Bewährte Praktiken bei der Protokollierung
- Verwenden Sie für Produktionsumgebungen die Protokollstufen
notice
,warn
odererror
, um das Protokollvolumen zu minimieren. - Setzen Sie zur Fehlersuche vorübergehend die Protokollstufe auf
debug
, um detailliertere Informationen zu erhalten.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
AUTOCONF_MODE |
no |
global | Nein | Autoconf-Modus: Autoconf-Docker-Integration aktivieren. |
SWARM_MODE |
no |
global | Nein | Swarm-Modus: Docker-Swarm-Integration aktivieren. |
KUBERNETES_MODE |
no |
global | Nein | Kubernetes-Modus: Kubernetes-Integration aktivieren. |
USE_TEMPLATE |
multisite | Nein | Vorlage verwenden: Konfigurationsvorlage, die die Standardwerte bestimmter Einstellungen überschreibt. |
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
NGINX_PREFIX |
/etc/nginx/ |
global | Nein | Nginx-Präfix: Wo Nginx nach Konfigurationen suchen wird. |
SERVER_NAMES_HASH_BUCKET_SIZE |
global | Nein | Server-Namen-Hash-Bucket-Größe: Wert für die server_names_hash_bucket_size -Direktive. |
Beispielkonfigurationen
Eine Standardkonfiguration für eine Produktionswebsite mit strenger Sicherheit:
SECURITY_MODE: "block"
SERVER_NAME: "example.com"
LOG_LEVEL: "notice"
Konfiguration für eine Entwicklungsumgebung mit zusätzlicher Protokollierung:
SECURITY_MODE: "detect"
SERVER_NAME: "dev.example.com"
LOG_LEVEL: "debug"
Konfiguration zum Hosten mehrerer Websites:
MULTISITE: "yes"
# Erste Website
site1.example.com_SERVER_NAME: "site1.example.com"
site1.example.com_SECURITY_MODE: "block"
# Zweite Website
site2.example.com_SERVER_NAME: "site2.example.com"
site2.example.com_SECURITY_MODE: "detect"
Konfiguration für einen TCP/UDP-Server:
SERVER_TYPE: "stream"
SERVER_NAME: "stream.example.com"
LISTEN_STREAM: "yes"
LISTEN_STREAM_PORT: "1337"
USE_TCP: "yes"
USE_UDP: "no"
Anti DDoS
(PRO)
STREAM-Unterstützung
Provides enhanced protection against DDoS attacks by analyzing and filtering suspicious traffic.
Einstellung | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_ANTIDDOS |
no |
global | nein | Enable or disable anti DDoS protection to mitigate high traffic spikes. |
ANTIDDOS_METRICS_DICT_SIZE |
10M |
global | nein | Size of in-memory storage for DDoS metrics (e.g., 10M, 500k). |
ANTIDDOS_THRESHOLD |
100 |
global | nein | Maximum suspicious requests allowed from a single IP before blocking. |
ANTIDDOS_WINDOW_TIME |
10 |
global | nein | Time window (seconds) to detect abnormal request patterns. |
ANTIDDOS_STATUS_CODES |
429 403 444 |
global | nein | HTTP status codes treated as suspicious for DDoS analysis. |
ANTIDDOS_DISTINCT_IP |
5 |
global | nein | Minimum distinct IP count before enabling anti DDoS measures. |
Antibot
STREAM-Unterstützung
Angreifer nutzen oft automatisierte Tools (Bots), um zu versuchen, Ihre Website auszunutzen. Zum Schutz davor enthält BunkerWeb eine „Antibot“-Funktion, die Benutzer auffordert, zu beweisen, dass sie menschlich sind. Wenn ein Benutzer die Herausforderung besteht, erhält er Zugriff auf Ihre Website. Diese Funktion ist standardmäßig deaktiviert.
So funktioniert es:
- Wenn ein Benutzer Ihre Website besucht, prüft BunkerWeb, ob er bereits eine Antibot-Herausforderung bestanden hat.
- Andernfalls wird der Benutzer auf eine Herausforderungsseite umgeleitet.
- Der Benutzer muss die Herausforderung abschließen (z. B. ein CAPTCHA lösen, JavaScript ausführen).
- Wenn die Herausforderung erfolgreich ist, wird der Benutzer auf die ursprünglich angeforderte Seite umgeleitet und kann normal navigieren.
So verwenden Sie es
Befolgen Sie diese Schritte, um Antibot zu aktivieren und zu konfigurieren:
- Wählen Sie einen Herausforderungstyp: Entscheiden Sie sich für den zu verwendenden Mechanismus (z. B. captcha, hcaptcha, javascript).
- Aktivieren Sie die Funktion: Setzen Sie den Parameter
USE_ANTIBOT
in Ihrer BunkerWeb-Konfiguration auf den gewählten Typ. - Konfigurieren Sie die Einstellungen: Passen Sie bei Bedarf andere
ANTIBOT_*
-Parameter an. Für reCAPTCHA, hCaptcha, Turnstile und mCaptcha erstellen Sie ein Konto beim gewählten Dienst und erhalten Sie API-Schlüssel. - Wichtig: Stellen Sie sicher, dass
ANTIBOT_URI
eine eindeutige URL Ihrer Website ist und nirgendwo anders verwendet wird.
Über den Parameter ANTIBOT_URI
Stellen Sie sicher, dass ANTIBOT_URI
eine eindeutige URL Ihrer Website ist und nirgendwo anders verwendet wird.
Sitzungen in Cluster-Umgebungen
Die Antibot-Funktion verwendet Cookies, um zu verfolgen, ob ein Benutzer die Herausforderung abgeschlossen hat. Wenn Sie BunkerWeb in einem Cluster (mehrere Instanzen) betreiben, müssen Sie die Sitzungsverwaltung korrekt konfigurieren: Setzen Sie SESSIONS_SECRET
und SESSIONS_NAME
auf allen BunkerWeb-Instanzen auf dieselben Werte. Andernfalls könnten Benutzer aufgefordert werden, die Herausforderung zu wiederholen. Weitere Informationen zur Sitzungskonfiguration finden Sie hier.
Allgemeine Parameter
Die folgenden Parameter werden von allen Herausforderungsmechanismen gemeinsam genutzt:
Parameter | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
ANTIBOT_URI |
/challenge |
Multisite | nein | Herausforderungs-URL: Die URL, zu der Benutzer umgeleitet werden, um die Herausforderung abzuschließen. Stellen Sie sicher, dass diese URL nicht für andere Zwecke verwendet wird. |
ANTIBOT_TIME_RESOLVE |
60 |
Multisite | nein | Herausforderungs-Timeout: Maximale Zeit (in Sekunden) zum Abschließen der Herausforderung. Danach wird eine neue Herausforderung generiert. |
ANTIBOT_TIME_VALID |
86400 |
Multisite | nein | Herausforderungs-Gültigkeit: Dauer (in Sekunden), für die eine erfolgreiche Herausforderung gültig bleibt. Nach dieser Zeit wird eine neue Herausforderung erforderlich sein. |
Ausschließen von Traffic von Herausforderungen
BunkerWeb ermöglicht es, bestimmte Benutzer, IPs oder Anfragen anzugeben, die die Antibot-Herausforderung vollständig umgehen sollen. Nützlich für vertrauenswürdige Dienste, interne Netzwerke oder Seiten, die immer zugänglich sein sollen:
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
ANTIBOT_IGNORE_URI |
Multisite | nein | Ausgeschlossene URLs: Eine durch Leerzeichen getrennte Liste von URI-Regulären Ausdrücken, die die Herausforderung umgehen sollen. | |
ANTIBOT_IGNORE_IP |
Multisite | nein | Ausgeschlossene IPs: Eine durch Leerzeichen getrennte Liste von IP-Adressen oder CIDR-Bereichen, die die Herausforderung umgehen sollen. | |
ANTIBOT_IGNORE_RDNS |
Multisite | nein | Ausgeschlossene rDNS: Eine durch Leerzeichen getrennte Liste von Reverse-DNS-Suffixen, die die Herausforderung umgehen sollen. | |
ANTIBOT_RDNS_GLOBAL |
yes |
Multisite | nein | Nur öffentliche IPs: Wenn yes , werden rDNS-Prüfungen nur für öffentliche IPs durchgeführt. |
ANTIBOT_IGNORE_ASN |
Multisite | nein | Ausgeschlossene ASNs: Eine durch Leerzeichen getrennte Liste von ASN-Nummern, die die Herausforderung umgehen sollen. | |
ANTIBOT_IGNORE_USER_AGENT |
Multisite | nein | Ausgeschlossene User-Agents: Eine durch Leerzeichen getrennte Liste von User-Agent-Regex-Mustern, die die Herausforderung umgehen sollen. |
Beispiele:
-
ANTIBOT_IGNORE_URI: "^/api/ ^/webhook/ ^/assets/"
Schließt alle URIs aus, die mit/api/
,/webhook/
oder/assets/
beginnen. -
ANTIBOT_IGNORE_IP: "192.168.1.0/24 10.0.0.1"
Schließt das interne Netzwerk192.168.1.0/24
und die spezifische IP10.0.0.1
aus. -
ANTIBOT_IGNORE_RDNS: ".googlebot.com .bingbot.com"
Schließt Anfragen von Hosts aus, deren Reverse-DNS aufgooglebot.com
oderbingbot.com
endet. -
ANTIBOT_IGNORE_ASN: "15169 8075"
Schließt Anfragen von den ASNs 15169 (Google) und 8075 (Microsoft) aus. -
ANTIBOT_IGNORE_USER_AGENT: "^Mozilla.+Chrome.+Safari"
Schließt Anfragen aus, deren User-Agent dem angegebenen Regex-Muster entspricht.
Herausforderungsmechanismen
Die Cookie-Herausforderung ist ein leichter Mechanismus, der auf der Installation eines Cookies im Browser des Benutzers basiert. Wenn ein Benutzer auf die Website zugreift, sendet der Server ein Cookie an den Client. Bei nachfolgenden Anfragen überprüft der Server das Vorhandensein dieses Cookies, um zu bestätigen, dass der Benutzer legitim ist. Diese Methode ist einfach und effektiv für einen grundlegenden Schutz vor Bots, ohne zusätzliche Benutzerinteraktion zu erfordern.
So funktioniert es:
- Der Server generiert ein eindeutiges Cookie und sendet es an den Client.
- Der Client muss das Cookie bei nachfolgenden Anfragen zurücksenden.
- Wenn das Cookie fehlt oder ungültig ist, wird der Benutzer auf die Herausforderungsseite umgeleitet.
Parameter:
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_ANTIBOT |
no |
Multisite | nein | Antibot aktivieren: Auf cookie setzen, um diesen Mechanismus zu aktivieren. |
Die JavaScript-Herausforderung fordert den Client auf, eine Rechenaufgabe mithilfe von JavaScript zu lösen. Dieser Mechanismus stellt sicher, dass der Client JavaScript aktiviert hat und den erforderlichen Code ausführen kann, was für die meisten Bots in der Regel nicht möglich ist.
So funktioniert es:
- Der Server sendet ein JavaScript-Skript an den Client.
- Das Skript führt eine Rechenaufgabe aus (z. B. einen Hash) und übermittelt das Ergebnis an den Server.
- Der Server überprüft das Ergebnis, um die Legitimität des Clients zu bestätigen.
Hauptmerkmale:
- Die Herausforderung generiert dynamisch eine einzigartige Aufgabe für jeden Client.
- Die Rechenaufgabe beinhaltet ein Hashing mit spezifischen Bedingungen (z. B. das Finden eines Hashes mit einem bestimmten Präfix).
Parameter:
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_ANTIBOT |
no |
Multisite | nein | Antibot aktivieren: Auf javascript setzen, um diesen Mechanismus zu aktivieren. |
Die Captcha-Herausforderung ist ein hauseigener Mechanismus, der bildbasierte Herausforderungen generiert, die vollständig in Ihrer BunkerWeb-Umgebung gehostet werden. Er testet die Fähigkeit der Benutzer, zufällige Zeichen zu erkennen und zu interpretieren, wodurch sichergestellt wird, dass automatisierte Bots effektiv blockiert werden, ohne auf externe Dienste angewiesen zu sein.
So funktioniert es:
- Der Server generiert ein CAPTCHA-Bild mit zufälligen Zeichen.
- Der Benutzer muss die im Bild angezeigten Zeichen in ein Textfeld eingeben.
- Der Server validiert die Benutzereingabe anhand des generierten CAPTCHAs.
Hauptmerkmale:
- Vollständig selbst gehostet, wodurch die Notwendigkeit von Drittanbieter-APIs entfällt.
- Dynamisch generierte Herausforderungen gewährleisten die Einzigartigkeit für jede Benutzersitzung.
- Verwendet einen anpassbaren Zeichensatz für die CAPTCHA-Generierung.
Unterstützte Zeichen:
Das CAPTCHA-System unterstützt die folgenden Zeichentypen:
- Buchstaben: Alle Kleinbuchstaben (a-z) und Großbuchstaben (A-Z)
- Ziffern: 2, 3, 4, 5, 6, 7, 8, 9 (schließt 0 und 1 aus, um Verwechslungen zu vermeiden)
- Sonderzeichen:
+-/=%"'&_(),.;:?!§`^ÄÖÜßäöüé''‚""„
Eine vollständige Liste der unterstützten Zeichen finden Sie in der Zeichentabelle der für das CAPTCHA verwendeten Schriftart.
Parameter:
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_ANTIBOT |
no |
Multisite | nein | Antibot aktivieren: Auf captcha setzen, um diesen Mechanismus zu aktivieren. |
ANTIBOT_CAPTCHA_ALPHABET |
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ |
Multisite | nein | Captcha-Alphabet: Eine Zeichenkette, die zur Generierung des CAPTCHAs verwendet werden soll. Unterstützte Zeichen: alle Buchstaben (a-z, A-Z), die Ziffern 2-9 (schließt 0 und 1 aus) und die Sonderzeichen: +-/=%"'&_(),.;:?!§`^ÄÖÜßäöüé''‚""„ |
Googles reCAPTCHA bietet eine Benutzervalidierung, die im Hintergrund (v3) ausgeführt wird, um eine Verhaltensbewertung zuzuweisen. Eine Bewertung unterhalb des konfigurierten Schwellenwerts löst eine zusätzliche Überprüfung aus oder blockiert die Anfrage. Bei sichtbaren Herausforderungen (v2) müssen Benutzer mit dem reCAPTCHA-Widget interagieren, bevor sie fortfahren können.
Es gibt jetzt zwei Möglichkeiten, reCAPTCHA zu integrieren:
- Die klassische Version (Site-/Geheimschlüssel, v2/v3-Verifizierungsendpunkt)
- Die neue Version mit Google Cloud (Projekt-ID + API-Schlüssel). Die klassische Version bleibt verfügbar und kann mit ANTIBOT_RECAPTCHA_CLASSIC
aktiviert werden.
Für die klassische Version erhalten Sie Ihre Site- und Geheimschlüssel über die Google reCAPTCHA Admin-Konsole. Für die neue Version erstellen Sie einen reCAPTCHA-Schlüssel in Ihrem Google Cloud-Projekt und verwenden Sie die Projekt-ID sowie einen API-Schlüssel (siehe Google Cloud reCAPTCHA-Konsole). Ein Site-Schlüssel ist immer erforderlich.
Parameter:
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_ANTIBOT |
no |
Multisite | nein | Antibot aktivieren: Auf recaptcha setzen, um diesen Mechanismus zu aktivieren. |
ANTIBOT_RECAPTCHA_CLASSIC |
yes |
Multisite | nein | Klassisches reCAPTCHA verwenden. Auf no setzen, um die neue Google Cloud-basierte Version zu verwenden. |
ANTIBOT_RECAPTCHA_SITEKEY |
Multisite | nein | reCAPTCHA Site-Schlüssel. Für beide Versionen erforderlich. | |
ANTIBOT_RECAPTCHA_SECRET |
Multisite | nein | reCAPTCHA Geheimschlüssel. Nur für die klassische Version erforderlich. | |
ANTIBOT_RECAPTCHA_PROJECT_ID |
Multisite | nein | Google Cloud Projekt-ID. Nur für die neue Version erforderlich. | |
ANTIBOT_RECAPTCHA_API_KEY |
Multisite | nein | Google Cloud API-Schlüssel, der zum Aufrufen der reCAPTCHA Enterprise API verwendet wird. Nur für die neue Version erforderlich. | |
ANTIBOT_RECAPTCHA_JA3 |
Multisite | nein | Optionaler JA3 TLS-Fingerabdruck, der in Enterprise-Bewertungen enthalten sein soll. | |
ANTIBOT_RECAPTCHA_JA4 |
Multisite | nein | Optionaler JA4 TLS-Fingerabdruck, der in Enterprise-Bewertungen enthalten sein soll. | |
ANTIBOT_RECAPTCHA_SCORE |
0.7 |
Multisite | nein | Mindestpunktzahl, die zum Bestehen erforderlich ist (gilt für klassische v3 und die neue Version). |
Wenn aktiviert, bietet hCaptcha eine effektive Alternative zu reCAPTCHA, indem es Benutzerinteraktionen überprüft, ohne auf einen Bewertungsmechanismus angewiesen zu sein. Es fordert Benutzer mit einem einfachen, interaktiven Test heraus, um ihre Legitimität zu bestätigen.
Um hCaptcha mit BunkerWeb zu integrieren, müssen Sie die erforderlichen Anmeldeinformationen vom hCaptcha-Dashboard unter hCaptcha abrufen. Diese Informationen umfassen einen Site-Schlüssel und einen Geheimschlüssel.
Parameter:
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_ANTIBOT |
no |
Multisite | nein | Antibot aktivieren: Auf hcaptcha setzen, um diesen Mechanismus zu aktivieren. |
ANTIBOT_HCAPTCHA_SITEKEY |
Multisite | nein | hCaptcha Site-Schlüssel. | |
ANTIBOT_HCAPTCHA_SECRET |
Multisite | nein | hCaptcha Geheimschlüssel. |
Turnstile ist ein moderner, datenschutzfreundlicher Herausforderungsmechanismus, der auf der Technologie von Cloudflare basiert, um automatisierten Traffic zu erkennen und zu blockieren. Er validiert Benutzerinteraktionen transparent und im Hintergrund, wodurch die Reibung für legitime Benutzer reduziert und Bots effektiv abgeschreckt werden.
Um Turnstile mit BunkerWeb zu integrieren, stellen Sie sicher, dass Sie die erforderlichen Anmeldeinformationen von Cloudflare Turnstile erhalten.
Parameter:
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_ANTIBOT |
no |
Multisite | nein | Antibot aktivieren: Auf turnstile setzen, um diesen Mechanismus zu aktivieren. |
ANTIBOT_TURNSTILE_SITEKEY |
Multisite | nein | Turnstile Site-Schlüssel (Cloudflare). | |
ANTIBOT_TURNSTILE_SECRET |
Multisite | nein | Turnstile Geheimschlüssel (Cloudflare). |
mCaptcha ist ein alternativer CAPTCHA-Herausforderungsmechanismus, der die Legitimität von Benutzern überprüft, indem er einen interaktiven Test präsentiert, ähnlich wie andere Antibot-Lösungen. Wenn aktiviert, fordert es Benutzer mit einem von mCaptcha bereitgestellten CAPTCHA heraus, um sicherzustellen, dass nur authentische Benutzer die automatisierten Sicherheitskontrollen umgehen.
mCaptcha ist datenschutzfreundlich konzipiert. Es ist vollständig DSGVO-konform und stellt sicher, dass alle am Herausforderungsprozess beteiligten Benutzerdaten strenge Datenschutzstandards erfüllen. Darüber hinaus bietet mCaptcha die Flexibilität, selbst gehostet zu werden, sodass Organisationen die volle Kontrolle über ihre Daten und Infrastruktur behalten. Diese Selbsthosting-Fähigkeit verbessert nicht nur den Datenschutz, sondern optimiert auch die Leistung und Anpassung an spezifische Bereitstellungsanforderungen.
Um mCaptcha mit BunkerWeb zu integrieren, müssen Sie die erforderlichen Anmeldeinformationen von der mCaptcha-Plattform oder Ihrem eigenen Anbieter abrufen. Diese Informationen umfassen einen Site-Schlüssel und einen Geheimschlüssel zur Überprüfung.
Parameter:
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_ANTIBOT |
no |
Multisite | nein | Antibot aktivieren: Auf mcaptcha setzen, um diesen Mechanismus zu aktivieren. |
ANTIBOT_MCAPTCHA_SITEKEY |
Multisite | nein | mCaptcha Site-Schlüssel. | |
ANTIBOT_MCAPTCHA_SECRET |
Multisite | nein | mCaptcha Geheimschlüssel. | |
ANTIBOT_MCAPTCHA_URL |
https://demo.mcaptcha.org |
Multisite | nein | Zu verwendende Domain für mCaptcha. |
Siehe Allgemeine Parameter für zusätzliche Optionen.
Konfigurationsbeispiele
USE_ANTIBOT: "cookie"
ANTIBOT_URI: "/challenge"
ANTIBOT_TIME_RESOLVE: "60"
ANTIBOT_TIME_VALID: "86400"
USE_ANTIBOT: "javascript"
ANTIBOT_URI: "/challenge"
ANTIBOT_TIME_RESOLVE: "60"
ANTIBOT_TIME_VALID: "86400"
USE_ANTIBOT: "captcha"
ANTIBOT_URI: "/challenge"
ANTIBOT_TIME_RESOLVE: "60"
ANTIBOT_TIME_VALID: "86400"
ANTIBOT_CAPTCHA_ALPHABET: "23456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"
Hinweis: Das obige Beispiel verwendet die Ziffern 2-9 und alle Buchstaben, die häufig für CAPTCHAs verwendet werden. Sie können das Alphabet bei Bedarf anpassen, um Sonderzeichen einzuschließen.
Beispielkonfiguration für das klassische reCAPTCHA (Site-/Geheimschlüssel):
USE_ANTIBOT: "recaptcha"
ANTIBOT_RECAPTCHA_CLASSIC: "yes"
ANTIBOT_RECAPTCHA_SITEKEY: "your-site-key"
ANTIBOT_RECAPTCHA_SECRET: "your-secret-key"
ANTIBOT_RECAPTCHA_SCORE: "0.7"
ANTIBOT_URI: "/challenge"
ANTIBOT_TIME_RESOLVE: "60"
ANTIBOT_TIME_VALID: "86400"
Beispielkonfiguration für das neue Google Cloud-basierte reCAPTCHA (Projekt-ID + API-Schlüssel):
USE_ANTIBOT: "recaptcha"
ANTIBOT_RECAPTCHA_CLASSIC: "no"
ANTIBOT_RECAPTCHA_SITEKEY: "your-site-key"
ANTIBOT_RECAPTCHA_PROJECT_ID: "your-gcp-project-id"
ANTIBOT_RECAPTCHA_API_KEY: "your-gcp-api-key"
# Optionale Fingerabdrücke zur Verbesserung der Enterprise-Bewertungen
# ANTIBOT_RECAPTCHA_JA3: "<ja3-fingerprint>"
# ANTIBOT_RECAPTCHA_JA4: "<ja4-fingerprint>"
ANTIBOT_RECAPTCHA_SCORE: "0.7"
ANTIBOT_URI: "/challenge"
ANTIBOT_TIME_RESOLVE: "60"
ANTIBOT_TIME_VALID: "86400"
USE_ANTIBOT: "hcaptcha"
ANTIBOT_HCAPTCHA_SITEKEY: "your-site-key"
ANTIBOT_HCAPTCHA_SECRET: "your-secret-key"
ANTIBOT_URI: "/challenge"
ANTIBOT_TIME_RESOLVE: "60"
ANTIBOT_TIME_VALID: "86400"
USE_ANTIBOT: "turnstile"
ANTIBOT_TURNSTILE_SITEKEY: "your-site-key"
ANTIBOT_TURNSTILE_SECRET: "your-secret-key"
ANTIBOT_URI: "/challenge"
ANTIBOT_TIME_RESOLVE: "60"
ANTIBOT_TIME_VALID: "86400"
USE_ANTIBOT: "mcaptcha"
ANTIBOT_MCAPTCHA_SITEKEY: "your-site-key"
ANTIBOT_MCAPTCHA_SECRET: "your-secret-key"
ANTIBOT_MCAPTCHA_URL: "https://demo.mcaptcha.org"
ANTIBOT_URI: "/challenge"
ANTIBOT_TIME_RESOLVE: "60"
ANTIBOT_TIME_VALID: "86400"
Auth basic
STREAM-Unterstützung
Das Auth Basic-Plugin bietet eine HTTP-Basisauthentifizierung zum Schutz Ihrer Website oder bestimmter Ressourcen. Diese Funktion fügt eine zusätzliche Sicherheitsebene hinzu, indem sie von den Benutzern die Eingabe eines Benutzernamens und eines Passworts verlangt, bevor sie auf geschützte Inhalte zugreifen können. Diese Art der Authentifizierung ist einfach zu implementieren und wird von den Browsern weitgehend unterstützt.
So funktioniert es:
- Wenn ein Benutzer versucht, auf einen geschützten Bereich Ihrer Website zuzugreifen, sendet der Server eine Authentifizierungsaufforderung.
- Der Browser zeigt ein Anmeldedialogfeld an, in dem der Benutzer zur Eingabe von Benutzername und Passwort aufgefordert wird.
- Der Benutzer gibt seine Anmeldedaten ein, die an den Server gesendet werden.
- Wenn die Anmeldeinformationen gültig sind, erhält der Benutzer Zugriff auf den angeforderten Inhalt.
- Wenn die Anmeldeinformationen ungültig sind, wird dem Benutzer eine Fehlermeldung mit dem Statuscode 401 Unauthorized angezeigt.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Auth Basic-Authentifizierung zu aktivieren und zu konfigurieren:
- Aktivieren Sie die Funktion: Setzen Sie die Einstellung
USE_AUTH_BASIC
in Ihrer BunkerWeb-Konfiguration aufyes
. - Wählen Sie den Schutzumfang: Entscheiden Sie, ob Sie Ihre gesamte Website oder nur bestimmte URLs schützen möchten, indem Sie die Einstellung
AUTH_BASIC_LOCATION
konfigurieren. - Anmeldeinformationen definieren: Richten Sie mindestens ein Paar aus Benutzername und Passwort mit den Einstellungen
AUTH_BASIC_USER
undAUTH_BASIC_PASSWORD
ein. - Passen Sie die Nachricht an: Ändern Sie optional den
AUTH_BASIC_TEXT
, um eine benutzerdefinierte Nachricht in der Anmeldeaufforderung anzuzeigen.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_AUTH_BASIC |
no |
multisite | nein | Auth Basic aktivieren: Auf yes setzen, um die Basisauthentifizierung zu aktivieren. |
AUTH_BASIC_LOCATION |
sitewide |
multisite | nein | Schutzumfang: Auf sitewide setzen, um die gesamte Website zu schützen, oder einen URL-Pfad angeben (z.B. /admin ), um nur bestimmte Bereiche zu schützen. |
AUTH_BASIC_USER |
changeme |
multisite | ja | Benutzername: Der für die Authentifizierung erforderliche Benutzername. Sie können mehrere Paare aus Benutzername und Passwort definieren. |
AUTH_BASIC_PASSWORD |
changeme |
multisite | ja | Passwort: Das für die Authentifizierung erforderliche Passwort. Jedes Passwort korrespondiert mit einem Benutzernamen. |
AUTH_BASIC_TEXT |
Restricted area |
multisite | nein | Aufforderungstext: Die Nachricht, die in der dem Benutzer angezeigten Authentifizierungsaufforderung erscheint. |
Sicherheitshinweise
Die HTTP-Basisauthentifizierung überträgt Anmeldeinformationen, die in Base64 kodiert (nicht verschlüsselt) sind. Obwohl dies bei Verwendung über HTTPS akzeptabel ist, sollte es über reines HTTP nicht als sicher angesehen werden. Aktivieren Sie immer SSL/TLS, wenn Sie die Basisauthentifizierung verwenden.
Verwendung mehrerer Anmeldeinformationen
Sie können mehrere Paare aus Benutzername/Passwort für den Zugriff konfigurieren. Jede AUTH_BASIC_USER
-Einstellung sollte eine entsprechende AUTH_BASIC_PASSWORD
-Einstellung haben.
Beispielkonfigurationen
So schützen Sie Ihre gesamte Website mit einem einzigen Satz von Anmeldeinformationen:
USE_AUTH_BASIC: "yes"
AUTH_BASIC_LOCATION: "sitewide"
AUTH_BASIC_USER: "admin"
AUTH_BASIC_PASSWORD: "secure_password"
AUTH_BASIC_TEXT: "Admin Access Only"
Um nur einen bestimmten Pfad zu schützen, wie z.B. ein Admin-Panel:
USE_AUTH_BASIC: "yes"
AUTH_BASIC_LOCATION: "/admin/"
AUTH_BASIC_USER: "admin"
AUTH_BASIC_PASSWORD: "secure_password"
AUTH_BASIC_TEXT: "Admin Access Only"
So richten Sie mehrere Benutzer mit unterschiedlichen Anmeldeinformationen ein:
USE_AUTH_BASIC: "yes"
AUTH_BASIC_LOCATION: "sitewide"
AUTH_BASIC_TEXT: "Staff Area"
# Erster Benutzer
AUTH_BASIC_USER: "admin"
AUTH_BASIC_PASSWORD: "admin_password"
# Zweiter Benutzer
AUTH_BASIC_USER_2: "editor"
AUTH_BASIC_PASSWORD_2: "editor_password"
# Dritter Benutzer
AUTH_BASIC_USER_3: "viewer"
AUTH_BASIC_PASSWORD_3: "viewer_password"
Backup
STREAM-Unterstützung
Das Backup-Plugin bietet eine automatisierte Backup-Lösung zum Schutz Ihrer BunkerWeb-Daten. Diese Funktion gewährleistet die Sicherheit und Verfügbarkeit Ihrer wichtigen Datenbank, indem sie regelmäßige Backups nach Ihrem bevorzugten Zeitplan erstellt. Backups werden an einem bestimmten Ort gespeichert und können sowohl durch automatisierte Prozesse als auch durch manuelle Befehle einfach verwaltet werden.
So funktioniert es:
- Ihre Datenbank wird automatisch gemäß dem von Ihnen festgelegten Zeitplan (täglich, wöchentlich oder monatlich) gesichert.
- Backups werden in einem angegebenen Verzeichnis auf Ihrem System gespeichert.
- Alte Backups werden automatisch basierend auf Ihren Aufbewahrungseinstellungen rotiert.
- Sie können jederzeit manuell Backups erstellen, vorhandene Backups auflisten oder eine Wiederherstellung aus einem Backup durchführen.
- Vor jeder Wiederherstellung wird der aktuelle Zustand als Sicherheitsmaßnahme automatisch gesichert.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Backup-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Die Backup-Funktion ist standardmäßig aktiviert. Bei Bedarf können Sie dies mit der Einstellung
USE_BACKUP
steuern. - Backup-Zeitplan konfigurieren: Wählen Sie mit dem Parameter
BACKUP_SCHEDULE
, wie oft Backups durchgeführt werden sollen. - Aufbewahrungsrichtlinie festlegen: Geben Sie mit der Einstellung
BACKUP_ROTATION
an, wie viele Backups aufbewahrt werden sollen. - Speicherort festlegen: Wählen Sie mit der Einstellung
BACKUP_DIRECTORY
, wo die Backups gespeichert werden sollen. - CLI-Befehle verwenden: Verwalten Sie Backups bei Bedarf manuell mit den
bwcli plugin backup
-Befehlen.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_BACKUP |
yes |
global | nein | Backup aktivieren: Auf yes setzen, um automatische Backups zu aktivieren. |
BACKUP_SCHEDULE |
daily |
global | nein | Backup-Frequenz: Wie oft Backups durchgeführt werden sollen. Optionen: daily , weekly oder monthly . |
BACKUP_ROTATION |
7 |
global | nein | Backup-Aufbewahrung: Die Anzahl der aufzubewahrenden Backup-Dateien. Ältere Backups werden automatisch gelöscht. |
BACKUP_DIRECTORY |
/var/lib/bunkerweb/backups |
global | nein | Backup-Speicherort: Das Verzeichnis, in dem die Backup-Dateien gespeichert werden. |
Befehlszeilenschnittstelle
Das Backup-Plugin bietet mehrere CLI-Befehle zur Verwaltung Ihrer Backups:
# Alle verfügbaren Backups auflisten
bwcli plugin backup list
# Ein manuelles Backup erstellen
bwcli plugin backup save
# Ein Backup an einem benutzerdefinierten Ort erstellen
bwcli plugin backup save --directory /pfad/zum/benutzerdefinierten/ort
# Aus dem neuesten Backup wiederherstellen
bwcli plugin backup restore
# Aus einer bestimmten Backup-Datei wiederherstellen
bwcli plugin backup restore /pfad/zum/backup/backup-sqlite-2023-08-15_12-34-56.zip
Sicherheit geht vor
Vor jeder Wiederherstellung erstellt das Backup-Plugin automatisch ein Backup des aktuellen Zustands Ihrer Datenbank an einem temporären Ort. Dies bietet eine zusätzliche Absicherung für den Fall, dass Sie die Wiederherstellung rückgängig machen müssen.
Datenbankkompatibilität
Das Backup-Plugin unterstützt SQLite, MySQL/MariaDB und PostgreSQL-Datenbanken. Oracle-Datenbanken werden derzeit für Backup- und Wiederherstellungsvorgänge nicht unterstützt.
Beispielkonfigurationen
Standardkonfiguration, die tägliche Backups erstellt und die letzten 7 Dateien aufbewahrt:
USE_BACKUP: "yes"
BACKUP_SCHEDULE: "daily"
BACKUP_ROTATION: "7"
BACKUP_DIRECTORY: "/var/lib/bunkerweb/backups"
Konfiguration für seltenere Backups mit längerer Aufbewahrung:
USE_BACKUP: "yes"
BACKUP_SCHEDULE: "weekly"
BACKUP_ROTATION: "12"
BACKUP_DIRECTORY: "/var/lib/bunkerweb/backups"
Konfiguration für monatliche Backups, die an einem benutzerdefinierten Ort gespeichert werden:
USE_BACKUP: "yes"
BACKUP_SCHEDULE: "monthly"
BACKUP_ROTATION: "24"
BACKUP_DIRECTORY: "/mnt/backup-drive/bunkerweb-backups"
Backup S3
(PRO)
STREAM-Unterstützung
Automatically backup your data to an S3 bucket
Einstellung | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_BACKUP_S3 |
no |
global | nein | Enable or disable the S3 backup feature |
BACKUP_S3_SCHEDULE |
daily |
global | nein | The frequency of the backup |
BACKUP_S3_ROTATION |
7 |
global | nein | The number of backups to keep |
BACKUP_S3_ENDPOINT |
global | nein | The S3 endpoint | |
BACKUP_S3_BUCKET |
global | nein | The S3 bucket | |
BACKUP_S3_DIR |
global | nein | The S3 directory | |
BACKUP_S3_REGION |
global | nein | The S3 region | |
BACKUP_S3_ACCESS_KEY_ID |
global | nein | The S3 access key ID | |
BACKUP_S3_ACCESS_KEY_SECRET |
global | nein | The S3 access key secret | |
BACKUP_S3_COMP_LEVEL |
6 |
global | nein | The compression level of the backup zip file |
Bad behavior
STREAM-Unterstützung
Das Bad Behavior-Plugin schützt Ihre Website, indem es IP-Adressen, die innerhalb eines bestimmten Zeitraums zu viele Fehler oder „schlechte“ HTTP-Statuscodes erzeugen, automatisch erkennt und sperrt. Dies hilft bei der Abwehr von Brute-Force-Angriffen, Web-Scrapern, Schwachstellen-Scannern und anderen böswilligen Aktivitäten, die zahlreiche Fehlerantworten erzeugen könnten.
Angreifer erzeugen oft „verdächtige“ HTTP-Statuscodes, wenn sie nach Schwachstellen suchen oder diese ausnutzen – Codes, die ein typischer Benutzer innerhalb eines bestimmten Zeitrahmens wahrscheinlich nicht auslösen würde. Durch die Erkennung dieses Verhaltens kann BunkerWeb die betreffende IP-Adresse automatisch sperren und den Angreifer zwingen, eine neue IP-Adresse zu verwenden, um seine Versuche fortzusetzen.
So funktioniert es:
- Das Plugin überwacht die HTTP-Antworten Ihrer Website.
- Wenn ein Besucher einen „schlechten“ HTTP-Statuscode (wie 400, 401, 403, 404 usw.) erhält, wird der Zähler für diese IP-Adresse erhöht.
- Wenn eine IP-Adresse den konfigurierten Schwellenwert für schlechte Statuscodes innerhalb des angegebenen Zeitraums überschreitet, wird die IP automatisch gesperrt.
- Gesperrte IPs können je nach Konfiguration entweder auf Dienstebene (nur für die spezifische Website) oder global (über alle Websites hinweg) blockiert werden.
- Sperren laufen automatisch nach der konfigurierten Sperrdauer ab oder bleiben dauerhaft, wenn sie mit
0
konfiguriert sind.
Wichtige Vorteile
- Automatischer Schutz: Erkennt und blockiert potenziell bösartige Clients ohne manuellen Eingriff.
- Anpassbare Regeln: Passen Sie genau an, was als „schlechtes Verhalten“ gilt, basierend auf Ihren spezifischen Anforderungen.
- Ressourcenschonung: Verhindert, dass böswillige Akteure Serverressourcen durch wiederholte ungültige Anfragen verbrauchen.
- Flexibler Geltungsbereich: Wählen Sie, ob Sperren nur für den aktuellen Dienst oder global für alle Dienste gelten sollen.
- Kontrolle der Sperrdauer: Legen Sie temporäre Sperren fest, die automatisch nach der konfigurierten Dauer ablaufen, oder permanente Sperren, die bis zur manuellen Aufhebung bestehen bleiben.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Bad Behavior-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Die Bad Behavior-Funktion ist standardmäßig aktiviert. Bei Bedarf können Sie dies mit der Einstellung
USE_BAD_BEHAVIOR
steuern. - Statuscodes konfigurieren: Definieren Sie mit der Einstellung
BAD_BEHAVIOR_STATUS_CODES
, welche HTTP-Statuscodes als „schlecht“ gelten sollen. - Schwellenwerte festlegen: Bestimmen Sie mit der Einstellung
BAD_BEHAVIOR_THRESHOLD
, wie viele „schlechte“ Antworten eine Sperre auslösen sollen. - Zeiträume konfigurieren: Geben Sie die Dauer für die Zählung schlechter Antworten und die Sperrdauer mit den Einstellungen
BAD_BEHAVIOR_COUNT_TIME
undBAD_BEHAVIOR_BAN_TIME
an. - Sperrbereich wählen: Entscheiden Sie mit der Einstellung
BAD_BEHAVIOR_BAN_SCOPE
, ob die Sperren nur für den aktuellen Dienst oder global für alle Dienste gelten sollen.
Stream-Modus
Im Stream-Modus wird nur der Statuscode 444
als „schlecht“ angesehen und löst dieses Verhalten aus.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_BAD_BEHAVIOR |
yes |
multisite | nein | Bad Behavior aktivieren: Auf yes setzen, um die Funktion zur Erkennung und Sperrung von schlechtem Verhalten zu aktivieren. |
BAD_BEHAVIOR_STATUS_CODES |
400 401 403 404 405 429 444 |
multisite | nein | Schlechte Statuscodes: Liste der HTTP-Statuscodes, die als „schlechtes“ Verhalten gezählt werden, wenn sie an einen Client zurückgegeben werden. |
BAD_BEHAVIOR_THRESHOLD |
10 |
multisite | nein | Schwellenwert: Die Anzahl der „schlechten“ Statuscodes, die eine IP innerhalb des Zählzeitraums erzeugen kann, bevor sie gesperrt wird. |
BAD_BEHAVIOR_COUNT_TIME |
60 |
multisite | nein | Zählzeitraum: Das Zeitfenster (in Sekunden), in dem schlechte Statuscodes auf den Schwellenwert angerechnet werden. |
BAD_BEHAVIOR_BAN_TIME |
86400 |
multisite | nein | Sperrdauer: Wie lange (in Sekunden) eine IP nach Überschreiten des Schwellenwerts gesperrt bleibt. Standard ist 24 Stunden (86400 Sekunden). 0 für permanente Sperren. |
BAD_BEHAVIOR_BAN_SCOPE |
service |
global | nein | Sperrbereich: Legt fest, ob Sperren nur für den aktuellen Dienst (service ) oder für alle Dienste (global ) gelten. |
Falsch-Positive
Seien Sie vorsichtig bei der Einstellung des Schwellenwerts und der Zählzeit. Zu niedrige Werte können versehentlich legitime Benutzer sperren, die beim Surfen auf Ihrer Website auf Fehler stoßen.
Anpassen Ihrer Konfiguration
Beginnen Sie mit konservativen Einstellungen (höherer Schwellenwert, kürzere Sperrzeit) und passen Sie diese je nach Ihren spezifischen Bedürfnissen und Verkehrsmustern an. Überwachen Sie Ihre Protokolle, um sicherzustellen, dass legitime Benutzer nicht fälschlicherweise gesperrt werden.
Beispielkonfigurationen
Die Standardkonfiguration bietet einen ausgewogenen Ansatz, der für die meisten Websites geeignet ist:
USE_BAD_BEHAVIOR: "yes"
BAD_BEHAVIOR_STATUS_CODES: "400 401 403 404 405 429 444"
BAD_BEHAVIOR_THRESHOLD: "10"
BAD_BEHAVIOR_COUNT_TIME: "60"
BAD_BEHAVIOR_BAN_TIME: "86400"
BAD_BEHAVIOR_BAN_SCOPE: "service"
Für Hochsicherheitsanwendungen, bei denen Sie potenzielle Bedrohungen aggressiver sperren möchten:
USE_BAD_BEHAVIOR: "yes"
BAD_BEHAVIOR_STATUS_CODES: "400 401 403 404 405 429 444 500 502 503"
BAD_BEHAVIOR_THRESHOLD: "5"
BAD_BEHAVIOR_COUNT_TIME: "120"
BAD_BEHAVIOR_BAN_TIME: "604800" # 7 Tage
BAD_BEHAVIOR_BAN_SCOPE: "global" # Sperre über alle Dienste hinweg
Für Websites mit hohem legitimen Datenverkehr, bei denen Sie Falsch-Positive vermeiden möchten:
USE_BAD_BEHAVIOR: "yes"
BAD_BEHAVIOR_STATUS_CODES: "401 403 429" # Nur unautorisierte, verbotene und ratenlimitierte zählen
BAD_BEHAVIOR_THRESHOLD: "20"
BAD_BEHAVIOR_COUNT_TIME: "30"
BAD_BEHAVIOR_BAN_TIME: "3600" # 1 Stunde
BAD_BEHAVIOR_BAN_SCOPE: "service"
Für Szenarien, in denen erkannte Angreifer dauerhaft gesperrt werden sollen, bis sie manuell entsperrt werden:
USE_BAD_BEHAVIOR: "yes"
BAD_BEHAVIOR_STATUS_CODES: "400 401 403 404 405 429 444"
BAD_BEHAVIOR_THRESHOLD: "10"
BAD_BEHAVIOR_COUNT_TIME: "60"
BAD_BEHAVIOR_BAN_TIME: "0" # Permanente Sperre (läuft nie ab)
BAD_BEHAVIOR_BAN_SCOPE: "global" # Sperre über alle Dienste hinweg
Blacklist
STREAM-Unterstützung
Das Blacklist-Plugin schützt Ihre Website, indem es den Zugriff basierend auf verschiedenen Client-Attributen blockiert. Diese Funktion wehrt bekannte bösartige Entitäten, Scanner und verdächtige Besucher ab, indem sie den Zugriff basierend auf IP-Adressen, Netzwerken, Reverse-DNS-Einträgen (rDNS), ASNs, User-Agents und spezifischen URI-Mustern verweigert.
So funktioniert's:[1][2][3]
- Das Plugin überprüft eingehende Anfragen anhand mehrerer Blacklist-Kriterien (IP-Adressen, Netzwerke, rDNS, ASN, User-Agent oder URI-Muster).
- Blacklists können direkt in Ihrer Konfiguration angegeben oder von externen URLs geladen werden.
- Wenn ein Besucher einer Blacklist-Regel entspricht (und keiner Ignorier-Regel), wird der Zugriff verweigert.
- Blacklists werden automatisch in regelmäßigen Abständen von den konfigurierten URLs aktualisiert.[4][5][6][7][8]
- Sie können genau anpassen, welche Kriterien überprüft und ignoriert werden, basierend auf Ihren spezifischen Sicherheitsanforderungen.
So verwenden Sie es
Befolgen Sie diese Schritte, um die Blacklist-Funktion einzurichten und zu verwenden:
- Funktion aktivieren: Die Blacklist-Funktion ist standardmäßig aktiviert. Bei Bedarf können Sie sie mit dem Parameter
USE_BLACKLIST
steuern. - Blockierregeln konfigurieren: Definieren Sie, welche IPs, Netzwerke, rDNS-Muster, ASNs, User-Agents oder URIs blockiert werden sollen.
- Ignorierregeln einrichten: Geben Sie Ausnahmen an, die die Blacklist-Überprüfungen umgehen sollen.
- Externe Quellen hinzufügen: Konfigurieren Sie URLs, um Blacklist-Daten automatisch herunterzuladen und zu aktualisieren.[4][5][6][7][8]
- Effektivität überwachen: Konsultieren Sie die Web-Oberfläche, um Statistiken über blockierte Anfragen anzuzeigen.
Stream-Modus
Im Stream-Modus werden nur Überprüfungen nach IP, rDNS und ASN durchgeführt.
Konfigurationsparameter[9][10][11][12][13][14][15][16][17]
Allgemein
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_BLACKLIST |
yes |
Multisite | Nein | Blacklist aktivieren: Setzen Sie auf yes , um die Blacklist-Funktion zu aktivieren. |
BLACKLIST_COMMUNITY_LISTS |
ip:danmeuk-tor-exit ua:mitchellkrogza-bad-user-agents |
Multisite | Nein | Community-Blacklists: Wählen Sie vorkonfigurierte und von der Community gepflegte Blacklists aus, die in die Blockierung einbezogen werden sollen. |
Was es bewirkt: Ermöglicht Ihnen, schnell gut gepflegte und von der Community stammende Blacklists hinzuzufügen, ohne die URLs manuell konfigurieren zu müssen.
Der Parameter BLACKLIST_COMMUNITY_LISTS
ermöglicht Ihnen die Auswahl aus ausgewählten Blacklist-Quellen. Die verfügbaren Optionen umfassen:
ID | Beschreibung | Quelle |
---|---|---|
ip:laurent-minne-data-shield-aggressive |
Data-Shield IPv4 Blocklist. DST = Europa | https://raw.githubusercontent.com/duggytuxy/Data-Shield_IPv4_Blocklist/refs/heads/main/prod_data-shield_ipv4_blocklist.txt |
ip:danmeuk-tor-exit |
IP-Adressen von Tor-Exit-Nodes (dan.me.uk) | https://www.dan.me.uk/torlist/?exit |
ua:mitchellkrogza-bad-user-agents |
Nginx Block Bad Bots, Spam Referrer Blocker, Vulnerability Scanners, User-Agents, Malware, Adware, Ransomware, Malicious Sites, mit Anti-DDOS, Wordpress Theme Detector Blocking und Fail2Ban Jail für Wiederholungstäter | https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/_generator_lists/bad-user-agents.list |
Konfiguration: Geben Sie mehrere Listen durch Leerzeichen getrennt an. Zum Beispiel:
BLACKLIST_COMMUNITY_LISTS: "ip:danmeuk-tor-exit ua:mitchellkrogza-bad-user-agents"
Community-Listen vs. manuelle Konfiguration
Community-Blacklists bieten eine bequeme Möglichkeit, mit bewährten Blacklist-Quellen zu beginnen. Sie können diese parallel zu manuellen URL-Konfigurationen für maximale Flexibilität verwenden.
=== "IP-Adresse"[18][19][20][21][22] Was es bewirkt: Blockiert Besucher basierend auf ihrer IP-Adresse oder ihrem Netzwerk.
| Parameter | Standard | Kontext | Mehrfach | Beschreibung |
| :------------------------- | :------------------------------------ | :-------- | :------- | :--------------------------------------------------------------------------------------------------------------------------- |
| `BLACKLIST_IP` | | Multisite | Nein | **IP-Blacklist:** Liste von IP-Adressen oder Netzwerken (CIDR-Notation) zum Blockieren, durch Leerzeichen getrennt. |
| `BLACKLIST_IGNORE_IP` | | Multisite | Nein | **IP-Ignorierliste:** Liste von IP-Adressen oder Netzwerken, die IP-Blacklist-Überprüfungen umgehen sollen. |
| `BLACKLIST_IP_URLS` | `https://www.dan.me.uk/torlist/?exit` | Multisite | Nein | **IP-Blacklist-URLs:** Liste von URLs, die zu blockierende IP-Adressen oder Netzwerke enthalten, durch Leerzeichen getrennt. |
| `BLACKLIST_IGNORE_IP_URLS` | | Multisite | Nein | **IP-Ignorierlisten-URLs:** Liste von URLs, die zu ignorierende IP-Adressen oder Netzwerke enthalten. |
Der Standardparameter `BLACKLIST_IP_URLS` enthält eine URL, die eine **Liste bekannter Tor-Exit-Nodes** bereitstellt. Dies ist eine häufige Quelle für bösartigen Datenverkehr und ein guter Ausgangspunkt für viele Websites.
=== "Reverse DNS"[23][24][25][26][27] Was es bewirkt: Blockiert Besucher basierend auf ihrem Reverse-Domain-Namen. Dies ist nützlich, um bekannte Scanner und Crawler basierend auf ihren Organisationsdomänen zu blockieren.
| Parameter | Standard | Kontext | Mehrfach | Beschreibung |
| :--------------------------- | :---------------------- | :-------- | :------- | :--------------------------------------------------------------------------------------------------------- |
| `BLACKLIST_RDNS` | `.shodan.io .censys.io` | Multisite | Nein | **rDNS-Blacklist:** Liste von Reverse-DNS-Suffixen zum Blockieren, durch Leerzeichen getrennt. |
| `BLACKLIST_RDNS_GLOBAL` | `yes` | Multisite | Nein | **Nur globales rDNS:** Führt rDNS-Überprüfungen nur für globale IP-Adressen durch, wenn auf `yes` gesetzt. |
| `BLACKLIST_IGNORE_RDNS` | | Multisite | Nein | **rDNS-Ignorierliste:** Liste von Reverse-DNS-Suffixen, die rDNS-Blacklist-Überprüfungen umgehen sollen. |
| `BLACKLIST_RDNS_URLS` | | Multisite | Nein | **rDNS-Blacklist-URLs:** Liste von URLs, die zu blockierende Reverse-DNS-Suffixe enthalten. |
| `BLACKLIST_IGNORE_RDNS_URLS` | | Multisite | Nein | **rDNS-Ignorierlisten-URLs:** Liste von URLs, die zu ignorierende Reverse-DNS-Suffixe enthalten. |
Der Standardparameter `BLACKLIST_RDNS` enthält Domänen gängiger Scanner wie **Shodan** und **Censys**. Diese werden oft von Sicherheitsforschern und Scannern verwendet, um anfällige Websites zu identifizieren.
Was es bewirkt: Blockiert Besucher von bestimmten Netzwerkanbietern. ASNs sind wie Postleitzahlen für das Internet – sie identifizieren, zu welchem Anbieter oder welcher Organisation eine IP gehört.
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
BLACKLIST_ASN |
Multisite | Nein | ASN-Blacklist: Liste von autonomen Systemnummern zum Blockieren, durch Leerzeichen getrennt. | |
BLACKLIST_IGNORE_ASN |
Multisite | Nein | ASN-Ignorierliste: Liste von ASNs, die ASN-Blacklist-Überprüfungen umgehen sollen. | |
BLACKLIST_ASN_URLS |
Multisite | Nein | ASN-Blacklist-URLs: Liste von URLs, die zu blockierende ASNs enthalten. | |
BLACKLIST_IGNORE_ASN_URLS |
Multisite | Nein | ASN-Ignorierlisten-URLs: Liste von URLs, die zu ignorierende ASNs enthalten. |
=== "User-Agent"[28][29][30][31][32] Was es bewirkt: Blockiert Besucher basierend auf dem Browser oder Tool, das sie angeblich verwenden. Dies ist effektiv gegen Bots, die sich ehrlich identifizieren (wie "ScannerBot" oder "WebHarvestTool").
| Parameter | Standard | Kontext | Mehrfach | Beschreibung |
| :--------------------------------- | :----------------------------------------------------------------------------------------------------------------------------- | :-------- | :------- | :----------------------------------------------------------------------------------------------------------------- |
| `BLACKLIST_USER_AGENT` | | Multisite | Nein | **User-Agent-Blacklist:** Liste von User-Agent-Mustern (PCRE-Regex) zum Blockieren, durch Leerzeichen getrennt. |
| `BLACKLIST_IGNORE_USER_AGENT` | | Multisite | Nein | **User-Agent-Ignorierliste:** Liste von User-Agent-Mustern, die User-Agent-Blacklist-Überprüfungen umgehen sollen. |
| `BLACKLIST_USER_AGENT_URLS` | `https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/_generator_lists/bad-user-agents.list` | Multisite | Nein | **User-Agent-Blacklist-URLs:** Liste von URLs, die zu blockierende User-Agent-Muster enthalten. |
| `BLACKLIST_IGNORE_USER_AGENT_URLS` | | Multisite | Nein | **User-Agent-Ignorierlisten-URLs:** Liste von URLs, die zu ignorierende User-Agent-Muster enthalten. |
Der Standardparameter `BLACKLIST_USER_AGENT_URLS` enthält eine URL, die eine **Liste bekannter bösartiger User-Agents** bereitstellt. Diese werden oft von bösartigen Bots und Scannern verwendet, um anfällige Websites zu identifizieren.
=== "URI"[33][34][35][36][37] Was es bewirkt: Blockiert Anfragen an spezifische URLs auf Ihrer Website. Dies ist nützlich, um Zugriffsversuche auf Admin-Seiten, Anmeldeformulare oder andere sensible Bereiche zu blockieren, die angegriffen werden könnten.
| Parameter | Standard | Kontext | Mehrfach | Beschreibung |
| :-------------------------- | :------- | :-------- | :------- | :------------------------------------------------------------------------------------------------ |
| `BLACKLIST_URI` | | Multisite | Nein | **URI-Blacklist:** Liste von URI-Mustern (PCRE-Regex) zum Blockieren, durch Leerzeichen getrennt. |
| `BLACKLIST_IGNORE_URI` | | Multisite | Nein | **URI-Ignorierliste:** Liste von URI-Mustern, die URI-Blacklist-Überprüfungen umgehen sollen. |
| `BLACKLIST_URI_URLS` | | Multisite | Nein | **URI-Blacklist-URLs:** Liste von URLs, die zu blockierende URI-Muster enthalten. |
| `BLACKLIST_IGNORE_URI_URLS` | | Multisite | Nein | **URI-Ignorierlisten-URLs:** Liste von URLs, die zu ignorierende URI-Muster enthalten. |
Unterstützung von URL-Formaten
Alle *_URLS
-Parameter unterstützen HTTP/HTTPS-URLs sowie lokale Dateipfade unter Verwendung des Präfixes file:///
. Die Basisauthentifizierung wird im Format http://user:pass@url
unterstützt.
!!! tip "Regelmäßige Updates"[4][5][6][7][8] Blacklists von URLs werden automatisch stündlich heruntergeladen und aktualisiert, um sicherzustellen, dass Ihr Schutz gegen die neuesten Bedrohungen auf dem neuesten Stand bleibt.
Konfigurationsbeispiele[38]
Eine einfache Konfiguration, die bekannte Tor-Exit-Nodes und gängige bösartige User-Agents mithilfe der Community-Blacklists blockiert:
USE_BLACKLIST: "yes"
BLACKLIST_COMMUNITY_LISTS: "ip:danmeuk-tor-exit ua:mitchellkrogza-bad-user-agents"
Alternativ können Sie eine manuelle Konfiguration per URL verwenden:
USE_BLACKLIST: "yes"
BLACKLIST_IP_URLS: "https://www.dan.me.uk/torlist/?exit"
BLACKLIST_USER_AGENT_URLS: "https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/_generator_lists/bad-user-agents.list"
Eine umfassendere Konfiguration mit benutzerdefinierten Blacklist-Einträgen und Ausnahmen:
USE_BLACKLIST: "yes"
# Benutzerdefinierte Blacklist-Einträge
BLACKLIST_IP: "192.168.1.100 203.0.113.0/24"
BLACKLIST_RDNS: ".shodan.io .censys.io .scanner.com"
BLACKLIST_ASN: "16509 14618" # ASN von AWS und Amazon
BLACKLIST_USER_AGENT: "(?:\b)SemrushBot(?:\b) (?:\b)AhrefsBot(?:\b)"
BLACKLIST_URI: "^/wp-login\.php$ ^/administrator/"
# Benutzerdefinierte Ignorierregeln
BLACKLIST_IGNORE_IP: "192.168.1.200 203.0.113.42"
# Externe Blacklist-Quellen
BLACKLIST_IP_URLS: "https://www.dan.me.uk/torlist/?exit https://www.spamhaus.org/drop/drop.txt"
BLACKLIST_USER_AGENT_URLS: "https://raw.githubusercontent.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/master/_generator_lists/bad-user-agents.list"
Konfiguration mit lokalen Dateien für Blacklists:
USE_BLACKLIST: "yes"
BLACKLIST_IP_URLS: "file:///chemin/vers/ip-blacklist.txt"
BLACKLIST_RDNS_URLS: "file:///chemin/vers/rdns-blacklist.txt"
BLACKLIST_ASN_URLS: "file:///chemin/vers/asn-blacklist.txt"
BLACKLIST_USER_AGENT_URLS: "file:///chemin/vers/user-agent-blacklist.txt"
BLACKLIST_URI_URLS: "file:///chemin/vers/uri-blacklist.txt"
Brotli
STREAM-Unterstützung
Das Brotli-Plugin aktiviert die Komprimierung von HTTP-Antworten mit dem Brotli-Algorithmus. Es reduziert die Bandbreitennutzung and beschleunigt das Laden, indem es Inhalte vor dem Senden an den Browser komprimiert.
Im Vergleich zu Gzip erreicht Brotli in der Regel bessere Kompressionsraten, was zu kleineren Dateien and einer schnelleren Bereitstellung führt.
So funktioniert's:
- Auf Anfrage eines Clients prüft BunkerWeb, ob der Browser Brotli unterstützt.
- Wenn ja, wird die Antwort auf dem konfigurierten Niveau (
BROTLI_COMP_LEVEL
) komprimiert. - Die entsprechenden Header zeigen die Brotli-Komprimierung an.
- Der Browser dekomprimiert vor der Anzeige.
- Bandbreite and Ladezeiten nehmen ab.
So wird's verwendet
- Aktivieren:
USE_BROTLI: yes
(standardmäßig deaktiviert). - MIME-Typen: Definieren Sie die zu komprimierenden Inhalte über
BROTLI_TYPES
. - Mindestgröße:
BROTLI_MIN_LENGTH
, um die Komprimierung kleiner Antworten zu vermeiden. - Komprimierungsstufe:
BROTLI_COMP_LEVEL
für das Gleichgewicht zwischen Geschwindigkeit and Verhältnis.
Parameter
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_BROTLI |
no |
Multisite | nein | Brotli-Komprimierung aktivieren. |
BROTLI_TYPES |
application/atom+xml application/javascript application/json application/rss+xml application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/x-javascript application/xhtml+xml application/xml font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml |
Multisite | nein | Komprimierte MIME-Typen. |
BROTLI_MIN_LENGTH |
1000 |
Multisite | nein | Mindestgröße (Bytes) für die Anwendung der Komprimierung. |
BROTLI_COMP_LEVEL |
6 |
Multisite | nein | Stufe 0–11: höher = bessere Komprimierung, aber mehr CPU. |
Komprimierungsstufe
6
bietet einen guten Kompromiss. Für statische Inhalte and verfügbare CPU: 9–11. Für dynamische Inhalte oder bei CPU-Einschränkungen: 4–5.
Beispiele
USE_BROTLI: "yes"
BROTLI_TYPES: "application/javascript application/json application/xml application/xhtml+xml text/css text/html text/javascript text/plain text/xml"
BROTLI_MIN_LENGTH: "1000"
BROTLI_COMP_LEVEL: "6"
USE_BROTLI: "yes"
BROTLI_TYPES: "application/atom+xml application/javascript application/json application/rss+xml application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/x-javascript application/xhtml+xml application/xml font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml"
BROTLI_MIN_LENGTH: "500"
BROTLI_COMP_LEVEL: "11"
USE_BROTLI: "yes"
BROTLI_TYPES: "application/javascript application/json text/css text/html text/javascript text/plain"
BROTLI_MIN_LENGTH: "1000"
BROTLI_COMP_LEVEL: "4"
BunkerNet
STREAM-Unterstützung
Das BunkerNet-Plugin ermöglicht den kollektiven Austausch von Bedrohungsdaten zwischen BunkerWeb-Instanzen und schafft so ein leistungsstarkes Schutznetzwerk gegen böswillige Akteure. Durch die Teilnahme an BunkerNet profitiert Ihre Instanz von einer globalen Datenbank bekannter Bedrohungen und trägt gleichzeitig dazu bei, die Sicherheit der gesamten BunkerWeb-Community zu verbessern.
So funktioniert es:
- Ihre BunkerWeb-Instanz registriert sich automatisch bei der BunkerNet-API, um eine eindeutige Kennung zu erhalten.
- Wenn Ihre Instanz eine bösartige IP-Adresse oder ein bösartiges Verhalten erkennt und blockiert, meldet sie die Bedrohung anonym an BunkerNet.
- BunkerNet sammelt Bedrohungsdaten von allen teilnehmenden Instanzen und verteilt die konsolidierte Datenbank.
- Ihre Instanz lädt regelmäßig eine aktualisierte Datenbank bekannter Bedrohungen von BunkerNet herunter.
- Diese kollektive Intelligenz ermöglicht es Ihrer Instanz, proaktiv IP-Adressen zu blockieren, die auf anderen BunkerWeb-Instanzen bösartiges Verhalten gezeigt haben.
Wichtige Vorteile
- Kollektive Verteidigung: Nutzen Sie die Sicherheitserkenntnisse von Tausenden anderer BunkerWeb-Instanzen weltweit.
- Proaktiver Schutz: Blockieren Sie böswillige Akteure, bevor sie Ihre Website angreifen können, basierend auf ihrem Verhalten an anderer Stelle.
- Beitrag zur Gemeinschaft: Helfen Sie, andere BunkerWeb-Benutzer zu schützen, indem Sie anonymisierte Bedrohungsdaten über Angreifer teilen.
- Keine Konfiguration erforderlich: Funktioniert standardmäßig mit sinnvollen Voreinstellungen und erfordert nur minimale Einrichtung.
- Datenschutzorientiert: Teilt nur notwendige Bedrohungsinformationen, ohne Ihre Privatsphäre oder die Ihrer Benutzer zu gefährden.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die BunkerNet-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Die BunkerNet-Funktion ist standardmäßig aktiviert. Bei Bedarf können Sie dies mit der Einstellung
USE_BUNKERNET
steuern. - Erstregistrierung: Beim ersten Start registriert sich Ihre Instanz automatisch bei der BunkerNet-API und erhält eine eindeutige Kennung.
- Automatische Updates: Ihre Instanz lädt automatisch in regelmäßigen Abständen die neueste Bedrohungsdatenbank herunter.
- Automatisches Melden: Wenn Ihre Instanz eine bösartige IP-Adresse blockiert, trägt sie diese Daten automatisch zur Gemeinschaft bei.
- Schutz überwachen: Überprüfen Sie die Web-Benutzeroberfläche, um Statistiken zu den von BunkerNet-Informationen blockierten Bedrohungen anzuzeigen.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_BUNKERNET |
yes |
multisite | nein | BunkerNet aktivieren: Auf yes setzen, um den Austausch von Bedrohungsdaten zu aktivieren. |
BUNKERNET_SERVER |
https://api.bunkerweb.io |
global | nein | BunkerNet-Server: Die Adresse des BunkerNet-API-Servers für den Austausch von Bedrohungsdaten. |
Netzwerkschutz
Wenn BunkerNet feststellt, dass eine IP-Adresse an bösartigen Aktivitäten auf mehreren BunkerWeb-Instanzen beteiligt war, wird diese IP zu einer kollektiven schwarzen Liste hinzugefügt. Dies bietet eine proaktive Verteidigungsebene, die Ihre Website vor Bedrohungen schützt, bevor sie Sie direkt angreifen können.
Anonymes Melden
Bei der Meldung von Bedrohungsinformationen an BunkerNet teilt Ihre Instanz nur die zur Identifizierung der Bedrohung erforderlichen Daten: die IP-Adresse, den Grund für die Sperrung und minimale kontextbezogene Daten. Es werden keine persönlichen Informationen über Ihre Benutzer oder sensible Details über Ihre Website weitergegeben.
Beispielkonfigurationen
Die Standardkonfiguration aktiviert BunkerNet mit dem offiziellen BunkerWeb-API-Server:
USE_BUNKERNET: "yes"
BUNKERNET_SERVER: "https://api.bunkerweb.io"
Wenn Sie nicht am BunkerNet-Bedrohungsdatennetzwerk teilnehmen möchten:
USE_BUNKERNET: "no"
Für Organisationen, die ihren eigenen BunkerNet-Server betreiben (ungewöhnlich):
USE_BUNKERNET: "yes"
BUNKERNET_SERVER: "https://bunkernet.example.com"
Integration der CrowdSec-Konsole
Falls Sie noch nicht mit der CrowdSec-Konsolenintegration vertraut sind: CrowdSec nutzt crowdsourced Intelligence zur Bekämpfung von Cyber-Bedrohungen. Stellen Sie es sich als das „Waze der Cybersicherheit“ vor – wenn ein Server angegriffen wird, werden andere Systeme weltweit alarmiert und vor denselben Angreifern geschützt. Mehr darüber erfahren Sie hier.
Durch unsere Partnerschaft mit CrowdSec können Sie Ihre BunkerWeb-Instanzen in Ihre CrowdSec-Konsole eintragen. Das bedeutet, dass von BunkerWeb blockierte Angriffe in Ihrer CrowdSec-Konsole neben den von CrowdSec Security Engines blockierten Angriffen sichtbar sind, was Ihnen einen einheitlichen Überblick über Bedrohungen gibt.
Wichtig ist, dass CrowdSec für diese Integration nicht installiert sein muss (obwohl wir dringend empfehlen, es mit dem CrowdSec-Plugin für BunkerWeb auszuprobieren, um die Sicherheit Ihrer Webdienste weiter zu erhöhen). Zusätzlich können Sie Ihre CrowdSec Security Engines in dasselbe Konsolenkonto eintragen, um eine noch größere Synergie zu erzielen.
Schritt 1: Erstellen Sie Ihr CrowdSec-Konsolenkonto
Gehen Sie zur CrowdSec-Konsole und registrieren Sie sich, falls Sie noch kein Konto haben. Notieren Sie sich anschließend den Anmeldeschlüssel, den Sie unter „Security Engines“ finden, nachdem Sie auf „Add Security Engine“ geklickt haben:
Schritt 2: Holen Sie sich Ihre BunkerNet-ID
Die Aktivierung der BunkerNet-Funktion (standardmäßig aktiviert) ist obligatorisch, wenn Sie Ihre BunkerWeb-Instanz(en) in Ihrer CrowdSec-Konsole registrieren möchten. Aktivieren Sie sie, indem Sie USE_BUNKERNET
auf yes
setzen.
Für Docker erhalten Sie Ihre BunkerNet-ID mit:
docker exec my-bw-scheduler cat /var/cache/bunkerweb/bunkernet/instance.id
Für Linux verwenden Sie:
cat /var/cache/bunkerweb/bunkernet/instance.id
Schritt 3: Registrieren Sie Ihre Instanz über das Panel
Sobald Sie Ihre BunkerNet-ID und den CrowdSec-Konsolen-Anmeldeschlüssel haben, bestellen Sie das kostenlose Produkt „BunkerNet / CrowdSec“ im Panel. Möglicherweise werden Sie aufgefordert, ein Konto zu erstellen, falls Sie noch keines haben.
Sie können nun den Dienst „BunkerNet / CrowdSec“ auswählen und das Formular ausfüllen, indem Sie Ihre BunkerNet-ID und den CrowdSec-Konsolen-Anmeldeschlüssel einfügen:
Schritt 4: Akzeptieren Sie die neue Security Engine in der Konsole
Gehen Sie dann zurück zu Ihrer CrowdSec-Konsole und akzeptieren Sie die neue Security Engine:
Herzlichen Glückwunsch, Ihre BunkerWeb-Instanz ist jetzt in Ihrer CrowdSec-Konsole registriert!
Profi-Tipp: Wenn Sie Ihre Warnungen anzeigen, klicken Sie auf die Option „Spalten“ und aktivieren Sie das Kontrollkästchen „Kontext“, um auf BunkerWeb-spezifische Daten zuzugreifen.
CORS
STREAM-Unterstützung
Das CORS-Plugin ermöglicht Cross-Origin Resource Sharing (Ressourcenfreigabe zwischen verschiedenen Ursprüngen) für Ihre Website und erlaubt so den kontrollierten Zugriff auf Ihre Ressourcen von verschiedenen Domains aus. Diese Funktion hilft Ihnen, Ihre Inhalte sicher mit vertrauenswürdigen Drittanbieter-Websites zu teilen, während die Sicherheit durch die explizite Definition der erlaubten Ursprünge, Methoden und Header gewährleistet wird.
So funktioniert es:
- Wenn ein Browser eine Cross-Origin-Anfrage an Ihre Website stellt, sendet er zuerst eine Preflight-Anfrage mit der
OPTIONS
-Methode. - BunkerWeb prüft, ob der anfragende Ursprung basierend auf Ihrer Konfiguration zulässig ist.
- Wenn dies der Fall ist, antwortet BunkerWeb mit den entsprechenden CORS-Headern, die definieren, was die anfragende Website tun darf.
- Bei nicht zulässigen Ursprüngen kann die Anfrage entweder komplett verweigert oder ohne CORS-Header ausgeliefert werden.
- Zusätzliche Cross-Origin-Richtlinien wie COEP, COOP und CORP können konfiguriert werden, um die Sicherheit weiter zu erhöhen.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die CORS-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Die CORS-Funktion ist standardmäßig deaktiviert. Setzen Sie die Einstellung
USE_CORS
aufyes
, um sie zu aktivieren. - Erlaubte Ursprünge konfigurieren: Geben Sie mit der Einstellung
CORS_ALLOW_ORIGIN
an, welche Domains auf Ihre Ressourcen zugreifen dürfen. - Zulässige Methoden festlegen: Definieren Sie mit
CORS_ALLOW_METHODS
, welche HTTP-Methoden für Cross-Origin-Anfragen erlaubt sind. - Erlaubte Header konfigurieren: Geben Sie mit
CORS_ALLOW_HEADERS
an, welche Header in Anfragen verwendet werden dürfen. - Anmeldeinformationen steuern: Entscheiden Sie mit
CORS_ALLOW_CREDENTIALS
, ob Cross-Origin-Anfragen Anmeldeinformationen enthalten dürfen.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_CORS |
no |
multisite | nein | CORS aktivieren: Auf yes setzen, um Cross-Origin Resource Sharing zu aktivieren. |
CORS_ALLOW_ORIGIN |
self |
multisite | nein | Erlaubte Ursprünge: PCRE-regulärer Ausdruck für erlaubte Ursprünge; * für jeden Ursprung, self nur für denselben Ursprung. |
CORS_ALLOW_METHODS |
GET, POST, OPTIONS |
multisite | nein | Erlaubte Methoden: HTTP-Methoden, die bei Cross-Origin-Anfragen verwendet werden können. |
CORS_ALLOW_HEADERS |
DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range |
multisite | nein | Erlaubte Header: HTTP-Header, die bei Cross-Origin-Anfragen verwendet werden können. |
CORS_ALLOW_CREDENTIALS |
no |
multisite | nein | Anmeldeinformationen erlauben: Auf yes setzen, um Anmeldeinformationen (Cookies, HTTP-Auth) in CORS-Anfragen zu erlauben. |
CORS_EXPOSE_HEADERS |
Content-Length,Content-Range |
multisite | nein | Verfügbar gemachte Header: HTTP-Header, auf die Browser von Cross-Origin-Antworten zugreifen dürfen. |
CROSS_ORIGIN_OPENER_POLICY |
same-origin |
multisite | nein | Cross-Origin-Opener-Policy: Steuert die Kommunikation zwischen Browser-Kontexten. |
CROSS_ORIGIN_EMBEDDER_POLICY |
require-corp |
multisite | nein | Cross-Origin-Embedder-Policy: Steuert, ob ein Dokument Ressourcen von anderen Ursprüngen laden kann. |
CROSS_ORIGIN_RESOURCE_POLICY |
same-site |
multisite | nein | Cross-Origin-Resource-Policy: Steuert, welche Websites Ihre Ressourcen einbetten dürfen. |
CORS_MAX_AGE |
86400 |
multisite | nein | Cache-Dauer für Preflight: Wie lange (in Sekunden) Browser die Preflight-Antwort zwischenspeichern sollen. |
CORS_DENY_REQUEST |
yes |
multisite | nein | Nicht autorisierte Ursprünge ablehnen: Wenn yes , werden Anfragen von nicht autorisierten Ursprüngen mit einem Fehlercode abgelehnt. |
Optimierung von Preflight-Anfragen
Die Einstellung CORS_MAX_AGE
bestimmt, wie lange Browser die Ergebnisse einer Preflight-Anfrage zwischenspeichern. Ein höherer Wert (wie der Standardwert von 86400 Sekunden/24 Stunden) reduziert die Anzahl der Preflight-Anfragen und verbessert die Leistung für häufig aufgerufene Ressourcen.
Sicherheitshinweise
Seien Sie vorsichtig, wenn Sie CORS_ALLOW_ORIGIN
auf *
(alle Ursprünge) oder CORS_ALLOW_CREDENTIALS
auf yes
setzen, da diese Konfigurationen bei unsachgemäßer Verwaltung Sicherheitsrisiken mit sich bringen können. Es ist im Allgemeinen sicherer, vertrauenswürdige Ursprünge explizit aufzulisten und die erlaubten Methoden und Header zu beschränken.
Beispielkonfigurationen
Hier sind Beispiele für mögliche Werte der Einstellung CORS_ALLOW_ORIGIN
und deren Verhalten:
*
: Erlaubt Anfragen von allen Ursprüngen.self
: Erlaubt automatisch Anfragen vom selben Ursprung wie der konfigurierteserver_name
.^https://www\.example\.com$
: Erlaubt Anfragen nur vonhttps://www.example.com
.^https://.+\.example\.com$
: Erlaubt Anfragen von jeder Subdomain, die auf.example.com
endet.^https://(www\.example1\.com|www\.example2\.com)$
: Erlaubt Anfragen entweder vonhttps://www.example1.com
oderhttps://www.example2.com
.^https?://www\.example\.com$
: Erlaubt Anfragen sowohl vonhttps://www.example.com
als auch vonhttp://www.example.com
.
Eine einfache Konfiguration, die Cross-Origin-Anfragen von derselben Domain erlaubt:
USE_CORS: "yes"
CORS_ALLOW_ORIGIN: "self"
CORS_ALLOW_METHODS: "GET, POST, OPTIONS"
CORS_ALLOW_HEADERS: "Content-Type, Authorization"
CORS_ALLOW_CREDENTIALS: "no"
CORS_DENY_REQUEST: "yes"
Konfiguration für eine öffentliche API, die von jedem Ursprung aus zugänglich sein muss:
USE_CORS: "yes"
CORS_ALLOW_ORIGIN: "*"
CORS_ALLOW_METHODS: "GET, OPTIONS"
CORS_ALLOW_HEADERS: "Content-Type, X-API-Key"
CORS_ALLOW_CREDENTIALS: "no"
CORS_MAX_AGE: "3600"
CORS_DENY_REQUEST: "no"
Konfiguration, die mehrere spezifische Domains mit einem einzigen PCRE-regulären Ausdrucksmuster erlaubt:
USE_CORS: "yes"
CORS_ALLOW_ORIGIN: "^https://(app|api|dashboard)\\.example\\.com$"
CORS_ALLOW_METHODS: "GET, POST, PUT, DELETE, OPTIONS"
CORS_ALLOW_HEADERS: "Content-Type, Authorization, X-Requested-With"
CORS_ALLOW_CREDENTIALS: "yes"
CORS_EXPOSE_HEADERS: "Content-Length, Content-Range, X-RateLimit-Remaining"
CORS_MAX_AGE: "86400"
CORS_DENY_REQUEST: "yes"
Konfiguration, die alle Subdomains einer Hauptdomain mithilfe eines PCRE-regulären Ausdrucksmusters erlaubt:
USE_CORS: "yes"
CORS_ALLOW_ORIGIN: "^https://.*\\.example\\.com$"
CORS_ALLOW_METHODS: "GET, POST, OPTIONS"
CORS_ALLOW_HEADERS: "Content-Type, Authorization"
CORS_ALLOW_CREDENTIALS: "no"
CORS_MAX_AGE: "86400"
CORS_DENY_REQUEST: "yes"
Konfiguration, die Anfragen von mehreren Domain-Mustern mit Alternation erlaubt:
USE_CORS: "yes"
CORS_ALLOW_ORIGIN: "^https://(.*\\.example\\.com|.*\\.trusted-partner\\.org|api\\.third-party\\.net)$"
CORS_ALLOW_METHODS: "GET, POST, PUT, OPTIONS"
CORS_ALLOW_HEADERS: "Content-Type, Authorization, X-Custom-Header"
CORS_ALLOW_CREDENTIALS: "no"
CORS_MAX_AGE: "86400"
CORS_DENY_REQUEST: "yes"
Client cache
STREAM-Unterstützung
Das Client-Cache-Plugin optimiert die Leistung von Websites, indem es steuert, wie Browser statische Inhalte zwischenspeichern. Es reduziert die Bandbreitennutzung, senkt die Serverlast und verbessert die Ladezeiten von Seiten, indem es Browser anweist, statische Assets wie Bilder, CSS- und JavaScript-Dateien lokal zu speichern und wiederzuverwenden, anstatt sie bei jedem Seitenbesuch erneut anzufordern.
So funktioniert es:
- Wenn aktiviert, fügt BunkerWeb den Antworten für statische Dateien Cache-Control-Header hinzu.
- Diese Header teilen den Browsern mit, wie lange sie den Inhalt lokal zwischenspeichern sollen.
- Für Dateien mit bestimmten Erweiterungen (wie Bilder, CSS, JavaScript) wendet BunkerWeb die konfigurierte Caching-Richtlinie an.
- Die optionale ETag-Unterstützung bietet einen zusätzlichen Validierungsmechanismus, um festzustellen, ob der zwischengespeicherte Inhalt noch aktuell ist.
- Wenn Besucher auf Ihre Website zurückkehren, können ihre Browser lokal zwischengespeicherte Dateien verwenden, anstatt sie erneut herunterzuladen, was zu schnelleren Ladezeiten der Seite führt.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Client-Cache-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Die Client-Cache-Funktion ist standardmäßig deaktiviert. Setzen Sie die Einstellung
USE_CLIENT_CACHE
aufyes
, um sie zu aktivieren. - Dateierweiterungen konfigurieren: Geben Sie mit der Einstellung
CLIENT_CACHE_EXTENSIONS
an, welche Dateitypen zwischengespeichert werden sollen. - Cache-Control-Anweisungen festlegen: Passen Sie mit der Einstellung
CLIENT_CACHE_CONTROL
an, wie Clients Inhalte zwischenspeichern sollen. - ETag-Unterstützung konfigurieren: Entscheiden Sie mit der Einstellung
CLIENT_CACHE_ETAG
, ob ETags zur Validierung der Cache-Frische aktiviert werden sollen. - Lassen Sie BunkerWeb den Rest erledigen: Nach der Konfiguration werden Caching-Header automatisch auf berechtigte Antworten angewendet.
Konfigurationseinstellungen
| Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
| ------------------------- | -------------------------- | --------- | -------- | ----------------------------------------------------------------------------------------------------------------- | --- |
| USE_CLIENT_CACHE
| no
| multisite | nein | Client-Cache aktivieren: Auf yes
setzen, um das clientseitige Caching von statischen Dateien zu aktivieren. |
| CLIENT_CACHE_EXTENSIONS
| jpg | jpeg | png | bmp | ico | svg | tif | css | js | otf | ttf | eot | woff | woff2
| global | nein | Cache-fähige Erweiterungen: Liste der Dateierweiterungen (getrennt durch |
), die vom Client zwischengespeichert werden sollen. |
| CLIENT_CACHE_CONTROL
| public, max-age=15552000
| multisite | nein | Cache-Control-Header: Wert für den Cache-Control-HTTP-Header zur Steuerung des Caching-Verhaltens. |
| CLIENT_CACHE_ETAG
| yes
| multisite | nein | ETags aktivieren: Auf yes
setzen, um den HTTP-ETag-Header für statische Ressourcen zu senden. |
Optimierung der Cache-Einstellungen
Für häufig aktualisierte Inhalte sollten Sie kürzere max-age
-Werte verwenden. Für Inhalte, die sich selten ändern (wie versionierte JavaScript-Bibliotheken oder Logos), verwenden Sie längere Cache-Zeiten. Der Standardwert von 15552000 Sekunden (180 Tage) ist für die meisten statischen Assets angemessen.
Browser-Verhalten
Unterschiedliche Browser implementieren Caching geringfügig anders, aber alle modernen Browser respektieren die Standard-Cache-Control-Anweisungen. ETags bieten einen zusätzlichen Validierungsmechanismus, der Browsern hilft festzustellen, ob zwischengespeicherte Inhalte noch gültig sind.
Beispielkonfigurationen
Eine einfache Konfiguration, die das Caching für gängige statische Assets aktiviert:
USE_CLIENT_CACHE: "yes"
CLIENT_CACHE_EXTENSIONS: "jpg|jpeg|png|gif|css|js|svg|woff|woff2"
CLIENT_CACHE_CONTROL: "public, max-age=86400" # 1 Tag
CLIENT_CACHE_ETAG: "yes"
Eine für maximales Caching optimierte Konfiguration, geeignet für Websites mit selten aktualisierten statischen Inhalten:
USE_CLIENT_CACHE: "yes"
CLIENT_CACHE_EXTENSIONS: "jpg|jpeg|png|bmp|ico|svg|tif|gif|css|js|otf|ttf|eot|woff|woff2|pdf|xml|txt"
CLIENT_CACHE_CONTROL: "public, max-age=31536000, immutable" # 1 Jahr
CLIENT_CACHE_ETAG: "yes"
Für Websites mit einer Mischung aus häufig und selten aktualisierten Inhalten sollten Sie die Dateiversionierung in Ihrer Anwendung und eine Konfiguration wie diese in Betracht ziehen:
USE_CLIENT_CACHE: "yes"
CLIENT_CACHE_EXTENSIONS: "jpg|jpeg|png|bmp|ico|svg|tif|gif|css|js|otf|ttf|eot|woff|woff2"
CLIENT_CACHE_CONTROL: "public, max-age=604800" # 1 Woche
CLIENT_CACHE_ETAG: "yes"
Country
STREAM-Unterstützung
Das Länder-Plugin aktiviert Geoblocking und ermöglicht die Einschränkung des Zugriffs basierend auf dem geografischen Standort der Besucher. Dies ist nützlich für die Einhaltung regionaler Vorschriften, zur Begrenzung von Betrug in Risikogebieten und zur Anwendung von Inhaltsbeschränkungen über Ländergrenzen hinweg.
So funktioniert's:
- Bei jedem Besuch ermittelt BunkerWeb das Herkunftsland über die IP-Adresse.
- Ihre Konfiguration definiert eine Whitelist (erlaubt) oder Blacklist (blockiert).
- Bei einer Whitelist: Nur die gelisteten Länder sind zugelassen.
- Bei einer Blacklist: Die gelisteten Länder werden abgelehnt.
- Das Ergebnis wird für wiederholte Besuche zwischengespeichert.
Anwendung
- Strategie: Wählen Sie eine Whitelist (wenige zugelassene Länder) oder eine Blacklist (bestimmte Länder blockieren).
- Ländercodes: Fügen Sie ISO 3166-1 Alpha-2 Codes (US, GB, FR) zu
WHITELIST_COUNTRY
oderBLACKLIST_COUNTRY
hinzu. - Anwendung: Nach der Konfiguration gilt die Beschränkung für alle Besucher.
- Überwachung: Konsultieren Sie die Web-UI für Statistiken nach Ländern.
Parameter
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
WHITELIST_COUNTRY |
Multisite | Nein | Whitelist: ISO 3166-1 Alpha-2 Ländercodes, durch Leerzeichen getrennt. Nur diese Länder sind zugelassen. | |
BLACKLIST_COUNTRY |
Multisite | Nein | Blacklist: ISO 3166-1 Alpha-2 Ländercodes, durch Leerzeichen getrennt. Diese Länder sind blockiert. |
Whitelist vs. Blacklist
Whitelist: Zugriff auf wenige Länder beschränkt. Blacklist: Problematische Regionen blockieren und den Rest zulassen.
Priorität
Wenn eine Whitelist und eine Blacklist definiert sind, hat die Whitelist Vorrang: Wenn das Land nicht auf der Whitelist steht, wird der Zugriff verweigert.
Ländererkennung
BunkerWeb verwendet die mmdb-Datenbank db-ip lite.
Beispiele
WHITELIST_COUNTRY: "US CA GB"
BLACKLIST_COUNTRY: "RU CN KP"
WHITELIST_COUNTRY: "AT BE BG HR CY CZ DK EE FI FR DE GR HU IE IT LV LT LU MT NL PL PT RO SK SI ES SE"
BLACKLIST_COUNTRY: "RU CN KP IR SY"
CrowdSec
STREAM-Unterstützung
Das CrowdSec-Plugin integriert BunkerWeb mit der CrowdSec-Sicherheits-Engine und bietet eine zusätzliche Schutzschicht gegen verschiedene Cyberbedrohungen. Dieses Plugin fungiert als CrowdSec-Bouncer und lehnt Anfragen basierend auf den Entscheidungen der CrowdSec-API ab.
CrowdSec ist eine moderne Open-Source-Sicherheits-Engine, die bösartige IP-Adressen basierend auf Verhaltensanalyse und der kollektiven Intelligenz ihrer Community erkennt und blockiert. Sie können auch Szenarien konfigurieren, um IP-Adressen basierend auf verdächtigem Verhalten automatisch zu sperren und so von einer partizipativen Blacklist zu profitieren.
So funktioniert's:
- Die CrowdSec-Engine analysiert Protokolle und erkennt verdächtige Aktivitäten in Ihrer Infrastruktur.
- Wenn eine bösartige Aktivität erkannt wird, erstellt CrowdSec eine Entscheidung, die betreffende IP-Adresse zu blockieren.
- BunkerWeb, das als Bouncer fungiert, fragt die lokale CrowdSec-API nach Entscheidungen bezüglich eingehender Anfragen ab.
- Wenn die IP-Adresse eines Clients einer aktiven Blockierungsentscheidung unterliegt, verweigert BunkerWeb den Zugriff auf die geschützten Dienste.
- Optional kann die Anwendungssicherheitskomponente (Application Security Component) eine eingehende Überprüfung der Anfragen für erhöhte Sicherheit durchführen.
Hauptvorteile
- Community-Sicherheit: Profitieren Sie von Bedrohungsinformationen, die von der CrowdSec-Benutzergemeinschaft geteilt werden.
- Verhaltensanalyse: Erkennen Sie ausgeklügelte Angriffe basierend auf Verhaltensmustern, nicht nur auf Signaturen.
- Leichte Integration: Minimaler Einfluss auf die Leistung Ihrer BunkerWeb-Instanz.
- Mehrstufiger Schutz: Kombinieren Sie Perimeterverteidigung (IP-Blockierung) mit Anwendungssicherheit für einen umfassenden Schutz.
Einrichtung
Akquisitionsdatei
Sie müssen eine CrowdSec-Instanz ausführen und diese so konfigurieren, dass sie die BunkerWeb-Protokolle analysiert. Da BunkerWeb auf NGINX basiert, können Sie den Wert nginx
für den Parameter type
in Ihrer Akquisitionsdatei verwenden (vorausgesetzt, die BunkerWeb-Protokolle werden unverändert ohne zusätzliche Daten gespeichert):
filenames:
- /var/log/bunkerweb.log
labels:
type: nginx
Anwendungssicherheitskomponente (optional)
CrowdSec bietet auch eine Anwendungssicherheitskomponente, die zum Schutz Ihrer Anwendung vor Angriffen verwendet werden kann. Wenn Sie diese verwenden möchten, müssen Sie eine weitere Akquisitionsdatei für die AppSec-Komponente erstellen:
appsec_config: crowdsecurity/appsec-default
labels:
type: appsec
listen_addr: 0.0.0.0:7422
source: appsec
Syslog
Für containerbasierte Integrationen empfehlen wir, die Protokolle des BunkerWeb-Containers an einen Syslog-Dienst umzuleiten, damit CrowdSec leicht darauf zugreifen kann. Hier ist ein Beispiel für eine syslog-ng-Konfiguration, die die Rohprotokolle von BunkerWeb in einer lokalen Datei /var/log/bunkerweb.log
speichert:
@version: 4.8
source s_net {
udp(
ip("0.0.0.0")
);
};
template t_imp {
template("$MSG\n");
template_escape(no);
};
destination d_file {
file("/var/log/bunkerweb.log" template(t_imp));
};
log {
source(s_net);
destination(d_file);
};
Docker Compose
Hier ist die Docker-Compose-Vorlage, die Sie verwenden können (vergessen Sie nicht, den Bouncer-Schlüssel zu aktualisieren):
x-bw-env: &bw-env
# Wir verwenden einen Anker, um die Wiederholung derselben Parameter für beide Dienste zu vermeiden
API_WHITELIST_IP: "127.0.0.0/8 10.20.30.0/24" # Stellen Sie sicher, dass Sie den richtigen IP-Bereich festlegen, damit der Scheduler die Konfiguration an die Instanz senden kann
services:
bunkerweb:
# Dies ist der Name, der zur Identifizierung der Instanz im Scheduler verwendet wird
image: bunkerity/bunkerweb:1.6.5-rc3
ports:
- "80:8080/tcp"
- "443:8443/tcp"
- "443:8443/udp" # Für QUIC / HTTP3 Unterstützung
environment:
<<: *bw-env # Wir verwenden den Anker, um die Wiederholung derselben Parameter für alle Dienste zu vermeiden
restart: "unless-stopped"
networks:
- bw-universe
- bw-services
logging:
driver: syslog # Protokolle an syslog senden
options:
syslog-address: "udp://10.20.30.254:514" # Die IP-Adresse des syslog-Dienstes
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5-rc3
environment:
<<: *bw-env
BUNKERWEB_INSTANCES: "bunkerweb" # Stellen Sie sicher, dass Sie den richtigen Instanznamen festlegen
DATABASE_URI: "mariadb+pymysql://bunkerweb:changeme@bw-db:3306/db" # Vergessen Sie nicht, ein stärkeres Datenbankpasswort festzulegen
SERVER_NAME: ""
MULTISITE: "yes"
USE_CROWDSEC: "yes"
CROWDSEC_API: "http://crowdsec:8080" # Dies ist die Adresse der CrowdSec-Container-API im selben Netzwerk
CROWDSEC_APPSEC_URL: "http://crowdsec:7422" # Auskommentieren, wenn Sie die AppSec-Komponente nicht verwenden möchten
CROWDSEC_API_KEY: "s3cr3tb0unc3rk3y" # Vergessen Sie nicht, einen stärkeren Schlüssel für den Bouncer festzulegen
volumes:
- bw-storage:/data # Dies wird verwendet, um den Cache und andere Daten wie Backups zu persistieren
restart: "unless-stopped"
networks:
- bw-universe
- bw-db
bw-db:
image: mariadb:11
# Wir legen die maximal zulässige Paketgröße fest, um Probleme mit großen Anfragen zu vermeiden
command: --max-allowed-packet=67108864
environment:
MYSQL_RANDOM_ROOT_PASSWORD: "yes"
MYSQL_DATABASE: "db"
MYSQL_USER: "bunkerweb"
MYSQL_PASSWORD: "changeme" # Vergessen Sie nicht, ein stärkeres Datenbankpasswort festzulegen
volumes:
- bw-data:/var/lib/mysql
restart: "unless-stopped"
networks:
- bw-db
crowdsec:
image: crowdsecurity/crowdsec:v1.7.0 # Verwenden Sie die neueste Version, aber pinnen Sie immer die Version für bessere Stabilität/Sicherheit
volumes:
- cs-data:/var/lib/crowdsec/data # Zum Persistieren der CrowdSec-Daten
- bw-logs:/var/log:ro # Die BunkerWeb-Protokolle, die von CrowdSec analysiert werden sollen
- ./acquis.yaml:/etc/crowdsec/acquis.yaml # Die Akquisitionsdatei für die BunkerWeb-Protokolle
- ./appsec.yaml:/etc/crowdsec/acquis.d/appsec.yaml # Auskommentieren, wenn Sie die AppSec-Komponente nicht verwenden möchten
environment:
BOUNCER_KEY_bunkerweb: "s3cr3tb0unc3rk3y" # Vergessen Sie nicht, einen stärkeren Schlüssel für den Bouncer festzulegen
COLLECTIONS: "crowdsecurity/nginx crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rules"
# COLLECTIONS: "crowdsecurity/nginx" # Wenn Sie die AppSec-Komponente nicht verwenden möchten, verwenden Sie stattdessen diese Zeile
networks:
- bw-universe
syslog:
image: balabit/syslog-ng:4.9.0
cap_add:
- NET_BIND_SERVICE # An niedrige Ports binden
- NET_BROADCAST # Broadcasts senden
- NET_RAW # Raw-Sockets verwenden
- DAC_READ_SEARCH # Dateien lesen, Berechtigungen umgehen
- DAC_OVERRIDE # Dateiberechtigungen überschreiben
- CHOWN # Besitzer ändern
- SYSLOG # In Systemprotokolle schreiben
volumes:
- bw-logs:/var/log/bunkerweb # Dies ist das Volume, das zum Speichern der Protokolle verwendet wird
- ./syslog-ng.conf:/etc/syslog-ng/syslog-ng.conf # Dies ist die Konfigurationsdatei von syslog-ng
networks:
bw-universe:
ipv4_address: 10.20.30.254
volumes:
bw-data:
bw-storage:
bw-logs:
cs-data:
networks:
bw-universe:
name: bw-universe
ipam:
driver: default
config:
- subnet: 10.20.30.0/24 # Stellen Sie sicher, dass Sie den richtigen IP-Bereich festlegen, damit der Scheduler die Konfiguration an die Instanz senden kann
bw-services:
name: bw-services
bw-db:
name: bw-db
Sie müssen CrowdSec installieren und so konfigurieren, dass es die BunkerWeb-Protokolle analysiert. Befolgen Sie die offizielle Dokumentation.
Damit CrowdSec die BunkerWeb-Protokolle analysieren kann, fügen Sie die folgenden Zeilen zu Ihrer Akquisitionsdatei unter /etc/crowdsec/acquis.yaml
hinzu:
filenames:
- /var/log/bunkerweb/access.log
- /var/log/bunkerweb/error.log
- /var/log/bunkerweb/modsec_audit.log
labels:
type: nginx
Fügen Sie nun Ihren benutzerdefinierten Bouncer zur CrowdSec-API hinzu, indem Sie das Tool cscli
verwenden:
sudo cscli bouncers add crowdsec-bunkerweb-bouncer/v1.6
API-Schlüssel
Bewahren Sie den von dem cscli
-Befehl generierten Schlüssel auf; Sie werden ihn später benötigen.
Starten Sie anschließend den CrowdSec-Dienst neu:
sudo systemctl restart crowdsec
Anwendungssicherheitskomponente (optional)
Wenn Sie die AppSec-Komponente verwenden möchten, müssen Sie eine weitere Akquisitionsdatei dafür erstellen, die sich unter /etc/crowdsec/acquis.d/appsec.yaml
befindet:
appsec_config: crowdsecurity/appsec-default
labels:
type: appsec
listen_addr: 127.0.0.1:7422
source: appsec
Sie müssen auch die Sammlungen der AppSec-Komponente installieren:
sudo cscli collections install crowdsecurity/appsec-virtual-patching
sudo cscli collections install crowdsecurity/appsec-generic-rules
Starten Sie schließlich den CrowdSec-Dienst neu:
sudo systemctl restart crowdsec
Parameter
Konfigurieren Sie das Plugin, indem Sie die folgenden Parameter zu Ihrer BunkerWeb-Konfigurationsdatei hinzufügen:
USE_CROWDSEC=yes
CROWDSEC_API=http://127.0.0.1:8080
CROWDSEC_API_KEY=<Der von cscli bereitgestellte Schlüssel>
# Auskommentieren, wenn Sie die AppSec-Komponente nicht verwenden möchten
CROWDSEC_APPSEC_URL=http://127.0.0.1:7422
Laden Sie schließlich den BunkerWeb-Dienst neu:
sudo systemctl reload bunkerweb
Das Docker-Image BunkerWeb All-In-One (AIO) wird mit vollständig integriertem CrowdSec geliefert. Sie müssen keine separate CrowdSec-Instanz einrichten oder die Akquisitionsdateien für die BunkerWeb-Protokolle manuell konfigurieren, wenn Sie den internen CrowdSec-Agenten verwenden.
Beachten Sie die Integrationsdokumentation des All-In-One (AIO)-Images.
Konfigurationsparameter
Parameter | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_CROWDSEC |
no |
multisite | no | CrowdSec aktivieren: Auf yes setzen, um den CrowdSec-Bouncer zu aktivieren. |
CROWDSEC_API |
http://crowdsec:8080 |
global | no | CrowdSec API URL: Die Adresse des lokalen CrowdSec API-Dienstes. |
CROWDSEC_API_KEY |
global | no | CrowdSec API-Schlüssel: Der API-Schlüssel zur Authentifizierung bei der CrowdSec-API, erhalten mit cscli bouncers add . |
|
CROWDSEC_MODE |
live |
global | no | Betriebsmodus: Entweder live (fragt die API für jede Anfrage ab) oder stream (cacht alle Entscheidungen periodisch). |
CROWDSEC_ENABLE_INTERNAL |
no |
global | no | Interner Traffic: Auf yes setzen, um den internen Traffic anhand der CrowdSec-Entscheidungen zu überprüfen. |
CROWDSEC_REQUEST_TIMEOUT |
1000 |
global | no | Anfrage-Timeout: Timeout in Millisekunden für HTTP-Anfragen an die lokale CrowdSec-API im Live-Modus. |
CROWDSEC_EXCLUDE_LOCATION |
global | no | Ausgeschlossene Orte: Kommagetrennte Liste von Orten (URIs), die von CrowdSec-Prüfungen ausgeschlossen werden sollen. | |
CROWDSEC_CACHE_EXPIRATION |
1 |
global | no | Cache-Ablauf: Die Cache-Ablaufzeit in Sekunden für IP-Entscheidungen im Live-Modus. |
CROWDSEC_UPDATE_FREQUENCY |
10 |
global | no | Update-Frequenz: Wie oft (in Sekunden) neue/abgelaufene Entscheidungen von der CrowdSec-API im Stream-Modus abgerufen werden sollen. |
Parameter der Anwendungssicherheitskomponente
Parameter | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
CROWDSEC_APPSEC_URL |
global | no | AppSec URL: Die URL der CrowdSec-Anwendungssicherheitskomponente. Leer lassen, um AppSec zu deaktivieren. | |
CROWDSEC_APPSEC_FAILURE_ACTION |
passthrough |
global | no | Aktion bei Fehler: Aktion, die ausgeführt werden soll, wenn AppSec einen Fehler zurückgibt. Kann passthrough oder deny sein. |
CROWDSEC_APPSEC_CONNECT_TIMEOUT |
100 |
global | no | Verbindungs-Timeout: Das Timeout in Millisekunden für die Verbindung zur AppSec-Komponente. |
CROWDSEC_APPSEC_SEND_TIMEOUT |
100 |
global | no | Sende-Timeout: Das Timeout in Millisekunden für das Senden von Daten an die AppSec-Komponente. |
CROWDSEC_APPSEC_PROCESS_TIMEOUT |
500 |
global | no | Verarbeitungs-Timeout: Das Timeout in Millisekunden für die Verarbeitung der Anfrage in der AppSec-Komponente. |
CROWDSEC_ALWAYS_SEND_TO_APPSEC |
no |
global | no | Immer senden: Auf yes setzen, um Anfragen immer an AppSec zu senden, auch wenn eine Entscheidung auf IP-Ebene vorliegt. |
CROWDSEC_APPSEC_SSL_VERIFY |
no |
global | no | SSL-Verifizierung: Auf yes setzen, um das SSL-Zertifikat der AppSec-Komponente zu überprüfen. |
!!! info "Über die Betriebsmodi" - Der Live-Modus fragt die CrowdSec-API für jede eingehende Anfrage ab und bietet Echtzeitschutz auf Kosten einer höheren Latenz. - Der Stream-Modus lädt periodisch alle Entscheidungen von der CrowdSec-API herunter und speichert sie lokal im Cache, wodurch die Latenz mit einer leichten Verzögerung bei der Anwendung neuer Entscheidungen reduziert wird.
Konfigurationsbeispiele
Dies ist eine einfache Konfiguration, wenn CrowdSec auf demselben Host ausgeführt wird:
USE_CROWDSEC: "yes"
CROWDSEC_API: "http://crowdsec:8080"
CROWDSEC_API_KEY: "your-api-key-here"
CROWDSEC_MODE: "live"
Eine umfassendere Konfiguration, einschließlich der Anwendungssicherheitskomponente:
USE_CROWDSEC: "yes"
CROWDSEC_API: "http://crowdsec:8080"
CROWDSEC_API_KEY: "your-api-key-here"
CROWDSEC_MODE: "stream"
CROWDSEC_UPDATE_FREQUENCY: "30"
CROWDSEC_EXCLUDE_LOCATION: "/health,/metrics"
# AppSec-Konfiguration
CROWDSEC_APPSEC_URL: "http://crowdsec:7422"
CROWDSEC_APPSEC_FAILURE_ACTION: "deny"
CROWDSEC_ALWAYS_SEND_TO_APPSEC: "yes"
CROWDSEC_APPSEC_SSL_VERIFY: "yes"
Custom SSL certificate
STREAM-Unterstützung
Das Plugin für benutzerdefinierte SSL-Zertifikate ermöglicht die Verwendung Ihrer eigenen SSL/TLS-Zertifikate mit BunkerWeb, anstelle der automatisch generierten. Dies ist nützlich, wenn Sie bereits Zertifikate von einer vertrauenswürdigen CA besitzen, spezifische Anforderungen haben oder die Zertifikatsverwaltung zentralisieren.
So funktioniert's:
- Sie stellen das Zertifikat und den privaten Schlüssel bereit (Dateipfade oder Daten in base64/PEM).
- BunkerWeb validiert das Format und die Verwendbarkeit der Dateien.
- Bei einer sicheren Verbindung stellt BunkerWeb Ihr benutzerdefiniertes Zertifikat bereit.
- Die Gültigkeit wird überwacht und Warnungen werden vor dem Ablauf ausgegeben.
- Sie behalten die volle Kontrolle über den Lebenszyklus der Zertifikate.
Automatische Überwachung
Mit USE_CUSTOM_SSL: yes
überwacht BunkerWeb das Zertifikat CUSTOM_SSL_CERT
, erkennt Änderungen und lädt NGINX bei Bedarf neu.
Verwendung
- Aktivieren:
USE_CUSTOM_SSL: yes
. - Methode: Dateien vs. Daten, Priorität über
CUSTOM_SSL_CERT_PRIORITY
. - Dateien: Geben Sie die Pfade zum Zertifikat und zum privaten Schlüssel an.
- Daten: Geben Sie die base64- oder Klartext-PEM-Strings an.
Stream-Modus
Im Stream-Modus konfigurieren Sie LISTEN_STREAM_PORT_SSL
für den SSL/TLS-Port.
Parameter
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_CUSTOM_SSL |
no |
multisite | nein | Aktiviert die Verwendung eines benutzerdefinierten Zertifikats. |
CUSTOM_SSL_CERT_PRIORITY |
file |
multisite | nein | Priorität der Quellen: file (Dateien) oder data (Daten). |
CUSTOM_SSL_CERT |
multisite | nein | Vollständiger Pfad zum Zertifikat (oder Bundle). | |
CUSTOM_SSL_KEY |
multisite | nein | Vollständiger Pfad zum privaten Schlüssel. | |
CUSTOM_SSL_CERT_DATA |
multisite | nein | Zertifikatsdaten (base64 oder Klartext-PEM). | |
CUSTOM_SSL_KEY_DATA |
multisite | nein | Daten des privaten Schlüssels (base64 oder Klartext-PEM). |
Sicherheit
Schützen Sie den privaten Schlüssel (angemessene Berechtigungen, nur vom BunkerWeb-Scheduler lesbar).
Format
Zertifikate müssen im PEM-Format vorliegen. Konvertieren Sie bei Bedarf.
Zertifikatsketten
Wenn eine Zwischenkette erforderlich ist, stellen Sie das vollständige Bundle in der richtigen Reihenfolge bereit (Zertifikat, dann Zwischenzertifikate).
Beispiele
USE_CUSTOM_SSL: "yes"
CUSTOM_SSL_CERT_PRIORITY: "file"
CUSTOM_SSL_CERT: "/path/to/your/certificate.pem"
CUSTOM_SSL_KEY: "/path/to/your/private-key.pem"
USE_CUSTOM_SSL: "yes"
CUSTOM_SSL_CERT_PRIORITY: "data"
CUSTOM_SSL_CERT_DATA: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR..."
CUSTOM_SSL_KEY_DATA: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSEV..."
USE_CUSTOM_SSL: "yes"
CUSTOM_SSL_CERT_PRIORITY: "data"
CUSTOM_SSL_CERT_DATA: |
-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIUJH...certificate content...AAAA
-----END CERTIFICATE-----
CUSTOM_SSL_KEY_DATA: |
-----BEGIN PRIVATE KEY-----
MIIEvQIBADAN...key content...AAAA
-----END PRIVATE KEY-----
USE_CUSTOM_SSL: "yes"
CUSTOM_SSL_CERT_PRIORITY: "file"
CUSTOM_SSL_CERT: "/path/to/your/certificate.pem"
CUSTOM_SSL_KEY: "/path/to/your/private-key.pem"
CUSTOM_SSL_CERT_DATA: "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR..."
CUSTOM_SSL_KEY_DATA: "LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSEV..."
DNSBL
STREAM-Unterstützung
Das DNSBL (Domain Name System Blacklist) Plugin bietet Schutz vor bekannten bösartigen IP-Adressen, indem es die IP-Adressen von Clients mit externen DNSBL-Servern abgleicht. Diese Funktion schützt Ihre Website vor Spam, Botnetzen und verschiedenen Arten von Cyber-Bedrohungen, indem sie auf von der Community gepflegte Listen problematischer IP-Adressen zurückgreift.
So funktioniert es:
- Wenn ein Client eine Verbindung zu Ihrer Website herstellt, fragt BunkerWeb die von Ihnen ausgewählten DNSBL-Server über das DNS-Protokoll ab.
- Die Überprüfung erfolgt durch Senden einer umgekehrten DNS-Anfrage mit der IP-Adresse des Clients an jeden DNSBL-Server.
- Wenn ein DNSBL-Server bestätigt, dass die IP-Adresse des Clients als bösartig aufgeführt ist, wird BunkerWeb den Client automatisch sperren und so verhindern, dass potenzielle Bedrohungen Ihre Anwendung erreichen.
- Die Ergebnisse werden zwischengespeichert, um die Leistung bei wiederholten Besuchen von derselben IP-Adresse zu verbessern.
- Die Abfragen werden effizient mit asynchronen Abfragen durchgeführt, um die Auswirkungen auf die Ladezeiten der Seite zu minimieren.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die DNSBL-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Die DNSBL-Funktion ist standardmäßig deaktiviert. Setzen Sie die Einstellung
USE_DNSBL
aufyes
, um sie zu aktivieren. - DNSBL-Server konfigurieren: Fügen Sie die Domainnamen der DNSBL-Dienste, die Sie verwenden möchten, zur Einstellung
DNSBL_LIST
hinzu. - Einstellungen anwenden: Nach der Konfiguration überprüft BunkerWeb eingehende Verbindungen automatisch mit den angegebenen DNSBL-Servern.
- Wirksamkeit überwachen: Überprüfen Sie die Web-Benutzeroberfläche, um Statistiken über Anfragen zu sehen, die durch DNSBL-Prüfungen blockiert wurden.
Konfigurationseinstellungen
Allgemein
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_DNSBL |
no |
multisite | nein | DNSBL aktivieren: auf yes setzen, um DNSBL-Prüfungen für eingehende Verbindungen zu aktivieren. |
DNSBL_LIST |
bl.blocklist.de sbl.spamhaus.org xbl.spamhaus.org |
global | nein | DNSBL-Server: Liste der zu überprüfenden DNSBL-Server-Domains, durch Leerzeichen getrennt. |
Ausnahmelisten
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
DNSBL_IGNORE_IP |
`` | multisite | ja | Durch Leerzeichen getrennte IPs/CIDRs, für die DNSBL-Prüfungen übersprungen werden sollen (Whitelist). |
DNSBL_IGNORE_IP_URLS |
`` | multisite | ja | Durch Leerzeichen getrennte URLs, die IPs/CIDRs zum Überspringen bereitstellen. Unterstützt http(s):// und file:// . |
Auswahl von DNSBL-Servern
Wählen Sie seriöse DNSBL-Anbieter, um Falschmeldungen zu minimieren. Die Standardliste enthält etablierte Dienste, die für die meisten Websites geeignet sind:
- bl.blocklist.de: Listet IPs, die bei Angriffen auf andere Server erkannt wurden.
- sbl.spamhaus.org: Konzentriert sich auf Spam-Quellen und andere bösartige Aktivitäten.
- xbl.spamhaus.org: Zielt auf infizierte Systeme ab, wie z. B. kompromittierte Maschinen oder offene Proxys.
Wie DNSBL funktioniert
DNSBL-Server funktionieren, indem sie auf speziell formatierte DNS-Anfragen antworten. Wenn BunkerWeb eine IP-Adresse überprüft, kehrt es die IP um und hängt den DNSBL-Domainnamen an. Wenn die resultierende DNS-Anfrage eine „Erfolgs“-Antwort zurückgibt, wird die IP als auf der schwarzen Liste stehend betrachtet.
Leistungsüberlegungen
Obwohl BunkerWeb DNSBL-Abfragen auf Leistung optimiert, könnte das Hinzufügen einer großen Anzahl von DNSBL-Servern potenziell die Antwortzeiten beeinträchtigen. Beginnen Sie mit einigen seriösen DNSBL-Servern und überwachen Sie die Leistung, bevor Sie weitere hinzufügen.
Beispielkonfigurationen
Eine einfache Konfiguration mit den Standard-DNSBL-Servern:
USE_DNSBL: "yes"
DNSBL_LIST: "bl.blocklist.de sbl.spamhaus.org xbl.spamhaus.org"
Eine minimale Konfiguration, die sich auf die zuverlässigsten DNSBL-Dienste konzentriert:
USE_DNSBL: "yes"
DNSBL_LIST: "zen.spamhaus.org"
Diese Konfiguration verwendet nur:
- zen.spamhaus.org: Die kombinierte Liste von Spamhaus wird aufgrund ihrer breiten Abdeckung und ihres Rufs für Genauigkeit oft als eigenständige Lösung als ausreichend angesehen. Sie kombiniert die SBL-, XBL- und PBL-Listen in einer einzigen Abfrage, was sie effizient und umfassend macht.
Sie können bestimmte Clients von DNSBL-Prüfungen ausschließen, indem Sie statische Werte und/oder entfernte Dateien verwenden:
DNSBL_IGNORE_IP
: Fügen Sie durch Leerzeichen getrennte IPs und CIDR-Bereiche hinzu. Beispiel:192.0.2.10 203.0.113.0/24 2001:db8::/32
.DNSBL_IGNORE_IP_URLS
: Geben Sie URLs an, deren Inhalte eine IP/CIDR pro Zeile auflisten. Kommentare, die mit#
oder;
beginnen, werden ignoriert. Doppelte Einträge werden entfernt.
Wenn eine eingehende Client-IP mit der Ausnahmeliste übereinstimmt, überspringt BunkerWeb die DNSBL-Abfragen und speichert das Ergebnis als „ok“ für schnellere nachfolgende Anfragen zwischen.
Der Job dnsbl-download
lädt und speichert stündlich zu ignorierende IPs:
- Protokolle:
https://
,http://
und lokalefile://
-Pfade. - Pro-URL-Cache mit Prüfsumme verhindert redundante Downloads (1 Stunde Toleranz).
- Pro Dienst zusammengeführte Datei:
/var/cache/bunkerweb/dnsbl/<service>/IGNORE_IP.list
. - Wird beim Start geladen und mit
DNSBL_IGNORE_IP
zusammengeführt.
Beispiel, das statische und URL-Quellen kombiniert:
USE_DNSBL: "yes"
DNSBL_LIST: "zen.spamhaus.org"
DNSBL_IGNORE_IP: "10.0.0.0/8 192.168.0.0/16 2001:db8::/32"
DNSBL_IGNORE_IP_URLS: "https://example.com/allow-cidrs.txt file:///etc/bunkerweb/dnsbl/ignore.txt"
Laden Sie zu ignorierende IPs aus lokalen Dateien unter Verwendung von file://
-URLs:
USE_DNSBL: "yes"
DNSBL_LIST: "zen.spamhaus.org"
DNSBL_IGNORE_IP_URLS: "file:///etc/bunkerweb/dnsbl/ignore.txt file:///opt/data/allow-cidrs.txt"
Database
STREAM-Unterstützung
Das Datenbank-Plugin bietet eine robuste Datenbankintegration für BunkerWeb, indem es die zentrale Speicherung und Verwaltung von Konfigurationsdaten, Protokollen und anderen wichtigen Informationen ermöglicht.
Diese Kernkomponente unterstützt mehrere Datenbank-Engines, darunter SQLite, PostgreSQL, MySQL/MariaDB und Oracle, sodass Sie die Datenbanklösung wählen können, die am besten zu Ihrer Umgebung und Ihren Anforderungen passt.
So funktioniert es:
- BunkerWeb verbindet sich mit Ihrer konfigurierten Datenbank über die bereitgestellte URI im SQLAlchemy-Format.
- Kritische Konfigurationsdaten, Laufzeitinformationen und Job-Protokolle werden sicher in der Datenbank gespeichert.
- Automatische Wartungsprozesse optimieren Ihre Datenbank, indem sie das Datenwachstum verwalten und überschüssige Datensätze bereinigen.
- Für Hochverfügbarkeitsszenarien können Sie eine schreibgeschützte Datenbank-URI konfigurieren, die sowohl als Failover als auch zur Entlastung von Leseoperationen dient.
- Datenbankoperationen werden entsprechend Ihrer angegebenen Protokollierungsstufe protokolliert, um eine angemessene Transparenz der Datenbankinteraktionen zu gewährleisten.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Datenbankfunktion zu konfigurieren und zu verwenden:
- Wählen Sie eine Datenbank-Engine: Wählen Sie je nach Ihren Anforderungen zwischen SQLite (Standard), PostgreSQL, MySQL/MariaDB oder Oracle.
- Konfigurieren Sie die Datenbank-URI: Setzen Sie
DATABASE_URI
, um sich mit Ihrer primären Datenbank im SQLAlchemy-Format zu verbinden. - Optionale schreibgeschützte Datenbank: Konfigurieren Sie für Hochverfügbarkeits-Setups eine
DATABASE_URI_READONLY
als Fallback oder für Leseoperationen.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
DATABASE_URI |
sqlite:////var/lib/bunkerweb/db.sqlite3 |
global | nein | Datenbank-URI: Die primäre Datenbankverbindungszeichenfolge im SQLAlchemy-Format. |
DATABASE_URI_READONLY |
global | nein | Schreibgeschützte Datenbank-URI: Optionale Datenbank für schreibgeschützte Operationen oder als Failover. | |
DATABASE_LOG_LEVEL |
warning |
global | nein | Protokollierungsstufe: Die Ausführlichkeitsstufe für Datenbankprotokolle. Optionen: debug , info , warn , warning oder error . |
DATABASE_MAX_JOBS_RUNS |
10000 |
global | nein | Maximale Job-Ausführungen: Die maximale Anzahl von Job-Ausführungsdatensätzen, die vor der automatischen Bereinigung aufbewahrt werden. |
DATABASE_MAX_SESSION_AGE_DAYS |
14 |
global | nein | Sitzungsaufbewahrung: Das maximale Alter (in Tagen) von UI-Benutzersitzungen, bevor sie automatisch bereinigt werden. |
!!! tip "Auswahl der Datenbank" - SQLite (Standard): Ideal für Single-Node-Bereitstellungen oder Testumgebungen aufgrund seiner Einfachheit und dateibasierten Natur. - PostgreSQL: Empfohlen für Produktionsumgebungen mit mehreren BunkerWeb-Instanzen aufgrund seiner Robustheit und Unterstützung für Gleichzeitigkeit. - MySQL/MariaDB: Eine gute Alternative zu PostgreSQL mit ähnlichen produktionsreifen Fähigkeiten. - Oracle: Geeignet für Unternehmensumgebungen, in denen Oracle bereits die Standard-Datenbankplattform ist.
SQLAlchemy-URI-Format
Die Datenbank-URI folgt dem SQLAlchemy-Format:
- SQLite:
sqlite:////pfad/zur/datenbank.sqlite3
- PostgreSQL:
postgresql://benutzername:passwort@hostname:port/datenbank
- MySQL/MariaDB:
mysql://benutzername:passwort@hostname:port/datenbank
odermariadb://benutzername:passwort@hostname:port/datenbank
- Oracle:
oracle://benutzername:passwort@hostname:port/datenbank
Datenbankwartung
Das Plugin führt automatisch tägliche Wartungsjobs aus:
- Bereinigung überschüssiger Job-Ausführungen: Entfernt Historien, die über dem Wert von
DATABASE_MAX_JOBS_RUNS
liegen. - Bereinigung abgelaufener UI-Sitzungen: Löscht UI-Benutzersitzungen, die älter sind als
DATABASE_MAX_SESSION_AGE_DAYS
.
Diese Aufgaben verhindern ein unbegrenztes Datenbankwachstum und bewahren gleichzeitig eine nützliche Betriebshistorie.
Easy Resolve
(PRO)
STREAM-Unterstützung
Provides a simpler way to fix false positives in reports.
Errors
STREAM-Unterstützung
Das Errors-Plugin bietet eine anpassbare Verwaltung von HTTP-Fehlern, um das Erscheinungsbild der Fehlerantworten für Ihre Benutzer zu definieren. So können Sie klare and konsistente Fehlerseiten anzeigen, die Ihrer Identität entsprechen, anstatt der technischen Standardseiten des Servers.
So funktioniert's:
- Wenn ein HTTP-Fehler auftritt (z.B. 400, 404, 500), fängt BunkerWeb die Antwort ab.
- Anstelle der Standardseite zeigt BunkerWeb eine angepasste and sorgfältig gestaltete Seite an.
- Die Fehlerseiten sind konfigurierbar: Sie können für jeden Fehlercode eine HTML-Datei bereitstellen. Die Dateien müssen in dem durch
ROOT_FOLDER
definierten Verzeichnis abgelegt werden (siehe Misc-Plugin).- Standardmäßig ist
ROOT_FOLDER
auf/var/www/html/{server_name}
gesetzt. - Im Multisite-Modus hat jede Site ihren eigenen
ROOT_FOLDER
; platzieren Sie die Fehlerseiten im entsprechenden Ordner für jede Site.
- Standardmäßig ist
- Die Standardseiten erklären das Problem klar and schlagen mögliche Maßnahmen vor.
Verwendung
- Benutzerdefinierte Seiten definieren: Verwenden Sie
ERRORS
, um HTTP-Codes mit HTML-Dateien (imROOT_FOLDER
) zu verknüpfen. - Ihre Seiten konfigurieren: Verwenden Sie die Standardseiten von BunkerWeb oder Ihre eigenen Dateien.
- Abgefangene Codes definieren: Wählen Sie mit
INTERCEPTED_ERROR_CODES
die Codes aus, die immer von BunkerWeb verwaltet werden sollen. - Lassen Sie BunkerWeb den Rest erledigen: Die Fehlerverwaltung wird automatisch angewendet.
Parameter
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
ERRORS |
Multisite | Nein | Benutzerdefinierte Fehlerseiten: Paare CODE=/pfad/seite.html . |
|
INTERCEPTED_ERROR_CODES |
400 401 403 404 405 413 429 500 501 502 503 504 |
Multisite | Nein | Abgefangene Codes: Liste der Codes, die mit der Standardseite verwaltet werden, wenn keine benutzerdefinierte Seite definiert ist. |
Seiten-Design
Die Standardseiten sind klar and lehrreich: Fehlerbeschreibung, mögliche Ursachen, vorgeschlagene Maßnahmen and visuelle Anhaltspunkte.
Fehlertypen
- 4xx (Client-seitig): Ungültige Anfragen, nicht existierende Ressource, fehlende Authentifizierung…
- 5xx (Server-seitig): Unmöglichkeit, eine gültige Anfrage zu bearbeiten (interner Fehler, vorübergehende Nichtverfügbarkeit…).
Beispiele
INTERCEPTED_ERROR_CODES: "400 401 403 404 405 413 429 500 501 502 503 504"
ERRORS: "404=/custom/404.html 500=/custom/500.html"
INTERCEPTED_ERROR_CODES: "400 401 403 404 405 413 429 500 501 502 503 504"
INTERCEPTED_ERROR_CODES: "404 500"
Greylist
STREAM-Unterstützung
Das Greylist-Plugin bietet einen flexiblen Sicherheitsansatz, der Besuchern den Zugriff ermöglicht, während wesentliche Sicherheitsfunktionen weiterhin aktiv bleiben.
Im Gegensatz zu traditionellen Blacklist/Whitelist-Ansätzen, die den Zugriff vollständig blockieren oder erlauben, schafft die Greylist einen Mittelweg, indem sie bestimmten Besuchern den Zugriff gewährt, sie aber dennoch Sicherheitsprüfungen unterzieht.
So funktioniert es:
- Sie definieren Kriterien für Besucher, die auf die Greylist gesetzt werden sollen (IP-Adressen, Netzwerke, rDNS, ASN, User-Agent oder URI-Muster).
- Wenn ein Besucher einem dieser Kriterien entspricht, erhält er Zugriff auf Ihre Website, während die anderen Sicherheitsfunktionen aktiv bleiben.
- Wenn ein Besucher keinem Greylist-Kriterium entspricht, wird sein Zugriff verweigert.
- Greylist-Daten können in regelmäßigen Abständen automatisch aus externen Quellen aktualisiert werden.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Greylist-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Die Greylist-Funktion ist standardmäßig deaktiviert. Setzen Sie die Einstellung
USE_GREYLIST
aufyes
, um sie zu aktivieren. - Greylist-Regeln konfigurieren: Definieren Sie, welche IPs, Netzwerke, rDNS-Muster, ASNs, User-Agents oder URIs auf die Greylist gesetzt werden sollen.
- Externe Quellen hinzufügen: Konfigurieren Sie optional URLs zum automatischen Herunterladen und Aktualisieren von Greylist-Daten.
- Zugriff überwachen: Überprüfen Sie die Web-Benutzeroberfläche, um zu sehen, welchen Besuchern der Zugriff gewährt oder verweigert wird.
Verhalten der Zugriffskontrolle
Wenn die Greylist-Funktion aktiviert ist, indem die Einstellung USE_GREYLIST
auf yes
gesetzt wird:
- Greylist-Besucher: Erhalten Zugriff, unterliegen aber weiterhin allen Sicherheitsprüfungen.
- Nicht-Greylist-Besucher: Wird der Zugriff vollständig verweigert.
Stream-Modus
Im Stream-Modus werden nur IP-, rDNS- und ASN-Prüfungen durchgeführt.
Konfigurationseinstellungen
Allgemein
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_GREYLIST |
no |
multisite | nein | Greylist aktivieren: Auf yes setzen, um Greylisting zu aktivieren. |
Was dies bewirkt: Setzt Besucher basierend auf ihrer IP-Adresse oder ihrem Netzwerk auf die Greylist. Diese Besucher erhalten Zugriff, unterliegen aber weiterhin den Sicherheitsprüfungen.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
GREYLIST_IP |
multisite | nein | IP-Greylist: Liste von IP-Adressen oder Netzwerken (in CIDR-Notation), die auf die Greylist gesetzt werden sollen, getrennt durch Leerzeichen. | |
GREYLIST_IP_URLS |
multisite | nein | IP-Greylist-URLs: Liste von URLs, die IP-Adressen oder Netzwerke enthalten, die auf die Greylist gesetzt werden sollen, getrennt durch Leerzeichen. |
Was dies bewirkt: Setzt Besucher basierend auf ihrem Domainnamen (in umgekehrter Reihenfolge) auf die Greylist. Nützlich, um Besuchern von bestimmten Organisationen oder Netzwerken bedingten Zugriff zu gewähren.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
GREYLIST_RDNS |
multisite | nein | rDNS-Greylist: Liste von Reverse-DNS-Suffixen, die auf die Greylist gesetzt werden sollen, getrennt durch Leerzeichen. | |
GREYLIST_RDNS_GLOBAL |
yes |
multisite | nein | Nur globales rDNS: Führt rDNS-Greylist-Prüfungen nur für globale IP-Adressen durch, wenn auf yes gesetzt. |
GREYLIST_RDNS_URLS |
multisite | nein | rDNS-Greylist-URLs: Liste von URLs, die Reverse-DNS-Suffixe enthalten, die auf die Greylist gesetzt werden sollen, getrennt durch Leerzeichen. |
Was dies bewirkt: Setzt Besucher von bestimmten Netzwerkanbietern mithilfe von Autonomen Systemnummern auf die Greylist. ASNs identifizieren, zu welchem Anbieter oder welcher Organisation eine IP gehört.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
GREYLIST_ASN |
multisite | nein | ASN-Greylist: Liste von Autonomen Systemnummern, die auf die Greylist gesetzt werden sollen, getrennt durch Leerzeichen. | |
GREYLIST_ASN_URLS |
multisite | nein | ASN-Greylist-URLs: Liste von URLs, die ASNs enthalten, die auf die Greylist gesetzt werden sollen, getrennt durch Leerzeichen. |
Was dies bewirkt: Setzt Besucher basierend auf dem Browser oder Tool, das sie angeben zu verwenden, auf die Greylist. Dies ermöglicht kontrollierten Zugriff für bestimmte Tools, während die Sicherheitsprüfungen aufrechterhalten werden.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
GREYLIST_USER_AGENT |
multisite | nein | User-Agent-Greylist: Liste von User-Agent-Mustern (PCRE-Regex), die auf die Greylist gesetzt werden sollen, getrennt durch Leerzeichen. | |
GREYLIST_USER_AGENT_URLS |
multisite | nein | User-Agent-Greylist-URLs: Liste von URLs, die User-Agent-Muster enthalten, die auf die Greylist gesetzt werden sollen. |
Was dies bewirkt: Setzt Anfragen an bestimmte URLs auf Ihrer Website auf die Greylist. Dies ermöglicht bedingten Zugriff auf bestimmte Endpunkte, während die Sicherheitsprüfungen aufrechterhalten werden.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
GREYLIST_URI |
multisite | nein | URI-Greylist: Liste von URI-Mustern (PCRE-Regex), die auf die Greylist gesetzt werden sollen, getrennt durch Leerzeichen. | |
GREYLIST_URI_URLS |
multisite | nein | URI-Greylist-URLs: Liste von URLs, die URI-Muster enthalten, die auf die Greylist gesetzt werden sollen, getrennt durch Leerzeichen. |
Unterstützung von URL-Formaten
Alle *_URLS
-Einstellungen unterstützen HTTP/HTTPS-URLs sowie lokale Dateipfade mit dem Präfix file:///
. Die Basisauthentifizierung wird im Format http://user:pass@url
unterstützt.
Regelmäßige Aktualisierungen
Greylists von URLs werden stündlich automatisch heruntergeladen und aktualisiert, um sicherzustellen, dass Ihr Schutz mit den neuesten vertrauenswürdigen Quellen auf dem neuesten Stand bleibt.
Beispielkonfigurationen
Eine einfache Konfiguration, die Greylisting auf das interne Netzwerk eines Unternehmens und einen Crawler anwendet:
USE_GREYLIST: "yes"
GREYLIST_IP: "192.168.1.0/24 10.0.0.0/8"
GREYLIST_USER_AGENT: "(?:\b)CompanyCrawler(?:\b)"
Eine umfassendere Konfiguration mit mehreren Greylist-Kriterien:
USE_GREYLIST: "yes"
# Unternehmensressourcen und genehmigte Crawler
GREYLIST_IP: "192.168.1.0/24 203.0.113.0/24"
GREYLIST_RDNS: ".company.com .partner-company.org"
GREYLIST_ASN: "12345 67890" # ASNs von Unternehmen und Partnern
GREYLIST_USER_AGENT: "(?:\b)GoodBot(?:\b) (?:\b)PartnerCrawler(?:\b)"
GREYLIST_URI: "^/api/v1/"
# Externe vertrauenswürdige Quellen
GREYLIST_IP_URLS: "https://example.com/trusted-networks.txt"
GREYLIST_USER_AGENT_URLS: "https://example.com/trusted-crawlers.txt"
Konfiguration mit lokalen Dateien für Greylists:
USE_GREYLIST: "yes"
GREYLIST_IP_URLS: "file:///path/to/ip-greylist.txt"
GREYLIST_RDNS_URLS: "file:///path/to/rdns-greylist.txt"
GREYLIST_ASN_URLS: "file:///path/to/asn-greylist.txt"
GREYLIST_USER_AGENT_URLS: "file:///path/to/user-agent-greylist.txt"
GREYLIST_URI_URLS: "file:///path/to/uri-greylist.txt"
Eine Konfiguration, die den Zugriff auf bestimmte API-Endpunkte erlaubt:
USE_GREYLIST: "yes"
GREYLIST_URI: "^/api/v1/public/ ^/api/v1/status"
GREYLIST_IP: "203.0.113.0/24" # Externes Partnernetzwerk
Gzip
STREAM-Unterstützung
Der GZIP-Plugin komprimiert HTTP-Antworten mit dem GZIP-Algorithmus, um die Bandbreite zu reduzieren und das Laden von Seiten zu beschleunigen.
Funktionsweise
- BunkerWeb erkennt, ob der Client GZIP unterstützt.
- Falls ja, wird die Antwort auf dem konfigurierten Niveau komprimiert.
- Die Header zeigen die Verwendung von GZIP an.
- Der Browser dekomprimiert vor der Anzeige.
Verwendung
- Aktivieren:
USE_GZIP: yes
(standardmäßig deaktiviert). - MIME-Typen:
GZIP_TYPES
definieren. - Mindestgröße:
GZIP_MIN_LENGTH
, um sehr kleine Dateien zu vermeiden. - Kompressionsstufe:
GZIP_COMP_LEVEL
(1–9). - Proxied-Inhalt:
GZIP_PROXIED
anpassen.
Parameter
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_GZIP |
no |
Multisite | nein | Aktiviert die GZIP-Kompression. |
GZIP_TYPES |
application/atom+xml application/javascript application/json application/rss+xml application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/x-javascript application/xhtml+xml application/xml font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml |
Multisite | nein | Komprimierte MIME-Typen. |
GZIP_MIN_LENGTH |
1000 |
Multisite | nein | Mindestgröße (Bytes) für die Anwendung der Kompression. |
GZIP_COMP_LEVEL |
5 |
Multisite | nein | Stufe 1–9: höher = bessere Kompression, aber mehr CPU. |
GZIP_PROXIED |
no-cache no-store private expired auth |
Multisite | nein | Gibt an, welche proxied-Inhalte basierend auf den Antwort-Headern komprimiert werden sollen. |
Kompressionsstufe
5
ist ein guter Kompromiss. Statisch/CPU verfügbar: 7–9. Dynamisch/CPU begrenzt: 1–3.
Beispiele
USE_GZIP: "yes"
GZIP_TYPES: "application/javascript application/json application/xml text/css text/html text/javascript text/plain text/xml"
GZIP_MIN_LENGTH: "1000"
GZIP_COMP_LEVEL: "5"
USE_GZIP: "yes"
GZIP_TYPES: "application/atom+xml application/javascript application/json application/rss+xml application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/x-javascript application/xhtml+xml application/xml font/eot font/opentype font/otf font/truetype image/svg+xml image/vnd.microsoft.icon image/x-icon image/x-win-bitmap text/css text/javascript text/plain text/xml"
GZIP_MIN_LENGTH: "500"
GZIP_COMP_LEVEL: "9"
GZIP_PROXIED: "any"
USE_GZIP: "yes"
GZIP_TYPES: "application/javascript application/json text/css text/html text/javascript text/plain"
GZIP_MIN_LENGTH: "1000"
GZIP_COMP_LEVEL: "3"
GZIP_PROXIED: "no-cache no-store private expired"
USE_GZIP: "yes"
GZIP_TYPES: "application/javascript application/json text/css text/html text/javascript"
GZIP_MIN_LENGTH: "1000"
GZIP_COMP_LEVEL: "4"
GZIP_PROXIED: "any"
HTML injection
STREAM-Unterstützung
Das HTML-Injection-Plugin ermöglicht es Ihnen, nahtlos benutzerdefinierten HTML-Code zu den Seiten Ihrer Website vor den schließenden </body>
- oder </head>
-Tags hinzuzufügen. Diese Funktion ist besonders nützlich, um Analyses-Skripte, Tracking-Pixel, benutzerdefiniertes JavaScript, CSS-Stile oder andere Integrationen von Drittanbietern hinzuzufügen, ohne den Quellcode Ihrer Website ändern zu müssen.
So funktioniert es:
- Wenn eine Seite von Ihrer Website ausgeliefert wird, untersucht BunkerWeb die HTML-Antwort.
- Wenn Sie die Body-Injection konfiguriert haben, fügt BunkerWeb Ihren benutzerdefinierten HTML-Code direkt vor dem schließenden
</body>
-Tag ein. - Wenn Sie die Head-Injection konfiguriert haben, fügt BunkerWeb Ihren benutzerdefinierten HTML-Code direkt vor dem schließenden
</head>
-Tag ein. - Das Einfügen erfolgt automatisch für alle HTML-Seiten, die von Ihrer Website ausgeliefert werden.
- Dies ermöglicht es Ihnen, Skripte, Stile oder andere Elemente hinzuzufügen, ohne den Code Ihrer Anwendung ändern zu müssen.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die HTML-Injection-Funktion zu konfigurieren und zu verwenden:
- Bereiten Sie Ihren benutzerdefinierten HTML-Code vor: Entscheiden Sie, welchen HTML-Code Sie in Ihre Seiten einfügen möchten.
- Wählen Sie die Einfügeorte: Bestimmen Sie, ob Sie Code im
<head>
-Bereich, im<body>
-Bereich oder in beiden einfügen müssen. - Konfigurieren Sie die Einstellungen: Fügen Sie Ihren benutzerdefinierten HTML-Code zu den entsprechenden Einstellungen (
INJECT_HEAD
und/oderINJECT_BODY
) hinzu. - Lassen Sie BunkerWeb den Rest erledigen: Nach der Konfiguration wird der HTML-Code automatisch in alle ausgelieferten HTML-Seiten eingefügt.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
INJECT_HEAD |
multisite | nein | Head-HTML-Code: Der HTML-Code, der vor dem </head> -Tag eingefügt wird. |
|
INJECT_BODY |
multisite | nein | Body-HTML-Code: Der HTML-Code, der vor dem </body> -Tag eingefügt wird. |
!!! tip "Bewährte Praktiken" - Aus Leistungsgründen sollten Sie JavaScript-Dateien am Ende des Body platzieren, um das Rendern nicht zu blockieren. - Platzieren Sie CSS und kritisches JavaScript im Head-Bereich, um ein Aufblitzen von ungestyltem Inhalt zu vermeiden. - Seien Sie vorsichtig mit eingefügtem Inhalt, der die Funktionalität Ihrer Website beeinträchtigen könnte.
!!! info "Häufige Anwendungsfälle" - Hinzufügen von Analyses-Skripten (wie Google Analytics, Matomo) - Integration von Chat-Widgets oder Kundensupport-Tools - Einbinden von Tracking-Pixeln für Marketingkampagnen - Hinzufügen von benutzerdefinierten CSS-Stilen oder JavaScript-Funktionen - Einbinden von Bibliotheken von Drittanbietern, ohne den Anwendungscode zu ändern
Beispielkonfigurationen
Hinzufügen von Google-Analytics-Tracking zu Ihrer Website:
INJECT_HEAD: ""
INJECT_BODY: "<script async src=\"https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX\"></script><script>window.dataLayer = window.dataLayer || [];function gtag(){dataLayer.push(arguments);}gtag('js', new Date());gtag('config', 'G-XXXXXXXXXX');</script>"
Hinzufügen von benutzerdefinierten CSS-Stilen zu Ihrer Website:
INJECT_HEAD: "<style>body { font-family: 'Arial', sans-serif; } .custom-element { color: blue; }</style>"
INJECT_BODY: ""
Hinzufügen von sowohl benutzerdefinierten Stilen als auch JavaScript:
INJECT_HEAD: "<style>body { font-family: 'Arial', sans-serif; } .notification-banner { background: #f8f9fa; padding: 10px; text-align: center; }</style>"
INJECT_BODY: "<script src=\"https://cdn.example.com/js/widget.js\"></script><script>initializeWidget('your-api-key');</script>"
Hinzufügen eines einfachen Cookie-Einwilligungsbanners:
INJECT_HEAD: "<style>.cookie-banner { position: fixed; bottom: 0; left: 0; right: 0; background: #f1f1f1; padding: 20px; text-align: center; z-index: 1000; } .cookie-banner button { background: #4CAF50; border: none; color: white; padding: 10px 20px; cursor: pointer; }</style>"
INJECT_BODY: "<div id=\"cookie-banner\" class=\"cookie-banner\">Diese Website verwendet Cookies, um sicherzustellen, dass Sie das beste Erlebnis erhalten. <button onclick=\"acceptCookies()\">Akzeptieren</button></div><script>function acceptCookies() { document.getElementById('cookie-banner').style.display = 'none'; localStorage.setItem('cookies-accepted', 'true'); } if(localStorage.getItem('cookies-accepted') === 'true') { document.getElementById('cookie-banner').style.display = 'none'; }</script>"
Headers
STREAM-Unterstützung
HTTP-Header spielen eine entscheidende Rolle bei der Sicherheit. Das Headers-Plugin bietet eine robuste Verwaltung von Standard- und benutzerdefinierten HTTP-Headern und verbessert so Sicherheit und Funktionalität. Es wendet dynamisch Sicherheitsmaßnahmen an, wie HSTS, CSP (einschließlich eines reinen Berichtsmodus) und die Injektion benutzerdefinierter Header, während es gleichzeitig Informationslecks verhindert.
Wie es funktioniert
- Wenn ein Client Inhalte von Ihrer Website anfordert, verarbeitet BunkerWeb die Antwort-Header.
- Sicherheits-Header werden gemäß Ihrer Konfiguration angewendet.
- Benutzerdefinierte Header können hinzugefügt werden, um Clients zusätzliche Informationen oder Funktionen bereitzustellen.
- Unerwünschte Header, die Serverinformationen preisgeben könnten, werden automatisch entfernt.
- Cookies werden so geändert, dass sie je nach Ihren Einstellungen die entsprechenden Sicherheitsflags enthalten.
- Header von Upstream-Servern können bei Bedarf selektiv beibehalten werden.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Headers-Funktion zu konfigurieren und zu verwenden:
- Sicherheits-Header konfigurieren: Legen Sie Werte für gängige Header fest.
- Benutzerdefinierte Header hinzufügen: Definieren Sie beliebige benutzerdefinierte Header mit der Einstellung
CUSTOM_HEADER
. - Unerwünschte Header entfernen: Verwenden Sie
REMOVE_HEADERS
, um sicherzustellen, dass Header, die Serverdetails preisgeben könnten, entfernt werden. - Cookie-Sicherheit einstellen: Aktivieren Sie eine robuste Cookie-Sicherheit, indem Sie
COOKIE_FLAGS
konfigurieren undCOOKIE_AUTO_SECURE_FLAG
aufyes
setzen, damit das Secure-Flag bei HTTPS-Verbindungen automatisch hinzugefügt wird. - Upstream-Header beibehalten: Geben Sie mit
KEEP_UPSTREAM_HEADERS
an, welche Upstream-Header beibehalten werden sollen. - Bedingte Header-Anwendung nutzen: Wenn Sie Richtlinien ohne Unterbrechung testen möchten, aktivieren Sie den CSP Report-Only-Modus über
CONTENT_SECURITY_POLICY_REPORT_ONLY
.
Konfigurationsleitfaden
Überblick
Sicherheits-Header erzwingen eine sichere Kommunikation, schränken das Laden von Ressourcen ein und verhindern Angriffe wie Clickjacking und Injection. Richtig konfigurierte Header bilden eine robuste Verteidigungsschicht für Ihre Website.
Vorteile von Sicherheits-Headern
- HSTS: Stellt sicher, dass alle Verbindungen verschlüsselt sind, und schützt so vor Protokoll-Downgrade-Angriffen.
- CSP: Verhindert die Ausführung bösartiger Skripte und verringert so das Risiko von XSS-Angriffen.
- X-Frame-Options: Blockiert Clickjacking-Versuche durch die Kontrolle der Iframe-Einbettung.
- Referrer Policy: Begrenzt das Durchsickern sensibler Informationen über Referrer-Header.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
STRICT_TRANSPORT_SECURITY |
max-age=63072000; includeSubDomains; preload |
multisite | nein | HSTS: Erzwingt sichere HTTPS-Verbindungen und verringert das Risiko von Man-in-the-Middle-Angriffen. |
CONTENT_SECURITY_POLICY |
object-src 'none'; form-action 'self'; frame-ancestors 'self'; |
multisite | nein | CSP: Beschränkt das Laden von Ressourcen auf vertrauenswürdige Quellen und mindert Cross-Site-Scripting- und Dateninjektionsangriffe. |
CONTENT_SECURITY_POLICY_REPORT_ONLY |
no |
multisite | nein | CSP-Berichtsmodus: Meldet Verstöße, ohne Inhalte zu blockieren, und hilft beim Testen von Sicherheitsrichtlinien, während Protokolle erfasst werden. |
X_FRAME_OPTIONS |
SAMEORIGIN |
multisite | nein | X-Frame-Options: Verhindert Clickjacking, indem es steuert, ob Ihre Website in einem Frame dargestellt werden kann. |
X_CONTENT_TYPE_OPTIONS |
nosniff |
multisite | nein | X-Content-Type-Options: Verhindert, dass Browser MIME-Sniffing betreiben, und schützt so vor Drive-by-Download-Angriffen. |
X_DNS_PREFETCH_CONTROL |
off |
multisite | nein | X-DNS-Prefetch-Control: Reguliert das DNS-Prefetching, um unbeabsichtigte Netzwerkanfragen zu reduzieren und die Privatsphäre zu verbessern. |
REFERRER_POLICY |
strict-origin-when-cross-origin |
multisite | nein | Referrer Policy: Steuert die Menge der gesendeten Referrer-Informationen und schützt die Privatsphäre der Benutzer. |
PERMISSIONS_POLICY |
accelerometer=(), ambient-light-sensor=(), attribution-reporting=(), autoplay=(), battery=(), ... |
multisite | nein | Permissions Policy: Beschränkt den Zugriff auf Browserfunktionen und reduziert potenzielle Angriffsvektoren. |
KEEP_UPSTREAM_HEADERS |
Content-Security-Policy Permissions-Policy X-Frame-Options |
multisite | nein | Header beibehalten: Behält ausgewählte Upstream-Header bei, was die Integration von Altsystemen erleichtert und gleichzeitig die Sicherheit aufrechterhält. |
Bewährte Praktiken
- Überprüfen und aktualisieren Sie Ihre Sicherheits-Header regelmäßig, um sie an die sich entwickelnden Sicherheitsstandards anzupassen.
- Verwenden Sie Tools wie das Mozilla Observatory, um Ihre Header-Konfiguration zu validieren.
- Testen Sie CSP im
Report-Only
-Modus, bevor Sie es erzwingen, um zu vermeiden, dass die Funktionalität beeinträchtigt wird.
Überblick
Richtige Cookie-Einstellungen gewährleisten sichere Benutzersitzungen, indem sie Hijacking, Fixierung und Cross-Site-Scripting verhindern. Sichere Cookies erhalten die Sitzungsintegrität über HTTPS und verbessern den allgemeinen Schutz der Benutzerdaten.
Vorteile sicherer Cookies
- HttpOnly-Flag: Verhindert, dass clientseitige Skripte auf Cookies zugreifen, und mindert so XSS-Risiken.
- SameSite-Flag: Reduziert CSRF-Angriffe, indem die Verwendung von Cookies über verschiedene Ursprünge hinweg eingeschränkt wird.
- Secure-Flag: Stellt sicher, dass Cookies nur über verschlüsselte HTTPS-Verbindungen übertragen werden.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
COOKIE_FLAGS |
* HttpOnly SameSite=Lax |
multisite | ja | Cookie-Flags: Fügt automatisch Sicherheitsflags wie HttpOnly und SameSite hinzu und schützt Cookies so vor dem Zugriff durch clientseitige Skripte und CSRF-Angriffe. |
COOKIE_AUTO_SECURE_FLAG |
yes |
multisite | nein | Automatisches Secure-Flag: Stellt sicher, dass Cookies nur über sichere HTTPS-Verbindungen gesendet werden, indem das Secure-Flag automatisch angehängt wird. |
Bewährte Praktiken
- Verwenden Sie
SameSite=Strict
für sensible Cookies, um den Zugriff über verschiedene Ursprünge hinweg zu verhindern. - Überprüfen Sie Ihre Cookie-Einstellungen regelmäßig, um die Einhaltung der Sicherheits- und Datenschutzbestimmungen sicherzustellen.
- Vermeiden Sie es, Cookies ohne das Secure-Flag in Produktionsumgebungen zu setzen.
Überblick
Benutzerdefinierte Header ermöglichen es Ihnen, spezifische HTTP-Header hinzuzufügen, um Anwendungs- oder Leistungsanforderungen zu erfüllen. Sie bieten Flexibilität, müssen aber sorgfältig konfiguriert werden, um die Preisgabe sensibler Serverdetails zu vermeiden.
Vorteile von benutzerdefinierten Headern
- Verbessern Sie die Sicherheit, indem Sie unnötige Header entfernen, die Serverdetails preisgeben könnten.
- Fügen Sie anwendungsspezifische Header hinzu, um die Funktionalität oder das Debugging zu verbessern.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
CUSTOM_HEADER |
multisite | ja | Benutzerdefinierter Header: Bietet eine Möglichkeit, benutzerdefinierte Header im Format HeaderName: HeaderValue für spezielle Sicherheits- oder Leistungsverbesserungen hinzuzufügen. |
|
REMOVE_HEADERS |
Server Expect-CT X-Powered-By X-AspNet-Version X-AspNetMvc-Version Public-Key-Pins |
multisite | nein | Header entfernen: Gibt an, welche Header entfernt werden sollen, um die Wahrscheinlichkeit der Preisgabe interner Serverdetails und bekannter Schwachstellen zu verringern. |
Sicherheitsaspekte
- Vermeiden Sie die Preisgabe sensibler Informationen durch benutzerdefinierte Header.
- Überprüfen und aktualisieren Sie benutzerdefinierte Header regelmäßig, um sie an die Anforderungen Ihrer Anwendung anzupassen.
Bewährte Praktiken
- Verwenden Sie
REMOVE_HEADERS
, um Header wieServer
undX-Powered-By
zu entfernen und so das Risiko des Fingerprintings zu verringern. - Testen Sie benutzerdefinierte Header in einer Staging-Umgebung, bevor Sie sie in der Produktion einsetzen.
Beispielkonfigurationen
Eine Standardkonfiguration mit wesentlichen Sicherheits-Headern:
STRICT_TRANSPORT_SECURITY: "max-age=63072000; includeSubDomains; preload"
CONTENT_SECURITY_POLICY: "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'"
X_FRAME_OPTIONS: "SAMEORIGIN"
X_CONTENT_TYPE_OPTIONS: "nosniff"
REFERRER_POLICY: "strict-origin-when-cross-origin"
REMOVE_HEADERS: "Server X-Powered-By X-AspNet-Version"
Konfiguration mit robusten Cookie-Sicherheitseinstellungen:
COOKIE_FLAGS: "* HttpOnly SameSite=Strict"
COOKIE_FLAGS_2: "session_cookie Secure HttpOnly SameSite=Strict"
COOKIE_FLAGS_3: "auth_cookie Secure HttpOnly SameSite=Strict Max-Age=3600"
COOKIE_AUTO_SECURE_FLAG: "yes"
Konfiguration für einen API-Dienst mit benutzerdefinierten Headern:
CUSTOM_HEADER: "API-Version: 1.2.3"
CUSTOM_HEADER_2: "Access-Control-Max-Age: 86400"
CONTENT_SECURITY_POLICY: "default-src 'none'; frame-ancestors 'none'"
REMOVE_HEADERS: "Server X-Powered-By X-AspNet-Version X-Runtime"
Konfiguration zum Testen von CSP, ohne die Funktionalität zu beeinträchtigen:
CONTENT_SECURITY_POLICY: "default-src 'self'; script-src 'self' https://trusted-cdn.example.com; img-src 'self' data: https://*.example.com; style-src 'self' 'unsafe-inline' https://trusted-cdn.example.com; connect-src 'self' https://api.example.com; object-src 'none'; frame-ancestors 'self'; form-action 'self'; base-uri 'self'; report-uri https://example.com/csp-reports"
CONTENT_SECURITY_POLICY_REPORT_ONLY: "yes"
Let's Encrypt
STREAM-Unterstützung
Das Let's Encrypt-Plugin vereinfacht die Verwaltung von SSL/TLS-Zertifikaten durch die Automatisierung der Erstellung, Erneuerung und Konfiguration von kostenlosen Zertifikaten von Let's Encrypt. Diese Funktion ermöglicht sichere HTTPS-Verbindungen für Ihre Websites ohne die Komplexität der manuellen Zertifikatsverwaltung, was sowohl Kosten als auch administrativen Aufwand reduziert.
Wie es funktioniert:
- Nach der Aktivierung erkennt BunkerWeb automatisch die für Ihre Website konfigurierten Domains.
- BunkerWeb beantragt kostenlose SSL/TLS-Zertifikate bei der Zertifizierungsstelle von Let's Encrypt.
- Der Domainbesitz wird entweder durch HTTP-Challenges (Nachweis, dass Sie die Website kontrollieren) oder DNS-Challenges (Nachweis, dass Sie die DNS Ihrer Domain kontrollieren) verifiziert.
- Zertifikate werden automatisch für Ihre Domains installiert und konfiguriert.
- BunkerWeb kümmert sich im Hintergrund um die Erneuerung der Zertifikate vor deren Ablauf und gewährleistet so eine kontinuierliche HTTPS-Verfügbarkeit.
- Der gesamte Prozess ist vollständig automatisiert und erfordert nach der Ersteinrichtung nur minimale Eingriffe.
Voraussetzungen
Um diese Funktion nutzen zu können, stellen Sie sicher, dass für jede Domain korrekte DNS-A-Einträge konfiguriert sind, die auf die öffentliche(n) IP(s) verweisen, unter der/denen BunkerWeb erreichbar ist. Ohne korrekte DNS-Konfiguration schlägt der Domain-Verifizierungsprozess fehl.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Let's Encrypt-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Setzen Sie die Einstellung
AUTO_LETS_ENCRYPT
aufyes
, um die automatische Ausstellung und Erneuerung von Zertifikaten zu aktivieren. - Geben Sie eine Kontakt-E-Mail an: Geben Sie Ihre E-Mail-Adresse in der Einstellung
EMAIL_LETS_ENCRYPT
ein, um wichtige Benachrichtigungen über Ihre Zertifikate zu erhalten. - Wählen Sie den Challenge-Typ: Wählen Sie entweder die
http
- oderdns
-Verifizierung mit der EinstellungLETS_ENCRYPT_CHALLENGE
. - DNS-Anbieter konfigurieren: Wenn Sie DNS-Challenges verwenden, geben Sie Ihren DNS-Anbieter und Ihre Anmeldeinformationen an.
- Zertifikatsprofil auswählen: Wählen Sie Ihr bevorzugtes Zertifikatsprofil mit der Einstellung
LETS_ENCRYPT_PROFILE
(classic, tlsserver oder shortlived). - Lassen Sie BunkerWeb den Rest erledigen: Nach der Konfiguration werden Zertifikate automatisch ausgestellt, installiert und bei Bedarf erneuert.
Zertifikatsprofile
Let's Encrypt bietet verschiedene Zertifikatsprofile für unterschiedliche Anwendungsfälle: - classic: Allzweck-Zertifikate mit 90-tägiger Gültigkeit (Standard) - tlsserver: Optimiert für die TLS-Server-Authentifizierung mit 90-tägiger Gültigkeit und kleinerem Payload - shortlived: Erhöhte Sicherheit mit 7-tägiger Gültigkeit für automatisierte Umgebungen - custom: Wenn Ihr ACME-Server ein anderes Profil unterstützt, legen Sie es mit LETS_ENCRYPT_CUSTOM_PROFILE
fest.
Profilverfügbarkeit
Beachten Sie, dass die Profile tlsserver
und shortlived
derzeit möglicherweise nicht in allen Umgebungen oder mit allen ACME-Clients verfügbar sind. Das classic
-Profil hat die breiteste Kompatibilität und wird für die meisten Benutzer empfohlen. Wenn ein ausgewähltes Profil nicht verfügbar ist, greift das System automatisch auf das classic
-Profil zurück.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
AUTO_LETS_ENCRYPT |
no |
multisite | nein | Let's Encrypt aktivieren: Auf yes setzen, um die automatische Ausstellung und Erneuerung von Zertifikaten zu aktivieren. |
LETS_ENCRYPT_PASSTHROUGH |
no |
multisite | nein | Let's Encrypt durchleiten: Auf yes setzen, um Let's Encrypt-Anfragen an den Webserver weiterzuleiten. Dies ist nützlich, wenn BunkerWeb hinter einem anderen Reverse-Proxy mit SSL-Handling steht. |
EMAIL_LETS_ENCRYPT |
contact@{FIRST_SERVER} |
multisite | nein | Kontakt-E-Mail: E-Mail-Adresse, die für Let's Encrypt-Benachrichtigungen verwendet und in Zertifikate aufgenommen wird. |
LETS_ENCRYPT_CHALLENGE |
http |
multisite | nein | Challenge-Typ: Methode zur Überprüfung des Domainbesitzes. Optionen: http oder dns . |
LETS_ENCRYPT_DNS_PROVIDER |
multisite | nein | DNS-Anbieter: Bei Verwendung von DNS-Challenges der zu verwendende DNS-Anbieter (z.B. cloudflare, route53, digitalocean). | |
LETS_ENCRYPT_DNS_PROPAGATION |
default |
multisite | nein | DNS-Propagation: Die Wartezeit für die DNS-Propagation in Sekunden. Wenn kein Wert angegeben wird, wird die Standard-Propagationszeit des Anbieters verwendet. |
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM |
multisite | ja | Anmeldeinformationselement: Konfigurationselemente für die Authentifizierung des DNS-Anbieters (z. B. cloudflare_api_token 123456 ). Werte können Rohtext, base64-kodiert oder ein JSON-Objekt sein. |
|
USE_LETS_ENCRYPT_WILDCARD |
no |
multisite | nein | Wildcard-Zertifikate: Wenn auf yes gesetzt, werden Wildcard-Zertifikate für alle Domains erstellt. Nur mit DNS-Challenges verfügbar. |
USE_LETS_ENCRYPT_STAGING |
no |
multisite | nein | Staging verwenden: Wenn auf yes gesetzt, wird die Staging-Umgebung von Let's Encrypt zum Testen verwendet. Staging hat höhere Ratenbegrenzungen, aber die Zertifikate sind nicht vertrauenswürdig. |
LETS_ENCRYPT_CLEAR_OLD_CERTS |
no |
global | nein | Alte Zertifikate löschen: Wenn auf yes gesetzt, werden alte Zertifikate, die bei der Erneuerung nicht mehr benötigt werden, entfernt. |
LETS_ENCRYPT_PROFILE |
classic |
multisite | nein | Zertifikatsprofil: Wählen Sie das zu verwendende Zertifikatsprofil aus. Optionen: classic (Allzweck), tlsserver (optimiert für TLS-Server) oder shortlived (7-Tage-Zertifikate). |
LETS_ENCRYPT_CUSTOM_PROFILE |
multisite | nein | Benutzerdefiniertes Zertifikatsprofil: Geben Sie ein benutzerdefiniertes Zertifikatsprofil ein, wenn Ihr ACME-Server nicht standardmäßige Profile unterstützt. Dies überschreibt LETS_ENCRYPT_PROFILE , falls gesetzt. |
|
LETS_ENCRYPT_MAX_RETRIES |
3 |
multisite | nein | Maximale Wiederholungen: Anzahl der Wiederholungsversuche bei der Zertifikatserstellung bei einem Fehler. Auf 0 setzen, um Wiederholungen zu deaktivieren. Nützlich bei temporären Netzwerkproblemen. |
!!! info "Informationen und Verhalten" - Die Einstellung LETS_ENCRYPT_DNS_CREDENTIAL_ITEM
ist eine Mehrfacheinstellung und kann verwendet werden, um mehrere Elemente für den DNS-Anbieter festzulegen. Die Elemente werden als Cache-Datei gespeichert, und Certbot liest die Anmeldeinformationen daraus. - Wenn keine LETS_ENCRYPT_DNS_PROPAGATION
-Einstellung angegeben ist, wird die Standard-Propagationszeit des Anbieters verwendet. - Die vollständige Let's Encrypt-Automatisierung mit der http
-Challenge funktioniert im Stream-Modus, solange Sie den Port 80/tcp
von außen öffnen. Verwenden Sie die Einstellung LISTEN_STREAM_PORT_SSL
, um Ihren SSL/TLS-Listening-Port zu wählen. - Wenn LETS_ENCRYPT_PASSTHROUGH
auf yes
gesetzt ist, behandelt BunkerWeb die ACME-Challenge-Anfragen nicht selbst, sondern leitet sie an den Backend-Webserver weiter. Dies ist nützlich in Szenarien, in denen BunkerWeb als Reverse-Proxy vor einem anderen Server fungiert, der für die Verarbeitung von Let's Encrypt-Challenges konfiguriert ist.
HTTP- vs. DNS-Challenges
HTTP-Challenges sind einfacher einzurichten und funktionieren für die meisten Websites gut:
- Erfordert, dass Ihre Website öffentlich auf Port 80 erreichbar ist
- Wird automatisch von BunkerWeb konfiguriert
- Kann nicht für Wildcard-Zertifikate verwendet werden
DNS-Challenges bieten mehr Flexibilität und sind für Wildcard-Zertifikate erforderlich:
- Funktioniert auch, wenn Ihre Website nicht öffentlich erreichbar ist
- Erfordert API-Anmeldeinformationen des DNS-Anbieters
- Erforderlich für Wildcard-Zertifikate (z. B. *.example.com)
- Nützlich, wenn Port 80 blockiert oder nicht verfügbar ist
Wildcard-Zertifikate
Wildcard-Zertifikate sind nur mit DNS-Challenges verfügbar. Wenn Sie sie verwenden möchten, müssen Sie die Einstellung USE_LETS_ENCRYPT_WILDCARD
auf yes
setzen und Ihre DNS-Anbieter-Anmeldeinformationen korrekt konfigurieren.
Ratenbegrenzungen
Let's Encrypt hat Ratenbegrenzungen für die Ausstellung von Zertifikaten. Verwenden Sie beim Testen von Konfigurationen die Staging-Umgebung, indem Sie USE_LETS_ENCRYPT_STAGING
auf yes
setzen, um zu vermeiden, dass Sie die Produktions-Ratenbegrenzungen erreichen. Staging-Zertifikate sind von Browsern nicht vertrauenswürdig, aber nützlich zur Validierung Ihrer Einrichtung.
Unterstützte DNS-Anbieter
Das Let's Encrypt-Plugin unterstützt eine breite Palette von DNS-Anbietern für DNS-Challenges. Jeder Anbieter benötigt spezifische Anmeldeinformationen, die über die Einstellung LETS_ENCRYPT_DNS_CREDENTIAL_ITEM
bereitgestellt werden müssen.
Anbieter | Beschreibung | Obligatorische Einstellungen | Optionale Einstellungen | Dokumentation |
---|---|---|---|---|
bunny |
bunny.net | api_key |
Dokumentation | |
cloudflare |
Cloudflare | entweder api_token oder email und api_key |
Dokumentation | |
desec |
deSEC | token |
Dokumentation | |
digitalocean |
DigitalOcean | token |
Dokumentation | |
domainoffensive |
Domain-Offensive | api_token |
Dokumentation | |
dnsimple |
DNSimple | token |
Dokumentation | |
dnsmadeeasy |
DNS Made Easy | api_key secret_key |
Dokumentation | |
dynu |
Dynu | auth_token |
Dokumentation | |
gehirn |
Gehirn DNS | api_token api_secret |
Dokumentation | |
google |
Google Cloud | project_id private_key_id private_key client_email client_id client_x509_cert_url |
type (Standard: service_account )auth_uri (Standard: https://accounts.google.com/o/oauth2/auth )token_uri (Standard: https://accounts.google.com/o/oauth2/token )auth_provider_x509_cert_url (Standard: https://www.googleapis.com/oauth2/v1/certs ) |
Dokumentation |
infomaniak |
Infomaniak | token |
Dokumentation | |
ionos |
IONOS | prefix secret |
endpoint (Standard: https://api.hosting.ionos.com ) |
Dokumentation |
linode |
Linode | key |
Dokumentation | |
luadns |
LuaDNS | email token |
Dokumentation | |
njalla |
Njalla | token |
Dokumentation | |
nsone |
NS1 | api_key |
Dokumentation | |
ovh |
OVH | application_key application_secret consumer_key |
endpoint (Standard: ovh-eu ) |
Dokumentation |
rfc2136 |
RFC 2136 | server name secret |
port (Standard: 53 )algorithm (Standard: HMAC-SHA512 )sign_query (Standard: false ) |
Dokumentation |
route53 |
Amazon Route 53 | access_key_id secret_access_key |
Dokumentation | |
sakuracloud |
Sakura Cloud | api_token api_secret |
Dokumentation | |
scaleway |
Scaleway | application_token |
Dokumentation |
Beispielkonfigurationen
Einfache Konfiguration mit HTTP-Challenges für eine einzelne Domain:
AUTO_LETS_ENCRYPT: "yes"
EMAIL_LETS_ENCRYPT: "admin@example.com"
LETS_ENCRYPT_CHALLENGE: "http"
Konfiguration für Wildcard-Zertifikate mit Cloudflare DNS:
AUTO_LETS_ENCRYPT: "yes"
EMAIL_LETS_ENCRYPT: "admin@example.com"
LETS_ENCRYPT_CHALLENGE: "dns"
LETS_ENCRYPT_DNS_PROVIDER: "cloudflare"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM: "api_token IHR_API_TOKEN"
USE_LETS_ENCRYPT_WILDCARD: "yes"
Konfiguration mit Amazon Route53 für DNS-Challenges:
AUTO_LETS_ENCRYPT: "yes"
EMAIL_LETS_ENCRYPT: "admin@example.com"
LETS_ENCRYPT_CHALLENGE: "dns"
LETS_ENCRYPT_DNS_PROVIDER: "route53"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM: "aws_access_key_id IHR_ZUGRIFFSSCHLUESSEL"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM_2: "aws_secret_access_key IHR_GEHEIMSCHLUESSEL"
Konfiguration zum Testen der Einrichtung mit der Staging-Umgebung und erweiterten Wiederholungseinstellungen:
AUTO_LETS_ENCRYPT: "yes"
EMAIL_LETS_ENCRYPT: "admin@example.com"
LETS_ENCRYPT_CHALLENGE: "http"
USE_LETS_ENCRYPT_STAGING: "yes"
LETS_ENCRYPT_MAX_RETRIES: "5"
Konfiguration mit DigitalOcean DNS mit einer längeren Propagationswartezeit:
AUTO_LETS_ENCRYPT: "yes"
EMAIL_LETS_ENCRYPT: "admin@example.com"
LETS_ENCRYPT_CHALLENGE: "dns"
LETS_ENCRYPT_DNS_PROVIDER: "digitalocean"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM: "token IHR_API_TOKEN"
LETS_ENCRYPT_DNS_PROPAGATION: "120"
Konfiguration mit Google Cloud DNS mit Anmeldeinformationen für ein Dienstkonto:
AUTO_LETS_ENCRYPT: "yes"
EMAIL_LETS_ENCRYPT: "admin@example.com"
LETS_ENCRYPT_CHALLENGE: "dns"
LETS_ENCRYPT_DNS_PROVIDER: "google"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM: "project_id ihre-projekt-id"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM_2: "private_key_id ihre-private-key-id"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM_3: "private_key ihr-private-key"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM_4: "client_email ihre-dienstkonto-email"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM_5: "client_id ihre-client-id"
LETS_ENCRYPT_DNS_CREDENTIAL_ITEM_6: "client_x509_cert_url ihre-zertifikats-url"
Limit
STREAM-Unterstützung
Das Limit-Plugin in BunkerWeb bietet robuste Funktionen zur Durchsetzung von Begrenzungsrichtlinien auf Ihrer Website, um eine faire Nutzung zu gewährleisten und Ihre Ressourcen vor Missbrauch, Denial-of-Service-Angriffen und übermäßigem Ressourcenverbrauch zu schützen. Diese Richtlinien umfassen:
- Anzahl der Verbindungen pro IP-Adresse (STREAM-Unterstützung
)
- Anzahl der Anfragen pro IP-Adresse und URL innerhalb eines bestimmten Zeitraums (STREAM-Unterstützung
)
Wie es funktioniert
- Ratenbegrenzung: Verfolgt die Anzahl der Anfragen von jeder Client-IP-Adresse an bestimmte URLs. Wenn ein Client die konfigurierte Ratenbegrenzung überschreitet, werden nachfolgende Anfragen vorübergehend abgelehnt.
- Verbindungsbegrenzung: Überwacht und beschränkt die Anzahl der gleichzeitigen Verbindungen von jeder Client-IP-Adresse. Je nach verwendetem Protokoll (HTTP/1, HTTP/2, HTTP/3 oder Stream) können unterschiedliche Verbindungsgrenzen angewendet werden.
- In beiden Fällen erhalten Clients, die die definierten Grenzwerte überschreiten, den HTTP-Statuscode „429 - Too Many Requests“, was hilft, eine Serverüberlastung zu verhindern.
Schritte zur Verwendung
- Anforderungsratenbegrenzung aktivieren: Verwenden Sie
USE_LIMIT_REQ
, um die Anforderungsratenbegrenzung zu aktivieren und URL-Muster zusammen mit ihren entsprechenden Ratenbegrenzungen zu definieren. - Verbindungsbegrenzung aktivieren: Verwenden Sie
USE_LIMIT_CONN
, um die Verbindungsbegrenzung zu aktivieren und die maximale Anzahl gleichzeitiger Verbindungen für verschiedene Protokolle festzulegen. - Granulare Kontrolle anwenden: Erstellen Sie mehrere Ratenbegrenzungsregeln für verschiedene URLs, um unterschiedliche Schutzniveaus auf Ihrer gesamten Website bereitzustellen.
- Wirksamkeit überwachen: Verwenden Sie die Web-Benutzeroberfläche, um Statistiken über begrenzte Anfragen und Verbindungen anzuzeigen.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_LIMIT_REQ |
yes |
multisite | nein | Anforderungsbegrenzung aktivieren: Auf yes setzen, um die Funktion zur Ratenbegrenzung von Anfragen zu aktivieren. |
LIMIT_REQ_URL |
/ |
multisite | ja | URL-Muster: URL-Muster (PCRE-Regex), auf das die Ratenbegrenzung angewendet wird; verwenden Sie / , um es für alle Anfragen anzuwenden. |
LIMIT_REQ_RATE |
2r/s |
multisite | ja | Ratenbegrenzung: Maximale Anfragerate im Format Nr/t , wobei N die Anzahl der Anfragen und t die Zeiteinheit ist: s (Sekunde), m (Minute), h (Stunde) oder d (Tag). |
Format der Ratenbegrenzung
Das Format der Ratenbegrenzung wird als Nr/t
angegeben, wobei:
N
die Anzahl der erlaubten Anfragen istr
ein literales 'r' ist (für 'requests')/
ein literaler Schrägstrich istt
die Zeiteinheit ist:s
(Sekunde),m
(Minute),h
(Stunde) oderd
(Tag)
Zum Beispiel bedeutet 5r/m
, dass 5 Anfragen pro Minute von jeder IP-Adresse erlaubt sind.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_LIMIT_CONN |
yes |
multisite | nein | Verbindungsbegrenzung aktivieren: Auf yes setzen, um die Funktion zur Verbindungsbegrenzung zu aktivieren. |
LIMIT_CONN_MAX_HTTP1 |
10 |
multisite | nein | HTTP/1.X-Verbindungen: Maximale Anzahl gleichzeitiger HTTP/1.X-Verbindungen pro IP-Adresse. |
LIMIT_CONN_MAX_HTTP2 |
100 |
multisite | nein | HTTP/2-Streams: Maximale Anzahl gleichzeitiger HTTP/2-Streams pro IP-Adresse. |
LIMIT_CONN_MAX_HTTP3 |
100 |
multisite | nein | HTTP/3-Streams: Maximale Anzahl gleichzeitiger HTTP/3-Streams pro IP-Adresse. |
LIMIT_CONN_MAX_STREAM |
10 |
multisite | nein | Stream-Verbindungen: Maximale Anzahl gleichzeitiger Stream-Verbindungen pro IP-Adresse. |
Verbindungs- vs. Anforderungsbegrenzung
- Verbindungsbegrenzung beschränkt die Anzahl der gleichzeitigen Verbindungen, die eine einzelne IP-Adresse aufrechterhalten kann.
- Anforderungsratenbegrenzung beschränkt die Anzahl der Anfragen, die eine IP-Adresse innerhalb eines definierten Zeitraums stellen kann.
Die Verwendung beider Methoden bietet einen umfassenden Schutz gegen verschiedene Arten von Missbrauch.
Festlegen angemessener Grenzwerte
Zu restriktive Grenzwerte können legitime Benutzer beeinträchtigen, insbesondere bei HTTP/2 und HTTP/3, wo Browser oft mehrere Streams verwenden. Die Standardwerte sind für die meisten Anwendungsfälle ausgewogen, aber erwägen Sie, sie je nach den Bedürfnissen Ihrer Anwendung und dem Benutzerverhalten anzupassen.
Beispielkonfigurationen
Eine einfache Konfiguration mit Standardeinstellungen zum Schutz Ihrer gesamten Website:
USE_LIMIT_REQ: "yes"
LIMIT_REQ_URL: "/"
LIMIT_REQ_RATE: "2r/s"
USE_LIMIT_CONN: "yes"
LIMIT_CONN_MAX_HTTP1: "10"
LIMIT_CONN_MAX_HTTP2: "100"
LIMIT_CONN_MAX_HTTP3: "100"
LIMIT_CONN_MAX_STREAM: "10"
Konfiguration mit unterschiedlichen Ratenbegrenzungen für verschiedene Endpunkte:
USE_LIMIT_REQ: "yes"
# Standardregel für alle Anfragen
LIMIT_REQ_URL: "/"
LIMIT_REQ_RATE: "10r/s"
# Strengere Begrenzung für die Anmeldeseite
LIMIT_REQ_URL_2: "^/login"
LIMIT_REQ_RATE_2: "1r/s"
# Strengere Begrenzung für die API
LIMIT_REQ_URL_3: "^/api/"
LIMIT_REQ_RATE_3: "5r/s"
USE_LIMIT_CONN: "yes"
LIMIT_CONN_MAX_HTTP1: "10"
LIMIT_CONN_MAX_HTTP2: "100"
LIMIT_CONN_MAX_HTTP3: "100"
LIMIT_CONN_MAX_STREAM: "10"
Konfiguration, die für Websites mit hohem Verkehrsaufkommen mit großzügigeren Grenzwerten optimiert ist:
USE_LIMIT_REQ: "yes"
# Allgemeine Begrenzung
LIMIT_REQ_URL: "/"
LIMIT_REQ_RATE: "30r/s"
# Schutz des Admin-Bereichs
LIMIT_REQ_URL_2: "^/admin/"
LIMIT_REQ_RATE_2: "5r/s"
USE_LIMIT_CONN: "yes"
LIMIT_CONN_MAX_HTTP1: "50"
LIMIT_CONN_MAX_HTTP2: "200"
LIMIT_CONN_MAX_HTTP3: "200"
LIMIT_CONN_MAX_STREAM: "30"
Konfiguration, die für einen API-Server mit Ratenbegrenzungen in Anfragen pro Minute optimiert ist:
USE_LIMIT_REQ: "yes"
# Öffentliche API-Endpunkte
LIMIT_REQ_URL: "^/api/public/"
LIMIT_REQ_RATE: "120r/m"
# Private API-Endpunkte
LIMIT_REQ_URL_2: "^/api/private/"
LIMIT_REQ_RATE_2: "300r/m"
# Authentifizierungsendpunkt
LIMIT_REQ_URL_3: "^/api/auth"
LIMIT_REQ_RATE_3: "10r/m"
USE_LIMIT_CONN: "yes"
LIMIT_CONN_MAX_HTTP1: "20"
LIMIT_CONN_MAX_HTTP2: "100"
LIMIT_CONN_MAX_HTTP3: "100"
LIMIT_CONN_MAX_STREAM: "20"
Load Balancer
(PRO)
STREAM-Unterstützung
Provides load balancing feature to group of upstreams with optional healthchecks.
Einstellung | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
LOADBALANCER_HEALTHCHECK_DICT_SIZE |
10m |
global | nein | Shared dict size (datastore for all healthchecks). |
LOADBALANCER_UPSTREAM_NAME |
global | ja | Name of the upstream (used in REVERSE_PROXY_HOST). | |
LOADBALANCER_UPSTREAM_SERVERS |
global | ja | List of servers/IPs in the server group. | |
LOADBALANCER_UPSTREAM_MODE |
round-robin |
global | ja | Load balancing mode (round-robin or sticky). |
LOADBALANCER_UPSTREAM_STICKY_METHOD |
ip |
global | ja | Sticky session method (ip or cookie). |
LOADBALANCER_UPSTREAM_RESOLVE |
no |
global | ja | Dynamically resolve upstream hostnames. |
LOADBALANCER_UPSTREAM_KEEPALIVE |
global | ja | Number of keepalive connections to cache per worker. | |
LOADBALANCER_UPSTREAM_KEEPALIVE_TIMEOUT |
60s |
global | ja | Keepalive timeout for upstream connections. |
LOADBALANCER_UPSTREAM_KEEPALIVE_TIME |
1h |
global | ja | Keepalive time for upstream connections. |
LOADBALANCER_HEALTHCHECK_URL |
/status |
global | ja | The healthcheck URL. |
LOADBALANCER_HEALTHCHECK_INTERVAL |
2000 |
global | ja | Healthcheck interval in milliseconds. |
LOADBALANCER_HEALTHCHECK_TIMEOUT |
1000 |
global | ja | Healthcheck timeout in milliseconds. |
LOADBALANCER_HEALTHCHECK_FALL |
3 |
global | ja | Number of failed healthchecks before marking the server as down. |
LOADBALANCER_HEALTHCHECK_RISE |
1 |
global | ja | Number of successful healthchecks before marking the server as up. |
LOADBALANCER_HEALTHCHECK_VALID_STATUSES |
200 |
global | ja | HTTP status considered valid in healthchecks. |
LOADBALANCER_HEALTHCHECK_CONCURRENCY |
10 |
global | ja | Maximum number of concurrent healthchecks. |
LOADBALANCER_HEALTHCHECK_TYPE |
http |
global | ja | Type of healthcheck (http or https). |
LOADBALANCER_HEALTHCHECK_SSL_VERIFY |
yes |
global | ja | Verify SSL certificate in healthchecks. |
LOADBALANCER_HEALTHCHECK_HOST |
global | ja | Host header for healthchecks (useful for HTTPS). |
Metrics
STREAM-Unterstützung
Das Metrics-Plugin bietet umfassende Überwachungs- und Datenerfassungsfunktionen für Ihre BunkerWeb-Instanz. Mit dieser Funktion können Sie verschiedene Leistungsindikatoren, Sicherheitsereignisse und Systemstatistiken verfolgen und erhalten so wertvolle Einblicke in das Verhalten und den Zustand Ihrer geschützten Websites und Dienste.
So funktioniert es:
- BunkerWeb erfasst während der Verarbeitung von Anfragen und Antworten wichtige Metriken.
- Zu diesen Metriken gehören Zähler für blockierte Anfragen, Leistungsmessungen und verschiedene sicherheitsrelevante Statistiken.
- Die Daten werden effizient im Speicher gespeichert, mit konfigurierbaren Grenzwerten, um eine übermäßige Ressourcennutzung zu verhindern.
- Für Multi-Instanz-Setups kann Redis zur Zentralisierung und Aggregation von Metrikdaten verwendet werden.
- Auf die erfassten Metriken kann über die API zugegriffen oder in der Web-Benutzeroberfläche visualisiert werden.
- Diese Informationen helfen Ihnen, Sicherheitsbedrohungen zu identifizieren, Probleme zu beheben und Ihre Konfiguration zu optimieren.
Technische Umsetzung
Das Metrics-Plugin funktioniert durch:
- Verwendung gemeinsamer Wörterbücher in NGINX, wobei
metrics_datastore
für HTTP undmetrics_datastore_stream
für TCP/UDP-Verkehr verwendet wird - Nutzung eines LRU-Cache für eine effiziente In-Memory-Speicherung
- Periodische Synchronisierung von Daten zwischen Workern mithilfe von Timern
- Speicherung detaillierter Informationen über blockierte Anfragen, einschließlich der Client-IP-Adresse, des Landes, des Zeitstempels, der Anfragedetails und des Blockierungsgrunds
- Unterstützung von Plugin-spezifischen Metriken über eine gemeinsame Schnittstelle zur Metrikerfassung
- Bereitstellung von API-Endpunkten zur Abfrage erfasster Metriken
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Metrics-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Die Metrikerfassung ist standardmäßig aktiviert. Sie können dies mit der Einstellung
USE_METRICS
steuern. - Speicherzuweisung konfigurieren: Legen Sie die Speichermenge fest, die für die Metrikspeicherung zugewiesen werden soll, indem Sie die Einstellung
METRICS_MEMORY_SIZE
verwenden. - Speichergrenzen festlegen: Definieren Sie, wie viele blockierte Anfragen pro Worker und in Redis mit den entsprechenden Einstellungen gespeichert werden sollen.
- Auf die Daten zugreifen: Sehen Sie sich die erfassten Metriken über die Web-Benutzeroberfläche oder API-Endpunkte an.
- Informationen analysieren: Verwenden Sie die gesammelten Daten, um Muster zu erkennen, Sicherheitsprobleme zu identifizieren und Ihre Konfiguration zu optimieren.
Erfasste Metriken
Das Metrics-Plugin erfasst die folgenden Informationen:
-
Blockierte Anfragen: Für jede blockierte Anfrage werden die folgenden Daten gespeichert:
- Anfrage-ID und Zeitstempel
- Client-IP-Adresse und Land (sofern verfügbar)
- HTTP-Methode und URL
- HTTP-Statuscode
- User-Agent
- Blockierungsgrund und Sicherheitsmodus
- Servername
- Zusätzliche Daten im Zusammenhang mit dem Blockierungsgrund
-
Plugin-Zähler: Verschiedene Plugin-spezifische Zähler, die Aktivitäten und Ereignisse verfolgen.
API-Zugriff
Auf Metrikdaten kann über die internen API-Endpunkte von BunkerWeb zugegriffen werden:
- Endpunkt:
/metrics/{filter}
- Methode: GET
- Beschreibung: Ruft Metrikdaten basierend auf dem angegebenen Filter ab
- Antwortformat: JSON-Objekt, das die angeforderten Metriken enthält
Zum Beispiel gibt /metrics/requests
Informationen über blockierte Anfragen zurück.
Konfiguration des API-Zugriffs
Um über die API auf Metriken zuzugreifen, müssen Sie sicherstellen, dass:
- Die API-Funktion mit
USE_API: "yes"
aktiviert ist (standardmäßig aktiviert) - Ihre Client-IP in der Einstellung
API_WHITELIST_IP
enthalten ist (Standard ist127.0.0.0/8
) - Sie auf die API über den konfigurierten Port zugreifen (Standard ist
5000
über die EinstellungAPI_HTTP_PORT
) - Sie den korrekten
API_SERVER_NAME
-Wert im Host-Header verwenden (Standard istbwapi
) - Wenn
API_TOKEN
konfiguriert ist, fügen SieAuthorization: Bearer <token>
in die Anfrage-Header ein.
Typische Anfragen:
Ohne Token (wenn API_TOKEN
nicht gesetzt ist):
curl -H "Host: bwapi" \
http://ihre-bunkerweb-instanz:5000/metrics/requests
Mit Token (wenn API_TOKEN
gesetzt ist):
curl -H "Host: bwapi" \
-H "Authorization: Bearer $API_TOKEN" \
http://ihre-bunkerweb-instanz:5000/metrics/requests
Wenn Sie den API_SERVER_NAME
auf einen anderen Wert als den Standard bwapi
angepasst haben, verwenden Sie diesen Wert stattdessen im Host-Header.
Für sichere Produktionsumgebungen beschränken Sie den API-Zugriff auf vertrauenswürdige IPs und aktivieren Sie API_TOKEN
.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_METRICS |
yes |
multisite | nein | Metriken aktivieren: Auf yes setzen, um die Erfassung und den Abruf von Metriken zu aktivieren. |
METRICS_MEMORY_SIZE |
16m |
global | nein | Speichergröße: Größe des internen Speichers für Metriken (z. B. 16m , 32m ). |
METRICS_MAX_BLOCKED_REQUESTS |
1000 |
global | nein | Max. blockierte Anfragen: Maximale Anzahl blockierter Anfragen, die pro Worker gespeichert werden sollen. |
METRICS_MAX_BLOCKED_REQUESTS_REDIS |
100000 |
global | nein | Max. Redis-blockierte Anfragen: Maximale Anzahl blockierter Anfragen, die in Redis gespeichert werden sollen. |
METRICS_SAVE_TO_REDIS |
yes |
global | nein | Metriken in Redis speichern: Auf yes setzen, um Metriken (Zähler und Tabellen) zur clusterweiten Aggregation in Redis zu speichern. |
Dimensionierung der Speicherzuweisung
Die Einstellung METRICS_MEMORY_SIZE
sollte basierend auf Ihrem Verkehrsaufkommen und der Anzahl der Instanzen angepasst werden. Bei stark frequentierten Websites sollten Sie diesen Wert erhöhen, um sicherzustellen, dass alle Metriken ohne Datenverlust erfasst werden.
Redis-Integration
Wenn BunkerWeb für die Verwendung von Redis konfiguriert ist, synchronisiert das Metrics-Plugin blockierte Anfragedaten automatisch mit dem Redis-Server. Dies bietet eine zentralisierte Ansicht von Sicherheitsereignissen über mehrere BunkerWeb-Instanzen hinweg.
Leistungsüberlegungen
Das Festlegen sehr hoher Werte für METRICS_MAX_BLOCKED_REQUESTS
oder METRICS_MAX_BLOCKED_REQUESTS_REDIS
kann den Speicherverbrauch erhöhen. Überwachen Sie Ihre Systemressourcen und passen Sie diese Werte entsprechend Ihren tatsächlichen Bedürfnissen und verfügbaren Ressourcen an.
Worker-spezifischer Speicher
Jeder NGINX-Worker verwaltet seine eigenen Metriken im Speicher. Beim Zugriff auf Metriken über die API werden die Daten aller Worker automatisch aggregiert, um eine vollständige Ansicht zu erhalten.
Beispielkonfigurationen
Standardkonfiguration, die für die meisten Bereitstellungen geeignet ist:
USE_METRICS: "yes"
METRICS_MEMORY_SIZE: "16m"
METRICS_MAX_BLOCKED_REQUESTS: "1000"
METRICS_MAX_BLOCKED_REQUESTS_REDIS: "100000"
METRICS_SAVE_TO_REDIS: "yes"
Konfiguration, die für Umgebungen mit begrenzten Ressourcen optimiert ist:
USE_METRICS: "yes"
METRICS_MEMORY_SIZE: "8m"
METRICS_MAX_BLOCKED_REQUESTS: "500"
METRICS_MAX_BLOCKED_REQUESTS_REDIS: "10000"
METRICS_SAVE_TO_REDIS: "no"
Konfiguration für Websites mit hohem Verkehrsaufkommen, die mehr Sicherheitsereignisse verfolgen müssen:
USE_METRICS: "yes"
METRICS_MEMORY_SIZE: "64m"
METRICS_MAX_BLOCKED_REQUESTS: "5000"
METRICS_MAX_BLOCKED_REQUESTS_REDIS: "500000"
METRICS_SAVE_TO_REDIS: "yes"
Konfiguration mit deaktivierter Metrikerfassung:
USE_METRICS: "no"
Migration
(PRO)
STREAM-Unterstützung
Migration of BunkerWeb configuration between instances made easy via the web UI
Miscellaneous
STREAM-Unterstützung
Das Plugin "Verschiedenes" (Miscellaneous) bietet wesentliche Grundeinstellungen, die helfen, die Sicherheit und Funktionalität Ihrer Website aufrechtzuerhalten. Diese Kernkomponente bietet umfassende Kontrollen für:
- Serververhalten - Konfigurieren Sie, wie Ihr Server auf verschiedene Anfragen reagiert
- HTTP-Einstellungen - Verwalten Sie Methoden, Anforderungsgrößen und Protokolloptionen
- Dateiverwaltung - Steuern Sie die Bereitstellung statischer Dateien und optimieren Sie deren Auslieferung
- Protokollunterstützung - Aktivieren Sie moderne HTTP-Protokolle für eine bessere Leistung
- Systemkonfigurationen - Erweitern Sie die Funktionalität und verbessern Sie die Sicherheit
Ob Sie HTTP-Methoden einschränken, Anforderungsgrößen verwalten, das Datei-Caching optimieren oder steuern müssen, wie Ihr Server auf verschiedene Anfragen reagiert, dieses Plugin gibt Ihnen die Werkzeuge, um das Verhalten Ihres Webdienstes feinabzustimmen und gleichzeitig Leistung und Sicherheit zu optimieren.
Hauptmerkmale
Funktionskategorie | Beschreibung |
---|---|
Steuerung der HTTP-Methoden | Definieren Sie, welche HTTP-Methoden für Ihre Anwendung zulässig sind |
Schutz des Standardservers | Verhindern Sie unbefugten Zugriff durch falsche Hostnamen und erzwingen Sie SNI für sichere Verbindungen |
Verwaltung der Anforderungsgröße | Legen Sie Grenzwerte für Client-Anforderungskörper und Datei-Uploads fest |
Bereitstellung statischer Dateien | Konfigurieren und optimieren Sie die Auslieferung von statischen Inhalten aus benutzerdefinierten Stammordnern |
Datei-Caching | Verbessern Sie die Leistung durch fortschrittliche Caching-Mechanismen für Dateideskriptoren |
Protokollunterstützung | Konfigurieren Sie moderne HTTP-Protokolloptionen (HTTP2/HTTP3) und Alt-Svc-Porteinstellungen |
Anonyme Berichterstattung | Optionale Nutzungsstatistik-Berichterstattung zur Verbesserung von BunkerWeb |
Unterstützung für externe Plugins | Erweitern Sie die Funktionalität durch die Integration externer Plugins über URLs |
Steuerung des HTTP-Status | Konfigurieren Sie, wie Ihr Server bei der Ablehnung von Anfragen reagiert (einschließlich Verbindungsabbruch) |
Konfigurationsanleitung
Steuerung des Standardservers
In HTTP gibt der Host
-Header den Zielserver an, aber er kann fehlen oder unbekannt sein, oft aufgrund von Bots, die nach Schwachstellen suchen.
Um solche Anfragen zu blockieren:
- Setzen Sie
DISABLE_DEFAULT_SERVER
aufyes
, um solche Anfragen stillschweigend mit dem NGINX-Statuscode444
abzulehnen. - Für eine strengere Sicherheit aktivieren Sie
DISABLE_DEFAULT_SERVER_STRICT_SNI
, um SSL/TLS-Verbindungen ohne gültiges SNI abzulehnen.
Sicherheitsvorteile
- Blockiert die Manipulation des Host-Headers und das Scannen von virtuellen Hosts
- Mindert die Risiken von HTTP-Request-Smuggling
- Entfernt den Standardserver als Angriffsvektor
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
DISABLE_DEFAULT_SERVER |
no |
global | nein | Standardserver: Auf yes setzen, um den Standardserver zu deaktivieren, wenn kein Hostname mit der Anfrage übereinstimmt. |
DISABLE_DEFAULT_SERVER_STRICT_SNI |
no |
global | nein | Striktes SNI: Wenn auf yes gesetzt, ist SNI für HTTPS-Verbindungen erforderlich und Verbindungen ohne gültiges SNI werden abgelehnt. |
SNI-Erzwingung
Die Aktivierung der strikten SNI-Validierung bietet eine stärkere Sicherheit, kann jedoch Probleme verursachen, wenn BunkerWeb hinter einem Reverse-Proxy betrieben wird, der HTTPS-Anfragen ohne Beibehaltung der SNI-Informationen weiterleitet. Testen Sie gründlich, bevor Sie dies in Produktionsumgebungen aktivieren.
Steuerung des HTTP-Status
Der erste Schritt bei der Behandlung von verweigertem Client-Zugriff ist die Definition der geeigneten Aktion. Dies kann mit der Einstellung DENY_HTTP_STATUS
konfiguriert werden. Wenn BunkerWeb eine Anfrage ablehnt, können Sie seine Antwort steuern. Standardmäßig gibt es einen 403 Forbidden
-Status zurück und zeigt dem Client eine Webseite oder benutzerdefinierten Inhalt an.
Alternativ schließt das Setzen auf 444
die Verbindung sofort, ohne eine Antwort zu senden. Dieser nicht standardmäßige Statuscode, der spezifisch für NGINX ist, ist nützlich, um unerwünschte Anfragen stillschweigend zu verwerfen.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
DENY_HTTP_STATUS |
403 |
global | nein | HTTP-Status bei Ablehnung: HTTP-Statuscode, der gesendet wird, wenn eine Anfrage abgelehnt wird (403 oder 444). Code 444 schließt die Verbindung. |
Überlegungen zum Statuscode 444
Da Clients kein Feedback erhalten, kann die Fehlerbehebung schwieriger sein. Das Setzen von 444
wird nur empfohlen, wenn Sie Falsch-Positive gründlich behandelt haben, mit BunkerWeb erfahren sind und ein höheres Sicherheitsniveau benötigen.
Stream-Modus
Im Stream-Modus wird diese Einstellung immer als 444
erzwungen, was bedeutet, dass die Verbindung geschlossen wird, unabhängig vom konfigurierten Wert.
Steuerung der HTTP-Methoden
Die Beschränkung der HTTP-Methoden auf nur diejenigen, die von Ihrer Anwendung benötigt werden, ist eine grundlegende Sicherheitsmaßnahme, die dem Prinzip der geringsten Rechte folgt. Indem Sie explizit zulässige HTTP-Methoden definieren, können Sie das Risiko der Ausnutzung durch ungenutzte oder gefährliche Methoden minimieren.
Diese Funktion wird mit der Einstellung ALLOWED_METHODS
konfiguriert, wobei die Methoden aufgelistet und durch ein |
getrennt sind (Standard: GET|POST|HEAD
). Wenn ein Client versucht, eine nicht aufgelistete Methode zu verwenden, antwortet der Server mit einem 405 - Method Not Allowed-Status.
Für die meisten Websites ist der Standardwert GET|POST|HEAD
ausreichend. Wenn Ihre Anwendung RESTful-APIs verwendet, müssen Sie möglicherweise Methoden wie PUT
und DELETE
hinzufügen.
Sicherheitsvorteile
- Verhindert die Ausnutzung von ungenutzten oder unnötigen HTTP-Methoden
- Reduziert die Angriffsfläche durch Deaktivierung potenziell schädlicher Methoden
- Blockiert von Angreifern verwendete Techniken zur Aufzählung von HTTP-Methoden
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
ALLOWED_METHODS |
GET | POST | HEAD |
multisite | nein | HTTP-Methoden: Liste der erlaubten HTTP-Methoden, getrennt durch Pipe-Zeichen (| ). |
CORS und Preflight-Anfragen
Wenn Ihre Anwendung Cross-Origin Resource Sharing (CORS) unterstützt, sollten Sie die OPTIONS
-Methode in der ALLOWED_METHODS
-Einstellung aufnehmen, um Preflight-Anfragen zu bearbeiten. Dies gewährleistet die ordnungsgemäße Funktionalität für Browser, die Cross-Origin-Anfragen stellen.
Sicherheitsüberlegungen
- Vermeiden Sie die Aktivierung von
TRACE
oderCONNECT
: Diese Methoden werden selten benötigt und können erhebliche Sicherheitsrisiken mit sich bringen, wie z. B. die Ermöglichung von Cross-Site-Tracing (XST) oder Tunneling-Angriffen. - Überprüfen Sie regelmäßig die erlaubten Methoden: Überprüfen Sie die
ALLOWED_METHODS
-Einstellung regelmäßig, um sicherzustellen, dass sie den aktuellen Anforderungen Ihrer Anwendung entspricht. - Testen Sie gründlich vor der Bereitstellung: Änderungen an den Einschränkungen von HTTP-Methoden können die Anwendungsfunktionalität beeinträchtigen. Validieren Sie Ihre Konfiguration in einer Staging-Umgebung, bevor Sie sie in der Produktion anwenden.
Größenbeschränkungen für Anfragen
Die maximale Größe des Anforderungskörpers kann mit der Einstellung MAX_CLIENT_SIZE
gesteuert werden (Standard: 10m
). Akzeptierte Werte folgen der hier beschriebenen Syntax.
Sicherheitsvorteile
- Schützt vor Denial-of-Service-Angriffen durch übermäßige Payload-Größen
- Mildert Pufferüberlauf-Schwachstellen
- Verhindert Angriffe durch Datei-Uploads
- Reduziert das Risiko der Erschöpfung von Serverressourcen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
MAX_CLIENT_SIZE |
10m |
multisite | nein | Maximale Anforderungsgröße: Die maximal zulässige Größe für Client-Anforderungskörper (z. B. Datei-Uploads). |
Best Practices für die Konfiguration der Anforderungsgröße
Wenn Sie einen Anforderungskörper von unbegrenzter Größe zulassen müssen, können Sie den Wert MAX_CLIENT_SIZE
auf 0
setzen. Dies wird jedoch aufgrund potenzieller Sicherheits- und Leistungsrisiken nicht empfohlen.
Best Practices:
- Konfigurieren Sie
MAX_CLIENT_SIZE
immer auf den kleinstmöglichen Wert, der die legitimen Anforderungen Ihrer Anwendung erfüllt. - Überprüfen und passen Sie diese Einstellung regelmäßig an die sich ändernden Bedürfnisse Ihrer Anwendung an.
- Vermeiden Sie es,
0
zu setzen, es sei denn, es ist absolut notwendig, da dies Ihren Server Denial-of-Service-Angriffen und Ressourcenerschöpfung aussetzen kann.
Durch sorgfältige Verwaltung dieser Einstellung können Sie optimale Sicherheit und Leistung für Ihre Anwendung gewährleisten.
HTTP-Protokolleinstellungen
Moderne HTTP-Protokolle wie HTTP/2 und HTTP/3 verbessern Leistung und Sicherheit. BunkerWeb ermöglicht eine einfache Konfiguration dieser Protokolle.
Sicherheits- und Leistungsvorteile
- Sicherheitsvorteile: Moderne Protokolle wie HTTP/2 und HTTP/3 erzwingen standardmäßig TLS/HTTPS, reduzieren die Anfälligkeit für bestimmte Angriffe und verbessern die Privatsphäre durch verschlüsselte Header (HTTP/3).
- Leistungsvorteile: Funktionen wie Multiplexing, Header-Komprimierung, Server-Push und binäre Datenübertragung verbessern Geschwindigkeit und Effizienz.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
LISTEN_HTTP |
yes |
multisite | nein | HTTP-Listen: Auf (unsichere) HTTP-Anfragen antworten, wenn auf yes gesetzt. |
HTTP2 |
yes |
multisite | nein | HTTP2: Unterstützt das HTTP2-Protokoll, wenn HTTPS aktiviert ist. |
HTTP3 |
yes |
multisite | nein | HTTP3: Unterstützt das HTTP3-Protokoll, wenn HTTPS aktiviert ist. |
HTTP3_ALT_SVC_PORT |
443 |
multisite | nein | HTTP3 Alt-Svc Port: Port, der im Alt-Svc-Header für HTTP3 verwendet wird. |
Über HTTP/3
HTTP/3, die neueste Version des Hypertext Transfer Protocol, verwendet QUIC über UDP anstelle von TCP und behebt Probleme wie das Head-of-Line-Blocking für schnellere, zuverlässigere Verbindungen.
NGINX hat ab Version 1.25.0 experimentelle Unterstützung für HTTP/3 und QUIC eingeführt. Diese Funktion ist jedoch noch experimentell, und bei der Verwendung in der Produktion ist Vorsicht geboten. Weitere Einzelheiten finden Sie in der offiziellen Dokumentation von NGINX.
Gründliche Tests werden empfohlen, bevor HTTP/3 in Produktionsumgebungen aktiviert wird.
Konfiguration der Dateibereitstellung
BunkerWeb kann statische Dateien direkt bereitstellen oder als Reverse-Proxy zu einem Anwendungsserver fungieren. Standardmäßig werden Dateien aus /var/www/html/{server_name}
bereitgestellt.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
SERVE_FILES |
yes |
multisite | nein | Dateien bereitstellen: Wenn auf yes gesetzt, stellt BunkerWeb statische Dateien aus dem konfigurierten Stammordner bereit. |
ROOT_FOLDER |
/var/www/html/{server_name} |
multisite | nein | Stammordner: Das Verzeichnis, aus dem statische Dateien bereitgestellt werden sollen. Leer bedeutet, den Standardort zu verwenden. |
Best Practices für die Bereitstellung statischer Dateien
- Direkte Bereitstellung: Aktivieren Sie die Dateibereitstellung (
SERVE_FILES=yes
), wenn BunkerWeb für die direkte Bereitstellung statischer Dateien verantwortlich ist. - Reverse-Proxy: Wenn BunkerWeb als Reverse-Proxy fungiert, deaktivieren Sie die Dateibereitstellung (
SERVE_FILES=no
), um die Angriffsfläche zu reduzieren und die Exposition unnötiger Verzeichnisse zu vermeiden. - Berechtigungen: Stellen Sie sicher, dass die Dateiberechtigungen und Pfadkonfigurationen korrekt sind, um unbefugten Zugriff zu verhindern.
- Sicherheit: Vermeiden Sie die Exposition sensibler Verzeichnisse oder Dateien durch Fehlkonfigurationen.
Durch sorgfältige Verwaltung der Bereitstellung statischer Dateien können Sie die Leistung optimieren und gleichzeitig eine sichere Umgebung aufrechterhalten.
Plugin- und Systemverwaltung
Diese Einstellungen verwalten die Interaktion von BunkerWeb mit externen Systemen und tragen durch optionale anonyme Nutzungsstatistiken zur Verbesserung des Produkts bei.
Anonyme Berichterstattung
Die anonyme Berichterstattung gibt dem BunkerWeb-Team Einblicke, wie die Software verwendet wird. Dies hilft, Verbesserungsbereiche zu identifizieren und die Entwicklung von Funktionen zu priorisieren. Die Berichte sind rein statistisch und enthalten keine sensiblen oder persönlich identifizierbaren Informationen. Sie umfassen:
- Aktivierte Funktionen
- Allgemeine Konfigurationsmuster
Sie können diese Funktion bei Bedarf deaktivieren, indem Sie SEND_ANONYMOUS_REPORT
auf no
setzen.
Externe Plugins
Externe Plugins ermöglichen es Ihnen, die Funktionalität von BunkerWeb durch die Integration von Drittanbieter-Modulen zu erweitern. Dies ermöglicht zusätzliche Anpassungen und fortgeschrittene Anwendungsfälle.
Sicherheit externer Plugins
Externe Plugins können Sicherheitsrisiken mit sich bringen, wenn sie nicht ordnungsgemäß überprüft werden. Befolgen Sie diese Best Practices, um potenzielle Bedrohungen zu minimieren:
- Verwenden Sie nur Plugins aus vertrauenswürdigen Quellen.
- Überprüfen Sie die Integrität der Plugins mithilfe von Prüfsummen, sofern verfügbar.
- Überprüfen und aktualisieren Sie Plugins regelmäßig, um Sicherheit und Kompatibilität zu gewährleisten.
Weitere Einzelheiten finden Sie in der Plugin-Dokumentation.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
SEND_ANONYMOUS_REPORT |
yes |
global | nein | Anonyme Berichte: Senden Sie anonyme Nutzungsberichte an die BunkerWeb-Maintainer. |
EXTERNAL_PLUGIN_URLS |
global | nein | Externe Plugins: URLs für externe Plugins zum Herunterladen (durch Leerzeichen getrennt). |
Optimierung des Datei-Cache
Der Cache für offene Dateien verbessert die Leistung, indem er Dateideskriptoren und Metadaten im Speicher speichert und so die Notwendigkeit wiederholter Dateisystemoperationen reduziert.
Vorteile des Datei-Caching
- Leistung: Reduziert Dateisystem-I/O, verringert die Latenz und senkt die CPU-Auslastung für Dateioperationen.
- Sicherheit: Mildert Timing-Angriffe durch Caching von Fehlerantworten und reduziert die Auswirkungen von DoS-Angriffen auf das Dateisystem.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_OPEN_FILE_CACHE |
no |
multisite | nein | Cache aktivieren: Aktivieren Sie das Caching von Dateideskriptoren und Metadaten, um die Leistung zu verbessern. |
OPEN_FILE_CACHE |
max=1000 inactive=20s |
multisite | nein | Cache-Konfiguration: Konfigurieren Sie den Cache für offene Dateien (z. B. maximale Einträge und Inaktivitäts-Timeout). |
OPEN_FILE_CACHE_ERRORS |
yes |
multisite | nein | Fehler zwischenspeichern: Speichert Fehler bei der Suche nach Dateideskriptoren sowie erfolgreiche Suchen zwischen. |
OPEN_FILE_CACHE_MIN_USES |
2 |
multisite | nein | Mindestverwendungen: Mindestanzahl von Zugriffen während des inaktiven Zeitraums, damit eine Datei im Cache verbleibt. |
OPEN_FILE_CACHE_VALID |
30s |
multisite | nein | Cache-Gültigkeit: Zeit, nach der zwischengespeicherte Elemente erneut validiert werden. |
Konfigurationsanleitung
So aktivieren und konfigurieren Sie das Datei-Caching:
1. Setzen Sie USE_OPEN_FILE_CACHE
auf yes
, um die Funktion zu aktivieren.
2. Passen Sie die OPEN_FILE_CACHE
-Parameter an, um die maximale Anzahl von Cache-Einträgen und deren Inaktivitäts-Timeout festzulegen.
3. Verwenden Sie OPEN_FILE_CACHE_ERRORS
, um sowohl erfolgreiche als auch fehlgeschlagene Suchen zwischenzuspeichern und so wiederholte Dateisystemoperationen zu reduzieren.
4. Legen Sie mit OPEN_FILE_CACHE_MIN_USES
die Mindestanzahl von Zugriffen fest, die erforderlich ist, damit eine Datei im Cache verbleibt.
5. Definieren Sie die Gültigkeitsdauer des Caches mit OPEN_FILE_CACHE_VALID
, um zu steuern, wie oft zwischengespeicherte Elemente erneut validiert werden.
Bewährte Praktiken
- Aktivieren Sie das Datei-Caching für Websites mit vielen statischen Dateien, um die Leistung zu verbessern.
- Überprüfen und optimieren Sie die Cache-Einstellungen regelmäßig, um Leistung und Ressourcenverbrauch auszugleichen.
- In dynamischen Umgebungen, in denen sich Dateien häufig ändern, sollten Sie die Gültigkeitsdauer des Caches verkürzen oder die Funktion deaktivieren, um die Aktualität der Inhalte zu gewährleisten.
Beispielkonfigurationen
Beispielkonfiguration zum Deaktivieren des Standardservers und Erzwingen von striktem SNI:
DISABLE_DEFAULT_SERVER: "yes"
DISABLE_DEFAULT_SERVER_STRICT_SNI: "yes"
Beispielkonfiguration zum stillschweigenden Verwerfen unerwünschter Anfragen:
DENY_HTTP_STATUS: "444"
Beispielkonfiguration zur Beschränkung der HTTP-Methoden auf die für eine RESTful-API erforderlichen:
ALLOWED_METHODS: "GET|POST|PUT|DELETE"
Beispielkonfiguration zur Begrenzung der maximalen Größe des Anforderungskörpers:
MAX_CLIENT_SIZE: "5m"
Beispielkonfiguration zur Aktivierung von HTTP/2 und HTTP/3 mit einem benutzerdefinierten Alt-Svc-Port:
HTTP2: "yes"
HTTP3: "yes"
HTTP3_ALT_SVC_PORT: "443"
Beispielkonfiguration zur Bereitstellung statischer Dateien aus einem benutzerdefinierten Stammordner:
SERVE_FILES: "yes"
ROOT_FOLDER: "/var/www/custom-folder"
Beispielkonfiguration zur Aktivierung und Optimierung des Datei-Caching:
USE_OPEN_FILE_CACHE: "yes"
OPEN_FILE_CACHE: "max=2000 inactive=30s"
OPEN_FILE_CACHE_ERRORS: "yes"
OPEN_FILE_CACHE_MIN_USES: "3"
OPEN_FILE_CACHE_VALID: "60s"
ModSecurity
STREAM-Unterstützung
Das ModSecurity-Plugin integriert die leistungsstarke ModSecurity Web Application Firewall (WAF) in BunkerWeb. Diese Integration bietet robusten Schutz gegen eine Vielzahl von Webangriffen, indem sie das OWASP Core Rule Set (CRS) nutzt, um Bedrohungen wie SQL-Injection, Cross-Site-Scripting (XSS), Local File Inclusion und mehr zu erkennen und zu blockieren.
So funktioniert es:
- Wenn eine Anfrage empfangen wird, bewertet ModSecurity sie anhand des aktiven Regelsatzes.
- Das OWASP Core Rule Set überprüft Header, Cookies, URL-Parameter und den Body-Inhalt.
- Jeder erkannte Verstoß trägt zu einem Gesamt-Anomalie-Score bei.
- Wenn dieser Score den konfigurierten Schwellenwert überschreitet, wird die Anfrage blockiert.
- Detaillierte Protokolle werden erstellt, um zu diagnostizieren, welche Regeln ausgelöst wurden und warum.
Wichtige Vorteile
- Branchenstandard-Schutz: Verwendet die weit verbreitete Open-Source-Firewall ModSecurity.
- OWASP Core Rule Set: Verwendet von der Community gepflegte Regeln, die die OWASP Top Ten und mehr abdecken.
- Konfigurierbare Sicherheitsstufen: Passen Sie die Paranoia-Stufen an, um die Sicherheit mit potenziellen Falsch-Positiven auszugleichen.
- Detaillierte Protokollierung: Bietet gründliche Audit-Protokolle zur Analyse von Angriffen.
- Plugin-Unterstützung: Erweitern Sie den Schutz mit optionalen CRS-Plugins, die auf Ihre Anwendungen zugeschnitten sind.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um ModSecurity zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: ModSecurity ist standardmäßig aktiviert. Dies kann mit der Einstellung
USE_MODSECURITY
gesteuert werden. - Wählen Sie eine CRS-Version: Wählen Sie eine Version des OWASP Core Rule Set (v3, v4 oder nightly).
- Plugins hinzufügen: Aktivieren Sie optional CRS-Plugins, um die Regelabdeckung zu verbessern.
- Überwachen und anpassen: Verwenden Sie Protokolle und die Web-Benutzeroberfläche, um Falsch-Positive zu identifizieren und die Einstellungen anzupassen.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_MODSECURITY |
yes |
multisite | nein | ModSecurity aktivieren: Schalten Sie den Schutz der ModSecurity Web Application Firewall ein. |
USE_MODSECURITY_CRS |
yes |
multisite | nein | Core Rule Set verwenden: Aktivieren Sie das OWASP Core Rule Set für ModSecurity. |
MODSECURITY_CRS_VERSION |
4 |
multisite | nein | CRS-Version: Die Version des zu verwendenden OWASP Core Rule Set. Optionen: 3 , 4 oder nightly . |
MODSECURITY_SEC_RULE_ENGINE |
On |
multisite | nein | Regel-Engine: Steuern Sie, ob Regeln erzwungen werden. Optionen: On , DetectionOnly oder Off . |
MODSECURITY_SEC_AUDIT_ENGINE |
RelevantOnly |
multisite | nein | Audit-Engine: Steuern Sie, wie die Audit-Protokollierung funktioniert. Optionen: On , Off oder RelevantOnly . |
MODSECURITY_SEC_AUDIT_LOG_PARTS |
ABIJDEFHZ |
multisite | nein | Audit-Protokoll-Teile: Welche Teile von Anfragen/Antworten in Audit-Protokolle aufgenommen werden sollen. |
MODSECURITY_REQ_BODY_NO_FILES_LIMIT |
131072 |
multisite | nein | Anforderungskörper-Limit (keine Dateien): Maximale Größe für Anforderungskörper ohne Datei-Uploads. Akzeptiert einfache Bytes oder menschenlesbare Suffixe (k , m , g ). |
USE_MODSECURITY_CRS_PLUGINS |
yes |
multisite | nein | CRS-Plugins aktivieren: Aktivieren Sie zusätzliche Plugin-Regelsätze für das Core Rule Set. |
MODSECURITY_CRS_PLUGINS |
multisite | nein | CRS-Plugin-Liste: Leerzeichengetrennte Liste von Plugins zum Herunterladen und Installieren (plugin-name[/tag] oder URL). |
|
USE_MODSECURITY_GLOBAL_CRS |
no |
global | nein | Globales CRS: Wenn aktiviert, werden CRS-Regeln global auf HTTP-Ebene anstatt pro Server angewendet. |
ModSecurity und das OWASP Core Rule Set
Wir empfehlen dringend, sowohl ModSecurity als auch das OWASP Core Rule Set (CRS) aktiviert zu lassen, um einen robusten Schutz gegen gängige Web-Schwachstellen zu bieten. Obwohl gelegentlich Falsch-Positive auftreten können, können diese mit etwas Aufwand durch Feinabstimmung von Regeln oder die Verwendung vordefinierter Ausschlüsse behoben werden.
Das CRS-Team pflegt aktiv eine Liste von Ausschlüssen für beliebte Anwendungen wie WordPress, Nextcloud, Drupal und Cpanel, was die Integration erleichtert, ohne die Funktionalität zu beeinträchtigen. Die Sicherheitsvorteile überwiegen bei weitem den minimalen Konfigurationsaufwand, der zur Behebung von Falsch-Positiven erforderlich ist.
Verfügbare CRS-Versionen
Wählen Sie eine CRS-Version, die Ihren Sicherheitsanforderungen am besten entspricht:
3
: Stabile v3.3.7.4
: Stabile v4.19.0 (Standard).nightly
: Nightly-Build mit den neuesten Regel-Updates.
Nightly-Build
Der Nightly-Build enthält die aktuellsten Regeln und bietet den neuesten Schutz gegen aufkommende Bedrohungen. Da er jedoch täglich aktualisiert wird und experimentelle oder ungetestete Änderungen enthalten kann, wird empfohlen, den Nightly-Build zunächst in einer Staging-Umgebung zu verwenden, bevor er in der Produktion eingesetzt wird.
Paranoia-Stufen
Das OWASP Core Rule Set verwendet "Paranoia-Stufen" (PL), um die Strenge der Regeln zu steuern:
- PL1 (Standard): Grundlegender Schutz mit minimalen Falsch-Positiven
- PL2: Strengere Sicherheit mit strengerem Musterabgleich
- PL3: Erhöhte Sicherheit mit strengerer Validierung
- PL4: Maximale Sicherheit mit sehr strengen Regeln (kann viele Falsch-Positive verursachen)
Sie können die Paranoia-Stufe festlegen, indem Sie eine benutzerdefinierte Konfigurationsdatei in /etc/bunkerweb/configs/modsec-crs/
hinzufügen.
Benutzerdefinierte Konfigurationen
Die Feinabstimmung von ModSecurity und dem OWASP Core Rule Set (CRS) kann durch benutzerdefinierte Konfigurationen erreicht werden. Diese Konfigurationen ermöglichen es Ihnen, das Verhalten in bestimmten Phasen der Verarbeitung von Sicherheitsregeln anzupassen:
modsec-crs
: Wird vor dem Laden des OWASP Core Rule Set angewendet.modsec
: Wird nach dem Laden des OWASP Core Rule Set angewendet. Dies wird auch verwendet, wenn das CRS überhaupt nicht geladen wird.crs-plugins-before
: Wird vor dem Laden der CRS-Plugins angewendet.crs-plugins-after
: Wird nach dem Laden der CRS-Plugins angewendet.
Diese Struktur bietet Flexibilität und ermöglicht es Ihnen, die Einstellungen von ModSecurity und CRS an die spezifischen Anforderungen Ihrer Anwendung anzupassen, während ein klarer Konfigurationsfluss beibehalten wird.
Hinzufügen von CRS-Ausschlüssen mit modsec-crs
Sie können eine benutzerdefinierte Konfiguration vom Typ modsec-crs
verwenden, um Ausschlüsse für bestimmte Anwendungsfälle hinzuzufügen, z. B. das Aktivieren vordefinierter Ausschlüsse für WordPress:
SecAction \
"id:900130,\
phase:1,\
nolog,\
pass,\
t:none,\
setvar:tx.crs_exclusions_wordpress=1"
In diesem Beispiel:
- Die Aktion wird in Phase 1 (früh im Anfrage-Lebenszyklus) ausgeführt.
- Sie aktiviert WordPress-spezifische CRS-Ausschlüsse, indem sie die Variable
tx.crs_exclusions_wordpress
setzt.
Aktualisieren von CRS-Regeln mit modsec
Um die geladenen CRS-Regeln zu optimieren, können Sie eine benutzerdefinierte Konfiguration vom Typ modsec
verwenden. Sie können beispielsweise bestimmte Regeln oder Tags für bestimmte Anfragepfade entfernen:
SecRule REQUEST_FILENAME "/wp-admin/admin-ajax.php" "id:1,ctl:ruleRemoveByTag=attack-xss,ctl:ruleRemoveByTag=attack-rce"
SecRule REQUEST_FILENAME "/wp-admin/options.php" "id:2,ctl:ruleRemoveByTag=attack-xss"
SecRule REQUEST_FILENAME "^/wp-json/yoast" "id:3,ctl:ruleRemoveById=930120"
In diesem Beispiel:
- Regel 1: Entfernt Regeln mit den Tags
attack-xss
undattack-rce
für Anfragen an/wp-admin/admin-ajax.php
. - Regel 2: Entfernt Regeln mit dem Tag
attack-xss
für Anfragen an/wp-admin/options.php
. - Regel 3: Entfernt eine bestimmte Regel (ID
930120
) für Anfragen, die auf/wp-json/yoast
passen.
Reihenfolge der Ausführung
Die Ausführungsreihenfolge für ModSecurity in BunkerWeb ist wie folgt, um eine klare und logische Abfolge der Regelanwendung zu gewährleisten:
- OWASP CRS-Konfiguration: Basiskonfiguration für das OWASP Core Rule Set.
- Konfiguration benutzerdefinierter Plugins (
crs-plugins-before
): Einstellungen, die für Plugins spezifisch sind und vor allen CRS-Regeln angewendet werden. - Regeln benutzerdefinierter Plugins (vor CRS-Regeln) (
crs-plugins-before
): Benutzerdefinierte Regeln für Plugins, die vor den CRS-Regeln ausgeführt werden. - Konfiguration heruntergeladener Plugins: Konfiguration für extern heruntergeladene Plugins.
- Regeln heruntergeladener Plugins (vor CRS-Regeln): Regeln für heruntergeladene Plugins, die vor den CRS-Regeln ausgeführt werden.
- Benutzerdefinierte CRS-Regeln (
modsec-crs
): Benutzerdefinierte Regeln, die vor dem Laden der CRS-Regeln angewendet werden. - OWASP CRS-Regeln: Der Kernsatz von Sicherheitsregeln, der von OWASP bereitgestellt wird.
- Regeln benutzerdefinierter Plugins (nach CRS-Regeln) (
crs-plugins-after
): Benutzerdefinierte Plugin-Regeln, die nach den CRS-Regeln ausgeführt werden. - Regeln heruntergeladener Plugins (nach CRS-Regeln): Regeln für heruntergeladene Plugins, die nach den CRS-Regeln ausgeführt werden.
- Benutzerdefinierte Regeln (
modsec
): Benutzerdefinierte Regeln, die nach allen CRS- und Plugin-Regeln angewendet werden.
Wichtige Hinweise:
- Pre-CRS-Anpassungen (
crs-plugins-before
,modsec-crs
) ermöglichen es Ihnen, Ausnahmen oder vorbereitende Regeln zu definieren, bevor die Kern-CRS-Regeln geladen werden. - Post-CRS-Anpassungen (
crs-plugins-after
,modsec
) sind ideal, um Regeln zu überschreiben oder zu erweitern, nachdem CRS- und Plugin-Regeln angewendet wurden. - Diese Struktur bietet maximale Flexibilität und ermöglicht eine präzise Steuerung der Regelausführung und -anpassung bei gleichzeitiger Aufrechterhaltung einer starken Sicherheitsgrundlage.
OWASP CRS-Plugins
Das OWASP Core Rule Set unterstützt auch eine Reihe von Plugins, die entwickelt wurden, um seine Funktionalität zu erweitern und die Kompatibilität mit bestimmten Anwendungen oder Umgebungen zu verbessern. Diese Plugins können dabei helfen, das CRS für die Verwendung mit beliebten Plattformen wie WordPress, Nextcloud und Drupal oder sogar benutzerdefinierten Setups zu optimieren. Weitere Informationen und eine Liste der verfügbaren Plugins finden Sie im OWASP CRS Plugin-Verzeichnis.
Plugin-Download
Die Einstellung MODSECURITY_CRS_PLUGINS
ermöglicht es Ihnen, Plugins herunterzuladen und zu installieren, um die Funktionalität des OWASP Core Rule Set (CRS) zu erweitern. Diese Einstellung akzeptiert eine Liste von Plugin-Namen mit optionalen Tags oder URLs, was es einfach macht, zusätzliche Sicherheitsfunktionen zu integrieren, die auf Ihre spezifischen Bedürfnisse zugeschnitten sind.
Hier ist eine nicht erschöpfende Liste der akzeptierten Werte für die Einstellung MODSECURITY_CRS_PLUGINS
:
fake-bot
- Lädt die neueste Version des Plugins herunter.wordpress-rule-exclusions/v1.0.0
- Lädt die Version 1.0.0 des Plugins herunter.https://github.com/coreruleset/dos-protection-plugin-modsecurity/archive/refs/heads/main.zip
- Lädt das Plugin direkt von der URL herunter.
Falsch-Positive
Höhere Sicherheitseinstellungen können legitimen Verkehr blockieren. Beginnen Sie mit den Standardeinstellungen und überwachen Sie die Protokolle, bevor Sie die Sicherheitsstufen erhöhen. Seien Sie bereit, Ausnahmeregeln für die spezifischen Anforderungen Ihrer Anwendung hinzuzufügen.
Beispielkonfigurationen
Eine Standardkonfiguration mit aktiviertem ModSecurity und CRS v4:
USE_MODSECURITY: "yes"
USE_MODSECURITY_CRS: "yes"
MODSECURITY_CRS_VERSION: "4"
MODSECURITY_SEC_RULE_ENGINE: "On"
Konfiguration zur Überwachung potenzieller Bedrohungen ohne Blockierung:
USE_MODSECURITY: "yes"
USE_MODSECURITY_CRS: "yes"
MODSECURITY_CRS_VERSION: "4"
MODSECURITY_SEC_RULE_ENGINE: "DetectionOnly"
MODSECURITY_SEC_AUDIT_ENGINE: "On"
MODSECURITY_SEC_AUDIT_LOG_PARTS: "ABIJDEFHZ"
Konfiguration mit CRS v4 und aktivierten Plugins für zusätzlichen Schutz:
USE_MODSECURITY: "yes"
USE_MODSECURITY_CRS: "yes"
MODSECURITY_CRS_VERSION: "4"
MODSECURITY_SEC_RULE_ENGINE: "On"
USE_MODSECURITY_CRS_PLUGINS: "yes"
MODSECURITY_CRS_PLUGINS: "wordpress-rule-exclusions fake-bot"
MODSECURITY_REQ_BODY_NO_FILES_LIMIT: "262144"
Konfiguration mit CRS v3 zur Kompatibilität mit älteren Setups:
USE_MODSECURITY: "yes"
USE_MODSECURITY_CRS: "yes"
MODSECURITY_CRS_VERSION: "3"
MODSECURITY_SEC_RULE_ENGINE: "On"
Konfiguration, die ModSecurity global auf alle HTTP-Verbindungen anwendet:
USE_MODSECURITY: "yes"
USE_MODSECURITY_CRS: "yes"
MODSECURITY_CRS_VERSION: "4"
USE_MODSECURITY_GLOBAL_CRS: "yes"
Konfiguration mit dem Nightly-Build von CRS mit benutzerdefinierten Plugins:
USE_MODSECURITY: "yes"
USE_MODSECURITY_CRS: "yes"
MODSECURITY_CRS_VERSION: "nightly"
USE_MODSECURITY_CRS_PLUGINS: "yes"
MODSECURITY_CRS_PLUGINS: "wordpress-rule-exclusions/v1.0.0 https://github.com/coreruleset/dos-protection-plugin-modsecurity/archive/refs/heads/main.zip"
Menschenlesbare Größenwerte
Für Größeneinstellungen wie MODSECURITY_REQ_BODY_NO_FILES_LIMIT
werden die Suffixe k
, m
und g
(Groß- und Kleinschreibung wird nicht beachtet) unterstützt und stehen für Kibibyte, Mebibyte und Gibibyte (Vielfache von 1024). Beispiele: 256k
= 262144, 1m
= 1048576, 2g
= 2147483648.
Monitoring
(PRO)
STREAM-Unterstützung
BunkerWeb monitoring pro system. This plugin is a prerequisite for some other plugins.
Einstellung | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_MONITORING |
yes |
global | nein | Enable monitoring of BunkerWeb. |
MONITORING_METRICS_DICT_SIZE |
10M |
global | nein | Size of the dict to store monitoring metrics. |
MONITORING_IGNORE_URLS |
global | nein | List of URLs to ignore when monitoring separated with spaces (e.g. /health) |
PHP
STREAM-Unterstützung
Das PHP-Plugin bietet eine nahtlose Integration mit PHP-FPM für BunkerWeb und ermöglicht die dynamische PHP-Verarbeitung für Ihre Websites. Diese Funktion unterstützt sowohl lokale PHP-FPM-Instanzen, die auf derselben Maschine laufen, als auch entfernte PHP-FPM-Server, was Ihnen Flexibilität bei der Konfiguration Ihrer PHP-Umgebung gibt.
So funktioniert es:
- Wenn ein Client eine PHP-Datei von Ihrer Website anfordert, leitet BunkerWeb die Anfrage an die konfigurierte PHP-FPM-Instanz weiter.
- Bei lokalem PHP-FPM kommuniziert BunkerWeb mit dem PHP-Interpreter über eine Unix-Socket-Datei.
- Bei entferntem PHP-FPM leitet BunkerWeb Anfragen an den angegebenen Host und Port über das FastCGI-Protokoll weiter.
- PHP-FPM verarbeitet das Skript und gibt den generierten Inhalt an BunkerWeb zurück, das ihn dann an den Client ausliefert.
- Die URL-Umschreibung wird automatisch konfiguriert, um gängige PHP-Frameworks und Anwendungen zu unterstützen, die "schöne URLs" verwenden.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die PHP-Funktion zu konfigurieren und zu verwenden:
- Wählen Sie Ihr PHP-FPM-Setup: Entscheiden Sie, ob Sie eine lokale oder eine entfernte PHP-FPM-Instanz verwenden möchten.
- Konfigurieren Sie die Verbindung: Geben Sie für lokales PHP den Socket-Pfad an; für entferntes PHP geben Sie den Hostnamen und den Port an.
- Legen Sie das Dokumentenstammverzeichnis fest: Konfigurieren Sie den Stammordner, der Ihre PHP-Dateien enthält, mit der entsprechenden Pfadeinstellung.
- Lassen Sie BunkerWeb den Rest erledigen: Nach der Konfiguration leitet BunkerWeb PHP-Anfragen automatisch an Ihre PHP-FPM-Instanz weiter.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
REMOTE_PHP |
multisite | nein | Entfernter PHP-Host: Hostname der entfernten PHP-FPM-Instanz. Leer lassen, um lokales PHP zu verwenden. | |
REMOTE_PHP_PATH |
multisite | nein | Entfernter Pfad: Stammordner mit Dateien in der entfernten PHP-FPM-Instanz. | |
REMOTE_PHP_PORT |
9000 |
multisite | nein | Entfernter Port: Port der entfernten PHP-FPM-Instanz. |
LOCAL_PHP |
multisite | nein | Lokaler PHP-Socket: Pfad zur PHP-FPM-Socket-Datei. Leer lassen, um eine entfernte PHP-FPM-Instanz zu verwenden. | |
LOCAL_PHP_PATH |
multisite | nein | Lokaler Pfad: Stammordner mit Dateien in der lokalen PHP-FPM-Instanz. |
Lokales vs. entferntes PHP-FPM
Wählen Sie das Setup, das am besten zu Ihrer Infrastruktur passt:
- Lokales PHP-FPM bietet aufgrund der Socket-basierten Kommunikation eine bessere Leistung und ist ideal, wenn PHP auf derselben Maschine wie BunkerWeb läuft.
- Entferntes PHP-FPM bietet mehr Flexibilität und Skalierbarkeit, indem die PHP-Verarbeitung auf separaten Servern erfolgen kann.
Pfadkonfiguration
Der REMOTE_PHP_PATH
oder LOCAL_PHP_PATH
muss mit dem tatsächlichen Dateisystempfad übereinstimmen, in dem Ihre PHP-Dateien gespeichert sind; andernfalls tritt ein "Datei nicht gefunden"-Fehler auf.
URL-Umschreibung
Das PHP-Plugin konfiguriert automatisch die URL-Umschreibung, um moderne PHP-Anwendungen zu unterstützen. Anfragen für nicht existierende Dateien werden an index.php
weitergeleitet, wobei die ursprüngliche Anfrage-URI als Abfrageparameter verfügbar ist.
Beispielkonfigurationen
Konfiguration für die Verwendung einer lokalen PHP-FPM-Instanz:
LOCAL_PHP: "/var/run/php/php8.1-fpm.sock"
LOCAL_PHP_PATH: "/var/www/html"
Konfiguration für die Verwendung einer entfernten PHP-FPM-Instanz:
REMOTE_PHP: "php-server.example.com"
REMOTE_PHP_PORT: "9000"
REMOTE_PHP_PATH: "/var/www/html"
Konfiguration für die Verwendung von PHP-FPM auf einem nicht standardmäßigen Port:
REMOTE_PHP: "php-server.example.com"
REMOTE_PHP_PORT: "9001"
REMOTE_PHP_PATH: "/var/www/html"
Für WordPress optimierte Konfiguration:
LOCAL_PHP: "/var/run/php/php8.1-fpm.sock"
LOCAL_PHP_PATH: "/var/www/html/wordpress"
Pro
STREAM-Unterstützung
Das Pro-Plugin bündelt erweiterte Funktionen und Verbesserungen für Unternehmensbereitstellungen von BunkerWeb. Es schaltet zusätzliche Funktionen, Premium-Plugins und erweiterte Funktionalität frei, die die Kernplattform von BunkerWeb ergänzen. Es bietet verbesserte Sicherheit, Leistung und Verwaltungsoptionen für unternehmenstaugliche Bereitstellungen.
So funktioniert es:
- Mit einem gültigen Pro-Lizenzschlüssel verbindet sich BunkerWeb mit dem Pro-API-Server, um Ihr Abonnement zu validieren.
- Nach der Authentifizierung lädt das Plugin automatisch Pro-exklusive Plugins und Erweiterungen herunter und installiert sie.
- Ihr Pro-Status wird regelmäßig überprüft, um den fortgesetzten Zugriff auf Premium-Funktionen sicherzustellen.
- Premium-Plugins werden nahtlos in Ihre bestehende BunkerWeb-Konfiguration integriert.
- Alle Pro-Funktionen arbeiten harmonisch mit dem Open-Source-Kern zusammen und erweitern die Funktionalität, anstatt sie zu ersetzen.
Wichtige Vorteile
- Premium-Erweiterungen: Zugriff auf exklusive Plugins und Funktionen, die in der Community-Edition nicht verfügbar sind.
- Verbesserte Leistung: Optimierte Konfigurationen und fortschrittliche Caching-Mechanismen.
- Unternehmens-Support: Vorrangige Unterstützung und dedizierte Support-Kanäle.
- Nahtlose Integration: Pro-Funktionen arbeiten ohne Konfigurationskonflikte neben den Community-Funktionen.
- Automatische Updates: Premium-Plugins werden automatisch heruntergeladen und auf dem neuesten Stand gehalten.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Pro-Funktionen zu konfigurieren und zu verwenden:
- Lizenzschlüssel erhalten: Kaufen Sie eine Pro-Lizenz im BunkerWeb Panel.
- Lizenzschlüssel konfigurieren: Verwenden Sie die Einstellung
PRO_LICENSE_KEY
, um Ihre Lizenz zu konfigurieren. - Lassen Sie BunkerWeb den Rest erledigen: Nach der Konfiguration mit einer gültigen Lizenz werden Pro-Plugins automatisch heruntergeladen und aktiviert.
- Überwachen Sie Ihren Pro-Status: Überprüfen Sie die Zustandsindikatoren in der Web-Benutzeroberfläche, um Ihren Pro-Abonnementstatus zu bestätigen.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
PRO_LICENSE_KEY |
global | nein | Pro-Lizenzschlüssel: Ihr BunkerWeb Pro-Lizenzschlüssel zur Authentifizierung. |
Lizenzverwaltung
Ihre Pro-Lizenz ist an Ihre spezifische Bereitstellungsumgebung gebunden. Wenn Sie Ihre Lizenz übertragen müssen oder Fragen zu Ihrem Abonnement haben, wenden Sie sich bitte über das BunkerWeb Panel an den Support.
Pro-Funktionen
Die spezifischen verfügbaren Pro-Funktionen können sich im Laufe der Zeit weiterentwickeln, wenn neue Funktionen hinzugefügt werden. Das Pro-Plugin übernimmt automatisch die Installation und Konfiguration aller verfügbaren Funktionen.
Netzwerkanforderungen
Das Pro-Plugin benötigt ausgehenden Internetzugang, um sich zur Lizenzüberprüfung mit der BunkerWeb-API zu verbinden und Premium-Plugins herunterzuladen. Stellen Sie sicher, dass Ihre Firewall Verbindungen zu api.bunkerweb.io
auf Port 443 (HTTPS) zulässt.
Häufig gestellte Fragen
F: Was passiert, wenn meine Pro-Lizenz abläuft?
A: Wenn Ihre Pro-Lizenz abläuft, wird der Zugriff auf Premium-Funktionen und -Plugins deaktiviert. Ihre BunkerWeb-Installation wird jedoch weiterhin mit allen Funktionen der Community-Edition betrieben. Um wieder Zugriff auf die Pro-Funktionen zu erhalten, erneuern Sie einfach Ihre Lizenz.
F: Werden die Pro-Funktionen meine bestehende Konfiguration stören?
A: Nein, die Pro-Funktionen sind so konzipiert, dass sie sich nahtlos in Ihr aktuelles BunkerWeb-Setup integrieren. Sie erweitern die Funktionalität, ohne Ihre bestehende Konfiguration zu verändern oder zu stören, und gewährleisten so ein reibungsloses und zuverlässiges Erlebnis.
F: Kann ich die Pro-Funktionen vor dem Kauf ausprobieren?
A: Auf jeden Fall! BunkerWeb bietet zwei Pro-Pläne, die Ihren Bedürfnissen entsprechen:
- BunkerWeb PRO Standard: Voller Zugriff auf die Pro-Funktionen ohne technischen Support.
- BunkerWeb PRO Enterprise: Voller Zugriff auf die Pro-Funktionen mit dediziertem technischen Support.
Sie können die Pro-Funktionen mit einer kostenlosen 1-monatigen Testversion erkunden, indem Sie den Promo-Code freetrial
verwenden. Besuchen Sie das BunkerWeb Panel, um Ihre Testversion zu aktivieren und mehr über flexible Preisoptionen basierend auf der Anzahl der von BunkerWeb PRO geschützten Dienste zu erfahren.
Prometheus exporter
(PRO)
STREAM-Unterstützung
Prometheus exporter for BunkerWeb internal metrics.
Einstellung | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_PROMETHEUS_EXPORTER |
no |
global | nein | Enable the Prometheus export. |
PROMETHEUS_EXPORTER_IP |
0.0.0.0 |
global | nein | Listening IP of the Prometheus exporter. |
PROMETHEUS_EXPORTER_PORT |
9113 |
global | nein | Listening port of the Prometheus exporter. |
PROMETHEUS_EXPORTER_URL |
/metrics |
global | nein | HTTP URL of the Prometheus exporter. |
PROMETHEUS_EXPORTER_ALLOW_IP |
127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 |
global | nein | List of IP/networks allowed to contact the Prometheus exporter endpoint. |
Real IP
STREAM-Unterstützung
Das Real IP Plugin stellt sicher, dass BunkerWeb die IP-Adresse des Clients auch hinter Proxys korrekt identifiziert. Dies ist unerlässlich für die Anwendung von Sicherheitsregeln, Ratenbegrenzung and zuverlässige Protokolle; andernfalls würden alle Anfragen von der IP des Proxys zu kommen scheinen.
So funktioniert's:
- Nach der Aktivierung prüft BunkerWeb die Header (z.B.
X-Forwarded-For
), die die ursprüngliche IP enthalten. - Es wird überprüft, ob die Quell-IP in
REAL_IP_FROM
(Liste vertrauenswürdiger Proxys) enthalten ist, um nur legitime Proxys zu akzeptieren. - Die Client-IP wird aus dem Header
REAL_IP_HEADER
extrahiert and für die Sicherheitsbewertung and Protokollierung verwendet. - Bei IP-Ketten kann eine rekursive Suche über
REAL_IP_RECURSIVE
die ursprüngliche IP ermitteln. - Die Unterstützung für das PROXY-Protokoll kann aktiviert werden, um die Client-IP direkt von kompatiblen Proxys (z.B. HAProxy) zu empfangen.
- Listen mit vertrauenswürdigen Proxy-IPs können automatisch über URLs heruntergeladen werden.
Verwendung
- Aktivieren:
USE_REAL_IP: yes
. - Vertrauenswürdige Proxys: Geben Sie IP/Bereiche in
REAL_IP_FROM
ein. - Header: Geben Sie an, welcher Header die echte IP über
REAL_IP_HEADER
enthält. - Rekursiv: Aktivieren Sie
REAL_IP_RECURSIVE
bei Bedarf. - URL-Quellen: Verwenden Sie
REAL_IP_FROM_URLS
, um Listen herunterzuladen. - PROXY-Protokoll: Aktivieren Sie
USE_PROXY_PROTOCOL
, wenn das Upstream-System es unterstützt.
Warnung PROXY-Protokoll
Das Aktivieren von USE_PROXY_PROTOCOL
ohne ein korrekt konfiguriertes Upstream-System, das es aussendet, führt dazu, dass Ihre Anwendung nicht funktioniert. Stellen Sie sicher, dass Sie es vor der Aktivierung konfiguriert haben.
Parameter
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_REAL_IP |
no |
multisite | nein | Aktiviert die Abfrage der echten IP aus Headern oder dem PROXY-Protokoll. |
REAL_IP_FROM |
192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 |
multisite | nein | Vertrauenswürdige Proxys: Liste von IP/Netzwerken, durch Leerzeichen getrennt. |
REAL_IP_HEADER |
X-Forwarded-For |
multisite | nein | Header, der die echte IP enthält, oder der spezielle Wert proxy_protocol . |
REAL_IP_RECURSIVE |
yes |
multisite | nein | Rekursive Suche in einem Header, der mehrere IPs enthält. |
REAL_IP_FROM_URLS |
multisite | nein | URLs, die IPs/Netzwerke von vertrauenswürdigen Proxys bereitstellen (unterstützt file:// ). |
|
USE_PROXY_PROTOCOL |
no |
global | nein | Aktiviert die PROXY-Protokoll-Unterstützung für die direkte Proxy→BunkerWeb-Kommunikation. |
Cloud-Anbieter
Fügen Sie die IPs Ihrer Load Balancer (AWS/GCP/Azure…) zu REAL_IP_FROM
hinzu, um eine korrekte Identifizierung zu gewährleisten.
Sicherheitsaspekte
Fügen Sie nur vertrauenswürdige Quellen hinzu, da sonst die Gefahr der IP-Spoofing über manipulierte Header besteht.
Mehrere Adressen
Mit REAL_IP_RECURSIVE
wird, wenn der Header mehrere IPs enthält, die erste IP, die nicht als vertrauenswürdiger Proxy aufgeführt ist, als Client-IP verwendet.
Beispiele
USE_REAL_IP: "yes"
REAL_IP_FROM: "192.168.1.0/24 10.0.0.5"
REAL_IP_HEADER: "X-Forwarded-For"
Redirect
STREAM-Unterstützung
Das Redirect-Plugin bietet einfache und effiziente HTTP-Umleitungsfunktionen für Ihre von BunkerWeb geschützten Websites. Mit dieser Funktion können Sie Besucher problemlos von einer URL zu einer anderen umleiten und dabei sowohl Umleitungen für die gesamte Domain als auch für bestimmte Pfade mit Beibehaltung des Pfades unterstützen.
So funktioniert es:
- Wenn ein Besucher auf Ihre Website zugreift, überprüft BunkerWeb, ob eine Umleitung konfiguriert ist.
- Wenn aktiviert, leitet BunkerWeb den Besucher an die angegebene Ziel-URL weiter.
- Sie können konfigurieren, ob der ursprüngliche Anfragepfad beibehalten (automatisch an die Ziel-URL angehängt) oder direkt zur exakten Ziel-URL umgeleitet werden soll.
- Der für die Umleitung verwendete HTTP-Statuscode kann zwischen permanenten (301) und temporären (302) Umleitungen angepasst werden.
- Diese Funktionalität ist ideal für Domain-Migrationen, die Einrichtung kanonischer Domains oder die Umleitung veralteter URLs.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Umleitungsfunktion zu konfigurieren und zu verwenden:
- Quellpfad festlegen: Konfigurieren Sie den Pfad, von dem umgeleitet werden soll, mit der Einstellung
REDIRECT_FROM
(z. B./
,/old-page
). - Ziel-URL festlegen: Konfigurieren Sie die Ziel-URL, zu der Besucher umgeleitet werden sollen, mit der Einstellung
REDIRECT_TO
. - Umleitungstyp wählen: Entscheiden Sie mit der Einstellung
REDIRECT_TO_REQUEST_URI
, ob der ursprüngliche Anfragepfad beibehalten werden soll. - Statuscode auswählen: Legen Sie den entsprechenden HTTP-Statuscode mit der Einstellung
REDIRECT_TO_STATUS_CODE
fest, um eine permanente oder temporäre Umleitung anzuzeigen. - Lassen Sie BunkerWeb den Rest erledigen: Nach der Konfiguration werden alle Anfragen an die Website automatisch basierend auf Ihren Einstellungen umgeleitet.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
REDIRECT_FROM |
/ |
multisite | ja | Pfad, von dem umgeleitet wird: Der Pfad, der umgeleitet wird. |
REDIRECT_TO |
multisite | ja | Ziel-URL: Die Ziel-URL, zu der Besucher umgeleitet werden. Leer lassen, um die Umleitung zu deaktivieren. | |
REDIRECT_TO_REQUEST_URI |
no |
multisite | ja | Pfad beibehalten: Wenn auf yes gesetzt, wird die ursprüngliche Anfrage-URI an die Ziel-URL angehängt. |
REDIRECT_TO_STATUS_CODE |
301 |
multisite | ja | HTTP-Statuscode: Der für die Umleitung zu verwendende HTTP-Statuscode. Optionen: 301 (permanent) oder 302 (temporär). |
Wahl des richtigen Statuscodes
- Verwenden Sie
301
(Moved Permanently), wenn die Umleitung dauerhaft ist, z. B. bei Domain-Migrationen oder zur Einrichtung kanonischer URLs. Dies hilft Suchmaschinen, ihre Indizes zu aktualisieren. - Verwenden Sie
302
(Found/Temporary Redirect), wenn die Umleitung vorübergehend ist oder wenn Sie die ursprüngliche URL in Zukunft möglicherweise wiederverwenden möchten.
Beibehaltung des Pfades
Wenn REDIRECT_TO_REQUEST_URI
auf yes
gesetzt ist, behält BunkerWeb den ursprünglichen Anfragepfad bei. Wenn ein Benutzer beispielsweise https://old-domain.com/blog/post-1
besucht und Sie eine Umleitung zu https://new-domain.com
eingerichtet haben, wird er zu https://new-domain.com/blog/post-1
umgeleitet.
Beispielkonfigurationen
Eine Konfiguration, die mehrere Pfade an verschiedene Ziele umleitet:
# Leitet /blog zu einer neuen Blog-Domain um
REDIRECT_FROM: "/blog/"
REDIRECT_TO: "https://blog.example.com/"
REDIRECT_TO_REQUEST_URI: "yes"
REDIRECT_TO_STATUS_CODE: "301"
# Leitet /shop zu einer anderen Domain um
REDIRECT_FROM_2: "/shop/"
REDIRECT_TO_2: "https://shop.example.com/"
REDIRECT_TO_REQUEST_URI_2: "no"
REDIRECT_TO_STATUS_CODE_2: "301"
# Leitet den Rest der Website um
REDIRECT_FROM_3: "/"
REDIRECT_TO_3: "https://new-domain.com"
REDIRECT_TO_REQUEST_URI_3: "no"
REDIRECT_TO_STATUS_CODE_3: "301"
Eine Konfiguration, die alle Besucher auf eine neue Domain umleitet:
REDIRECT_TO: "https://new-domain.com"
REDIRECT_TO_REQUEST_URI: "no"
REDIRECT_TO_STATUS_CODE: "301"
Eine Konfiguration, die Besucher auf eine neue Domain umleitet und dabei den angeforderten Pfad beibehält:
REDIRECT_TO: "https://new-domain.com"
REDIRECT_TO_REQUEST_URI: "yes"
REDIRECT_TO_STATUS_CODE: "301"
Eine Konfiguration für eine temporäre Umleitung zu einer Wartungsseite:
REDIRECT_TO: "https://maintenance.example.com"
REDIRECT_TO_REQUEST_URI: "no"
REDIRECT_TO_STATUS_CODE: "302"
Eine Konfiguration zur Umleitung einer Subdomain auf einen bestimmten Pfad der Hauptdomain:
REDIRECT_TO: "https://example.com/support"
REDIRECT_TO_REQUEST_URI: "yes"
REDIRECT_TO_STATUS_CODE: "301"
Redis
STREAM-Unterstützung
Der Redis-Plugin integriert Redis oder Valkey in BunkerWeb zur Zwischenspeicherung and für schnellen Datenzugriff. Dies ist unerlässlich in Hochverfügbarkeitsumgebungen, um Sitzungen, Metriken and andere Informationen zwischen mehreren Knoten zu teilen.
Funktionsweise:
- Nach der Aktivierung verbindet sich BunkerWeb mit dem konfigurierten Redis-/Valkey-Server.
- Kritische Daten (Sitzungen, Metriken, Sicherheit) werden dort gespeichert.
- Mehrere Instanzen teilen diese Daten für ein reibungsloses Clustering.
- Unterstützt Standalone-Bereitstellungen, passwortbasierte Authentifizierung, SSL/TLS and Redis Sentinel.
- Automatische Wiederverbindung and konfigurierbare Timeouts sorgen für Robustheit.
Verwendung
- Aktivieren:
USE_REDIS: yes
. - Verbindung: Host/IP and Port.
- Sicherheit: Anmeldeinformationen, falls erforderlich.
- Erweitert: Datenbank, SSL and Timeouts.
- Hochverfügbarkeit: Konfigurieren Sie Sentinel, falls verwendet.
Parameter
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_REDIS |
no |
global | nein | Aktiviert die Redis-/Valkey-Integration (Cluster-Modus). |
REDIS_HOST |
global | nein | Host/IP des Redis-/Valkey-Servers. | |
REDIS_PORT |
6379 |
global | nein | Redis-/Valkey-Port. |
REDIS_DATABASE |
0 |
global | nein | Datenbanknummer (0–15). |
REDIS_SSL |
no |
global | nein | Aktiviert SSL/TLS. |
REDIS_SSL_VERIFY |
yes |
global | nein | Überprüft das SSL-Zertifikat des Servers. |
REDIS_TIMEOUT |
5 |
global | nein | Timeout (Sekunden). |
REDIS_USERNAME |
global | nein | Benutzername (Redis ≥ 6.0). | |
REDIS_PASSWORD |
global | nein | Passwort. | |
REDIS_SENTINEL_HOSTS |
global | nein | Sentinel-Hosts (durch Leerzeichen getrennt, host:port ). |
|
REDIS_SENTINEL_USERNAME |
global | nein | Sentinel-Benutzer. | |
REDIS_SENTINEL_PASSWORD |
global | nein | Sentinel-Passwort. | |
REDIS_SENTINEL_MASTER |
mymaster |
global | nein | Name des Sentinel-Masters. |
REDIS_KEEPALIVE_IDLE |
300 |
global | nein | TCP-Keepalive-Intervall (Sekunden) für inaktive Verbindungen. |
REDIS_KEEPALIVE_POOL |
3 |
global | nein | Maximale Anzahl der im Pool gehaltenen Verbindungen. |
Hochverfügbarkeit
Konfigurieren Sie Redis Sentinel für ein automatisches Failover in der Produktion.
Sicherheit
- Verwenden Sie starke Passwörter für Redis and Sentinel.
- Erwägen Sie die Verwendung von SSL/TLS.
- Setzen Sie Redis nicht dem Internet aus.
- Beschränken Sie den Zugriff auf den Redis-Port (Firewall, Segmentierung).
Beispiele
USE_REDIS: "yes"
REDIS_HOST: "localhost"
REDIS_PORT: "6379"
USE_REDIS: "yes"
REDIS_HOST: "redis.example.com"
REDIS_PORT: "6379"
REDIS_PASSWORD: "your-strong-password"
REDIS_SSL: "yes"
REDIS_SSL_VERIFY: "yes"
USE_REDIS: "yes"
REDIS_SENTINEL_HOSTS: "sentinel1:26379 sentinel2:26379 sentinel3:26379"
REDIS_SENTINEL_MASTER: "mymaster"
REDIS_SENTINEL_PASSWORD: "sentinel-password"
REDIS_PASSWORD: "redis-password"
USE_REDIS: "yes"
REDIS_HOST: "redis.example.com"
REDIS_PORT: "6379"
REDIS_PASSWORD: "your-strong-password"
REDIS_DATABASE: "3"
REDIS_TIMEOUT: "3"
REDIS_KEEPALIVE_IDLE: "60"
REDIS_KEEPALIVE_POOL: "5"
Reporting
(PRO)
STREAM-Unterstützung
Regular reporting of important data from BunkerWeb (global, attacks, bans, requests, reasons, AS...). Monitoring pro plugin needed to work.
Einstellung | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_REPORTING_SMTP |
no |
global | nein | Enable sending the report via email. |
USE_REPORTING_WEBHOOK |
no |
global | nein | Enable sending the report via webhook. |
REPORTING_SCHEDULE |
weekly |
global | nein | The frequency at which reports are sent. |
REPORTING_WEBHOOK_URLS |
global | nein | List of webhook URLs to receive the report in Markdown (separated by spaces). | |
REPORTING_SMTP_EMAILS |
global | nein | List of email addresses to receive the report in HTML format (separated by spaces). | |
REPORTING_SMTP_HOST |
global | nein | The host server used for SMTP sending. | |
REPORTING_SMTP_PORT |
465 |
global | nein | The port used for SMTP. Please note that there are different standards depending on the type of connection (SSL = 465, TLS = 587). |
REPORTING_SMTP_FROM_EMAIL |
global | nein | The email address used as the sender. Note that 2FA must be disabled for this email address. | |
REPORTING_SMTP_FROM_USER |
global | nein | The user authentication value for sending via the from email address. | |
REPORTING_SMTP_FROM_PASSWORD |
global | nein | The password authentication value for sending via the from email address. | |
REPORTING_SMTP_SSL |
SSL |
global | nein | Determine whether or not to use a secure connection for SMTP. |
REPORTING_SMTP_SUBJECT |
BunkerWeb Report |
global | nein | The subject line of the email. |
Reverse proxy
STREAM-Unterstützung
Das Reverse-Proxy-Plugin bietet nahtlose Proxy-Funktionen für BunkerWeb, mit denen Sie Anfragen an Backend-Server und -Dienste weiterleiten können. Mit dieser Funktion kann BunkerWeb als sicheres Frontend für Ihre Anwendungen fungieren und gleichzeitig zusätzliche Vorteile wie SSL-Terminierung und Sicherheitsfilterung bieten.
So funktioniert es:
- Wenn ein Client eine Anfrage an BunkerWeb sendet, leitet das Reverse-Proxy-Plugin die Anfrage an Ihren konfigurierten Backend-Server weiter.
- BunkerWeb fügt Sicherheitsheader hinzu, wendet WAF-Regeln an und führt andere Sicherheitsprüfungen durch, bevor die Anfragen an Ihre Anwendung weitergeleitet werden.
- Der Backend-Server verarbeitet die Anfrage und gibt eine Antwort an BunkerWeb zurück.
- BunkerWeb wendet zusätzliche Sicherheitsmaßnahmen auf die Antwort an, bevor sie an den Client zurückgesendet wird.
- Das Plugin unterstützt sowohl HTTP- als auch TCP/UDP-Stream-Proxying und ermöglicht so eine breite Palette von Anwendungen, einschließlich WebSockets und anderen Nicht-HTTP-Protokollen.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Reverse-Proxy-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Setzen Sie die Einstellung
USE_REVERSE_PROXY
aufyes
, um die Reverse-Proxy-Funktionalität zu aktivieren. - Konfigurieren Sie Ihre Backend-Server: Geben Sie die Upstream-Server mit der Einstellung
REVERSE_PROXY_HOST
an. - Proxy-Einstellungen anpassen: Optimieren Sie das Verhalten mit optionalen Einstellungen für Zeitüberschreitungen, Puffergrößen und andere Parameter.
- Protokollspezifische Optionen konfigurieren: Passen Sie für WebSockets oder spezielle HTTP-Anforderungen die entsprechenden Einstellungen an.
- Caching einrichten (optional): Aktivieren und konfigurieren Sie das Proxy-Caching, um die Leistung für häufig aufgerufene Inhalte zu verbessern.
Konfigurationsanleitung
Kerneinstellungen
Die wesentlichen Konfigurationseinstellungen aktivieren und steuern die Grundfunktionalität der Reverse-Proxy-Funktion.
Vorteile des Reverse-Proxy
- Sicherheitsverbesserung: Der gesamte Datenverkehr durchläuft die Sicherheitsschichten von BunkerWeb, bevor er Ihre Anwendungen erreicht
- SSL-Terminierung: Verwalten Sie SSL/TLS-Zertifikate zentral, während Backend-Dienste unverschlüsselte Verbindungen verwenden können
- Protokollbehandlung: Unterstützung für HTTP, HTTPS, WebSockets und andere Protokolle
- Fehlerabfang: Passen Sie Fehlerseiten für ein einheitliches Benutzererlebnis an
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_REVERSE_PROXY |
no |
multisite | nein | Reverse-Proxy aktivieren: Auf yes setzen, um die Reverse-Proxy-Funktionalität zu aktivieren. |
REVERSE_PROXY_HOST |
multisite | ja | Backend-Host: Vollständige URL der weitergeleiteten Ressource (proxy_pass). | |
REVERSE_PROXY_URL |
/ |
multisite | ja | Standort-URL: Pfad, der zum Backend-Server weitergeleitet wird. |
REVERSE_PROXY_BUFFERING |
yes |
multisite | ja | Antwort-Pufferung: Aktiviert oder deaktiviert die Pufferung von Antworten von der weitergeleiteten Ressource. |
REVERSE_PROXY_KEEPALIVE |
no |
multisite | ja | Keep-Alive: Aktiviert oder deaktiviert Keep-Alive-Verbindungen mit der weitergeleiteten Ressource. |
REVERSE_PROXY_CUSTOM_HOST |
multisite | nein | Benutzerdefinierter Host: Überschreibt den an den Upstream-Server gesendeten Host-Header. | |
REVERSE_PROXY_INTERCEPT_ERRORS |
yes |
multisite | nein | Fehler abfangen: Ob Fehlerantworten vom Backend abgefangen und neu geschrieben werden sollen. |
Bewährte Praktiken
- Geben Sie in
REVERSE_PROXY_HOST
immer die vollständige URL an, einschließlich des Protokolls (http:// oder https://) - Verwenden Sie
REVERSE_PROXY_INTERCEPT_ERRORS
, um konsistente Fehlerseiten für alle Ihre Dienste bereitzustellen - Verwenden Sie bei der Konfiguration mehrerer Backends das nummerierte Suffixformat (z. B.
REVERSE_PROXY_HOST_2
,REVERSE_PROXY_URL_2
)
Konfiguration von Verbindungen und Zeitüberschreitungen
Diese Einstellungen steuern das Verbindungsverhalten, die Pufferung und die Zeitüberschreitungswerte für die weitergeleiteten Verbindungen.
Vorteile
- Optimierte Leistung: Passen Sie Puffergrößen und Verbindungseinstellungen an die Bedürfnisse Ihrer Anwendung an
- Ressourcenmanagement: Kontrollieren Sie die Speichernutzung durch geeignete Pufferkonfigurationen
- Zuverlässigkeit: Konfigurieren Sie geeignete Zeitüberschreitungen, um langsame Verbindungen oder Backend-Probleme zu bewältigen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
REVERSE_PROXY_CONNECT_TIMEOUT |
60s |
multisite | ja | Verbindungs-Timeout: Maximale Zeit zum Herstellen einer Verbindung zum Backend-Server. |
REVERSE_PROXY_READ_TIMEOUT |
60s |
multisite | ja | Lese-Timeout: Maximale Zeit zwischen der Übertragung von zwei aufeinanderfolgenden Paketen vom Backend-Server. |
REVERSE_PROXY_SEND_TIMEOUT |
60s |
multisite | ja | Sende-Timeout: Maximale Zeit zwischen der Übertragung von zwei aufeinanderfolgenden Paketen zum Backend-Server. |
PROXY_BUFFERS |
multisite | nein | Puffer: Anzahl und Größe der Puffer zum Lesen der Antwort vom Backend-Server. | |
PROXY_BUFFER_SIZE |
multisite | nein | Puffergröße: Größe des Puffers zum Lesen des ersten Teils der Antwort vom Backend-Server. | |
PROXY_BUSY_BUFFERS_SIZE |
multisite | nein | Größe der belegten Puffer: Größe der Puffer, die mit dem Senden einer Antwort an den Client beschäftigt sein können. |
Überlegungen zu Zeitüberschreitungen
- Zu kurze Zeitüberschreitungen können legitime, aber langsame Verbindungen unterbrechen
- Zu lange Zeitüberschreitungen können Verbindungen unnötig offen lassen und möglicherweise Ressourcen erschöpfen
- Bei WebSocket-Anwendungen sollten Sie die Lese- und Sende-Timeouts deutlich erhöhen (300s oder mehr empfohlen)
SSL/TLS-Einstellungen für Backend-Verbindungen
Diese Einstellungen steuern, wie BunkerWeb sichere Verbindungen zu Backend-Servern herstellt.
Vorteile
- Ende-zu-Ende-Verschlüsselung: Behalten Sie verschlüsselte Verbindungen vom Client zum Backend bei
- Zertifikatsvalidierung: Kontrollieren Sie, wie Backend-Serverzertifikate validiert werden
- SNI-Unterstützung: Geben Sie die Server Name Indication für Backends an, die mehrere Websites hosten
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
REVERSE_PROXY_SSL_SNI |
no |
multisite | nein | SSL SNI: Aktiviert oder deaktiviert das Senden von SNI (Server Name Indication) an den Upstream. |
REVERSE_PROXY_SSL_SNI_NAME |
multisite | nein | SSL SNI-Name: Legt den SNI-Hostnamen fest, der an den Upstream gesendet wird, wenn SSL SNI aktiviert ist. |
SNI erklärt
Server Name Indication (SNI) ist eine TLS-Erweiterung, die es einem Client ermöglicht, den Hostnamen anzugeben, mit dem er während des Handshake-Prozesses eine Verbindung herstellen möchte. Dies ermöglicht es Servern, mehrere Zertifikate auf derselben IP-Adresse und demselben Port zu präsentieren, sodass mehrere sichere (HTTPS-)Websites von einer einzigen IP-Adresse aus bedient werden können, ohne dass alle diese Websites dasselbe Zertifikat verwenden müssen.
Protokollspezifische Konfiguration
Konfigurieren Sie die Behandlung spezieller Protokolle, insbesondere für WebSockets und andere Nicht-HTTP-Protokolle.
Vorteile
- Protokollflexibilität: Die Unterstützung für WebSockets ermöglicht Echtzeitanwendungen
- Moderne Webanwendungen: Aktivieren Sie interaktive Funktionen, die eine bidirektionale Kommunikation erfordern
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
REVERSE_PROXY_WS |
no |
multisite | ja | WebSocket-Unterstützung: Aktiviert das WebSocket-Protokoll für die Ressource. |
WebSocket-Konfiguration
- Bei der Aktivierung von WebSockets mit
REVERSE_PROXY_WS: "yes"
sollten Sie die Zeitüberschreitungswerte erhöhen - WebSocket-Verbindungen bleiben länger offen als typische HTTP-Verbindungen
- Für WebSocket-Anwendungen wird folgende Konfiguration empfohlen:
REVERSE_PROXY_WS: "yes" REVERSE_PROXY_READ_TIMEOUT: "300s" REVERSE_PROXY_SEND_TIMEOUT: "300s"
HTTP-Header-Konfiguration
Kontrollieren Sie, welche Header an Backend-Server und Clients gesendet werden, und ermöglichen Sie das Hinzufügen, Ändern oder Beibehalten von HTTP-Headern.
Vorteile
- Informationskontrolle: Verwalten Sie genau, welche Informationen zwischen Clients und Backends ausgetauscht werden
- Sicherheitsverbesserung: Fügen Sie sicherheitsrelevante Header hinzu oder entfernen Sie Header, die sensible Informationen preisgeben könnten
- Integrationsunterstützung: Stellen Sie die für die Authentifizierung und den ordnungsgemäßen Backend-Betrieb erforderlichen Header bereit
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
REVERSE_PROXY_HEADERS |
multisite | ja | Benutzerdefinierte Header: HTTP-Header, die durch Semikolons getrennt an das Backend gesendet werden. | |
REVERSE_PROXY_HIDE_HEADERS |
Upgrade |
multisite | ja | Header ausblenden: HTTP-Header, die vor Clients verborgen werden sollen, wenn sie vom Backend empfangen werden. |
REVERSE_PROXY_HEADERS_CLIENT |
multisite | ja | Client-Header: HTTP-Header, die durch Semikolons getrennt an den Client gesendet werden. | |
REVERSE_PROXY_UNDERSCORES_IN_HEADERS |
no |
multisite | nein | Unterstriche in Headern: Aktiviert oder deaktiviert die underscores_in_headers -Direktive. |
Sicherheitsüberlegungen
Seien Sie bei der Verwendung der Reverse-Proxy-Funktion vorsichtig, welche Header Sie an Ihre Backend-Anwendungen weiterleiten. Bestimmte Header können sensible Informationen über Ihre Infrastruktur preisgeben oder Sicherheitskontrollen umgehen.
Beispiele für Header-Formate
Benutzerdefinierte Header an Backend-Server:
REVERSE_PROXY_HEADERS: "X-Real-IP $remote_addr;X-Forwarded-For $proxy_add_x_forwarded_for;X-Forwarded-Proto $scheme"
Benutzerdefinierte Header an Clients:
REVERSE_PROXY_HEADERS_CLIENT: "X-Powered-By BunkerWeb;X-Frame-Options SAMEORIGIN"
Konfiguration der externen Authentifizierung
Integrieren Sie externe Authentifizierungssysteme, um die Autorisierungslogik für Ihre Anwendungen zu zentralisieren.
Vorteile
- Zentralisierte Authentifizierung: Implementieren Sie einen einzigen Authentifizierungspunkt für mehrere Anwendungen
- Konsistente Sicherheit: Wenden Sie einheitliche Authentifizierungsrichtlinien für verschiedene Dienste an
- Verbesserte Kontrolle: Leiten Sie Authentifizierungsdetails über Header oder Variablen an Backend-Anwendungen weiter
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
REVERSE_PROXY_AUTH_REQUEST |
multisite | ja | Authentifizierungsanforderung: Aktiviert die Authentifizierung über einen externen Anbieter. | |
REVERSE_PROXY_AUTH_REQUEST_SIGNIN_URL |
multisite | ja | Anmelde-URL: Leitet Clients bei fehlgeschlagener Authentifizierung zur Anmelde-URL weiter. | |
REVERSE_PROXY_AUTH_REQUEST_SET |
multisite | ja | Authentifizierungsanforderungssatz: Variablen, die vom Authentifizierungsanbieter festgelegt werden sollen. |
Authentifizierungsintegration
- Die Authentifizierungsanforderungsfunktion ermöglicht die Implementierung zentralisierter Authentifizierungsmikrodienste
- Ihr Authentifizierungsdienst sollte bei erfolgreicher Authentifizierung einen 200-Statuscode oder bei einem Fehler 401/403 zurückgeben
- Verwenden Sie die auth_request_set-Direktive, um Informationen vom Authentifizierungsdienst zu extrahieren und weiterzuleiten
Zusätzliche Konfigurationsoptionen
Diese Einstellungen bieten eine weitere Anpassung des Reverse-Proxy-Verhaltens für spezielle Szenarien.
Vorteile
- Anpassung: Fügen Sie zusätzliche Konfigurationsausschnitte für komplexe Anforderungen hinzu
- Leistungsoptimierung: Optimieren Sie die Anforderungsbehandlung für bestimmte Anwendungsfälle
- Flexibilität: Passen Sie sich mit speziellen Konfigurationen an einzigartige Anwendungsanforderungen an
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
REVERSE_PROXY_INCLUDES |
multisite | ja | Zusätzliche Konfigurationen: Fügen Sie zusätzliche Konfigurationen in den Standortblock ein. | |
REVERSE_PROXY_PASS_REQUEST_BODY |
yes |
multisite | ja | Anforderungskörper weiterleiten: Aktiviert oder deaktiviert das Weiterleiten des Anforderungskörpers. |
Sicherheitsüberlegungen
Seien Sie vorsichtig, wenn Sie benutzerdefinierte Konfigurationsausschnitte einfügen, da diese die Sicherheitseinstellungen von BunkerWeb überschreiben oder bei unsachgemäßer Konfiguration Schwachstellen einführen können.
Einstellungen für das Caching von Antworten
Verbessern Sie die Leistung durch das Caching von Antworten von Backend-Servern, wodurch die Last reduziert und die Antwortzeiten verbessert werden.
Vorteile
- Leistung: Reduzieren Sie die Last auf Backend-Servern, indem Sie zwischengespeicherte Inhalte bereitstellen
- Reduzierte Latenz: Schnellere Antwortzeiten für häufig angeforderte Inhalte
- Bandbreiteneinsparungen: Minimieren Sie den internen Netzwerkverkehr durch das Caching von Antworten
- Anpassung: Konfigurieren Sie genau, was, wann und wie Inhalte zwischengespeichert werden
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_PROXY_CACHE |
no |
multisite | nein | Caching aktivieren: Auf yes setzen, um das Caching von Backend-Antworten zu aktivieren. |
PROXY_CACHE_PATH_LEVELS |
1:2 |
global | nein | Cache-Pfad-Ebenen: Wie die Hierarchie des Cache-Verzeichnisses strukturiert werden soll. |
PROXY_CACHE_PATH_ZONE_SIZE |
10m |
global | nein | Cache-Zonengröße: Größe des gemeinsam genutzten Speicherbereichs, der für Cache-Metadaten verwendet wird. |
PROXY_CACHE_PATH_PARAMS |
max_size=100m |
global | nein | Cache-Pfad-Parameter: Zusätzliche Parameter für den Cache-Pfad. |
PROXY_CACHE_METHODS |
GET HEAD |
multisite | nein | Cache-Methoden: HTTP-Methoden, die zwischengespeichert werden können. |
PROXY_CACHE_MIN_USES |
2 |
multisite | nein | Mindestverwendungen für Cache: Mindestanzahl von Anfragen, bevor eine Antwort zwischengespeichert wird. |
PROXY_CACHE_KEY |
$scheme$host$request_uri |
multisite | nein | Cache-Schlüssel: Der Schlüssel, der zur eindeutigen Identifizierung einer zwischengespeicherten Antwort verwendet wird. |
PROXY_CACHE_VALID |
200=24h 301=1h 302=24h |
multisite | nein | Cache-Gültigkeit: Wie lange bestimmte Antwortcodes zwischengespeichert werden sollen. |
PROXY_NO_CACHE |
$http_pragma $http_authorization |
multisite | nein | Kein Cache: Bedingungen, unter denen Antworten nicht zwischengespeichert werden, auch wenn sie normalerweise zwischengespeichert werden könnten. |
PROXY_CACHE_BYPASS |
0 |
multisite | nein | Cache-Umgehung: Bedingungen, unter denen der Cache umgangen werden soll. |
Bewährte Praktiken für das Caching
- Speichern Sie nur Inhalte zwischen, die sich nicht häufig ändern oder nicht personalisiert sind
- Verwenden Sie je nach Inhaltstyp geeignete Cache-Dauern (statische Assets können länger zwischengespeichert werden)
- Konfigurieren Sie
PROXY_NO_CACHE
, um das Zwischenspeichern sensibler oder personalisierter Inhalte zu vermeiden - Überwachen Sie die Cache-Trefferquoten und passen Sie die Einstellungen entsprechend an
Docker Compose-Benutzer - NGINX-Variablen
Wenn Sie Docker Compose mit NGINX-Variablen in Ihren Konfigurationen verwenden, müssen Sie das Dollarzeichen ($
) durch doppelte Dollarzeichen ($$
) maskieren. Dies gilt für alle Einstellungen, die NGINX-Variablen wie $remote_addr
, $proxy_add_x_forwarded_for
usw. enthalten.
Ohne diese Maskierung versucht Docker Compose, diese Variablen durch Umgebungsvariablen zu ersetzen, die normalerweise nicht existieren, was zu leeren Werten in Ihrer NGINX-Konfiguration führt.
Beispielkonfigurationen
Eine einfache Konfiguration zum Weiterleiten von HTTP-Anfragen an einen Backend-Anwendungsserver:
USE_REVERSE_PROXY: "yes"
REVERSE_PROXY_HOST: "http://application:8080"
REVERSE_PROXY_URL: "/"
REVERSE_PROXY_CONNECT_TIMEOUT: "10s"
REVERSE_PROXY_SEND_TIMEOUT: "60s"
REVERSE_PROXY_READ_TIMEOUT: "60s"
Konfiguration, die für eine WebSocket-Anwendung mit längeren Zeitüberschreitungen optimiert ist:
USE_REVERSE_PROXY: "yes"
REVERSE_PROXY_HOST: "http://websocket-app:8080"
REVERSE_PROXY_URL: "/"
REVERSE_PROXY_WS: "yes"
REVERSE_PROXY_CONNECT_TIMEOUT: "10s"
REVERSE_PROXY_SEND_TIMEOUT: "300s"
REVERSE_PROXY_READ_TIMEOUT: "300s"
Konfiguration zum Weiterleiten verschiedener Pfade an verschiedene Backend-Dienste:
USE_REVERSE_PROXY: "yes"
# API-Backend
REVERSE_PROXY_HOST: "http://api-server:8080"
REVERSE_PROXY_URL: "/api/"
# Admin-Backend
REVERSE_PROXY_HOST_2: "http://admin-server:8080"
REVERSE_PROXY_URL_2: "/admin/"
# Frontend-App
REVERSE_PROXY_HOST_3: "http://frontend:3000"
REVERSE_PROXY_URL_3: "/"
Konfiguration mit aktiviertem Proxy-Caching für eine bessere Leistung:
USE_REVERSE_PROXY: "yes"
REVERSE_PROXY_HOST: "http://application:8080"
REVERSE_PROXY_URL: "/"
USE_PROXY_CACHE: "yes"
PROXY_CACHE_VALID: "200=24h 301=1h 302=24h"
PROXY_CACHE_METHODS: "GET HEAD"
PROXY_NO_CACHE: "$http_authorization"
Konfiguration mit benutzerdefinierter Header-Manipulation:
USE_REVERSE_PROXY: "yes"
REVERSE_PROXY_HOST: "http://application:8080"
REVERSE_PROXY_URL: "/"
# Benutzerdefinierte Header an das Backend
REVERSE_PROXY_HEADERS: "X-Real-IP $remote_addr;X-Forwarded-For $proxy_add_x_forwarded_for;X-Forwarded-Proto $scheme"
# Benutzerdefinierte Header an den Client
REVERSE_PROXY_HEADERS_CLIENT: "X-Powered-By BunkerWeb;X-Frame-Options SAMEORIGIN"
Konfiguration mit externer Authentifizierung:
USE_REVERSE_PROXY: "yes"
REVERSE_PROXY_HOST: "http://application:8080"
REVERSE_PROXY_URL: "/"
# Authentifizierungskonfiguration
REVERSE_PROXY_AUTH_REQUEST: "/auth"
REVERSE_PROXY_AUTH_REQUEST_SIGNIN_URL: "https://login.example.com"
REVERSE_PROXY_AUTH_REQUEST_SET: "$auth_user $upstream_http_x_user;$auth_role $upstream_http_x_role"
# Backend des Authentifizierungsdienstes
REVERSE_PROXY_HOST_2: "http://auth-service:8080"
REVERSE_PROXY_URL_2: "/auth"
Reverse scan
STREAM-Unterstützung
Das Reverse Scan-Plugin schützt robust vor Proxy-Umgehungsversuchen, indem es die Ports der Clients scannt, um festzustellen, ob sie Proxyserver oder andere Netzwerkdienste betreiben. Diese Funktion hilft dabei, potenzielle Bedrohungen von Clients zu identifizieren und zu blockieren, die möglicherweise versuchen, ihre wahre Identität oder Herkunft zu verbergen, und verbessert so die Sicherheitslage Ihrer Website.
So funktioniert es:
- Wenn ein Client eine Verbindung zu Ihrem Server herstellt, versucht BunkerWeb, bestimmte Ports auf der IP-Adresse des Clients zu scannen.
- Das Plugin prüft, ob gängige Proxy-Ports (wie 80, 443, 8080 usw.) auf der Client-Seite geöffnet sind.
- Wenn offene Ports erkannt werden, was darauf hindeutet, dass der Client möglicherweise einen Proxyserver betreibt, wird die Verbindung verweigert.
- Dies fügt eine zusätzliche Sicherheitsebene gegen automatisierte Tools, Bots und böswillige Benutzer hinzu, die versuchen, ihre Identität zu verschleiern.
Wichtige Vorteile
- Erhöhte Sicherheit: Identifiziert Clients, die potenziell Proxyserver betreiben, die für bösartige Zwecke verwendet werden könnten.
- Proxy-Erkennung: Hilft bei der Erkennung und Blockierung von Clients, die versuchen, ihre wahre Identität zu verbergen.
- Konfigurierbare Einstellungen: Passen Sie an, welche Ports basierend auf Ihren spezifischen Sicherheitsanforderungen gescannt werden sollen.
- Leistungsoptimiert: Intelligentes Scannen mit konfigurierbaren Zeitüberschreitungen, um die Auswirkungen auf legitime Benutzer zu minimieren.
- Nahtlose Integration: Arbeitet transparent mit Ihren bestehenden Sicherheitsebenen zusammen.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Reverse-Scan-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Setzen Sie die Einstellung
USE_REVERSE_SCAN
aufyes
, um das Scannen von Client-Ports zu aktivieren. - Zu scannende Ports konfigurieren: Passen Sie die Einstellung
REVERSE_SCAN_PORTS
an, um anzugeben, welche Client-Ports überprüft werden sollen. - Scan-Timeout festlegen: Passen Sie den
REVERSE_SCAN_TIMEOUT
an, um ein Gleichgewicht zwischen gründlichem Scannen und Leistung zu finden. - Scan-Aktivität überwachen: Überprüfen Sie die Protokolle und die Web-Benutzeroberfläche, um die Scan-Ergebnisse und potenzielle Sicherheitsvorfälle zu überprüfen.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_REVERSE_SCAN |
no |
multisite | nein | Reverse-Scan aktivieren: Auf yes setzen, um das Scannen von Client-Ports zu aktivieren. |
REVERSE_SCAN_PORTS |
22 80 443 3128 8000 8080 |
multisite | nein | Zu scannende Ports: Leerzeichengetrennte Liste der zu überprüfenden Ports auf der Client-Seite. |
REVERSE_SCAN_TIMEOUT |
500 |
multisite | nein | Scan-Timeout: Maximale Zeit in Millisekunden, die für das Scannen eines Ports zulässig ist. |
Leistungsüberlegungen
Das Scannen mehrerer Ports kann die Latenz bei Client-Verbindungen erhöhen. Verwenden Sie einen angemessenen Zeitüberschreitungswert und begrenzen Sie die Anzahl der gescannten Ports, um eine gute Leistung aufrechtzuerhalten.
Gängige Proxy-Ports
Die Standardkonfiguration umfasst gängige Ports, die von Proxyservern (80, 443, 8080, 3128) und SSH (22) verwendet werden. Sie können diese Liste basierend auf Ihrem Bedrohungsmodell anpassen.
Beispielkonfigurationen
Eine einfache Konfiguration zum Aktivieren des Client-Port-Scannens:
USE_REVERSE_SCAN: "yes"
REVERSE_SCAN_TIMEOUT: "500"
REVERSE_SCAN_PORTS: "80 443 8080"
Eine gründlichere Konfiguration, die zusätzliche Ports überprüft:
USE_REVERSE_SCAN: "yes"
REVERSE_SCAN_TIMEOUT: "1000"
REVERSE_SCAN_PORTS: "22 80 443 3128 8080 8000 8888 1080 3333 8081"
Konfiguration, die auf eine bessere Leistung abgestimmt ist, indem weniger Ports mit einer geringeren Zeitüberschreitung überprüft werden:
USE_REVERSE_SCAN: "yes"
REVERSE_SCAN_TIMEOUT: "250"
REVERSE_SCAN_PORTS: "80 443 8080"
Konfiguration mit Fokus auf maximale Sicherheit mit erweitertem Scannen:
USE_REVERSE_SCAN: "yes"
REVERSE_SCAN_TIMEOUT: "1500"
REVERSE_SCAN_PORTS: "22 25 80 443 1080 3128 3333 4444 5555 6588 6666 7777 8000 8080 8081 8800 8888 9999"
Robots.txt
STREAM-Unterstützung
Das Robots.txt-Plugin verwaltet die Datei robots.txt für Ihre Website. Diese Datei teilt Web-Crawlern und Robotern mit, auf welche Teile Ihrer Website sie zugreifen dürfen und auf welche nicht.
So funktioniert es:
Wenn aktiviert, generiert BunkerWeb dynamisch die /robots.txt
-Datei im Stammverzeichnis Ihrer Website. Die Regeln in dieser Datei werden in der folgenden Reihenfolge aus mehreren Quellen zusammengefasst:
- DarkVisitors-API: Wenn
ROBOTSTXT_DARKVISITORS_TOKEN
angegeben ist, werden Regeln von der DarkVisitors-API abgerufen, was eine dynamische Blockierung bösartiger Bots und KI-Crawler basierend auf konfigurierten Agententypen und nicht zugelassenen Benutzeragenten ermöglicht. - Community-Listen: Regeln aus vordefinierten, von der Community gepflegten
robots.txt
-Listen (angegeben durchROBOTSTXT_COMMUNITY_LISTS
) werden einbezogen. - Benutzerdefinierte URLs: Regeln werden von vom Benutzer bereitgestellten URLs abgerufen (angegeben durch
ROBOTSTXT_URLS
). - Manuelle Regeln: Regeln, die direkt über
ROBOTSTXT_RULE
-Umgebungsvariablen definiert werden, werden hinzugefügt.
Alle Regeln aus diesen Quellen werden kombiniert. Nach der Aggregation werden ROBOTSTXT_IGNORE_RULE
angewendet, um unerwünschte Regeln mit PCRE-Regex-Mustern herauszufiltern. Wenn nach diesem gesamten Prozess keine Regeln mehr übrig sind, wird automatisch eine Standardregel User-agent: *
und Disallow: /
angewendet, um einen grundlegenden Schutz zu gewährleisten. Optionale Sitemap-URLs (angegeben durch ROBOTSTXT_SITEMAP
) werden ebenfalls in die endgültige robots.txt
-Ausgabe aufgenommen.
Dynamische Bot-Umgehung mit der DarkVisitors-API
DarkVisitors ist ein Dienst, der eine dynamische robots.txt
-Datei bereitstellt, um bekannte bösartige Bots und KI-Crawler zu blockieren. Durch die Integration mit DarkVisitors kann BunkerWeb automatisch eine aktuelle robots.txt
abrufen und bereitstellen, die Ihre Website vor unerwünschtem automatisiertem Datenverkehr schützt.
Um dies zu aktivieren, müssen Sie sich bei darkvisitors.com anmelden und ein Bearer-Token erhalten.
Wie man es benutzt
- Aktivieren Sie die Funktion: Setzen Sie die Einstellung
USE_ROBOTSTXT
aufyes
. - Regeln konfigurieren: Wählen Sie eine oder mehrere Methoden, um Ihre
robots.txt
-Regeln zu definieren:- DarkVisitors-API: Geben Sie
ROBOTSTXT_DARKVISITORS_TOKEN
und optionalROBOTSTXT_DARKVISITORS_AGENT_TYPES
undROBOTSTXT_DARKVISITORS_DISALLOW
an. - Community-Listen: Geben Sie
ROBOTSTXT_COMMUNITY_LISTS
an (durch Leerzeichen getrennte IDs). - Benutzerdefinierte URLs: Geben Sie
ROBOTSTXT_URLS
an (durch Leerzeichen getrennte URLs). - Manuelle Regeln: Verwenden Sie
ROBOTSTXT_RULE
für einzelne Regeln (mehrere Regeln können mitROBOTSTXT_RULE_N
angegeben werden).
- DarkVisitors-API: Geben Sie
- Regeln filtern (optional): Verwenden Sie
ROBOTSTXT_IGNORE_RULE_N
, um bestimmte Regeln nach Regex-Muster auszuschließen. - Sitemaps hinzufügen (optional): Verwenden Sie
ROBOTSTXT_SITEMAP_N
für Sitemap-URLs. - Die generierte robots.txt-Datei abrufen: Sobald BunkerWeb mit den obigen Einstellungen läuft, können Sie auf die dynamisch generierte
robots.txt
-Datei zugreifen, indem Sie eine HTTP-GET-Anfrage anhttp(s)://your-domain.com/robots.txt
senden.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_ROBOTSTXT |
no |
multisite | Nein | Aktiviert oder deaktiviert die robots.txt -Funktion. |
ROBOTSTXT_DARKVISITORS_TOKEN |
multisite | Nein | Bearer-Token für die DarkVisitors-API. | |
ROBOTSTXT_DARKVISITORS_AGENT_TYPES |
multisite | Nein | Kommagetrennte Liste von Agententypen (z. B. AI Data Scraper ), die von DarkVisitors einbezogen werden sollen. |
|
ROBOTSTXT_DARKVISITORS_DISALLOW |
/ |
multisite | Nein | Ein String, der angibt, welche URLs nicht erlaubt sind. Dieser Wert wird als Disallow-Feld gesendet, wenn die DarkVisitors-API kontaktiert wird. |
ROBOTSTXT_COMMUNITY_LISTS |
multisite | Nein | Leerzeichengetrennte Liste von von der Community gepflegten Regelsatz-IDs, die einbezogen werden sollen. | |
ROBOTSTXT_URLS |
multisite | Nein | Leerzeichengetrennte Liste von URLs, von denen zusätzliche robots.txt -Regeln abgerufen werden sollen. Unterstützt file:// und Basic-Auth. |
|
ROBOTSTXT_RULE |
multisite | Ja | Eine einzelne Regel für robots.txt . |
|
ROBOTSTXT_HEADER |
multisite | Ja | Kopfzeile für die robots.txt -Datei (vor den Regeln). Kann Base64-kodiert sein. |
|
ROBOTSTXT_FOOTER |
multisite | Ja | Fußzeile für die robots.txt -Datei (nach den Regeln). Kann Base64-kodiert sein. |
|
ROBOTSTXT_IGNORE_RULE |
multisite | Ja | Ein einzelnes PCRE-Regex-Muster zum Ignorieren von Regeln. | |
ROBOTSTXT_SITEMAP |
multisite | Ja | Eine einzelne Sitemap-URL. |
Beispielkonfigurationen
Grundlegende manuelle Regeln
USE_ROBOTSTXT: "yes"
ROBOTSTXT_RULE: "User-agent: *"
ROBOTSTXT_RULE_1: "Disallow: /private"
ROBOTSTXT_SITEMAP: "https://example.com/sitemap.xml"
Verwendung dynamischer Quellen (DarkVisitors & Community-Liste)
USE_ROBOTSTXT: "yes"
ROBOTSTXT_DARKVISITORS_TOKEN: "ihr-darkvisitors-token-hier"
ROBOTSTXT_DARKVISITORS_AGENT_TYPES: "AI Data Scraper"
ROBOTSTXT_COMMUNITY_LISTS: "robots-disallowed"
ROBOTSTXT_IGNORE_RULE: "User-agent: Googlebot-Image"
Kombinierte Konfiguration
USE_ROBOTSTXT: "yes"
ROBOTSTXT_DARKVISITORS_TOKEN: "ihr-darkvisitors-token-hier"
ROBOTSTXT_COMMUNITY_LISTS: "ai-robots-txt"
ROBOTSTXT_URLS: "https://example.com/my-custom-rules.txt"
ROBOTSTXT_RULE: "User-agent: MyOwnBot"
ROBOTSTXT_RULE_1: "Disallow: /admin"
ROBOTSTXT_IGNORE_RULE: "User-agent: Googlebot-Image"
ROBOTSTXT_SITEMAP: "https://example.com/sitemap.xml"
Mit Kopf- und Fußzeile
USE_ROBOTSTXT: "yes"
ROBOTSTXT_HEADER: "# Dies ist eine benutzerdefinierte Kopfzeile"
ROBOTSTXT_RULE: "User-agent: *"
ROBOTSTXT_RULE_1: "Disallow: /private"
ROBOTSTXT_FOOTER: "# Dies ist eine benutzerdefinierte Fußzeile"
ROBOTSTXT_SITEMAP: "https://example.com/sitemap.xml"```
---
Weitere Informationen finden Sie in der [robots.txt-Dokumentation](https://www.robotstxt.org/robotstxt.html).
SSL
STREAM-Unterstützung
Das SSL-Plugin bietet eine robuste SSL/TLS-Verschlüsselung für Ihre durch BunkerWeb geschützten Websites. Es ermöglicht sichere HTTPS-Verbindungen durch die Konfiguration von Protokollen, kryptografischen Suiten und zugehörigen Parametern.
So funktioniert's:
- Bei einer HTTPS-Verbindung verwaltet BunkerWeb die SSL/TLS-Aushandlung gemäß Ihren Einstellungen.
- Das Plugin erzwingt moderne Protokolle und starke Suiten und deaktiviert anfällige Optionen.
- Optimierte Sitzungsparameter verbessern die Leistung, ohne die Sicherheit zu beeinträchtigen.
- Die Präsentation der Zertifikate folgt Best Practices für Kompatibilität und Sicherheit.
Verwendung
- Protokolle: Wählen Sie die Versionen über
SSL_PROTOCOLS
. - Suiten: Wählen Sie ein Niveau über
SSL_CIPHERS_LEVEL
oder benutzerdefinierte Suiten überSSL_CIPHERS_CUSTOM
. - Weiterleitungen: Konfigurieren Sie die HTTP→HTTPS-Weiterleitung mit
AUTO_REDIRECT_HTTP_TO_HTTPS
und/oderREDIRECT_HTTP_TO_HTTPS
.
Parameter
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
REDIRECT_HTTP_TO_HTTPS |
no |
Multisite | nein | Leitet alle HTTP-Anfragen zu HTTPS um. |
AUTO_REDIRECT_HTTP_TO_HTTPS |
yes |
Multisite | nein | Automatische Weiterleitung, wenn HTTPS erkannt wird. |
SSL_PROTOCOLS |
TLSv1.2 TLSv1.3 |
Multisite | nein | Unterstützte SSL/TLS-Protokolle (durch Leerzeichen getrennt). |
SSL_CIPHERS_LEVEL |
modern |
Multisite | nein | Sicherheitsniveau der Suiten (modern , intermediate , old ). |
SSL_CIPHERS_CUSTOM |
Multisite | nein | Benutzerdefinierte Suiten (durch : getrennte Liste), die das Niveau ersetzen. |
SSL Labs Test
Testen Sie Ihre Konfiguration über Qualys SSL Labs. Eine gut eingestellte BunkerWeb-Konfiguration erreicht in der Regel A+.
Veraltete Protokolle
SSLv3, TLSv1.0 und TLSv1.1 sind standardmäßig deaktiviert (bekannte Schwachstellen). Aktivieren Sie diese nur bei Bedarf für ältere Clients.
Beispiele
LISTEN_HTTPS: "yes"
SSL_PROTOCOLS: "TLSv1.2 TLSv1.3"
SSL_CIPHERS_LEVEL: "modern"
AUTO_REDIRECT_HTTP_TO_HTTPS: "yes"
REDIRECT_HTTP_TO_HTTPS: "no"
LISTEN_HTTPS: "yes"
SSL_PROTOCOLS: "TLSv1.3"
SSL_CIPHERS_LEVEL: "modern"
AUTO_REDIRECT_HTTP_TO_HTTPS: "yes"
REDIRECT_HTTP_TO_HTTPS: "yes"
LISTEN_HTTPS: "yes"
SSL_PROTOCOLS: "TLSv1.2 TLSv1.3"
SSL_CIPHERS_LEVEL: "old"
AUTO_REDIRECT_HTTP_TO_HTTPS: "no"
LISTEN_HTTPS: "yes"
SSL_PROTOCOLS: "TLSv1.2 TLSv1.3"
SSL_CIPHERS_CUSTOM: "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305"
AUTO_REDIRECT_HTTP_TO_HTTPS: "yes"
Security.txt
STREAM-Unterstützung
Das Security.txt-Plugin implementiert den Security.txt-Standard (RFC 9116) für Ihre Website. Diese Funktion erleichtert Sicherheitsforschern den Zugriff auf Ihre Sicherheitsrichtlinien und bietet eine standardisierte Möglichkeit, Sicherheitslücken zu melden, die sie in Ihren Systemen entdecken.
So funktioniert es:
- Nach der Aktivierung erstellt BunkerWeb eine
/.well-known/security.txt
-Datei im Stammverzeichnis Ihrer Website. - Diese Datei enthält Informationen zu Ihren Sicherheitsrichtlinien, Kontakten und anderen relevanten Details.
- Sicherheitsforscher und automatisierte Tools können diese Datei leicht am Standardort finden.
- Der Inhalt wird über einfache Einstellungen konfiguriert, mit denen Sie Kontaktinformationen, Verschlüsselungsschlüssel, Richtlinien und Danksagungen angeben können.
- BunkerWeb formatiert die Datei automatisch gemäß RFC 9116.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Security.txt-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Setzen Sie die Einstellung
USE_SECURITYTXT
aufyes
, um die security.txt-Datei zu aktivieren. - Kontaktinformationen konfigurieren: Geben Sie mindestens eine Kontaktmethode mit der Einstellung
SECURITYTXT_CONTACT
an. - Zusätzliche Informationen festlegen: Konfigurieren Sie optionale Felder wie Ablaufdatum, Verschlüsselung, Danksagungen und Richtlinien-URLs.
- Lassen Sie BunkerWeb den Rest erledigen: Nach der Konfiguration erstellt und stellt BunkerWeb die security.txt-Datei automatisch am Standardort bereit.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_SECURITYTXT |
no |
multisite | nein | Security.txt aktivieren: Auf yes setzen, um die security.txt-Datei zu aktivieren. |
SECURITYTXT_URI |
/.well-known/security.txt |
multisite | nein | Security.txt-URI: Gibt die URI an, unter der die security.txt-Datei zugänglich sein wird. |
SECURITYTXT_CONTACT |
multisite | ja | Kontaktinformationen: Wie Sicherheitsforscher Sie kontaktieren können (z. B. mailto:security@example.com ). |
|
SECURITYTXT_EXPIRES |
multisite | nein | Ablaufdatum: Wann diese security.txt-Datei als abgelaufen betrachtet werden soll (ISO 8601-Format). | |
SECURITYTXT_ENCRYPTION |
multisite | ja | Verschlüsselung: URL, die auf Verschlüsselungsschlüssel für die sichere Kommunikation verweist. | |
SECURITYTXT_ACKNOWLEDGEMENTS |
multisite | ja | Danksagungen: URL, unter der Sicherheitsforscher für ihre Berichte anerkannt werden. | |
SECURITYTXT_POLICY |
multisite | ja | Sicherheitsrichtlinie: URL, die auf die Sicherheitsrichtlinie verweist, die beschreibt, wie Schwachstellen gemeldet werden. | |
SECURITYTXT_HIRING |
multisite | ja | Sicherheitsjobs: URL, die auf sicherheitsrelevante Stellenangebote verweist. | |
SECURITYTXT_CANONICAL |
multisite | ja | Kanonische URL: Die kanonische(n) URI(s) für diese security.txt-Datei. | |
SECURITYTXT_PREFERRED_LANG |
en |
multisite | nein | Bevorzugte Sprache: Die in der Kommunikation verwendete(n) Sprache(n). Angegeben als ISO 639-1-Sprachcode. |
SECURITYTXT_CSAF |
multisite | ja | CSAF: Link zur provider-metadata.json Ihres Common Security Advisory Framework-Anbieters. |
Ablaufdatum erforderlich
Gemäß RFC 9116 ist das Feld Expires
erforderlich. Wenn Sie keinen Wert für SECURITYTXT_EXPIRES
angeben, setzt BunkerWeb das Ablaufdatum automatisch auf ein Jahr ab dem aktuellen Datum.
Kontaktinformationen sind unerlässlich
Das Feld Contact
ist der wichtigste Teil der security.txt-Datei. Sie sollten mindestens eine Möglichkeit für Sicherheitsforscher angeben, Sie zu kontaktieren. Dies kann eine E-Mail-Adresse, ein Webformular, eine Telefonnummer oder eine andere Methode sein, die für Ihre Organisation funktioniert.
URLs müssen HTTPS verwenden
Gemäß RFC 9116 MÜSSEN alle URLs in der security.txt-Datei (außer mailto:
- und tel:
-Links) HTTPS verwenden. Nicht-HTTPS-URLs werden von BunkerWeb automatisch in HTTPS konvertiert, um die Einhaltung des Standards zu gewährleisten.
Beispielkonfigurationen
Eine minimale Konfiguration mit nur Kontaktinformationen:
USE_SECURITYTXT: "yes"
SECURITYTXT_CONTACT: "mailto:security@example.com"
SECURITYTXT_POLICY: "https://example.com/security-policy"
Eine vollständigere Konfiguration mit allen Feldern:
USE_SECURITYTXT: "yes"
SECURITYTXT_CONTACT: "mailto:security@example.com"
SECURITYTXT_CONTACT_2: "https://example.com/security-contact-form"
SECURITYTXT_EXPIRES: "2023-12-31T23:59:59+00:00"
SECURITYTXT_ENCRYPTION: "https://example.com/pgp-key.txt"
SECURITYTXT_ACKNOWLEDGEMENTS: "https://example.com/hall-of-fame"
SECURITYTXT_POLICY: "https://example.com/security-policy"
SECURITYTXT_HIRING: "https://example.com/jobs/security"
SECURITYTXT_CANONICAL: "https://example.com/.well-known/security.txt"
SECURITYTXT_PREFERRED_LANG: "en"
SECURITYTXT_CSAF: "https://example.com/provider-metadata.json"
Konfiguration mit mehreren Kontaktmethoden:
USE_SECURITYTXT: "yes"
SECURITYTXT_CONTACT: "mailto:security@example.com"
SECURITYTXT_CONTACT_2: "tel:+1-201-555-0123"
SECURITYTXT_CONTACT_3: "https://example.com/security-form"
SECURITYTXT_POLICY: "https://example.com/security-policy"
SECURITYTXT_EXPIRES: "2024-06-30T23:59:59+00:00"
Self-signed certificate
STREAM-Unterstützung
Das Plugin "Selbstsigniertes Zertifikat" generiert und verwaltet automatisch SSL/TLS-Zertifikate direkt in BunkerWeb, um HTTPS ohne externe Zertifizierungsstelle zu aktivieren. Ideal für die Entwicklung, interne Netzwerke oder schnelle HTTPS-Bereitstellungen.
So funktioniert's:
- Nach der Aktivierung generiert BunkerWeb ein selbstsigniertes Zertifikat für Ihre konfigurierten Domains.
- Das Zertifikat enthält alle definierten Servernamen, um eine korrekte Validierung zu gewährleisten.
- Die Zertifikate werden sicher gespeichert und verschlüsseln den gesamten HTTPS-Verkehr.
- Die Verlängerung erfolgt automatisch vor dem Ablaufdatum.
Browser-Warnungen
Browser zeigen Sicherheitswarnungen an, da ein selbstsigniertes Zertifikat nicht von einer vertrauenswürdigen CA ausgestellt wurde. Verwenden Sie in der Produktion vorzugsweise Let's Encrypt.
Verwendung
- Aktivieren:
GENERATE_SELF_SIGNED_SSL: yes
. - Algorithmus: Wählen Sie über
SELF_SIGNED_SSL_ALGORITHM
. - Gültigkeit: Dauer in Tagen über
SELF_SIGNED_SSL_EXPIRY
. - Betreff: Betrefffeld über
SELF_SIGNED_SSL_SUBJ
.
Stream-Modus
Im Stream-Modus konfigurieren Sie LISTEN_STREAM_PORT_SSL
, um den SSL/TLS-Listening-Port zu definieren.
Parameter
Parameter | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
GENERATE_SELF_SIGNED_SSL |
no |
Multisite | nein | Aktiviert die automatische Generierung selbstsignierter Zertifikate. |
SELF_SIGNED_SSL_ALGORITHM |
ec-prime256v1 |
Multisite | nein | Algorithmus: ec-prime256v1 , ec-secp384r1 , rsa-2048 , rsa-4096 . |
SELF_SIGNED_SSL_EXPIRY |
365 |
Multisite | nein | Gültigkeit (Tage). |
SELF_SIGNED_SSL_SUBJ |
/CN=www.example.com/ |
Multisite | nein | Betreff des Zertifikats (identifiziert die Domain). |
Beispiele
GENERATE_SELF_SIGNED_SSL: "yes"
SELF_SIGNED_SSL_ALGORITHM: "ec-prime256v1"
SELF_SIGNED_SSL_EXPIRY: "365"
SELF_SIGNED_SSL_SUBJ: "/CN=mysite.local/"
GENERATE_SELF_SIGNED_SSL: "yes"
SELF_SIGNED_SSL_ALGORITHM: "ec-prime256v1"
SELF_SIGNED_SSL_EXPIRY: "90"
SELF_SIGNED_SSL_SUBJ: "/CN=dev.example.com/"
SERVER_NAME: "test.example.com"
GENERATE_SELF_SIGNED_SSL: "yes"
SELF_SIGNED_SSL_ALGORITHM: "rsa-4096"
SELF_SIGNED_SSL_EXPIRY: "365"
SELF_SIGNED_SSL_SUBJ: "/CN=test.example.com/"
Sessions
STREAM-Unterstützung
Das Sessions-Plugin bietet eine robuste HTTP-Sitzungsverwaltung für BunkerWeb und ermöglicht eine sichere und zuverlässige Verfolgung von Benutzersitzungen über Anfragen hinweg. Diese Kernfunktion ist unerlässlich für die Aufrechterhaltung des Benutzerstatus, die Persistenz der Authentifizierung und die Unterstützung anderer Funktionen, die eine Kontinuität der Identität erfordern, wie z. B. der Anti-Bot-Schutz und Benutzerauthentifizierungssysteme.
So funktioniert es:
- Wenn ein Benutzer zum ersten Mal mit Ihrer Website interagiert, erstellt BunkerWeb eine eindeutige Sitzungs-ID.
- Diese ID wird sicher in einem Cookie im Browser des Benutzers gespeichert.
- Bei nachfolgenden Anfragen ruft BunkerWeb die Sitzungs-ID aus dem Cookie ab und verwendet sie, um auf die Sitzungsdaten des Benutzers zuzugreifen.
- Sitzungsdaten können lokal oder in Redis für verteilte Umgebungen mit mehreren BunkerWeb-Instanzen gespeichert werden.
- Sitzungen werden automatisch mit konfigurierbaren Zeitüberschreitungen verwaltet, um die Sicherheit bei gleichzeitiger Benutzerfreundlichkeit zu gewährleisten.
- Die kryptografische Sicherheit von Sitzungen wird durch einen geheimen Schlüssel gewährleistet, der zum Signieren von Sitzungs-Cookies verwendet wird.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Sessions-Funktion zu konfigurieren und zu verwenden:
- Sitzungssicherheit konfigurieren: Legen Sie einen starken, eindeutigen
SESSIONS_SECRET
fest, um sicherzustellen, dass Sitzungs-Cookies nicht gefälscht werden können. (Der Standardwert ist "random", wodurch BunkerWeb einen zufälligen geheimen Schlüssel generiert.) - Sitzungsnamen wählen: Passen Sie optional den
SESSIONS_NAME
an, um zu definieren, wie Ihr Sitzungs-Cookie im Browser heißen soll. (Der Standardwert ist "random", wodurch BunkerWeb einen zufälligen Namen generiert.) - Sitzungs-Timeouts festlegen: Konfigurieren Sie mit den Timeout-Einstellungen (
SESSIONS_IDLING_TIMEOUT
,SESSIONS_ROLLING_TIMEOUT
,SESSIONS_ABSOLUTE_TIMEOUT
), wie lange Sitzungen gültig bleiben. - Redis-Integration konfigurieren: Setzen Sie für verteilte Umgebungen
USE_REDIS
auf "yes" und konfigurieren Sie Ihre Redis-Verbindung, um Sitzungsdaten über mehrere BunkerWeb-Knoten hinweg zu teilen. - Lassen Sie BunkerWeb den Rest erledigen: Nach der Konfiguration erfolgt die Sitzungsverwaltung für Ihre Website automatisch.
Konfigurationseinstellungen
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
SESSIONS_SECRET |
random |
global | nein | Sitzungsgeheimnis: Kryptografischer Schlüssel zum Signieren von Sitzungs-Cookies. Sollte eine starke, zufällige Zeichenfolge sein, die für Ihre Website eindeutig ist. |
SESSIONS_NAME |
random |
global | nein | Cookie-Name: Der Name des Cookies, in dem die Sitzungs-ID gespeichert wird. |
SESSIONS_IDLING_TIMEOUT |
1800 |
global | nein | Leerlauf-Timeout: Maximale Zeit (in Sekunden) der Inaktivität, bevor die Sitzung ungültig wird. |
SESSIONS_ROLLING_TIMEOUT |
3600 |
global | nein | Rollierendes Timeout: Maximale Zeit (in Sekunden), bevor eine Sitzung erneuert werden muss. |
SESSIONS_ABSOLUTE_TIMEOUT |
86400 |
global | nein | Absolutes Timeout: Maximale Zeit (in Sekunden), bevor eine Sitzung unabhängig von der Aktivität zerstört wird. |
SESSIONS_CHECK_IP |
yes |
global | nein | IP prüfen: Wenn auf yes gesetzt, wird die Sitzung zerstört, wenn sich die IP-Adresse des Clients ändert. |
SESSIONS_CHECK_USER_AGENT |
yes |
global | nein | User-Agent prüfen: Wenn auf yes gesetzt, wird die Sitzung zerstört, wenn sich der User-Agent des Clients ändert. |
Sicherheitshinweise
Die Einstellung SESSIONS_SECRET
ist für die Sicherheit von entscheidender Bedeutung. In Produktionsumgebungen:
- Verwenden Sie einen starken, zufälligen Wert (mindestens 32 Zeichen)
- Halten Sie diesen Wert vertraulich
- Verwenden Sie denselben Wert für alle BunkerWeb-Instanzen in einem Cluster
- Erwägen Sie die Verwendung von Umgebungsvariablen oder Geheimnisverwaltung, um die Speicherung im Klartext zu vermeiden
Cluster-Umgebungen
Wenn Sie mehrere BunkerWeb-Instanzen hinter einem Load Balancer betreiben:
- Setzen Sie
USE_REDIS
aufyes
und konfigurieren Sie Ihre Redis-Verbindung - Stellen Sie sicher, dass alle Instanzen genau denselben
SESSIONS_SECRET
undSESSIONS_NAME
verwenden - Dies stellt sicher, dass Benutzer ihre Sitzung beibehalten, unabhängig davon, welche BunkerWeb-Instanz ihre Anfragen bearbeitet
Beispielkonfigurationen
Eine einfache Konfiguration für eine einzelne BunkerWeb-Instanz:
SESSIONS_SECRET: "ihr-starker-zufälliger-geheimschlüssel-hier"
SESSIONS_NAME: "meineappsitzung"
SESSIONS_IDLING_TIMEOUT: "1800"
SESSIONS_ROLLING_TIMEOUT: "3600"
SESSIONS_ABSOLUTE_TIMEOUT: "86400"
Konfiguration mit erhöhten Sicherheitseinstellungen:
SESSIONS_SECRET: "ihr-sehr-starker-zufälliger-geheimschlüssel-hier"
SESSIONS_NAME: "sicheresitzung"
SESSIONS_IDLING_TIMEOUT: "900" # 15 Minuten
SESSIONS_ROLLING_TIMEOUT: "1800" # 30 Minuten
SESSIONS_ABSOLUTE_TIMEOUT: "43200" # 12 Stunden
SESSIONS_CHECK_IP: "yes"
SESSIONS_CHECK_USER_AGENT: "yes"
Konfiguration für mehrere BunkerWeb-Instanzen, die Sitzungsdaten gemeinsam nutzen:
SESSIONS_SECRET: "ihr-starker-zufälliger-geheimschlüssel-hier"
SESSIONS_NAME: "clustersitzung"
SESSIONS_IDLING_TIMEOUT: "1800"
SESSIONS_ROLLING_TIMEOUT: "3600"
SESSIONS_ABSOLUTE_TIMEOUT: "86400"
USE_REDIS: "yes"
# Stellen Sie sicher, dass die Redis-Verbindung korrekt konfiguriert ist
Konfiguration für Anwendungen, die eine erweiterte Sitzungspersistenz erfordern:
SESSIONS_SECRET: "ihr-starker-zufälliger-geheimschlüssel-hier"
SESSIONS_NAME: "persistentesitzung"
SESSIONS_IDLING_TIMEOUT: "86400" # 1 Tag
SESSIONS_ROLLING_TIMEOUT: "172800" # 2 Tage
SESSIONS_ABSOLUTE_TIMEOUT: "604800" # 7 Tage
UI
STREAM-Unterstützung
Integrate easily the BunkerWeb UI.
Einstellung | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_UI |
no |
multisite | nein | Use UI |
UI_HOST |
global | nein | Address of the web UI used for initial setup |
User Manager
(PRO)
STREAM-Unterstützung
Add the possibility to manage users on the web interface
Einstellung | Standardwert | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USERS_REQUIRE_2FA |
no |
global | nein | Require two-factor authentication for all users |
Whitelist
STREAM-Unterstützung
Das Whitelist-Plugin ermöglicht es Ihnen, eine Liste vertrauenswürdiger IP-Adressen zu definieren, die andere Sicherheitsfilter umgehen. Um stattdessen unerwünschte Clients zu blockieren, lesen Sie das Blacklist-Plugin.
Das Whitelist-Plugin bietet einen umfassenden Ansatz, um den Zugriff auf Ihre Website basierend auf verschiedenen Client-Attributen explizit zu erlauben. Diese Funktion bietet einen Sicherheitsmechanismus: Besuchern, die bestimmte Kriterien erfüllen, wird sofortiger Zugriff gewährt, während alle anderen reguläre Sicherheitsprüfungen durchlaufen müssen.
So funktioniert es:
- Sie definieren Kriterien für Besucher, die auf die "Whitelist" gesetzt werden sollen (IP-Adressen, Netzwerke, rDNS, ASN, User-Agent oder URI-Muster).
- Wenn ein Besucher versucht, auf Ihre Website zuzugreifen, prüft BunkerWeb, ob er einem dieser Whitelist-Kriterien entspricht.
- Wenn ein Besucher einer Whitelist-Regel entspricht (und keiner Ignorier-Regel), wird ihm der Zugriff auf Ihre Website gewährt und er umgeht alle anderen Sicherheitsprüfungen.
- Wenn ein Besucher keinem Whitelist-Kriterium entspricht, durchläuft er wie gewohnt alle normalen Sicherheitsprüfungen.
- Whitelists können in regelmäßigen Abständen automatisch aus externen Quellen aktualisiert werden.
Wie man es benutzt
Führen Sie die folgenden Schritte aus, um die Whitelist-Funktion zu konfigurieren und zu verwenden:
- Aktivieren Sie die Funktion: Die Whitelist-Funktion ist standardmäßig deaktiviert. Setzen Sie die Einstellung
USE_WHITELIST
aufyes
, um sie zu aktivieren. - Erlaubnisregeln konfigurieren: Definieren Sie, welche IPs, Netzwerke, rDNS-Muster, ASNs, User-Agents oder URIs auf die Whitelist gesetzt werden sollen.
- Ignorierregeln einrichten: Geben Sie alle Ausnahmen an, die die Whitelist-Prüfungen umgehen sollen.
- Externe Quellen hinzufügen: Konfigurieren Sie URLs zum automatischen Herunterladen und Aktualisieren von Whitelist-Daten.
- Zugriff überwachen: Überprüfen Sie die Web-Benutzeroberfläche, um zu sehen, welchen Besuchern der Zugriff gewährt oder verweigert wird.
Stream-Modus
Im Stream-Modus werden nur IP-, rDNS- und ASN-Prüfungen durchgeführt.
Konfigurationseinstellungen
Allgemein
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
USE_WHITELIST |
no |
multisite | nein | Whitelist aktivieren: Auf yes setzen, um die Whitelist-Funktion zu aktivieren. |
Was dies bewirkt: Setzt Besucher basierend auf ihrer IP-Adresse oder ihrem Netzwerk auf die Whitelist. Diese Besucher umgehen alle Sicherheitsprüfungen.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
WHITELIST_IP |
multisite | nein | IP-Whitelist: Liste von IP-Adressen oder Netzwerken (CIDR-Notation), die erlaubt werden sollen, getrennt durch Leerzeichen. | |
WHITELIST_IGNORE_IP |
multisite | nein | IP-Ignorierliste: Liste von IP-Adressen oder Netzwerken, die IP-Whitelist-Prüfungen umgehen sollen. | |
WHITELIST_IP_URLS |
multisite | nein | IP-Whitelist-URLs: Liste von URLs, die IP-Adressen oder Netzwerke enthalten, die auf die Whitelist gesetzt werden sollen, getrennt durch Leerzeichen. | |
WHITELIST_IGNORE_IP_URLS |
multisite | nein | IP-Ignorierlisten-URLs: Liste von URLs, die IP-Adressen oder Netzwerke enthalten, die ignoriert werden sollen. |
Was dies bewirkt: Setzt Besucher basierend auf ihrem Domainnamen (in umgekehrter Reihenfolge) auf die Whitelist. Dies ist nützlich, um Besuchern von bestimmten Organisationen oder Netzwerken den Zugriff nach ihrer Domain zu ermöglichen.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
WHITELIST_RDNS |
multisite | nein | rDNS-Whitelist: Liste von Reverse-DNS-Suffixen, die erlaubt werden sollen, getrennt durch Leerzeichen. | |
WHITELIST_RDNS_GLOBAL |
yes |
multisite | nein | Nur globales rDNS: Führt rDNS-Whitelist-Prüfungen nur für globale IP-Adressen durch, wenn auf yes gesetzt. |
WHITELIST_IGNORE_RDNS |
multisite | nein | rDNS-Ignorierliste: Liste von Reverse-DNS-Suffixen, die rDNS-Whitelist-Prüfungen umgehen sollen. | |
WHITELIST_RDNS_URLS |
multisite | nein | rDNS-Whitelist-URLs: Liste von URLs, die Reverse-DNS-Suffixe enthalten, die auf die Whitelist gesetzt werden sollen, getrennt durch Leerzeichen. | |
WHITELIST_IGNORE_RDNS_URLS |
multisite | nein | rDNS-Ignorierlisten-URLs: Liste von URLs, die Reverse-DNS-Suffixe enthalten, die ignoriert werden sollen. |
Was dies bewirkt: Setzt Besucher von bestimmten Netzwerkanbietern mithilfe von Autonomen Systemnummern auf die Whitelist. ASNs identifizieren, zu welchem Anbieter oder welcher Organisation eine IP gehört.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
WHITELIST_ASN |
multisite | nein | ASN-Whitelist: Liste von Autonomen Systemnummern, die erlaubt werden sollen, getrennt durch Leerzeichen. | |
WHITELIST_IGNORE_ASN |
multisite | nein | ASN-Ignorierliste: Liste von ASNs, die ASN-Whitelist-Prüfungen umgehen sollen. | |
WHITELIST_ASN_URLS |
multisite | nein | ASN-Whitelist-URLs: Liste von URLs, die ASNs enthalten, die auf die Whitelist gesetzt werden sollen, getrennt durch Leerzeichen. | |
WHITELIST_IGNORE_ASN_URLS |
multisite | nein | ASN-Ignorierlisten-URLs: Liste von URLs, die ASNs enthalten, die ignoriert werden sollen. |
Was dies bewirkt: Setzt Besucher basierend darauf auf die Whitelist, welchen Browser oder welches Tool sie angeben zu verwenden. Dies ist effektiv, um den Zugriff auf bestimmte bekannte Tools oder Dienste zu ermöglichen.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
WHITELIST_USER_AGENT |
multisite | nein | User-Agent-Whitelist: Liste von User-Agent-Mustern (PCRE-Regex), die erlaubt werden sollen, getrennt durch Leerzeichen. | |
WHITELIST_IGNORE_USER_AGENT |
multisite | nein | User-Agent-Ignorierliste: Liste von User-Agent-Mustern, die User-Agent-Whitelist-Prüfungen umgehen sollen. | |
WHITELIST_USER_AGENT_URLS |
multisite | nein | User-Agent-Whitelist-URLs: Liste von URLs, die User-Agent-Muster enthalten, die auf die Whitelist gesetzt werden sollen. | |
WHITELIST_IGNORE_USER_AGENT_URLS |
multisite | nein | User-Agent-Ignorierlisten-URLs: Liste von URLs, die User-Agent-Muster enthalten, die ignoriert werden sollen. |
Was dies bewirkt: Setzt Anfragen an bestimmte URLs auf Ihrer Website auf die Whitelist. Dies ist hilfreich, um den Zugriff auf bestimmte Endpunkte unabhängig von anderen Faktoren zu ermöglichen.
Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
---|---|---|---|---|
WHITELIST_URI |
multisite | nein | URI-Whitelist: Liste von URI-Mustern (PCRE-Regex), die erlaubt werden sollen, getrennt durch Leerzeichen. | |
WHITELIST_IGNORE_URI |
multisite | nein | URI-Ignorierliste: Liste von URI-Mustern, die URI-Whitelist-Prüfungen umgehen sollen. | |
WHITELIST_URI_URLS |
multisite | nein | URI-Whitelist-URLs: Liste von URLs, die URI-Muster enthalten, die auf die Whitelist gesetzt werden sollen, getrennt durch Leerzeichen. | |
WHITELIST_IGNORE_URI_URLS |
multisite | nein | URI-Ignorierlisten-URLs: Liste von URLs, die URI-Muster enthalten, die ignoriert werden sollen. |
Unterstützung von URL-Formaten
Alle *_URLS
-Einstellungen unterstützen HTTP/HTTPS-URLs sowie lokale Dateipfade mit dem Präfix file:///
. Die Basisauthentifizierung wird im Format http://user:pass@url
unterstützt.
Regelmäßige Aktualisierungen
Whitelists von URLs werden stündlich automatisch heruntergeladen und aktualisiert, um sicherzustellen, dass Ihr Schutz mit den neuesten vertrauenswürdigen Quellen auf dem neuesten Stand bleibt.
Sicherheitsumgehung
Auf der Whitelist stehende Besucher umgehen vollständig alle anderen Sicherheitsprüfungen in BunkerWeb, einschließlich WAF-Regeln, Ratenbegrenzung, Erkennung bösartiger Bots und aller anderen Sicherheitsmechanismen. Verwenden Sie die Whitelist nur für vertrauenswürdige Quellen, bei denen Sie absolut sicher sind.
Beispielkonfigurationen
Eine einfache Konfiguration, die die IP-Adressen des Unternehmensbüros auf die Whitelist setzt:
USE_WHITELIST: "yes"
WHITELIST_IP: "192.168.1.0/24 10.0.0.0/8 203.0.113.42"
Eine umfassendere Konfiguration mit mehreren Whitelist-Kriterien:
USE_WHITELIST: "yes"
# Unternehmens- und vertrauenswürdige Partner-Assets
WHITELIST_IP: "192.168.1.0/24 203.0.113.0/24"
WHITELIST_RDNS: ".company.com .partner-company.org"
WHITELIST_ASN: "12345 67890" # ASNs von Unternehmen und Partnern
WHITELIST_USER_AGENT: "(?:\b)CompanyBot(?:\b) (?:\b)PartnerCrawler(?:\b)"
# Externe vertrauenswürdige Quellen
WHITELIST_IP_URLS: "https://example.com/trusted-networks.txt"
WHITELIST_USER_AGENT_URLS: "https://example.com/trusted-crawlers.txt"
Konfiguration mit lokalen Dateien für Whitelists:
USE_WHITELIST: "yes"
WHITELIST_IP_URLS: "file:///path/to/ip-whitelist.txt"
WHITELIST_RDNS_URLS: "file:///path/to/rdns-whitelist.txt"
WHITELIST_ASN_URLS: "file:///path/to/asn-whitelist.txt"
WHITELIST_USER_AGENT_URLS: "file:///path/to/user-agent-whitelist.txt"
WHITELIST_URI_URLS: "file:///path/to/uri-whitelist.txt"
Eine Konfiguration, die sich darauf konzentriert, den Zugriff nur auf bestimmte API-Endpunkte zu ermöglichen:
USE_WHITELIST: "yes"
WHITELIST_URI: "^/api/v1/public/ ^/api/v1/status"
WHITELIST_IP: "192.168.1.0/24" # Internes Netzwerk für alle Endpunkte
Eine Konfiguration, die gängige Suchmaschinen- und Social-Media-Crawler auf die Whitelist setzt:
USE_WHITELIST: "yes"
# Verifizierung mit Reverse DNS für zusätzliche Sicherheit
WHITELIST_RDNS: ".googlebot.com .search.msn.com .crawl.yahoo.net .yandex.com .baidu.com .facebook.com"
WHITELIST_RDNS_GLOBAL: "yes" # Nur globale IPs prüfen
Diese Konfiguration ermöglicht es legitimen Crawlern, Ihre Website zu indizieren, ohne Ratenbegrenzungen oder anderen Sicherheitsmaßnahmen unterworfen zu sein, die sie blockieren könnten. Die rDNS-Prüfungen helfen zu überprüfen, ob die Crawler tatsächlich von den von ihnen angegebenen Unternehmen stammen.