Restructuration et vulgarisation

This commit is contained in:
Pierre Coimbra
2020-02-21 14:54:26 +01:00
parent aa86186014
commit a2b0df16d8
19 changed files with 218 additions and 46 deletions

View File

@@ -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)

View 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)

View File

@@ -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](#)

View 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](#)

View File

@@ -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.

View File

Before

Width:  |  Height:  |  Size: 143 KiB

After

Width:  |  Height:  |  Size: 143 KiB

View 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)

View File

@@ -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.

View 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](#)

View File

@@ -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.

View 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)