Sécurisation de l’Infrastructure SecureDev SARL
1. Introduction
1.1. contexte et objectif
SecureDev SARL est une PME spécialisée dans le développement logiciel sur des sujets sensibles. La PME nécessite une infrastructure informatique robuste, sécurisée et résiliente pour garantir la confidentialité, l’intégrité et la disponibilité de ses données.
En tant que nouvel administrateur sécurité, notre mission consiste à concevoir, déployer et sécuriser l’infrastructure réseau de l’entreprise, en tenant compte des enjeux métiers (développement de logiciels critiques) et des contraintes techniques (multi-sites, sensibilité des données).
Ce projet s’inscrit dans une démarche proactive de gestion des risques, conformément aux bonnes pratiques en cybersécurité (ISO 27001, RGPD, recommandations ANSSI).
Il a pour but de mettre en place une infrastructure système et réseau sécurisée pour SecureDev SARL.
1.2. Schéma d’architecture
1.3. Description des Flux et Rôles
| Composant | Rôle | Sécurité Associée |
|---|---|---|
| Pare-feu | Filtre les flux entre VLANs et sites | Règles DEFAULT DROP, journalisation |
| VLAN 10 (FTP) | Serveur FTP sécurisé avec SSL/TLS et détection d’intrusions (SNORT) | Chroot, certificats signés par la CA |
| VLAN 20 (CA) | Autorité de certification pour les certificats SSL/TLS | Accès restreint aux admins, logs SNORT |
| VLAN 30 (Clients) | Postes utilisateurs | Accès contrôlé via pare-feu |
| VLAN 40 (AD/OpenVAS) | Active Directory + scanner de vulnérabilités | Intégration avec LDAP/Kerberos, scans quotidiens (dans l’ideal LDAPS) |
| VPN IPsec | Connexion sécurisée entre Site 1 et Site 2 | Chiffrement AES-256, authentification par certificats |
| Sauvegardes (cloud privé) | Sauvegardes automatiques et chiffrées, sécurité physique | Protocole SFTP/SCP, chiffrement |
| Redondance | Serveurs de secours (symbolisés) | Exemple Keepalived (en production) |
1.4. Matrice de flux Réseau
Protocole/Port utilisés :
TCP 21/990 : FTP (standard et sécurisé avec SSL/TLS)
TCP 2222: SSH (accès admin uniquement)
TCP 389/636 : LDAP (authentification) / LDAPS (chiffré)
UDP 500/4500 : VPN IPsec (IKE pour l’échange de clés)
TCP 9390 : OpenVAS (interface de scan)
TCP 80/443 : HTTP/HTTPS (accès web)
TCP/UDP 53 : DNS
TCP 465/587/993 : SMTPS/IMAPS
| Source | Destination | Protocole/Port | Rôle | Sécurité Appliquée | Politique |
|---|---|---|---|---|---|
| POSTE-client (VLAN 30) | Pare-feu | TCP/UDP (tout) | Trafic utilisateur vers le pare-feu | Filtrage (règles strictes) | ✅ Oui |
| Pare-feu | SRV FTP (VLAN 10) | TCP 21 (FTP) / TCP 990 (FTPS) | Accès au serveur FTP sécurisé | Chiffrement SSL/TLS, authentification AD | ✅ Oui |
| Pare-feu | SRV CA (VLAN 20) | TCP 2222 (SSH) | Administration de la CA | Authentification par clé SSH + MFA | ✅ Oui (Admins) |
| Pare-feu | SRV AD (VLAN 40) | TCP 389 (LDAP) / TCP 636 (LDAPS) | Authentification centralisée (AD) | Chiffrement TLS, intégration avec Kerberos | ✅ Oui |
| SRV FTP (VLAN 10) | SRV CA (VLAN 20) | TCP 80 (HTTP) / TCP 443 (HTTPS) | Récupération des certificats SSL/TLS | Certificats signés par la CA interne | ✅ Oui |
| SRV AD (VLAN 40) | SRV FTP (VLAN 10) | TCP 389 (LDAP) / TCP 636 (LDAPS) | Vérification des identités pour le FTP | Intégration avec Samba/Winbind | ✅ Oui |
| SRV AD (VLAN 40) | POSTE-client (VLAN 30) | TCP 389 (LDAP) / TCP 636 (LDAPS) / UDP 88 (Kerberos) | Authentification des utilisateurs | Chiffrement des échanges | ✅ Oui |
| SRV OpenVAS (VLAN 40) | Tous les VLAN | TCP 9390 (OpenVAS) | Scan de vulnérabilités | Accès restreint aux admins sécurité | ✅ Oui (Admins) |
| Pare-feu | Pare-feu (site2) | UDP 500/4500 (IKE/NAT-T) | Établissement du VPN IPsec entre sites | Chiffrement AES-256, authentification certifs | ✅ Oui |
| Pare-feu | Cloud Privé | TCP 2222 (SFTP) / TCP 443 (HTTPS) | Sauvegardes chiffrées | Chiffrement AES-256, authentification clé SSH | ✅ Oui |
| SRV FTP (VLAN 10) | Cloud Privé | TCP 2222 (SFTP) | Sauvegarde des données FTP | Chiffrement et signature des sauvegardes | ✅ Oui |
| SRV AD (VLAN 40) | Cloud Privé | TCP 2222 (SFTP) | Sauvegarde des configurations AD | Chiffrement et journalisation | ✅ Oui |
| POSTE-client (VLAN 30) | Internet (via pare feu et si possible proxy) | TCP 80/443 (HTTP/HTTPS) / TCP-UDP 53 (DNS) / TCP 465/587/993 (SMTPS/IMAPS) | Accès web externe | Filtrage URL, chiffrement, proxy sécurisé | ✅ Oui (uniquement en sortie) |
Sécurité Appliquée :
Chiffrement : TLS 1.3 pour le FTP, SSL pour les certificats, AES-256 pour le VPN. Authentification : LDAP – ou de préférence LDAPS / Kerberos pour l’AD, clés SSH pour les accès admin. Filtrage : Pare-feu en mode DEFAULT DROP (tout est bloqué sauf ce qui est explicitement autorisé).
Règles Implicites (Non Exhaustives)
Entre VLANs :
Aucun flux direct entre VLANs sans passer par le pare-feu.
Journalisation :
Tous les flux autorisés et bloqués sont logués
1.5. Points de vigilance
- Acces internet
Les utilisateurs du VLAN 30 ont besoin d’un accès Internet restreint et sécurisé pour :
Consulter des documentations techniques (ex : GitHub, Stack Overflow). Effectuer des mises à jour logicielles (ex : apt update). Accéder à des outils métiers en ligne (ex : outils de développement collaboratif). Mesures mises en place :
Filtrage strict : Seuls les ports 80 (HTTP), 443 (HTTPS), et 53 (DNS) sont autorisés vers Internet. Proxy filtrant utilisé pour :
Bloquer les sites non professionnels (ex : réseaux sociaux). Journaliser les accès pour audit.
DNS sécurisé : Les requêtes DNS sont chiffrées via DNS-over-TLS pour éviter les attaques de type man-in-the-middle.
Pas d’accès SSH direct : Le port 2222 est bloqué pour éviter les tentatives de brute-force.
- FTP -> FTPS
Il s’agit d’un protocole qui permet d’envoyer et recevoir des fichiers et qui fonctionne sur le mode client/serveur. L’inconvénient principal du protocole FTP, c’est qu’il n’est pas sécurisé : lorsque l’on établis une connexion avec un serveur FTP, l’identifiant, le mot de passe et toutes les commandes que l’on passe transitent en clair sur le réseau. Le port 21 (FTP) est autorisé uniquement en conjonction avec le port 990 (FTPS) pour forcer le chiffrement SSL/TLS.
2. Mise en Place de l’Environnement
Configuration de l’infrastructure
2.1. Présentation de l’entreprise
SecureDev SARL est une entreprise de développement de logiciels sensibles. Nous avons mis en place une infrastructure réseau bi-site très sécurisée. L’objectif de cette infrastructure est de garantir la confidentialité des échanges entre le siège (Site 1) et le site permettant de faire des audits (Site 2) tout en isolant les services critiques (FTP,PKI,AD).
2.2. Architecture Réseau et Adressage
| VLAN | Nom | Réseau | Usage |
|---|---|---|---|
| 10 | SERVEUR_FTP | 172.16.10.0/24 | Stockage de fichiers (SSL/TLS) |
| 20 | SERVEUR_CA | 172.16.20.0/24 | Autorité de Certification (Debian) |
| 30 | CLIENTS | 172.16.30.0/24 | Postes de travail développeurs |
| 40 | AD_OPENVAS | 172.16.40.0/24 | AD et OpenVAS (Site 2) |
| VPN IPSec | 192.168.1.0/30 | Liaison Routeurs R0-R1 |
2.3. Configuration des équipements + sécurité des équipements
2.3.1 Switch L3 (Site 1)
enable
configure terminal
hostname L301_Site1
enable secret cisco
service password-encryption
ip domain-name securedev.lan
crypto key generate rsa (modulus 2048)
ip ssh version 2
line con 0
password cisco
login
! Changement du port SSH
ip ssh port 2222 (non fonctionnel sur packet tracer)
line vty 0 15
password cisco
login
transport input ssh
--- Création des VLANS ---
vlan 10
name SERVEUR_FTP
vlan 20
name SERVEUR_CA
vlan 30
name CLIENTS
exit
--- Configuration des interfaces ---
! Interface pour le serveur FTP
interface GigabitEthernet1/0/2
description VERS_SERVEUR_FTP
switchport mode access
switchport access vlan 10
switchport port-security
switchport port-security maximum 1
switchport port-security violation shutdown
! Interface pour le serveur CA
interface GigabitEthernet1/0/3
description VERS_SERVEUR_CA
switchport mode access
switchport access vlan 20
switchport port-security
switchport port-security maximum 1
switchport port-security violation shutdown
! Interface poue les PC Client
interface GigabitEthernet1/0/5
description VERS_PC_CLIENT
switchport mode access
switchport access vlan 30
switchport port-security
switchport port-security maximum 1
switchport port-security violation shutdown
! Désactivation des ports inutilisés
interface range GigabitEthernet1/0/4, GigabitEthernet1/0/6-34
shutdown
--- Routage Inter-VLAN (SVI) ---
ip routing
interface vlan 10
description passerelle FTP
ip address 172.16.10.254 255.255.255.0
interface vlan 20
description passerelle CA
ip address 172.16.20.254 255.255.255.0
interface vlan 30
description passerelle CLIENTS
ip address 172.16.30.254 255.255.255.0
--- Liaison vers le routeur RO ---
interface GigabitEthernet1/0/1
description VERS_ROUTEUR_0
no switchport
ip address 192.168.0.2 255.255.255.252
--- Route Statiques ---
! route par défaut vers le routeur 0 pour sortir du LAN
ip route 0.0.0.0 0.0.0.0 192.168.0.1
--- ACL entre les VLAN ---
! Autoriser les administrateurs à administrer les équipements via le nouveau port SSH (port 2222)
! Autoriser les admins du vlan 30 à administrer le switch lui même et les serveurs en ssh
access-list 110 permit tcp 172.16.30.0 0.0.0.255 172.16.0.0 0.0.255.255 eq 2222
access-list 110 permit tcp 172.16.30.0 0.0.0.255 192.168.0.0 0.0.0.255 eq 2222
! Autoriser les admins à administrer le site 2 via le VPN
access-list 110 permit tcp 172.16.30.0 0.0.0.255 172.16.40.0 0.0.0.255 eq 2222
access-list 110 permit tcp 172.16.30.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 2222
! On autorise OpenVAS (Site 2), le FTPS (990) et on isole le reste
access-list 110 permit ip host 172.16.40.1 any
access-list 110 permit tcp any host 172.16.10.1 eq 990
access-list 110 deny tcp any host 172.16.10.1 eq 21
access-list 110 permit ip host 172.16.10.1 host 172.16.20.1
access-list 110 permit ip 172.16.30.0 0.0.0.255 host 172.16.20.1
access-list 110 permit ip any any
! Autoriser DNS vers l'AD
access-list 110 permit udp 172.16.0.0 0.0.255.255 host 172.16.40.1 eq 53
access-list 110 permit tcp 172.16.0.0 0.0.255.255 host 172.16.40.1 eq 53
! Autoriser Kerberos
access-list 110 permit tcp 172.16.0.0 0.0.255.255 host 172.16.40.1 eq 88
access-list 110 permit udp 172.16.0.0 0.0.255.255 host 172.16.40.1 eq 88
! Autorisé LDAPS
access-list 110 permit tcp 172.16.0.0 0.0.255.255 host 172.16.40.1 eq 636
! Autoriser SMB et RPC
access-list 110 permit tcp 172.16.0.0 0.0.255.255 host 172.16.40.1 eq 445
access-list 110 permit tcp 172.16.0.0 0.0.255.255 host 172.16.40.1 eq 135
--- Application des ACL aux interfaces ---
interface vlan 10
ip access-group 110 in
interface vlan 20
ip access-group 110 in
interface vlan 30
ip access-group 110 in
end
write
Pour qu’on respecte la politique de sécurité de SecureDev SARL, seul le protocole LDAPS (636) est autorisé pour les requêtes d’annuaire. Le protocole LDAP classique (389) n’a pas été retenu dans ce cas là car il fait circuler les identifiants en clair sur le réseau, ce qui n’est pas acceptable pour un SI traitant des données sensibles.
2.3.2 Switch L3 (Site 2)
enable
configure terminal
hostname L302_SITE_AUDIT
enable secret cisco
service password-encryption
ip domain-name securedev.lan
crypto key generate rsa (modulus 2048)
ip ssh version 2
line con 0
password cisco
login
! Changement du port SSH
ip ssh port 2222 (non fonctionnel sur packet tracer)
line vty 0 15
password cisco
login
transport input ssh
--- Création du vlan 40 ---
vlan 40
name AD_OPENVAS
exit
--- Configuration des interfaces + sécruité
interface GigabitEthernet1/0/2
description VERS_SERVEUR_AD_OPENVAS
switchport mode access
switchport access vlan 40
switchport port-security
switchport port-security maximum 1
switchport port-security violation shutdown
! Désactivation des ports inutilisés
interface range GigabitEthernet1/0/3-24
shutdown
--- Routage et adressage (SVI)
ip routing
interface vlan 40
description Passerelle Site 2
ip address 172.16.40.254 255.255.255.0
--- Liaison vers routeur 1 ---
interface GigabitEthernet1/0/1
description VERS_ROUTEUR_R1
no switchport
ip address 192.168.1.2 255.255.255.252
--- Routage statique ---
! Route par défaut permettant d'envoyer tout le traffic vers le Site 1 via R1
ip route 0.0.0.0 0.0.0.0 192.168.1.1
--- ACL ---
! Autoriser les flux SSH (port 2222) entrants pour l'administration de l'AD ou du switch en luui-même
access-list 140 permit tcp 172.16.30.0 0.0.0.255 host 172.16.40.1 eq 2222
access-list 140 permit tcp 172.16.30.0 0.0.0.255 host 192.168.1.2 eq 2222
! Autoriser les réponses SSH (Etablished) du serveur vers les admins
access-list 140 permit tcp host 172.16.40.1 eq 2222 172.16.30.0 0.0.0.255 established
! Autoriser OPNVAS à scanner tout le réseau du site 1
access-list 140 permit ip host 172.16.40.1 172.16.0.0 0.0.255.255
! Autoriser l'AD à répondre aux requêtes DNS venant du site 1
access-list 140 permit udp host 172.16.40.1 eq 53 172.16.0.0 0.0.255.255
access-list 140 permit tcp host 172.16.40.1 eq 53 172.16.0.0 0.0.255.255
! Autoriser l'AD à répondre aux requêtes Kerberos et LDAPS
access-list 140 permit tcp host 172.16.40.1 eq 88 172.16.0.0 0.0.255.255
access-list 140 permit udp host 172.16.40.1 eq 88 172.16.0.0 0.0.255.255
access-list 140 permit tcp host 172.16.40.1 eq 636 172.16.0.0 0.0.255.255
! Autoriser l'AD à répondre aux flux SMB/RPC déjà établis
access-list 140 permit tcp host 172.16.40.1 172.16.0.0 0.0.255.255 established
! Bloquer tout autre traffic initié par le serveur vers l'extérieur (Couche de sécurité en plus)
access-list 140 deny ip host 172.16.40.1 any
! Autoriser le reste du traffic
access-list 140 permit ip any any
interface vlan 40
ip access-group 140 in
end
write
2.3.3 Routeur 0 du Site 1
enable
configure terminal
hostname R0-SIEGE
enable secret cisco
service password-encryption
ip domain-name securedev.lan
crypto key generate rsa (modulus 2048)
ip ssh version 2
line con 0
password cisco
login
line vty 0 15
password cisco
login
transport input ssh
--- Interfaces ---
! Liaison vers le Switch L3 local (Site 1)
interface GigabitEthernet0/0/1
description VERS_L301
ip address 192.168.0.1 255.255.255.252
no shutdown
! Liaison WAN vers le cloud
interface Serial0/1/0
description VERS_WAN_INTERNET
ip address 80.1.1.1 255.255.255.252
encapsulation frame-relay
no shutdown
--- Routage Statique ---
! Routes vers les VLANs locaux via le Switch L301
ip route 172.16.10.0 255.255.255.0 192.168.0.2
ip route 172.16.20.0 255.255.255.0 192.168.0.2
ip route 172.16.30.0 255.255.255.0 192.168.0.2
! Route par défaut vers le site distant (via le lien WAN)
ip route 0.0.0.0 0.0.0.0 80.1.1.2
end
write
2.3.4 Routeur 1 du site 1
enable
configure terminal
hostname R1-SITE-AUDIT
enable secret cisco
service password-encryption
ip domain-name securedev.lan
crypto key generate rsa (modulus 2048)
ip ssh version 2
line con 0
password cisco
login
line vty 0 15
password cisco
login
transport input ssh
--- Interfaces ---
! Liaison vers le Switch L3 local (Site 2)
interface GigabitEthernet0/0/1
description VERS_L302
ip address 192.168.1.1 255.255.255.252
no shutdown
! Liaison WAN vers le cloud
interface Serial0/1/0
description VERS_WAN_INTERNET
ip address 80.1.1.2 255.255.255.252
encapsulation frame-relay
no shutdown
--- Routage Statique ---
! Route vers le VLAN 40 local via le Switch L302
ip route 172.16.40.0 255.255.255.0 192.168.1.2
! Route par défaut vers le site principal (via le lien WAN)
ip route 0.0.0.0 0.0.0.0 80.1.1.1
end
write
2.3.5 Configuration du VPN IPSEC entre les deux sites
2.3.5.1 Routeur 1
--- ETAPE 1 ---
crypto isakmp policy 10
encryption aes
authentication pre-share
hash sha
group 2
lifetime 86400
exit
--- Création de la clé pré-partagée ---
crypto key cisco address 80.1.1.2
--- ETAPE 2 ---
crypto ipsec transform-set VPNKEY esp-aes esp-sha-hmac
crypto ipsec security-association lifetime seconds 7200
--- ETAPE 3 ---
! On autorise tout le traffic du site 1 vers le site 2 (VLAN 40)
access-list 100 permit ip 172.16.0.0 0.0.255.255 172.16.40.0 0.0.0.255
--- ETAPE 4 ---
crypto map VPNMAP 10 ipsec-isakmp
match address 100
set peer 80.1.1.2
set transform-set VPNKEY
exit
interface Serial0/1/0
crypto map VPNMAP
end
2.3.5.2 Routeur 2
--- ETAPE 1 ---
crypto isakmp policy 10
encryption aes
authentication pre-share
hash sha
group 2
lifetime 86400
exit
--- Création de la clé pré-partagée ---
crypto key cisco address 80.1.1.1
--- ETAPE 2 ---
crypto ipsec transform-set VPNKEY esp-aes esp-sha-hmac
crypto ipsec security-association lifetime seconds 7200
--- ETAPE 3 ---
! On autorise tout le traffic du site 2 (VLAN40) vers le site 1
access-list 100 permit ip 172.16.40.0 0.0.0.255 172.16.0.0 0.0.255.255
--- ETAPE 4 ---
crypto map VPNMAP 10 ipsec-isakmp
match address 100
set peer 80.1.1.1
set transform-set VPNKEY
exit
interface Serial0/1/0
crypto map VPNMAP
end
3. Création du serveur Ubuntu faisant office de serveur FTP sécurisé par certificat SSL/TLS
Afin de sécuriser les communications et les échanges de fichiers au sein du réseau de l’entreprise, nous mettons en place une architecture segmentée s’appuyant sur les solutions suivantes :
vsftpd (Very Secure FTP Daemon) : Comme son nom l’indique, il est conçu pour être le serveur FTP le plus sécurisé et le plus rapide sous Linux. Il permet de limiter les vulnérabilités liées aux débordements de mémoire (buffer overflows) et offre un contrôle très fin sur les utilisateurs via le chroot (isolement de l’utilisateur dans son répertoire).
FTPS (FTP over SSL/TLS) : Le protocole FTP classique fait circuler les mots de passe et les fichiers « en clair ». L’ajout de SSL/TLS, grâce à un certificat signé par notre propre Autorité de Certification (Debian), permet de chiffrer la connexion de bout en bout, rendant les données illisibles pour un espion sur le réseau.
Snort (IDS) : Même un serveur sécurisé peut être la cible d’attaques. Snort agit comme un agent de sécurité qui analyse chaque paquet réseau pour détecter des comportements suspects (comme des tentatives de brute force testant des dizaines de mots de passe par minute) et génère des alertes en temps réel.
Segmentation par VLAN : L’isolement du serveur de fichiers et de l’autorité de certification dans des VLANs distincts permet de limiter la « surface d’attaque » et d’empêcher une compromission totale du réseau en cas d’intrusion sur un seul service.
3.1. Installation des paquets
Nous installons le service FTP et les outils de cryptographie.
sudo apt update && sudo apt install vsftpd openssl -y
3.2. Génération de l’Identité (CSR)
Le serveur Ubuntu doit générer une demande de signature pour obtenir son certificat officiel de la part du serveur Debian.
# 1. Création du dossier pour la clé privée
sudo mkdir -p /etc/ssl/private
# 2. Génération de la clé et de la demande (CSR)
sudo openssl req -new -newkey rsa:2048 -nodes \
-keyout /etc/ssl/private/vsftpd.key \
-out /tmp/vsftpd.csr
3.3. Transfert Sécurisé entre Ubuntu et Debian (Commandes SCP)
Depuis le terminal Ubuntu, il faut envoyer le fichier .csr vers le dossier /tmp du serveur Debian :
scp /tmp/vsftpd.csr utilisateur@IP_SERVEUR_DEBIAN:/tmp/
3.4. Récupérer les certificats signés depuis Debian :
Une fois que le serveur Debian a signé le fichier, récupèrez le certificat du serveur (vsftpd.crt) et le certificat racine de l’autorité (ca-root.crt)
# Récupérer le certificat signé
scp utilisateur@IP_SERVEUR_DEBIAN:/tmp/vsftpd.crt /tmp/
# Récupérer le certificat de l'autorité (CA)
scp utilisateur@IP_SERVEUR_DEBIAN:/tmp/ca-root.crt /tmp/
# Déplacer les fichiers dans le bon dossier système
sudo mv /tmp/vsftpd.crt /etc/ssl/certs/
sudo mv /tmp/ca-root.crt /etc/ssl/certs/
Configuration de vsftpd pour le FTPS
Modifier le fichier de configuration :
sudo nano /etc/vsftpd.conf
# --- Paramètres de base ---
anonymous_enable=NO
local_enable=YES
write_enable=YES
chroot_local_user=YES
allow_writeable_chroot=YES
# --- Activation du chiffrement SSL/TLS ---
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1_2=YES
# --- Chemins vers les fichiers signés par Debian ---
rsa_cert_file=/etc/ssl/certs/vsftpd.crt
rsa_private_key_file=/etc/ssl/private/vsftpd.key
ca_certs_file=/etc/ssl/certs/ca-root.crt
Redémarrage du service : sudo systemctl restart vsftpd
3.5. Mise en place de Snort (Détection d’Intrusion)
Installation et configuration des alertes pour le réseau.
sudo apt install snort -y
Configuration des règles locales :
sudo nano /etc/snort/rules/local.rules
alert tcp any any -> $HOME_NET 21 (msg:"[ALERTE] Force Brute FTP détectée"; content:"USER"; threshold:type both, track by_src, count 10, seconds 60; sid:1000001; rev:1;)
alert tcp any any -> $HOME_NET 22 (msg:"[ALERTE] Force Brute SSH détectée"; flags:S; threshold:type both, track by_src, count 5, seconds 60; sid:1000002; rev:1;)
Avant de lancer le service, nous vérifions que nos règles ne contiennent pas d’erreurs de syntaxe :
sudo snort -T -c /etc/snort/snort.conf
Nous voyons « Snort successfully validated the configuration! », tout est bon.
Lancement en mode console (Pour les tests)
Pour voir les alertes s’afficher en direct pendant nos tests, nous lançons Snort avec cette commande :
sudo snort -A console -q -c /etc/snort/snort.conf
Simulation d’attaque
Depuis votre hôte Windows ou une autre VM, nous tentons de nous connecter plusieurs fois avec un mauvais mot de passe en FTP ou en SSH.
Sur votre écran Snort : Vous devriez voir apparaître en rouge les messages : [ALERTE] Force Brute FTP détectée.
Si nous voulons que la console n’affiche que nos détections de force brute sans être polluée par le trafic réseau classique, nous pouvons utiliser la commande grep :
sudo snort -A console -q -c /etc/snort/snort.conf | grep "ALERTE"
Cette commande lance Snort mais ne laisse passer à l’écran que les lignes contenant le mot « ALERTE » (que nous avons mis dans notre règle locale).
3.6. Procédure de test final (Le « Crash Test »)
Pour votre dossier technique, nous devons capturer une preuve que la règle fonctionne. Voici la marche à suivre :
Sur Ubuntu : Nous lançons la commande avec le filtre grep citée ci-dessus. Le terminal semble « figé », c’est normal, il attend une attaque.
Sur Windows (ou une autre VM) : Nous allons forcer le serveur. Ouvrez une invite de commande (cmd) et tapez :
for /L %i in (1,1,15) do ftp 192.168.1.20
(Cette commande tente d’ouvrir 15 connexions FTP à la suite).
Sur Ubuntu : Nous observons le résultat. Si 10 tentatives surviennent en moins d’une minute, votre message [ALERTE] Force Brute FTP détectée doit apparaître instantanément.
3.7. Phase de Tests et Validation
Une fois la configuration terminée, effectuer ces vérifications :
Vérification de la validité du certificat :
openssl verify -CAfile /etc/ssl/certs/ca-root.crt /etc/ssl/certs/vsftpd.crt
Doit répondre : OK
Test de connexion (Client FileZilla) :
Utiliser le mode « Connexion FTP explicite sur TLS ». Dois voir apparaître le certificat signé par ta Debian.
Test de l’IDS : Tente 10 connexions ratées et vérifie les logs :
sudo tail -f /var/log/snort/alert
3.8. Audit et Analyse Réseau (Preuve du chiffrement FTPES)
Afin de valider la conformité de notre installation et de garantir que les identifiants de connexion ne circulent pas en clair sur le réseau de l’entreprise, nous effectuons une analyse de paquets via l’outil Wireshark depuis le poste client (Hôte).
3.8.1 Méthodologie de test
Lancement de la capture : Wireshark est activé sur l’interface réseau de l’hôte en filtrant le trafic sur le port de contrôle FTP : tcp.port == 21.
Connexion Client : Utilisation du client FileZilla paramétré en mode « Connexion FTP explicite sur TLS » vers l’adresse du serveur Ubuntu.
Analyse du flux : Observation du passage du protocole FTP (non chiffré) au protocole TLS (chiffré).
3.8.2 Analyse des résultats (Interprétation de la capture) Comme nous pouvons l’observer sur la capture d’écran de l’audit, le mécanisme de sécurisation se déroule en trois étapes clés :
Initialisation (Handshake) : À la ligne 183, nous voyons la commande AUTH TLS. C’est le moment où FileZilla demande au serveur Ubuntu de basculer la session sur un canal sécurisé.
Négociation TLS : Suite à l’acceptation du serveur, les lignes 189 et 193 montrent le protocole TLSv1.3 prenant le relais.
Chiffrement des données : À partir de la ligne 203, le protocole devient exclusivement du Application Data chiffré.
3.8.3 Vérification par le « TCP Stream » Pour apporter la preuve ultime de la confidentialité, nous utilisons la fonction Follow > TCP Stream de Wireshark.
Observation : Si le début de la conversation est lisible (bannière vsftpd, AUTH TLS), l’intégralité de la suite, incluant les commandes USER et PASS (mot de passe), est remplacée par une suite de caractères aléatoires et indéchiffrables.
Conclusion de l’audit : Le test est concluant. Même si un attaquant intercepte les paquets sur le réseau, il lui est techniquement impossible de récupérer les informations de compte ou le contenu des fichiers transférés.
4. Création du serveur sous Debian faisant office d’autorité de certification
4.1. Préparation de l’environnement
Pour commencer, nous installons l’outil OpenSSL. C’est le standard industriel qui nous permet de manipuler les clés privées et de générer les certificats.
sudo apt update
sudo apt install openssl -y
4.2. Création d’un environnement de travail sécurisé
Avant de générer nos clés, nous préparons un dossier dédié afin d’organiser nos fichiers et de les protéger.
mkdir -p ~/pki-autorite && cd ~/pki-autorite
Pourquoi mkdir -p ? : Cette commande crée le dossier s’il n’existe pas. L’option -p évite les messages d’erreur et permet de créer des sous-dossiers si besoin.
Pourquoi && cd ? : Nous utilisons l’opérateur && pour ne nous déplacer dans le dossier que si sa création a réussi. Cela garantit que nous ne générons pas nos clés sensibles au mauvais endroit.
4.3. Génération de l’identité de l’Autorité (Root CA)
Nous créons maintenant les deux fichiers qui constituent la base de notre confiance réseau.
4.4. La Clé Privée (La signature secrète)
openssl genrsa -out ca-root.key 4096
4.5. Le Certificat Racine
C’est ce fichier que nous distribuerons sur le réseau. Il contient notre identité publique.
openssl req -x509 -new -nodes -key ca-root.key -sha256 -days 3650 -out ca-root.crt
-x509 : Précise que nous créons un certificat auto-signé (la base de la pyramide).
-days 3650 : Nous fixons une validité de 10 ans pour éviter de devoir renouveler toute l’infrastructure trop souvent.
Common Name (CN) : Lors du questionnaire, nous saisissons un nom explicite (ex: CA-LiveCampus) pour identifier notre autorité.
4.6. Signature de la demande provenant d’Ubuntu
Le serveur Ubuntu nous a envoyé un fichier vsftpd.csr. Nous allons maintenant lui donner une valeur officielle en le signant avec nos outils.
openssl x509 -req -in /tmp/vsftpd.csr \
-CA ca-root.crt -CAkey ca-root.key \
-CAcreateserial -out /tmp/vsftpd.crt \
-days 365 -sha256
4.7. Transfert et Validation finale
Pour terminer, nous utilisons la commande scp (Secure Copy) pour renvoyer les fichiers vers Ubuntu.
Nous renvoyons le certificat signé et le certificat de l’autorité
scp /tmp/vsftpd.crt utilisateur@IP_UBUNTU:/tmp/
scp ~/pki-autorite/ca-root.crt utilisateur@IP_UBUNTU:/tmp/
Nous vérifions une dernière fois que le certificat d’Ubuntu est bien reconnu par notre autorité :
openssl verify -CAfile ca-root.crt /tmp/vsftpd.crt
Si la console nous répond OK, notre chaîne de confiance est techniquement validée.
4.8. Bascule sur le serveur Ubuntu
4.8.1 Rangement des fichiers et sécurisation
Actuellement, les fichiers sont dans le dossier /tmp/. Nous devons les placer dans les dossiers systèmes officiels et restreindre les droits pour que seul l’administrateur puisse les lire.
# 1. Déplacement vers les dossiers officiels
sudo mv /tmp/vsftpd.crt /etc/ssl/certs/
sudo mv /tmp/ca-root.crt /etc/ssl/certs/
# 2. Application des droits de lecture (644 : tout le monde lit, seul root écrit)
sudo chmod 644 /etc/ssl/certs/vsftpd.crt
sudo chmod 644 /etc/ssl/certs/ca-root.crt
4.8.2 Configuration du serveur vsftpd
Nous allons maintenant dire à notre serveur FTP d’utiliser précisément ces fichiers pour chiffrer les connexions.
Ouvrez le fichier de configuration :
sudo nano /etc/vsftpd.conf
Modifiez ou ajoutez les lignes suivantes (attention à bien vérifier les chemins) :
# Désactivation du FTP non sécurisé pour les connexions locales
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
# Chemins vers les fichiers que nous venons d'importer
rsa_cert_file=/etc/ssl/certs/vsftpd.crt
rsa_private_key_file=/etc/ssl/private/vsftpd.key
ca_certs_file=/etc/ssl/certs/ca-root.crt
# Protocoles et sécurité (TLS 1.2 recommandé)
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH
Nous redémarrons le service pour prendre en compte les changements :
sudo systemctl restart vsftpd
4.9. Phase de Tests et Validation
Une fois la configuration appliquée, nous devons réaliser une série de tests rigoureux pour valider l’intégrité de notre infrastructure.
4.9.1. Vérification de la chaîne de confiance (Côté Serveur)
Avant toute tentative de connexion distante, nous validons que le certificat est correctement reconnu par le système Ubuntu.
openssl verify -CAfile /etc/ssl/certs/ca-root.crt /etc/ssl/certs/vsftpd.crt
Résultat attendu : La console doit retourner OK. Cela confirme que le certificat du serveur est bien signé par notre autorité Debian.
4.9.2. Test de connexion sécurisée avec FileZilla (Côté Client)
Nous utilisons le client FileZilla pour simuler l’accès d’un utilisateur.
Paramètres de connexion :
Hôte : ftpes://192.168.1.20192.168.1.20 (IP de votre serveur Ubuntu).
Protocole : FTP – Protocole de Transfert de Fichiers.
Chiffrement : Connexion FTP explicite sur TLS (Requis).
Validation du certificat :
Lors de la connexion, une fenêtre d’alerte apparaît. Nous vérifions que l’émetteur du certificat correspond bien à notre Autorité de Certification : CA-LiveCampus
Vérification du cadenas :
Une fois connecté, nous observons un petit cadenas en bas à droite de l’interface FileZilla, confirmant que le tunnel TLS est actif.
Pour finaliser la connexion, nous devons simplement dire à FileZilla que nous avons confiance en cette chaîne de certification :
Cochez la case « Toujours faire confiance à ce certificat lors des prochaines sessions ».
Cliquez sur le bouton OK.
Création d’un dossier
Puis regarder avec filezillia si il apparait bien
Dans notre fichier /etc/vsftpd.conf, nous avons activé une option cruciale pour la sécurité : chroot_local_user=YES.
Pourquoi vous ne pouvez pas sortir de votre dossier ?
Le mécanisme du Chroot : Cette directive « enferme » l’utilisateur dans son propre répertoire personnel (son Home). Pour l’utilisateur david, la racine / qu’il voit dans FileZilla correspond en réalité à /home/david/ sur le serveur Ubuntu.
L’objectif de sécurité : Nous faisons cela pour empêcher un utilisateur FTP de se balader dans l’arborescence système. S’il pouvait accéder à /etc/ssl ou /etc/shadow, il pourrait tenter de lire des fichiers de configuration sensibles ou des clés privées.
Isolation : Même si vous êtes administrateur (sudo) sur la machine en ligne de commande, le service FTP vous considère comme un simple utilisateur pour limiter les risques en cas de vol de vos identifiants.
Comment faire si vous devez accéder à d’autres fichiers ?
Si nous devons absolument transférer des fichiers situés dans /etc/ssl :
La méthode propre : Nous utilisons le terminal Ubuntu pour copier les fichiers cibles vers votre dossier personnel avant de les récupérer via FileZilla :
sudo cp /etc/ssl/certs/vsftpd.crt /home/david/
sudo chown david:david /home/david/vsftpd.crt
Alternative (Moins sécurisée) : Nous pourrions désactiver le chroot dans la configuration, mais cela affaiblirait considérablement la sécurité de votre infrastructure, ce qui n’est pas recommandé
4.9.3. Analyse de flux avec Wireshark (Preuve technique)
Pour prouver que les données ne circulent pas « en clair », nous réalisons une capture de paquets pendant un transfert de fichiers.
Observation : Dans Wireshark, les paquets ne sont plus marqués comme « FTP » mais comme TLSv1.2 ou Application Data.
Analyse : Si nous tentons de reconstruire le flux TCP (Follow TCP Stream), les identifiants et le contenu des fichiers sont totalement illisibles.
4.9.4. Installation et configuration de l’IDS snort et Test de l’IDS Snort (Détection d’Intrusion)
Comme nous l’avons vu, il a fallu compiler manuellement Snort et certaines de ses dépendances car, sur Debian 13, les paquets officiels étaient soit introuvables, soit incompatibles avec les versions modernes des bibliothèques système.
- Préparation de l’environnement (Dépendances) Ces commandes ont permis de résoudre les conflits liés à l’absence de bibliothèques anciennes sur Debian 13.
Installation des outils de compilation et RPC :
sudo apt update && sudo apt install -y build-essential libpcap-dev libdumbnet-dev bison flex zlib1g-dev liblzma-dev libtirpc-dev
Compilation manuelle de PCRE (Version 8.45) :
cd /tmp
wget [https://sourceforge.net/projects/pcre/files/pcre/8.45/pcre-8.45.tar.gz](https://sourceforge.net/projects/pcre/files/pcre/8.45/pcre-8.45.tar.gz)
tar -xvzf pcre-8.45.tar.gz && cd pcre-8.45
./configure --prefix=/usr --disable-static
make && sudo make install
- Compilation et Installation de Snort 2.9.20 Configuration du moteur en injectant les chemins spécifiques à Debian 13.
Configuration :
cd /tmp/snort-2.9.20
export CFLAGS="-I/usr/include/tirpc"
LDFLAGS="-L/usr/lib" ./configure --enable-sourcefire --disable-open-appid
Installation :
make && sudo make install
sudo ldconfig
- Création de l’arborescence système Snort compilé manuellement nécessite la création de ses propres dossiers de travail.
Répertoires de configuration et de règles :
sudo mkdir -p /etc/snort/rules
sudo mkdir -p /etc/snort/preproc_rules
Répertoires de logs et de bibliothèques :
sudo mkdir -p /var/log/snort
sudo mkdir -p /usr/local/lib/snort_dynamicrules
Copie des fichiers de configuration de base :
cd /tmp/snort-2.9.20/etc
sudo cp *.conf *.map *.dtd /etc/snort/
sudo cp classification.config reference.config /etc/snort/
- Configuration des règles et du service Modification du fichier principal pour l’adapter à ton réseau.
Création de la règle de détection SSH :
sudo nano /etc/snort/rules/local.rules
(Ajouter la ligne suivante) :
alert tcp any any -> any 22 (msg:"[ALERTE] Tentative de Force Brute SSH"; content:"SSH-2.0"; threshold:type both, track by_src, count 5, seconds 60; sid:1000002; rev:1;)
Création des fichiers de listes (vides) :
sudo touch /etc/snort/rules/white_list.rules /etc/snort/rules/black_list.rules
Modification de snort.conf :
sudo nano /etc/snort/snort.conf
Remplacer les var RULE_PATH ../rules par var RULE_PATH /etc/snort/rules (et ainsi de suite pour les chemins absolus).
Commenter avec un # toutes les inclusions de règles inutiles sauf include $RULE_PATH/local.rules.
- Exécution et Analyse des résultats
Test de validité de la configuration :
sudo snort -T -c /etc/snort/snort.conf
Lancement de la surveillance en temps réel :
sudo snort -A console -q -c /etc/snort/snort.conf -i ens33
Lecture et analyse forensique des logs binaires :
cd /var/log/snort
sudo snort -dv -r snort.log.XXXXXXXXXX
5. Sécurisation du SI
Application des mesures de sécurité sur toutes les couches du modèle OSI :
Couche physique : Isolation des équipements, accès restreints.
Couche réseau : Filtrage des flux (pare-feu), segmentation (VLANs), chiffrement (VPN IPsec).
Couche transport : Chiffrement des données en transit (TLS 1.3 pour le FTP, SSL pour les certificats). Durcissement de SSH.
Couche application : Mises à jour régulières, désactivation des services inutiles, configuration sécurisée des services exposés (FTP, AD).
Couche données : Chiffrement des données au repos (LUKS), sauvegardes automatiques et externalisées (cloud privé souverain).
Couche utilisateur : Authentification forte (MFA pour les accès sensibles), gestion des droits via l’AD.
Surveillance : Détection d’intrusions (SNORT), logs centralisés, alertes en cas d’anomalie. Scazn réseau avec OpenVAS
| Couche | Mesure | Outils/Exemples |
|---|---|---|
| Physique | Accès restreint aux serveurs (badges, journalisation) | Badges RFID, caméras |
| Réseau | filtrage pare feu, segmentation VLAN avec des ACL sur les switchs | Cisco ACL, VLAN |
| Transport | Chiffrement TLS 1.3 pour tous les services exposés | OpenSSL, Certificats |
| Application | WAF (Web Application Firewall) | HTTPS |
| Données | Chiffrement des données au repos (LUKS pour les disques) | cryptsetup luksFormat |
| Authentification | LDAPSécurisé, MFA pour les accès sensibles | LDAPS, WireGuard, Serveur de mot de passes |
| Surveillance | Trafic analysé et filtré, détection et alertes, scan vulnérabilité | Pare feu, SNORT, OpenVAS |
| Sauvegarde | 3-2-1 Rule : 3 copies, 2 supports différents, 1 hors site | BorgBackup |
| Tests | Pentest régulier, test de restauration, éteudes CVE | Metasploit, PCA/PRA, Audits |
5.1 Pare-feu et Isolation des VLAN
L’implémentation d’un pare-feu central par site est essentielle pour contrôler et filtrer tous les flux réseau (inter-VLANs et vers Internet) en appliquant le principe du moindre privilège, garantissant ainsi une isolation stricte des services sensibles (FTP, CA, AD) et une protection contre les accès non autorisés. Cette approche complète les IDS (SNORT) déployés sur les serveurs FTP et CA, qui se concentrent sur la détection des intrusions au niveau des machines critiques.
- Règles d’Isolation des VLANs (Site 1)
| Source | Destination | Protocole/Port | Action | Justification |
|---|---|---|---|---|
| VLAN 30 (Clients) | VLAN 10 (FTP) | TCP 21, 990 | ACCEPT | Accès FTP sécurisé (SSL/TLS) |
| VLAN 30 (Clients) | VLAN 20 (CA) | TCP 2222 | ACCEPT | Admin uniquement (SSH + MFA) |
| VLAN 30 (Clients) | VLAN 40 (AD/OpenVAS) | TCP 636 | ACCEPT | Authentification LDAP/LDAPS |
| VLAN 10 (FTP) | VLAN 20 (CA) | TCP 80, 443 | ACCEPT | Récupération des certificats (HTTP/HTTPS) |
| VLAN 10/20/30 | VLAN 40 (AD) | TCP 636 | ACCEPT | Vérification des identités (LDAPS) |
| Tout autre trafic | Entre VLANs | Tous | DROP | Isolation stricte |
- Règles pour l’Accès Internet (VLAN 30 uniquement)
| Source | Destination | Protocole/Port | Action | Justification |
|---|---|---|---|---|
| VLAN 30 | Internet | TCP 80, 443 | ACCEPT | Navigation web (HTTP/HTTPS) |
| VLAN 30 | Internet | TCP/UDP 53 | ACCEPT | Résolution DNS (chiffré si possible) |
| VLAN 30 | Internet | TCP 465, 587 | ACCEPT | Envoi d’emails (SMTPS) |
| VLAN 30 | Internet | Autres ports | DROP | Blocage par défaut |
- Règles pour le VPN IPsec (Entre PF1 et PF2)
| Source | Destination | Protocole/Port | Action | Justification |
|---|---|---|---|---|
| PF1 | PF2 | UDP 500, 4500 | ACCEPT | Échange de clés IKE (VPN IPsec) |
| PF2 | PF1 | UDP 500, 4500 | ACCEPT | Symétrique |
5.2 VPN IPsec
Ce protocole permet un chiffrement (encryption aes) de tout le trafic qui transit dans le tunnel VPN. Il existe des protocoles de chiffrements plus peerformants, mais ils n’ont pas été retenus ici en raison de compatibilités matérielles (en réalité compatibilité CPT).
5.3 Détection d’Intrusions (SNORT)
Exemples de règles pertinantes à intégrer à SNORT
- Définir les variables dans /etc/snort/snort.conf :
var FTP_SERVER 172.16.10.10/24 var CA_SERVER 172.16.20.20/24 var AD_SERVER 172.16.40.30/24
- Détecter plus de 5 tentatives de connexion FTPS échouées en 1 minute depuis une même IP.
Règle : alert tcp any any -> $FTP_SERVER 990 (msg: »Tentative de brute-force FTPS »; flow:to_server,established; content: »USER »; nocase; pcre: »/^USER\s+\w+\r\n/ »; threshold:type threshold, track by_src, count 5, seconds 60; sid:1000001; rev:1;)
Explications :
$FTP_SERVER : Variable à définir dans /etc/snort/snort.conf (ex : var FTP_SERVER 172.16.10.20). content: »USER » : Détecte les commandes USER (identifiant) dans le trafic FTP. threshold : Déclenche une alerte après 5 tentatives en 60 secondes depuis la même IP.
- Détection de Scans de Ports (Nmap) sur les Serveurs Scénario : Détecter les scans SYN (typiques de nmap -sS) sur tes serveurs.
Règle : alert tcp any any -> $HOME_NET any (msg: »Scan SYN détecté (Nmap) »; flags:S; ack:0; threshold:type threshold, track by_src, count 20, seconds 10; sid:1000002; rev:1;)
Explications :
flags:S; ack:0 : Détecte les paquets SYN sans ACK (caractéristiques d’un scan SYN). count 20 : Alerte après 20 paquets SYN en 10 secondes (seuil ajustable). $HOME_NET : Variable définissant le réseau interne
- Détecter une tentative d’exploitation d’une vulnérabilité connue (ex : buffer overflow dans vsftpd).
Règle : alert tcp any any -> $FTP_SERVER 990 (msg: »Tentative d’exploitation FTP (CVE-2021-21341) »; flow:to_server,established; content: »USER « ; depth:5; content: ») »; within:10; pcre: »/USER\s+[^\r\n]{200,}/ »; sid:1000003; rev:1;)
Explications :
content: »USER » + pcre : Détecte une commande USER anormalement longue (potentiel overflow). within:10 : Vérifie que le motif apparaît dans les 10 octets suivants.
- Détection de Trafic Suspect vers le Serveur CA en SSH (VLAN 20)
Règle : alert tcp any any -> $CA_SERVER 2222 (msg: »Tentative de brute-force SSH sur la CA »; flow:to_server,established; content: »root »; nocase; threshold:type threshold, track by_src, count 3, seconds 30; sid:1000004; rev:1;)
Explications :
content: »root » : Détecte les tentatives de connexion avec l’utilisateur root (à éviter sur une CA). count 3 : Alerte après 3 tentatives en 30 secondes.
Enfin, l’idéal serait ensuite d’automatiser les réaction pour gagner en réactivité (exemple : scripts pour bloquer des IP suite à une alerte).
5.4 Scanner de vulnérabilité OpenVAS
Dans cette évaluation, par manque de temps, nous allons utiliser OPENVAS avec une machine metasploitable 2 qui est une machine virtuelle vulnérable à certaines attaques, ce qui en fait un très bon exemple pour montrer comment fonctionne OPENVAS
5.4.1 Initier un scan
Pour cela nous devons aller sur l’interface d’OPENVAS. Aller dans Scans puis Tasks. Ensuite nous devons créer une tâche afin de faire notre premier test de vulnérabilité sur la machine metasploitable. Nous cliquons sur la petite baguette magique puis Task Wizard. A partir de là nous rentrons l’adresse ip de la machine à auditer. Dans notre cas cela sera 192.168.1.24 Il suffit juste de cliquer sur le bouton « Start Scan »
Notre scan est pour l’instant en mode « Queued » ce qui signifie que le système à bien reçu l’ordre du scan mais il ne peut pas se lancer immédiatement pour plusieurs raisons :
- Synchronisation des feeds (NVT, SCAP)
- Ressources occupées
- Limite de scans simultanés
Synchronisation des feeds
Mode Running : Le scan va prendre plus ou moins de temps, cela peut dépendre aussi de la vitesse de la connexion réseau. Si on se réfère à l’infra de SecureDev cela pourrait prendre du temps étant donné qu’on passe par le VPN IPSEC notamment à cause de la surchage au niveau de l’encapsulation des données.
Une fois le scan terminé, nous pouvons nous rendre dans l’onglet « Reports » afin de voir le résultat du scan. Voici ce que ça explique :
- Un score global de 10.0 (Critical) qui siginifie que c’est la note maximale sur l’échelle CVSS. OpenVAS à trouvé au moins une faille qui permet de prendre le contrôle total de la machine à distance, sans aucune authentification
Voici la répartition des trouvailles
- Critical (Rouge) : 11. Ce sont les failles prioritaires. Elles permettent généralement une exécution de code à distance (RCE)
- High (Rose): 11. Ce sont des failles graves qui peuvent mener à un vol de données ou une compromission partielle
- Medium (Orange) : 40. Ce sont des failles qui nécessitent souvent des conditions spécifiques pour être exploitées mais qui reste cependant dangeureuse si on ne les patch pas.
- Low (Bleu) 6. Ce sont des failles mineures ou des fuites d’informations simples
- Log (Gris): 92. Ce ne sont pas des failles mais justes des informations sur les services ouverts (ex: Détection d’un serveur apache).
Nous pouvons aussi nous rendre dans l’onglet « Results » qui permet de voir toutes les vulnérabilités de la machine.
5.4.2 Scanner tout un SI (SecureDev)
Ce scan à été fait sur une seule machine. Mais si nous devions scanner tout un SI. Voici comment on procéderai (Ex: SecureDev)
Création d’une nouvelle tâche
Dans la partie « Scan Targets » on clique sur le petit [+] afin d’ajouter notre cible. Pour nous ce sera 172.16.0.0/16 qui contiendrat tous les VLANs et on exclus la machine OPENVAS elle-même pour éviter qu’elle se scanne elle-même. Ensuite on laisse les autres options par défaut puis on peut faire « save ».
A partir de là, la nouvelle tâche s’est bien ajoutée, on a plus qu’a cliquer sur le bouton pour démarrer le scan
5.4.3 Conclusion OPENVAS
En conclusion pour cette partie, OPENVAS n’est pas juste un simple outil de scan mais représente toute la stratégie de cyber-résilience de l’infrastructure de SecureDev SARL. Grâce aux tâches qui peuvent être planifiés, cela représente le Maintien en Condition de Sécurité (MCS) car grâce à ça, le SI bénificie d’une visibilité sur ses vulnérabilités.
6. Conclusion et Améliorations Possibles
Ce projet réalisé pour SecureDev SARL a permis de concevoir, déployer et sécuriser une infrastructure réseau multi-sites, adaptée aux besoins d’une PME développant des logiciels sur des sujets sensibles. En partant d’un schéma d’architecture initial, nous avons pu structurer un environnement robuste, intégrant des mécanismes de sécurité sur toutes les couches du système d’information
Perspectives d’Amélioration
- Redondance :
En production, une redondance active/passive serait mise en place avec Keepalived pour les serveurs critiques, mais cela dépasse le cadre temporel du projet. Un serveur FTP de secours (VLAN 10). Un serveur AD/OpenVAS de secours (VLAN 40).
- Chiffrement des connexions AD et FTP
Forcer LDAPS plutôt que LDAP pour refuser les connexions non chiffrées, et encapsuler les connexions FTP en FTPS (ou SFTP via SSH)
- Supervision et logs
Créer un VLAN de supervision, avec des solution comme Prometheus + Grafana et avec un serveur de centralisation des logs
- Sauvegardes
Mettre en place un réseau segmenté critique (SFTP, chiffrement, accès uniquement admin)
- DMZ
reverse proxy ou bastion pour sécuriser les accès entrants via internet
- Sécurisation du DNS
Configurer un serveur DNS local (ex : Unbound) pour pour chiffrer les requêtes via DNS-over-TLS (DoT).
- Ajout d’un SIEM (ex : Wazuh ou ELK Stack) pour une corrélation avancée des logs et une détection proactive des menaces.