Fortgeschrittene Nutzungen
Viele Beispiele für reale Anwendungsfälle sind im Ordner examples des GitHub-Repositorys verfügbar.
Wir stellen auch zahlreiche Boilerplates zur Verfügung, wie z. B. YAML-Dateien für verschiedene Integrationen und Datenbanktypen. Diese sind im Ordner misc/integrations verfügbar.
Dieser Abschnitt konzentriert sich nur auf fortgeschrittene Nutzungen und Sicherheits-Tuning. Informationen zu allen verfügbaren Einstellungen finden Sie im Features-Abschnitt der Dokumentation.
Anwendungsfälle
Testen
Um schnelle Tests durchzuführen, wenn der Multisite-Modus aktiviert ist (und wenn Sie nicht die richtigen DNS-Einträge für die Domains eingerichtet haben), können Sie curl mit dem HTTP-Host-Header Ihrer Wahl verwenden:
curl -H "Host: app1.example.com" http://ip-oder-fqdn-des-servers
Wenn Sie HTTPS verwenden, müssen Sie mit SNI spielen:
curl -H "Host: app1.example.com" --resolve example.com:443:ip-des-servers https://example.com
Hinter einem Load Balancer oder Reverse Proxy
Echte IP
Wenn BunkerWeb selbst hinter einem Load Balancer oder einem Reverse Proxy steht, müssen Sie es so konfigurieren, dass es die echte IP-Adresse der Clients erhält. Wenn Sie dies nicht tun, werden die Sicherheitsfunktionen die IP-Adresse des Load Balancers oder Reverse Proxys anstelle der des Clients blockieren.
BunkerWeb unterstützt tatsächlich zwei Methoden, um die echte IP-Adresse des Clients abzurufen:
- Verwendung des
PROXY-Protokolls - Verwendung eines HTTP-Headers wie
X-Forwarded-For
Die folgenden Einstellungen können verwendet werden:
USE_REAL_IP: Aktivieren/Deaktivieren des Abrufs der echten IPUSE_PROXY_PROTOCOL: Aktivieren/Deaktivieren der Unterstützung des PROXY-Protokolls.REAL_IP_FROM: Liste der vertrauenswürdigen IP-/Netzwerkadressen, die uns die "echte IP" senden dürfenREAL_IP_HEADER: Der HTTP-Header, der die echte IP enthält, oder der spezielle Wertproxy_protocolbei Verwendung des PROXY-Protokolls
Weitere Einstellungen zur echten IP finden Sie im Features-Abschnitt der Dokumentation.
Wir gehen von Folgendem bezüglich der Load Balancer oder Reverse Proxys aus (Sie müssen die Einstellungen entsprechend Ihrer Konfiguration anpassen):
- Sie verwenden den
X-Forwarded-For-Header, um die echte IP festzulegen - Sie haben IPs in den Netzwerken
1.2.3.0/24und100.64.0.0/10
Navigieren Sie zur Seite Globale Konfiguration, wählen Sie das Plugin Real IP und füllen Sie die folgenden Einstellungen aus:
Bitte beachten Sie, dass es empfohlen wird, BunkerWeb neu zu starten, wenn Sie Einstellungen im Zusammenhang mit der echten IP ändern.
Sie müssen die Einstellungen zur Datei /etc/bunkerweb/variables.env hinzufügen:
...
USE_REAL_IP=yes
REAL_IP_FROM=1.2.3.0/24 100.64.0.0/16
REAL_IP_HEADER=X-Forwarded-For
...
Bitte beachten Sie, dass es empfohlen wird, einen Neustart anstelle eines Neuladens durchzuführen, wenn Sie Einstellungen im Zusammenhang mit der echten IP konfigurieren:
sudo systemctl restart bunkerweb && \
sudo systemctl restart bunkerweb-scheduler
Sie müssen die Einstellungen zu den Umgebungsvariablen hinzufügen, wenn Sie den All-in-one-Container ausführen:
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-e USE_REAL_IP="yes" \
-e REAL_IP_FROM="1.2.3.0/24 100.64.0.0/10" \
-e REAL_IP_HEADER="X-Forwarded-For" \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:1.6.5
Bitte beachten Sie, dass Sie, wenn Ihr Container bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen aktualisiert werden.
Sie müssen die Einstellungen zu den Umgebungsvariablen sowohl des BunkerWeb- als auch des Scheduler-Containers hinzufügen:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
...
environment:
USE_REAL_IP: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "X-Forwarded-For"
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
...
environment:
USE_REAL_IP: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "X-Forwarded-For"
...
Bitte beachten Sie, dass Sie, wenn Ihr Container bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen aktualisiert werden.
Sie müssen die Einstellungen zu den Umgebungsvariablen sowohl des BunkerWeb- als auch des Scheduler-Containers hinzufügen:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
...
environment:
USE_REAL_IP: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "X-Forwarded-For"
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
...
environment:
USE_REAL_IP: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "X-Forwarded-For"
...
Bitte beachten Sie, dass Sie, wenn Ihr Container bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen aktualisiert werden.
Sie müssen die Einstellungen zu den Umgebungsvariablen sowohl der BunkerWeb- als auch der Scheduler-Pods hinzufügen.
Hier ist der entsprechende Teil Ihrer values.yaml-Datei, den Sie verwenden können:
bunkerweb:
extraEnvs:
- name: USE_REAL_IP
value: "yes"
- name: REAL_IP_FROM
value: "1.2.3.0/24 100.64.0.0/10"
- name: REAL_IP_HEADER
value: "X-Forwarded-For"
scheduler:
extraEnvs:
- name: USE_REAL_IP
value: "yes"
- name: REAL_IP_FROM
value: "1.2.3.0/24 100.64.0.0/10"
- name: REAL_IP_HEADER
value: "X-Forwarded-For"
Veraltet
Die Swarm-Integration ist veraltet und wird in einer zukünftigen Version entfernt. Bitte erwägen Sie stattdessen die Verwendung der Kubernetes-Integration.
Weitere Informationen finden Sie in der Swarm-Integrationsdokumentation.
Sie müssen die Einstellungen zu den Umgebungsvariablen sowohl der BunkerWeb- als auch der Scheduler-Dienste hinzufügen:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
...
environment:
USE_REAL_IP: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "X-Forwarded-For"
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
...
environment:
USE_REAL_IP: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "X-Forwarded-For"
...
Bitte beachten Sie, dass Sie, wenn Ihr Dienst bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen aktualisiert werden.
Sorgfältig lesen
Verwenden Sie das PROXY-Protokoll nur, wenn Sie sicher sind, dass Ihr Load Balancer oder Reverse Proxy es sendet. Wenn Sie es aktivieren und es nicht verwendet wird, erhalten Sie Fehler.
Wir gehen von Folgendem bezüglich der Load Balancer oder Reverse Proxys aus (Sie müssen die Einstellungen entsprechend Ihrer Konfiguration anpassen):
- Sie verwenden das
PROXY-Protokollv1 oder v2, um die echte IP festzulegen - Sie haben IPs in den Netzwerken
1.2.3.0/24und100.64.0.0/10
Navigieren Sie zur Seite Globale Konfiguration, wählen Sie das Plugin Real IP und füllen Sie die folgenden Einstellungen aus:
Bitte beachten Sie, dass es empfohlen wird, BunkerWeb neu zu starten, wenn Sie Einstellungen im Zusammenhang mit der echten IP ändern.
Sie müssen die Einstellungen zur Datei /etc/bunkerweb/variables.env hinzufügen:
...
USE_REAL_IP=yes
USE_PROXY_PROTOCOL=yes
REAL_IP_FROM=1.2.3.0/24 100.64.0.0/16
REAL_IP_HEADER=proxy_protocol
...
Bitte beachten Sie, dass es empfohlen wird, einen Neustart anstelle eines Neuladens durchzuführen, wenn Sie Einstellungen im Zusammenhang mit Proxy-Protokollen konfigurieren:
sudo systemctl restart bunkerweb && \
sudo systemctl restart bunkerweb-scheduler
Sie müssen die Einstellungen zu den Umgebungsvariablen hinzufügen, wenn Sie den All-in-one-Container ausführen:
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-e USE_REAL_IP="yes" \
-e USE_PROXY_PROTOCOL="yes" \
-e REAL_IP_FROM="1.2.3.0/24 100.64.0.0/10" \
-e REAL_IP_HEADER="proxy_protocol" \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:1.6.5
Bitte beachten Sie, dass Sie, wenn Ihr Container bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen aktualisiert werden.
Sie müssen die Einstellungen zu den Umgebungsvariablen sowohl des BunkerWeb- als auch des Scheduler-Containers hinzufügen:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
...
environment:
USE_REAL_IP: "yes"
USE_PROXY_PROTOCOL: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "proxy_protocol"
...
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
...
environment:
USE_REAL_IP: "yes"
USE_PROXY_PROTOCOL: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "proxy_protocol"
...
Bitte beachten Sie, dass Sie, wenn Ihr Container bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen aktualisiert werden.
Sie müssen die Einstellungen zu den Umgebungsvariablen sowohl des BunkerWeb- als auch des Scheduler-Containers hinzufügen:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
...
environment:
USE_REAL_IP: "yes"
USE_PROXY_PROTOCOL: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "proxy_protocol"
...
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
...
environment:
USE_REAL_IP: "yes"
USE_PROXY_PROTOCOL: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "proxy_protocol"
...
Bitte beachten Sie, dass Sie, wenn Ihr Container bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen aktualisiert werden.
Sie müssen die Einstellungen zu den Umgebungsvariablen sowohl der BunkerWeb- als auch der Scheduler-Pods hinzufügen.
Hier ist der entsprechende Teil Ihrer values.yaml-Datei, den Sie verwenden können:
bunkerweb:
extraEnvs:
- name: USE_REAL_IP
value: "yes"
- name: USE_PROXY_PROTOCOL
value: "yes"
- name: REAL_IP_FROM
value: "1.2.3.0/24 100.64.0.0/10"
- name: REAL_IP_HEADER
value: "proxy_protocol"
scheduler:
extraEnvs:
- name: USE_REAL_IP
value: "yes"
- name: USE_PROXY_PROTOCOL
value: "yes"
- name: REAL_IP_FROM
value: "1.2.3.0/24 100.64.0.0/10"
- name: REAL_IP_HEADER
value: "proxy_protocol"
Veraltet
Die Swarm-Integration ist veraltet und wird in einer zukünftigen Version entfernt. Bitte erwägen Sie stattdessen die Verwendung der Kubernetes-Integration.
Weitere Informationen finden Sie in der Swarm-Integrationsdokumentation.
Sie müssen die Einstellungen zu den Umgebungsvariablen sowohl der BunkerWeb- als auch der Scheduler-Dienste hinzufügen.
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
...
environment:
USE_REAL_IP: "yes"
USE_PROXY_PROTOCOL: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "proxy_protocol"
...
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
...
environment:
USE_REAL_IP: "yes"
USE_PROXY_PROTOCOL: "yes"
REAL_IP_FROM: "1.2.3.0/24 100.64.0.0/10"
REAL_IP_HEADER: "proxy_protocol"
...
Bitte beachten Sie, dass Sie, wenn Ihr Dienst bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen aktualisiert werden.
Verwendung benutzerdefinierter DNS-Auflösungsmechanismen
BunkerWebs NGINX-Konfiguration kann angepasst werden, um je nach Ihren Bedürfnissen unterschiedliche DNS-Resolver zu verwenden. Dies kann in verschiedenen Szenarien besonders nützlich sein:
- Um Einträge in Ihrer lokalen
/etc/hosts-Datei zu berücksichtigen - Wenn Sie für bestimmte Domains benutzerdefinierte DNS-Server verwenden müssen
- Zur Integration mit lokalen DNS-Caching-Lösungen
Verwendung von systemd-resolved
Viele moderne Linux-Systeme verwenden systemd-resolved für die DNS-Auflösung. Wenn Sie möchten, dass BunkerWeb den Inhalt Ihrer /etc/hosts-Datei respektiert und den DNS-Auflösungsmechanismus des Systems verwendet, können Sie es so konfigurieren, dass es den lokalen systemd-resolved DNS-Dienst verwendet.
Um zu überprüfen, ob systemd-resolved auf Ihrem System läuft, können Sie Folgendes verwenden:
systemctl status systemd-resolved
Um systemd-resolved als Ihren DNS-Resolver in BunkerWeb zu aktivieren, setzen Sie die Einstellung DNS_RESOLVERS auf 127.0.0.53, was die Standard-Listenadresse für systemd-resolved ist:
Navigieren Sie zur Seite Globale Konfiguration und setzen Sie die DNS-Resolver auf 127.0.0.53
Sie müssen die Datei /etc/bunkerweb/variables.env ändern:
...
DNS_RESOLVERS=127.0.0.53
...
Nach dieser Änderung laden Sie den Scheduler neu, um die Konfiguration anzuwenden:
sudo systemctl reload bunkerweb-scheduler
Verwendung von dnsmasq
dnsmasq ist ein leichtgewichtiger DNS-, DHCP- und TFTP-Server, der häufig für lokales DNS-Caching und Anpassungen verwendet wird. Er ist besonders nützlich, wenn Sie mehr Kontrolle über Ihre DNS-Auflösung benötigen, als systemd-resolved bietet.
Installieren und konfigurieren Sie zuerst dnsmasq auf Ihrem Linux-System:
# dnsmasq installieren
sudo apt-get update && sudo apt-get install dnsmasq
# dnsmasq so konfigurieren, dass es nur auf localhost lauscht
echo "listen-address=127.0.0.1" | sudo tee -a /etc/dnsmasq.conf
echo "bind-interfaces" | sudo tee -a /etc/dnsmasq.conf
# Bei Bedarf benutzerdefinierte DNS-Einträge hinzufügen
echo "address=/custom.example.com/192.168.1.10" | sudo tee -a /etc/dnsmasq.conf
# dnsmasq neu starten
sudo systemctl restart dnsmasq
sudo systemctl enable dnsmasq
# dnsmasq installieren
sudo dnf install dnsmasq
# dnsmasq so konfigurieren, dass es nur auf localhost lauscht
echo "listen-address=127.0.0.1" | sudo tee -a /etc/dnsmasq.conf
echo "bind-interfaces" | sudo tee -a /etc/dnsmasq.conf
# Bei Bedarf benutzerdefinierte DNS-Einträge hinzufügen
echo "address=/custom.example.com/192.168.1.10" | sudo tee -a /etc/dnsmasq.conf
# dnsmasq neu starten
sudo systemctl restart dnsmasq
sudo systemctl enable dnsmasq
Konfigurieren Sie dann BunkerWeb, um dnsmasq zu verwenden, indem Sie DNS_RESOLVERS auf 127.0.0.1 setzen:
Navigieren Sie zur Seite Globale Konfiguration, wählen Sie das NGINX-Plugin und setzen Sie die DNS-Resolver auf 127.0.0.1.
Sie müssen die Datei /etc/bunkerweb/variables.env ändern:
...
DNS_RESOLVERS=127.0.0.1
...
Nach dieser Änderung laden Sie den Scheduler neu:
sudo systemctl reload bunkerweb-scheduler
Wenn Sie den All-in-one-Container verwenden, führen Sie dnsmasq in einem separaten Container aus und konfigurieren Sie BunkerWeb, um ihn zu verwenden:
# Ein benutzerdefiniertes Netzwerk für die DNS-Kommunikation erstellen
docker network create bw-dns
# dnsmasq-Container mit dockurr/dnsmasq und Quad9 DNS ausführen
# Quad9 bietet sicherheitsorientierte DNS-Auflösung mit Malware-Blockierung
docker run -d \
--name dnsmasq \
--network bw-dns \
-e DNS1="9.9.9.9" \
-e DNS2="149.112.112.112" \
-p 53:53/udp \
-p 53:53/tcp \
--cap-add=NET_ADMIN \
--restart=always \
dockurr/dnsmasq
# BunkerWeb All-in-one mit dnsmasq DNS-Resolver ausführen
docker run -d \
--name bunkerweb-aio \
--network bw-dns \
-v bw-storage:/data \
-e DNS_RESOLVERS="dnsmasq" \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:1.6.5
Fügen Sie einen dnsmasq-Dienst zu Ihrer docker-compose-Datei hinzu und konfigurieren Sie BunkerWeb, um ihn zu verwenden:
services:
dnsmasq:
image: dockurr/dnsmasq
container_name: dnsmasq
environment:
# Verwendung von Quad9 DNS-Servern für verbesserte Sicherheit und Datenschutz
# Primär: 9.9.9.9 (Quad9 mit Malware-Blockierung)
# Sekundär: 149.112.112.112 (Quad9 Backup-Server)
DNS1: "9.9.9.9"
DNS2: "149.112.112.112"
ports:
- 53:53/udp
- 53:53/tcp
cap_add:
- NET_ADMIN
restart: always
networks:
- bw-dns
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
...
environment:
DNS_RESOLVERS: "dnsmasq"
...
networks:
- bw-universe
- bw-services
- bw-dns
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
...
environment:
DNS_RESOLVERS: "dnsmasq"
...
networks:
- bw-universe
- bw-dns
networks:
# ...vorhandene Netzwerke...
bw-dns:
name: bw-dns
Benutzerdefinierte Konfigurationen
Um benutzerdefinierte Konfigurationen zu BunkerWeb hinzuzufügen und anzupassen, können Sie die NGINX-Grundlage nutzen. Benutzerdefinierte NGINX-Konfigurationen können in verschiedenen NGINX-Kontexten hinzugefügt werden, einschließlich Konfigurationen für die ModSecurity Web Application Firewall (WAF), die eine Kernkomponente von BunkerWeb ist. Weitere Details zu ModSecurity-Konfigurationen finden Sie hier.
Hier sind die verfügbaren Typen von benutzerdefinierten Konfigurationen:
- http: Konfigurationen auf der HTTP-Ebene von NGINX.
- server-http: Konfigurationen auf der HTTP/Server-Ebene von NGINX.
- default-server-http: Konfigurationen auf der Server-Ebene von NGINX, speziell für den "default server", wenn der angegebene Client-Name mit keinem Servernamen in
SERVER_NAMEübereinstimmt. - modsec-crs: Konfigurationen, die angewendet werden, bevor das OWASP Core Rule Set geladen wird.
- modsec: Konfigurationen, die angewendet werden, nachdem das OWASP Core Rule Set geladen wurde, oder die verwendet werden, wenn das Core Rule Set nicht geladen ist.
- crs-plugins-before: Konfigurationen für die CRS-Plugins, die angewendet werden, bevor die CRS-Plugins geladen werden.
- crs-plugins-after: Konfigurationen für die CRS-Plugins, die angewendet werden, nachdem die CRS-Plugins geladen wurden.
- stream: Konfigurationen auf der Stream-Ebene von NGINX.
- server-stream: Konfigurationen auf der Stream/Server-Ebene von NGINX.
Benutzerdefinierte Konfigurationen können global oder spezifisch für einen bestimmten Server angewendet werden, abhängig vom anwendbaren Kontext und ob der Multisite-Modus aktiviert ist.
Die Methode zum Anwenden benutzerdefinierter Konfigurationen hängt von der verwendeten Integration ab. Der zugrunde liegende Prozess besteht jedoch darin, Dateien mit der .conf-Endung zu bestimmten Ordnern hinzuzufügen. Um eine benutzerdefinierte Konfiguration für einen bestimmten Server anzuwenden, sollte die Datei in einem Unterordner platziert werden, der nach dem primären Servernamen benannt ist.
Einige Integrationen bieten bequemere Möglichkeiten zum Anwenden von Konfigurationen, wie z. B. die Verwendung von Configs in Docker Swarm oder ConfigMap in Kubernetes. Diese Optionen bieten einfachere Ansätze zur Verwaltung und Anwendung von Konfigurationen.
Navigieren Sie zur Seite Konfigurationen, klicken Sie auf Neue benutzerdefinierte Konfiguration erstellen, Sie können dann wählen, ob es sich um eine globale oder eine für einen Dienst spezifische Konfiguration handelt, den Konfigurationstyp und den Konfigurationsnamen:
Vergessen Sie nicht, auf die Schaltfläche 💾 Speichern zu klicken.
Bei Verwendung der Linux-Integration müssen benutzerdefinierte Konfigurationen in den Ordner /etc/bunkerweb/configs geschrieben werden.
Hier ist ein Beispiel für server-http/hello-world.conf:
location /hello {
default_type 'text/plain';
content_by_lua_block {
ngx.say('world')
}
}
Da BunkerWeb als unprivilegierter Benutzer (nginx:nginx) läuft, müssen Sie die Berechtigungen bearbeiten:
chown -R root:nginx /etc/bunkerweb/configs && \
chmod -R 770 /etc/bunkerweb/configs
Überprüfen wir nun den Status des Schedulers:
systemctl status bunkerweb-scheduler
Wenn er bereits läuft, können wir ihn neu laden:
systemctl reload bunkerweb-scheduler
Andernfalls müssen wir ihn starten:
systemctl start bunkerweb-scheduler
Bei Verwendung des All-in-one-Images haben Sie zwei Möglichkeiten, benutzerdefinierte Konfigurationen hinzuzufügen:
- Verwendung spezifischer Einstellungen
*_CUSTOM_CONF_*als Umgebungsvariablen beim Ausführen des Containers (empfohlen). - Schreiben von
.conf-Dateien in das Verzeichnis/data/configs/innerhalb des an/datagemounteten Volumes.
Verwendung von Einstellungen (Umgebungsvariablen)
Die zu verwendenden Einstellungen müssen dem Muster <SITE>_CUSTOM_CONF_<TYPE>_<NAME> folgen:
<SITE>: Optionaler primärer Servername, wenn der Multisite-Modus aktiviert ist und die Konfiguration auf einen bestimmten Dienst angewendet werden soll.<TYPE>: Der Typ der Konfiguration, akzeptierte Werte sindHTTP,DEFAULT_SERVER_HTTP,SERVER_HTTP,MODSEC,MODSEC_CRS,CRS_PLUGINS_BEFORE,CRS_PLUGINS_AFTER,STREAMundSERVER_STREAM.<NAME>: Der Name der Konfiguration ohne die.conf-Endung.
Hier ist ein Dummy-Beispiel beim Ausführen des All-in-one-Containers:
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-e "CUSTOM_CONF_SERVER_HTTP_hello-world=location /hello { \
default_type 'text/plain'; \
content_by_lua_block { \
ngx.say('world'); \
} \
}" \
-p 80:8080/tcp \
-p 443:8443/tcp \
bunkerity/bunkerweb-all-in-one:1.6.5
Bitte beachten Sie, dass Sie, wenn Ihr Container bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen angewendet werden.
Verwendung von Dateien
Als Erstes müssen Sie die Ordner erstellen:
mkdir -p ./bw-data/configs/server-http
Sie können nun Ihre Konfigurationen schreiben:
echo "location /hello {
default_type 'text/plain';
content_by_lua_block {
ngx.say('world')
}
}" > ./bw-data/configs/server-http/hello-world.conf
Da der Scheduler als unprivilegierter Benutzer mit UID und GID 101 läuft, müssen Sie die Berechtigungen bearbeiten:
chown -R root:101 bw-data && \
chmod -R 770 bw-data
Beim Starten des Scheduler-Containers müssen Sie den Ordner an /data mounten:
docker run -d \
--name bunkerweb-aio \
-v ./bw-data:/data \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:1.6.5
Bei Verwendung der Docker-Integration haben Sie zwei Möglichkeiten, benutzerdefinierte Konfigurationen hinzuzufügen:
- Verwendung spezifischer Einstellungen
*_CUSTOM_CONF_*als Umgebungsvariablen (empfohlen) - Schreiben von
.conf-Dateien in das an/datades Schedulers gemountete Volume
Verwendung von Einstellungen
Die zu verwendenden Einstellungen müssen dem Muster <SITE>_CUSTOM_CONF_<TYPE>_<NAME> folgen:
<SITE>: Optionaler primärer Servername, wenn der Multisite-Modus aktiviert ist und die Konfiguration auf einen bestimmten Dienst angewendet werden soll<TYPE>: Der Typ der Konfiguration, akzeptierte Werte sindHTTP,DEFAULT_SERVER_HTTP,SERVER_HTTP,MODSEC,MODSEC_CRS,CRS_PLUGINS_BEFORE,CRS_PLUGINS_AFTER,STREAMundSERVER_STREAM<NAME>: Der Name der Konfiguration ohne die.conf-Endung
Hier ist ein Dummy-Beispiel mit einer docker-compose-Datei:
...
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
environment:
- |
CUSTOM_CONF_SERVER_HTTP_hello-world=
location /hello {
default_type 'text/plain';
content_by_lua_block {
ngx.say('world')
}
}
...
Verwendung von Dateien
Als Erstes müssen Sie die Ordner erstellen:
mkdir -p ./bw-data/configs/server-http
Sie können nun Ihre Konfigurationen schreiben:
echo "location /hello {
default_type 'text/plain';
content_by_lua_block {
ngx.say('world')
}
}" > ./bw-data/configs/server-http/hello-world.conf
Da der Scheduler als unprivilegierter Benutzer mit UID und GID 101 läuft, müssen Sie die Berechtigungen bearbeiten:
chown -R root:101 bw-data && \
chmod -R 770 bw-data
Beim Starten des Scheduler-Containers müssen Sie den Ordner an /data mounten:
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
volumes:
- ./bw-data:/data
...
Bei Verwendung der Docker-Autoconf-Integration haben Sie zwei Möglichkeiten, benutzerdefinierte Konfigurationen hinzuzufügen:
- Verwendung spezifischer Einstellungen
*_CUSTOM_CONF_*als Labels (am einfachsten) - Schreiben von
.conf-Dateien in das an/datades Schedulers gemountete Volume
Verwendung von Labels
Einschränkungen bei der Verwendung von Labels
Bei der Verwendung von Labels mit der Docker-Autoconf-Integration können Sie nur benutzerdefinierte Konfigurationen für den entsprechenden Webdienst anwenden. Das Anwenden von http-, default-server-http-, stream- oder globalen Konfigurationen (wie server-http oder server-stream für alle Dienste) ist nicht möglich: Dafür müssen Sie Dateien mounten.
Die zu verwendenden Labels müssen dem Muster bunkerweb.CUSTOM_CONF_<TYPE>_<NAME> folgen:
<TYPE>: Der Typ der Konfiguration, akzeptierte Werte sindSERVER_HTTP,MODSEC,MODSEC_CRS,CRS_PLUGINS_BEFORE,CRS_PLUGINS_AFTERundSERVER_STREAM<NAME>: Der Name der Konfiguration ohne die.conf-Endung
Hier ist ein Dummy-Beispiel mit einer docker-compose-Datei:
myapp:
image: nginxdemos/nginx-hello
labels:
- |
bunkerweb.CUSTOM_CONF_SERVER_HTTP_hello-world=
location /hello {
default_type 'text/plain';
content_by_lua_block {
ngx.say('world')
}
}
...
Verwendung von Dateien
Als Erstes müssen Sie die Ordner erstellen:
mkdir -p ./bw-data/configs/server-http
Sie können nun Ihre Konfigurationen schreiben:
echo "location /hello {
default_type 'text/plain';
content_by_lua_block {
ngx.say('world')
}
}" > ./bw-data/configs/server-http/hello-world.conf
Da der Scheduler als unprivilegierter Benutzer mit UID und GID 101 läuft, müssen Sie die Berechtigungen bearbeiten:
chown -R root:101 bw-data && \
chmod -R 770 bw-data
Beim Starten des Scheduler-Containers müssen Sie den Ordner an /data mounten:
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
volumes:
- ./bw-data:/data
...
Bei Verwendung der Kubernetes-Integration werden benutzerdefinierte Konfigurationen über ConfigMap verwaltet.
Um es einfach zu halten, müssen Sie die ConfigMap nicht einmal mit einem Pod verwenden (z. B. als Umgebungsvariable oder Volume): Der Autoconf-Pod lauscht auf ConfigMap-Ereignisse und aktualisiert die benutzerdefinierten Konfigurationen bei Bedarf.
Beim Erstellen einer ConfigMap müssen Sie spezielle Labels hinzufügen:
- bunkerweb.io/CONFIG_TYPE: Muss auf einen gültigen Typ für benutzerdefinierte Konfigurationen gesetzt werden (http, server-http, default-server-http, modsec, modsec-crs, crs-plugins-before, crs-plugins-after, stream oder server-stream)
- bunkerweb.io/CONFIG_SITE: Auf einen Servernamen setzen, um die Konfiguration auf diesen spezifischen Server anzuwenden (optional, wird global angewendet, wenn nicht gesetzt)
Hier ist das Beispiel:
apiVersion: v1
kind: ConfigMap
metadata:
name: cfg-bunkerweb-all-server-http
annotations:
bunkerweb.io/CONFIG_TYPE: "server-http"
data:
myconf: |
location /hello {
default_type 'text/plain';
content_by_lua_block {
ngx.say('world')
}
}
Benutzerdefinierte zusätzliche Konfiguration
Seit Version 1.6.0 können Sie Einstellungen über die Annotation bunkerweb.io/CONFIG_TYPE=settings hinzufügen/überschreiben. Hier ist ein Beispiel:
apiVersion: v1
kind: ConfigMap
metadata:
name: cfg-bunkerweb-extra-settings
annotations:
bunkerweb.io/CONFIG_TYPE: "settings"
data:
USE_ANTIBOT: "captcha" # Multisite-Einstellung, die auf alle Dienste angewendet wird, die sie nicht überschreiben
USE_REDIS: "yes" # Globale Einstellung, die global angewendet wird
...
Veraltet
Die Swarm-Integration ist veraltet und wird in einer zukünftigen Version entfernt. Bitte erwägen Sie stattdessen die Verwendung der Kubernetes-Integration.
Weitere Informationen finden Sie in der Swarm-Integrationsdokumentation.
Bei Verwendung der Swarm-Integration werden benutzerdefinierte Konfigurationen über Docker Configs verwaltet.
Um es einfach zu halten, müssen Sie die Config nicht einmal an einen Dienst anhängen: Der Autoconf-Dienst lauscht auf Config-Ereignisse und aktualisiert die benutzerdefinierten Konfigurationen bei Bedarf.
Beim Erstellen einer Config müssen Sie spezielle Labels hinzufügen:
- bunkerweb.CONFIG_TYPE: Muss auf einen gültigen Typ für benutzerdefinierte Konfigurationen gesetzt werden (http, server-http, default-server-http, modsec, modsec-crs, crs-plugins-before, crs-plugins-after, stream oder server-stream)
- bunkerweb.CONFIG_SITE: Auf einen Servernamen setzen, um die Konfiguration auf diesen spezifischen Server anzuwenden (optional, wird global angewendet, wenn nicht gesetzt)
Hier ist das Beispiel:
echo "location /hello {
default_type 'text/plain';
content_by_lua_block {
ngx.say('world')
}
}" | docker config create -l bunkerweb.CONFIG_TYPE=server-http my-config -
Es gibt keinen Aktualisierungsmechanismus: Die Alternative besteht darin, eine vorhandene Konfiguration mit docker config rm zu entfernen und sie dann neu zu erstellen.
Viele Dienste in der Produktion betreiben
Globales CRS
CRS-Plugins
Wenn das CRS global geladen wird, werden CRS-Plugins nicht unterstützt. Wenn Sie sie verwenden müssen, müssen Sie das CRS pro Dienst laden.
Wenn Sie BunkerWeb in der Produktion mit einer großen Anzahl von Diensten verwenden und die ModSecurity-Funktion global mit CRS-Regeln aktivieren, kann die zum Laden der BunkerWeb-Konfigurationen erforderliche Zeit zu lang werden, was möglicherweise zu einem Timeout führt.
Die Problemumgehung besteht darin, die CRS-Regeln global anstatt pro Dienst zu laden. Dieses Verhalten ist aus Gründen der Abwärtskompatibilität standardmäßig nicht aktiviert und weil es einen Nachteil hat: Wenn Sie das globale Laden von CRS-Regeln aktivieren, ist es nicht mehr möglich, modsec-crs-Regeln (die vor den CRS-Regeln ausgeführt werden) pro Dienst zu definieren. Diese Einschränkung kann jedoch umgangen werden, indem globale modsec-crs-Ausschlussregeln wie diese geschrieben werden:
SecRule REQUEST_FILENAME "@rx ^/somewhere$" "nolog,phase:4,allow,id:1010,chain"
SecRule REQUEST_HEADERS:Host "@rx ^app1\.example\.com$" "nolog"
Sie können das globale Laden von CRS-Regeln aktivieren, indem Sie USE_MODSECURITY_GLOBAL_CRS auf yes setzen.
max_allowed_packet für MariaDB/MySQL anpassen
Es scheint, dass der Standardwert für den Parameter max_allowed_packet in MariaDB- und MySQL-Datenbankservern nicht ausreicht, wenn BunkerWeb mit einer großen Anzahl von Diensten verwendet wird.
Wenn Sie Fehler wie diesen feststellen, insbesondere auf dem Scheduler:
[Warning] Aborted connection 5 to db: 'db' user: 'bunkerweb' host: '172.20.0.4' (Got a packet bigger than 'max_allowed_packet' bytes)
Sie müssen den max_allowed_packet auf Ihrem Datenbankserver erhöhen.
Persistenz von Sperren und Berichten
Standardmäßig speichert BunkerWeb Sperren und Berichte in einem lokalen Lua-Datenspeicher. Obwohl dies einfach und effizient ist, bedeutet diese Einrichtung, dass Daten verloren gehen, wenn die Instanz neu gestartet wird. Um sicherzustellen, dass Sperren und Berichte über Neustarts hinweg bestehen bleiben, können Sie BunkerWeb so konfigurieren, dass ein entfernter Redis- oder Valkey-Server verwendet wird.
Warum Redis/Valkey verwenden?
Redis und Valkey sind leistungsstarke In-Memory-Datenspeicher, die häufig als Datenbanken, Caches und Message Broker verwendet werden. Sie sind hoch skalierbar und unterstützen eine Vielzahl von Datenstrukturen, darunter:
- Strings: Grundlegende Schlüssel-Wert-Paare.
- Hashes: Feld-Wert-Paare innerhalb eines einzelnen Schlüssels.
- Listen: Geordnete Sammlungen von Zeichenketten.
- Mengen: Ungeordnete Sammlungen von eindeutigen Zeichenketten.
- Sortierte Mengen: Geordnete Sammlungen mit Bewertungen.
Durch die Nutzung von Redis oder Valkey kann BunkerWeb Sperren, Berichte und Cache-Daten dauerhaft speichern und so Haltbarkeit und Skalierbarkeit gewährleisten.
Aktivieren der Redis/Valkey-Unterstützung
Um die Unterstützung für Redis oder Valkey zu aktivieren, konfigurieren Sie die folgenden Einstellungen in Ihrer BunkerWeb-Konfigurationsdatei:
# Redis/Valkey-Unterstützung aktivieren
USE_REDIS=yes
# Redis/Valkey-Server-Hostname oder IP-Adresse
REDIS_HOST=<hostname>
# Redis/Valkey-Server-Portnummer (Standard: 6379)
REDIS_PORT=6379
# Redis/Valkey-Datenbanknummer (Standard: 0)
REDIS_DATABASE=0
USE_REDIS: Aufyessetzen, um die Redis/Valkey-Integration zu aktivieren.REDIS_HOST: Geben Sie den Hostnamen oder die IP-Adresse des Redis/Valkey-Servers an.REDIS_PORT: Geben Sie die Portnummer für den Redis/Valkey-Server an. Standard ist6379.REDIS_DATABASE: Geben Sie die zu verwendende Redis/Valkey-Datenbanknummer an. Standard ist0.
Wenn Sie erweiterte Einstellungen wie Authentifizierung, SSL/TLS-Unterstützung oder den Sentinel-Modus benötigen, finden Sie detaillierte Anleitungen in der Dokumentation zu den Redis-Plugin-Einstellungen.
UDP/TCP-Anwendungen schützen
Experimentelles Feature
Dieses Feature ist nicht produktionsreif. Fühlen Sie sich frei, es zu testen und uns Fehler über Issues im GitHub-Repository zu melden.
BunkerWeb bietet die Möglichkeit, als generischer UDP/TCP-Reverse-Proxy zu fungieren, sodass Sie alle netzwerkbasierten Anwendungen schützen können, die mindestens auf Schicht 4 des OSI-Modells arbeiten. Anstelle des "klassischen" HTTP-Moduls verwendet BunkerWeb das Stream-Modul von NGINX.
Es ist wichtig zu beachten, dass nicht alle Einstellungen und Sicherheitsfunktionen bei Verwendung des Stream-Moduls verfügbar sind. Weitere Informationen hierzu finden Sie in den Features-Abschnitten der Dokumentation.
Die Konfiguration eines einfachen Reverse-Proxys ist der HTTP-Einrichtung sehr ähnlich, da dieselben Einstellungen verwendet werden: USE_REVERSE_PROXY=yes und REVERSE_PROXY_HOST=myapp:9000. Selbst wenn BunkerWeb hinter einem Load Balancer positioniert ist, bleiben die Einstellungen gleich (wobei das PROXY-Protokoll aus offensichtlichen Gründen die unterstützte Option ist).
Darüber hinaus werden die folgenden spezifischen Einstellungen verwendet:
SERVER_TYPE=stream: aktiviert denstream-Modus (generisches UDP/TCP) anstelle deshttp-Modus (Standard)LISTEN_STREAM_PORT=4242: der lauschende "einfache" (ohne SSL/TLS) Port, auf dem BunkerWeb lauschen wirdLISTEN_STREAM_PORT_SSL=4343: der lauschende "ssl/tls"-Port, auf dem BunkerWeb lauschen wirdUSE_UDP=no: lauscht auf UDP-Pakete und leitet sie anstelle von TCP weiter
Eine vollständige Liste der Einstellungen für den stream-Modus finden Sie im Abschnitt Features der Dokumentation.
mehrere lauschende Ports
Seit Version 1.6.0 unterstützt BunkerWeb mehrere lauschende Ports für den stream-Modus. Sie können sie mit den Einstellungen LISTEN_STREAM_PORT und LISTEN_STREAM_PORT_SSL angeben.
Hier ist ein Beispiel:
...
LISTEN_STREAM_PORT=4242
LISTEN_STREAM_PORT_SSL=4343
LISTEN_STREAM_PORT_1=4244
LISTEN_STREAM_PORT_SSL_1=4344
...
Sie müssen die Einstellungen zu den Umgebungsvariablen hinzufügen, wenn Sie den All-in-one-Container ausführen. Sie müssen auch die Stream-Ports freigeben.
Dieses Beispiel konfiguriert BunkerWeb, um zwei Stream-basierte Anwendungen, app1.example.com und app2.example.com, zu proxieren.
docker run -d \
--name bunkerweb-aio \
-v bw-storage:/data \
-e SERVICE_UI="no" \
-e SERVER_NAME="app1.example.com app2.example.com" \
-e MULTISITE="yes" \
-e USE_REVERSE_PROXY="yes" \
-e SERVER_TYPE="stream" \
-e app1.example.com_REVERSE_PROXY_HOST="myapp1:9000" \
-e app1.example.com_LISTEN_STREAM_PORT="10000" \
-e app2.example.com_REVERSE_PROXY_HOST="myapp2:9000" \
-e app2.example.com_LISTEN_STREAM_PORT="20000" \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
-p 10000:10000/tcp \
-p 20000:20000/tcp \
bunkerity/bunkerweb-all-in-one:1.6.5
Bitte beachten Sie, dass Sie, wenn Ihr Container bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen angewendet werden.
Ihre Anwendungen (myapp1, myapp2) sollten in separaten Containern laufen (oder anderweitig erreichbar sein) und ihre Hostnamen/IPs (z. B. myapp1, myapp2, die in _REVERSE_PROXY_HOST verwendet werden) müssen vom bunkerweb-aio-Container aus auflösbar und erreichbar sein. Dies geschieht typischerweise, indem sie mit einem gemeinsamen Docker-Netzwerk verbunden werden.
UI-Dienst deaktivieren
Es wird empfohlen, den UI-Dienst zu deaktivieren (z. B. durch Setzen von SERVICE_UI=no als Umgebungsvariable), da die Web-UI nicht mit SERVER_TYPE=stream kompatibel ist.
Bei Verwendung der Docker-Integration ist der einfachste Weg, bestehende Netzwerkanwendungen zu schützen, die Dienste zum bw-services-Netzwerk hinzuzufügen:
x-bw-api-env: &bw-api-env
# Wir verwenden einen Anker, um die Wiederholung derselben Einstellungen für alle Dienste zu vermeiden
API_WHITELIST_IP: "127.0.0.0/8 10.20.30.0/24"
# Optionaler API-Token für authentifizierte API-Aufrufe
API_TOKEN: ""
services:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
ports:
- "80:8080" # Behalten, wenn Sie die Let's Encrypt-Automatisierung mit dem http-Challenge-Typ verwenden möchten
- "10000:10000" # app1
- "20000:20000" # app2
labels:
- "bunkerweb.INSTANCE=yes"
environment:
<<: *bw-api-env
restart: "unless-stopped"
networks:
- bw-universe
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
environment:
<<: *bw-api-env
BUNKERWEB_INSTANCES: "bunkerweb" # Diese Einstellung ist obligatorisch, um die BunkerWeb-Instanz anzugeben
SERVER_NAME: "app1.example.com app2.example.com"
MULTISITE: "yes"
USE_REVERSE_PROXY: "yes" # Wird auf alle Dienste angewendet
SERVER_TYPE: "stream" # Wird auf alle Dienste angewendet
app1.example.com_REVERSE_PROXY_HOST: "myapp1:9000"
app1.example.com_LISTEN_STREAM_PORT: "10000"
app2.example.com_REVERSE_PROXY_HOST: "myapp2:9000"
app2.example.com_LISTEN_STREAM_PORT: "20000"
volumes:
- bw-storage:/data # Wird verwendet, um den Cache und andere Daten wie Backups zu persistieren
restart: "unless-stopped"
networks:
- bw-universe
myapp1:
image: istio/tcp-echo-server:1.3
command: [ "9000", "app1" ]
networks:
- bw-services
myapp2:
image: istio/tcp-echo-server:1.3
command: [ "9000", "app2" ]
networks:
- bw-services
volumes:
bw-storage:
networks:
bw-universe:
name: bw-universe
ipam:
driver: default
config:
- subnet: 10.20.30.0/24
bw-services:
name: bw-services
Bevor Sie den Docker-Autoconf-Integrations-Stack auf Ihrer Maschine ausführen, müssen Sie die Ports bearbeiten:
services:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
ports:
- "80:8080" # Behalten, wenn Sie die Let's Encrypt-Automatisierung mit dem http-Challenge-Typ verwenden möchten
- "10000:10000" # app1
- "20000:20000" # app2
...
Sobald der Stack läuft, können Sie Ihre bestehenden Anwendungen mit dem bw-services-Netzwerk verbinden und BunkerWeb mit Labels konfigurieren:
services:
myapp1:
image: istio/tcp-echo-server:1.3
command: [ "9000", "app1" ]
networks:
- bw-services
labels:
- "bunkerweb.SERVER_NAME=app1.example.com"
- "bunkerweb.SERVER_TYPE=stream"
- "bunkerweb.USE_REVERSE_PROXY=yes"
- "bunkerweb.REVERSE_PROXY_HOST=myapp1:9000"
- "bunkerweb.LISTEN_STREAM_PORT=10000"
myapp2:
image: istio/tcp-echo-server:1.3
command: [ "9000", "app2" ]
networks:
- bw-services
labels:
- "bunkerweb.SERVER_NAME=app2.example.com"
- "bunkerweb.SERVER_TYPE=stream"
- "bunkerweb.USE_REVERSE_PROXY=yes"
- "bunkerweb.REVERSE_PROXY_HOST=myapp2:9000"
- "bunkerweb.LISTEN_STREAM_PORT=20000"
networks:
bw-services:
external: true
name: bw-services
Experimentelles Feature
Im Moment unterstützen Ingresses den stream-Modus nicht. Was wir hier tun, ist ein Workaround, um es zum Laufen zu bringen.
Fühlen Sie sich frei, es zu testen und uns Fehler über Issues im GitHub-Repository zu melden.
Bevor Sie den Kubernetes-Integrations-Stack auf Ihrer Maschine ausführen, müssen Sie die Ports an Ihrem Load Balancer öffnen:
apiVersion: v1
kind: Service
metadata:
name: lb
spec:
type: LoadBalancer
ports:
- name: http # Behalten, wenn Sie die Let's Encrypt-Automatisierung mit dem http-Challenge-Typ verwenden möchten
port: 80
targetPort: 8080
- name: app1
port: 10000
targetPort: 10000
- name: app2
port: 20000
targetPort: 20000
selector:
app: bunkerweb
Sobald der Stack läuft, können Sie Ihre Ingress-Ressourcen erstellen:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress
namespace: services
annotations:
bunkerweb.io/SERVER_TYPE: "stream" # Wird auf alle Dienste angewendet
bunkerweb.io/app1.example.com_LISTEN_STREAM_PORT: "10000"
bunkerweb.io/app2.example.com_LISTEN_STREAM_PORT: "20000"
spec:
rules:
- host: app1.example.com
http:
paths:
- path: / # Wird im Stream-Modus nicht verwendet, ist aber erforderlich
pathType: Prefix
backend:
service:
name: svc-app1
port:
number: 9000
- host: app2.example.com
http:
paths:
- path: / # Wird im Stream-Modus nicht verwendet, ist aber erforderlich
pathType: Prefix
backend:
service:
name: svc-app2
port:
number: 9000
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: app1
namespace: services
labels:
app: app1
spec:
replicas: 1
selector:
matchLabels:
app: app1
template:
metadata:
labels:
app: app1
spec:
containers:
- name: app1
image: istio/tcp-echo-server:1.3
args: ["9000", "app1"]
ports:
- containerPort: 9000
---
apiVersion: v1
kind: Service
metadata:
name: svc-app1
namespace: services
spec:
selector:
app: app1
ports:
- protocol: TCP
port: 9000
targetPort: 9000
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: app2
namespace: services
labels:
app: app2
spec:
replicas: 1
selector:
matchLabels:
app: app2
template:
metadata:
labels:
app: app2
spec:
containers:
- name: app2
image: istio/tcp-echo-server:1.3
args: ["9000", "app2"]
ports:
- containerPort: 9000
---
apiVersion: v1
kind: Service
metadata:
name: svc-app2
namespace: services
spec:
selector:
app: app2
ports:
- protocol: TCP
port: 9000
targetPort: 9000
Sie müssen die Einstellungen zur Datei /etc/bunkerweb/variables.env hinzufügen:
...
SERVER_NAME=app1.example.com app2.example.com
MULTISITE=yes
USE_REVERSE_PROXY=yes
SERVER_TYPE=stream
app1.example.com_REVERSE_PROXY_HOST=myapp1.domain.or.ip:9000
app1.example.com_LISTEN_STREAM_PORT=10000
app2.example.com_REVERSE_PROXY_HOST=myapp2.domain.or.ip:9000
app2.example.com_LISTEN_STREAM_PORT=20000
...
Überprüfen wir nun den Status des Schedulers:
systemctl status bunkerweb-scheduler
Wenn er bereits läuft, können wir ihn neu laden:
systemctl reload bunkerweb-scheduler
Andernfalls müssen wir ihn starten:
systemctl start bunkerweb-scheduler
Veraltet
Die Swarm-Integration ist veraltet und wird in einer zukünftigen Version entfernt. Bitte erwägen Sie stattdessen die Verwendung der Kubernetes-Integration.
Weitere Informationen finden Sie in der Swarm-Integrationsdokumentation.
Bevor Sie den Swarm-Integrations-Stack auf Ihrer Maschine ausführen, müssen Sie die Ports bearbeiten:
services:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
ports:
# Behalten, wenn Sie die Let's Encrypt-Automatisierung mit dem http-Challenge-Typ verwenden möchten
- published: 80
target: 8080
mode: host
protocol: tcp
# app1
- published: 10000
target: 10000
mode: host
protocol: tcp
# app2
- published: 20000
target: 20000
mode: host
protocol: tcp
...
Sobald der Stack läuft, können Sie Ihre bestehenden Anwendungen mit dem bw-services-Netzwerk verbinden und BunkerWeb mit Labels konfigurieren:
services:
myapp1:
image: istio/tcp-echo-server:1.3
command: [ "9000", "app1" ]
networks:
- bw-services
deploy:
placement:
constraints:
- "node.role==worker"
labels:
- "bunkerweb.SERVER_NAME=app1.example.com"
- "bunkerweb.SERVER_TYPE=stream"
- "bunkerweb.USE_REVERSE_PROXY=yes"
- "bunkerweb.REVERSE_PROXY_HOST=myapp1:9000"
- "bunkerweb.LISTEN_STREAM_PORT=10000"
myapp2:
image: istio/tcp-echo-server:1.3
command: [ "9000", "app2" ]
networks:
- bw-services
deploy:
placement:
constraints:
- "node.role==worker"
labels:
- "bunkerweb.SERVER_NAME=app2.example.com"
- "bunkerweb.SERVER_TYPE=stream"
- "bunkerweb.USE_REVERSE_PROXY=yes"
- "bunkerweb.REVERSE_PROXY_HOST=myapp2:9000"
- "bunkerweb.LISTEN_STREAM_PORT=20000"
networks:
bw-services:
external: true
name: bw-services
PHP
Experimentelles Feature
Im Moment ist die PHP-Unterstützung mit BunkerWeb noch in der Beta-Phase und wir empfehlen Ihnen, wenn möglich eine Reverse-Proxy-Architektur zu verwenden. Übrigens wird PHP für einige Integrationen wie Kubernetes überhaupt nicht unterstützt.
BunkerWeb unterstützt PHP über externe oder entfernte PHP-FPM-Instanzen. Wir gehen davon aus, dass Sie bereits mit der Verwaltung solcher Dienste vertraut sind.
Die folgenden Einstellungen können verwendet werden:
REMOTE_PHP: Hostname der entfernten PHP-FPM-Instanz.REMOTE_PHP_PATH: Stammordner mit Dateien in der entfernten PHP-FPM-Instanz.REMOTE_PHP_PORT: Port der entfernten PHP-FPM-Instanz (Standard ist 9000).LOCAL_PHP: Pfad zur lokalen Socket-Datei der PHP-FPM-Instanz.LOCAL_PHP_PATH: Stammordner mit Dateien in der lokalen PHP-FPM-Instanz.
Bei Verwendung des All-in-one-Images müssen Sie zur Unterstützung von PHP-Anwendungen Folgendes tun:
- Mounten Sie Ihre PHP-Dateien in den Ordner
/var/www/htmlvon BunkerWeb. - Richten Sie einen PHP-FPM-Container für Ihre Anwendung ein und mounten Sie den Ordner mit den PHP-Dateien.
- Verwenden Sie die spezifischen Einstellungen
REMOTE_PHPundREMOTE_PHP_PATHals Umgebungsvariablen beim Ausführen von BunkerWeb.
Wenn Sie den Multisite-Modus aktivieren, müssen Sie separate Verzeichnisse für jede Ihrer Anwendungen erstellen. Jedes Unterverzeichnis sollte nach dem ersten Wert von SERVER_NAME benannt werden. Hier ist ein Dummy-Beispiel:
www
├── app1.example.com
│ └── index.php
└── app2.example.com
└── index.php
2 Verzeichnisse, 2 Dateien
Wir gehen davon aus, dass sich Ihre PHP-Apps in einem Ordner namens www befinden. Bitte beachten Sie, dass Sie die Berechtigungen korrigieren müssen, damit BunkerWeb (UID/GID 101) zumindest Dateien lesen und Ordner auflisten kann und PHP-FPM (UID/GID 33, wenn Sie das php:fpm-Image verwenden) der Eigentümer der Dateien und Ordner ist:
chown -R 33:101 ./www && \
find ./www -type f -exec chmod 0640 {} \; && \
find ./www -type d -exec chmod 0750 {} \;
Sie können nun BunkerWeb ausführen, es für Ihre PHP-Anwendung konfigurieren und auch die PHP-Apps ausführen. Sie müssen ein benutzerdefiniertes Docker-Netzwerk erstellen, damit BunkerWeb mit Ihren PHP-FPM-Containern kommunizieren kann.
# Ein benutzerdefiniertes Netzwerk erstellen
docker network create php-network
# PHP-FPM-Container ausführen
docker run -d --name myapp1-php --network php-network -v ./www/app1.example.com:/app php:fpm
docker run -d --name myapp2-php --network php-network -v ./www/app2.example.com:/app php:fpm
# BunkerWeb All-in-one ausführen
docker run -d \
--name bunkerweb-aio \
--network php-network \
-v ./www:/var/www/html \
-v bw-storage:/data \
-e SERVER_NAME="app1.example.com app2.example.com" \
-e MULTISITE="yes" \
-e REMOTE_PHP_PATH="/app" \
-e app1.example.com_REMOTE_PHP="myapp1-php" \
-e app2.example.com_REMOTE_PHP="myapp2-php" \
-p 80:8080/tcp \
-p 443:8443/tcp \
-p 443:8443/udp \
bunkerity/bunkerweb-all-in-one:1.6.5
Bitte beachten Sie, dass Sie, wenn Ihr Container bereits erstellt wurde, ihn löschen und neu erstellen müssen, damit die neuen Umgebungsvariablen angewendet werden.
Bei Verwendung der Docker-Integration müssen Sie zur Unterstützung von PHP-Anwendungen Folgendes tun:
- Mounten Sie Ihre PHP-Dateien in den Ordner
/var/www/htmlvon BunkerWeb - Richten Sie einen PHP-FPM-Container für Ihre Anwendung ein und mounten Sie den Ordner mit den PHP-Dateien
- Verwenden Sie die spezifischen Einstellungen
REMOTE_PHPundREMOTE_PHP_PATHals Umgebungsvariablen beim Starten von BunkerWeb
Wenn Sie den Multisite-Modus aktivieren, müssen Sie separate Verzeichnisse für jede Ihrer Anwendungen erstellen. Jedes Unterverzeichnis sollte nach dem ersten Wert von SERVER_NAME benannt werden. Hier ist ein Dummy-Beispiel:
www
├── app1.example.com
│ └── index.php
├── app2.example.com
│ └── index.php
└── app3.example.com
└── index.php
3 Verzeichnisse, 3 Dateien
Wir gehen davon aus, dass sich Ihre PHP-Apps in einem Ordner namens www befinden. Bitte beachten Sie, dass Sie die Berechtigungen korrigieren müssen, damit BunkerWeb (UID/GID 101) zumindest Dateien lesen und Ordner auflisten kann und PHP-FPM (UID/GID 33, wenn Sie das php:fpm-Image verwenden) der Eigentümer der Dateien und Ordner ist:
chown -R 33:101 ./www && \
find ./www -type f -exec chmod 0640 {} \; && \
find ./www -type d -exec chmod 0750 {} \;
Sie können nun BunkerWeb ausführen, es für Ihre PHP-Anwendung konfigurieren und auch die PHP-Apps ausführen:
x-bw-api-env: &bw-api-env
# Wir verwenden einen Anker, um die Wiederholung derselben Einstellungen für alle Dienste zu vermeiden
API_WHITELIST_IP: "127.0.0.0/8 10.20.30.0/24"
services:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
ports:
- "80:8080/tcp"
- "443:8443/tcp"
- "443:8443/udp" # QUIC
environment:
<<: *bw-api-env
volumes:
- ./www:/var/www/html
restart: "unless-stopped"
networks:
- bw-universe
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
environment:
<<: *bw-api-env
BUNKERWEB_INSTANCES: "bunkerweb" # Diese Einstellung ist obligatorisch, um die BunkerWeb-Instanz anzugeben
SERVER_NAME: "app1.example.com app2.example.com"
MULTISITE: "yes"
REMOTE_PHP_PATH: "/app" # Wird dank der MULTISITE-Einstellung auf alle Dienste angewendet
app1.example.com_REMOTE_PHP: "myapp1"
app2.example.com_REMOTE_PHP: "myapp2"
app3.example.com_REMOTE_PHP: "myapp3"
volumes:
- bw-storage:/data # Wird verwendet, um den Cache und andere Daten wie Backups zu persistieren
restart: "unless-stopped"
networks:
- bw-universe
myapp1:
image: php:fpm
volumes:
- ./www/app1.example.com:/app
networks:
- bw-services
myapp2:
image: php:fpm
volumes:
- ./www/app2.example.com:/app
networks:
- bw-services
myapp3:
image: php:fpm
volumes:
- ./www/app3.example.com:/app
networks:
- bw-services
volumes:
bw-storage:
networks:
bw-universe:
name: bw-universe
ipam:
driver: default
config:
- subnet: 10.20.30.0/24
bw-services:
name: bw-services
Multisite-Modus aktiviert
Die Docker-Autoconf-Integration impliziert die Verwendung des Multisite-Modus: Das Schützen einer PHP-Anwendung ist dasselbe wie das Schützen mehrerer.
Bei Verwendung der Docker-Autoconf-Integration müssen Sie zur Unterstützung von PHP-Anwendungen Folgendes tun:
- Mounten Sie Ihre PHP-Dateien in den Ordner
/var/www/htmlvon BunkerWeb - Richten Sie PHP-FPM-Container für Ihre Anwendungen ein und mounten Sie den Ordner mit den PHP-Apps
- Verwenden Sie die spezifischen Einstellungen
REMOTE_PHPundREMOTE_PHP_PATHals Labels für Ihren PHP-FPM-Container
Da die Docker-Autoconf die Verwendung des Multisite-Modus impliziert, müssen Sie separate Verzeichnisse für jede Ihrer Anwendungen erstellen. Jedes Unterverzeichnis sollte nach dem ersten Wert von SERVER_NAME benannt werden. Hier ist ein Dummy-Beispiel:
www
├── app1.example.com
│ └── index.php
├── app2.example.com
│ └── index.php
└── app3.example.com
└── index.php
3 Verzeichnisse, 3 Dateien
Sobald die Ordner erstellt sind, kopieren Sie Ihre Dateien und korrigieren Sie die Berechtigungen, damit BunkerWeb (UID/GID 101) zumindest Dateien lesen und Ordner auflisten kann und PHP-FPM (UID/GID 33, wenn Sie das php:fpm-Image verwenden) der Eigentümer der Dateien und Ordner ist:
chown -R 33:101 ./www && \
find ./www -type f -exec chmod 0640 {} \; && \
find ./www -type d -exec chmod 0750 {} \;
Wenn Sie den BunkerWeb-Autoconf-Stack starten, mounten Sie den Ordner www in /var/www/html für den Scheduler-Container:
x-bw-api-env: &bw-api-env
# Wir verwenden einen Anker, um die Wiederholung derselben Einstellungen für alle Dienste zu vermeiden
AUTOCONF_MODE: "yes"
API_WHITELIST_IP: "127.0.0.0/8 10.20.30.0/24"
services:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
labels:
- "bunkerweb.INSTANCE=yes"
environment:
<<: *bw-api-env
volumes:
- ./www:/var/www/html
restart: "unless-stopped"
networks:
- bw-universe
- bw-services
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
environment:
<<: *bw-api-env
BUNKERWEB_INSTANCES: "" # Wir müssen die BunkerWeb-Instanz hier nicht angeben, da sie automatisch vom Autoconf-Dienst erkannt werden
SERVER_NAME: "" # Der Servername wird über Dienst-Labels gefüllt
MULTISITE: "yes" # Obligatorische Einstellung für Autoconf
DATABASE_URI: "mariadb+pymysql://bunkerweb:changeme@bw-db:3306/db" # Denken Sie daran, ein stärkeres Passwort für die Datenbank festzulegen
volumes:
- bw-storage:/data # Wird verwendet, um den Cache und andere Daten wie Backups zu persistieren
restart: "unless-stopped"
networks:
- bw-universe
- bw-db
bw-autoconf:
image: bunkerity/bunkerweb-autoconf:1.6.5
depends_on:
- bunkerweb
- bw-docker
environment:
AUTOCONF_MODE: "yes"
DATABASE_URI: "mariadb+pymysql://bunkerweb:changeme@bw-db:3306/db" # Denken Sie daran, ein stärkeres Passwort für die Datenbank festzulegen
DOCKER_HOST: "tcp://bw-docker:2375" # Der Docker-Socket
restart: "unless-stopped"
networks:
- bw-universe
- bw-docker
- bw-db
bw-docker:
image: tecnativa/docker-socket-proxy:nightly
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
environment:
CONTAINERS: "1"
LOG_LEVEL: "warning"
networks:
- bw-docker
bw-db:
image: mariadb:11
# Wir setzen die maximal zulässige Paketgröße, um Probleme mit großen Abfragen zu vermeiden
command: --max-allowed-packet=67108864
environment:
MYSQL_RANDOM_ROOT_PASSWORD: "yes"
MYSQL_DATABASE: "db"
MYSQL_USER: "bunkerweb"
MYSQL_PASSWORD: "changeme" # Denken Sie daran, ein stärkeres Passwort für die Datenbank festzulegen
volumes:
- bw-data:/var/lib/mysql
networks:
- bw-docker
volumes:
bw-data:
bw-storage:
networks:
bw-universe:
name: bw-universe
ipam:
driver: default
config:
- subnet: 10.20.30.0/24
bw-services:
name: bw-services
bw-docker:
name: bw-docker
Sie können nun Ihre PHP-FPM-Container erstellen, die richtigen Unterordner mounten und Labels verwenden, um BunkerWeb zu konfigurieren:
services:
myapp1:
image: php:fpm
volumes:
- ./www/app1.example.com:/app
networks:
bw-services:
aliases:
- myapp1
labels:
- "bunkerweb.SERVER_NAME=app1.example.com"
- "bunkerweb.REMOTE_PHP=myapp1"
- "bunkerweb.REMOTE_PHP_PATH=/app"
myapp2:
image: php:fpm
volumes:
- ./www/app2.example.com:/app
networks:
bw-services:
aliases:
- myapp2
labels:
- "bunkerweb.SERVER_NAME=app2.example.com"
- "bunkerweb.REMOTE_PHP=myapp2"
- "bunkerweb.REMOTE_PHP_PATH=/app"
myapp3:
image: php:fpm
volumes:
- ./www/app3.example.com:/app
networks:
bw-services:
aliases:
- myapp3
labels:
- "bunkerweb.SERVER_NAME=app3.example.com"
- "bunkerweb.REMOTE_PHP=myapp3"
- "bunkerweb.REMOTE_PHP_PATH=/app"
networks:
bw-services:
external: true
name: bw-services
PHP wird für Kubernetes nicht unterstützt
Die Kubernetes-Integration ermöglicht die Konfiguration über Ingress und der BunkerWeb-Controller unterstützt im Moment nur HTTP-Anwendungen.
Wir gehen davon aus, dass Sie bereits den Linux-Integrations-Stack auf Ihrer Maschine laufen haben.
Standardmäßig sucht BunkerWeb nach Web-Dateien im Ordner /var/www/html. Sie können ihn verwenden, um Ihre PHP-Anwendungen zu speichern. Bitte beachten Sie, dass Sie Ihren PHP-FPM-Dienst so konfigurieren müssen, dass er den Benutzer/die Gruppe der laufenden Prozesse und die UNIX-Socket-Datei, die zur Kommunikation mit BunkerWeb verwendet wird, abruft oder festlegt.
Zunächst müssen Sie sicherstellen, dass Ihre PHP-FPM-Instanz auf die Dateien im Ordner /var/www/html zugreifen kann und dass BunkerWeb auf die UNIX-Socket-Datei zugreifen kann, um mit PHP-FPM zu kommunizieren. Wir empfehlen, einen anderen Benutzer wie www-data für den PHP-FPM-Dienst festzulegen und der nginx-Gruppe Zugriff auf die UNIX-Socket-Datei zu geben. Hier ist die entsprechende PHP-FPM-Konfiguration:
...
[www]
user = www-data
group = www-data
listen = /run/php/php-fpm.sock
listen.owner = www-data
listen.group = nginx
listen.mode = 0660
...
Vergessen Sie nicht, Ihren PHP-FPM-Dienst neu zu starten:
systemctl restart php-fpm
Wenn Sie den Multisite-Modus aktivieren, müssen Sie separate Verzeichnisse für jede Ihrer Anwendungen erstellen. Jedes Unterverzeichnis sollte nach dem ersten Wert von SERVER_NAME benannt werden. Hier ist ein Dummy-Beispiel:
/var/www/html
├── app1.example.com
│ └── index.php
├── app2.example.com
│ └── index.php
└── app3.example.com
└── index.php
3 Verzeichnisse, 3 Dateien
Bitte beachten Sie, dass Sie die Berechtigungen korrigieren müssen, damit BunkerWeb (Gruppe nginx) zumindest Dateien lesen und Ordner auflisten kann und PHP-FPM (Benutzer www-data, kann je nach System unterschiedlich sein) der Eigentümer der Dateien und Ordner ist:
chown -R www-data:nginx /var/www/html && \
find /var/www/html -type f -exec chmod 0640 {} \; && \
find /var/www/html -type d -exec chmod 0750 {} \;
Sie können nun die Datei /etc/bunkerweb/variable.env bearbeiten:
HTTP_PORT=80
HTTPS_PORT=443
DNS_RESOLVERS=9.9.9.9 8.8.8.8 8.8.4.4
API_LISTEN_IP=127.0.0.1
MULTISITE=yes
SERVER_NAME=app1.example.com app2.example.com app3.example.com
app1.example.com_LOCAL_PHP=/run/php/php-fpm.sock
app1.example.com_LOCAL_PHP_PATH=/var/www/html/app1.example.com
app2.example.com_LOCAL_PHP=/run/php/php-fpm.sock
app2.example.com_LOCAL_PHP_PATH=/var/www/html/app2.example.com
app3.example.com_LOCAL_PHP=/run/php/php-fpm.sock
app3.example.com_LOCAL_PHP_PATH=/var/www/html/app3.example.com
Überprüfen wir nun den Status des Schedulers:
systemctl status bunkerweb-scheduler
Wenn er bereits läuft, können wir ihn neu laden:
systemctl reload bunkerweb-scheduler
Andernfalls müssen wir ihn starten:
systemctl start bunkerweb-scheduler
Veraltet
Die Swarm-Integration ist veraltet und wird in einer zukünftigen Version entfernt. Bitte erwägen Sie stattdessen die Verwendung der Kubernetes-Integration.
Weitere Informationen finden Sie in der Swarm-Integrationsdokumentation.
Multisite-Modus aktiviert
Die Swarm-Integration impliziert die Verwendung des Multisite-Modus: Das Schützen einer PHP-Anwendung ist dasselbe wie das Schützen mehrerer.
Geteiltes Volume
Die Verwendung von PHP mit der Docker Swarm-Integration erfordert ein geteiltes Volume zwischen allen BunkerWeb- und PHP-FPM-Instanzen, was in dieser Dokumentation nicht behandelt wird.
Bei Verwendung von Swarm müssen Sie zur Unterstützung von PHP-Anwendungen Folgendes tun:
- Mounten Sie Ihre PHP-Dateien in den Ordner
/var/www/htmlvon BunkerWeb - Richten Sie PHP-FPM-Container für Ihre Anwendungen ein und mounten Sie den Ordner mit den PHP-Apps
- Verwenden Sie die spezifischen Einstellungen
REMOTE_PHPundREMOTE_PHP_PATHals Labels für Ihren PHP-FPM-Container
Da die Swarm-Integration die Verwendung des Multisite-Modus impliziert, müssen Sie separate Verzeichnisse für jede Ihrer Anwendungen erstellen. Jedes Unterverzeichnis sollte nach dem ersten Wert von SERVER_NAME benannt werden. Hier ist ein Dummy-Beispiel:
www
├── app1.example.com
│ └── index.php
├── app2.example.com
│ └── index.php
└── app3.example.com
└── index.php
3 Verzeichnisse, 3 Dateien
Als Beispiel gehen wir davon aus, dass Sie einen freigegebenen Ordner auf Ihren Worker-Knoten am Endpunkt /shared gemountet haben.
Sobald die Ordner erstellt sind, kopieren Sie Ihre Dateien und korrigieren Sie die Berechtigungen, damit BunkerWeb (UID/GID 101) zumindest Dateien lesen und Ordner auflisten kann und PHP-FPM (UID/GID 33, wenn Sie das php:fpm-Image verwenden) der Eigentümer der Dateien und Ordner ist:
chown -R 33:101 /shared/www && \
find /shared/www -type f -exec chmod 0640 {} \; && \
find /shared/www -type d -exec chmod 0750 {} \;
Wenn Sie den BunkerWeb-Stack starten, mounten Sie den Ordner /shared/www in /var/www/html für den Scheduler-Container:
services:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
volumes:
- /shared/www:/var/www/html
...
Sie können nun Ihre PHP-FPM-Dienste erstellen, die richtigen Unterordner mounten und Labels verwenden, um BunkerWeb zu konfigurieren:
services:
myapp1:
image: php:fpm
volumes:
- ./www/app1.example.com:/app
networks:
bw-services:
aliases:
- myapp1
deploy:
placement:
constraints:
- "node.role==worker"
labels:
- "bunkerweb.SERVER_NAME=app1.example.com"
- "bunkerweb.REMOTE_PHP=myapp1"
- "bunkerweb.REMOTE_PHP_PATH=/app"
myapp2:
image: php:fpm
volumes:
- ./www/app2.example.com:/app
networks:
bw-services:
aliases:
- myapp2
deploy:
placement:
constraints:
- "node.role==worker"
labels:
- "bunkerweb.SERVER_NAME=app2.example.com"
- "bunkerweb.REMOTE_PHP=myapp2"
- "bunkerweb.REMOTE_PHP_PATH=/app"
myapp3:
image: php:fpm
volumes:
- ./www/app3.example.com:/app
networks:
bw-services:
aliases:
- myapp3
deploy:
placement:
constraints:
- "node.role==worker"
labels:
- "bunkerweb.SERVER_NAME=app3.example.com"
- "bunkerweb.REMOTE_PHP=myapp3"
- "bunkerweb.REMOTE_PHP_PATH=/app"
networks:
bw-services:
external: true
name: bw-services
IPv6
Experimentelles Feature
Dieses Feature ist nicht produktionsreif. Fühlen Sie sich frei, es zu testen und uns Fehler über Issues im GitHub-Repository zu melden.
Standardmäßig lauscht BunkerWeb nur auf IPv4-Adressen und verwendet kein IPv6 für die Netzwerkkommunikation. Wenn Sie die IPv6-Unterstützung aktivieren möchten, müssen Sie USE_IPV6=yes setzen. Bitte beachten Sie, dass die IPv6-Konfiguration Ihres Netzwerks und Ihrer Umgebung außerhalb des Geltungsbereichs dieser Dokumentation liegt.
Zunächst müssen Sie Ihren Docker-Daemon so konfigurieren, dass er die IPv6-Unterstützung für Container aktiviert und bei Bedarf ip6tables verwendet. Hier ist eine Beispielkonfiguration für Ihre /etc/docker/daemon.json-Datei:
{
"experimental": true,
"ipv6": true,
"ip6tables": true,
"fixed-cidr-v6": "fd00:dead:beef::/48"
}
Sie können nun den Docker-Dienst neu starten, um die Änderungen zu übernehmen:
systemctl restart docker
Sobald Docker für die Unterstützung von IPv6 eingerichtet ist, können Sie die Einstellung USE_IPV6 hinzufügen und die bw-services für IPv6 konfigurieren:
services:
bw-scheduler:
image: bunkerity/bunkerweb-scheduler:1.6.5
environment:
USE_IPv6: "yes"
...
networks:
bw-services:
name: bw-services
enable_ipv6: true
ipam:
config:
- subnet: fd00:13:37::/48
gateway: fd00:13:37::1
...
Sie müssen die Einstellungen zur Datei /etc/bunkerweb/variables.env hinzufügen:
...
USE_IPV6=yes
...
Überprüfen wir den Status von BunkerWeb:
systemctl status bunkerweb
Wenn er bereits läuft, können wir ihn neu starten:
systemctl restart bunkerweb
Andernfalls müssen wir ihn starten:
systemctl start bunkerweb
Docker Logging Best Practices
Bei der Verwendung von Docker ist es wichtig, die Container-Protokolle zu verwalten, um zu verhindern, dass sie übermäßig viel Speicherplatz beanspruchen. Standardmäßig verwendet Docker den json-file-Protokollierungstreiber, der bei fehlender Konfiguration zu sehr großen Protokolldateien führen kann.
Um dies zu vermeiden, können Sie die Protokollrotation konfigurieren. Dies kann für bestimmte Dienste in Ihrer docker-compose.yml-Datei oder global für den Docker-Daemon erfolgen.
Konfiguration pro Dienst
Sie können den Protokollierungstreiber für Ihre Dienste in Ihrer docker-compose.yml-Datei so konfigurieren, dass die Protokolle automatisch rotiert werden. Hier ist ein Beispiel, das bis zu 10 Protokolldateien mit jeweils 20 MB aufbewahrt:
services:
bunkerweb:
image: bunkerity/bunkerweb:1.6.5
logging:
driver: "json-file"
options:
max-size: "20m"
max-file: "10"
...
Diese Konfiguration stellt sicher, dass die Protokolle rotiert werden, und verhindert, dass sie Ihre Festplatte füllen. Sie können dies auf jeden Dienst in Ihrer Docker Compose-Einrichtung anwenden.
Globale Konfiguration (daemon.json)
Wenn Sie diese Protokollierungseinstellungen standardmäßig auf alle Container auf dem Host anwenden möchten, können Sie den Docker-Daemon konfigurieren, indem Sie die Datei /etc/docker/daemon.json bearbeiten (oder erstellen):
{
"log-driver": "json-file",
"log-opts": {
"max-size": "20m",
"max-file": "10"
}
}
Nachdem Sie daemon.json geändert haben, müssen Sie den Docker-Daemon neu starten, damit die Änderungen wirksam werden:
sudo systemctl restart docker
Diese globale Konfiguration wird von allen Containern übernommen. Jede pro Dienst in einer docker-compose.yml-Datei definierte Protokollierungskonfiguration überschreibt jedoch die globalen Einstellungen in daemon.json.
Sicherheits-Tuning
BunkerWeb bietet viele Sicherheitsfunktionen, die Sie mit Features konfigurieren können. Auch wenn die Standardwerte der Einstellungen eine minimale "Sicherheit von Haus aus" gewährleisten, empfehlen wir dringend, sie anzupassen. Dadurch können Sie das Sicherheitsniveau Ihrer Wahl sicherstellen und auch Fehlalarme verwalten.
Andere Funktionen
Dieser Abschnitt konzentriert sich nur auf das Sicherheits-Tuning, siehe den Abschnitt Features der Dokumentation für andere Einstellungen.
CrowdSec Console-Integration
Wenn Sie noch nicht mit der CrowdSec Console-Integration vertraut sind, CrowdSec nutzt crowdsourced Intelligenz, um Cyber-Bedrohungen zu bekämpfen. Stellen Sie es sich wie 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.
Herzlichen Glückwunsch, Ihre BunkerWeb-Instanz ist jetzt in Ihrer CrowdSec Console registriert!
Pro-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.
Überwachung und Berichterstattung
Überwachung 
(PRO)
STREAM-Unterstützung 
Das Überwachungs-Plugin ermöglicht es Ihnen, Metriken über BunkerWeb zu sammeln und abzurufen. Durch die Aktivierung beginnen Ihre Instanz(en), verschiedene Daten zu Angriffen, Anfragen und Leistung zu sammeln. Sie können sie dann durch Aufrufen des API-Endpunkts /monitoring regelmäßig abrufen oder andere Plugins wie den Prometheus-Exporter verwenden.
Liste der Funktionen
- Aktivierung der Sammlung verschiedener BunkerWeb-Metriken
- Abrufen von Metriken von der API
- Verwendung in Kombination mit anderen Plugins (z. B. Prometheus-Exporter)
- Dedizierte UI-Seite zur Überwachung Ihrer Instanz(en)
Liste der Einstellungen
| Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
|---|---|---|---|---|
USE_MONITORING |
yes |
global | nein | Aktiviert die Überwachung von BunkerWeb. |
MONITORING_METRICS_DICT_SIZE |
10M |
global | nein | Größe des Diktionärs zum Speichern von Überwachungsmetriken. |
Prometheus-Exporter (PRO)
STREAM-Unterstützung
Das Prometheus-Exporter-Plugin fügt einen Prometheus-Exporter zu Ihrer/n BunkerWeb-Instanz(en) hinzu. Wenn aktiviert, können Sie Ihre Prometheus-Instanz(en) so konfigurieren, dass sie einen bestimmten Endpunkt auf BunkerWeb abrufen und interne Metriken sammeln.
Wir stellen auch ein Grafana-Dashboard zur Verfügung, das Sie in Ihre eigene Instanz importieren und mit Ihrer eigenen Prometheus-Datenquelle verbinden können.
Bitte beachten Sie, dass die Verwendung des Prometheus-Exporter-Plugins die Aktivierung des Überwachungs-Plugins erfordert (USE_MONITORING=yes)
Liste der Funktionen
- Prometheus-Exporter, der interne BunkerWeb-Metriken bereitstellt
- Dedizierter und konfigurierbarer Port, lauschende IP und URL
- Whitelist-IP/Netzwerk für maximale Sicherheit
Liste der Einstellungen
| Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
|---|---|---|---|---|
USE_PROMETHEUS_EXPORTER |
no |
global | nein | Aktiviert den Prometheus-Export. |
PROMETHEUS_EXPORTER_IP |
0.0.0.0 |
global | nein | Lauschende IP des Prometheus-Exporters. |
PROMETHEUS_EXPORTER_PORT |
9113 |
global | nein | Lauschender Port des Prometheus-Exporters. |
PROMETHEUS_EXPORTER_URL |
/metrics |
global | nein | HTTP-URL des Prometheus-Exporters. |
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 | Liste der IP/Netzwerke, die den Prometheus-Exporter-Endpunkt kontaktieren dürfen. |
Berichterstattung (PRO)
STREAM-Unterstützung
Überwachungs-Plugin erforderlich
Dieses Plugin erfordert, dass das Monitoring Pro-Plugin installiert und mit der Einstellung USE_MONITORING auf yes gesetzt ist.
Das Reporting-Plugin bietet eine umfassende Lösung für die regelmäßige Berichterstattung wichtiger Daten aus BunkerWeb, einschließlich globaler Statistiken, Angriffe, Sperren, Anfragen, Gründe und AS-Informationen. Es bietet eine breite Palette von Funktionen, einschließlich automatischer Berichterstellung, Anpassungsoptionen und nahtloser Integration mit dem Monitoring Pro-Plugin. Mit dem Reporting-Plugin können Sie Berichte einfach erstellen und verwalten, um die Leistung und Sicherheit Ihrer Anwendung zu überwachen.
Liste der Funktionen
- Regelmäßige Berichterstattung wichtiger Daten aus BunkerWeb, einschließlich globaler Statistiken, Angriffe, Sperren, Anfragen, Gründe und AS-Informationen.
- Integration mit dem Monitoring Pro-Plugin für nahtlose Integration und erweiterte Berichtsfunktionen.
- Unterstützung für Webhooks (klassisch, Discord und Slack) für Echtzeit-Benachrichtigungen.
- Unterstützung für SMTP für E-Mail-Benachrichtigungen.
- Konfigurationsoptionen zur Anpassung und Flexibilität.
Liste der Einstellungen
| Einstellung | Standard | Kontext | Beschreibung |
|---|---|---|---|
USE_REPORTING_SMTP |
no |
global | Aktiviert das Senden des Berichts per E-Mail. |
USE_REPORTING_WEBHOOK |
no |
global | Aktiviert das Senden des Berichts per Webhook. |
REPORTING_SCHEDULE |
weekly |
global | Die Häufigkeit, mit der Berichte gesendet werden. |
REPORTING_WEBHOOK_URLS |
global | Liste der Webhook-URLs, die den Bericht im Markdown-Format erhalten sollen (durch Leerzeichen getrennt). | |
REPORTING_SMTP_EMAILS |
global | Liste der E-Mail-Adressen, die den Bericht im HTML-Format erhalten sollen (durch Leerzeichen getrennt). | |
REPORTING_SMTP_HOST |
global | Der Host-Server, der für den SMTP-Versand verwendet wird. | |
REPORTING_SMTP_PORT |
465 |
global | Der für SMTP verwendete Port. Bitte beachten Sie, dass es je nach Verbindungstyp unterschiedliche Standards gibt (SSL = 465, TLS = 587). |
REPORTING_SMTP_FROM_EMAIL |
global | Die als Absender verwendete E-Mail-Adresse. Beachten Sie, dass 2FA für diese E-Mail-Adresse deaktiviert sein muss. | |
REPORTING_SMTP_FROM_USER |
global | Der Benutzerauthentifizierungswert für das Senden über die Absender-E-Mail-Adresse. | |
REPORTING_SMTP_FROM_PASSWORD |
global | Der Passwortauthentifizierungswert für das Senden über die Absender-E-Mail-Adresse. | |
REPORTING_SMTP_SSL |
SSL |
global | Bestimmt, ob eine sichere Verbindung für SMTP verwendet werden soll oder nicht. |
REPORTING_SMTP_SUBJECT |
BunkerWeb Report |
global | Die Betreffzeile der E-Mail. |
Information und Verhalten
- wenn
USE_REPORTING_SMTPaufyesgesetzt ist, muss die EinstellungREPORTING_SMTP_EMAILSgesetzt werden. - wenn
USE_REPORTING_WEBHOOKaufyesgesetzt ist, muss die EinstellungREPORTING_WEBHOOK_URLSgesetzt werden. - Akzeptierte Werte für
REPORTING_SCHEDULEsinddaily,weeklyundmonthly. - wenn keine
REPORTING_SMTP_FROM_USERundREPORTING_SMTP_FROM_PASSWORDgesetzt sind, versucht das Plugin, die E-Mail ohne Authentifizierung zu senden. - wenn
REPORTING_SMTP_FROM_USERnicht gesetzt ist, aberREPORTING_SMTP_FROM_PASSWORDgesetzt ist, verwendet das Plugin dieREPORTING_SMTP_FROM_EMAILals Benutzernamen. - wenn der Job fehlschlägt, versucht das Plugin, den Bericht bei der nächsten Ausführung erneut zu senden.
Sicherung und Wiederherstellung
Sicherung S3 (PRO)
STREAM-Unterstützung 
Das Backup S3-Tool automatisiert nahtlos den Datenschutz, ähnlich dem Community-Backup-Plugin. Es zeichnet sich jedoch dadurch aus, dass es Backups direkt und sicher in einem S3-Bucket speichert.
Durch die Aktivierung dieser Funktion schützen Sie proaktiv die Integrität Ihrer Daten. Das Speichern von Backups remote schützt wichtige Informationen vor Bedrohungen wie Hardwareausfällen, Cyberangriffen oder Naturkatastrophen. Dies gewährleistet sowohl Sicherheit als auch Verfügbarkeit, ermöglicht eine schnelle Wiederherstellung bei unerwarteten Ereignissen, bewahrt die betriebliche Kontinuität und sorgt für Sorgenfreiheit.
Informationen für Benutzer von Red Hat Enterprise Linux (RHEL) 8.9
Wenn Sie RHEL 8.9 verwenden und eine externe Datenbank nutzen möchten, müssen Sie das Paket mysql-community-client installieren, um sicherzustellen, dass der Befehl mysqldump verfügbar ist. Sie können das Paket mit den folgenden Befehlen installieren:
-
Installieren Sie das MySQL-Repository-Konfigurationspaket
sudo dnf install https://dev.mysql.com/get/mysql80-community-release-el8-9.noarch.rpm -
Aktivieren Sie das MySQL-Repository
sudo dnf config-manager --enable mysql80-community -
Installieren Sie den MySQL-Client
sudo dnf install mysql-community-client
-
Installieren Sie das PostgreSQL-Repository-Konfigurationspaket
dnf install "https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-$(uname -m)/pgdg-redhat-repo-latest.noarch.rpm" -
Installieren Sie den PostgreSQL-Client
dnf install postgresql<version>
Liste der Funktionen
- Automatische Datensicherung in einem S3-Bucket
- Flexible Planungsoptionen: täglich, wöchentlich oder monatlich
- Rotationsmanagement zur Steuerung der Anzahl der aufzubewahrenden Backups
- Anpassbarer Komprimierungsgrad für Backup-Dateien
Liste der Einstellungen
| Einstellung | Standard | Kontext | Beschreibung |
|---|---|---|---|
USE_BACKUP_S3 |
no |
global | Aktiviert oder deaktiviert die S3-Backup-Funktion |
BACKUP_S3_SCHEDULE |
daily |
global | Die Häufigkeit des Backups |
BACKUP_S3_ROTATION |
7 |
global | Die Anzahl der aufzubewahrenden Backups |
BACKUP_S3_ENDPOINT |
global | Der S3-Endpunkt | |
BACKUP_S3_BUCKET |
global | Der S3-Bucket | |
BACKUP_S3_DIR |
global | Das S3-Verzeichnis | |
BACKUP_S3_REGION |
global | Die S3-Region | |
BACKUP_S3_ACCESS_KEY_ID |
global | Die S3-Zugriffsschlüssel-ID | |
BACKUP_S3_ACCESS_KEY_SECRET |
global | Das S3-Zugriffsschlüsselgeheimnis | |
BACKUP_S3_COMP_LEVEL |
6 |
global | Der Komprimierungsgrad der Backup-Zip-Datei |
Manuelle Sicherung
Um eine Sicherung manuell zu starten, führen Sie den folgenden Befehl aus:
bwcli plugin backup_s3 save
docker exec -it <scheduler_container> bwcli plugin backup_s3 save
Dieser Befehl erstellt eine Sicherung Ihrer Datenbank und speichert sie im S3-Bucket, der in der Einstellung BACKUP_S3_BUCKET angegeben ist.
Sie können auch einen benutzerdefinierten S3-Bucket für die Sicherung angeben, indem Sie die Umgebungsvariable BACKUP_S3_BUCKET bei der Ausführung des Befehls bereitstellen:
BACKUP_S3_BUCKET=your-bucket-name bwcli plugin backup_s3 save
docker exec -it -e BACKUP_S3_BUCKET=your-bucket-name <scheduler_container> bwcli plugin backup_s3 save
Spezifikationen für MariaDB/MySQL
Falls Sie MariaDB/MySQL verwenden, kann beim Versuch, Ihre Datenbank zu sichern, der folgende Fehler auftreten:
caching_sha2_password could not be loaded: Error loading shared library /usr/lib/mariadb/plugin/caching_sha2_password.so
Um dieses Problem zu lösen, können Sie den folgenden Befehl ausführen, um das Authentifizierungs-Plugin auf mysql_native_password zu ändern:
ALTER USER 'yourusername'@'localhost' IDENTIFIED WITH mysql_native_password BY 'youpassword';
Wenn Sie die Docker-Integration verwenden, können Sie den folgenden Befehl zur docker-compose.yml-Datei hinzufügen, um das Authentifizierungs-Plugin automatisch zu ändern:
bw-db:
image: mariadb:<version>
command: --default-authentication-plugin=mysql_native_password
...
bw-db:
image: mysql:<version>
command: --default-authentication-plugin=mysql_native_password
...
Manuelle Wiederherstellung
Um eine Wiederherstellung manuell zu starten, führen Sie den folgenden Befehl aus:
bwcli plugin backup_s3 restore
docker exec -it <scheduler_container> bwcli plugin backup_s3 restore
Dieser Befehl erstellt eine temporäre Sicherung Ihrer Datenbank im S3-Bucket, der in der Einstellung BACKUP_S3_BUCKET angegeben ist, und stellt Ihre Datenbank auf die neueste im Bucket verfügbare Sicherung wieder her.
Sie können auch eine benutzerdefinierte Sicherungsdatei für die Wiederherstellung angeben, indem Sie den Pfad dazu als Argument bei der Ausführung des Befehls angeben:
bwcli plugin backup_s3 restore s3_backup_file.zip
docker exec -it <scheduler_container> bwcli plugin backup restore s3_backup_file.zip
Im Falle eines Fehlers
Machen Sie sich keine Sorgen, wenn die Wiederherstellung fehlschlägt, Sie können Ihre Datenbank jederzeit auf den vorherigen Zustand zurücksetzen, indem Sie den Befehl erneut ausführen, da vor der Wiederherstellung eine Sicherung erstellt wird:
bwcli plugin backup_s3 restore
docker exec -it <scheduler_container> bwcli plugin backup_s3 restore
Migration (PRO)
STREAM-Unterstützung
Das Migrations-Plugin revolutioniert die Übertragung von BunkerWeb-Konfigurationen zwischen Instanzen mit seiner benutzerfreundlichen Weboberfläche, die den gesamten Migrationsprozess vereinfacht. Ob Sie Systeme aufrüsten, die Infrastruktur skalieren oder Umgebungen wechseln, dieses Tool ermöglicht es Ihnen, Einstellungen, Präferenzen und Daten mühelos und mit unübertroffener Leichtigkeit und Zuversicht zu übertragen. Verabschieden Sie sich von umständlichen manuellen Prozessen und begrüßen Sie ein nahtloses, problemloses Migrationserlebnis.
Liste der Funktionen
-
Mühelose Migration: Übertragen Sie BunkerWeb-Konfigurationen einfach zwischen Instanzen, ohne die Komplexität manueller Verfahren.
-
Intuitive Weboberfläche: Navigieren Sie mühelos durch den Migrationsprozess mit einer benutzerfreundlichen Weboberfläche, die für eine intuitive Bedienung entwickelt wurde.
-
Datenbankübergreifende Kompatibilität: Genießen Sie eine nahtlose Migration über verschiedene Datenbankplattformen hinweg, einschließlich SQLite, MySQL, MariaDB und PostgreSQL, und gewährleisten Sie die Kompatibilität mit Ihrer bevorzugten Datenbankumgebung.
Eine Migrationsdatei erstellen
Um eine Migrationsdatei manuell zu erstellen, führen Sie den folgenden Befehl aus:
bwcli plugin migration create /pfad/zur/migrations/datei
-
Eine Migrationsdatei erstellen:
docker exec -it <scheduler_container> bwcli plugin migration create /pfad/zur/migrations/datei -
Kopieren Sie die Migrationsdatei auf Ihren lokalen Rechner:
docker cp <scheduler_container>:/pfad/zur/migrations/datei /pfad/zur/migrations/datei
Dieser Befehl erstellt eine Sicherung Ihrer Datenbank und speichert sie im im Befehl angegebenen Sicherungsverzeichnis.
Spezifikationen für MariaDB/MySQL
Falls Sie MariaDB/MySQL verwenden, kann beim Versuch, Ihre Datenbank zu sichern, der folgende Fehler auftreten:
caching_sha2_password could not be loaded: Error loading shared library /usr/lib/mariadb/plugin/caching_sha2_password.so
Um dieses Problem zu lösen, können Sie den folgenden Befehl ausführen, um das Authentifizierungs-Plugin auf mysql_native_password zu ändern:
ALTER USER 'yourusername'@'localhost' IDENTIFIED WITH mysql_native_password BY 'youpassword';
Wenn Sie die Docker-Integration verwenden, können Sie den folgenden Befehl zur docker-compose.yml-Datei hinzufügen, um das Authentifizierungs-Plugin automatisch zu ändern:
bw-db:
image: mariadb:<version>
command: --default-authentication-plugin=mysql_native_password
...
bw-db:
image: mysql:<version>
command: --default-authentication-plugin=mysql_native_password
...
Eine Migration initialisieren
Um eine Migration manuell zu initialisieren, führen Sie den folgenden Befehl aus:
bwcli plugin migration migrate /pfad/zur/migrations/datei
-
Kopieren Sie die Migrationsdatei in den Container:
docker cp /pfad/zur/migrations/datei <scheduler_container>:/pfad/zur/migrations/datei -
Initialisieren Sie die Migration:
docker exec -it <scheduler_container> bwcli plugin migration migrate /pfad/zur/migrations/datei
-
Kopieren Sie die Migrationsdatei in den Container:
docker cp /pfad/zur/migrations/datei bunkerweb-aio:/pfad/zur/migrations/datei -
Initialisieren Sie die Migration:
docker exec -it bunkerweb-aio bwcli plugin migration migrate /pfad/zur/migrations/datei
Dieser Befehl migriert Ihre BunkerWeb-Daten nahtlos, um genau der in der Migrationsdatei beschriebenen Konfiguration zu entsprechen.
Anti-DDoS (PRO)
STREAM-Unterstützung
Das Anti-DDoS-Plugin bietet fortschrittlichen Schutz gegen Distributed Denial of Service (DDoS)-Angriffe, indem es verdächtigen Verkehr in Echtzeit überwacht, analysiert und filtert.
Durch die Verwendung eines gleitenden Fenstermechanismus unterhält das Plugin ein In-Memory-Wörterbuch mit Zeitstempeln von Anfragen, um anormale Verkehrsspitzen von einzelnen IP-Adressen zu erkennen. Basierend auf dem konfigurierten Sicherheitsmodus kann es entweder die beleidigenden Verbindungen blockieren oder die verdächtige Aktivität zur weiteren Überprüfung protokollieren.
Funktionen
- Echtzeit-Verkehrsanalyse: Überwacht kontinuierlich eingehende Anfragen, um potenzielle DDoS-Angriffe zu erkennen.
- Gleitender Fenstermechanismus: Verfolgt die jüngsten Anforderungsaktivitäten innerhalb eines konfigurierbaren Zeitfensters.
- Konfigurierbare Schwellenwerte: Ermöglicht die Definition der maximalen Anzahl verdächtiger Anfragen pro IP.
- Fortschrittliche Blockierungslogik: Wertet sowohl die Anzahl der Anfragen pro IP als auch die Anzahl der unterschiedlichen IPs aus, die den Schwellenwert überschreiten.
- Flexible Sicherheitsmodi: Wählen Sie zwischen sofortiger Verbindungsblockierung oder dem reinen Erkennungsmodus (Protokollierung).
- Optimierter In-Memory-Datenspeicher: Gewährleistet Hochgeschwindigkeits-Lookups und effizientes Metrik-Tracking.
- Automatische Bereinigung: Löscht regelmäßig veraltete Daten, um eine optimale Leistung zu gewährleisten.
Konfiguration
Passen Sie das Verhalten des Plugins mit den folgenden Einstellungen an:
| Einstellung | Standard | Kontext | Mehrfach | Beschreibung |
|---|---|---|---|---|
USE_ANTIDDOS |
no |
global | nein | Aktiviert oder deaktiviert den Anti-DDoS-Schutz. Setzen Sie auf "yes", um das Plugin zu aktivieren. |
ANTIDDOS_METRICS_DICT_SIZE |
10M |
global | nein | Größe des In-Memory-Datenspeichers zur Verfolgung von DDoS-Metriken (z. B. 10M, 500k). |
ANTIDDOS_THRESHOLD |
100 |
global | nein | Maximale Anzahl verdächtiger Anfragen pro IP innerhalb des definierten Zeitfensters. |
ANTIDDOS_WINDOW_TIME |
10 |
global | nein | Zeitfenster in Sekunden, in dem verdächtige Anfragen gezählt werden. |
ANTIDDOS_STATUS_CODES |
429 403 444 |
global | nein | HTTP-Statuscodes, die als verdächtig gelten und zur Auslösung von Anti-DDoS-Aktionen verwendet werden. |
ANTIDDOS_DISTINCT_IP |
5 |
global | nein | Mindestanzahl unterschiedlicher IPs, die den Schwellenwert überschreiten müssen, bevor der Blockierungsmodus erzwungen wird. |
Bewährte Verfahren
- Schwellenwert-Tuning: Passen Sie
ANTIDDOS_THRESHOLDundANTIDDOS_WINDOW_TIMEbasierend auf Ihren typischen Verkehrsmustern an. - Statuscode-Überprüfung: Aktualisieren Sie
ANTIDDOS_STATUS_CODESregelmäßig, um neue oder sich entwickelnde verdächtige Verhaltensweisen zu erfassen. - Überwachung: Analysieren Sie Protokolle und Metriken regelmäßig, um die Einstellungen zu optimieren und den Gesamtschutz zu verbessern.
Benutzer-Manager (PRO)
Das Benutzerverwaltungs-Plugin bietet eine robuste Schnittstelle zur Verwaltung von Benutzerkonten in Ihrem System.
Mit diesem Plugin können Administratoren mühelos Benutzerkonten erstellen, aktualisieren und deaktivieren, Benutzerrollen verwalten, die Zwei-Faktor-Authentifizierung (2FA) umschalten und detaillierte Benutzerinformationen wie letzte Anmeldezeitstempel und Kontostatus (aktiv oder inaktiv) anzeigen. Dieses Plugin wurde mit Blick auf Sicherheit und Benutzerfreundlichkeit entwickelt und vereinfacht routinemäßige Benutzerverwaltungsaufgaben, während es gleichzeitig die Einhaltung von Vorschriften und die Überprüfbarkeit gewährleistet.
Funktionen
- Benutzerkonto-Operationen: Importieren im CSV/XSLX-Format, Erstellen, Bearbeiten und Löschen von Benutzerkonten mit Leichtigkeit.
- Rollenbasierte Zugriffskontrolle: Weisen Sie Benutzerrollen zu und ändern Sie sie, um Berechtigungen und Zugriffsebenen zu verwalten.
- 2FA-Verwaltung: Deaktivieren Sie die Zwei-Faktor-Authentifizierung basierend auf administrativen Entscheidungen.
- Umfassende Benutzereinblicke: Überwachen Sie wichtige Benutzerdaten, einschließlich letzter Anmeldezeiten, Kontoerstellungsdaten und Aktiv/Inaktiv-Status.
- Audit-Protokollierung: Führen Sie eine Audit-Spur für alle Benutzerverwaltungsaktionen für verbesserte Sicherheit und Compliance.
Easy Resolve (PRO)
Das Easy Resolve Plugin ermöglicht es Ihnen, Fehlalarme und wiederkehrende Probleme direkt von der Berichtsseite aus schnell zu beheben. Es wandelt geführte "Resolve"-Aktionen in sichere, bereichsbezogene Konfigurationsupdates um – ohne manuelle Bearbeitung.
Funktionen
- Ein-Klick-Aktionen aus Berichten und Berichtsdetails.
- Kontextbezogene Vorschläge für ModSecurity, Blacklist und DNSBL.
- Generiert sichere ModSecurity-Ausschlüsse oder aktualisiert Ignorierlisten.
- Wendet Änderungen auf Dienst- oder globaler Ebene mit Berechtigungsprüfungen an.
- Optionales automatisches Öffnen der zugehörigen Konfigurationsseite nach der Anwendung.
