Browse Source

Changement total de l'infra réseau

master
Pierre Coimbra 1 year ago
parent
commit
6df6fca32b
Signed by: pcoimbra GPG Key ID: F9C449C78F6FAEE6
36 changed files with 471 additions and 606 deletions
  1. +2
    -2
      applicatif/README.md
  2. +14
    -31
      applicatif/repartition_en_zones.md
  3. +2
    -2
      applicatif/zone_ctf/README.md
  4. +4
    -4
      applicatif/zone_ctf/environnement_systeme.md
  5. +3
    -3
      applicatif/zone_ctf/nginx_ctf.md
  6. +1
    -17
      applicatif/zone_dmz/README.md
  7. +234
    -66
      applicatif/zone_dmz/dns.md
  8. +8
    -8
      applicatif/zone_dmz/haproxy/certificat_ssl_client.md
  9. +30
    -33
      applicatif/zone_dmz/haproxy/haproxy.md
  10. +20
    -25
      applicatif/zone_dmz/proxy_interne.md
  11. +1
    -2
      applicatif/zone_interne/README.md
  12. +4
    -5
      applicatif/zone_interne/gitea.md
  13. +9
    -10
      applicatif/zone_interne/ldap/interface_web_ldap.md
  14. +2
    -3
      applicatif/zone_interne/ldap/serveur_ldap.md
  15. +2
    -3
      applicatif/zone_interne/mail.md
  16. +4
    -5
      applicatif/zone_interne/nextcloud.md
  17. +3
    -4
      applicatif/zone_interne/rocket_chat.md
  18. +2
    -3
      applicatif/zone_proxy/README.md
  19. +3
    -7
      applicatif/zone_proxy/nginx_principal.md
  20. +1
    -5
      applicatif/zone_wan/README.md
  21. +5
    -5
      applicatif/zone_wan/opnsense/configuration_initiale.md
  22. +2
    -0
      deploiement/README.md
  23. +0
    -8
      deploiement/sources/hosts
  24. +3
    -3
      presentation_projet.md
  25. +3
    -20
      proxmox/creation_cluster.md
  26. +10
    -10
      proxmox/haute_disponibilite.md
  27. +3
    -9
      proxmox/installation_hyperviseurs.md
  28. +1
    -1
      proxmox/introduction_a_la_virtualisation.md
  29. +1
    -1
      proxmox/securisation/systeme_authentification_base.md
  30. +24
    -72
      proxmox/securisation/template_ferm.md
  31. +2
    -2
      proxmox/systeme_de_fichier.md
  32. +28
    -0
      reseau/logique_interface_pare_feu.md
  33. +0
    -18
      reseau/logique_ip_ct_vm.md
  34. +36
    -215
      reseau/mise_en_place.md
  35. +2
    -2
      reseau/topologie_globale.md
  36. +2
    -2
      reseau/topologie_reseau_virtuel.md

+ 2
- 2
applicatif/README.md View File

@ -27,6 +27,6 @@ L'accès au réseau des services est décrit dans la partie réseau, il est donc
4. [Gitea](zone_interne/gitea.md)
6. [Zone CTF](zone_ctf)
1. [Reverse Proxy NGINX](zone_ctf/nginx_ctf.md)
2. [Environnment Web](zone_ctf/environnement_web.md)
3. [Environnment Système](zone_ctf/environnement_systeme.md)
2. [Environnement Web](zone_ctf/environnement_web.md)
3. [Environnement Système](zone_ctf/environnement_systeme.md)
4. [CTFd](#)

+ 14
- 31
applicatif/repartition_en_zones.md View File

@ -2,6 +2,7 @@
Les services seront répartis 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.
C'est un complément à [cette page](!../reseau/topologie_globale) et [cette page](!../reseau/topologie_reseau_virtuel)
## Services Frontend
@ -11,13 +12,16 @@ Les services Frontend sont directement accessibles depuis internet derrière OPN
Cette zone regroupe les pare-feux et les hyperviseurs.
Les services DMZ devront avoir les interfaces réseau suivantes :
- Bridge WAN VLAN 10 (WAN)
- Bridge Admin VLAN 100 (ADMIN)
Pour OPNSense
Les hyperviseurs WAN devront avoir, en plus des interfaces par défaut, l'interface réseau suivante :
- Bridge Interne VLAN 10 (DMZ)
Les Pare-feux devront avoir les interfaces réseau suivantes :
- Bridge Interne VLAN 10 (DMZ)
- Bridge Interne VLAN 20 (PROXY)
- Bridge Interne VLAN 30 (INT)
- Bridge Interne VLAN 40 (CTF)
- Bridge Interne VLAN 50 (DIRTY)
- Bridge Admin VLAN 100 (ADMIN)
### Zone DMZ
@ -28,24 +32,8 @@ C'est le cas de,
- 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 suivantes :
Les services DMZ devront avoir l'interface 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 (DIRTY)
## Services Backend
@ -56,10 +44,8 @@ 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 suivantes :
Les services de la zone PROXY devront avoir l'interface 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, donc tout sauf ce qui concerne les tests et les CTF. Elle contient uniquement des services backend.
@ -69,9 +55,8 @@ C'est le cas de
- Du serveur mail qui sera en lien avec le relais mail présent dans le zone PROXY.
- Tous les autres services plus classiques (serveurs web, cloud, git...).
Les services de la zone INT devront avoir les interfaces réseau suivantes :
Les services de la zone INT devront avoir l'interface 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.
@ -81,14 +66,12 @@ C'est le cas de
- VM avec du Docker pour les environnements 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 suivantes :
Les services de la zone CTF devront avoir l'interface réseau suivante :
- Bridge Interne VLAN 40 (CTF)
- Bridge Admin VLAN 100 (ADMIN)
### Zone DIRTY
Cette zone ne regroupe rien de spécial mis à part d'éventuels conteneurs de test. Elle ne sera d'ailleurs pas documentée ici.
Les services de la zone DIRTY devront avoir les interfaces réseau suivantes :
Les services de la zone DIRTY devront avoir l'interface réseau suivante :
- Bridge Interne VLAN 50 (DIRTY)
- Bridge Admin VLAN 100 (ADMIN)

+ 2
- 2
applicatif/zone_ctf/README.md View File

@ -4,9 +4,9 @@ Vous trouverez ici toute la documentation relative au fonctionnement et à la co
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 suivantes :
Les services de la zone CTF devront avoir l'interface réseau suivante :
- Bridge Interne VLAN 40 (CTF)
- Bridge Admin VLAN 100 (ADMIN)
# Table des matières
1. [Reverse Proxy NGINX](nginx_ctf.md)


+ 4
- 4
applicatif/zone_ctf/environnement_systeme.md View File

@ -35,7 +35,7 @@ adduser systeme docker
su systeme
```
#### /usr/local/bin/dockersh
```
```python
#!/usr/bin/env python3
# PYTHON_ARGCOMPLETE_OK
import os
@ -180,7 +180,7 @@ docker built -t debmod .
Usage : ./createImg <systemeXX> <dockerfile>
```
```bash
#!/bin/bash
if [ "$#" -lt "2" ]
then
@ -199,7 +199,7 @@ fi
Usage ./deployEnv <systemeXX>
```
```bash
#!/bin/bash
if [ "$#" -eq "0" ]
then
@ -239,7 +239,7 @@ systeme7 -> history
Extraire l'archive des challenge dans /home/systeme/SystemeChall/
### Script qui utilisera les deux autres pour tout déployer
```
```bash
#!/bin/bash
declare -a path=(easyshell pwn_my_home overflow shellcode1 shellcode2 shellcode3 history)
for i in `seq 0 6`;


+ 3
- 3
applicatif/zone_ctf/nginx_ctf.md View File

@ -11,15 +11,15 @@ Ce service n'est pas redondé car non vital. Il portera le numéro 145 sur Beta.
#### /root/.wgetrc
```
http_proxy = http://10.0.3.252:3128/
https_proxy = http://10.0.3.252:3128/
http_proxy = http://10.0.0.252:3128/
https_proxy = http://10.0.0.252:3128/
use_proxy = on
```
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.3.252:9999";
Proxy "http://10.0.0.252:9999";
};
```


+ 1
- 17
applicatif/zone_dmz/README.md View File

@ -4,24 +4,8 @@ Vous trouverez ici toute la documentation relative au fonctionnement et à la co
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 suivantes :
Les services DMZ devront avoir l'interface 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 (DIRTY)
# Table des matières
1. [HAProxy](haproxy)


+ 234
- 66
applicatif/zone_dmz/dns.md View File

@ -8,18 +8,15 @@ On conseille généralement de ne pas faire les deux sur un même serveur. En ef
## Le conteneur
Numéro 107 (Beta)
#### Trois interfaces
- eth0 : vmbr1 / VLAN 10 / IP 10.0.0.253 / GW 10.0.0.254
- eth1 : vmbr1 / VLAN 20 / IP 10.0.1.253 / GW 10.0.1.254
- eth2 : vmbr1 / VLAN 30 / IP 10.0.2.253 / GW 10.0.2.254
- eth3 : vmbr2 / VLAN 100 / IP 10.1.0.107 / GW 10.1.0.254
#### Interface réseau
- eth0 : vmbr1 / VLAN 20 / IP 10.0.1.253 / GW 10.0.1.254
### Le proxy
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.2.252:9999";
Proxy "http://10.0.0.252:9999";
};
```
@ -77,47 +74,67 @@ logging {
```
## Gestion par vue
Pour savoir depuis quelle zone de notre réseau la requête est faites nous allons utiliser les vues de bind9 ainsi le serveur pourra renvoyer une IP différente en fonction de la zone.
Le serveur aura une pâte sur chaque zone comme décrit ci-dessous :
- DMZ -> 10.0.0.253
- PROXY -> 10.0.1.253
- INT -> 10.0.2.253
Pour savoir depuis quelle zone de notre réseau la requête est faites nous allons utiliser les vues de bind9 ainsi le serveur pourra renvoyer une IP différente en fonction de la zone. Bind choisi la zone du client en fonction de l'adresse IP source.
On définit deux zones DNS, une première, **front**, qui regroupe les zones DMZ et PROXY et une seconde, **back** qui regroupe les zones PROXY et INT.
On définit quatres zones DNS, une première, **front**, pour la zones DMZ, une seconde, **proxy** pour la zone PROXY, une troisième **back** pour la zone Interne et une quatrième **admin** qui regroupe toutes les zones.
### /etc/bind/named.conf
```
include "/etc/bind/named.conf.options";
acl front {
127.0.0.1;
acl proxy {
10.0.0.0/24;
};
acl back {
acl proxy {
127.0.0.1;
10.0.1.0/24;
};
acl back {
10.0.2.0/24;
};
acl admin {
10.1.0.0/24;
};
view "internalfront" {
recursion yes;
match-clients {front;};
allow-query {front;};
allow-recursion {front;};
allow-query-cache {front;};
match-clients {proxy;};
allow-query {proxy;};
allow-recursion {proxy;};
allow-query-cache {proxy;};
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
zone "krhacken.org" {
notify no;
type master;
file "/etc/bind/zones/db.krhacken.org.front";
file "/etc/bind/zones/db.krhacken.org.proxy";
};
zone "1.0.10.in-addr.arpa" {
zone "0.0.10.in-addr.arpa" {
notify no;
type master;
file "/etc/bind/zones/db.krhacken.org.intrafront.rev";
};
};
view "internalproxy" {
recursion yes;
match-clients {proxy;};
allow-query {proxy;};
allow-recursion {proxy;};
allow-query-cache {proxy;};
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
zone "krhacken.org" {
notify no;
type master;
file "/etc/bind/zones/db.krhacken.org.proxy";
};
zone "1.0.10.in-addr.arpa" {
notify no;
type master;
file "/etc/bind/zones/db.krhacken.org.intraproxy.rev";
};
};
view "internalback" {
recursion yes;
match-clients {back;};
@ -131,105 +148,256 @@ view "internalback" {
type master;
file "/etc/bind/zones/db.krhacken.org.back";
};
zone "1.1.10.in-addr.arpa" {
zone "2.0.10.in-addr.arpa" {
notify no;
type master;
file "/etc/bind/zones/db.krhacken.org.intraback.rev";
};
};
view "internaladmin" {
recursion yes;
match-clients {admin;};
allow-query {admin;};
allow-recursion {admin;};
allow-query-cache {admin;};
include "/etc/bind/named.conf.default-zones";
include "/etc/bind/zones.rfc1918";
zone "krhacken.org" {
notify no;
type master;
file "/etc/bind/zones/db.krhacken.org.admin";
};
zone "0.1.10.in-addr.arpa" {
notify no;
type master;
file "/etc/bind/zones/db.krhacken.org.intraadmin.rev";
};
};
```
## Les serveurs récursif-cache
Voici les trois fichiers pour la configuration pour les forward DNS.
Pour la zone **front** :
### /etc/bind/zones/db.krhacken.org.front
```
$TTL 10800
@ IN SOA dns.krhacken.org. dnsmaster.krhacken.org. (
2015010101 ; Serial
@ IN SOA dns.krhacken.org. r.krhacken.org. (
2020050101 ; Serial
5400 ; Refresh
2700 ; Retry
2419200 ; Expire
300 ) ; Negative TTL
IN NS dns.krhacken.org. ;Nom du serveur
alpha.fw IN A 10.0.0.1
beta.fw IN A 10.0.0.2
vip.fw IN A 10.0.0.3
alpha.haproxy IN A 10.0.0.4
beta.haproxy IN A 10.0.0.5
vip.haproxy IN A 10.0.0.6
proxyint IN A 10.0.0.7
mail IN A 10.0.0.10
dns IN A 10.0.0.253
alpha.nginx IN A 10.0.1.3
beta.nginx IN A 10.0.1.4
IN NS dns.krhacken.org.
alpha.pve IN A 10.0.0.1
beta.pve IN A 10.0.0.2
alpha.fw IN A 10.0.0.3
beta.fw IN A 10.0.0.4
alpha.haproxy IN A 10.0.0.5
beta.haproxy IN A 10.0.0.6
vip.haproxy IN A 10.0.0.7
proxy IN A 10.0.0.252
dns IN A 10.0.1.253
vip.fw IN A 10.0.1.254
```
Pour la zone **proxy** :
```
$TTL 10800
@ IN SOA dns.krhacken.org. r.krhacken.org. (
2020050101 ; Serial
5400 ; Refresh
2700 ; Retry
2419200 ; Expire
300 ) ; Negative TTL
IN NS dns.krhacken.org.
alpha.nginx IN A 10.0.1.1
beta.nginx IN A 10.0.1.2
mail IN A 10.0.1.5
alpha.fw IN A 10.0.1.252
beta.fw IN A 10.0.1.253
vip.fw IN A 10.0.1.254
```
Pour la zones **back** :
### /etc/bind/zones/db.krhacken.org.back
```
$TTL 10800
@ IN SOA dns.krhacken.org. dnsmaster.krhacken.org. (
2015010101 ; Serial
@ IN SOA dns.krhacken.org. r.krhacken.org. (
2020050101 ; Serial
5400 ; Refresh
2700 ; Retry
2419200 ; Expire
300 ) ; Negative TTL
IN NS dns.krhacken.org. ;Nom du serveur
alpha.haproxy IN A 10.0.1.1
beta.haproxy IN A 10.0.1.2
IN NS dns.krhacken.org.
IN A 10.0.2.7
alpha.ldap IN A 10.0.2.1
beta.ldap IN A 10.0.2.2
vip.ldap IN A 10.0.2.3
alpha.nginx IN A 10.0.2.4
beta.nginx IN A 10.0.2.5
dns IN A 10.0.2.253
proxyint IN A 10.0.2.254
mail IN A 10.0.2.4
back.mail IN A 10.0.2.5
ldapui IN A 10.0.2.6
wiki IN A 10.0.2.8
cloud IN A 10.0.2.10
git IN A 10.0.2.11
keyserver IN A 10.0.2.12
pass IN A 10.0.2.13
alpha.fw IN A 10.0.2.252
beta.fw IN A 10.0.2.253
vip.fw IN A 10.0.2.254
```
Pour la zone **admin** :
### /etc/bind/zones/db.krhacken.org.admin
```
$TTL 10800
@ IN SOA dns.krhacken.org. r.krhacken.org (
2020050101 ; Serial
5400 ; Refresh
2700 ; Retry
2419200 ; Expire
300 ) ; Negative TTL
IN NS dns.krhacken.org. ;Nom du serveur
master.haproxy IN A 10.0.0.6
slave.haproxy IN A 10.0.0.7
proxy IN A 10.0.0.252
master.nginx IN A 10.0.1.3
slave.nginx IN A 10.0.1.4
dns IN A 10.0.0.253
ldap IN A 10.0.2.1
mail IN A 10.0.2.10
ldapui IN A 10.0.2.15
nextcloud IN A 10.0.2.20
gitea IN A 10.0.2.21
rocketchat IN A 10.0.2.30
drone IN A 10.0.2.14
ctf.nginx IN A 10.0.3.4
club.ctfd IN A 10.0.3.10
ct.snt IN A 10.0.3.50
blog IN A 10.0.2.50
grafana IN A 10.1.0.252
ansible IN A 10.1.0.253
opn IN A 10.0.0.254
vm.snt IN A 10.0.3.10
```
INT
## Les serveurs d’autorité
Voici les trois fichiers pour la configuration pour les reverses DNS.
Pour la zone **front** :
### /etc/bind/zones/db.krhacken.org.intrafront.rev
```
REV
$TTL 10800
@ IN SOA dns.krhacken.org. dnsmaster.krhacken.org. (
2015021102 ; Serial
@ IN SOA dns.krhacken.org. r.krhacken.org. (
2020050101 ; Serial
5400 ; Refresh
2700 ; Retry
2419200 ; Expire
300 ) ; Negative TTL
@ IN NS dns.krhacken.org.
253 IN PTR dns.krhacken.org.
1 IN PTR alpha.fw.krhacken.org.
2 IN PTR beta.fw.krhacken.org.
3 IN PTR vip.fw.krhacken.org.
4 IN PTR alpha.haproxy.krhacken.org.
5 IN PTR beta.haproxy.krhacken.org.
6 IN PTR vip.haproxy.krhacken.org.
7 IN PTR proxyint.krhacken.org.
10 IN PTR mail.krhacken.org.
3 IN PTR alpha.nginx.krhacken.org.
4 IN PTR beta.nginx.krhacken.org.
1 IN PTR alpha.pve.krhacken.org.
2 IN PTR beta.pve.krhacken.org.
3 IN PTR alpha.fw.krhacken.org.
4 IN PTR beta.fw.krhacken.org.
5 IN PTR alpha.haproxy.krhacken.org.
6 IN PTR beta.haproxy.krhacken.org.
7 IN PTR vip.haproxy.krhacken.org.
252 IN PTR proxy.krhacken.org.
254 IN PTR vip.fw.krhacken.org.
```
Pour la zone **proxy** :
### /etc/bind/zones/db.krhacken.org.intraproxy.rev
```
REV
$TTL 10800
@ IN SOA dns.krhacken.org. r.krhacken.org. (
2020050101 ; Serial
5400 ; Refresh
2700 ; Retry
2419200 ; Expire
300 ) ; Negative TTL
@ IN NS dns.krhacken.org.
1 IN PTR alpha.nginx.krhacken.org.
2 IN PTR beta.nginx.krhacken.org.
5 IN PTR mail.krhacken.org.
252 IN PTR alpha.haproxy.krhacken.org.
253 IN PTR beta.haproxy.krhacken.org.
254 IN PTR vip.fw.krhacken.org.
```
Pour la zone **back** :
### /etc/bind/zones/db.krhacken.org.intraback.rev
```
REV
$TTL 10800
@ IN SOA dns.krhacken.org. dnsmaster.krhacken.org. (
2015021102 ; Serial
@ IN SOA dns.krhacken.org. r.krhacken.org. (
2020050101 ; Serial
5400 ; Refresh
2700 ; Retry
2419200 ; Expire
300 ) ; Negative TTL
@ IN NS dns.krhacken.org.
253 IN PTR dns.krhacken.org.
1 IN PTR alpha.haproxy.krhacken.org.
2 IN PTR beta.haproxy.krhacken.org.
1 IN PTR alpha.ldap.krhacken.org.
2 IN PTR beta.ldap.krhacken.org.
3 IN PTR vip.ldap.krhacken.org.
4 IN PTR alpha.nginx.krhacken.org.
5 IN PTR beta.nginx.krhacken.org.
254 IN PTR proxyint.krhacken.org.
4 IN PTR mail.krhacken.org.
5 IN PTR back.mail.krhacken.org.
6 IN PTR ldapui.krhacken.org.
7 IN PTR krhacken.org.
8 IN PTR wiki.krhacken.org.
10 IN PTR cloud.krhacken.org.
11 IN PTR git.krhacken.org.
12 IN PTR keyserver.krhacken.org.
13 IN PTR pass.krhacken.org.
252 IN PTR alpha.fw.krhacken.org.
253 IN PTR beta.fw.krhacken.org.
254 IN PTR vip.fw.krhacken.org.
```
Pour la zone **admin** :
### /etc/bind/zones/db.krhacken.org.intraadmin.rev
```
$TTL 10800
@ IN SOA dns.krhacken.org. r.krhacken.org (
2020050101 ; Serial
5400 ; Refresh
2700 ; Retry
2419200 ; Expire
300 ) ; Negative TTL
@ IN NS dns.krhacken.org.
6 IN PTR master.haproxy.krhacken.org.
7 IN PTR slave.haproxy.krhacken.org.
252 IN PTR proxy.krhacken.org.
3 IN PTR master.nginx.krhacken.org.
4 IN PTR slave.nginx.krhacken.org.
253 IN PTR dns.krhacken.org.
1 IN PTR ldap.krhacken.org.
10 IN PTR mail.krhacken.org.
15 IN PTR ldapui.krhacken.org.
20 IN PTR nextcloud.krhacken.org.
21 IN PTR gitea.krhacken.org.
30 IN PTR rocketchat.krhacken.org.
14 IN PTR drone.krhacken.org.
4 IN PTR ctf.nginx.krhacken.org.
10 IN PTR club.ctfd.krhacken.org.
50 IN PTR ct.snt.krhacken.org.
50 IN PTR blog.krhacken.org.
252 IN PTR grafana.krhacken.org.
253 IN PTR ansible.krhacken.org.
254 IN PTR opn.krhacken.org.
10 IN PTR vm.snt.krhacken.org.
```
Redémarrage de bind9


+ 8
- 8
applicatif/zone_dmz/haproxy/certificat_ssl_client.md View File

@ -5,7 +5,7 @@ Faire les commandes dans `/home/hasync/ssl`
## Création du premier certificat client
### Création du certificat serveur
```
```shell
openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
```
@ -24,7 +24,7 @@ Email Address []:contact@krhacken.org
### Création de la clé et du CSR du client
```
```shell
openssl req -newkey rsa:2048 -nodes -keyout client.key -out client.csr
```
@ -45,7 +45,7 @@ A challenge password []:
An optional company name []:
```
```
```shell
openssl x509 -req -days 3650 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out client.crt
openssl req -newkey rsa:2048 -nodes -keyout haproxy.key -out haproxy.csr
```
@ -69,18 +69,18 @@ A challenge password []:
An optional company name []:
```
```
```shell
openssl x509 -req -days 365 -in haproxy.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out haproxy.crt
```
### Création du certificat pour le navigateur
```
```shell
openssl pkcs12 -export -out haproxy_user.pfx -inkey haproxy.key -in haproxy.crt -certfile ca.crt
```
## Génération d'un second certificat
```
```shell
openssl req -newkey rsa:2048 -nodes -keyout haproxy2.key -out haproxy2.csr
```
### Spécification du certificat Client
@ -103,7 +103,7 @@ An optional company name []:
### Certificat pour le navigateur
```
```shell
openssl x509 -req -days 365 -in haproxy2.csr -CA ca.crt -CAkey ca.key -set_serial 03 -out haproxy2.crt
openssl pkcs12 -export -out haproxy_user2.pfx -inkey haproxy2.key -in haproxy2.crt -certfile ca.crt
```
@ -112,7 +112,7 @@ Il faut maintenant que vous ajoutiez ce certificat à vos certificats Firefox
### Copie des certificats
On copie le certificat pour HAProxy
```
```shell
cp ca.crt /home/hasync/pve.crt
scp ca.crt root@10.0.0.7:/home/hasync/pve.crt
```


+ 30
- 33
applicatif/zone_dmz/haproxy/haproxy.md View File

@ -6,22 +6,19 @@ Cela consiste en la gestion des flux post firewall.
Deux conteneurs Debian 10 identiques, un sur Alpha l'autre sur Bêta avec deux interfaces :
Numéro 102 (Alpha)
#### Trois interfaces
- eth0 : vmbr1 / VLAN 10 / IP 10.0.0.6 / GW 10.0.0.254
- eth1 : vmbr1 / VLAN 20 / IP 10.0.1.1 / GW 10.0.1.254
- eth2 : vmbr2 / VLAN 100 / IP 10.1.0.102 / GW 10.1.0.254
#### Interface réseau
- eth0 : vmbr1 / VLAN 10 / IP 10.0.0.5 / GW 10.0.0.254
Numéro 103 (Beta)
#### Trois interfaces
- eth0 : vmbr1 / VLAN 10 / IP 10.0.0.7 / GW 10.0.0.254
- eth1 : vmbr1 / VLAN 20 / IP 10.0.1.2 / GW 10.0.1.254
- eth2 : vmbr2 / VLAN 100 / IP 10.1.0.103 / GW 10.1.0.254
#### Interface réseau
- eth0 : vmbr1 / VLAN 10 / IP 10.0.0.6 / GW 10.0.0.254
### Le proxy
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.2.252:9999";
Proxy "http://10.0.0.252:9999";
};
```
@ -50,8 +47,8 @@ Voici les choix techniques faits afin de répondre à ces objectifs :
Afin de pouvoir faire des scp de manière automatique entre les deux conteneurs, il faut mettre en place une connexion ssh par clé en root entre les deux conteneurs.
Le procédé est le même, en voici les variantes :
- Sur Alpha le conteneur HAProxy aura comme IP 10.0.0.6
- Sur Beta le conteneur HAProxy aura comme IP 10.0.0.7
- Sur Alpha le conteneur HAProxy aura comme IP 10.0.0.5
- Sur Beta le conteneur HAProxy aura comme IP 10.0.0.6
### /etc/ssh/sshd_config
Remplacer la ligne concernée par
@ -68,9 +65,9 @@ Utilisateur crée par le playbook Ansible
adduser hasync
ssh-keygen -o -a 100 -t ed25519 -f /root/.ssh/id_ed25519
Alpha : ssh-copy-id -i /root/.ssh/id_ed25519 root@10.0.0.7
Alpha : ssh-copy-id -i /root/.ssh/id_ed25519 root@10.0.0.6
Beta : ssh-copy-id -i /root/.ssh/id_ed25519 root@10.0.0.6
Beta : ssh-copy-id -i /root/.ssh/id_ed25519 root@10.0.0.5
```
### /etc/ssh/sshd_config
@ -88,18 +85,18 @@ Il est maintenant possible de se connecter par clé entre les conteneurs
## Installation et configuration de HAProxy sur chaque node
Le procédé est le même, en voici les variantes :
- Sur Alpha le conteneur HAProxy aura comme IP 10.0.0.6
- Sur Beta le conteneur HAProxy aura comme IP 10.0.0.7
- Sur Alpha le conteneur HAProxy aura comme IP 10.0.0.5
- Sur Beta le conteneur HAProxy aura comme IP 10.0.0.6
### Installation
Faite par le playbook Ansible
```
```shell
apt-get update
apt-get install -y haproxy hatop certbot nginx psmisc
systemctl enable haproxy
systemctl enable nginx
```
```
```shell
rm /etc/nginx/sites-enabled/default
rm /etc/nginx/sites-available/default
rm /etc/letsencrypt/live/README
@ -255,21 +252,21 @@ server {
ln -s /etc/nginx/sites-available/letsencrypt.conf /etc/nginx/sites-enabled/
```
### Démarrage des services
```
```shell
systemctl restart nginx.service
systemctl restart haproxy.service
```
## Mise en place de la haute disponibilité du load balanceur
Voilà la configuration que nous allons mettre en place :
- Sur Alpha le conteneur HAProxy aura comme IP 10.0.0.6
- Sur Beta le conteneur HAProxy aura comme IP 10.0.0.7
- L'IP virtuelle 10.0.0.8 sera attribuée en fonction de la disponibilité des load balanceur
- Sur Alpha le conteneur HAProxy aura comme IP 10.0.0.5
- Sur Beta le conteneur HAProxy aura comme IP 10.0.0.6
- L'IP virtuelle 10.0.0.7 sera attribuée en fonction de la disponibilité des load balanceur
- La node Alpha sera le master et la node Beta sera le Slave
### Installation (commune au deux nodes)
Faites par le playbook Ansible.
```
```shell
apt-get install -y keepalived
systemctl enable keepalived.service
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
@ -293,7 +290,7 @@ vrrp_instance VI_1 {
virtual_router_id 51
priority 101 # 101 on master, 100 on backup
virtual_ipaddress {
10.0.0.8 # the virtual IP
10.0.0.7 # the virtual IP
}
track_script {
chk_haproxy
@ -320,7 +317,7 @@ vrrp_instance VI_1 {
virtual_router_id 51
priority 100 # 101 on master, 100 on backup
virtual_ipaddress {
10.0.0.8 # the virtual IP
10.0.0.7 # the virtual IP
}
track_script {
chk_haproxy
@ -332,7 +329,7 @@ systemctl restart keepalived
```
#### Vérification
Le retour de cette commande doit montrer l'adresse IP 10.0.0.8 sur Alpha
Le retour de cette commande doit montrer l'adresse IP 10.0.0.7 sur Alpha
```
ip a | grep -e inet.*eth0
```
@ -346,17 +343,17 @@ certbot certonly --webroot -w /home/hasync/letsencrypt-requests/ -d sub.krhacken
```
Voici un script pour mettre en place les certificats Let's Encrypt au bon endroit qui s'occupe de propager les certificats sur l'autre conteneur (depuis Alpha vers Beta). Disponible dans `/root/install-certs.sh` si créer avec Ansible.
```
```bash
#!/bin/bash
if [ "$(ip a | grep -c "10.0.0.8")" -ge 1 ]; then
if [ "$(ip a | grep -c "10.0.0.7")" -ge 1 ]; then
ct_ip=$(ip -o -4 addr list eth0 | awk '{print $4}' | cut -d/ -f1 | head -n 1 | tail -c2)
if [ $ct_ip = 6 ]
then
other_ip=10.0.0.7
other_ip=10.0.0.6
fi
if [ $ct_ip = 7 ]
then
other_ip=10.0.0.6
other_ip=10.0.0.5
fi
rm -f /etc/letsencrypt/live/README
rm -rf /etc/ssl/letsencrypt/*
@ -375,17 +372,17 @@ Pour une question de simplicité d'administration, les certificats Let's Encrypt
### /home/hasync/renew.sh
Voilà un script d'automatisation à mettre sur les deux conteneurs. Déjà présent si installer avec Ansible.
```
```bash
#!/bin/bash
if [ "$(ip a | grep -c "10.0.0.8")" -ge 1 ]; then
if [ "$(ip a | grep -c "10.0.0.7")" -ge 1 ]; then
ct_ip=$(ip -o -4 addr list eth0 | awk '{print $4}' | cut -d/ -f1 | head -n 1 | tail -c2)
if [ $ct_ip = 6 ]
then
other_ip=10.0.0.7
other_ip=10.0.0.6
fi
if [ $ct_ip = 7 ]
then
other_ip=10.0.0.6
other_ip=10.0.0.5
fi
certbot renew
rm -rf /etc/ssl/letsencrypt/*


+ 20
- 25
applicatif/zone_dmz/proxy_interne.md View File

@ -13,16 +13,11 @@ Au niveau des ressources allouées :
- 1 Coeur
- 1Gb de RAM
- 1Gb de SWAP
- 24Gb de Stockage
- 16Gb de Stockage
Au niveau des interfaces réseaux :
Firewall toujours désactiver.
Interface réseau :
- eth0: vmbr1 / VLAN: 10 / IP: 10.0.0.252/24 / GW: 10.0.0.254
- eth1: vmbr1 / VLAN: 20 / IP: 10.0.1.252/24
- eth2: vmbr1 / VLAN: 30 / IP: 10.0.2.252/24
- eth3: vmbr1 / VLAN: 40 / IP: 10.0.3.252/24
- eth4: vmbr1 / VLAN: 50 / IP: 10.0.4.252/24
- eth5: vmbr2 / VLAN: 100 / IP: 10.1.0.104/24 / GW: 10.1.0.254
Dans les options activé le démarrage automatique.
@ -41,7 +36,7 @@ Allow HTTP tunnel throutgt Apt-Cacher NG? -> No
### /etc/apt-cacher-ng/acng.conf
```
Port: 9999
BindAddress: 10.0.1.252 10.0.2.252 10.0.3.252 10.0.4.252 10.1.0.104
BindAddress: 10.0.0.252
PassThroughPattern: ^(.*):443$
```
```
@ -68,11 +63,8 @@ apt-get install -y squid3 ca-certificates
#acl localnet src 192.168.0.0/16 # RFC 1918 local private network (LAN)
#acl localnet src fc00::/7 # RFC 4193 local private network range
#acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
acl localnet src 10.0.1.0/24 # Zone Proxy
acl localnet src 10.0.2.0/24 # Zone Int
acl localnet src 10.0.3.0/24 # Zone CTF
acl localnet src 10.0.4.0/24 # Zone Dirty
acl localnet src 10.1.0.0/24 # Zone Admin
acl localnet src 10.0.0.0/8 # L'ensemble des zones
[...]
@ -90,20 +82,15 @@ Squid est maintenant accessible depuis le port 3128 du proxy interne uniquement
Les outils principaux sont WGET et APT-GET on va donc les reliées au Proxy Interne.
Le proxy interne sera accessible uniquement depuis les zones PROXY, INT, CTF et DIRTY voilà l'ip du proxy en fonction de la zone :
- PROXY (VLAN 20) -> 10.0.1.252
- INT (VLAN 30) -> 10.0.2.252
- CTF (VLAN 40) -> 10.0.3.252
- DIRTY (VLAN 50) -> 10.0.4.252
- ADMIN (VLAN 100) -> 10.1.0.104
Le proxy interne sera accessible depuis toutes les zones à l'adresse 10.0.0.252.
### WGET
Les requêtes passerons désormais par le proxy interne sur le port 3128 pour les requêtes http et https. Seul le root aura accès au proxy.
#### /root/.wgetrc
```
http_proxy = http://<ip_proxy_zone>:3128/
https_proxy = http://<ip_proxy_zone>:3128/
http_proxy = http://10.0.0.252:3128/
https_proxy = http://10.0.0.252:3128/
use_proxy = on
```
WGET doit maintenant fonctionner.
@ -114,7 +101,7 @@ On va maintenant faire passer apt-get par le proxy apt qui est sur le port 9999
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://<ip_proxy_zone>:9999";
Proxy "http://10.0.0.252:9999";
};
```
APT-GET doit maintenant fonctionner.
@ -127,7 +114,15 @@ Les requêtes passerons désormais par le proxy interne sur le port 3128 pour le
#### /root/.gitconfig
```
[http]
proxy = http://<ip_proxy_zone>:3128
proxy = http://10.0.0.252:3128
[https]
proxy = https://<ip_proxy_zone>:3128
proxy = https://10.0.0.252:3128
```
### Toutes requêtes HTTP
Pour faire passer toute les requêtes HTTP par le proxy exécuter les commandes suivantes.
```
export http_proxy=http://10.0.0.252:3128
export https_proxy=$http_proxy
```

+ 1
- 2
applicatif/zone_interne/README.md View File

@ -4,9 +4,8 @@ Vous trouverez ici toute la documentation relative au fonctionnement et à la co
Cela comprend tous les conteneurs des services sensibles permanents (Nextcloud, Gitea...) et les services internes nécessaires au fonctionnement des services sensibles comme l'annuaire LDAP.
## Réseau
Les services de la zone INT devront avoir les interfaces réseau suivantes :
Les services de la zone INT devront avoir l'interface réseau suivante :
- Bridge Interne VLAN 30 (INT)
- Bridge Admin VLAN 100 (ADMIN)
# Table des matières
1. [LDAP](ldap)


+ 4
- 5
applicatif/zone_interne/gitea.md View File

@ -2,23 +2,22 @@
## Le conteneur
Numéro 121 (Beta)
#### Deux interfaces
#### Interface réseau
- eth0 : vmbr1 / VLAN 30 / IP 10.0.2.21 / GW 10.0.2.254
- eth1 : vmbr2 / VLAN 100 / IP 10.1.0.121 / GW 10.1.0.254
### Le proxy
#### /root/.wgetrc
```
http_proxy = http://10.0.2.252:3128/
https_proxy = http://10.0.2.252:3128/
http_proxy = http://10.0.0.252:3128/
https_proxy = http://10.0.0.252:3128/
use_proxy = on
```
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.2.252:9999";
Proxy "http://10.0.0.252:9999";
};
```


+ 9
- 10
applicatif/zone_interne/ldap/interface_web_ldap.md View File

@ -8,31 +8,30 @@ Cette interface permet aussi aux utilisateurs non admin de changer de mot de pas
## Le conteneur
Numéro 115 (Beta)
#### Deux interfaces
#### Interface réseau
- eth0 : vmbr1 / VLAN 30 / IP 10.0.2.15 / GW 10.0.2.254
- eth1 : vmbr2 / VLAN 100 / IP 10.1.0.115 / GW 10.1.0.254
### Le proxy
#### /root/.gitconfig
```
[http]
proxy = http://10.0.2.252:3128
proxy = http://10.0.0.252:3128
[https]
proxy = https://10.0.2.252:3128
proxy = https://10.0.0.252:3128
```
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.2.252:9999";
Proxy "http://10.0.0.252:9999";
};
```
Il vous faut mettre en place le certificat SSL pour LDAP. La démarche et la même que dans la partie LDAP.
## Installation
```
```shell
git clone https://github.com/kakwa/ldapcherry
cd ldapcherry
apt-get install python-ldap python-pip
@ -229,7 +228,7 @@ tools.staticdir.dir = '/usr/share/ldapcherry/static/'
```
### /etc/ldapcherry/roles.yml
```
```yml
admin:
display_name: AdminSys
description: Administrateur total de l'annuaire LDAP
@ -288,10 +287,10 @@ sh ~/deploy-webhost.sh ldapui
### Dans le conteneur HAProxy
Obtention du certificat
```
```bash
certbot certonly --webroot -w /home/hasync/letsencrypt-requests/ -d ldapui.krhacken.org
```
```
```shell
sh ~/install-certs.sh
```
@ -309,7 +308,7 @@ ExecStop=kill -9 `cat /etc/ldapcherry/proc.pid`
[Install]
WantedBy=multi-user.target
```
```
```shell
systemctl enable ldapui.service
systemctl start ldapui.service
```


+ 2
- 3
applicatif/zone_interne/ldap/serveur_ldap.md View File

@ -6,15 +6,14 @@ Pour la sécurisation de LDAP nous allons utiliser LDAP avec StartTLS.
## Le conteneur
Numéro 108 (Alpha)
#### Deux interfaces
#### Interface réseau
- eth0 : vmbr1 / VLAN 30 / IP 10.0.2.1 / GW 10.0.2.254
- eth1 : vmbr2 / VLAN 100 / IP 10.1.0.108 / GW 10.1.0.254
### Le proxy
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.2.252:9999";
Proxy "http://10.0.0.252:9999";
};
```


+ 2
- 3
applicatif/zone_interne/mail.md View File

@ -5,15 +5,14 @@ Il faut avoir établie une connexion TLS avec le serveur LDAP, la marche à suiv
## Le conteneur
Numéro 111 (Alpha)
#### Deux interfaces
#### Interface réseau
- eth0 : vmbr1 / VLAN 30 / IP 10.0.2.11 / GW 10.0.2.254
- eth1 : vmbr2 / VLAN 100 / IP 10.1.0.111 / GW 10.1.0.254
### Le proxy
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.2.252:9999";
Proxy "http://10.0.0.252:9999";
};
```


+ 4
- 5
applicatif/zone_interne/nextcloud.md View File

@ -4,23 +4,22 @@ Mise en place du conteneur pour NextCloud et intégration à l'annuaire LDAP.
## Le conteneur
Numéro 120 (Beta)
#### Deux interfaces
#### Interface réseau
- eth0 : vmbr1 / VLAN 30 / IP 10.0.2.20 / GW 10.0.2.254
- eth1 : vmbr2 / VLAN 100 / IP 10.1.0.120 / GW 10.1.0.254
### Le proxy
#### /root/.wgetrc
```
http_proxy = http://10.0.2.252:3128/
https_proxy = http://10.0.2.252:3128/
http_proxy = http://10.0.0.252:3128/
https_proxy = http://10.0.0.252:3128/
use_proxy = on
```
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.2.252:9999";
Proxy "http://10.0.0.252:9999";
};
```


+ 3
- 4
applicatif/zone_interne/rocket_chat.md View File

@ -6,15 +6,15 @@ Sur un container dédié (CT113)
### /root/.wgetrc
```
http_proxy = http://10.0.2.252:3128/
https_proxy = http://10.0.2.252:3128/
http_proxy = http://10.0.0.252:3128/
https_proxy = http://10.0.0.252:3128/
use_proxy = on
```
### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.2.252:9999";
Proxy "http://10.0.0.252:9999";
};
```
@ -233,4 +233,3 @@ C'est tout pour l'instant.
TDL
- Solutions de Visio WebRC ou Jitsi
- Link Mail
- Enlever les messages de restrictions (New user registration is currently disabled...)

+ 2
- 3
applicatif/zone_proxy/README.md View File

@ -4,10 +4,9 @@ Vous trouverez ici toute la documentation relative au fonctionnement et à la co
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 suivantes :
Les services de la zone PROXY devront avoir l'interface 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)


+ 3
- 7
applicatif/zone_proxy/nginx_principal.md View File

@ -4,22 +4,18 @@
Ce service est redondé car vital, il n'a pas d'IP virtuelle.
Numéro 105 (Alpha)
#### Trois interfaces
#### Interface réseau
- eth0 : vmbr1 / VLAN 20 / IP 10.0.1.3 / GW 10.0.1.254
- eth1 : vmbr1 / VLAN 30 / IP 10.0.2.4 / GW 10.0.2.254
- eth2 : vmbr2 / VLAN 100 / IP 10.1.0.105 / GW 10.1.0.254
Numéro 106 (Beta)
#### Trois interfaces
#### Interface réseau
- eth0 : vmbr1 / VLAN 20 / IP 10.0.1.4 / GW 10.0.1.254
- eth1 : vmbr1 / VLAN 30 / IP 10.0.2.5 / GW 10.0.2.254
- eth2 : vmbr2 / VLAN 100 / IP 10.1.0.106 / GW 10.1.0.254
### Le proxy
#### /etc/apt/apt.conf.d/01proxy
```
Acquire::http {
Proxy "http://10.0.2.252:9999";
Proxy "http://10.0.0.252:9999";
};
```


+ 1
- 5
applicatif/zone_wan/README.md View File

@ -5,12 +5,8 @@ Cela comprend les pare-feu et les hyperviseurs. C'est cette zone qui aura un acc
## Réseau
Les services DMZ devront avoir les interfaces réseau suivante
Les services DMZ devront avoir l'interface réseau suivante
- Bridge WAN VLAN 10 (WAN)
- Bridge Admin VLAN 100 (ADMIN)
Pour OPNSense
- Bridge Interne VLAN 10 (DMZ)
# Table des matières
1. [OPNSense](opnsense)


+ 5
- 5
applicatif/zone_wan/opnsense/configuration_initiale.md View File

@ -1,6 +1,6 @@
# Pare-Feu OPNSense
Au niveau du pare-feu nous allons utiliser OPNSense (fork de pfSense). Alpha et Sigma auront une VM avec OPNSense pour la Haute Disponibilité, l'IP publique (WAN) se déplacera entre les trois VM grâce à une IP virtuelle CARP et à pfSync. Ca sera la même chose pour la gateway sur chaque interface.
Au niveau du pare-feu nous allons utiliser OPNSense (fork de pfSense). Alpha et Beta auront une VM avec OPNSense pour la Haute Disponibilité, l'IP publique (WAN) se déplacera entre les trois VM grâce à une IP virtuelle CARP et à pfSync. Ca sera la même chose pour la gateway sur chaque interface.
Dans options activé le démarrage automatique.
@ -45,12 +45,12 @@ On ajoutera le reste plus tard.
Il faut maintenant configurer les adresses IP des interfaces :
- WAN, mettre l'IP (dépend du choix fait) et la gateway donnée. Pas de DHCP ni d'ipv6.
- LAN, dépend de la node
- Alpha : 10.0.0.4
- Sigma : 10.0.0.6
- Alpha : 10.0.0.3
- Beta : 10.0.0.4
- pfSync, dépend de la node
- Alpha : 10.1.2.1
- Gamma : 10.1.2.2
- Beta : 10.1.2.2
### Accès au panel d'administration
@ -115,7 +115,7 @@ Système / Haute disponibilité / Paramètres
- Identifiant du Système Distant `root` (pour l'instant)
- Tout cocher et sauvegarder
### Sigma
### Beta
Système / Haute disponibilité / Paramètres


+ 2
- 0
deploiement/README.md View File

@ -1,5 +1,7 @@
# Aide au déploiement
Cette partie est fausse, pour le moment.
Vous trouverez ici toute la documentation relative au déploiement via Ansible ainsi que des notes et des conseils issue des précédents déploiement.
# Table des matières


+ 0
- 8
deploiement/sources/hosts View File

@ -26,14 +26,6 @@ nginx
# Zone Interne
[ldap]
10.1.0.107 #LDAP Master
[zoneinterne:children]
ldap
# Zone Interne
[ldap]
10.1.0.108 #LDAPMaster


+ 3
- 3
presentation_projet.md View File

@ -2,14 +2,14 @@
### Infrastructure matérielle
Du côté infrastructure, nous disposons de deux rack 1U avec deux PC à l'intérieur possédant chacun 24Go de DDR3-ECC et un Xeon x5670 6 Coeurs cadencé à 2.93 GHz. Côté stockage, nous allons mettre en place un RAID1 ZFS avec deux disques par PC (les données du premier disque seront aussi présentes sur le second) ainsi le stockage sera répliqué pour éviter toute perte de données.
Du côté infrastructure, nous disposons d'un rack 1U avec deux PC à l'intérieur possédant chacun 24Go de DDR3-ECC et un Xeon x5670 6 Coeurs cadencé à 2.93 GHz. Côté stockage, nous allons mettre en place un RAID1 ZFS avec deux disques par PC (les données du premier disque seront aussi présentes sur le second) ainsi le stockage sera répliqué pour éviter toute perte de données.
Les 4 nodes du serveur, que nous appellerons Alpha, Beta, Gamma et Sigma, auront Proxmox comme hyperviseur et les trois premières d'entre elles seront en cluster grâce à Proxmox.
Les 2 nodes du serveur, que nous appellerons Alpha et Beta auront Proxmox comme hyperviseur et seront en cluster grâce à Proxmox.
### Infrastructure logicielle
#### Infrastructure réseau du serveur
Les conteneurs/VMs sensibles seront répliqués entre les trois nodes de production
Les conteneurs/VMs sensibles seront répliqués.
L'infrastructure réseau du club s'articulerait de la manière suivante (sur chaque node) :
- Un bloc pare-feu / routeur (OPNSense).


+ 3
- 20
proxmox/creation_cluster.md View File

@ -1,15 +1,13 @@
# Mise en place du cluster entre nos nodes
Il faut avoir mis en place le réseau avant de mettre les nodes en cluster.
Un lien externalisé entre les quatres nodes est déjà en place grâce à un Int Port sur le VLAN 30 du switch administration.
Un lien externalisé entre les deux nodes est déjà en place grâce à un Int Port sur le VLAN 30 du switch administration.
Nous n'allons utilisé que trois de ces nodes en production, la quatrième nodes ne feras donc pas parti du cluster.
Les nodes seront accessibles grâce au DNS interne via :
- alpha.krhacken.org -> 10.0.5.1
- beta.krhacken.org -> 10.0.5.2
- gamma.krhacken.org -> 10.0.5.3
- delta.krhacken.org -> 10.0.5.4
Le cluster de production s'appellera Sigma et regroupera Alpha, Beta et Gamma.
@ -24,7 +22,6 @@ X.X.X.X alpha.krhacken.org alpha pvelocalhost
#Corosync (pas toucher)
10.0.5.1 alpha-corosync.krhacken.org alpha-corosync
10.0.5.2 beta-corosync.krhacken.org beta-corosync
10.0.5.3 gamma-corosync.krhacken.org gamma-corosync
```
##### Sur Beta
@ -34,31 +31,17 @@ Y.Y.Y.Y beta.krhacken.org beta pvelocalhost
#Corosync (pas toucher)
10.0.5.1 alpha-corosync.krhacken.org alpha-corosync
10.0.5.2 beta-corosync.krhacken.org beta-corosync
10.0.5.3 gamma-corosync.krhacken.org gamma-corosync
```
##### Sur Gamma
```
127.0.0.1 localhost.localdomain localhost
Z.Z.Z.Z gamma.krhacken.org gamma pvelocalhost
#Corosync (pas toucher)
10.0.5.1 alpha-corosync.krhacken.org alpha-corosync
10.0.5.2 beta-corosync.krhacken.org beta-corosync
10.0.5.3 gamma-corosync.krhacken.org gamma-corosync
```
Alpha, Beta et Gamma sont désormais accessibles via des Hostnames.
Alpha et Beta sont désormais accessibles via des Hostnames.
### Création du cluster
Nous allons maintenant créer le cluster Sigma depuis Alpha,
```
pvecm create sigma --link0 alpha-corosync
```
On ajoute Beta au cluster Sigma directement depuis Beta,
Puis on ajoute Beta au cluster Sigma directement depuis Beta,
```
pvecm add alpha-corosync --link0 beta-corosync
```
Puis on ajoute Gamma au cluster Sigma directement depuis Beta
```
pvecm add alpha-corosync --link0 gamma-corosync
```
Notre cluster Gamma est maintenant créé et Corosync utilise la VLAN 30 du switch administration pour communiquer.

+ 10
- 10
proxmox/haute_disponibilite.md View File

@ -16,30 +16,30 @@ Les services redondés et utilisant keepalived seront :
- HAProxy : un conteneur sur chaque node, celui de Alpha sera Master,
- NGINX : un conteneur sur chaque node load-balancing par HAProxy,
- LDAP : un conteneur sur chaque node, réplication des données grâce à slapd et accessibilité / loadbalancing via Keepalived,
- Redis : un conteneur sur Alpha, un sur Sigma,
- Service Mail : un conteneur sur Alpha, un sur Sigma,
- DNS : un conteneur sur Alpha un sur Sigma.
- Redis : un conteneur sur Alpha, un sur Beta,
- Service Mail : un conteneur sur Alpha,
- DNS : un conteneur sur Alpha
## Répartition non exhaustive des conteneurs entre les nodes
En réflexion
- OPNSense -> Alpha et Sigma
- HAProxy -> Alpha, Beta et Sigma
- NGINX -> Alpha, Beta et Sigma
- Redis -> Alpha et Sigma
- LDAP -> Alpha et Sigma
- OPNSense -> Alpha et Beta
- HAProxy -> Alpha et Beta
- NGINX -> Alpha et Beta
- Redis -> Alpha et Beta
- LDAP -> Alpha et Beta
- Git -> Alpha
- Mattermost -> Alpha
- NextCloud -> Beta
- Mail -> Alpha et Sigma
- Mail -> Alpha
- CTF -> Beta (3 services)
- LDAPUI -> Alpha
- DNS -> Beta
- Proxy interne -> Beta
- Ansible -> Alpha
- Site Web KRKN -> Sigma
- Site Web KRKN -> Alpha
- Wiki KRKN -> Beta
- Etat des services -> Alpha


+ 3
- 9
proxmox/installation_hyperviseurs.md View File

@ -1,8 +1,8 @@
# Installation des hyperviseurs
Proxmox étant un hyperviseur de type 1, nous allons l'installer sur les quatres nodes du serveur.
Proxmox étant un hyperviseur de type 1, nous allons l'installer sur les deux nodes du serveur.
Pour cette installation, nous partons du principe que les quatres nodes ont accès à internet soit via une IP publique soit via un réseau privé. Cela ne change rien car nous modifierons la configuration réseau par la suite.
Pour cette installation, nous partons du principe que les deux nodes ont accès à internet soit via une IP publique soit via un réseau privé. Cela ne change rien car nous modifierons la configuration réseau par la suite.
Pour l'installation il faut :
- Une clé USB,
@ -53,14 +53,8 @@ Vérifier la cohérence et lancer l'installation.
### Sur la deuxième node (Beta)
Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **beta.krhacken.org**
### Sur la troisième node (Gamma)
Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **gamma.krhacken.org**
### Sur la quatrième node (Delta)
Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **delta.krhacken.org**
## Préparation des hyperviseurs
La procédure est la même sur les quatres nodes. Elle peut être faite via SSH (recommandé) ou sur l'interface d'administration **https://IP:8006**
La procédure est la même sur les deux nodes. Elle peut être faite via SSH (recommandé) ou sur l'interface d'administration **https://IP:8006**
### Mise à jour


+ 1
- 1
proxmox/introduction_a_la_virtualisation.md View File

@ -4,7 +4,7 @@ Proxmox est un hyperviseur de type 1 (bare metal). C’est une plateforme de vir
Contrairement à un hyperviseur de type 2 (VirtualBox par exemple), Proxmox ne s'exécute pas dans un autre OS mais dispose de son propre OS (basé sur Debian) adapté à la virtualisation.
Donc, Proxmox permet la virtualisation de plusieurs machines au sein d’un seul serveur. Proxmox nous permettra aussi des mettre les quatres nodes du serveur en cluster permettant entre autre de migrer des contenants d'une node à l'autre en cas de chute de l'une d'elles grâce aux fonctions de Haute Disponibilité de Proxmox.
Donc, Proxmox permet la virtualisation de plusieurs machines au sein d’un seul serveur. Proxmox nous permettra aussi des mettre les deux nodes du serveur en cluster permettant entre autre de migrer des contenants d'une node à l'autre en cas de chute de l'une d'elles grâce aux fonctions de Haute Disponibilité de Proxmox.
## Technologie de virtualisation


+ 1
- 1
proxmox/securisation/systeme_authentification_base.md View File

@ -41,7 +41,7 @@ Seulement les comptes adminsys auront un accès SSH.
#### Ajout du compte *coimbrap*
Via le shell :
```
```shell
useradd coimbrap
usermod -a -G adminsys coimbrap
usermod -a -G sudo coimbrap


+ 24
- 72
proxmox/securisation/template_ferm.md View File

@ -9,75 +9,54 @@ Nous présentons ici une template pour la sécurisation des conteneurs avec ferm
Tout les conteneurs et toutes les VM auront un firewall dédié (ferm) qui filtrera en INPUT / OUTPUT et bloquera tout en FORWARDING
Voici comment le filtrage ce fera en INPUT :
- Tout autoriser sur l'interface admin.
- Autoriser que ce qui est nécessaire sur l'interface principale.
- Autoriser que ce qui est nécessaire sur les interfaces secondaires avec la possibilité de rien ouvrir.
- Option port UDP dans les deux cas.
- Option pour autorisé le protocole VRRP.
- Option port UDP pour le DNS.
Voici comment le filtrage ce fera en OUTPUT :
- Tout bloquer, sauf les connexions établies, sur l'interface admin.
- Autoriser que ce qui est nécessaire sur l'interface principale.
- Autoriser que ce qui est nécessaire sur les interfaces secondaires avec la possibilité de rien ouvrir.
- Option port UDP dans les deux cas.
- Autoriser que ce qui est nécessaire et les connexions établies sur l'interface principale.
- Option port UDP pour le DNS.
La template utilise des paramètres pour éviter d'avoir à modifier la configuration. Il vous suffit d'adapter les paramètres suivant en fonction de la configuration souhaité.
#### Interfaces
- IF_ADMIN : Nom de l'interface d'administration
- IF_FRONT : Nom du point d'entrée principal sur le conteneur
- IF_BACK : Liste des interfaces secondaire, ne doit inclure ni l'interface administration ni les interfaces qui n'ont pas besoin de règles autre que DROP.
- IF_VRRP : Nom de l'interface ayant besoin d'utiliser le protocole VRRP, mettre NEED_VRRP à 1 si besoin de VRRP.
#### Ports TCP ouverts
- HAVE_BACK_ACCESS : Doit accéder à des conteneurs qui sont sur des interfaces secondaires
- HAVE_BACK_REQUEST : Doit être accessible depuis des conteneurs qui sont sur des interfaces secondaires
- OPEN_PORT_FRONT : Liste des ports TCP à ouvrir en entrée sur l'interface principale
- OPEN_PORT_BACK_REQUEST : Liste des ports TCP à ouvrir en entrée sur les interfaces secondaires
- OPEN_PORT_BACK_ACCESS : Liste des ports TCP à ouvrir en sortie sur les interfaces secondaires
- HAVE_FRONT_ACCESS : Doit accéder à des conteneurs qui sont sur l'interface principale
- HAVE_FRONT_REQUEST : Doit être accessible depuis des conteneurs qui sont sur l'interface principale
- OPEN_PORT_FRONT_REQUEST : Liste des ports TCP à ouvrir en entrée sur l'interface principale
- OPEN_PORT_FRONT_ACCESS : Liste des ports TCP à ouvrir en sortie sur l'interface principale
#### Ports UDP ouverts
- NEED_UDP_* : 0 si pas besoin d'ouvrir un port UDP 1 sinon
- UDP_OPEN_PORT_FRONT : Liste des ports UDP à ouvrir en entrée sur l'interface principale
- UDP_OPEN_PORT_BACK_ACCESS : Liste des ports UDP à ouvrir en sortie sur les interfaces secondaires
- UDP_OPEN_PORT_BACK_REQUEST : Liste des ports UDP à ouvrir en entrée sur les interfaces secondaires
- NEED_UDP_FRONT_ACCESS : 0 si pas besoin d'ouvrir un port UDP en sortie 1 sinon
- NEED_UDP_FRONT_REQUEST : 0 si pas besoin d'ouvrir un port UDP en entrée 1 sinon
- UDP_OPEN_PORT_FRONT_ACCESS : Liste des ports UDP à ouvrir en sortie sur l'interface principale
- UDP_OPEN_PORT_FRONT_REQUEST : Liste des ports UDP à ouvrir en entrée sur l'interface principale
Les règles restrictives en sortie permettent d'éviter qu'un attaquant puisse accéder à tout le rester du réseau.
Les règles restrictives en sortie permettent d'éviter qu'un attaquant puisse accéder à tout le reste du réseau.
```
@def $IF_ADMIN = ;
@def $IF_FRONT = ;
@def $IF_BACK = ();
@def $IF_FRONT = eth0;
# REQUEST : EXT -> INT | ACCESS : INT -> EXT
# Depuis l'extérieur sur l'interface principale
@def $HAVE_FRONT_REQUEST = 1; #0 pour NON 1 pour OUI
@def $OPEN_PORT_FRONT_REQUEST = ();
@def $OPEN_PORT_FRONT_REQUEST = (80 3128 9999); #Par défaut 80/3128/9999
@def $NEED_UDP_FRONT_REQUEST = 0; #0 pour NON 1 pour OUI
@def $UDP_OPEN_PORT_FRONT_REQUEST = ();
# Depuis l'intérieur sur l'interface principale
@def $HAVE_FRONT_ACCESS = 1; #0 pour NON 1 pour OUI
@def $OPEN_PORT_FRONT_ACCESS = ();
@def $NEED_UDP_FRONT_ACCESS = 0; #0 pour NON 1 pour OUI
@def $UDP_OPEN_PORT_FRONT_ACCESS = ();
@def $OPEN_PORT_FRONT_ACCESS = (53); #Par défaut 53
@def $NEED_UDP_FRONT_ACCESS = 1; #0 pour NON 1 pour OUI
@def $UDP_OPEN_PORT_FRONT_ACCESS = (53); #Par défaut 53
# Depuis l'extérieur sur les interfaces secondaires
@def $HAVE_BACK_REQUEST = 0; #0 pour NON 1 pour OUI
@def $OPEN_PORT_BACK_REQUEST = ();
@def $NEED_UDP_BACK_REQUEST = 0; #0 pour NON 1 pour OUI
@def $UDP_OPEN_PORT_BACK_REQUEST = ();
# Depuis l'intérieur sur les interfaces secondaires
@def $HAVE_BACK_ACCESS = 1; #0 pour NON 1 pour OUI
@def $OPEN_PORT_BACK_ACCESS = (53);
@def $NEED_UDP_BACK_ACCESS = 1; #0 pour NON 1 pour OUI
@def $UDP_OPEN_PORT_BACK_ACCESS = (53);
# Besoin de VRRP sur IF_VRRP
# Besoin de VRRP
@def $NEED_VRRP = 0; #0 pour NON 1 pour OUI
@def $IF_VRRP = eth0;
table filter {
chain INPUT {
@ -85,62 +64,35 @@ table filter {
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
interface lo ACCEPT;
interface $IF_ADMIN ACCEPT;
@if $HAVE_FRONT_REQUEST {
interface $IF_FRONT proto tcp dport $OPEN_PORT_FRONT_REQUEST ACCEPT;
}
@if $NEED_VRRP {
interface $IF_VRRP proto vrrp ACCEPT;
interface $IF_FRONT proto vrrp ACCEPT;
}
@if $NEED_UDP_FRONT_REQUEST {
interface $IF_FRONT proto udp dport $UDP_OPEN_PORT_FRONT_REQUEST ACCEPT;
}
@if $HAVE_BACK_REQUEST {
interface $IF_BACK proto tcp dport $OPEN_PORT_BACK_REQUEST ACCEPT;
}
@if $NEED_UDP_BACK_REQUEST {
interface $IF_BACK proto udp dport $UDP_OPEN_PORT_BACK_REQUEST ACCEPT;
}
proto icmp icmp-type echo-request ACCEPT;
}
chain OUTPUT {
chain OUTPUT {
policy DROP;
mod state state INVALID DROP;
mod state state (ESTABLISHED RELATED) ACCEPT;
outerface lo ACCEPT;
@if $HAVE_FRONT_ACCESS {
outerface $IF_FRONT proto tcp dport $OPEN_PORT_FRONT_ACCESS ACCEPT;
}
@if $NEED_VRRP {
outerface $IF_VRRP proto vrrp ACCEPT;
outerface $IF_FRONT proto vrrp ACCEPT;
}
@if $NEED_UDP_FRONT_ACCESS {
outerface $IF_FRONT proto udp dport $UDP_OPEN_PORT_FRONT_ACCESS ACCEPT;
}
@if $HAVE_BACK_ACCESS {
outerface $IF_BACK proto tcp dport $OPEN_PORT_BACK_ACCESS ACCEPT;
}
@if $NEED_UDP_BACK_ACCESS {
outerface $IF_BACK proto udp dport $UDP_OPEN_PORT_BACK_ACCESS ACCEPT;
}
proto icmp ACCEPT;
}
chain FORWARD policy DROP;
}
```

+ 2
- 2
proxmox/systeme_de_fichier.md View File

@ -1,8 +1,8 @@
# ZFS et de l'articulation des nodes
On a quatres nodes dont 3 d'entre elle en production il faut donc limiter au maximum le risque de perte de données. Pour cela nous allons mettre en place sur chaque node deux disques identique en RAID-1. Nous avons choisi ZFS comme système de fichier, CEPH à été envisagé puis abandonné car trop comliqué à mettre en place sur l'infrastructure sans grosse dépense.
On a deux nodes en production il faut donc limiter au maximum le risque de perte de données. Pour cela nous allons mettre en place sur chaque node deux disques identique en RAID-1. Nous avons choisi ZFS comme système de fichier, CEPH à été envisagé puis abandonné car trop comliqué à mettre en place sur l'infrastructure sans grosse dépense.
Nous avons choisi d'avoir 4 pools ZFS indépendante pour que la réplication des données soit indépendante d'une node à l'autre.
Nous avons choisi d'avoir 2 pools ZFS indépendante pour que la réplication des données soit indépendante d'une node à l'autre.
## Avantages de ZFS


+ 28
- 0
reseau/logique_interface_pare_feu.md View File

@ -0,0 +1,28 @@
# Choix des interfaces et des adresses IP
Petits récapitulatif sur comment on était choisi les interfaces sur chaque conteneurs / VM.
**Un container = Une interface**
Rappel sur l'ordre des zones :
- WAN/DMZ/PROXY/INTERNE pour la partie Kr[HACK]en
- WAN/DMZ/CTF pour la partie CTF
Voici les règles pour le choix de l'interface du conteneur :
- Les conteneurs qui agissent sur plusieurs zones seront dans la zone la plus élevée.
- Les autres conteneurs seront dans la zone sur laquelle ils agissent.
Les IP sont organisé avec la logique suivante :
- Plus le service est important plus sont numéro est petit,
- Les IP des services redondé ainsi que leur éventuelle IP virtuelle se suivent.
La liste est disponible [ici](mise_en_place.md).
# Règles de pare-feu
Afin de permettre à un conteneur d'une zone de communiquer avec un conteneur d'une autre zone il y aura du routage entre VLAN qui sera géré au niveau de OPNSense, tout cela sera détaillé dans la partie OPNSense. Il y aura aussi un pare-feu sur chaque conteneur qui autorisera que ce qui est nécessaire, le détails est disponible [ici](../proxmox/securisation/template_ferm.md).
Donc deux types de pare-feu :
- Global au niveau d'OPNSense.
- Local sur chaque conteneur.

+ 0
- 18
reseau/logique_ip_ct_vm.md View File

@ -1,18 +0,0 @@
# Interfaces des containes / VM
Les addresse IP des conteneurs (en fonction des zones) sont décrite dans leur fiche de documentation et mis en place automatiquement par les playbook Ansible.
Si vous n'utilisez pas Ansible, vous touverez ici les bonnes manière pour choisir les adresses IP
## Zone ADMIN
Tout les conteneurs doivent avoir une interface réseau sur la VLAN 100 du switch administation ce qui permettra d'utiliser Ansible ou de faire, a terme, du monitoring.
Les IP seront de la forme `10.1.0.ID_PROXMOX` ou l'ID Proxmox est le numéro du contenant dans Proxmox
## Le reste
Pour les autres interfaces chosissez une adresse cohérente vis à vis des adresses déjà allouées, la liste est disponible [ici](mise_en_place.md).
Les IP sont organisé avec la logique suivante :
- Plus le service est important plus sont numéro est petit,
- Les IP des services redondé ainsi que leur éventuelle IP virtuelle se suivent.

+ 36
- 215
reseau/mise_en_place.md View File

@ -12,84 +12,58 @@ Switch Wan VLAN 10
Switch Interne VLAN 10
- Proxmox Alpha :10.0.0.1
- Proxmox Beta : 10.0.0.2
- Proxmox Sigma : 10.0.0.3
- Firewall Alpha : 10.0.0.4
- Firewall Sigma : 10.0.0.5
- HAProxy Alpha : 10.0.0.6
- HAProxy Beta : 10.0.0.7
- HAProxy Sigma : 10.0.0.8
- HAProxy VIP : 10.0.0.9
- Firewall Alpha : 10.0.0.3
- Firewall Beta : 10.0.0.4
- HAProxy Alpha : 10.0.0.5