Rajout présentation du projet
parent
ef9c5c3c83
commit
1ce75c1586
|
@ -10,12 +10,12 @@ D'abord, l'idée est d'héberger tous les outils utilisés par le club (Web, Nex
|
|||
- D. Pressensé
|
||||
|
||||
## La philosophie
|
||||
Le fait de reprendre le contrôle physique sur les infrastructures techniques utilisées au sein du club s'inscrit dans une démarche volontaire. Cela nous pemettra d'élargir le champs de nos connaissances sur des problématiques concrètes.
|
||||
Le fait de reprendre le contrôle physique sur les infrastructures techniques utilisées au sein du club s'inscrit dans une démarche volontaire. Cela nous permettra d'élargir le champs de nos connaissances sur des problématiques concrètes.
|
||||
|
||||
L'indépendance financière et la pérénité sont des points clefs dans un projet d'une telle ampleur un petit club étudiant. Ainsi le fait que nous ne soyions plus dépendants d'un service payant chez OVH, nous libère de beaucoup de contraintes à la fois pécunières et organisationnelles. La documentation et la transmission des connaissances sera primordiale.
|
||||
L'indépendance financière et la pérennité sont des points clefs dans un projet d'une telle ampleur un petit club étudiant. Ainsi le fait que nous ne soyons plus dépendants d'un service payant chez OVH, nous libère de beaucoup de contraintes à la fois pécuniaires et organisationnelles. La documentation et la transmission des connaissances sera primordiale.
|
||||
|
||||
## Les responsabilités
|
||||
Nous sommes conscients que dans un tel projet, le plus dur n'est pas de monter l'infrastructure, mais de la maintenir au fil des années. Les responsabilités seront donc gérées de manière extrèmement strictes, avec plusieurs niveaux d'accès. Il faudra en effet différencier le poste du webmestre qui ne pourra agir que sur la partie applicative, de celui de l'administrateur système qui aura l'accès global. De grands pouvoirs appellant de grandes responsabilités, les adminsys en poste auront la
|
||||
Nous sommes conscients que dans un tel projet, le plus dur n'est pas de monter l'infrastructure, mais de la maintenir au fil des années. Les responsabilités seront donc gérées de manière extrêmement strictes, avec plusieurs niveaux d'accès. Il faudra en effet différencier le poste du webmestre qui ne pourra agir que sur la partie applicative, de celui de l'administrateur système qui aura l'accès global. De grands pouvoirs appelant de grandes responsabilités, les adminsys en poste auront la
|
||||
charge de former leur successeurs.
|
||||
|
||||
# Table des matières
|
||||
|
|
|
@ -1,49 +1,49 @@
|
|||
## Présentation de l'infrastructure
|
||||
|
||||
### Infrastructure matérielle
|
||||
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 Coeur cadencé à 2.93 GHz. Côté stockage, nous allons mettre en place un RAID1 ZFS pour chacune des nodes ainsi le stockage sera répliqué pour éviter toute perte de données.
|
||||
|
||||
Les 2 serveurs seront en cluster 2 noeuds avec Proxmox 6. Tous les services hébergés seront dans des containers différents.
|
||||
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 disque par PC (les données du premier disque seront copiées sur le second) ainsi le stockage sera répliqué pour éviter toute perte de données.
|
||||
|
||||
L'un des buts de cette installation est d'avoir une documentation complète sur toute la mise en place du serveur et de Proxmox, mais aussi une documentation pour toutes les tâches d'administration ce qui permettra à nos successeurs de maintenir le serveur sans difficulté.
|
||||
Les 2 nodes du serveurs, que nous appellerons Alpha et Beta, auront Proxmox comme hyperviseur et seront en cluster grâce à Proxmox. Pour plus de détails sur Proxmox ce référer à la partie Proxmox.
|
||||
|
||||
### Infrastructure logicielle
|
||||
|
||||
#### Infrastructure réseau du serveur
|
||||
Tous les containers/VMs seront répliqués entre les deux nodes car ce sont des services sensibles
|
||||
L'infrastructure réseau du club s'articulerait de la manière suivante (sur chaque node) :
|
||||
- Une VM OPNSense qui servira de Firewall de routeur
|
||||
- Un container HAProxy qui servira de loadbalancing entre les reverses proxy
|
||||
- Un container NGINX Public qui servira de reverse proxy entre HAProxy et les services publics.
|
||||
- Uniquement sur Bêta, un container avec NGINX qui servira de reverse proxy entre HAProxy l'environnement CTF.
|
||||
Les containers/VMs sensibles seront répliqués entre les deux nodes
|
||||
|
||||
#### Infrastructure publique du serveur
|
||||
L'infrastructure réseau du club s'articulerait de la manière suivante (sur chaque node) :
|
||||
- OPNSense qui servira de Firewall de routeur.
|
||||
- HAProxy qui servira de loadbalanceur entre les reverses proxy
|
||||
- NGINX qui fera office de reverse proxy entre HAProxy et les serveurs web autre que ceux des environnements CTF.
|
||||
- Uniquement sur Beta, un reverse proxy NGINX qui servira de reverse proxy entre HAProxy et l'environnement CTF.
|
||||
|
||||
#### Services permanents
|
||||
Les containers/VMs permettant l'accès à ces services ne sont pas détaillés ici.
|
||||
|
||||
L'infrastructure web du club s'articulerait de la manière suivante :
|
||||
- Un container pour héberger le site web du club.
|
||||
- Un container pour héberger le Wiki du club.
|
||||
- Un NextCloud pour mettre en commun des fichiers au sein du club et l'ordre du jour des réunions.
|
||||
- Un Git sur lequel toutes les sources de tous les challenges du club seront stockées ainsi que toute la documentation des services pour qu'ils puissent être maintenus dans le temps.
|
||||
- Un service de messagerie instantanée du type Mattermost pour pouvoir communiquer simplement entre membres du club.
|
||||
- Un annuaire LDAP (slapd), qui permettra d'avoir un compte unique pour accéder à tous nos services, avec des groupes limitant l'accès à certain services.
|
||||
- Un serveur mail pour remplacer le serveur actuel hébergé chez OVH.
|
||||
- Un annuaire LDAP (slapd), géré avec FusionDirectory, qui permettra d'avoir un compte unique pour accéder à tous nos services. Ces comptes seront créés uniquement pour les membres actifs du club et pour un responsable.
|
||||
- Le site web du club.
|
||||
- Le Wiki du club.
|
||||
- NextCloud pour mettre en commun des fichiers au sein du club et l'ordre du jour des réunions.
|
||||
- Gitea sur lequel toutes les sources de tous les challenges du club seront stockées ainsi que toute la documentation du club.
|
||||
- Un service de messagerie instantanée du type Mattermost
|
||||
|
||||
L'objectif de l'infrastructure web est de regrouper tous les hébergements utilisés par le club.
|
||||
L'objectif de ces services est de regrouper tous les hébergements utilisés par le club.
|
||||
|
||||
#### Infrastructure CTF du club
|
||||
L'objectif est de remplacer la banque de challenge du club stockée actuellement sur un serveur en B141, serveur qui est très mal documenté ce qui réduit considérablement les modifications que nous pouvons y apporter.
|
||||
#### Environnements CTF
|
||||
L'objectif est de remplacer la banque de challenge du club stockée actuellement sur un serveur en B141, serveur qui n'est pas documenté ce qui réduit considérablement les modifications que nous pouvons y apporter.
|
||||
|
||||
L'infrastructure CTF du club s'organisera de la manière suivante :
|
||||
- Un container CTFd avec tous les challenges actuels du club utilisés pour les OpenCTF.
|
||||
- Un autre container CTFd que nous utiliserons pour les sessions en externe comme par exemple pour la session 0 ou il n'y a ni classement ni challenge récurrent.
|
||||
- Un premier CTFd avec tous les challenges actuels du club utilisés pour les OpenCTF.
|
||||
- Un autre CTFd que nous utiliserons pour les sessions en externe comme par exemple pour la session 0 ou il n'y a ni classement ni challenge récurrent.
|
||||
- Une VM avec différents environnements Docker temporaires pour les challenges système.
|
||||
- Une VM avec différents environnements Docker pour les challenges Web.
|
||||
|
||||
L'objectif de l'infrastructure CTF est de retrouver un contrôle sur notre banque de challenges pour pouvoir y ajouter des challenges et de pouvoir mettre en place des CTF temporaires pour les événements du club.
|
||||
|
||||
## Gestion du serveur en interne
|
||||
|
||||
Pour la gestion en interne du serveur, nous nous organiserions de la manière suivante : seulement deux personnes du bureau auront un accès total au serveur pour éviter tout problème d'administration. Les accès seront logés et les comptes nominatifs.
|
||||
Pour ce qui est de l'accès aux services web, tous les membres actifs du club y auront accès, mais seul le responsable technique et les 2 personnes s'occupant du serveur auront les droits d'administration.
|
||||
Pour ce qui est de l'accès au service CTF, seulement les responsables événements, technique et serveur y auront accès en tant qu'administrateurs, toutes les personnes participant à l'événement auront un accès à l'interface utilisateur de CTFd, les accès seront loggés.
|
||||
Pour la gestion en interne du serveur, nous nous organiserions de la manière suivante,
|
||||
|
||||
- Seulement deux personnes du bureau auront un accès total au serveur pour éviter tout problème d'administration. Les accès seront logés et les comptes nominatifs.
|
||||
- Pour ce qui est de l'accès aux services web, tous les membres actifs du club y auront accès, mais seul le responsable technique et les personnes s'occupant du serveur auront les droits d'administration.
|
||||
- Pour ce qui est de l'accès aux services CTF, seulement les responsables événements, technique et serveur y auront accès en tant qu'administrateurs, toutes les personnes participant à l'événement auront un accès à l'interface utilisateur du CTF, les accès à cette interface seront loggés.
|
||||
|
|
|
@ -14,10 +14,10 @@ Les requêtes arriveront sur le pare-feu qui effectura un premier filtrage et tr
|
|||
|
||||
## Pour les connexions à la partie administration
|
||||
|
||||
L'accès à l'interface d'administration de Proxmox se fera par la voie classique, en cas de connexion à pve.krhacken.org, HAProxy vérifira le certificat client et son CN avant de rediriger vers un des deux panels.
|
||||
L'accès à l'interface d'administration de Proxmox se fera par la voie classique, en cas de connexion à pve.krhacken.org, HAProxy vérifiera le certificat client et son CN avant de rediriger vers un des deux panels.
|
||||
|
||||
L'accès au port 8006 (port par défaut de l'UI Proxmox) et au port 22 se fera par un VPN qui sera géré par le pare feu (OPNSense) sur la zone ADMIN.
|
||||
|
||||
Voilà un schéma (très simplifié) de la topologie globale du réseau (user et admin)
|
||||
|
||||

|
||||

|
||||
|
|
Loading…
Reference in New Issue