Changement total de l'infra réseau
Pierre Coimbra
parent
c32b5f161c
commit
6df6fca32b
|
|
@ -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](#)
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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`;
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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,45 +74,65 @@ 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 "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.intrafront.rev";
|
||||
file "/etc/bind/zones/db.krhacken.org.intraproxy.rev";
|
||||
};
|
||||
};
|
||||
view "internalback" {
|
||||
|
|
@ -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.
|
||||
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
|
||||
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
|
||||
alpha.haproxy IN A 10.0.1.1
|
||||
beta.haproxy IN A 10.0.1.2
|
||||
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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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/*
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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,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";
|
||||
};
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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...)
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
- HAProxy Beta : 10.0.0.6
|
||||
- HAProxy VIP : 10.0.0.7
|
||||
- Proxy Interne : 10.0.0.252
|
||||
- DNS : 10.0.0.253
|
||||
- Firewall VIP : 10.0.0.254
|
||||
|
||||
### PROXY
|
||||
Switch Interne VLAN 20
|
||||
- HAProxy Alpha : 10.0.1.1
|
||||
- HAProxy Beta : 10.0.1.2
|
||||
- HAProxy Sigma : 10.0.1.3
|
||||
- Nginx Public Alpha : 10.0.1.3
|
||||
- Nginx Public Beta : 10.0.1.4
|
||||
- Nginx Public Sigma : 10.0.1.3
|
||||
- Mail Alpha : 10.0.1.10
|
||||
- Mail Sigma : 10.0.1.11
|
||||
- Mail VIP : 10.0.1.12
|
||||
- Firewall Alpha : 10.0.1.248
|
||||
- Firewall Sigma : 10.0.1.249
|
||||
- DNS Alpha : 10.0.1.250
|
||||
- DNS Sigma : 10.0.1.251
|
||||
- Proxy Interne : 10.0.1.252
|
||||
- DNS VIP : 10.0.1.253
|
||||
- Nginx Public Alpha : 10.0.1.1
|
||||
- Nginx Public Beta : 10.0.1.2
|
||||
- Mail : 10.0.1.5
|
||||
- Firewall Alpha : 10.0.1.252
|
||||
- Firewall Beta : 10.0.1.253
|
||||
- Firewall VIP : 10.0.1.254
|
||||
|
||||
### INT
|
||||
Switch Interne VLAN 30
|
||||
- LDAP Beta : 10.0.2.1
|
||||
- LDAP Sigma : 10.0.2.2
|
||||
- LDAP Beta : 10.0.2.2
|
||||
- LDAP VIP : 10.0.2.3
|
||||
- Nginx Public Alpha : 10.0.2.4
|
||||
- Nginx Public Beta : 10.0.2.5
|
||||
- Nginx Public Sigma : 10.0.2.3
|
||||
- Mail Frontend : 10.0.2.9 (peut-être)
|
||||
- Mail Backend Alpha : 10.0.2.10
|
||||
- Mail Backend Sigma : 10.0.2.11
|
||||
- Mail Backend VIP : 10.0.2.12
|
||||
- LDAP WebUI : 10.0.2.15
|
||||
- Nextcloud : 10.0.2.20
|
||||
- Gitea : 10.0.2.21
|
||||
- [...]
|
||||
- Firewall Alpha : 10.0.2.248
|
||||
- Firewall Sigma : 10.0.2.249
|
||||
- DNS Alpha : 10.0.2.250
|
||||
- DNS Sigma : 10.0.2.251
|
||||
- Proxy Interne : 10.0.2.252
|
||||
- DNS VIP : 10.0.2.253
|
||||
- Mail Frontend : 10.0.2.4
|
||||
- Mail Backend : 10.0.2.5
|
||||
- LDAP WebUI : 10.0.2.6
|
||||
- Site Web : 10.0.2.7
|
||||
- Wiki : 10.0.2.8
|
||||
- Nextcloud : 10.0.2.10
|
||||
- Gitea : 10.0.2.11
|
||||
- Mailvelope : 10.0.2.12
|
||||
- SysPass : 10.0.2.13
|
||||
- Firewall Alpha : 10.0.2.252
|
||||
- Firewall Beta : 10.0.2.253
|
||||
- Firewall VIP : 10.0.2.254
|
||||
|
||||
|
||||
### CTF :
|
||||
Switch Interne VLAN 40
|
||||
- HAProxy Alpha : 10.0.3.1
|
||||
- HAProxy Beta : 10.0.3.2
|
||||
- HAProxy Sigma : 10.0.3.3
|
||||
- Nginx CTF : 10.0.3.4
|
||||
- CTFd Open : 10.0.3.10
|
||||
- CTFd Special : 10.0.3.11
|
||||
- Environnement Système : 10.0.3.12
|
||||
- Environnement Web : 10.0.3.13
|
||||
- [...]
|
||||
- Firewall Alpha : 10.0.3.250
|
||||
- Firewall Sigma : 10.0.3.251
|
||||
- Proxy Interne : 10.0.3.252
|
||||
- Nginx CTF : 10.0.3.1
|
||||
- CTFd Open : 10.0.3.5
|
||||
- CTFd Special : 10.0.3.6
|
||||
- Environnement Système : 10.0.3.7
|
||||
- Environnement Web : 10.0.3.8
|
||||
- Firewall Alpha : 10.0.3.252
|
||||
- Firewall Beta : 10.0.3.253
|
||||
- Firewall VIP : 10.0.3.254
|
||||
|
||||
|
||||
### DIRTY :
|
||||
Switch Interne VLAN 50
|
||||
- Firewall Alpha : 10.0.4.250
|
||||
- Firewall Sigma : 10.0.4.251
|
||||
- Proxy Interne : 10.0.4.6252
|
||||
- Firewall VIP : 10.0.4.6254
|
||||
- Firewall Alpha : 10.0.4.252
|
||||
- Firewall Beta : 10.0.4.253
|
||||
- Firewall VIP : 10.0.4.254
|
||||
|
||||
Pas d'autres conteneurs permanent (10.0.4.0/24)
|
||||
|
||||
|
|
@ -97,48 +71,37 @@ Pas d'autres conteneurs permanent (10.0.4.0/24)
|
|||
Switch Interne VLAN 100
|
||||
- Alpha : 10.0.10.1
|
||||
- Beta : 10.0.10.2
|
||||
- Gamma : 10.0.10.3
|
||||
|
||||
### CoroSync
|
||||
Switch Administration VLAN 10
|
||||
- Alpha : 10.1.1.1
|
||||
- Beta : 10.1.1.2
|
||||
- Gamma : 10.1.1.3
|
||||
|
||||
### pfSync
|
||||
Switch Administration VLAN 20
|
||||
- Alpha : 10.1.2.1
|
||||
- Gamma : 10.1.2.2
|
||||
- Beta : 10.1.2.2
|
||||
|
||||
### GRE Admin
|
||||
Switch Administration VLAN 30
|
||||
- Alpha : 10.1.10.1
|
||||
- Beta : 10.1.10.2
|
||||
- Gamma : 10.1.10.3
|
||||
|
||||
### Administration :
|
||||
Switch Administration VLAN 100
|
||||
- Firewall Alpha : 10.1.0.1
|
||||
- Firewall Gamma : 10.1.0.2
|
||||
- Proxmox Alpha : 10.1.0.4
|
||||
- Proxmox Beta : 10.1.0.5
|
||||
- Proxmox Gamma : 10.1.0.6
|
||||
- [...]
|
||||
- Proxy Interne : 10.1.0.252
|
||||
- DNS : 10.1.0.253
|
||||
- Firewall VIP : 10.1.0.254
|
||||
|
||||
|
||||
- Grafana : 10.1.0.3
|
||||
- Ansible : 10.1.0.4
|
||||
|
||||
# Réseau physique
|
||||
|
||||
La configuration et les branchement à faire sur le switch sera détaillé plus tard.
|
||||
|
||||
# Réseau virtuel
|
||||
Cette partie consiste à mettre en place OpenvSwitch sur les deux nodes.
|
||||
|
||||
## Installation
|
||||
Commune aux trois nodes
|
||||
Commune aux deux nodes
|
||||
```
|
||||
apt-get update
|
||||
apt-get install openvswitch-switch
|
||||
|
|
@ -212,21 +175,9 @@ iface vmbr1 inet manual
|
|||
ovs_ports bond0 vx1 dmz
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre1 -- set interface gre1 type=gre options:remote_ip='10.0.10.2'
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre2 -- set interface gre2 type=gre options:remote_ip='10.0.10.3'
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre1
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre2
|
||||
#Switch Interne
|
||||
|
||||
#Admin Task
|
||||
allow-vmbr2 admintask
|
||||
iface vmbr2 inet static
|
||||
address 10.1.0.4
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr2
|
||||
ovs_options tag=100
|
||||
#Accès à la Admin
|
||||
|
||||
#Corosync
|
||||
allow-vmbr2 coro
|
||||
iface coro inet static
|
||||
|
|
@ -264,9 +215,7 @@ iface vmbr2 inet manual
|
|||
ovs_ports eth2 vx2
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr2 gre3 -- set interface gre3 type=gre options:remote_ip='10.1.10.2'
|
||||
up ovs-vsctl --may-exist add-port vmbr2 gre4 -- set interface gre4 type=gre options:remote_ip='10.1.10.3'
|
||||
down ovs-vsctl --if-exists del-port vmbr2 gre3
|
||||
down ovs-vsctl --if-exists del-port vmbr2 gre4
|
||||
#Switch Administration
|
||||
```
|
||||
|
||||
|
|
@ -336,9 +285,7 @@ iface vmbr1 inet manual
|
|||
ovs_ports bond0 vx1 dmz
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre1 -- set interface gre1 type=gre options:remote_ip='10.0.10.1'
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre2 -- set interface gre2 type=gre options:remote_ip='10.0.10.3'
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre1
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre2
|
||||
#Switch Interne
|
||||
|
||||
#Admin Task
|
||||
|
|
@ -388,132 +335,6 @@ iface vmbr2 inet manual
|
|||
ovs_ports eth2 vx2
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr2 gre3 -- set interface gre3 type=gre options:remote_ip='10.1.10.1'
|
||||
up ovs-vsctl --may-exist add-port vmbr2 gre4 -- set interface gre4 type=gre options:remote_ip='10.1.10.3'
|
||||
down ovs-vsctl --if-exists del-port vmbr2 gre3
|
||||
down ovs-vsctl --if-exists del-port vmbr2 gre4
|
||||
#Switch Administration
|
||||
```
|
||||
|
||||
### Pour Gamma (/etc/network/interfaces)
|
||||
```
|
||||
#Bond eth1/eth3 pour vmbr1
|
||||
allow-vmbr1 bond0
|
||||
iface bond0 inet manual
|
||||
ovs_bonds eth1 eth3
|
||||
ovs_type OVSBond
|
||||
ovs_bridge vmbr1
|
||||
ovs_options bond_mode=active-backup
|
||||
|
||||
auto lo
|
||||
iface lo inet loopback
|
||||
|
||||
iface eth0 inet manual
|
||||
|
||||
iface eth1 inet manual
|
||||
|
||||
iface eth2 inet manual
|
||||
|
||||
iface eth3 inet manual
|
||||
|
||||
# WAN
|
||||
allow-vmbr0 wan
|
||||
iface lan inet static
|
||||
address X.X.X.X
|
||||
netmask YY
|
||||
gateway Z.Z.Z.Z
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr0
|
||||
ovs_options tag=10
|
||||
#IP Publique
|
||||
|
||||
#OVS Bridge WAN
|
||||
allow-ovs vmbr0
|
||||
iface vmbr0 inet manual
|
||||
ovs_type OVSBridge
|
||||
ovs_ports eth0
|
||||
#Switch WAN
|
||||
|
||||
#GRE vmbr1
|
||||
allow-vmbr1 vx1
|
||||
iface vx1 inet static
|
||||
address 10.0.10.3
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr1
|
||||
ovs_options tag=100
|
||||
#Synchronisation Switch Interne
|
||||
|
||||
#DMZ vmbr1
|
||||
allow-vmbr1 dmz
|
||||
iface dmz inet static
|
||||
address 10.0.0.3
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr1
|
||||
ovs_options tag=10
|
||||
#Accès à la DMZ
|
||||
|
||||
#OVS Bridge interne
|
||||
auto vmbr1
|
||||
iface vmbr1 inet manual
|
||||
ovs_type OVSBridge
|
||||
ovs_ports bond0 vx1 dmz
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre1 -- set interface gre1 type=gre options:remote_ip='10.0.10.1'
|
||||
up ovs-vsctl --may-exist add-port vmbr1 gre2 -- set interface gre2 type=gre options:remote_ip='10.0.10.2'
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre1
|
||||
down ovs-vsctl --if-exists del-port vmbr1 gre2
|
||||
#Switch Interne
|
||||
|
||||
#Admin Task
|
||||
allow-vmbr2 admintask
|
||||
iface vmbr2 inet static
|
||||
address 10.1.0.6
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr2
|
||||
ovs_options tag=100
|
||||
#Accès à la Admin
|
||||
|
||||
#Corosync
|
||||
allow-vmbr2 coro
|
||||
iface coro inet static
|
||||
address 10.1.1.3
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr2
|
||||
ovs_options tag=10
|
||||
#Synchronisation des hyperviseurs
|
||||
|
||||
#pfSync
|
||||
allow-vmbr2 pfsync
|
||||
iface pfsync inet static
|
||||
address 10.1.2.3
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr2
|
||||
ovs_options tag=20
|
||||
#Synchronisation des FW
|
||||
|
||||
#GRE vmbr2
|
||||
allow-vmbr2 vx2
|
||||
iface vx2 inet static
|
||||
address 10.1.10.3
|
||||
netmask 24
|
||||
ovs_type OVSIntPort
|
||||
ovs_bridge vmbr2
|
||||
ovs_options tag=30
|
||||
#Synchronisation du switch Administration
|
||||
|
||||
#OVS Bridge administation
|
||||
auto vmbr2
|
||||
iface vmbr2 inet manual
|
||||
ovs_type OVSBridge
|
||||
ovs_ports eth2 vx2
|
||||
up ovs-vsctl set Bridge ${IFACE} rstp_enable=true
|
||||
up ovs-vsctl --may-exist add-port vmbr2 gre3 -- set interface gre3 type=gre options:remote_ip='10.1.10.1'
|
||||
up ovs-vsctl --may-exist add-port vmbr2 gre4 -- set interface gre4 type=gre options:remote_ip='10.1.10.2'
|
||||
down ovs-vsctl --if-exists del-port vmbr2 gre3
|
||||
down ovs-vsctl --if-exists del-port vmbr2 gre4
|
||||
#Switch Administration
|
||||
```
|
||||
|
|
|
|||
|
|
@ -13,9 +13,9 @@ Le réseau WAN permettra de faire le lien entre l'extérieur, les pare-feux et l
|
|||
|
||||
Le réseau interne sera séparé en 5 zones privées :
|
||||
|
||||
- DMZ qui sera située juste après le firewall et qui contiendra les loadbalanceurs (HAProxy) et le serveur DNS.
|
||||
- DMZ qui sera située juste après le firewall et qui contiendra les loadbalanceurs (HAProxy), le proxy interne et le serveur DNS interne.
|
||||
|
||||
- PROXY qui sera placée juste après la DMZ et qui contiendra les reverses proxy pour les services autres que les environnements CTF ainsi qu'une Mail Gateway pour faire un relai entre l'extérieur et le serveur mail. Ce relai permettra de filtrer les mails.
|
||||
- PROXY qui sera placée juste après la DMZ et qui contiendra les reverses proxy pour les services autres que les environnements CTF, un proxy interne ainsi qu'une Mail Gateway pour faire un relai entre l'extérieur et le serveur mail. Ce relai permettra de filtrer les mails.
|
||||
|
||||
- INT qui contiendra les conteneurs des services permanents. La liaison entre INT et PROXY se fera à travers les reverse proxy NGINX et la Mail Gateway.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ Tous les hyperviseurs auront une interface pour le protocole GRE qui permet l'é
|
|||
|
||||
## Services Frontend
|
||||
|
||||
Concrètement, les conteneurs / VM frontend auront des ports d'entrée DNAT via le pare-feu, les rendant accessibles depuis internet. C'est le cas de HAProxy, du serveur DNS et du Proxy des services.
|
||||
Concrètement, les conteneurs / VM frontend auront des ports d'entrée DNAT via le pare-feu, les rendant accessibles depuis internet. C'est le cas de HAProxy, du serveur DNS et du Proxy.
|
||||
|
||||
Tout ces conteneurs auront obligatoirement une interface sur le VLAN 10 et une VLAN backend du switch Interne.
|
||||
|
||||
|
|
@ -43,7 +43,7 @@ Cette partie sera découpée en plusieurs zones :
|
|||
|
||||
## Partie Internet
|
||||
|
||||
Tout les conteneurs et les VM Backend auront accès à internet via le proxy interne (en frontend). L'accès se fera depuis toutes les zones sur l'adresse terminant en .252.
|
||||
Tout les conteneurs et les VM Backend auront accès à internet via le proxy interne (en frontend). L'accès se fera depuis toutes les zones à l'adresse 10.0.0.252.
|
||||
|
||||
## Partie Administration
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue