Nginx on slash-root.fr

Docker-Compose : Nginx Proxy Manager

Mon, 13 Dec 2021 11:41:08 +0100

docker-compose.yml

version: '3'
services:
 app:
 image: 'jc21/nginx-proxy-manager:latest'
 container_name: npm
 restart: unless-stopped
 ports:
 - '80:80'
 - '8082:81'
 - '443:443'
 volumes:
 - ./data:/data
 - ./letsencrypt:/etc/letsencrypt

Credentials

Email: admin@example.com
Password: changeme

LemonLDAP : Activer le HTTPS + Reverse-Proxy

Sat, 20 Nov 2021 15:36:41 +0100

Apache / Nginx configuration

La 1ère chose à faire est de configurer le serveur web pour le passer en HTTPS.

Suivre cet article par exemple : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS - slash-root.fr

LemonLDAP configuration

La 2nde étape est de configurer les URL en HTTPS pour le portail, cookie, ...

A exécuter en tant que root :

/usr/share/lemonldap-ng/bin/lemonldap-ng-cli -yes 1 \
 set \
 portal https://auth.example.com \
 mailUrl https://auth.example.com/resetpwd \
 registerUrl https://auth.example.com/register \
 https 1 \
 securedCookie 1

Reverse-Proxy configuration

Nginx : Reverse Proxy avec SSL - slash-root.fr

Si le portail est derrière un reverse-proxy en HTTPS, il est impératif d'effectuer les manipulations plus haut.

Exemple d'un vhost sous Nginx pour le portail :

server {
listen 80;
server_name auth.example.fr;
rewrite ^ https://auth.example.fr permanent;
}

server {
listen 443 ssl;
server_name auth.example.fr;
ssl_certificate /etc/letsencrypt/live/auth.example.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/auth.example.fr/privkey.pem;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;

error_log /var/log/nginx/error.log;

location / {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_pass http://192.168.49.68:80;
}
}

Exemple d'un vhost sous Nginx pour le manager :

server {
listen 80;
server_name manager.example.fr;
rewrite ^ https://manager.example.fr permanent;
}

server {
listen 443 ssl;
server_name manager.example.fr;
ssl_certificate /etc/letsencrypt/live/manager.example.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/manager.example.fr/privkey.pem;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;

location / {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_pass http://192.168.49.68:80;
}
}

Le serveur web doit être compilé avec le module --with-http_realip_module.

Pour vérifier :

nginx -V

## Retour attendu :
nginx version: nginx/1.14.2
built with OpenSSL 1.1.1d 10 Sep 2019
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-m1Thpq/nginx-1.14.2=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-auth-pam --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-dav-ext --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-echo --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-upstream-fair --add-dynamic-module=/build/nginx-m1Thpq/nginx-1.14.2/debian/modules/http-subs-filter

Fail2ban : Protéger l’authentification WordPress sous Nginx

Tue, 26 Oct 2021 02:43:26 +0200

Introduction

WordPress est une application web extrêmement populaire. Il existe de nombreuses attaques de brute-force sur la page de login de WordPress. Ces attaques peuvent générées des milliers de tentatives de login à votre application WordPress.

Cet article fait suite à Fail2ban : Installation et configuration.

Par défaut fail2ban est embarqué avec de nombreuses jails mais aucune pour protéger l'authentification de WordPress. Avant de configurer une jail pour WordPress, il va falloir faire quelques modifications en son sein. En effet par défaut, lorsqu'un utilisateur tente de s'authentifier, un message s'affiche à l'écran indiquant une erreur mais surtout la page retourne un code HTTP 200 (le même que celui lors d'un succès d'authentification). Cela sera modifié.

Configuration

Prérequis

L'installation et les explications sur la configuration général de fail2ban est décrite dans cet article : Fail2ban : Installation et configuration.
Fail2ban doit être installé et fonctionnel.

Modification du code HTTP

Comme expliqué en introduction, lors d'un échec d'authentification sur la page de login de WordPress, celui-ci génère un code http identique à celui d'un succès.

Modifier le fichier functions.php de votre thème WordPress pour y inclure :

/* Change WP-Admin login error message to be more generic */
function generic_login_msg ($msg) {
 global $errors;
 $err_codes = $errors->get_error_codes();
 if ( in_array( 'invalid_username', $err_codes ) || in_array('incorrect_password', $err_codes )) {
 $msg = 'ERROR: Invalid credential.';
 }
 return $msg;
}
add_filter('login_errors', 'generic_login_msg');

/* Return 403 instead of 200 when wp-login failed */
add_action( 'wp_login_failed', function () { 
 status_header(403); 
} );

Cela aura pour effet d'indiquer un message générique sur la page lors d'un échec d'authentification et surtout de générer un code HTTP 403. Le code HTTP 200 sera toujours le code retour lors d'un succès d'authentification.

11.22.33.44 - - [26/Oct/2021:01:52:10 +0200] "POST /wp-login.php HTTP/1.1" 403 3149 "https://wordpress.example.com/wp-login.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36 Edg/95.0.1020.30"

Création du filtre fail2ban

Fail2ban n'a pas de preset de filtre pour l'authentification de WordPress. Créer un filtre :
```
sudo vi /etc/fail2ban/filter.d/wp-login.conf
```
Ajouter le filtre suivant :
```
[Definition]
_daemon = wp-login
failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).* 403
```
failregex va matcher sur les requêtes POST à destination de wp-login.php et xmlrpc.php portant un code HTTP 403.

Ajouter la jail dans /etc/fail2ban/jail.local :

[wordpress]
enabled = true
port = http,https
filter = wp-login
logpath = /var/log/nginx/access.log

Redémarrer fail2ban :
```
sudo systemctl restart fail2ban
```
Vérifier la prise en compte de la jail avec :
```
sudo fail2ban-client status
```

Le retour doit être :

Status
|- Number of jail: 1
`- Jail list: wordpress

Keycloak : Installation avec Docker et reverse-proxy SSL Nginx

Mon, 25 Oct 2021 17:37:16 +0200

Introduction

Keycloak est une solution opensource permettant d'implémenter du SSO (Single-Sign-On) au sein d'une infrastructure. Il est compatible avec les principaux protocoles d'authentification (OAuth2.0, OpenID-Connect). Il peut être couplé à un annuaire LDAP.

Dans cet article, Keycloak, va être déployé sur une Debian 10 conteneurisé dans 2 images dockers. Docker-Compose va orchestrer le tout. Un serveur nginx sera en frontal en tant que reverse-proxy.

Prérequis

1 serveur Debian 10 à jour qui sera dédié à hébergé le serveur Keycloack
1 serveur web Nginx opérationnel
Certificats SSL générés pour votre nom de domaine

Voir article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS

Installation

Installation des paquets

Installer docker :
```
sudo apt install docker
```
Installer docker-compose :
```
sudo apt install docker-compose
```
Vérifier l'installation de docker-compose :
```
docker-compose --version
```

Création du docker-compose

Créer un répertoire afin d'y stocker le fichier docker-compose :
```
sudo mkdir keycloak
```
Se positionner dans le répertoire nouvellement créé :
```
cd keycloak
```
Créer un fichier docker-compose.yml :
```
sudo vi docker-compose.yml
```

Attention, le fichier doit être au format YAML ce qui signifie que la tabulation est interdite (il faut mettre des espaces pour l'indentation).

Copier / Coller le fichier suivant :

version: '3.3'

volumes:
postgres_data:
 driver: local

services:
postgres:
 image: postgres
 volumes:
 - postgres_data:/var/lib/postgresql/data
 environment:
 POSTGRES_DB: keycloak
 POSTGRES_USER: keycloak
 POSTGRES_PASSWORD: password
keycloak:
 image: jboss/keycloak:latest
 environment:
 PROXY_ADDRESS_FORWARDING: 'true'
 DB_VENDOR: POSTGRES
 DB_ADDR: postgres
 DB_DATABASE: keycloak
 DB_USER: keycloak
 DB_PASSWORD: password
 KEYCLOAK_USER: admin
 KEYCLOAK_PASSWORD: Mon_mot_de_passe
 ports:
 - 9090:8080
 depends_on:
 - postgres

Le numéro de version indiqué en 1ère ligne peut varier suivant votre version de docker-compose. Dans mon cas, j'ai une version de docker-compose en 1.21.0.

Le port de keycloak dans le conteneur est le 8080, il sera bind sur le 9090 du serveur.

La directive PROXY_ADDRESS_FORWARDING est très importante dans le cas d'une utilisation de reverse proxy.

Lancement du docker-compose

Exécuter le docker-compose :

sudo docker-compose -f ~/keycloak/docker-compose.yml up

Pour lancer le docker-compose en arrière-plan :

sudo docker-compose -f ~/keycloak/docker-compose.yml up -d

Vérifier que les conteneurs docker soient bien démarrés :
```
sudo docker ps
```

Le résultat soit être similaire à :

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
643f26101b75 jboss/keycloak:latest "/opt/jboss/tools/do…" About a minute ago Up 52 seconds 8443/tcp, 0.0.0.0:9090->8080/tcp keycloak_keycloak_1
6789a8285283 postgres "docker-entrypoint.s…" About a minute ago Up 52 seconds 5432/tcp keycloak_postgres_1

Configuration reverse-proxy SSL avec Nginx

Un serveur Nginx doit être opérationnel.

S'appuyer sur cet article : Nginx : Installation d’un Reverse Proxy
Les certificats SSl doivent être générés.

S'appuyer sur cet article : Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS
Créer le fichier de configuration du virtual host :
```
sudo vi /etc/nginx/sites-available/keycloak.conf
```

Copier / Coller le fichier suivant :

server {
 listen 80;
 server_name keycloak.example.com;
 rewrite ^ https://keycloak.example.com permanent;
}

server {
 listen 443 ssl;
 server_name keycloak.example.com;
 ssl_certificate /etc/letsencrypt/live/keycloak.example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/keycloak.example.com/privkey.pem;
 ssl_session_cache builtin:1000 shared:SSL:10m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
 ssl_prefer_server_ciphers on;

 location / {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_pass http://IP_MON_SERVEUR_KEYCLOACK:9090;
 }

}

Remplacer keycloak.example.com par le nom de domaine pour le serveur keycloak. Le nécessaire doit être fait au sein de la zone DNS.

Vérifier les chemins d'accès aux certificats SSL.

Modifier la directive proxy_pass pour correspondre avec le serveur keycloak.

Créer un lien symbolique pour activer le virtual host :

sudo ln -s /etc/nginx/sites-available/keycloak.conf /etc/nginx/sites-enabled/keycloak.conf

Vérifier la configuration de Nginx avec :
```
sudo nginx -t
```
Redémarrer le service nginx :
```
sudo systemctl restart nginx
```

Accès administrateur à Keycloak

Se rendre à l'adresse : https://keycloak.example.com
Accéder à Administration Console :

Les credentials à entrer sont ceux définit dans le fichier docker-compose.yml aux lignes suivantes :
 KEYCLOAK_USER: admin
 KEYCLOAK_PASSWORD: Mon_mot_de_passe

Démarrage automatique avec le système

Avec la configuration actuelle au redémarrage du serveur keycloak, le docker-compose ne sera pas lancé.
Pour activer le démarrage automatique des conteneurs Postegresql et Keycloak au boot du serveur, modifier le docker-compose.yml et ajouter cette ligne dans chaque services qui doit démarrer avec le service docker :
```
restart: always
```
Si les conteneurs sont arrêtés à la main, ils ne démarreront pas automatiquement. Docker comprend que c'est une action manuelle et que c'est l'état désiré.
Pour que cela soit fonctionnel, le service docker.service doit être en status enable :
```
sudo systemctl status docker.service
```

Le résultat doit être le suivant :

Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)

Si cela n'est pas le cas :
```
sudo systemctl enable docker.service
```

Nginx : Reverse Proxy avec SSL

Fri, 15 Oct 2021 15:00:06 +0200

Pré-requis

Avoir suivi : Nginx : Installation d’un Reverse Proxy
Avoir suivi : Nginx : Ajouter un certificat SSL Lets Encrypt pour passer en HTTPS

Nginx configuration

Editez le fichier de configuration du reverse proxy :

sudo vim /etc/nginx/sites-available/reverse-proxy.example.conf

En principe, après avoir suivi l'installation d'un reverse proxy avec Nginx, le server block suivant va être modifié :

server {
 listen 80;
 server_name blog.example.com;

 location / {
 proxy_pass http://172.0.1.10:80;
 }
}

En premier lieu, nous allons réécrire l'url de http://blog.example.com en https://blog.example.conf, pour cela nous allons modifié le server block précédent en :

server {
 listen 80;
 server_name blog.example.com;
 rewrite ^ https://blog.example.com permanent;
 }

Ajouter un nouveau server block pour permettre de faire du reverse proxy SSL comme suit :

server {
 listen 443 ssl;
 server_name blog.example.com;
 ssl_certificate /etc/letsencrypt/live/blog.example.com/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/blog.example.com/privkey.pem;
 ssl_session_cache builtin:1000 shared:SSL:10m;
 ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
 ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
 ssl_prefer_server_ciphers on;

 location / {
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_pass https://172.0.1.10:443;
 proxy_read_timeout 90;
 }
}

ssl_certificate et ssl_certificate_key contiendront le chemin d'accès au certificat et à la clef privée. Bien entendu, il faudra les transféré sur le serveur reverse proxy au bon endroit avec les bonnes permissions. Générer un certificat wildcard est fortement recommandé si vous souhaitez développer plusieurs sous-domaine. Cette partie ne sera pas détaillé dans ce tutorial ainsi que la gestion de son renouvelement.

proxy_pass : L'URL http / https vers le serveur hébergeant blog.example.com.

Vérifiez la configuration de Nginx avec :

sudo nginx -t

Aucune erreur ne doit être retournée :

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Redémarrer le serveur reverse proxy :

sudo systemctl restart nginx

Nginx : Ajouter un certificat SSL Let’s Encrypt pour passer en HTTPS

Fri, 15 Oct 2021 14:05:01 +0200

Installation de Certbot pour Nginx

Installez les deux paquets nécessaires à l'utilisation de Certbot sous Debian avec un serveur Nginx :

sudo apt install certbot python3-certbot-nginx

Let’s Encrypt : Demander un certificat SSL pour Nginx

Effectuez une demande de certificat :

sudo certbot --nginx -d www.example.com

--nginx : Pour spécifier que l'on utilise un serveur web sous Nginx

-d www.example.com : Pour préciser le nom de domaine

Votre adresse e-mail vous sera demandé. Un e-mail vous sera envoyé dans le cas où le certificat ne parvient pas à se renouveler automatiquement avant expiration.

Il vous sera demandé si vous souhaitez rediriger automatiquement le traffic HTTP vers HTTPS :

Si tout se passe bien, un message de congratulations doit apparaitre :

Il a noté que dans le message final, les emplacements du certificat, clef privée, etc... sont également indiquées.

Certbot c'est occupé de configurer automatiquement le bloc server correspondant.

Vous pouvez aller voir les modifications apportées par Certbot dans le fichier de configuration de votre site. Les ajouts / modifications apportés par Certbot seront commentés en fin de ligne par # managed by Certbot

Renouvellement automatique du certificat SSL

Un certificat Let's Encrypt a une durée de validité de 90 jours.
Certbot va s'occuper tout seul du renouvellement de celui-ci.
Une tâche cron a été créée automatiquement par Certbot. Pour se rassurer :

sudo vim /etc/cron.d/certbot

La tâche planifiée va s'exécuter de façon à renouveler le certificat avant qu'il expire.

Il est possible de faire une simulation de renouvellement du certificat :

sudo certbot renew --dry-run

--dry-run : Permet de faire une simulation

Le message "Congratulations, all renewals succeded." doit apparaitre si la simulation du renouvellement du certificat est un succès.

La tâche planifiée va s'occuper de gérer cette opération à notre place. En cas de soucis, un e-mail sera envoyé à l'adresse indiqué lors de la demande de certificat.

Nginx : Installation d’un Reverse Proxy

Fri, 15 Oct 2021 13:50:26 +0200

Préambule

Un des outils reverse proxy le + populaires du moment est Nginx
Un reverse proxy est un serveur positionné entre les applications web internes et les utilisateurs extérieurs. Le reverse proxy aiguille les requêtes des utilisateurs vers le serveur approprié.
Le service reverse proxy agis comme un front-end qui traite toutes les requetes clientes entrantes et les distribue vers le back-end, bdd, ou autres serveurs. Puis il redirige les réponses en retour vers le client.
Nginx en tant que reverse proxy permet :
- Load balancing
- Améliore la sécurité
- Meilleur performance
- Point de terminaison SSL

Installation d’un reverse proxy avec Nginx

Une Debian 10 sera utilisée avec 4GB de RAM, 2 vCPU, 20GB de disque

Installer Nginx

Installer Nginx :
```
sudo apt install nginx
```
Après l'installation, vous pouvez vérifier que Nginx c'est correctement installé en vérifiant la version :
```
nginx -v
```

Configurer Nginx

Nous allons considérer que le site principal example.com est sur le même serveur que notre Nginx. Un site WordPress est disponible sur un sous domaine blog.example.com hébergé sur un serveur différent ayant l'adresse IP 172.0.1.10
Nous devons configurer un reverse proxy avec Nginx pour rediriger les requêtes à destination de blog.example.com vers le serveur 172.0.1.10
Désactivez le vhost pré-configuré par défaut :
```
unlink /etc/nginx/sites-enabled/default
```
Rendez-vous dans le répertoire /etc/nginx/sites-available et créez le fichier de configuration du reverse proxy :
```
cd /etc/nginx/sites-available
sudo vim example.conf
```

Collez cette configuration Nginx :

server {
listen 80;
server_name example.com www.example.com;

location / {
 try_files $uri $uri/ /index.php?$query_string;
}
}

server {
listen 80;
server_name blog.example.com;

location / {
 proxy_set_header X-Forwarded-Host $host:$server_port;
 proxy_set_header X-Forwarded-Server $host;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_pass http://172.0.1.10:80;
}
}

Dans cet exemple, le site example.com et www.example.com reste accessible sur la même instance Nginx. Par contre, Nginx redirige toutes les connexions entrantes pour blog.example.com sur le port 80 vers le serveur 127.0.1.10 écoutant sur le port 80

Sauvegardez le fichier et activez le en créant un lien symbolique :

sudo ln -s /etc/nginx/sites-available/example.conf /etc/nginx/sites-enabled/

Testez Nginx pour d'éventuelles erreurs de configuration :

sudo nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Si aucune erreur, redémarrez Nginx pour prendre en compte les modifications :
```
sudo systemctl restart nginx
```
C'est terminé !