librewolf
/
bunkerized-nginx
mirror of https://github.com/bunkerity/bunkerized-nginx
4
0
Fork 1
Code Issues Projects Releases Wiki Activity

fix links in docs and change cache location for GHA jobs

This commit is contained in:
florian 2022-06-06 14:51:47 +02:00
parent 05a89c3037
commit 389e050943
14 changed files with 107 additions and 107 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
.github/workflows/new-dev.yml vendored
View File

@ -37,8 +37,8 @@ jobs:
platforms: linux/amd64
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-amd64:latest
cache-from: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-amd64:buildcache
cache-to: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-amd64:buildcache,mode=min
cache-from: type=registry,ref=bunkerity/cache:bw-amd64-cache
cache-to: type=registry,ref=bunkerity/cache:bw-amd64-cache,mode=min
- name: Build BW autoconf for amd64
uses: docker/build-push-action@v3
with:
@ -47,8 +47,8 @@ jobs:
platforms: linux/amd64
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-amd64:latest
cache-from: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-amd64:buildcache
cache-to: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-amd64:buildcache,mode=min
cache-from: type=registry,ref=bunkerity/cache:bw-autoconf-amd64-cache
cache-to: type=registry,ref=bunkerity/cache:bw-autoconf-amd64-cache,mode=min
- name: Build BW UI for amd64
uses: docker/build-push-action@v3
with:
@ -57,8 +57,8 @@ jobs:
platforms: linux/amd64
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/bunkerweb-ui-tests-amd64:latest
cache-from: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-ui-tests-amd64:buildcache
cache-to: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-ui-tests-amd64:buildcache,mode=min
cache-from: type=registry,ref=bunkerity/cache:bw-ui-amd64-cache
cache-to: type=registry,ref=bunkerity/cache:bw-ui-amd64-cache,mode=min
# Build bunkerweb/386
build-bw-386:
@ -90,8 +90,8 @@ jobs:
platforms: linux/386
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-386:latest
cache-from: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-386:buildcache
cache-to: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-386:buildcache,mode=min
cache-from: type=registry,ref=bunkerity/cache:bw-386-cache
cache-to: type=registry,ref=bunkerity/cache:bw-386-cache,mode=min
- name: Build BW autoconf for 386
uses: docker/build-push-action@v3
with:
@ -100,8 +100,8 @@ jobs:
platforms: linux/386
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-386:latest
cache-from: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-386:buildcache
cache-to: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-386:buildcache,mode=min
cache-from: type=registry,ref=bunkerity/cache:bw-autoconf-386-cache
cache-to: type=registry,ref=bunkerity/cache:bw-autoconf-386-cache,mode=min
- name: Build BW UI for 386
uses: docker/build-push-action@v3
with:
@ -110,9 +110,8 @@ jobs:
platforms: linux/386
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-386:latest
cache-from: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-386:buildcache
cache-to: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-386:buildcache,mode=min
cache-from: ttype=registry,ref=bunkerity/cache:bw-ui-386-cache
cache-to: type=registry,ref=bunkerity/cache:bw-ui-386-cache,mode=min
# Build bunkerweb/arm
build-bw-arm:
@ -143,8 +142,8 @@ jobs:
platforms: linux/arm/v7,linux/arm64/v8
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-arm:latest
cache-from: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-arm:buildcache
cache-to: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-arm:buildcache,mode=min
cache-from: type=registry,ref=bunkerity/cache:bw-arm-cache
cache-to: type=registry,ref=bunkerity/cache:bw-arm-cache,mode=min
- name: Build BW autoconf for arm
uses: docker/build-push-action@v3
with:
@ -153,8 +152,8 @@ jobs:
platforms: linux/arm/v7,linux/arm64/v8
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-arm:latest
cache-from: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-arm:buildcache
cache-to: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-arm:buildcache,mode=min
cache-from: type=registry,ref=bunkerity/cache:bw-autoconf-arm-cache
cache-to: type=registry,ref=bunkerity/cache:bw-autoconf-arm-cache,mode=min
- name: Build BW UI for arm
uses: docker/build-push-action@v3
with:
@ -163,8 +162,8 @@ jobs:
platforms: linux/arm/v7,linux/arm64/v8
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-ui-tests-arm:latest
cache-from: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-ui-tests-arm:buildcache
cache-to: type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-ui-tests-arm:buildcache,mode=min
cache-from: type=registry,ref=bunkerity/cache:bw-ui-arm-cache
cache-to: type=registry,ref=bunkerity/cache:bw-ui-arm-cache,mode=min
# Run tests
tests:
@ -247,9 +246,9 @@ jobs:
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb:staging,bunkerity/bunkerweb:dev
cache-from: |
type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-amd64:buildcache
type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-386:buildcache
type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-tests-arm:buildcache
type=registry,ref=bunkerity/cache:bw-amd64-cache
type=registry,ref=bunkerity/cache:bw-386-cache
type=registry,ref=bunkerity/cache:bw-arm-cache
- name: Build and push BW autoconf
uses: docker/build-push-action@v3
with:
@ -259,9 +258,9 @@ jobs:
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf:staging,bunkerity/bunkerweb-autoconf:dev
cache-from: |
type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-amd64:buildcache
type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-386:buildcache
type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-autoconf-tests-arm:buildcache
type=registry,ref=bunkerity/cache:bw-autoconf-amd64-cache
type=registry,ref=bunkerity/cache:bw-autoconf-386-cache
type=registry,ref=bunkerity/cache:bw-autoconf-arm-cache
- name: Build and push BW UI
uses: docker/build-push-action@v3
with:
@ -271,9 +270,9 @@ jobs:
push: true
tags: ${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-ui:staging,bunkerity/bunkerweb-ui:dev
cache-from: |
type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-ui-tests-amd64:buildcache
type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-ui-tests-386:buildcache
type=registry,ref=${{ secrets.PRIVATE_REGISTRY }}/infra/bunkerweb-ui-tests-arm:buildcache
type=registry,ref=bunkerity/cache:bw-ui-amd64-cache
type=registry,ref=bunkerity/cache:bw-ui-386-cache
type=registry,ref=bunkerity/cache:bw-ui-arm-cache
# Push to PackageCloud
push-linux:

36
README.md
View File

@ -59,7 +59,7 @@ A non-exhaustive list of security features :
- **Block known bad IPs** with external blacklists and DNSBL
- And much more ...
Learn more about the core security features in the [security tuning](https://docs.bunkerweb.io/security-tuning) section of the documentation.
Learn more about the core security features in the [security tuning](https://docs.bunkerweb.io/latest/security-tuning) section of the documentation.
## Demo
@ -75,7 +75,7 @@ A demo website protected with BunkerWeb is available at [demo.bunkerweb.io](http
<img alt="BunkerWeb logo" src="https://github.com/bunkerity/bunkerweb/raw/master/docs/assets/img/concepts.svg" />
</p>
You will find more information about the key concepts of BunkerWeb in the [documentation](https://docs.bunkerweb.io/concepts).
You will find more information about the key concepts of BunkerWeb in the [documentation](https://docs.bunkerweb.io/latest/concepts).
## Integrations
@ -83,11 +83,11 @@ The first concept is the integration of BunkerWeb into the target environment. W
The following integrations are officially supported :
- [Docker](https://docs.bunkerweb.io/integrations/#docker)
- [Docker autoconf](https://docs.bunkerweb.io/integrations/#docker-autoconf)
- [Swarm](https://docs.bunkerweb.io/integrations/#swarm)
- [Kubernetes](https://docs.bunkerweb.io/integrations/#kubernetes)
- [Linux](https://docs.bunkerweb.io/integrations/#linux)
- [Docker](https://docs.bunkerweb.io/latest/integrations/#docker)
- [Docker autoconf](https://docs.bunkerweb.io/latest/integrations/#docker-autoconf)
- [Swarm](https://docs.bunkerweb.io/latest/integrations/#swarm)
- [Kubernetes](https://docs.bunkerweb.io/latest/integrations/#kubernetes)
- [Linux](https://docs.bunkerweb.io/latest/integrations/#linux)
## Settings
@ -119,7 +119,7 @@ When multisite mode is enabled, BunkerWeb will serve and protect multiple web ap
## Custom configurations
Because meeting all the use cases only using the settings is not an option (even with [external plugins](https://docs.bunkerweb.io/plugins)), you can use custom configurations to solve your specific challenges.
Because meeting all the use cases only using the settings is not an option (even with [external plugins](https://docs.bunkerweb.io/latest/plugins)), you can use custom configurations to solve your specific challenges.
Under the hood, BunkerWeb uses the notorious NGINX web server, that's why you can leverage its configuration system for your specific needs. Custom NGINX configurations can be included in different [contexts](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/#contexts) like HTTP or server (all servers and/or specific server block).
@ -141,7 +141,7 @@ Usage and configuration of the BunkerWeb container are based on :
- **Volume** to cache important data and mount custom configuration files
- **Networks** to expose ports for clients and connect to upstream web services
You will find more information in the [Docker integration section](https://docs.bunkerweb.io/integrations/#docker) of the documentation.
You will find more information in the [Docker integration section](https://docs.bunkerweb.io/latest/integrations/#docker) of the documentation.
## Docker autoconf
@ -153,7 +153,7 @@ The downside of using environment variables is that the container needs to be re
Instead of defining environment variables for the BunkerWeb container, you simply add **labels** to your web applications containers and the **autoconf** will "automagically" take care of the rest.
You will find more information in the [Docker autoconf section](https://docs.bunkerweb.io/integrations/#docker-autoconf) of the documentation.
You will find more information in the [Docker autoconf section](https://docs.bunkerweb.io/latest/integrations/#docker-autoconf) of the documentation.
## Swarm
@ -167,7 +167,7 @@ Like the [Docker autoconf integration](#docker-autoconf), configuration for web
The recommended setup is to schedule the **BunkerWeb service** as a **global service** on all worker nodes and the **autoconf service** as a **single replicated service** on a manager node.
You will find more information in the [Swarm section](https://docs.bunkerweb.io/integrations/#swarm) of the documentation.
You will find more information in the [Swarm section](https://docs.bunkerweb.io/latest/integrations/#swarm) of the documentation.
## Kubernetes
@ -177,7 +177,7 @@ You will find more information in the [Swarm section](https://docs.bunkerweb.io/
The autoconf acts as an [Ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) and will configure the BunkerWeb instances according to the [Ingress resources](https://kubernetes.io/docs/concepts/services-networking/ingress/). It also monitors other Kubernetes objects like [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) for custom configurations.
You will find more information in the [Kubernetes section](https://docs.bunkerweb.io/integrations/#kubernetes) of the documentation.
You will find more information in the [Kubernetes section](https://docs.bunkerweb.io/latest/integrations/#kubernetes) of the documentation.
## Linux
@ -194,11 +194,11 @@ List of supported Linux distros :
Repositories of Linux packages for BunkerWeb are available on [PackageCloud](https://packagecloud.io/bunkerity/bunkerweb), they provide a bash script to automatically add and trust the repository (but you can also follow the [manual installation](https://packagecloud.io/bunkerity/bunkerweb/install) instructions if you prefer).
You will find more information in the [Linux section](https://docs.bunkerweb.io/integrations/#linux) of the documentation.
You will find more information in the [Linux section](https://docs.bunkerweb.io/latest/integrations/#linux) of the documentation.
# Quickstart guide
Once you have setup BunkerWeb with the integration of your choice, you can follow the [quickstart guide](https://docs.bunkerweb.io/quickstart-guide/) that will cover the following common use cases :
Once you have setup BunkerWeb with the integration of your choice, you can follow the [quickstart guide](https://docs.bunkerweb.io/latest/quickstart-guide/) that will cover the following common use cases :
- Protecting a single HTTP application
- Protecting multiple HTTP application
- Retrieving the real IP of clients when operating behind a load balancer
@ -208,7 +208,7 @@ Once you have setup BunkerWeb with the integration of your choice, you can follo
BunkerWeb offers many security features that you can configure with [settings](/settings). Even if the default values of settings ensure a minimal "security by default", we strongly recommend you to tune them. By doing so you will be able to ensure a security level of your choice but also manage false positives.
You will find more information in the [security tuning section](https://docs.bunkerweb.io/security-tuning) of the documentation.
You will find more information in the [security tuning section](https://docs.bunkerweb.io/latest/security-tuning) of the documentation.
# Settings
@ -218,7 +218,7 @@ As a general rule when multisite mode is enabled, if you want to apply settings
When settings are considered as "multiple", it means that you can have multiple groups of settings for the same feature by adding numbers as suffix like `REVERSE_PROXY_URL_1=/subdir`, `REVERSE_PROXY_HOST_1=http://myhost1`, `REVERSE_PROXY_URL_2=/anotherdir`, `REVERSE_PROXY_HOST_2=http://myhost2`, ... for example.
Check the [settings section](https://docs.bunkerweb.io/settings) of the documentation to get the full list.
Check the [settings section](https://docs.bunkerweb.io/latest/settings) of the documentation to get the full list.
# Web UI
@ -234,7 +234,7 @@ The "Web UI" is a web application that helps you manage your BunkerWeb instance
- Install and uninstall external plugins
- View the logs and search pattern
You will find more information in the [Web UI section](https://docs.bunkerweb.io/web-ui) of the documentation.
You will find more information in the [Web UI section](https://docs.bunkerweb.io/latest/web-ui) of the documentation.
# Plugins
@ -248,7 +248,7 @@ Here is the list of "official" plugins that we maintain (see the [bunkerweb-plug
| **CrowdSec** | 0.1 | CrowdSec bouncer for BunkerWeb. | [bunkerweb-plugins/crowdsec](https://github.com/bunkerity/bunkerweb-plugins/tree/main/crowdsec) |
| **VirusTotal** | 0.1 | Automatically scans uploaded files with the VirusTotal API and denies the request when a file is detected as malicious. | [bunkerweb-plugins/virustotal](https://github.com/bunkerity/bunkerweb-plugins/tree/main/virustotal) |
You will find more information in the [plugins section](https://docs.bunkerweb.io/plugins) of the documentation.
You will find more information in the [plugins section](https://docs.bunkerweb.io/latest/plugins) of the documentation.
# Support

2
docs/about.md
View File

@ -34,7 +34,7 @@ Here is a non-exhaustive list of what you can do :
- Follow us on [LinkedIn](https://www.linkedin.com/company/bunkerity/), [Twitter](https://twitter.com/bunkerity) and [GitHub](https://github.com/bunkerity)
- Report bugs and propose new features using [issues](https://github.com/bunkerity/bunkerweb/issues)
- Contribute to the code using [pull requests](https://github.com/bunkerity/bunkerweb/pulls)
- Write an awesome [plugin](/plugins)
- Write an awesome [plugin](/1.4/plugins)
- Talk about BunkerWeb to your friends/colleagues, on social media, on your blog, ...
## How to report security issue ?

20
docs/concepts.md
View File

@ -11,17 +11,17 @@ The first concept is the integration of BunkerWeb into the target environment. W
The following integrations are officially supported :
- [Docker](/integrations/#docker)
- [Docker autoconf](/integrations/#docker-autoconf)
- [Swarm](/integrations/#swarm)
- [Kubernetes](/integrations/#kubernetes)
- [Linux](/integrations/#linux)
- [Docker](/1.4/integrations/#docker)
- [Docker autoconf](/1.4/integrations/#docker-autoconf)
- [Swarm](/1.4/integrations/#swarm)
- [Kubernetes](/1.4/integrations/#kubernetes)
- [Linux](/1.4/integrations/#linux)
If you think that a new integration should be supported, do not hesitate to open a [new issue](https://github.com/bunkerity/bunkerweb/issues) on the GitHub repository.
!!! info "Going further"
The technical details of all BunkerWeb integrations are available in the [integrations section](/integrations) of the documentation.
The technical details of all BunkerWeb integrations are available in the [integrations section](/1.4/integrations) of the documentation.
## Settings
@ -43,7 +43,7 @@ USE_BROTLI=no
!!! info "Going further"
The complete list of available settings with descriptions and possible values is available in the [settings section](/settings) of the documentation.
The complete list of available settings with descriptions and possible values is available in the [settings section](/1.4/settings) of the documentation.
!!! info "Settings generator tool"
@ -78,11 +78,11 @@ app3.example.com_USE_BAD_BEHAVIOR=no
!!! info "Going further"
You will find concrete examples of multisite mode in the [quickstart guide](/quickstart-guide) of the documentation and the [examples](https://github.com/bunkerity/bunkerweb/tree/master/examples) directory of the repository.
You will find concrete examples of multisite mode in the [quickstart guide](/1.4/quickstart-guide) of the documentation and the [examples](https://github.com/bunkerity/bunkerweb/tree/master/examples) directory of the repository.
## Custom configurations
Because meeting all the use cases only using the settings is not an option (even with [external plugins](/plugins)), you can use custom configurations to solve your specific challenges.
Because meeting all the use cases only using the settings is not an option (even with [external plugins](/1.4/plugins)), you can use custom configurations to solve your specific challenges.
Under the hood, BunkerWeb uses the notorious NGINX web server, that's why you can leverage its configuration system for your specific needs. Custom NGINX configurations can be included in different [contexts](https://docs.nginx.com/nginx/admin-guide/basic-functionality/managing-configuration-files/#contexts) like HTTP or server (all servers and/or specific server block).
@ -90,4 +90,4 @@ Another core component of BunkerWeb is the ModSecurity Web Application Firewall
!!! info "Going further"
You will find concrete examples of custom configurations in the [quickstart guide](/quickstart-guide) of the documentation and the [examples](https://github.com/bunkerity/bunkerweb/tree/master/examples) directory of the repository.
You will find concrete examples of custom configurations in the [quickstart guide](/1.4/quickstart-guide) of the documentation and the [examples](https://github.com/bunkerity/bunkerweb/tree/master/examples) directory of the repository.

4
docs/index.md
View File

@ -9,9 +9,9 @@
BunkerWeb is a web server based on the notorious [NGINX](https://nginx.org/) and focused on security.
It integrates into existing environments ([Linux](/integrations/#linux), [Docker](/integrations/#docker), [Swarm](/integrations/#swarm), [Kubernetes](/integrations/#Kubernetes), …) to make your web services "secure by default" without any hassle. The security best practices are automatically applied for you while keeping control of every setting to meet your use case.
It integrates into existing environments ([Linux](/1.4/integrations/#linux), [Docker](/1.4/integrations/#docker), [Swarm](/1.4/integrations/#swarm), [Kubernetes](/1.4/integrations/#Kubernetes), …) to make your web services "secure by default" without any hassle. The security best practices are automatically applied for you while keeping control of every setting to meet your use case.
BunkerWeb contains primary [security features](/security-tuning) as part of the core but can be easily extended with additional ones thanks to a [plugin system](/plugins).
BunkerWeb contains primary [security features](/1.4/security-tuning) as part of the core but can be easily extended with additional ones thanks to a [plugin system](/1.4/plugins).
## Why BunkerWeb ?

6
docs/integrations.md
View File

@ -54,7 +54,7 @@ services:
```
!!! info "Full list"
For the complete list of environment variables, see the [settings section](/settings) of the documentation.
For the complete list of environment variables, see the [settings section](/1.4/settings) of the documentation.
### Volume
@ -175,7 +175,7 @@ The downside of using environment variables is that the container needs to be re
Instead of defining environment variables for the BunkerWeb container, you simply add **labels** to your web applications containers and the **autoconf** will "automagically" take care of the rest.
!!! info "Multisite mode"
The Docker autoconf integration implies the use of **multisite mode**. Please refer to the [multisite section](/concepts/#multisite-mode) of the documentation for more information.
The Docker autoconf integration implies the use of **multisite mode**. Please refer to the [multisite section](/1.4/concepts/#multisite-mode) of the documentation for more information.
First of all, you will need to create the data volume :
@ -645,7 +645,7 @@ spec:
mountPath: /data
```
Once the BunkerWeb Kubernetes stack is setup and running (see autoconf logs for more information), you can now deploy web applications in the cluster and declare your Ingress resource. Please note that [settings](/settings) need to be set as annotations for the Ingress resource with the special value **bunkerweb.io** for the domain part :
Once the BunkerWeb Kubernetes stack is setup and running (see autoconf logs for more information), you can now deploy web applications in the cluster and declare your Ingress resource. Please note that [settings](/1.4/settings) need to be set as annotations for the Ingress resource with the special value **bunkerweb.io** for the domain part :
```yaml
apiVersion: networking.k8s.io/v1

3
docs/json2md.py
View File

@ -22,7 +22,8 @@ def print_md_table(settings) :
print("")
print("# Settings\n")
print("This section contains the full list of settings supported by BunkerWeb. If you are not familiar with BunkerWeb, you should first read the [concepts](/concepts) section of the documentation. Please follow the instructions for your own [integration](/integrations) on how to apply the settings.\n")
print("!!! info \"Settings generator tool\"\n\n To help you tuning BunkerWeb we have made an easy to use settings generator tool available at [config.bunkerweb.io](https://config.bunkerweb.io).\n")
print("This section contains the full list of settings supported by BunkerWeb. If you are not familiar with BunkerWeb, you should first read the [concepts](/1.4/concepts) section of the documentation. Please follow the instructions for your own [integration](/1.4/integrations) on how to apply the settings.\n")
print("As a general rule when multisite mode is enabled, if you want to apply settings with multisite context to a specific server you will need to add the primary (first) server name as a prefix like `www.example.com_USE_ANTIBOT=captcha` or `myapp.example.com_USE_GZIP=yes` for example.\n")
print("When settings are considered as \"multiple\", it means that you can have multiple groups of settings for the same feature by adding numbers as suffix like `REVERSE_PROXY_URL_1=/subdir`, `REVERSE_PROXY_HOST_1=http://myhost1`, `REVERSE_PROXY_URL_2=/anotherdir`, `REVERSE_PROXY_HOST_2=http://myhost2`, ... for example.\n")

10
docs/migrating.md
View File

@ -6,19 +6,19 @@
## Volumes
When using container-based integrations like [Docker](/integrations/#docker), [Docker autoconf](/integrations/#docker-autoconf), [Swarm](/integrations/#swarm) or [Kubernetes](/integrations/#kubernetes), volumes for storing data like certificates, cache or custom configurations has changed. We now have a single "bw-data" volume which contains everything and should be easier to manage than bunkerized.
When using container-based integrations like [Docker](/1.4/integrations/#docker), [Docker autoconf](/1.4/integrations/#docker-autoconf), [Swarm](/1.4/integrations/#swarm) or [Kubernetes](/1.4/integrations/#kubernetes), volumes for storing data like certificates, cache or custom configurations has changed. We now have a single "bw-data" volume which contains everything and should be easier to manage than bunkerized.
## Removed features
We decided to drop the following features :
- Authelia : we will make an official [plugin](/plugins) for that
- Authelia : we will make an official [plugin](/1.4/plugins) for that
- Blocking "bad" referrers : we may add it again in the future
- ROOT_SITE_SUBFOLDER : we will need to redesign this in the future
## Replaced BLOCK_*, WHITELIST_* and BLACKLIST_* settings
The blocking mechanisms has been completely redesigned. We have detected that a lot of false positives came from the default blacklists hardcoded into bunkerized. That's why we decided to give the users the choice of their blacklists (and also whitelists) for IP address, reverse DNS, user-agent, URI and ASN, see the [Blacklisting and whitelisting](/security-tuning/#blacklisting-and-whitelisting) section of the [security tuning](/security-tuning).
The blocking mechanisms has been completely redesigned. We have detected that a lot of false positives came from the default blacklists hardcoded into bunkerized. That's why we decided to give the users the choice of their blacklists (and also whitelists) for IP address, reverse DNS, user-agent, URI and ASN, see the [Blacklisting and whitelisting](/1.4/security-tuning/#blacklisting-and-whitelisting) section of the [security tuning](/1.4/security-tuning).
## Changed WHITELIST_USER_AGENT setting behavior
@ -26,8 +26,8 @@ The new behavior of the WHITELIST_USER_AGENT setting is to **disable completely
## Changed PROXY_REAL_IP_* settings
To avoid any confusion between reverse proxy and real IP, we decided to renamed the `PROXY_REAL_IP_*` settings, you will find more information on the subject [here](/quickstart-guide/#behind-load-balancer-or-reverse-proxy).
To avoid any confusion between reverse proxy and real IP, we decided to renamed the `PROXY_REAL_IP_*` settings, you will find more information on the subject [here](/1.4/quickstart-guide/#behind-load-balancer-or-reverse-proxy).
## Default values and new settings
The default value of settings may have changed and we have added many other settings, we recommend you to read the [security tuning](/security-tuning) and [settings](/settings) sections of the documentation.
The default value of settings may have changed and we have added many other settings, we recommend you to read the [security tuning](/1.4/security-tuning) and [settings](/1.4/settings) sections of the documentation.

12
docs/plugins.md
View File

@ -18,7 +18,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Docker"
When using the [Docker integration](/integrations/#docker), plugins must be written to the volume mounted on `/data`.
When using the [Docker integration](/1.4/integrations/#docker), plugins must be written to the volume mounted on `/data`.
The first thing to do is to create the plugins folder :
```shell
@ -57,7 +57,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Docker autoconf"
When using the [Docker autoconf integration](/integrations/#docker-autoconf), plugins must be written to the volume mounted on `/data`.
When using the [Docker autoconf integration](/1.4/integrations/#docker-autoconf), plugins must be written to the volume mounted on `/data`.
The easiest way to do it is by starting the Docker autoconf stack with a folder mounted on `/data` (instead of a named volume). Once the stack is started, you can copy the plugins of your choice to the `plugins` folder from your host :
```shell
@ -73,7 +73,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Swarm"
When using the [Swarm integration](/integrations/#swarm), the easiest way of installing plugins is by using `docker exec` and downloading the plugins from the container.
When using the [Swarm integration](/1.4/integrations/#swarm), the easiest way of installing plugins is by using `docker exec` and downloading the plugins from the container.
Execute a shell inside the autoconf container (use `docker ps` to get the name) :
```shell
@ -88,7 +88,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Kubernetes"
When using the [Kubernetes integration](/integrations/#kubernetes), the easiest way of installing plugins is by using `kubectl exec` and downloading the plugins from the container.
When using the [Kubernetes integration](/1.4/integrations/#kubernetes), the easiest way of installing plugins is by using `kubectl exec` and downloading the plugins from the container.
Execute a shell inside the autoconf container (use `kubectl get pods` to get the name) :
```shell
@ -103,7 +103,7 @@ The first step is to install the plugin by putting the plugin files inside the c
=== "Linux"
When using the [Linux integration](/integrations/#linux), plugins must be written to the `/opt/bunkerweb/plugins` folder :
When using the [Linux integration](/1.4/integrations/#linux), plugins must be written to the `/opt/bunkerweb/plugins` folder :
```shell
git clone https://github.com/bunkerity/bunkerweb-plugins && \
cp -rp ./bunkerweb-plugins/* /data/plugins
@ -192,7 +192,7 @@ Each job has the following fields :
### Configurations
You can add custom NGINX configurations by adding a folder named **confs** with content similar to the [custom configurations](/quickstart-guide/#custom-configurations). Each subfolder inside the **confs** will contain [jinja2](https://jinja.palletsprojects.com) templates that will be generated and loaded at the corresponding context (`http`, `server-http` and `default-server-http`).
You can add custom NGINX configurations by adding a folder named **confs** with content similar to the [custom configurations](/1.4/quickstart-guide/#custom-configurations). Each subfolder inside the **confs** will contain [jinja2](https://jinja.palletsprojects.com) templates that will be generated and loaded at the corresponding context (`http`, `server-http` and `default-server-http`).
Here is an example for a configuration template file inside the **confs/server-http** folder named **example.conf** :

42
docs/quickstart-guide.md
View File

@ -1,7 +1,7 @@
# Quickstart guide
!!! info "Prerequisites"
We assume that you're already familiar with the [core concepts](/concepts) and you have followed the [integrations instructions](/integrations) for your environment.
We assume that you're already familiar with the [core concepts](/1.4/concepts) and you have followed the [integrations instructions](/1.4/integrations) for your environment.
!!! tip "Going further"
To demonstrate the use of BunkerWeb, we will deploy a dummy "Hello World" web application as an example. See the [examples folder](https://github.com/bunkerity/bunkerweb/tree/master/examples) of the repository to get real-world examples.
@ -16,7 +16,7 @@ The following settings can be used :
- `REVERSE_PROXY_URL` : the public path prefix
- `REVERSE_PROXY_HOST` : (internal) address of the proxied web application
You will find more settings about reverse proxy in the [settings section](/settings/#reverse-proxy) of the documentation.
You will find more settings about reverse proxy in the [settings section](/1.4/settings/#reverse-proxy) of the documentation.
### Single application
@ -92,7 +92,7 @@ You will find more settings about reverse proxy in the [settings section](/setti
=== "Docker autoconf"
We will assume that you already have the [Docker autoconf integration](/integrations/#docker-autoconf) stack running on your machine and connected to a network called bw-services.
We will assume that you already have the [Docker autoconf integration](/1.4/integrations/#docker-autoconf) stack running on your machine and connected to a network called bw-services.
You can instantiate your container and pass the settings as labels :
```shell
@ -132,7 +132,7 @@ You will find more settings about reverse proxy in the [settings section](/setti
=== "Swarm"
We will assume that you already have the [Swarm integration](/integrations/#swarm) stack running on your cluster.
We will assume that you already have the [Swarm integration](/1.4/integrations/#swarm) stack running on your cluster.
You can instantiate your service and pass the settings as labels :
```shell
@ -177,7 +177,7 @@ You will find more settings about reverse proxy in the [settings section](/setti
=== "Kubernetes"
We will assume that you already have the [Kubernetes integration](/integrations/#kubernetes) stack running on your cluster.
We will assume that you already have the [Kubernetes integration](/1.4/integrations/#kubernetes) stack running on your cluster.
Let's assume that you have a typical Deployment with a Service to access the web application from within the cluster :
```yaml
@ -240,7 +240,7 @@ You will find more settings about reverse proxy in the [settings section](/setti
=== "Linux"
We will assume that you already have the [Linux integration](/integrations/#linux) stack running on your machine.
We will assume that you already have the [Linux integration](/1.4/integrations/#linux) stack running on your machine.
The following command will run a basic HTTP server on the port 8000 and deliver the files in the current directory :
```shell
@ -383,7 +383,7 @@ You will find more settings about reverse proxy in the [settings section](/setti
=== "Docker autoconf"
We will assume that you already have the [Docker autoconf integration](/integrations/#docker-autoconf) stack running on your machine and connected to a network called bw-services.
We will assume that you already have the [Docker autoconf integration](/1.4/integrations/#docker-autoconf) stack running on your machine and connected to a network called bw-services.
You can instantiate your containers and pass the settings as labels :
=== "App #1"
@ -495,7 +495,7 @@ You will find more settings about reverse proxy in the [settings section](/setti
=== "Swarm"
We will assume that you already have the [Swarm integration](/integrations/#swarm) stack running on your cluster.
We will assume that you already have the [Swarm integration](/1.4/integrations/#swarm) stack running on your cluster.
You can instantiate your services and pass the settings as labels :
=== "App #1"
@ -623,7 +623,7 @@ You will find more settings about reverse proxy in the [settings section](/setti
=== "Kubernetes"
We will assume that you already have the [Kubernetes integration](/integrations/#kubernetes) stack running on your cluster.
We will assume that you already have the [Kubernetes integration](/1.4/integrations/#kubernetes) stack running on your cluster.
Let's also assume that you have some typical Deployments with Services to access the web applications from within the cluster :
@ -782,7 +782,7 @@ You will find more settings about reverse proxy in the [settings section](/setti
=== "Linux"
We will assume that you already have the [Linux integration](/integrations/#linux) stack running on your machine.
We will assume that you already have the [Linux integration](/1.4/integrations/#linux) stack running on your machine.
Let's assume that you have some web applications running on the same machine as BunkerWeb :
@ -848,7 +848,7 @@ The following settings can be used :
- `REAL_IP_FROM` : list of trusted IP/network address allowed to send us the "real IP"
- `REAL_IP_HEADER` : the HTTP header containing the real IP or special value "proxy_protocol" when using PROXY protocol
You will find more settings about real IP in the [settings section](/settings/#real-ip) of the documentation.
You will find more settings about real IP in the [settings section](/1.4/settings/#real-ip) of the documentation.
### HTTP header
@ -892,7 +892,7 @@ REAL_IP_HEADER=X-Forwarded-For
=== "Docker autoconf"
Before running the [Docker autoconf integration](/integrations/#docker-autoconf) stack, you will need to add the settings for the BunkerWeb container :
Before running the [Docker autoconf integration](/1.4/integrations/#docker-autoconf) stack, you will need to add the settings for the BunkerWeb container :
```shell
docker run \
...
@ -917,7 +917,7 @@ REAL_IP_HEADER=X-Forwarded-For
=== "Swarm"
Before running the [Swarm integration](/integrations/#swarm) stack, you will need to add the settings for the BunkerWeb service :
Before running the [Swarm integration](/1.4/integrations/#swarm) stack, you will need to add the settings for the BunkerWeb service :
```shell
docker service create \
...
@ -1026,7 +1026,7 @@ REAL_IP_HEADER=proxy_protocol
=== "Docker autoconf"
Before running the [Docker autoconf integration](/integrations/#docker-autoconf) stack, you will need to add the settings for the BunkerWeb container :
Before running the [Docker autoconf integration](/1.4/integrations/#docker-autoconf) stack, you will need to add the settings for the BunkerWeb container :
```shell
docker run \
...
@ -1053,7 +1053,7 @@ REAL_IP_HEADER=proxy_protocol
=== "Swarm"
Before running the [Swarm integration](/integrations/#swarm) stack, you will need to add the settings for the BunkerWeb service :
Before running the [Swarm integration](/1.4/integrations/#swarm) stack, you will need to add the settings for the BunkerWeb service :
```shell
docker service create \
...
@ -1124,7 +1124,7 @@ REAL_IP_HEADER=proxy_protocol
## Custom configurations
Because BunkerWeb is based on the NGINX web server, you can add custom NGINX configurations in different NGINX contexts. You can also apply custom configurations for the ModSecurity WAF which is a core component of BunkerWeb (more info [here](/security-tuning/#modsecurity)). Here is the list of custom configurations types :
Because BunkerWeb is based on the NGINX web server, you can add custom NGINX configurations in different NGINX contexts. You can also apply custom configurations for the ModSecurity WAF which is a core component of BunkerWeb (more info [here](/1.4/security-tuning/#modsecurity)). Here is the list of custom configurations types :
- **http** : http level of NGINX
- **server-http** : server level of NGINX
@ -1140,7 +1140,7 @@ Some integrations offer a more convenient way of applying configurations for exa
=== "Docker"
When using the [Docker integration](/integrations/#docker), custom configurations must be written to the volume mounted on /data.
When using the [Docker integration](/1.4/integrations/#docker), custom configurations must be written to the volume mounted on /data.
The first thing to do is to create the folders :
```shell
@ -1183,7 +1183,7 @@ Some integrations offer a more convenient way of applying configurations for exa
=== "Docker autoconf"
When using the [Docker autoconf integration](/integrations/#docker-autoconf), custom configurations must be written to the volume mounted on /data.
When using the [Docker autoconf integration](/1.4/integrations/#docker-autoconf), custom configurations must be written to the volume mounted on /data.
The first thing to do is to create the folders :
```shell
@ -1226,7 +1226,7 @@ Some integrations offer a more convenient way of applying configurations for exa
=== "Swarm"
When using the [Swarm integration](/integrations/#swarm), custom configurations are managed using [Docker Configs](https://docs.docker.com/engine/swarm/configs/).
When using the [Swarm integration](/1.4/integrations/#swarm), custom configurations are managed using [Docker Configs](https://docs.docker.com/engine/swarm/configs/).
To keep it simple, you don't even need to attach the Config to a service : the autoconf service is listening for Config events and will update the custom configurations when needed.
@ -1249,7 +1249,7 @@ Some integrations offer a more convenient way of applying configurations for exa
=== "Kubernetes"
When using the [Kubernetes integration](/integrations/#kubernetes), custom configurations are managed using [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/).
When using the [Kubernetes integration](/1.4/integrations/#kubernetes), custom configurations are managed using [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/).
To keep it simple, you don't even need to use the ConfigMap with a Pod (e.g. as environment variable or volume) : the autoconf Pod is listening for ConfigMap events and will update the custom configurations when needed.
@ -1278,7 +1278,7 @@ Some integrations offer a more convenient way of applying configurations for exa
=== "Linux"
When using the [Linux integration](/integrations/#linux), custom configurations must be written to the /opt/bunkerweb/configs folder.
When using the [Linux integration](/1.4/integrations/#linux), custom configurations must be written to the /opt/bunkerweb/configs folder.
Here is an example for server-http/hello-world.conf :
```conf

6
docs/security-tuning.md
View File

@ -1,9 +1,9 @@
# Security tuning
BunkerWeb offers many security features that you can configure with [settings](/settings). Even if the default values of settings ensure a minimal "security by default", we strongly recommend you to tune them. By doing so you will be able to ensure a security level of your choice but also manage false positives.
BunkerWeb offers many security features that you can configure with [settings](/1.4/settings). Even if the default values of settings ensure a minimal "security by default", we strongly recommend you to tune them. By doing so you will be able to ensure a security level of your choice but also manage false positives.
!!! tip "Other settings"
This section only focuses on security tuning, see the [settings section](/settings) of the documentation for other settings.
This section only focuses on security tuning, see the [settings section](/1.4/settings) of the documentation for other settings.
## HTTP protocol
@ -117,7 +117,7 @@ ModSecurity is integrated and enabled by default alongside the OWASP Core Rule S
We strongly recommend keeping both ModSecurity and the OWASP Core Rule Set enabled. The only downsides are the false positives that may occur. But they can be fixed with some efforts and the CRS team maintains a list of exclusions for common applications (e.g., WordPress, Nextcloud, Drupal, Cpanel, ...).
Tuning ModSecurity and the CRS can be done using [custom configurations](/quickstart-guide/#custom-configurations) :
Tuning ModSecurity and the CRS can be done using [custom configurations](/1.4/quickstart-guide/#custom-configurations) :
- modsec-crs : before the OWASP Core Rule Set is loaded
- modsec : after the OWASP Core Rule Set is loaded (also used if CRS is not loaded)

2
docs/settings.md
View File

@ -4,7 +4,7 @@
To help you tuning BunkerWeb we have made an easy to use settings generator tool available at [config.bunkerweb.io](https://config.bunkerweb.io).
This section contains the full list of settings supported by BunkerWeb. If you are not familiar with BunkerWeb, you should first read the [concepts](/concepts) section of the documentation. Please follow the instructions for your own [integration](/integrations) on how to apply the settings.
This section contains the full list of settings supported by BunkerWeb. If you are not familiar with BunkerWeb, you should first read the [concepts](/1.4/concepts) section of the documentation. Please follow the instructions for your own [integration](/1.4/integrations) on how to apply the settings.
As a general rule when multisite mode is enabled, if you want to apply settings with multisite context to a specific server you will need to add the primary (first) server name as a prefix like `www.example.com_USE_ANTIBOT=captcha` or `myapp.example.com_USE_GZIP=yes` for example.

8
docs/troubleshooting.md
View File

@ -83,7 +83,7 @@ Here is how you can access the logs depending on your integration :
## Permissions
Don't forget that BunkerWeb runs as an unprivileged user for obvious security reasons. Double-check the permissions of files and folders used by BunkerWeb especially if you use custom configurations (more info [here](/quickstart-guide/#custom-configurations)). You will need to set at least **RW** rights on files and **_RWX_** on folders.
Don't forget that BunkerWeb runs as an unprivileged user for obvious security reasons. Double-check the permissions of files and folders used by BunkerWeb especially if you use custom configurations (more info [here](/1.4/quickstart-guide/#custom-configurations)). You will need to set at least **RW** rights on files and **_RWX_** on folders.
## ModSecurity
@ -174,11 +174,11 @@ As we can see there are 3 different logs :
One important thing to understand is that rule **949110** is not a "real" one : it's the one that will deny the request because the anomaly threshold is reached (which is **10** in this example). You should never remove the **949110** rule !
If it's a false-positive you should then focus on both **930120** and **932160** rules. ModSecurity and/or CRS tuning is out of the scope of this documentation but don't forget that you can apply custom configurations before and after the CRS is loaded (more info [here](/quickstart-guide/#custom-configurations)).
If it's a false-positive you should then focus on both **930120** and **932160** rules. ModSecurity and/or CRS tuning is out of the scope of this documentation but don't forget that you can apply custom configurations before and after the CRS is loaded (more info [here](/1.4/quickstart-guide/#custom-configurations)).
## Bad Behavior
A common false-positive case is that the client is banned because of the "bad behavior" feature which means that too many suspicious HTTP status codes were generated within a time period (more info [here](/security-tuning/#bad-behavior)). You should start by reviewing the settings and edit them according to your web application(s) like removing a suspicious HTTP code, decreasing the count time, increasing the threshold, ...
A common false-positive case is that the client is banned because of the "bad behavior" feature which means that too many suspicious HTTP status codes were generated within a time period (more info [here](/1.4/security-tuning/#bad-behavior)). You should start by reviewing the settings and edit them according to your web application(s) like removing a suspicious HTTP code, decreasing the count time, increasing the threshold, ...
## IP unban
@ -231,7 +231,7 @@ You can manually unban an IP which can be useful when doing some tests but it ne
## Whitelisting
If you have bots that need to access your website, the recommended way to avoid any false positive is to whitelist it using the [whitelisting feature](/security-tuning/#blacklisting-and-whitelisting). We don't recommend using the `WHITELIST_URI*` or `WHITELIST_USER_AGENT*` settings unless they are set to secret and unpredictable values. Common use cases are :
If you have bots that need to access your website, the recommended way to avoid any false positive is to whitelist it using the [whitelisting feature](/1.4/security-tuning/#blacklisting-and-whitelisting). We don't recommend using the `WHITELIST_URI*` or `WHITELIST_USER_AGENT*` settings unless they are set to secret and unpredictable values. Common use cases are :
- Healthcheck / status bot
- Callback like IPN or webhook

8
docs/web-ui.md
View File

@ -32,11 +32,11 @@ Because the web UI is a web application, the recommended installation procedure
* Choose a strong password for the login
* Put the web UI under a "hard to guess" URI
* Do not open the web UI on the Internet without any further restrictions
* Apply settings listed in the [security tuning section](/security-tuning/) of the documentation
* Apply settings listed in the [security tuning section](/1.4/security-tuning/) of the documentation
!!! info "Multisite mode"
The installation of the web UI implies enabling the [multisite mode](/concepts/#multisite-mode).
The installation of the web UI implies enabling the [multisite mode](/1.4/concepts/#multisite-mode).
!!! info "UI specific env variables"
@ -45,7 +45,7 @@ Because the web UI is a web application, the recommended installation procedure
=== "Docker"
When using the [Docker integration](/integrations/#docker), we recommend you to connect the BunkerWeb and web UI using a dedicated network and use another dedicated network for the communications between BunkerWeb and your web applications. The web UI can be deployed using a dedicated container based on the [bunkerweb-ui image](https://hub.docker.com/r/bunkerity/bunkerweb-ui).
When using the [Docker integration](/1.4/integrations/#docker), we recommend you to connect the BunkerWeb and web UI using a dedicated network and use another dedicated network for the communications between BunkerWeb and your web applications. The web UI can be deployed using a dedicated container based on the [bunkerweb-ui image](https://hub.docker.com/r/bunkerity/bunkerweb-ui).
Let's start by creating the networks (replace 10.20.30.0/24 with an unused network of your choice) :
```shell
@ -194,7 +194,7 @@ Because the web UI is a web application, the recommended installation procedure
=== "Linux"
The installation of the web UI using the [Linux integration](/integrations/#linux) is pretty straightforward because it is installed with BunkerWeb.
The installation of the web UI using the [Linux integration](/1.4/integrations/#linux) is pretty straightforward because it is installed with BunkerWeb.
The first thing to do is to edit the BunkerWeb configuration located at **/opt/bunkerweb/variables.env** to add settings related to the web UI :
```conf