Analyse de sécurité - bpatureau/admin-2-TP GitHub Wiki

Auteurs : Maxime, Bastien, Guillaume

1. Identification des biens à protéger

1.1 Schéma réseau

1.2 Texte explicatif du schéma réseau

Notre infrastructure contient 3 vps fournis au préalable :

srv-dns : Ce serveur vps fait tourner un seul container qui héberge un serveur bind9. Celui-ci s'occupe du dns. Il contient donc un fichier named.conf disponible ici et un fichier l1-2.zone disponible ici. Il permet de déservir la zone l1-2.ephec-ti.be. Le port 53/UDP et 53/TCP du container et redirigé vers le port 51515 du vps pour pouvoir contacter l'extérieur. Le parefeu laisse passer les port 53/UDP, 53/TCP et 51515.
srv-web : Ce vps possède 3 containers qui tournent en même temps. Le premier héberge un serveur Nginx sans données sensibles. Le second héberge un serveur PHP qui fait le lien entre la DB et le serveur Nginx et enfin, le troisième héberge un serveur mariaDB et contient une base de donnée SQL. Seul le docker Nginx possède un port ouvert, le port 8080/TCP. Il est relié au serveur PHP par un réseau qui constitue la DMZ. Le serveur PHP est également connecté via un autre réseau au serveur mariaDB pour ne pas l'exposer à la DMZ. Le port 8080 du vps est donc aussi ouvert.
srv-mail : Ce VPS est dédié à l'hébergement sécurisé d’un service mail complet. Il repose sur un container unique basé sur l'image docker-mailserver, qui regroupe les composants nécessaires à l’envoi, à la réception et à la sécurisation des emails. Voici les éléments clés de cette infrastructure. La configuration du serveur est gérée par 2 fichiers principaux : mailserver.env et docker-compose.yaml. Le service est équipé d'un chiffrement TLS/SSL ce qui permet de garantir la confidentialité. Les ports ouverts sont les suivants : 25/TCP (SMTP), 465/TCP (SMTPS), 587/TCP (Submission), 993/TCP (IMAPS).

1.3 Liste des biens à protéger

Physiques

Nos 3 VPS hébergés chez OVH

Logiques

Parefeu (ufw)
Docker (containers)
Fichiers de configs
Bind9
Zone DNS
Clés de sécurités (SSH, DNSSEC, DKIM)
La base de données (mariaDB)
Le serveur PHP
Le serveur Nginx
Le serveur mailserver

Immatériels

Employés de woodytoys
Réputation de l'entreprise

2. Lister les vulnérabilités et menaces pesant sur ces biens

VPS

Confidentialité :

Nos VPS, s'ils ne sont pas correctement sécurisés, sont vulnérables aux accès non autorisés. Physiquement aussi.
Menace : attaques brute force visant les mots de passe, accès physique non autorisé, compromission de l'accès root.

Intégrité :

Le manque de mise à jour OS, des erreurs de configuration ou l'installation de logiciels douteux peut entraîner des compromissions.
Menace : malwares.

Disponibilité :

Nous sommes vulnérables aux pannes du côté d’OVH ou à des attaques réseau.
Menace : attaques DDoS, pannes matérielles.

Pare-feu

Confidentialité :

Une mauvaise configuration des ports peut exposer nos services inutilement.
Menace : scans de ports.

Intégrité :

En cas de compromission du VPS, un attaquant pourrait modifier les règles du pare-feu.
Menace : escalade de privilèges et désactivation du pare-feu.

Docker

Intégrité :

L’utilisation d’images compromises ou non mise à jour peut introduire des logiciels malveillants.
Menace : malwares.

Disponibilité :

L’utilisation d’images excessivement lourdes pourrait saturer l’espace de stockage.
Menace : saturation des ressources et interruption des services.

Fichiers de configs

Confidentialité :

Des mots de passe en clair ou des permissions trop ouvertes pourraient exposer des données sensibles.
Menace : compromission d’informations critiques.

Disponibilité :

Une mauvaise configuration peut entraîner des crashs ou une indisponibilité de service.
Menace : interruption du service.

Bind9 (DNS)

Intégrité :

Si un attaquant accède au serveur DNS et change les RR ou qu'un attaquant intercepte les requêtes pour les modifier, il pourrait rediriger les clients vers son site malveillant.
Menace : modification de RR, redirection DNS, DNS cache poisoning.

Confidentialité :

Eviter que des informations sensibles ne soit accèsibles grâce à des requêtes malveillantes.
Menaces : Requêtes DNS malveillantes, interception de requêtes.

Disponibilité :

Le service DNS peut être affecté par des configurations incorrectes ou des attaques.
Menace : attaque DDoS.

Zone DNS

Confidentialité :

Des informations techniques visibles peuvent faciliter une reconnaissance préalable à une attaque.
Menace : cartographie du réseau.

Disponibilité :

Des erreurs dans la zone DNS peuvent provoquer une coupure des services.
Menace : interruption du service.

Clés de sécurité (SSH, DNSSEC, DKIM)

Confidentialité :

Un stockage non chiffré ou un partage non sécurisé des clés pourrait permettre un accès non autorisé.
Menace : vol d'identité, accès non autorisé.

Disponibilité :

Des clés expirées ou corrompues peuvent entraîner une perte d’accès aux services.
Menace : défaillance d’authentification ou de signature DKIM.

Serveurs web (Nginx, PHP, MariaDB)

Des failles systèmes peuvent provenir de n'importe lesquel de ces trois serveur, par exemple à cause d'un système non mis à jour, manque de système de sécurités, ports inutilements ouverts

Confidentialité :

Ces failles si elle compromettent la DB, pourraient leaker des données sensibles sur les clients. Il faut aussi faire attention à la communication entre le serveur et les clients il pourrait y avoir des interceptions de données. Menace : Fuite de données clients sensibles, interception de données.

Intégrité :

Elle peuvent aussi menacer l'intégrité des données si celle-ci disparaissent soit à cause d'attaques soit à cause de malwares soit à cause de systèmes défectueux. Menace : faille de sécurité, perte de données.

Disponibilité :

Les failles peuvent aussi laisser passer des attaques de déni de service. Menace : DDoS.

Mail

Confidentialité :

Il faut faire attention à la communication entre les clients et le serveur, des attaquant pourraient intercepter des mails. Les attaquant peuvent aussi envoyer de mails frauduleux. Menace : Interception de données, phishing.

Intégrité :

Il faut être sur que les données utilisées par les clients provenant du mail proviennet bien de chez nous. Sinon le client peut se retrouver avec des information provenant de serveurs malveillants immitants nos services. Menace : Usurpation de serveur.

Disponibilité :

Il est important de faire attention aux spams car ceux-ci peuvent rendre compliqué aux clients la consultation de leurs mail. Menace : Spams.

Employés de Woodytoys

Confidentialité :

Les employés sont vulnérables au phishing et à l'ingénierie sociale.
Menace : vol de mots de passe, phishing.

Intégrité :

Des erreurs humaines peuvent entraîner des modifications ou suppressions de fichiers.
Menace : altération des données.

Disponibilité :

Départs, maladies ou surcharge de travail peuvent affecter la continuité du service.
Menace : indisponibilité humaine.

Réputation de l'entreprise

Confidentialité :

Une fuite de données clients ou critiques peut nuire à la confiance des utilisateurs.
Menace : perte de réputation, poursuites judiciaires.

Disponibilité :

L’indisponibilité des services ou un manque de réactivité nuit à l’image de l’entreprise.
Menace : perte de clients, mauvaise presse.

3. Evaluer les risques

Menace	Probabilité	Impact	Estimation du risque	Contre-mesure
Brute force sur les mots de passe	Moyenne	Fort	Élevé	Authentification par paires de clés, mots de passe forts, limitation des tentatives
Accès non autorisé au VPS	Fort si pas sécurisé	Fort	Élevé	Sécurisation de l'accès SSH, limitation du nombre de ports ouverts
Malwares	Faible	Fort	Moyen	Formation des employés, antivirus, vérification des sources des images Docker
Déni de service	Myoen	Faible (si services non critiques)	Faible	Fail2ban, pare-feu
Scans de ports	Moyenne	Faible (si configuration correcte)	Faible	Fail2ban, modification du port d'écoute SSH, parefeu
Escalade de privilèges	Moyen	Fort	Élevé	Mise en place de users avec une politique du moindre privilège
Indisponibilité des services	Moyen	Fort ( en fonction du service visé )	Élevé	Redondance, docker swarm, dns secondaire
Fuite de données	Moyen	Fort	Élevé	Chiffrement
Panne matérielle	Faible	Fort	Moyen	Backups
Requêtes DNS malveillantes	Moyenne	Faible (fuite d’IP, logs, etc.)	Faible	Intégrité des données DNS, autantification des RR (DNSSEC)
Redirection DNS (DNS cache poisoning)	Faible	Moyen (impact client, redirection malveillante)	Faible	Chaînes de confiances (DNSSEC)
Failles de sécurité	Faible	Fort	Moyen	Hardening des serveur
Phishing	Moyenne	Fort	Elevé	Sensibilisation, filtres
Spams	Forte	Moyen (fort sur le client)	Elevé	Filtres anti-spam, configuration mail correcte
Usurpation de serveur	Faible	Forte	Moyen	Authentification du service
Indisponibilité humaine	Faible	Moyen	Faible	Documentation, redondance des rôles, gestion RH
Perte de réputation	Faible	Moyen à fort (dépend du type de fuite ou incident)	Moyen	Contrôle de la communication, sécurité des données, journalisation
Perte de clients	Faible	Moyen à fort (en cas d’indisponibilité ou fuite)	Moyen	Haute disponibilité, transparence, sécurisation des services
Intrusion physique dans la salle des serveurs	Moyen	Fort	Élevé	Systèmes de sécurités physiques

4. Choisir et mettre en oeuvre des contre-mesures pour contrer les risques

4.1 Liste de contre mesures urgentes à mettre en place

Authentification par clé SSH
Limitation des tentatives (Fail2ban)
Users et politique du moindre privilège
Parefeu
Redondance, docker swarm, dns secondaire
Chiffrement (web, mail)
Hardening des serveurs (pour le web)
Authentification des services (DNS, Mail)
Systèmes de sécurités physiques

4.2 Liste des contre mesures choisies en fonction du temps et du budget

Mesures déjà mises en place :

Authentification par clé SSH
Limitation des tentatives (Fail2ban)
Users et politique du moindre privilège
Parefeu
Chiffrement (web, mail)
Hardening des serveurs (pour le web)
Authentification des services (DNS, Mail)

4.3 Détails des contre mesures mise en place

Authentification par clé SSH

Afin d'empêcher tout accès non autorisé à nos services, nous avons configuré l'accès SSH à nos VPS uniquement via des paires de clés (publique/privée). Pour valider cette configuration, nous avons tenté une connexion SSH sans utiliser de clé. Comme le montre la capture d'écran ci-dessous, l'accès est effectivement refusé :

Fail2ban

Fail2ban permet de bannir des adresses IP après un trop grand nombre de tentatives de connexion échouées. Cette solution est particulièrement efficace contre les attaques par brute force ou les scans automatisés de ports.

Dans la configuration suivante (mise en place sur nos VPS), les IP qui tentent de se connecter trop fréquemment en SSH sont bannies automatiquement :

[DEFAULT]
bantime = 15m
maxretry = 5
enabled = false

[sshd]
enabled = true
port = 51515
logpath = /var/log/auth.log
filter = sshd
maxretry = 4
findtime = 30m
bantime  = 1h
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 24h

sudo fail2ban-client status sshd

Nous suivons également les bannissements via le fichier /var/log/auth.log. Tous les services exposés sur les VPS sont protégés par Fail2ban. Par exemple, le service web est protégé sur le VPS srv-www.

Parefeu

Le pare-feu est une barrière essentielle entre notre infrastructure et Internet. Étant donné que n'importe quoi peut provenir d'internet, il est impératif de limiter rigoureusement les connexions entrantes.

Nous appliquons une politique par défaut restrictive : tout est bloqué sauf ce qui est explicitement autorisé. Par exemple, sur le serveur DNS (srv-dns), seuls les ports suivants sont ouverts :

51515 pour SSH
53/UDP et 53/TCP pour le DNS Pour le parefeu sur le srv-dns par exemple, nous utilisons ufw.

Politique du moindre privilège

Pour prévenir toute escalade de privilèges, nous appliquons la politique du moindre privilège, qui consiste à attribuer à chaque utilisateur uniquement les droits nécessaires à l'exécution de ses tâches.

Par exemple, sur le VPS srv-dns :

L'utilisateur maxime ne possède que les droits de base (users).
L'utilisateur dns, protégé par un mot de passe, fait partie des groupes docker et users.

Un compte administrateur admin, appartenant au groupe sudo, a été mis en place. Étant donné ses privilèges étendus, il est impératif qu’il soit fortement sécurisé, ce que nous avons fait avec un mot de passe sophistiqué :

Chiffrement des données

Il est essentiel de chiffrer les données sensibles qui transitent entre nos serveur et les clients pour éviter qu'une personne malveillante puisse intercepter ces informations. Nous avons identifié deux transfères de données sensible : les échanges clients-DB et les échanges mails.

Web : Pour sécuriser les communications web, nous avons mis en place HTTPS grâce à OpenSSL, un certificat auto-signé pour notre site.
Mail : Nous avons chiffré les échanges mail grâce à TLS qui a été activé pour SMTP et IMAP.

Hardening des serveurs web

Notre architechture web est composée de 3 serveurs (Nginx, PHP, mariaDB) ces 3 serveurs font des choses diffèrentes. Etant donné que ces services sont nombreux, une faille de sécurité peut arriver plus vite. Aussi, la DB doit être protégées car elle contient des toutes nos données des clients de notre site.

Pour faire tout cela nous avons mis en place une DMZ, zone depuis laquel internet à accès, seul le serveur distribuant les pages web et PHP sont accèsibles depuis cette zone. La DB elle, se situe dans une zone isolée de cela et sécurisée (DB_net) nginx n'a pas accès directement à cette zone.

En plus de tout cela, nous nous assuront d'utiliser des versions d'images docker connue et mise à jour, les OS, le parefeu sont également tenus à jour.

Authentification des services

Nos services sont accèsibles pour nos clients mais de base, rien ne prouve leur validité. Une personne mal intentionnée pourrait alors se faire passer pour nous, par exemple avec un service DNS usurpant le notre, il pourrait rediriger les clients vers son site frauduleux. Pour remider à cela, nous avons authentifiés nos services sensible, le DNS et le mail.

DNS : Nous authentifions le DNS grâce au DNSSEC, il permet de fournir, pour chaque Resource Record de la zone, une signature cryptographique (RRSIG) qui confirme grâce à une chaine de confiance, la validité de nos RR.
Mail : pour le mail, l'utilité de l'authantification est plus axé pour la lutte contre le spam. Nous avons mis en place ceci grâce à un alignement des records MX-PTR-A, SPF, DKIM et DMARK. (plus d'info sur notre wiki dédié au mail)

5. Prévoir les risques résiduels et organiser la réaction en cas d’incident (détection, réaction et récupération)

Même si nous avons mis en place plusieurs contre-mesures pour prévenir les attaques, il reste possible que certaines menaces parviennent à compromettre notre infrastructure. Cela peut être dû à des vulnérabilités non contrées soit involontairement ou par faute de moyens/temps. Ou à l’exploitation de failles inconnues (zero-day). Il est donc essentiel de se préparer à ces situations en définissant un plan de détection, de réaction et de récupération en cas d'incident.

5.1 Détection d’attaque

Attaque sur la disponibilité

Pour détecter les interruptions de service, nous pouvons mettre en place une solution de supervision (comme un site externe ou un outil comme Zabbix) qui surveille en continu la disponibilité de nos services et envoie des alertes en cas de panne ou de réponse anormale.

Attaque d'intrusion

Pour repérer une intrusion ou un comportement suspect, nous pourrions nous appuyer sur des outils de logs comme Syslog. Ces derniers peuvent être configurés pour détecter et remonter :

Des tentatives de connexions SSH suspectes
La création ou la suppression d’utilisateurs
Des modifications de fichiers critiques (configuration, fichiers système sensibles)
Des ouvertures de ports inattendus

Tentatives d'attaques

Les attaques ne réussissent pas toujours du premier coup. Il est donc utile de repérer les tentatives d'attaques ou de reconnaissance, car elles indiquent souvent une phase préparatoire à une attaque.

Pour cela, plusieurs approches sont possibles :

Analyse des logs (ex : logs de notre Fail2ban, logs du pare-feu)
Mise en place de honeypots pour détecter des comportements malveillants

5.2 Réaction face à une attaque

Lorsqu’une attaque est détectée, il est essentiel de réagir rapidement et méthodiquement afin de limiter les dégâts, contenir la menace et éviter toute propagation. La réactivité est un facteur clé pour protéger les données, maintenir la confiance des utilisateurs et réduire l’impact global de l’incident.

Identifier la nature de l’attaque

Dans un premier temps, il est primordial de comprendre ce que l’attaque cible, d’identifier quels systèmes ou services sont compromis, et de déterminer ceux qui restent intègres. Cela permet de prioriser les actions à mener et d’éviter des décisions précipitées.

Contenir l’attaque

Une fois les systèmes touchés identifiés, il faut immédiatement mettre en place des mesures de confinement pour empêcher toute propagation. Voici quelques actions possibles :

Déconnecter les machines compromises du réseau.
Bloquer les ports utilisés par l’attaquant (via le pare-feu).
Appliquer temporairement des règles réseau (firewall) pour isoler les segments touchés.
Ajouter des règles à des outils comme Fail2ban pour bloquer les adresses IP malveillantes identifiées.

5.3 Reprise des services après une attaque

Une fois l’attaque contenue, il est nécessaire de restaurer les services affectés, tout en s’assurant que la vulnérabilité exploitée a bien été corrigée.

Correction de la faille

Avant de remettre en ligne un service compromis, il est indispensable d’avoir corrigé la faille utilisée par l’attaquant. Cette étape repose sur une analyse approfondie de l’incident. Exemples de correctifs possibles :

Mise à jour de l’OS ou des logiciels vulnérables tel qu'une image docker.
Renforcement de la configuration de sécurité.
Modification des mots de passe ou des clés SSH.
Fermeture ou restriction de ports inutiles ou mal protégés.

Restauration depuis les sauvegardes

Une fois la faille comblée, les services peuvent être restaurés à partir des sauvegardes. Pour cela, il est essentiel d’avoir mis en place une politique de sauvegarde efficace, incluant :

Les fichiers de configuration (pare-feu, Fail2ban, DNS, Apache/Nginx, Postfix, etc.).
Les données (contenu des sites web, bases de données, fichiers utilisateurs).
Les images ou volumes des conteneurs Docker.
Les fichiers d’infrastructure (Dockerfile, docker-compose).

Ces sauvegardes permettent de remettre en route rapidement les services, de façon propre et sécurisée.

Recovery Point Objective (RPO)

Voici la quantité de données que nous pouvons nous permettre de perdre en cas d’incident. Etant donné la nature de notre infrastructure, nous pourions tolérer une perte de jusqu’à 5 heure de données si nous faisions des sauvegardes régulièrement (ex : toutes les 5 heures).

Recovery Time Objective (RTO)

Voci le temps maximal que nous estimons acceptable pour restaurer un service après un incident. Étant une petite infrastructure, un délai de 24 heures pour un retour à la normale est acceptable. Ce délai est cohérent avec les personnes disponibles et la taille modérée de nos infrastructures à restaurer.

6. Évaluer et maintenir les contre-mesures

La sécurité informatique est un domaine en constante évolution, où de nouvelles menaces apparaissent régulièrement. Il est donc essentiel d’adopter une démarche d’amélioration continue pour garantir une protection efficace et durable.

6.1 Mises à niveau

Il est important de remettre régulièrement en question les procédures et les configurations en place pour s’assurer qu’elles restent adaptées aux risques actuels. Cela inclut la mise à jour fréquente des différents composants du système, tels que les images Docker, les systèmes d’exploitation, les règles du pare-feu, ou encore les outils de sécurité comme Fail2ban.

6.2 Vérification des systèmes

Les systèmes doivent faire l’objet de contrôles réguliers pour garantir leur bon fonctionnement. Cela concerne notamment :

les sauvegardes (s’assurer qu’elles sont à jour, valides et restaurables),
les services (s’assurer qu’ils tournent comme prévu),
les règles de sécurité (vérifier qu’elles sont bien appliquées).

6.3 Suivis des actualités de sécurité

Il est essentiel d’effectuer une veille technologique pour se tenir informé des nouvelles vulnérabilités, techniques d’attaque ou failles critiques. Cette veille permet d’adapter rapidement les contre-mesures et de réagir avant qu’une faille ne soit exploitée.

6.4 Suivi de l’évolution de l’entreprise

Les besoins en sécurité doivent évoluer en parallèle avec la croissance de l’entreprise. Par exemple, une augmentation soudaine du nombre d’utilisateurs ou de services peut exiger des capacités d’infrastructure plus robustes, une meilleure tolérance aux pannes ou une révision des règles de sécurité pour éviter les goulets d’étranglement ou les zones d’ombre.

Note d'utilisation d'IA

Maxime : j'ai utilisé l'IA uniquement pour repasser sur mes textes (corriger les fautes la grammaire et la tournure des phrases). Le reste des informations ont été piochées dans le cours où sur internet.