URL:     https://linuxfr.org/news/bunkerized-nginx-securisez-facilement-et-sans-tracas-vos-services-web
Title:   bunkerized-nginx - Sécurisez facilement et sans tracas vos services web
Authors: 
         Julien Jorge, Ysabeau, palm123 et devnewton
Date:    2021-04-28T11:05:35+02:00
License: CC By-SA
Tags:    
Score:   8


C’est quoi bunkerized-nginx ?
===========



C’est un outil qui va vous éviter de devoir suivre les bonnes pratiques de sécurité à chaque fois que vous avez besoin d’un serveur web ou d’un reverse proxy en frontal de vos services web. Bunkerized-nginx se présente sous la forme d’une image Docker et va s’occuper des paramètres et configurations pour vous. Le but final est d’atteindre une sécurité « par défaut » sans (trop) d’action de votre part.



![bunkerized-nginx](https://github.com/bunkerity/bunkerized-nginx/blob/master/logo.png?raw=true)



----

[Projet GitHub](https://github.com/bunkerity/bunkerized-nginx/)
[Demo en ligne](https://demo-nginx.bunkerity.com)
[Documentation](https://github.com/bunkerity/bunkerized-nginx/blob/master/README.md)
[Exemples](https://github.com/bunkerity/bunkerized-nginx/tree/master/examples)

----

Liste non exhaustive des fonctionnalités :



- support du HTTPS et Let's Encrypt automatique ;
- bonnes pratiques de sécurité web : entêtes HTTP, éviter les fuites d’info, durcissement de TLS… ;
- ModSecurity intégré avec les règles OWASP Core Rule Set ;
- bannissement des comportements « suspects » avec fail2ban ;
- détection de robots avec des « challenges » (cookie, JavaScript, CAPTCHA…) ;
- blocage des nœuds de sortie TOR, des « mauvais » User-Agent, des pays de votre choix… ;
- blocage des IPs connues comme malveillantes via des listes noires externes (DNSBL, CrowdSec…) ;
- prévention des attaques par bruteforce en limitant les requêtes ;
- détection des fichiers « mauvais » avec ClamAV à l’upload;
- facile à configurer avec des variables d’environnement ou une interface web ;
- configuration automatique possible via des « labels » ;
- support de Docker Swarm.



L’outil permet de duper facilement les outils automatisés comme vous pouvez le voir [ici](https://github.com/bunkerity/bunkerized-nginx/blob/master/demo.gif).



Il y a une démo en ligne ici : [demo bunkerized-nginx](https://demo-nginx.bunkerity.com). N’hésitez pas à faire des tests de sécurité dessus.



Comment ça fonctionne ?
===========



En lien avec PHP
-----------



```shell
docker network create mynet

docker run --network mynet \
           -p 80:8080 \
           -v /path/to/web/files:/www:ro \
           -e REMOTE_PHP=myphp \
           -e REMOTE_PHP_PATH=/app \
           bunkerity/bunkerized-nginx

docker run --network mynet \
           --name myphp \
           -v /path/to/web/files:/app \
           php:fpm
```






Les fichiers web sont stockés dans le dossier /www à l’intérieur du conteneur. Veuillez noter que bunkerized-nginx ne tourne pas en root (pour des raisons évidentes de sécurité) mais avec un utilisateur non privilégié ayant comme UID 101 et comme GID 101. Il faut donc mettre les droits sur /path/to/web/files en conséquence.



La variable d’environnement `REMOTE_PHP` permet de définir l’adresse d’une instance PHP-FPM qui va exécuter les fichiers PHP. Tandis que la variable `REMOTE_PHP_PATH` permet de définir le chemin utilisé par l’instance PHP-FPM pour chercher les fichiers.



HTTPS avec Let's Encrypt automatique
-----------



```shell
docker run -p 80:8080 \
           -p 443:8443 \
           -v /path/to/web/files:/www:ro \
           -v /where/to/save/certificates:/etc/letsencrypt \
           -e SERVER_NAME=www.yourdomain.com \
           -e AUTO_LETS_ENCRYPT=yes \
           -e REDIRECT_HTTP_TO_HTTPS=yes \
           bunkerity/bunkerized-nginx
```






Les certificats sont stockés dans le répertoire /etc/letsencrypt à l’intérieur du conteneur. Il est conseillé de les stocker en local pour pouvoir les réutiliser en cas de redémarrage du conteneur. Veuillez noter que bunkerized-nginx ne tourne pas en root (pour des raisons évidentes de sécurité) mais avec un utilisateur non privilégié ayant comme UID 101 et comme GID 101. Il faut donc mettre les droits sur /where/to/save/certificates en conséquence.



Si vous ne voulez pas que bunkerized-nginx écoute en HTTP, vous pouvez rajouter la variable d’environnement `LISTEN_HTTP=no` (seulement du HTTPS par exemple). Par contre, Let's Encrypt a besoin du port 80 pour résoudre les challenges, il faut donc garder la redirection.



Ici nous avons 3 variables d’environnement :
- `SERVER_NAME` : il s’agit du FQDN de votre service (qui doit pointer vers l’adresse IP de votre serveur pour que Let's Encrypt fonctionne)
- `AUTO_LETS_ENCRYPT` : active la création et le renouvellement automatique de certificats via Let's Encrypt
- `REDIRECT_HTTP_TO_HTTPS` : active la redirection HTTP vers HTTPS



En tant que reverse proxy
-----------



```shell
docker run -p 80:8080 \
           -e USE_REVERSE_PROXY=yes \
           -e REVERSE_PROXY_URL=/ \
           -e REVERSE_PROXY_HOST=http://myserver:8080 \
           bunkerity/bunkerized-nginx
```







Il s’agit d’un cas assez simple où il n’y a qu’une seule application derrière le reverse proxy. Si vous en avez plus d’une, vous pouvez utiliser plusieurs fois les variables d’environnement REVERSE_PROXY_URL/REVERSE_PROXY_HOST en rajoutant un nombre à la fin comme ceci :



```shell
docker run -p 80:8080 \
           -e USE_REVERSE_PROXY=yes \
           -e REVERSE_PROXY_URL_1=/app1/ \
           -e REVERSE_PROXY_HOST_1=http://myapp1:3000/ \
           -e REVERSE_PROXY_URL_2=/app2/ \
           -e REVERSE_PROXY_HOST_2=http://myapp2:3000/ \
           bunkerity/bunkerized-nginx
```







Multisite
-----------



Par défaut, bunkerized-nginx va seulement créer une seule configuration « serveur » (un seul bloc « server » sera créé dans la configuration nginx). En mettant la variable d’environnement `MULTISITE` avec la valeur `yes`, une configuration « serveur » sera créée pour chaque hôte présent dans la variable d’environnement `SERVER_NAME`. De plus, vous pouvez définir des configurations différentes pour chaque service en préfixant les variables par le FQDN comme ceci :



```shell
docker run -p 80:8080 \
           -p 443:8443 \
           -v /where/to/save/certificates:/etc/letsencrypt \
           -e SERVER_NAME=app1.domain.com app2.domain.com \
           -e MULTISITE=yes \
           -e AUTO_LETS_ENCRYPT=yes \
           -e REDIRECT_HTTP_TO_HTTPS=yes \
           -e USE_REVERSE_PROXY=yes \
           -e app1.domain.com_REVERSE_PROXY_URL=/ \
           -e app1.domain.com_REVERSE_PROXY_HOST=http://myapp1:8000 \
           -e app2.domain.com_REVERSE_PROXY_URL=/ \
           -e app2.domain.com_REVERSE_PROXY_HOST=http://myapp2:8000 \
           bunkerity/bunkerized-nginx
```







`USE_REVERSE_PROXY` est donc appliquée « globalement » pour chaque serveur. Par contre les variables d’environnement `app1.domain.com_*` et `app2.domain.com_*` sont seulement appliquées pour app1.domain.com et app2.domain.com respectivement.



Quand bunkerized-nginx doit lire des fichiers et que `MULTISITE` a pour valeur `yes`, le répertoire /www contiendra un sous-dossier par service et chaque sous-dossier aura pour nom le FQDN correspondant dans la variable `SERVER_NAME`. Prenons cet exemple :



```shell
docker run -p 80:8080 \
           -p 443:8443 \
           -v /where/to/save/certificates:/etc/letsencrypt \
           -v /where/are/web/files:/www:ro \
           -e SERVER_NAME=app1.domain.com app2.domain.com \
           -e MULTISITE=yes \
           -e AUTO_LETS_ENCRYPT=yes \
           -e REDIRECT_HTTP_TO_HTTPS=yes \
           -e app1.domain.com_REMOTE_PHP=php1 \
           -e app1.domain.com_REMOTE_PHP_PATH=/app \
           -e app2.domain.com_REMOTE_PHP=php2 \
           -e app2.domain.com_REMOTE_PHP_PATH=/app \
           bunkerity/bunkerized-nginx
```







Dans ce cas, le répertoire /where/are/web/files devra avoir une structure comme celle-ci :



```shell
/where/are/web/files
├── app1.domain.com
│   └── index.php
│   └── ...
└── app2.domain.com
    └── index.php
    └── ...
```







Aller plus loin
===========



Bunkerized-nginx permet de faire bien plus que ce soit la [configuration automatique avec des labels](https://github.com/bunkerity/bunkerized-nginx#automatic-configuration), [l’intégration dans un environnement Docker Swarm](https://github.com/bunkerity/bunkerized-nginx#swarm-mode) ou même l’utilisation d’une [interface web pour configurer les services](https://github.com/bunkerity/bunkerized-nginx#web-ui). Tout est expliqué dans le README du [projet GitHub](https://github.com/bunkerity/bunkerized-nginx).



Veuillez noter qu’énormément d’éléments de sécurité sont activés avec des valeurs par défaut. Mais vous pouvez tout configurer comme bon vous semble. Pour plus d’informations vous pouvez consulter la [liste des variables d’environnement](https://github.com/bunkerity/bunkerized-nginx#list-of-environment-variables).



Il y a aussi des exemples concrets accompagnés de fichiers docker-compose.yml prêts à l’emploi dans le [dossier examples](https://github.com/bunkerity/bunkerized-nginx/tree/master/examples) sur GitHub.