First commit -clean
This commit is contained in:
252
content/3.serveex/3.securite/1.wireguard.md
Normal file
252
content/3.serveex/3.securite/1.wireguard.md
Normal file
@ -0,0 +1,252 @@
|
||||
---
|
||||
navigation: true
|
||||
title: Wireguard
|
||||
main:
|
||||
fluid: false
|
||||
---
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px}
|
||||
# Wireguard
|
||||
|
||||
::alert{type="info"}
|
||||
🎯 __Objectifs :__
|
||||
- Installer Wireguard
|
||||
- Configurer les clients
|
||||
- Accéder au réseau sécurisé
|
||||
::
|
||||
|
||||
## Introduction
|
||||
---
|
||||
L'utilisation d'un VPN permet d'accéder à distance aux ressources locales du serveur sans les exposer sur internet. C'est notamment une manière propre de sécuriser l'accès à la console SSH, plutot que d'exposer le port sur internet. C'est pouvoir se connecter à son réseau où que l'on soit, de maniere sécurisée, et de faire dialoguer des machines qui sont sur des réseaux différents.
|
||||
|
||||
Ici nous utiliserons [Wireguard](https://www.wireguard.com/), un serveur VPN sécurisé et très performant, à l'aide des conteneurs :
|
||||
|
||||
- [wg-easy](https://github.com/wg-easy/wg-easy) pour le serveur, qui propose une interface web très simple pour controler les connexions et télécharger les fichiers de conf (notamment par QR code pour les téléphones)
|
||||
- [Wireguard](https://docs.linuxserver.io/images/docker-wireguard/?h=wireguard) pour les clients linux
|
||||
|
||||
Il existe aussi des clients Windows, MacOS, iOS et Android.
|
||||
|
||||
Le principe est le suivant :
|
||||
|
||||
- Sur internet, n'importe qui peut contacter n'importe quel box internet et donc essayer de contacter n'importe quel serveur exposé.
|
||||
- Votre serveur est sur votre réseau local. Il est accessible depuis le réseau local mais pas depuis internet, mis à part les services exposés (comme nous l'avons fait avec Dockge). Pour accéder aux ressources non exposées, vous devez être connecté sur le meme réseau que votre serveur et donc etre chez vous. De plus, vous devez laisser ouvert les ports utilisés par vos services à travers le pare feu de votre serveur.
|
||||
- Nous souhaitons ici au contraire, depuis n'importe où, pouvoir accéder de maniere securisée aux services non exposés sur internet du serveur, comme la console SSH qui permet de se connecter à la machine par exemple.
|
||||
- Nous souhaitons aussi accéder aux services d'autres serveurs, et par exemple relier de maniere sécurisée deux instances de Dockge pour tout controler depuis la meme interface.
|
||||
|
||||
Pour cela nous allons créer un **réseau privé virtuel**, ou VPN, c'est à dire un tunnel sécurisé auquel personne n'a accès à part les machines que vous relierez entre elles. Elles feront partie d'un nouveau réseau et pourront dialoguer entre elle comme dans un réseau local.
|
||||
|
||||
D'autre part, vous pourrez ajouter votre téléphone, un ordinateur portable ou n'importe quel appareil au réseau pour pouvoir utiliser vos ressources depuis vos appareils quotidiens, où que vous soyiez.
|
||||
|
||||
|
||||
|
||||
Dans cette illustration, la machine 1 est sur deux réseaux :
|
||||
|
||||
- son réseau local (tous les appareils liés à la box, avec une adresse IP du type `192.168.x.x ` donc ici la machine 1 et la machine 2)
|
||||
- le réseau du VPN (tous les appareils reliés au VPN, avec une seconde adresse IP du type `10.8.x.x` donc ici la machine 1 et 4)
|
||||
|
||||
On peut aussi faire en sorte que les machines reliées au réseau virtuel partagent les acces à leur réseau local. Ici nous ne le ferons pas, pour des raisons de sécurité, et de complexité en terme de sous-réseau (si les deux machines distantes ont des machines locales qui utilisent la meme adresse IP locale, par exemple `192.168.1.1`, cela posera des conflits).
|
||||
|
||||
Ainsi, sur le réseau virtuel, seules les machines directement reliées pourront dialoguer entre elle depuis ce réseau. Elles ne pourront pas dialoguer avec une machine situées sur un autre réseau local et non reliée au VPN.
|
||||
|
||||
## Côté serveur
|
||||
---
|
||||
::alert{type="info"}
|
||||
📋 __A vérifier au préalable :__
|
||||
- Vérifiez si le port `51820 UDP` estlibre sur votre serveur, et bien routé dans le NAT de la box `Source 51820 UDP -> Destination 51820 UDP -> Serveur`. En effet, votre serveur étant derrière votre box, le port de votre box doit etre joignable et rediriger vers le port de votre serveur connecté à votre VPN.
|
||||
- Vérifiez aussi que le port `51821 TCP` est libre sur le serveur pour accéder à la web ui.
|
||||
::
|
||||
|
||||
::alert{type="warning"}
|
||||
:::list{type="warning"}
|
||||
- __Attention :__ Cette documentation utilise la version `14` de [wg-easy](https://wg-easy.github.io/wg-easy/latest/). La version `15`comporte des breaking changes qui ne sont pas compatibles avec les configurations proposées ici.
|
||||
:::
|
||||
::
|
||||
|
||||
Structure des dossiers
|
||||
|
||||
```console
|
||||
root
|
||||
└── docker
|
||||
└── wg-easy
|
||||
├── config
|
||||
│ └── etc_wireguard
|
||||
├── compose.yaml
|
||||
└── .env
|
||||
```
|
||||
|
||||
Le conteneur sera en mode `HOST`, c'est à dire qu'il occupera les ports de votre host comme s'il n'etait pas dans un conteneur mais directement installé sur la machine, sans passer par un sous-réseau.
|
||||
|
||||
Ouvrez Dockge, cliquez sur `compose` et nommez la stack `wg_easy`.
|
||||
|
||||
Copiez la configuration suivante :
|
||||
|
||||
```yaml
|
||||
---
|
||||
volumes:
|
||||
etc_wireguard:
|
||||
services:
|
||||
wg-easy:
|
||||
network_mode: host
|
||||
env_file:
|
||||
- .env
|
||||
environment:
|
||||
- LANG=en
|
||||
- WG_HOST=${HOST}
|
||||
- PASSWORD_HASH=${PW}
|
||||
- WG_DEFAULT_ADDRESS=${ADDRESS}
|
||||
- WG_HIDE_KEYS=never
|
||||
- WG_ALLOWED_IPS=${IPS}
|
||||
- WG_DEFAULT_DNS=
|
||||
- UI_TRAFFIC_STATS=true
|
||||
- UI_CHART_TYPE=1
|
||||
image: ghcr.io/wg-easy/wg-easy:14
|
||||
container_name: wg-easy
|
||||
volumes:
|
||||
- /docker/wg_easy/config/etc_wireguard:/etc/wireguard
|
||||
restart: unless-stopped
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
- SYS_MODULE
|
||||
```
|
||||
::alert{type="success"}
|
||||
✨ __Astuce :__ ajoutez le label de watchtower afin d'automatiser les mises à jour
|
||||
|
||||
```yaml
|
||||
services
|
||||
wg-easy:
|
||||
#...
|
||||
labels:
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
::
|
||||
|
||||
Dans `.env` :
|
||||
|
||||
```properties
|
||||
HOST=
|
||||
PW=
|
||||
ADDRESS=
|
||||
IPS=
|
||||
```
|
||||
|
||||
| Variable | Valeur | Exemples |
|
||||
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------|
|
||||
| `HOST`{lang=properties} | Domaine de l'host | `mondomaine.fr` |
|
||||
| `PW`{lang=properties} | Hash du mot de passe, [à générer ici](https://bcrypt-generator.com/). **ATTENTION:** doubler les `$` | `$$2a$$12$$FF6T4QqSP9Ho`|
|
||||
| `ADDRESS`{lang=properties} | Plage d'adresse que le DHCP du VPN peut attribuer, le `x` doit etre présent, on peut changer les autres chiffres ou les remplacer par `x` aussi | `10.8.0.x` |
|
||||
| `IPS`{lang=properties} | les IPs qui doivent etre routées par les clients vers le VPN. Dans notre cas, on veut que seul le traffic vers le serveur et clients du VPN soit routé, on veut pas de leurs réseau local et on veut conserver l'accès à internet direct sans passer par le VPN.Si vous voulez tout de meme ajouter toutes les machines connectées aux appareils en local, ajoutez la plage `192.168.0.0/16` en séparant les deux plages par une virgule. | `10.8.0.0/24` |
|
||||
|
||||
|
||||
Puis déployez la stack.
|
||||
|
||||
### Activation du forwarding depuis l'host
|
||||
|
||||
Pour que l'host autorise les clients à communiquer entre eux, vous devez activer les paramèttres suivants :
|
||||
|
||||
```shell
|
||||
sudo sysctl net.ipv4.ip_forward=1
|
||||
sudo sysctl net.ipv4.conf.all.src_valid_mark=1
|
||||
```
|
||||
|
||||
### Recuperation des fichiers de conf
|
||||
|
||||
Afin de configurer les clients, vous devez télécharger les fichiers de conf générés par l'host :
|
||||
|
||||
- Connectez vous via le web en local sur `http://ipduserveur:51821`
|
||||
- Créez un client
|
||||
- Téléchargez le fichier de conf
|
||||
- Renommez le en `wg0.conf`
|
||||
|
||||
::alert{type="danger"}
|
||||
:::list{type="danger"}
|
||||
- En cas d'échec, vérifiez les règles du pare-feu.
|
||||
:::
|
||||
::
|
||||
|
||||
## Sur le serveur client
|
||||
---
|
||||
::alert{type="info"}
|
||||
:::list{type="info"}
|
||||
- Nous partons du principe que le serveur client est un serveur linux avec Docker installé
|
||||
:::
|
||||
::
|
||||
|
||||
Structure des dossiers
|
||||
|
||||
```console
|
||||
root
|
||||
└── docker
|
||||
└── wireguard
|
||||
└── config
|
||||
│ └── wg_confs
|
||||
└── compose.yaml
|
||||
```
|
||||
|
||||
Creez le dossier `/docker/wireguard/config/wg_confs`.
|
||||
|
||||
::alert{type="success"}
|
||||
✨ __Astuce pour les allergiques au terminal :__
|
||||
vous pouvez utiliser [File Browser](/serveex/files/file-browser) pour naviguer dans vos fichier et éditer vos documents au lieu d'utiliser les commandes du terminal.
|
||||
::
|
||||
|
||||
```shell
|
||||
sudo mkdir -p /docker/wireguard/config/wg_confs
|
||||
```
|
||||
|
||||
Copiez le fichier` wg0.conf` téléchargé précédemment.
|
||||
|
||||
::alert{type="success"}
|
||||
✨ __Astuce :__ Le moyen le plus simple est de transférer le fichier par sftp dans le dossier `/home/nomdutilisateur` puis de le copier dans le bon dossier :
|
||||
|
||||
```shell
|
||||
sudo cp ~/wg0.conf /docker/wireguard/config/wg_confs
|
||||
|
||||
::
|
||||
|
||||
Creez le `compose.yaml` dans `/docker/wireguard `:
|
||||
```shell
|
||||
sudo vi /docker/wireguard/compose.yaml
|
||||
```
|
||||
Appuyez sur `i` pour rentrer en modification et copiez la configuration ci-dessous
|
||||
```yaml
|
||||
services:
|
||||
wireguard:
|
||||
image: lscr.io/linuxserver/wireguard:latest
|
||||
container_name: wireguard
|
||||
network_mode: host
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
- SYS_MODULE #optional
|
||||
environment:
|
||||
- TZ=Europe/Paris
|
||||
volumes:
|
||||
- /docker/wireguard/config:/config
|
||||
- /lib/modules:/lib/modules #optional
|
||||
restart: unless-stopped
|
||||
```
|
||||
|
||||
Appuyez sur `Echap` puis tapez `:x` pour quitter et sauvegarder.
|
||||
|
||||
Lancez le conteneur :
|
||||
```shell
|
||||
cd /docker/wireguard
|
||||
sudo docker compose up -d
|
||||
```
|
||||
::alert{type="info" icon="exclamation-circle"}
|
||||
:::list{type="info"}
|
||||
- A répéter pour chaque client
|
||||
:::
|
||||
::
|
||||
|
||||
## Autres appareils
|
||||
---
|
||||
- **Téléphone :** installer wireguard et scanner le QR code via le webui (http://ipduserveur:51821)
|
||||
- **PC :** Installer wireguard client et mettre directement le fichier de conf téléchargé via le webui
|
||||
|
||||
::alert{type="warning"}
|
||||
:::list{type="warning"}
|
||||
- __Attention :__ Si des machines clientes sont sur le meme réseau local que le serveur (derriere la box), éditez le fichier `wg0.conf` uploadé sur cette machine en changeant avec l'adresse locale du serveur : `Endpoint = ipduserveur:51820`{lang=properties}
|
||||
:::
|
||||
::
|
||||
|
||||
Et voilà ce que cela peut donner !
|
||||
|
||||
|
||||
588
content/3.serveex/3.securite/2.authentik.md
Normal file
588
content/3.serveex/3.securite/2.authentik.md
Normal file
@ -0,0 +1,588 @@
|
||||
---
|
||||
navigation: true
|
||||
title: Authentik
|
||||
main:
|
||||
fluid: false
|
||||
---
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px}
|
||||
# Authentik
|
||||
|
||||
::alert{type="info"}
|
||||
🎯 __Objectifs :__
|
||||
- Installer et exposer Authentik
|
||||
- Paramétrer le Multi-Facteur
|
||||
- Protéger une app native ou via reverse proxy
|
||||
::
|
||||
|
||||
[Authentik](https://goauthentik.io) est un outil d'authentification unique permettant de vous logger une seule fois sur les plateformes compatibles OpenID. Il permet également de sécuriser l'accès aux services que vous exposez, en s'injectant via SWAG aux requetes vers vos services.
|
||||
|
||||
Ainsi, si vous exposez Dockge sur internet via `dockge.mondomaine.fr`, au moment de l'accès à cette page, vous tomberez sur une page de login d'authentik. Si vous avez déjà été identifié sur un autre service sécurisé par authentik auparavant, alors vous serez déjà identifié. cela permet d'avoir à vous identifiez qu'une seule fois par jour sur l'ensemble des services protégés par authentik.
|
||||
|
||||
Authentik permet aussi d'utiliser le multi-facteur, notamment par TOTP (code généré par une application d'authentification de votre choix. Enfin, authentik permet aussi de se connecter directement via un compte Microsoft ou Google, si vous avez configuré une application d'un de ces services.
|
||||
|
||||
C'est une bonne manière de se passer de VPN pour exposer vos services, et d'exposer des services qui ne sont pas protégés par du MFA voir pas protégés par des login (comme le dashboard de swag).
|
||||
|
||||
Authentik dipose d'[une doc très fournie](https://docs.goauthentik.io/docs/installation/docker-compose) et des [fabuleux tuto de Cooptonian](https://www.youtube.com/@cooptonian). Ici, nous montrerons juste les bases, avec l'exemple de l'exposition de Dockge.
|
||||
|
||||
Deux modes principaux sont à connaitre:
|
||||
|
||||
- Le premier permet à une application qui dispose nativement d'une intégration avec du SSO compatible OpenID de se connecter directement à Authentik. C'est la solution à privilégier car elle permet de laisser l'application décider de ce qui est public et de ce qui est protégé.
|
||||
|
||||
|
||||
|
||||
- Le second permet d'injecter une authentification via authentik grace à SWAG avant d'arriver sur le service désiré.
|
||||
|
||||
|
||||
|
||||
Les deux modes son configurables application par application.
|
||||
|
||||
|
||||
|
||||
## Installation
|
||||
---
|
||||
Structure des dossiers :
|
||||
```console
|
||||
root
|
||||
└── docker
|
||||
└── authentik
|
||||
├── .env
|
||||
├── compose.yml
|
||||
├── media
|
||||
├── certs
|
||||
├── custom-template
|
||||
└── ssh
|
||||
```
|
||||
|
||||
Créez les dossiers :
|
||||
|
||||
```shell
|
||||
sudo mkdir -p /docker/authentik/media /docker/authentik/certs /docker/authentik/custom-template /docker/authentik/ssh
|
||||
```
|
||||
|
||||
Positionnez vous dans le dossier `authentik` et générez un mot de passe et une clé secrete que l'on va intégrer dans le .env :
|
||||
|
||||
```shell
|
||||
sudo echo "PG_PASS=$(openssl rand 36 | base64)" >> .env
|
||||
sudo echo "AUTHENTIK_SECRET_KEY=$(openssl rand 60 | base64)" >> .env
|
||||
```
|
||||
::alert{type="info"}
|
||||
:::list{type="info"}
|
||||
- Afin de générer la clé, nous avons créé les dossiers en amont du déploiement via Dockge. Dockge vous empechera de créer une stack du meme nom dans ces dossiers s'il n'existe pas de `compose.yml`. Il faut donc créer un `compose.yml` vide afin que ce dernier la reconnaisse comme existante dans les stacks inactives :
|
||||
:::
|
||||
```shell
|
||||
sudo vi /docker/authentik/compose.yml
|
||||
::
|
||||
|
||||
Ouvrez dockge, et cherchez "authentik" dans les stack inactives.
|
||||
Nommez la stack authentik et collez la configuration suivante, en changeant les chiffres de `{AUTHENTIK_TAG:-2024.2.3}`{lang=properties} par [la dernière version de Authentik](https://version-2024-6.goauthentik.io/docs/releases).
|
||||
|
||||
```yaml
|
||||
---
|
||||
services:
|
||||
|
||||
postgresql:
|
||||
image: docker.io/library/postgres:12-alpine
|
||||
container_name: authentik-postgresql
|
||||
restart: unless-stopped
|
||||
healthcheck:
|
||||
test:
|
||||
- CMD-SHELL
|
||||
- pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}
|
||||
start_period: 20s
|
||||
interval: 30s
|
||||
retries: 5
|
||||
timeout: 5s
|
||||
volumes:
|
||||
- database:/var/lib/postgresql/data
|
||||
environment:
|
||||
POSTGRES_PASSWORD: ${PG_PASS:?database password required}
|
||||
POSTGRES_USER: ${PG_USER:-authentik}
|
||||
POSTGRES_DB: ${PG_DB:-authentik}
|
||||
env_file:
|
||||
- .env
|
||||
|
||||
redis:
|
||||
image: docker.io/library/redis:alpine
|
||||
container_name: authentik-redis
|
||||
command: --save 60 1 --loglevel warning
|
||||
restart: unless-stopped
|
||||
healthcheck:
|
||||
test:
|
||||
- CMD-SHELL
|
||||
- redis-cli ping | grep PONG
|
||||
start_period: 20s
|
||||
interval: 30s
|
||||
retries: 5
|
||||
timeout: 3s
|
||||
volumes:
|
||||
- redis:/data
|
||||
|
||||
server:
|
||||
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2024.2.3}
|
||||
container_name: authentik-server
|
||||
restart: unless-stopped
|
||||
command: server
|
||||
environment:
|
||||
AUTHENTIK_REDIS__HOST: redis
|
||||
AUTHENTIK_POSTGRESQL__HOST: postgresql
|
||||
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
|
||||
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
|
||||
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
|
||||
volumes:
|
||||
- ./media:/media
|
||||
- ./custom-templates:/templates
|
||||
- ./auth.css:/web/dist/custom.css
|
||||
- ./ssh:/authentik/.ssh
|
||||
env_file:
|
||||
- .env
|
||||
ports:
|
||||
- ${COMPOSE_PORT_HTTP:-9000}:9000
|
||||
- ${COMPOSE_PORT_HTTPS:-9443}:9443
|
||||
depends_on:
|
||||
- postgresql
|
||||
- redis
|
||||
|
||||
worker:
|
||||
image: ${AUTHENTIK_IMAGE:-ghcr.io/goauthentik/server}:${AUTHENTIK_TAG:-2024.2.3}
|
||||
container_name: authentik-worker
|
||||
restart: unless-stopped
|
||||
command: worker
|
||||
environment:
|
||||
AUTHENTIK_REDIS__HOST: redis
|
||||
AUTHENTIK_POSTGRESQL__HOST: postgresql
|
||||
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
|
||||
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
|
||||
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
|
||||
# `user: root` and the docker socket volume are optional.
|
||||
# See more for the docker socket integration here:
|
||||
# https://goauthentik.io/docs/outposts/integrations/docker
|
||||
# Removing `user: root` also prevents the worker from fixing the permissions
|
||||
# on the mounted folders, so when removing this make sure the folders have the correct UID/GID
|
||||
# (1000:1000 by default)
|
||||
user: root
|
||||
volumes:
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
- ./media:/media
|
||||
- ./certs:/certs
|
||||
- ./custom-templates:/templates
|
||||
- ./auth.css:/web/dist/custom.css
|
||||
- ./ssh:/authentik/.ssh
|
||||
env_file:
|
||||
- .env
|
||||
depends_on:
|
||||
- postgresql
|
||||
- redis
|
||||
|
||||
volumes:
|
||||
database:
|
||||
driver: local
|
||||
redis:
|
||||
driver: local
|
||||
```
|
||||
|
||||
Dans le point `.env`, les variables `PG_PASS` et `AUTHENTIK_SECRET_KEY` sont déjà remplies.
|
||||
Déployez la stack.
|
||||
|
||||
Vous pouvez alors commencer le set-up d'authentik en tappant `http://ipduserveur:9000/if/flow/initial-setup/`.
|
||||
|
||||
::alert{type="warning"}
|
||||
:::list{type="warning"}
|
||||
- __Attention :__ il est conseillé de créer un nouveau compte admin, et de **désactiver** le compte admin de base `akadmin`.
|
||||
:::
|
||||
::
|
||||
|
||||
## Exposer authentik
|
||||
---
|
||||
Pour être utilisable hors de chez vous, vous devez exposer authentik.
|
||||
|
||||
::alert{type="info"}
|
||||
📋 __Au préalable :__ <br/><br/>
|
||||
Nous partons du principe quer vous avez créé dans votre [zone DNS](/generalites/dns) un sous domaine du type `auth.mondomaine.fr` avec pour CNAME `mondomaine.fr` et, [à moins que vous utilisiez Cloudflare Zero Trust](/serveex/securite/cloudflare), vous avez déjà redirigé le port `443` de votre box vers le `443` de votre serveur dans [les règles NAT](/generalites/nat).
|
||||
::
|
||||
|
||||
Ouvrez le fichier `authentik-server.conf`.
|
||||
|
||||
::alert{type="success"}
|
||||
✨ __Astuce pour les allergiques au terminal :__
|
||||
vous pouvez utiliser [File Browser](/serveex/files/file-browser) pour naviguer dans vos fichier et éditer vos documents au lieu d'utiliser les commandes du terminal.
|
||||
::
|
||||
|
||||
```shell
|
||||
sudo vi /docker/swag/config/nginx/authentik-server.conf
|
||||
```
|
||||
|
||||
Vérifiez que dans chaque cas les variables ci-dessous sont correctes :
|
||||
|
||||
```nginx
|
||||
set $upstream_authentik authentik-server;
|
||||
proxy_pass http://$upstream_authentik:9000;
|
||||
```
|
||||
|
||||
Si ce n'est pas le cas, passez en mode modification en tapant `i` et éditez les. Sauvegardez et quittez en tapant sur `Echap` puis `:x`.
|
||||
|
||||
Créez le fichier `auth.subdomain.conf`
|
||||
|
||||
```shell
|
||||
sudo vi /docker/swag/config/nginx/proxy-confs/auth.subdomain.conf
|
||||
|
||||
```
|
||||
|
||||
Appuyez sur `i` pour rentrer en mode modification puis collez la configuration suivante :
|
||||
|
||||
```nginx
|
||||
## Version 2023/05/31
|
||||
# make sure that your authentik container is named authentik-server
|
||||
# make sure that your dns has a cname set for authentik
|
||||
|
||||
server {
|
||||
listen 443 ssl;
|
||||
listen [::]:443 ssl;
|
||||
|
||||
server_name auth.*;
|
||||
|
||||
include /config/nginx/ssl.conf;
|
||||
|
||||
client_max_body_size 0;
|
||||
|
||||
location / {
|
||||
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app authentik-server;
|
||||
set $upstream_port 9000;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
}
|
||||
|
||||
location ~ (/authentik)?/api {
|
||||
include /config/nginx/proxy.conf;
|
||||
include /config/nginx/resolver.conf;
|
||||
set $upstream_app authentik-server;
|
||||
set $upstream_port 9000;
|
||||
set $upstream_proto http;
|
||||
proxy_pass $upstream_proto://$upstream_app:$upstream_port;
|
||||
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Sauvegardez et quittez en appuyant sur `Echap` puis en tapant `:x`.
|
||||
|
||||
Rendez-vous dans dockge, et éditez le compose de SWAG en ajoutant le réseau d'Authentik :
|
||||
|
||||
```yaml
|
||||
services:
|
||||
swag:
|
||||
container_name: # ...
|
||||
# ...
|
||||
networks: # Relie le conteneur au réseau custom
|
||||
# ...
|
||||
- authentik # Nom du réseau déclaré dans la stack
|
||||
|
||||
networks: # Définit le réseau custom
|
||||
# ...
|
||||
authentik: # Nom du réseau déclaré dans la stack
|
||||
name: authentik_default # Nom véritable du réseau externe
|
||||
external: true # Précise que c'est un réseau à rechercher en externe
|
||||
```
|
||||
|
||||
Relancez la stack et patientez le temps que SWAG soit complètement opérationnel.
|
||||
|
||||
Et voilà ! Vous pouvez accéder à authentik via `https://auth.mondomaine.fr`
|
||||
|
||||
## Activer le multifacteur
|
||||
---
|
||||
Tout l'intérêt de authentik c'est de disposer du multifacteur pour toutes les apps que l'on protègera.
|
||||
|
||||
- Rendez vous sur `https://auth.mondomaine.fr`
|
||||
- Identifiez-vous
|
||||
- Rendez-vous dans _paramètres_
|
||||
- Cliquez sur la section _MFA_
|
||||
- Cliquez sur _s'inscrire_
|
||||
- Choisissez une méthode comme _TOTP device_ ( dans ce cas vous devrez utilisez une app d'authentification telle que Google Authenticator par exemple)
|
||||
- Suivez les étapes
|
||||
|
||||
Et voilà, vous serez invité à saisir un code à usage unique à chaque connexion.
|
||||
|
||||
## Protéger une app native
|
||||
---
|
||||
Authentik est compatible nativement avec un certain nombre d'application, vous retrouverez la liste et [le support ici](https://docs.goauthentik.io/integrations/services/)
|
||||
|
||||
## Protéger une app par reverse proxy
|
||||
---
|
||||
Swag permet d'intercaler la page d'authentik entre la requête et l'accès à votre service. Pour cela il va falloir :
|
||||
|
||||
- Configurer le service d'authentification dans authentik.
|
||||
- Configurer le fichier proxy du domaine pour que swag puisse intercaler la page.
|
||||
|
||||
Pourquoi le faire alors que Dockge a déjà une page d'authentification ? Tout simplement parce que l'authentification HTTP utilisée par Dockge est faible. Avec Authentik, vous aurez directement une authentification forte par MFA, et vous serez loggé automatiquement à toutes vos apps déjà protégées par authentik. Cela permet de sécuriser l'accès à Dockge et aux autres apps que vous protégerez, sans avoir à passer par un VPN.
|
||||
|
||||
### Configuration de Authentik
|
||||
|
||||
- Rendez vous dans Authentik
|
||||
- Allez dans le panneau d'administration
|
||||
- Sélectionnez _application_ puis _créer avec l'assistant_
|
||||
- Renseignez les champs comme suit :
|
||||
|
||||
|
||||
|
||||
- Puis à l'étape suivante choisissez "Transférer l'authentification (application unique)" et éditez comme suit (attention aux flow, c'est important) :
|
||||
|
||||
|
||||
|
||||
- Ensuite, allez dans le menu à gauche dans _Avant-poste_ et éditez _authentik Embedded Outpost_
|
||||
|
||||
|
||||
|
||||
- Ajoutez l'application `dockge` en la faisant passer à droite et validez.
|
||||
|
||||
### Configuration de SWAG
|
||||
|
||||
Ensuite rendez-vous dans le fichier `dockge.mondomaine.fr`.
|
||||
|
||||
```shell
|
||||
sudo vi /docker/swag/config/nginx/proxy-confs/dockge.subdomain.conf
|
||||
```
|
||||
|
||||
Puis entrez en modification en appuyant sur `i` et enlevez les `#` des deux lignes `#include /config/nginx/authentik-server.conf;`{lang=nginx}.
|
||||
|
||||
Appuyez sur `Echap` puis tapez `:x` et appuyez sur `Entrée` pour sauvegarder et quitter.
|
||||
|
||||
Et voilà ! En tapant `https://dockge.mondomaine.fr`, vous tomberez à présent sur la mire d'authentification de authentik.
|
||||
|
||||
::alert{type="success"}
|
||||
✨ __Astuce :__ dans Dockge, dans les paramètres, vous pouvez désactiver l'authentification de Dockge afin de ne pas avoir à vous identifier deux fois. **Attention**, cela voudra dire que si vous avez exposé un port sur votre réseau local, il n'y aura plus aucune authentification.
|
||||
::
|
||||
|
||||
::alert{type="info"}
|
||||
:::list{type="info"}
|
||||
- Vous pouvez répétez l'opération pour chaque application que vous souhaitez protéger (si elle ne dipose pas d'intégration directe avec Authentik).
|
||||
:::
|
||||
::
|
||||
|
||||
Voilà votre nouvelle architecture :
|
||||
|
||||
|
||||
|
||||
## Protéger un service sur un serveur distant
|
||||
---
|
||||
Dans le cas d'une application [native](/serveex/securite/authentik#protéger-une-app-native) (via OAuth 2.0 ou autre), rien ne change.
|
||||
|
||||
Dans le cas d'une application non native à protéger derrière un reverse proxy, vous devrez déployer un __avant-poste__. Un avant-poste est un conteneur qui jouera le rôle de proxy local, c'est à dire que c'est vers ce conteneur que les requêtes d'authentification de vos applications seront redirigées. C'est le seul qui est autorisé à dialoguer avec l'API de votre instance authentik.
|
||||
|
||||
|
||||
::alert{type="info"}
|
||||
Pré-requis :
|
||||
- Avoir installé [docker](/serveex/coeur/docker) sur votre machine distante hébergeant le service à protéger.
|
||||
- Si l'application n'a pas d'intégration native, avoir un reverse proxy compatible. Comme partout ici, nous utiliserons [SWAG](/serveex/coeur/swag).
|
||||
::
|
||||
|
||||
Ce conteneur redirigera ensuite les requetes vers votre instance [Authentik](/serveex/securite/authentik#authentik) principale, à travers le web (ou votre réseau local). Le serveur executera les controle et renverra la réponse à l'_avant-poste_, qui bloquera ou non la connexion à l'app protégée.
|
||||
|
||||
|
||||
|
||||
### Configuration d'Authentik
|
||||
|
||||
Créez vos [fournisseurs et applications](/serveex/securite/authentik#protéger-une-app-native) comme nous l'avons vu plus haut.
|
||||
|
||||
Puis, dans votre panneau admin, allez dans la rubrique _Applications > Avant-postes_, puis créez un nouvel avant-poste.
|
||||
|
||||
Remplissez comme suit :
|
||||
|
||||
|
||||
| Champs | Valeur |
|
||||
|----------------|-----------------------------------------------------------------------|
|
||||
| `Nom` | Le nom que vous souhaitez |
|
||||
| `Type` | `Proxy` |
|
||||
| `Intégration` | Laissez vide |
|
||||
| `Applications` | Sélectionnez le ou les applications que vous avez créées précédemment |
|
||||
|
||||
Dans la section `Paramètres avancés`, supprimez l'existant, et complétez comme suit :
|
||||
|
||||
```yaml
|
||||
log_level: info
|
||||
docker_labels: null
|
||||
authentik_host: https://domaine_de_votre_serveur_authentik/
|
||||
object_naming_template: ak-outpost-%(name)s
|
||||
authentik_host_insecure: false
|
||||
container_image:
|
||||
docker_network: null
|
||||
docker_map_ports: true
|
||||
docker_labels: null
|
||||
```
|
||||
|
||||
Enrtegistrez et quittez.
|
||||
|
||||
Sur l'écran affichant les avant-postes créés, vous verrez le nouvel avant-poste que vous venez de créer. A la fin de la ligne, cliquez sur _afficher les informations_, et copiez précieusement le jeton d'accès.
|
||||
|
||||
### Configuration de la machine distante
|
||||
|
||||
Nous partons du principe que vous avez déjà installé [Docker](/serveex/coeur/docker) et [SWAG](/serveex/coeur/swag) sur cette machine distante.
|
||||
|
||||
Sur votre machine distante, à l'aide de [Dockge](/serveex/coeur/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs), créez une stack `authentik-outpost`.
|
||||
|
||||
Si vous n'avez pas installé [Dockge](/serveex/coeur/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs), créez un dossier `/docker/authentik-outpost`, ou directement en ligne de commande :
|
||||
|
||||
```shell
|
||||
sudo mkdir -P /docker/authentik-outpost
|
||||
```
|
||||
|
||||
::alert{type="success"}
|
||||
✨ __Astuce pour les allergiques au terminal :__
|
||||
vous pouvez utiliser [File Browser](/serveex/files/file-browser) pour naviguer dans vos fichier et éditer vos documents au lieu d'utiliser les commandes du terminal.
|
||||
::
|
||||
|
||||
Créez le fichier `compose.yaml` ou copiez la configuration directement dans le champs si vous avez [Dockge](/serveex/coeur/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs)
|
||||
|
||||
En ligne de commande :
|
||||
|
||||
```shell
|
||||
sudo vi /docker/authentik-outpost/compose.yaml
|
||||
```
|
||||
Entrez en mode modification avec `i` et collez la configuration suivante, en changeant les chiffres de `{AUTHENTIK_TAG:proxy:2024.2.3}`{lang=properties} par la meme version que celle de votre serveur Authentik.
|
||||
|
||||
```yaml
|
||||
version: "3.5"
|
||||
services:
|
||||
authentik_proxy:
|
||||
container_name: authentik-outpost
|
||||
image: ghcr.io/goauthentik/proxy:2024.2.3
|
||||
# Optionally specify which networks the container should be
|
||||
# might be needed to reach the core authentik server
|
||||
restart: unless-stopped
|
||||
env_file:
|
||||
- .env
|
||||
# - foo
|
||||
ports:
|
||||
- 9000:9000
|
||||
- 9443:9443
|
||||
environment:
|
||||
AUTHENTIK_HOST: ${HOST}
|
||||
AUTHENTIK_INSECURE: "false"
|
||||
AUTHENTIK_TOKEN: ${TOKEN}
|
||||
# Starting with 2021.9, you can optionally set this too
|
||||
# when authentik_host for internal communication doesn't match the public URL
|
||||
# AUTHENTIK_HOST_BROWSER: https://external-domain.tld
|
||||
```
|
||||
|
||||
Rendez-vous sur la stack de SWAG de la machine distante (ou remplissez directement si vous avez [Dockge](/serveex/coeur/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs)) et ajoutez le réseau de authentik-outpost dans le fichier de conf sur ce modele (les champs `networks`) :
|
||||
|
||||
|
||||
```shell
|
||||
sudo vi /docker/swag/compose.yaml
|
||||
```
|
||||
|
||||
```yaml
|
||||
services:
|
||||
swag:
|
||||
container_name: #...
|
||||
# ...
|
||||
networks: # Relie le conteneur au réseau custom
|
||||
- authentik-outpost # Nom du réseau déclaré dans la stack
|
||||
|
||||
networks: # Définit le réseau custom
|
||||
#...
|
||||
authentik-outpost: # Nom du réseau déclaré dans la stack
|
||||
name: authentik-outpost_default # Nom véritable du réseau externe
|
||||
external: true # Précise que c'est un réseau à rechercher en externe
|
||||
```
|
||||
|
||||
Appuyez sur `Echap` puis tapez `:x` et appuyez sur `Entrée` pour sauvegarder et quitter.
|
||||
|
||||
::alert{type="info"}
|
||||
:::list{type="info"}
|
||||
- Ici nous partons du principe que le nom du réseau de dockge est `authentik-outpost_default`.
|
||||
:::
|
||||
::
|
||||
|
||||
Si vous avez [Dockge](/serveex/coeur/docker/#installer-dockge-pour-g"rer-et-d"ployer-les-conteneurs), relancez SWAG.
|
||||
|
||||
Sinon, via le terminal :
|
||||
|
||||
```shell
|
||||
cd /docker/swag/
|
||||
sudo docker compose up -d
|
||||
```
|
||||
|
||||
Creez (ou remplissez directement si vous avez [Dockge](/serveex/coeur/docker/#installer-dockge-pour-gérer-et-déployer-les-conteneurs)) le fichier `.env` dans le dossier de l'avant poste authentik :
|
||||
|
||||
En ligne de commande :
|
||||
|
||||
```shell
|
||||
sudo vi /docker/authentik-outpost/.env
|
||||
```
|
||||
|
||||
Entrez en mode modification avec `i` et collez la configuration suivante
|
||||
|
||||
```properties
|
||||
HOST=
|
||||
TOKEN=
|
||||
```
|
||||
Remplissez comme suit
|
||||
|
||||
| Variable | Valeur | Exemple |
|
||||
|-------------------------|---------------------------------------------------------|----------------------------|
|
||||
| `HOST`{lang=properties} | L'url de votre serveur authentik | `https://auth.domaine.fr` |
|
||||
| `TOKEN`{lang=properties} | Le token que vous avez précédemment copié précieusement | `Q2pVEqsTNRkJSO9SkJzU3KZ2` |
|
||||
|
||||
Appuyez sur `Echap` puis tapez `:x` et appuyez sur `Entrée` pour sauvegarder et quitter.
|
||||
|
||||
Si vous avez [Dockge](/serveex/coeur/docker/#installer-dockge-pour-g"rer-et-d"ployer-les-conteneurs), déployez la stack.
|
||||
|
||||
Sinon, via le terminal :
|
||||
|
||||
```shell
|
||||
cd /docker/authentik-outpost/
|
||||
sudo docker compose up -d
|
||||
```
|
||||
|
||||
Le conteneur est en route, vous pouvez vérifier son état dans votre panneau admin de votre instance Authentik, section _Applications > Avant-postes_.
|
||||
|
||||
|
||||
Nous allons a présent configurer SWAG.
|
||||
|
||||
Ouvrez le fichier `authentik-server.conf`.
|
||||
|
||||
```shell
|
||||
sudo vi /docker/swag/config/nginx/authentik-server.conf
|
||||
```
|
||||
|
||||
Dans le fichier, passez en mode modification en tapant `i` et changez `authentik-server` par `authentik-outpost` comme suit :
|
||||
|
||||
```nginx
|
||||
set $upstream_authentik authentik-outpost;
|
||||
proxy_pass http://$upstream_authentik:9000;
|
||||
```
|
||||
|
||||
Sauvegardez et quittez en tapant sur `Echap` puis `:x` et sur `Entrée`.
|
||||
|
||||
Ensuite, configurez les applications à protéger selon si elles sont [natives](/serveex/securite/authentik#protéger-une-app-native) ou par [proxy](/serveex/securite/authentik#protéger-une-app-par-reverse-proxy) comme vous l'avez fait sur votre serveur principal.
|
||||
|
||||
## Migrer une base authentik
|
||||
---
|
||||
Sur la machine d'origine, dumper la bdd :
|
||||
|
||||
```shell
|
||||
sudo docker exec authentik-postgres pg_dump -U authentik -F t authentik > /path/to/mydb.tar
|
||||
```
|
||||
|
||||
Puis l'envoyer sur la machine cible. Sur la machine cible, copier le fichier dans le container docker
|
||||
|
||||
```shell
|
||||
cp /path/to/mydb.tar authentik-postgres:/path/to/wherever
|
||||
```
|
||||
|
||||
(Optionnel) Purgez les tables existantes :
|
||||
|
||||
```shell
|
||||
sudo docker exec -i authentik-postgres psql -U authentik -c "SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = 'authentik' AND pid <> pg_backend_pid();" && \
|
||||
sudo docker exec -i authentik-postgres psql -U authentik -d postgres -c "DROP DATABASE IF EXISTS authentik;" && \
|
||||
sudo docker exec -i authentik-postgres psql -U authentik -d postgres -c "CREATE DATABASE authentik;" && \
|
||||
```
|
||||
|
||||
Restaurez la bdd
|
||||
|
||||
```shell
|
||||
sudo docker exec authentik-postgresql pg_restore -U authentik -d authentik /path/to/wherever/mydb.tar
|
||||
```
|
||||
268
content/3.serveex/3.securite/3.cloudflare.md
Normal file
268
content/3.serveex/3.securite/3.cloudflare.md
Normal file
@ -0,0 +1,268 @@
|
||||
---
|
||||
navigation: true
|
||||
title: Cloudflare Zero Trust
|
||||
main:
|
||||
fluid: false
|
||||
---
|
||||
:ellipsis{left=0px width=40rem top=10rem blur=140px}
|
||||
# Cloudflare Zero Trust
|
||||
|
||||
::alert{type="info"}
|
||||
🎯 __Objectifs :__
|
||||
- Comprendre le principe des Tunnels Cloudflare
|
||||
- Paramétrer son compte cloudflare
|
||||
- Paramétrer SWAG
|
||||
- Gérer plusieurs tunnels
|
||||
::
|
||||
|
||||
|
||||
|
||||
## Introduction
|
||||
---
|
||||
L'architecture _Zero Trust_ est la pratique consistant à concevoir des systèmes fondés sur le principe de __« ne jamais faire confiance__, __toujours vérifier »__, par opposition au principe traditionnel de __« confiance, mais vérifier »__. Ce concept est devenu très populaires récemment, à la suite des attaques toujours plus nombreuses concernant les données des utilisateurs. C'est un concept très large, nous nous concentrerons sur l’application du _Zero Trust_ aux services Web que nous hébergeons.
|
||||
|
||||
Les _tunnels Cloudflare_ offrent un moyen simple d'arriver au _Zero Trust_, en s'appuyant sur [SWAG](/serveex/coeur/swag) et [Authentik](/serveex/securite/authentik).
|
||||
|
||||
Pour le dire simplement, les Tunnels Cloudflare permettent notamment de :
|
||||
|
||||
- Masquer l'IP de votre serveur (et donc de votre box s'il est hébergé chez vous).
|
||||
- D'authentifier le traffic.
|
||||
- De bénéficier des protection de Cloudflare (attaques DDOS, etc, blacklist, requêtes malveillantes, etc...).
|
||||
- De bénéficier du CDN, c'est à dire du serveur de cache de Cloudlfare, qui permet d'augmenter les performances de vos sites web.
|
||||
- De ne plus avoir besoin de l'ouverture de ports de votre routeur pour les services exposés par SWAG.
|
||||
|
||||
Ici, nous expliquerons comment associer SWAG aux tunnels Cloudflare.
|
||||
|
||||
::alert{type="warning"}
|
||||
:::list{type="warning"}
|
||||
- __Attention :__
|
||||
:::
|
||||
- N'utilisez pas les tunnels Cloudflare pour exposer un serveur mail
|
||||
- N'utilisez pas les tunnels Cloudflare pour exposer un service vidéo, comme Plex (si vous avez [suivi ce guide](/serveex/media/plex), Plex n'est pas exposé, c'est donc valide)
|
||||
- N'utilisez pas les tunnels Cloudflare pour utiliser le protocole bittorrent (si vous avez [suivi ce guide](/serveex/media/qbittorrent), tout est bon)
|
||||
::
|
||||
|
||||
## Configuration Cloudflare
|
||||
---
|
||||
### Zone DNS
|
||||
|
||||
Avant toute chose, vous devez définir Cloudflare comme gestionnaire de votre [zone DNS](/generalites/dns). Si vous avez réservé votre nom de domaine chez Cloudflare, c'est déjà le cas. Sinon, renseignez vous auprès de votre registrar sur comment ajouter des DNS externes. Cloudflare dispose d'[une documentation expliquant pas à pas comment paramétrer une Zone DNS](https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/), que vous ayez un domaine externe ou reservé chez Cloudflare.
|
||||
|
||||
Si vous avez qu'un seul serveur à protéger derrière Cloudflare, vous pouvez supprimer l'ensemble des enregistrement DNS existant, par défaut le domaine et tout ses sous-domaines seront directement redirigés vers le tunnel.
|
||||
|
||||
Si vous avez des sous-domaines à rediriger vers d'autres serveurs, vous pourrez toujours les déclarer dans la zone DNS à l'aide d'un enregistrement A.
|
||||
|
||||
Si vous avez plusieurs serveurs et donc plusieurs tunnels pour un meme domaine principal, [voyez ici](http://192.168.7.80:8005/serveex/cloudflare/#gerer-plusieurs-tunnels-pour-plusieurs-serveurs).
|
||||
|
||||
### Clé API
|
||||
|
||||
Pour commencer, nous devons créer un nouveau jeton API pour Cloudflare et récupérer nos identifiants de zone et de compte.
|
||||
|
||||
Sur le tableau de bord de Cloudflare, dans la page de présentation de votre domaine, vous pouvez voir les identifiants de `zone` et de `compte` en bas à droite de l'écran. Copiez précieusement ces deux identifiants.
|
||||
|
||||
|
||||
|
||||
Juste en dessous d'eux, il y a un lien intitulé _Obtenez votre jeton API_. Cliquez dessus. Le périmètre dont nous avons besoin pour le jeton doit inclure `Zone:DNS:Edit` et `Account:Cloudflare Tunnel:Edit`. Assurez-vous que votre page de création de token ressemble à celle illustrée dans la capture d'écran ci-dessous.
|
||||
|
||||
|
||||
|
||||
Une fois que nous aurons enregistré, notre jeton sera affiché une fois. copiez le précieusement, car vous ne pourrez plus le revoir après la fermeture.
|
||||
|
||||
### Cloudflare Zero Trust
|
||||
|
||||
Vous devez vous inscrire à _Cloudflare Teams_ pour pouvoir accéder au tableau de bord _Zero Trust_ qui gère les tunnels et les politiques d'accès. Il s'agit d'un service premium, mais ils proposent un forfait gratuit pour un maximum de 50 utilisateurs, ce qui devrait suffire pour votre Home Lab. Gardez à l’esprit que puisqu’il s’agit d’une fonctionnalité premium, ils demandent une carte de crédit valide lors de l’inscription, mais avec le forfait gratuit, il n'y aura aucun frais.
|
||||
|
||||
Inscrivez-vous [via ce lien](https://dash.teams.cloudflare.com/).
|
||||
|
||||
|
||||
## Configuration de Swag
|
||||
---
|
||||
::alert{type="info"}
|
||||
:::list{type="info"}
|
||||
- Nous partons du principe que vous avez le domaine `mondomaine.fr` avec les DNS qui pointent bien vers ceux de Cloudflare, comme vu précédemment.
|
||||
:::
|
||||
::
|
||||
|
||||
SWAG dispose de deux `Docker Mods` permettant d'y intégrer :
|
||||
|
||||
- __Cloudflared__, le conteneur qui permet de créer et de gérer les tunnels
|
||||
- __Cloudflared Real IP__, un conteneur qui permet à SWAG d'obtenir la vraie source IP des requêtes depuis internet plutot que celle de Docker (ce qui pourrait entrer en conflit avec le mod de géolocalisatioN DBIP).
|
||||
|
||||
Ces deux mods, fusionnés dans le conteneur de SWAG, nécessitent un peu de configuration.
|
||||
|
||||
### Configuration du tunnel
|
||||
|
||||
Pour configurer les tunnels, nous aurons besoin de créer un fichier `tunnelconfig.yml` auquel nous ferons appel dans le `compose.yaml` de SWAG.
|
||||
|
||||
::alert{type="success"}
|
||||
✨ __Astuce :__ vous pouvez utiliser [File Browser](/serveex/files/file-browser) pour naviguer dans vos fichier et éditer vos documents au lieu d'utiliser les commandes du terminal.
|
||||
::
|
||||
|
||||
```shell
|
||||
sudo vi /docker/swag/config/tunnelconfig.yml
|
||||
```
|
||||
|
||||
Entrez en modification avec la touche `i` et collez la configuration ci-dessous
|
||||
|
||||
```yaml
|
||||
ingress:
|
||||
- hostname: mondomaine.fr
|
||||
service: https://mondomaine.fr
|
||||
- hostname: "*.mondomaine.fr"
|
||||
service: https://mondomaine..fr
|
||||
- service: http_status:404
|
||||
```
|
||||
|
||||
Appuyez sur `Echap` puis sauvegardez et quittez en tapant `:x` puis en appuyant sur `Entrée`.
|
||||
|
||||
### Configuration de Cloudflare Real IP
|
||||
|
||||
A présent, nous allons configurer le bon fonctionnement du mode _Cloudflare Real IP_
|
||||
|
||||
Ouvrez le fichier `nginx.conf`
|
||||
|
||||
```shell
|
||||
sudo vi /docker/swag/config/nginx/nginx.conf
|
||||
```
|
||||
Entrez en modification avec la touche `i` et collez la configuration ci-dessous à la fin de la section `http`
|
||||
|
||||
```nginx
|
||||
real_ip_header X-Forwarded-For;
|
||||
real_ip_recursive on;
|
||||
include /config/nginx/cf_real-ip.conf;
|
||||
set_real_ip_from 127.0.0.1;
|
||||
```
|
||||
Appuyez sur `Echap` puis sauvegardez et quittez en tapant `:x` puis en appuyant sur `Entrée`.
|
||||
|
||||
### Docker compose
|
||||
|
||||
Ouvrez Dockge, éditez la stack SWAG avec cette configuration
|
||||
|
||||
```yaml
|
||||
---
|
||||
services:
|
||||
swag:
|
||||
image: lscr.io/linuxserver/swag:latest
|
||||
container_name: swag
|
||||
cap_add:
|
||||
- NET_ADMIN
|
||||
env_file:
|
||||
- .env
|
||||
environment:
|
||||
- DOCKER_MODS=linuxserver/mods:swag-dbip|linuxserver/mods:swag-dashboard|linuxserver/mods:swag-auto-reload|linuxserver/mods:universal-cloudflared|linuxserver/mods:swag-cloudflare-real-ip
|
||||
- PUID=${PUID}
|
||||
- PGID=${PGID}
|
||||
- TZ=Europe/Paris
|
||||
- URL=${DOMAIN}
|
||||
- SUBDOMAINS=wildcard
|
||||
- VALIDATION=dns
|
||||
- DNSPLUGIN=${PLUGIN}
|
||||
- EMAIL=${EMAIL}
|
||||
- CF_ZONE_ID=${ZONE_ID}
|
||||
- CF_ACCOUNT_ID=${ACCOUNT_ID}
|
||||
- CF_API_TOKEN=${API_TOKEN}
|
||||
- CF_TUNNEL_NAME=${TUNNEL_NAME}
|
||||
- CF_TUNNEL_PASSWORD=${TUNNEL_PW}
|
||||
- FILE__CF_TUNNEL_CONFIG=/config/tunnelconfig.yml
|
||||
extra_hosts:
|
||||
- ${DOMAIN}:127.0.0.1
|
||||
ports:
|
||||
- 81:81
|
||||
volumes:
|
||||
- /docker/swag/config:/config
|
||||
- /docker/swag/config/fail2ban/fail2ban.sqlite3:/dashboard/fail2ban.sqlite3:ro
|
||||
restart: unless-stopped
|
||||
```
|
||||
|
||||
::alert{type="success"}
|
||||
✨ __Astuce :__ ajoutez le label de watchtower dans chaque conteneur afin d'automatiser les mises à jour
|
||||
|
||||
```yaml
|
||||
services:
|
||||
swag:
|
||||
#...
|
||||
labels:
|
||||
- com.centurylinklabs.watchtower.enable=true
|
||||
::
|
||||
|
||||
|
||||
Et renseignez le `.env` les infos que vous avez trouvées et notées tout au long de ce guide
|
||||
|
||||
```properties
|
||||
PUID=
|
||||
PGID=
|
||||
DOMAIN=
|
||||
PLUGIN=
|
||||
EMAIL=
|
||||
ZONE_ID=
|
||||
ACCOUNT_ID=
|
||||
API_TOKEN=
|
||||
TUNNEL_NAME=
|
||||
TUNNEL_PW=
|
||||
```
|
||||
|
||||
| Variable | Valeur | Exemples |
|
||||
|-----------------------------------|-----------------------------------------------------------------------------------------------------------|--------------------------------|
|
||||
| `PUID`{lang=properties} | A renseigner avec les infos de votre user (trouvables via la commande `id nomdutilisateur`{lang=shell}) | `1000` |
|
||||
| `GUID`{lang=properties} | A renseigner avec les infos de votre user (trouvables via la commande `id nomdutilisateur`{lang=shell}) | `1000 ` |
|
||||
| `DOMAIN`{lang=properties} | Le domaine que vous avez réservé | `mondomaine.fr` |
|
||||
| `PLUGIN`{lang=properties} | Le fournisseur de zone DNS, ici Cloudflare. Pensez à renseigner `cloudflare.ini` (voir [guide de swag](https://docs.linuxserver.io/general/swag/#create-container-via-dns-validation-with-a-wildcard-cert)) | `cloudflare` |
|
||||
| `EMAIL`{lang=properties} | Votre email pour le certificat | `votre@email.fr` |
|
||||
| `ZONE_ID`{lang=properties} | L'ID de Zone que vous avez noté précédemment | `aNhcz1l3JfWbFZo2XMpzQlP2iOqk` |
|
||||
| `ACCOUNT_ID`{lang=properties} | L'ID de Compte que vous avez noté précédemment | `buKsjNHLyzKMM1qYnzOy4s7SHfly` |
|
||||
| `API_TOKEN`{lang=properties} | Le jeton d'API que vous avez noté précédemment | `53ydYus9TFFk1DOXNdP87iIcJtQjoW` |
|
||||
| `TUNNEL_NAME`{lang=properties} | Le nom de votre tunnel | `mon_tunnel` |
|
||||
| `TUNNEL_PW`{lang=properties} | Un mot de passe fort généré aléatoirement | `iSzKRmP4VbnlsMvdSdgBEJiJi` |
|
||||
|
||||
Une fois fait, déployez la stack. Cela prendra un peu de temps, vérifiez les logs, vous devriez arriver à `serveur ready`
|
||||
|
||||
Une fois le conteneur en ligne, vérifiez dans cloudflare que votre tunnel est bien présent dans la section _Networks > Tunnels_ de [Cloudflare Zero Trust](https://one.dash.cloudflare.com/). Par défaut, l'ensemble des sous domaine sont redirigés vers le tunnel, sans avoir besoin de les déclarer [dans votre zone DNS](/generalites/dns).
|
||||
|
||||
::alert{type="success"}
|
||||
✨ __Astuce:__ si vous voulez exposer un service sans tunnel, vous pouvez toujours déclarer un enregistrement A [dans votre zone DNS](/generalites/dns). En cas de problème de résolution, désactivez la fonction _proxy_ pour cet enregistrement. Par exemple pour `sous.mondomaine.fr`
|
||||
|
||||
::
|
||||
|
||||
|
||||
## Gérer plusieurs tunnels pour plusieurs serveurs
|
||||
---
|
||||
Par défaut, l'ensemble des sous domaine de votre nom de domaine pointent vers le tunnel que vous avez créé. Mais si vous avez un second serveur, vous pouvez avoir un second tunnel en changeant seulement le nom de tunnel dans la configuration de l'instance swag de votre serveur.
|
||||
|
||||
Vous devrez ensuite dans votre zone DNS rediriger les sous domaine souhaité vers le bon tunnel. Pour cela, faites comme suit.
|
||||
|
||||
Rendez-vous dans dans la section _Networks > Tunnels_ de [Cloudflare Zero Trust](https://one.dash.cloudflare.com/).
|
||||
|
||||
Notez les deux ID des tunnels
|
||||
|
||||
|
||||
|
||||
Rendez-vous à présent dans la section DNS de [cloudflare](https://dash.cloudflare.com/), après avoir cliqué sur le nom de domaine concerné.
|
||||
|
||||
Cliquez sur `ajouter un enregistrement` et ajoutez deux enregistrements comme suit en ajoutant bien `.cfargotunnel.com` après vos id de tunnels.
|
||||
|
||||
| Type | Nom | Cible |
|
||||
|---------|----------------|-------------------------------------|
|
||||
| `CNAME` | `sousdomaine1` | `votreiddetunnel1.cfargotunnel.com` |
|
||||
| `CNAME` | `sousdomaine2` | `votreiddetunnel2.cfargotunnel.com` |
|
||||
|
||||
|
||||
|
||||
Si vous avez de nombreux sous-domaines, vous pouvez déclarer un seul sous domaine par tunnel comme ci-dessus, puis déclarer vos autres sous domaine en les faisant pointer vers ces sous domaines de référence.
|
||||
|
||||
Ainsi, en cas de changement d'id de tunnel, vous n'aurez qu'à le changer que pour un seul sous-domaine.
|
||||
Par exemple :
|
||||
|
||||
- Le serveur de `sousdomaine1` doit egalement etre la cible de sub1, et sub2 :
|
||||
|
||||
| Type | Nom | Cible |
|
||||
|---------|----------------|-------------------------------------|
|
||||
| `CNAME` | `sub1` | `sousdomaine1` |
|
||||
| `CNAME` | `sub2` | `sousdomaine1` |
|
||||
|
||||
- Le serveur de `sousdomaine2` doit egalement etre la cible de sub3, et sub4 :
|
||||
|
||||
| Type | Nom | Cible |
|
||||
|---------|----------------|-------------------------------------|
|
||||
| `CNAME` | `sub3` | `sousdomaine2` |
|
||||
| `CNAME` | `sub4` | `sousdomaine2` |
|
||||
|
||||
1
content/3.serveex/3.securite/_dir.yml
Normal file
1
content/3.serveex/3.securite/_dir.yml
Normal file
@ -0,0 +1 @@
|
||||
navigation.title: La sécurité
|
||||
Reference in New Issue
Block a user