Restructuration et vulgarisation
This commit is contained in:
@@ -1,10 +1,10 @@
|
||||
# Applicatif
|
||||
Vous trouverez ici toute la documentation relative à la partie applicative. Les services sont découpés en plusieurs zones qui sont décrite dans le premier point. L'accès au réseau des services de cette zone est décrit dans la partie réseau, il est donc impératif de mettre en place le réseau avant de s'occuper de l'applicatif.
|
||||
|
||||
1. [Répartition des services dans les zones](#)
|
||||
2. [Zone WAN](#)
|
||||
3. [Zone DMZ](#)
|
||||
4. [Zone Proxy](#)
|
||||
5. [Zone Interne](#)
|
||||
6. [Zone CTF](#)
|
||||
7. [Zone "Sale"](#)
|
||||
# Table des matières
|
||||
1. [Répartition des services dans les zones](repartition_en_zones.md)
|
||||
2. [Zone WAN](zone_wan/README.md)
|
||||
3. [Zone DMZ](zone_dmz/README.md)
|
||||
4. [Zone Proxy](zone_proxy/README.md)
|
||||
5. [Zone Interne](zone_interne/README.md)
|
||||
6. [Zone CTF](zone_ctf/README.md)
|
||||
|
||||
90
applicatif/repartition_en_zones.md
Normal file
90
applicatif/repartition_en_zones.md
Normal file
@@ -0,0 +1,90 @@
|
||||
# Répartition des services en zones
|
||||
|
||||
Les services seront réparti en plusieurs zones à la manière du découpage du réseau. Il est donc recommandé d'avoir compris l'infrastructure réseau avant de lire cette partie.
|
||||
|
||||
|
||||
## Services Frontend
|
||||
Les services Frontend sont directement accessible depuis internet derrière OPNSense.
|
||||
|
||||
### Zone WAN
|
||||
Cette zone regroupe les pare-feux et les hyperviseurs.
|
||||
|
||||
Les services DMZ devront avoir les interfaces réseau suivante
|
||||
- Bridge WAN VLAN 10 (WAN)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
Pour OPNSense
|
||||
- Bridge Interne VLAN 10 (DMZ)
|
||||
|
||||
|
||||
### Zone DMZ
|
||||
Cette zone regroupe les services qui nécessite un accès direct à internet.
|
||||
|
||||
C'est le cas de,
|
||||
- HAProxy, le proxy/loadbalanceur qui filtre les accès aux services depuis l'extérieur.
|
||||
- Bind9, le serveur DNS qui servira à la fois de résolveur interne et de zone DNS pour le domaine krhacken.org.
|
||||
- Squid, le proxy filtrant qui s'occupe de gérer l'accès à internet des conteneurs/VM
|
||||
|
||||
Les services DMZ devront avoir les interfaces réseau suivante
|
||||
- Bridge Interne VLAN 10 (DMZ)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
Pour HAProxy
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
|
||||
Pour Bind9
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
|
||||
Pour Squid
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
- Bridge Interne VLAN 50 (EXT)
|
||||
|
||||
## Services Backend
|
||||
|
||||
### Zone PROXY
|
||||
Cette zone est une sorte de DMZ de DMZ, c'est à dire qu'elle se place entre la DMZ et la zone INT. Elle acceuille les services faisant le lien entre la Frontend et la backend.
|
||||
|
||||
C'est le cas de,
|
||||
- NGINX qui servira de reverse proxy http
|
||||
- Proxmox Mail Gateway, le relais entre l'extérieur et le serveur mail en backend qui s'occupe aussi de filtrer les mails (antispam et antivirus).
|
||||
|
||||
Les services de la zone PROXY devront avoir les interfaces réseau suivante
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
### Zone INT
|
||||
Cette zone regroupe les services sensibles permanents soit tout sauf ce qui concerne les tests et les CTF. Elle contient uniquement des services backend.
|
||||
|
||||
C'est le cas de,
|
||||
- L'annuaire LDAP (slapd), qui permettra d'avoir un compte unique pour accéder à tous nos services, avec des groupes limitant l'accès à certain services.
|
||||
- Du serveur mail qui sera en lien avec le relais mail présent dans le zone PROXY.
|
||||
- Tout les autres services plus classique (serveurs web, cloud, git...).
|
||||
|
||||
Les services de la zone INT devront avoir les interfaces réseau suivante
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
### Zone CTF
|
||||
Cette zone regroupe les différents services en rapport avec la partie CTF
|
||||
|
||||
C'est le cas de
|
||||
- NGINX, qui servira de reverse proxy dédié à la partie CTF.
|
||||
- VM avec du Docker pour les environnement Web et Système.
|
||||
- CTFd qui servira d'interface utilisateur pour les CTF.
|
||||
|
||||
Les services de la zone CTF devront avoir les interfaces réseau suivante
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
## Zone DIRTY
|
||||
Cette zone regroupe rien de spécial à part d'éventuels containers de test. Elle ne sera d'ailleurs pas documenté ici.
|
||||
|
||||
Les services de la zone DIRTY devront avoir les interfaces réseau suivante
|
||||
- Bridge Interne VLAN 50 (DIRTY)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
@@ -1,2 +1,15 @@
|
||||
# Présentation de la zone CTF
|
||||
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la zone CTF. Cela comprend le reverse proxy CTF, l'environnement Web, l'environnement Système et CTFd.
|
||||
# Zone CTF
|
||||
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la zone CTF.
|
||||
|
||||
Cela comprend le reverse proxy CTF, l'environnement Web, l'environnement Système et CTFd.
|
||||
|
||||
## Réseau
|
||||
Les services de la zone CTF devront avoir les interfaces réseaux suivante
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
# Table des matières
|
||||
1. [Reverse Proxy NGINX](nginx_ctf.md)
|
||||
2. [Environnment Web](environnement_web.md)
|
||||
3. [Environnment Système](environnement_systeme.md)
|
||||
4. [CTFd](#)
|
||||
|
||||
29
applicatif/zone_dmz/README.md
Normal file
29
applicatif/zone_dmz/README.md
Normal file
@@ -0,0 +1,29 @@
|
||||
# Zone DMZ
|
||||
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la DMZ.
|
||||
|
||||
Cela comprend les deux HAProxy, le serveur DNS et le proxy pour l'accès à internet des contenants.
|
||||
|
||||
## Réseau
|
||||
Les services DMZ devront avoir les interfaces réseau suivante
|
||||
- Bridge Interne VLAN 10 (DMZ)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
Pour HAProxy
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
|
||||
Pour Bind9
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
|
||||
Pour Squid
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Interne VLAN 40 (CTF)
|
||||
- Bridge Interne VLAN 50 (EXT)
|
||||
|
||||
# Table des matières
|
||||
1. [HAProxy](haproxy.md)
|
||||
2. [Serveur DNS](#)
|
||||
3. [Proxy pour les contenants](#)
|
||||
@@ -1,8 +1,8 @@
|
||||
# Gestion du flux post-firewall
|
||||
|
||||
|
||||
## Présentation des containers
|
||||
|
||||
Deux containers Debian 10 identiques, un sur Alpha l'autre sur Bêta avec deux interfaces
|
||||
Deux containers Debian 10 identiques, un sur Alpha l'autre sur Bêta avec deux interfaces
|
||||
- Sur Alpha le container HAProxy a comme IP 10.0.0.3/24 sur ROUTE (eth0) 10.0.1.3/24 sur CTF (eth1)
|
||||
- Sur Beta le container HAProxy a comme IP 10.0.0.4/24 sur ROUTE 10.0.1.4/24 sur CTF
|
||||
L'option Firewall PVE des interfaces est désactivée
|
||||
@@ -19,7 +19,7 @@ Trois objectifs pour la gestion du flux post-firewall
|
||||
|
||||
Voici les choix techniques faits afin de répondre à ces objectifs
|
||||
- Pour le load balancing entre les deux reverse proxy Nginx, on utilisera HAProxy.Le lien sécurisé sera entre l'utilisateur de HAProxy qui soumettra ensuite des requêtes HTTP à un des reverse proxy Nginx.
|
||||
- Pour la redondance du proxy entre les deux nodes, on utilisera keepalived et la technologie VRRP pour garantir la disponibilité du proxy via une ip virtuelle.
|
||||
- Pour la redondance du proxy entre les deux nodes, on utilisera keepalived et la technologie VRRP pour garantir la disponibilité du proxy via une ip virtuelle.
|
||||
- Pour la vérification du certificat client - uniquement si le client veut se connecter au panel Proxmox- on fera une première frontend à la couche 4 (TCP) pour les connexions https qui rediregera les connexions vers le panel sur une frontend dédié et le reste vers une frontend par défaut.
|
||||
- Pour les certificats SSL, nous allons utiliser Let's Encrypt avec un serveur Nginx local dédié à l'obtention des certificats et des scripts pour le dépoiement sur les deux containers HAProxy.
|
||||
- La séparation des flux entre les deux reverse public et le reverse ctf ce fera au niveau de la seconde frontend par défaut tout comme le filtrage des requêtes par nom de domaine.
|
||||
@@ -74,13 +74,13 @@ systemctl enable nginx
|
||||
```
|
||||
Pour la vérification du certificat du client, la méthode est dans la git. Il faut placer le ca.crt dans /home/hasync/pve.crt et ajouter le CN autorisé dans /home/hasync/allowed_cn.txt
|
||||
|
||||
### Configuration
|
||||
### Configuration
|
||||
Voilà une rapide explication de la configuration faite
|
||||
- Une première frontend (all-web-in) de type TCP en écoute sur le port 443 qui vérifie si les requêtes tcp sont bien SSL et redirige tout vers la frontend principale via un proxy sauf les requêtes vers la panel Proxmox qui sont redirigées vers la frontend admin via un proxy.
|
||||
|
||||
- La frontend principale (user-web-in) de type http écoute sur le ports 80 et le proxy évoqué plus haut. Filtrage des requêtes ne respectant pas le nom de domaine et forçage du https sans www sinon rejet du packet. Redirection des requêtes Let's Encrypt vers un serveur Nginx local dédié aux certifications sinon séparation du flux avec d'un côté une backend s'occupant du load balancing entre les deux reverse proxy Nginx public et de l'autre une backend redirigeant vers le reverse proxy ctf à l'aide du nom de domaine.
|
||||
- La frontend principale (user-web-in) de type http écoute sur le ports 80 et le proxy évoqué plus haut. Filtrage des requêtes ne respectant pas le nom de domaine et forçage du https sans www sinon rejet du packet. Redirection des requêtes Let's Encrypt vers un serveur Nginx local dédié aux certifications sinon séparation du flux avec d'un côté une backend s'occupant du load balancing entre les deux reverse proxy Nginx public et de l'autre une backend redirigeant vers le reverse proxy ctf à l'aide du nom de domaine.
|
||||
|
||||
#### /etc/haproxy/haproxy.cfg
|
||||
#### /etc/haproxy/haproxy.cfg
|
||||
```
|
||||
global
|
||||
log /dev/log local0
|
||||
@@ -119,7 +119,7 @@ frontend all-web-in
|
||||
use_backend is-admin if { req_ssl_sni -i pve.sessionkrkn.fr }
|
||||
use_backend is-admin if { req_ssl_sni -i rspamd.sessionkrkn.fr }
|
||||
default_backend is-user
|
||||
|
||||
|
||||
frontend user-web-in
|
||||
mode http
|
||||
bind *:80 interface eth0
|
||||
@@ -138,7 +138,7 @@ frontend user-web-in
|
||||
|
||||
redirect scheme https code 301 if !{ ssl_fc } authorized_host !host_letsencrypt !mail
|
||||
use_backend nginx-ctf if ctf_host !host_letsencrypt !mail
|
||||
use_backend letsencrypt if host_letsencrypt !mail
|
||||
use_backend letsencrypt if host_letsencrypt !mail
|
||||
use_backend reverse-nginx if authorized_host !ctf_host OR mail
|
||||
default_backend drop-http
|
||||
|
||||
@@ -151,11 +151,11 @@ frontend admin-in
|
||||
use_backend reverse-nginx if { ssl_fc_has_crt } is_auth rspamd
|
||||
use_backend pve-interface if { ssl_fc_has_crt } is_auth pve
|
||||
default_backend drop-http
|
||||
|
||||
|
||||
backend is-admin
|
||||
mode tcp
|
||||
server admin-in abns@haproxy-admin send-proxy-v2
|
||||
|
||||
|
||||
backend is-user
|
||||
mode tcp
|
||||
server admin-in abns@haproxy-user send-proxy-v2
|
||||
@@ -209,7 +209,7 @@ server {
|
||||
systemctl restart nginx.service
|
||||
systemctl restart haproxy.service
|
||||
```
|
||||
### Obtention des premiers certificats et déploiement
|
||||
### Obtention des premiers certificats et déploiement
|
||||
```
|
||||
certbot certonly --webroot -w /home/hasync/letsencrypt-requests/ -d sub.sessionkrkn.fr
|
||||
```
|
||||
@@ -219,7 +219,7 @@ Voici un script pour mettre en place les certificats Let's Encrypt au bon endroi
|
||||
#!/bin/bash
|
||||
rm -f /etc/letsencrypt/live/README
|
||||
rm -rf /etc/ssl/letsencrypt/*
|
||||
for domain in $(ls /etc/letsencrypt/live); do
|
||||
for domain in $(ls /etc/letsencrypt/live); do
|
||||
cat /etc/letsencrypt/live/$domain/privkey.pem /etc/letsencrypt/live/$domain/fullchain.pem > /etc/ssl/letsencrypt/$domain.pem
|
||||
done
|
||||
scp -r /etc/ssl/letsencrypt/* root@10.0.0.3:/etc/ssl/letsencrypt
|
||||
@@ -252,7 +252,7 @@ vrrp_script chk_haproxy {
|
||||
interval 2
|
||||
weight 2
|
||||
}
|
||||
|
||||
|
||||
vrrp_instance VI_1 {
|
||||
interface eth0
|
||||
state MASTER
|
||||
@@ -276,7 +276,7 @@ vrrp_script chk_haproxy {
|
||||
interval 2
|
||||
weight 2
|
||||
}
|
||||
|
||||
|
||||
vrrp_instance VI_1 {
|
||||
interface eth0
|
||||
state MASTER
|
||||
@@ -308,7 +308,7 @@ Voilà un script d'automatisation à mettre sur les deux containers
|
||||
if [ "$(ip a | grep -c "10.0.0.5")" -ge 1 ]; then
|
||||
certbot renew
|
||||
rm -rf /etc/ssl/letsencrypt/*
|
||||
for domain in $(ls /etc/letsencrypt/live); do
|
||||
for domain in $(ls /etc/letsencrypt/live); do
|
||||
cat /etc/letsencrypt/live/$domain/privkey.pem /etc/letsencrypt/live/$domain/fullchain.pem > /etc/ssl/letsencrypt/$domain.pem
|
||||
done
|
||||
scp -r /etc/ssl/letsencrypt/* hasync@<ip_autre_ct>:/etc/ssl/letsencrypt
|
||||
@@ -320,4 +320,4 @@ Le script est stocké dans /home/hasync/renew.sh, voici la crontab à ajouter (c
|
||||
0 4 */15 * * /bin/sh /home/hasync/renew.sh >/dev/null 2>&1
|
||||
```
|
||||
|
||||
C'est tout pour la configuration de HAProxy, la prochaine étape est la mise en place des trois reverses proxy.
|
||||
C'est tout pour la configuration de HAProxy, la prochaine étape est la mise en place des trois reverses proxy.
|
||||
|
Before Width: | Height: | Size: 143 KiB After Width: | Height: | Size: 143 KiB |
14
applicatif/zone_interne/README.md
Normal file
14
applicatif/zone_interne/README.md
Normal file
@@ -0,0 +1,14 @@
|
||||
# Zone INT
|
||||
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration applicative des services de la zone INT.
|
||||
|
||||
Cela comprend tous les containers des services sensible permanents (Nextcloud, Gitea...) et les services internes nécessaires au fonctionnement des services sensible comme l'annuaire LDAP.
|
||||
|
||||
## Réseau
|
||||
Les services de la zone PROXY devront avoir les interfaces réseau suivante
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
# Table des matières
|
||||
1. [LDAP](ldap.md)
|
||||
2. [Serveur Mail](mail.md)
|
||||
@@ -1,2 +0,0 @@
|
||||
# Présentation de la zone KRKN
|
||||
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la zone KRKN. Cela comprend tous les containers des services publics (Nextcloud, Gitea...) et les services internes nécessaires au fonctionnement des services publics comme l'annuaire LDAP.
|
||||
14
applicatif/zone_proxy/README.md
Normal file
14
applicatif/zone_proxy/README.md
Normal file
@@ -0,0 +1,14 @@
|
||||
# Zone PROXY
|
||||
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration applicative des services de la zone PROXY.
|
||||
|
||||
Cela comprend tous les services faisant le lien entre la frontend et la backend (Reverse NGINX et Relais Mail).
|
||||
|
||||
## Réseau
|
||||
Les services de la zone PROXY devront avoir les interfaces réseau suivante
|
||||
- Bridge Interne VLAN 20 (PROXY)
|
||||
- Bridge Interne VLAN 30 (INT)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
# Table des matières
|
||||
1. [Reverse Proxy NGINX](nginx_principal.md)
|
||||
2. [Relais mails](#)
|
||||
@@ -1,2 +0,0 @@
|
||||
# Présentation de la zone ROUTE
|
||||
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration de la zone ROUTE. Cela comprend les deux HAProxy et les deux reverses proxy public nginx.
|
||||
12
applicatif/zone_wan/README.md
Normal file
12
applicatif/zone_wan/README.md
Normal file
@@ -0,0 +1,12 @@
|
||||
# Zone WAN
|
||||
Vous trouverez ici toute la documentation relative au fonctionnement et à la configuration applicative des services de la zone WAN.
|
||||
|
||||
Cela comprend les pare-feu et les hyperviseurs. C'est cette zone qui aura un accès direct à l'extérieur.
|
||||
|
||||
## Réseau
|
||||
Les services DMZ devront avoir les interfaces réseau suivante
|
||||
- Bridge WAN VLAN 10 (WAN)
|
||||
- Bridge Admin VLAN 100 (ADMIN)
|
||||
|
||||
Pour OPNSense
|
||||
- Bridge Interne VLAN 10 (DMZ)
|
||||
Reference in New Issue
Block a user