coimbrap/projet_serveur_krkn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Changement total de l'infra réseau

Browse Source
This commit is contained in:
Pierre Coimbra
2020-05-02 13:55:38 +02:00
parent c32b5f161c
commit 6df6fca32b
36 changed files with 473 additions and 608 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

20
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

12
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

2
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

2
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

96
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;
}
```

4
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