Analyse de sécurité : l1‐1
Cette analyse de sécurité porte sur le sous-domaine l1-1.ephec-ti.be du groupe 1 de la classe L1 du cours T206 - Administration Systèmes et Réseaux II.
| Nom | Pseudo Github |
|---|---|
| HUYBRECHTS Louis | Nini1551 |
| TROONBEECKX Hugo | hugotnbx |
| VERBIEST Mateo | Correba |
Le serveur de nom est hébergé sur un VPS du fournisseur OVH fourni dans le cadre du cours T206 - Administration Systèmes et Réseaux II à VERBIEST Mateo.
Adresse IP : 54.37.8.13
Nom du VPS : vps-0b7ac9ac.vps.ovh.net
Le sous-domaine DNS à sécuriser est l1-1.ephec-ti.be. Il est sous-domaine du domaine DNS propre au cours ephec-ti.be géré par les professeurs du cours.
Le sous-domaine DNS est hébergé via un conteneur Docker dédié qui est ouvert sur les ports 53 TCP/UDP pour la gestion DNS et 853 TCP pour la gestion DNS encapsulée par TLS. Les mêmes ports sont respectivement ouverts sur le VPS Hôte. Pour la vérification des certificats TLS du DNS un volume a été mis en place pour lier le répertoire /etc/letsencrypt du conteneur et le répertoire /certificate de l'hôte.
Le serveur web héberge deux sites web (www.l1-1.ephec-ti.be et blog.l1-1.ephec-ti.be) et une base de donnée. Le serveur web est, lui-même, hébergé sur trois conteneurs Docker.
Un premier conteneur sert d'API et est ouvert sur les ports 80 pour la connexion HTTP et 443 pour la connexion HTTPS (HTTP encapsulé par TLS). Il est lié à un réseau 'api' afin de communiquer avec les autres conteneurs. Pour la vérification des certificats TLS du DNS un volume a été mis en place pour lier le répertoire /etc/letsencrypt du conteneur et le répertoire /certificate de l'hôte. Pour récupérer les pages HTML des différentes pages des sites web, un volume a été mis en place pour lier le répertoire /var/www/html du conteneur et le répertoire /web/html de l'hôte.
Un deuxième conteneur sert à la liaison, fait sous PHP entre l'API et la base de données. Il est lié à deux réseaux 'api' et 'db' afin de communiquer avec les autres conteneurs. Pour récupérer la pages PHP des différentes pages des sites web, un volume a été mis en place pour lier le répertoire /var/www/html du conteneur et le répertoire /web/html de l'hôte.
Un troisième conteneur sert à la création et gestion de la base de données, sous MariaDB. Il est lié à un réseau 'db' afin de communiquer avec les autres conteneurs. Pour communiquer la base de données et récupérer la configuration de celle-ci, deux volumes ont été mis en place pour les lier respectivement les répertoire /docker-entrypoint-initdb.d et /etc/mysql/conf.d/my-resolve.cnf du conteneur avec les répertoires /web/db/sql et /web/db/conf/my-resolve.cnf de l'hôte.
Le serveur mail, de nom mail.l1-1.ephec-ti.be, héberge plusieurs adresses mails.
Le sous-domaine DNS est hébergé via un conteneur Docker dédié qui est ouvert sur les ports 25 pour la connexion SMTP, 143 pour la connexion IMAP4, 465 pour la connexion ESMTP, 587 pour la connexion ESMTP encapsulé TLS, 993 pour la connexion IMAP4 encapsulée TLS. Les mêmes ports sont respectivement ouverts sur le VPS Hôte. Pour la vérification des certificats TLS du DNS, un volume a été mis en place pour lier le répertoire /etc/letsencrypt du conteneur et le répertoire /certificate de l'hôte. Pour récupérer l'heure locale de la machine hôte, un volume a été mis en place pour lier le répertoire /etc/localtime du conteneur et le répertoire /etc/localtime de l'hôte. Pour transférer toutes les données liées spécifiquement au serveur mail, de nombreux volumes sont mis en place pour lier le conteneur et le répertoire /mail/docker-data/dms de l'hôte.
L'usurpation d'identité DNS est une technique utilisée par les attaquants pour falsifier les réponses DNS afin de rediriger le trafic Internet légitime vers des destinations malveillantes. Cette technique exploite une faiblesse dans la façon dont les serveurs DNS génèrent et gèrent les identifiants de requête.
Possibles raison de la vulnérabilité:
- Prévisibilité des IDs DNS
- Absence de vérification d'authenticité
- Manque de sécurité sur le réseau
Le cache poisoning DNS est une méthode utilisée par les attaquants pour corrompre les données dans le cache d'un serveur DNS, entraînant la redirection du trafic Internet légitime vers des sites malveillants.
Possibles raison de la vulnérabilité:
- Absence de validation des réponses DNS
- Mauvaise définition d’autorisation
Les attaques par déni de service (DDoS) peuvent affecter les serveurs DNS, Web et de messagerie de différentes manières, compromettant ainsi leur disponibilité et leur capacité à répondre aux demandes légitimes.
Possibles vulnérabilité:
- Faiblesse dans le traitement des requêtes DNS
- Vulnérabilités d'amplification DNS
En cas de dysfonctionnement de l'hôte serveur (VPS) ou du fournisseur des hôtes serveurs (OVH), le serveur DNS devient indisponible et les données des serveurs peuvent être complètement perdues.
Possibles vulnérabilité:
- Indisponibilités des services DNS
- Perte des données web (zones, configuration, domaines, ...)
Les attaques par déni de service peuvent affecter les serveurs DNS, Web et de messagerie de différentes manières, compromettant ainsi leur disponibilité et leur capacité à répondre aux demandes légitimes.
Possibles vulnérabilité:
- Vulnérabilités de traitement des requêtes HTTP
- Attaques de type Slowloris ou Slow POST
Lorsqu'il s'agit de mauvais contrôle d'accès sur les serveurs Web et de messagerie, cela expose les systèmes à diverses vulnérabilités qui peuvent être exploitées par les attaquants pour accéder à des informations sensibles, compromettre la confidentialité des données, ou même prendre le contrôle complet des serveurs.
Possibles vulnérabilité:
- Mauvaise configuration des autorisations de fichiers et répertoires
- Absence de mécanismes d'authentification robustes
Les failles cryptographiques sur les serveurs Web peuvent compromettre la confidentialité et l'intégrité des données échangées entre les serveurs et les clients.
Possibles vulnérabilité:
- Utilisation de protocoles obsolètes ou vulnérables
- Faiblesse dans les paramètres de chiffrement
- Absence de chiffrement de bout en bout
Les attaques par injection SQL sont l'une des vulnérabilités les plus courantes et les plus dangereuses auxquelles les serveurs Web peuvent être confrontés. Elles exploitent les failles de sécurité dans les applications web qui ne filtrent pas correctement les entrées utilisateur, permettant ainsi aux attaquants d'exécuter des commandes SQL malveillantes sur la base de données sous-jacente.
Possibles vulnérabilité:
- Permissions excessives sur la base de données
- Manque de sécurité au niveau du serveur de base de données
- Manque de validation des entrées utilisateur
- Utilisation de requêtes SQL non paramétrées
Les attaques XSS (Cross-Site Scripting) exploitent les failles de sécurité dans les applications web qui permettent aux attaquants d'injecter et d'exécuter du code JavaScript malveillant dans les navigateurs des utilisateurs. Ces attaques peuvent avoir des conséquences graves, notamment le vol de sessions utilisateur, la redirection vers des sites malveillants, la collecte de données sensibles, ou la prise de contrôle de comptes utilisateur.
Possibles vulnérabilité:
- Manque de validation des entrées utilisateur
- Absence de stratégies de sécurité au niveau du navigateur
En cas de dysfonctionnement de l'hôte serveur (VPS) ou du fournisseur des hôtes serveurs (OVH), le serveur web devient indisponible et les données des serveurs peuvent être complètement perdues.
Possibles vulnérabilité:
- Indisponibilités des services webs
- Perte des données web (pages, bases de données, configuration, ...)
Si l'entreprise ne prévoit pas assez de protocole pour prouver son intégrité et sa crédibilité dans la gestion de ses sites web, celle-ci peut perdre toute crédibilité dans son environnement.
Possibles vulnérabilité:
- Manque de vérification des signatures numériques
Les attaques par déni de service peuvent affecter les serveurs DNS, Web et de messagerie de différentes manières, compromettant ainsi leur disponibilité et leur capacité à répondre aux demandes légitimes.
Possibles vulnérabilité:
- Vulnérabilités de traitement des requêtes SMTP
- Attaques par rétrodiffusion (Backscatter)
Lorsqu'il s'agit de mauvais contrôle d'accès sur les serveurs Web et de messagerie, cela expose les systèmes à diverses vulnérabilités qui peuvent être exploitées par les attaquants pour accéder à des informations sensibles, compromettre la confidentialité des données, ou même prendre le contrôle complet des serveurs.
Possibles vulnérabilité:
- Faible gestion des autorisations sur les boîtes aux lettres
- Absence de chiffrement pour les connexions SMTP et IMAP
- Faible contrôle d'accès aux listes de diffusion
Les failles cryptographiques sur les serveurs de messagerie peuvent compromettre la confidentialité et l'intégrité des e-mails échangés entre les serveurs et les utilisateurs.
Possibles vulnérabilité:
- Utilisation de protocoles obsolètes ou vulnérables
- Faiblesse dans les paramètres de chiffrement
- Absence de chiffrement de bout en bout
Les failles de confidentialité pour les serveurs de messagerie peuvent compromettre la sécurité et la confidentialité des communications électroniques échangées entre les utilisateurs.
Possibles vulnérabilité:
- Manque de chiffrement des connexions
- Configuration incorrecte des paramètres d’accès
- Absence de chiffrement de bout en bout
- Vulnérabilités dans les logiciels et les protocoles utilisés
Les failles d'intégrité des données pour les serveurs de messagerie peuvent compromettre la sécurité et la fiabilité des e-mails stockés et transitant à travers le serveur.
Possibles vulnérabilité:
- Configuration incorrecte des paramètres d’accès
- Altération des e-mails en transit
- Absence de chiffrement de bout en bout
- Manque de vérification des signatures numériques
Les failles d'intégrité des services de messagerie peuvent compromettre la sécurité et la fiabilité des e-mails stockés et transitant à travers ces services.
Possibles vulnérabilité:
- Vulnérabilités dans les logiciels de service de messagerie
- Accès non autorisé aux boîtes aux lettres
- Mauvaise configuration
- Mauvaise gestion des sauvegardes
En cas de dysfonctionnement de l'hôte serveur (VPS) ou du fournisseur des hôtes serveurs (OVH), le serveur mail devient indisponible et les données des serveurs peuvent être complètement perdues.
Possibles vulnérabilité:
- Indisponibilités des services mails
- Perte des données mails (utilisateurs, historique des mails, configuration, ...)
Les spams sont des messages électroniques non sollicités et souvent malveillants qui peuvent entraîner une surcharge des serveurs de messagerie, perturber les utilisateurs légitimes, et présenter des risques pour la sécurité des données.
Possibles vulnérabilité:
- Mauvaise configuration des filtres anti-spam
- Listes de diffusion non sécurisées
- Absence de surveillance et de gestion des activités suspectes
- Mauvaise gestion des adresses e-mail
Si l'entreprise ne prévoit pas assez de protocole pour prouver son intégrité et sa crédibilité dans la gestion de ses mails, celle-ci peut perdre toute crédibilité dans son environnement.
Possibles vulnérabilité:
- Mauvaise configuration du serveur mail
- Serveur marqué comme "Open Relay"
- Manque de vérification des signatures numériques
| Menace | Probabilité | Impact | Estimation du risque | Contre-mesure |
|---|---|---|---|---|
| ID spoofing (5.2.1) | Faible | Fort | Moyen | DNSSEC |
| Cache Poisoning (5.2.1) | Faible | Fort | Moyen | DNSSEC |
| DOS (Deni Of Service) (5.2.2) | Moyenne | Fort | Elevé | Serveur de backup |
| Intégrité des hôtes | Faible | Fort | Moyen | Serveur de backup, Sauvegarde des configurations |
| Menace | Probabilité | Impact | Estimation du risque | Contre-mesure |
|---|---|---|---|---|
| DOS (Deni Of Service) (5.2.2) | Moyenne | Fort | Elevé | Serveur de backup |
| Mauvais contrôle d'accès (6.2) | Moyenne | Fort | Elevé | Filtrage d'accès et isolation des services |
| Faille cryptographique (6.2) | Haute | Moyen | Elevé | Mise à jour et sécurisation HTTPS |
| Attaque par injection | Faible | Fort | Moyen | Sécurisation des champs inputs et requête paramètre |
| Scripting inter site (XSS) | Faible | Moyen | Moyen | Mise à jour, surveillance et pare-feu adéquat |
| Intégrité des hôtes | Faible | Fort | Moyen | Serveur de backup, Sauvegarde des configurations |
| Mauvaise réputation de l'entreprise | Faible | Fort | Faible | Mise à jour et sécurisation HTTPS |
| Altération/violation des données | Moyen | Fort | Moyen | Isolation de la base de données, Attribution des privilèges minimum aux utilisateurs |
| Menace | Probabilité | Impact | Estimation du risque | Contre-mesure |
|---|---|---|---|---|
| DOS (Deni Of Service) (5.2.2) | Moyenne | Fort | Elevé | Serveur de backup |
| Mauvais contrôle d'accès (6.2) | Moyenne | Fort | Elevé | Filtrage d'accès |
| Faille cryptographique (6.2) | Haute | Moyen | Elevé | Mise à jour et encryption TLS |
| Faille de confidentialité (7.2) | Moyenne | Moyen | Moyen | Encryption TLS et filtrage d'accès |
| Intégrité des données (7.2) | Haute | Fort | Elevé | Encryption TLS |
| Intégrité des services mails (7.2) | Moyenne | Fort | Elevé | Pare-feu, DMZ, gestion d'accès et validation des configuration |
| Intégrité des hôtes | Faible | Fort | Moyen | Serveur de backup, Sauvegarde des configurations |
| Spam (7.2) | Haute | Fort | Très elevé | Filtrage des mails |
| Mauvaise réputation de l'entreprise | Faible | Fort | Faible | Encryption TLS, Filtrage d'accès, Signature des mails |
Le DNSSEC est une extension du DNS qui vise à sécuriser les requêtes DNS. Il utilise le principe de cryptographie asymétrique pour signer les ressources records présents dans les fichiers de zone. Chaque zone dispose d’une paire de clés. La clé privée est utilisée pour créer des signatures pour les ressources records de la zone tandis que la clé publique est utilisée pour valider ces ressources records.
C’est une extension qui repose sur le principe de chaîne de confiance car il faut s’assurer que le propriétaire de la clé publique est bien la personne qu’elle prétend être. La chaîne de confiance permet donc d’authentifier les clés publiques. La racine, qui se trouve tout en haut de la chaîne de confiance, valide les éléments se trouvant en dessous d’elle dans la hiérarchie en signant leurs clés publiques à l’aide de sa propre clé privée. Les éléments qui se trouvent en dessous de la racine valident ensuite à leur tour les éléments en dessous d’eux en signant leurs clés publiques et ainsi de suite.
Le DNSSEC est mis en place pour contrer les menaces suivantes :
- ID spoofing
- Cache Poisoning
L’utilisation de serveurs de backup est très utile pour permettre à des services essentiels de continuer de tourner au cas où le serveur principal rencontre une panne ou se fait attaquer. Les serveurs de backup sont également utilisés pour stocker des copies de sauvegardes de données importantes ce qui permet de garantir l’intégrité de ces données.
Les serveurs de backup sont mis en place pour contrer les menaces suivantes :
- DOS (Deni Of Service)
Le filtrage d'accès est utilisé pour surveiller le trafic entrant et sortant via des pare-feux et restreindre l’accès à des ressources et/ou données seulement aux utilisateurs qui y sont autorisés. Celui-ci peut autoriser (ou non) l’accès aux ressources de différentes manières. Il est possible de faire du filtrage d’accès en fonction des adresses IP, des ports ou encore des protocoles.
Le filtrage d’accès est mis en place pour contrer les menaces suivantes :
- Mauvais contrôle d’accès
- Faille de confidentialité
- Intégrité des serveurs
Le principe de l’isolation des services est de séparer les différents services utilisés (DNS, web et mail dans notre cas) afin de renforcer la sécurité globale du système. Cela permet d'empêcher qu’un service n’affecte les autres services ou le système en lui-même au cas où il rencontre un problème.
Les différents services présents dans le système doivent être répartis et exécutés dans des environnements bien distincts afin d’éviter les interactions inutiles entre ceux-ci. Ils peuvent être exécutés dans des machines virtuelles, des systèmes physiques ou dans notre cas des conteneurs.
L’isolation des services est mise en place pour contrer les menaces suivantes :
- Mauvais contrôle d’accès
Cela paraît peut-être banal, mais les mises à jour sont importantes pour garantir la sécurité des serveurs. Les mises à jour permettent souvent de contrer une faille de sécurité qui a été découverte, ou encore de simplement mettre en place les nouvelles protections de sécurité qui ont été développées. Il vaut donc toujours mieux utiliser des composants et algorithmes qui sont à jour, cela permet de limiter les risques d’attaques et de garantir aux utilisateurs la protection de leurs données.
Les mises à jour sont utilisées pour contrer les menaces suivantes :
- Faille cryptographique
- Scripting inter site (XSS)
Le HTTPS est une version du protocole HTTP sécurisé par du TLS. TLS est un protocole utilisé pour sécuriser les échanges applicatifs tels que HTTP, SMTP, IMAP/POP ou encore le DNS.
Tout comme le DNSSEC, TLS utilise le principe de cryptographie asymétrique pour authentifier un intervenant (client ou serveur). Un challenge est généré sur base de la clé privée de l’intervenant et sa clé publique est ensuite utilisée pour déchiffrer ce même challenge.
Les clés publiques sont authentifiées par des autorités de certification. Via sa clé privée, l’autorité de certification signe le hash calculé depuis la clé publique de l’intervenant. Cette signature est ensuite ajoutée à la clé publique de l’intervenant et encodée sous forme de certificat signé. Pour respecter le principe de chaîne de confiance, l’autorité de certification est elle aussi signée par une autre autorité de certification et ainsi de suite jusqu’à arriver à une autorité de certification racine.
La sécurisation HTTPS est mise en place pour contrer les menaces suivantes :
- Faille cryptographique
- Mauvaise réputation de l'entreprise
Les pare-feux sont utilisés pour filtrer et contrôler le trafic réseau entrant et sortant. Ils peuvent être configurés avec un ensemble de règles, ce qui leur permettent de déterminer quelles requêtes ils vont laisser passer à travers le trafic réseau et lesquelles ils vont bloquer.
Les pare-feux sont utilisés pour contrer les menaces suivantes :
- Scripting inter site (XSS)
- Intégrité des serveurs
- DoS (Denial of Service)
TLS est un protocole utilisé pour sécuriser les échanges applicatifs tels que HTTP, SMTP, IMAP/POP ou encore le DNS. TLS utilise le principe de cryptographie asymétrique. Chaque serveur a besoin d’un certificat TLS pour garantir l’authenticité des clés publiques qui sont utilisées lors des échanges. Comme expliqué dans la partie sécurisation HTTPS, les serveurs peuvent obtenir ces certificats en demandant à des autorités de certification.
TLS peut être utilisé de manière explicite ou de manière implicite. Si le TLS est utilisé de manière explicite, la connexion est initialement non sécurisée, et le client peut ensuite basculer sur une connexion TLS en utilisant une commande. Si au contraire, le TLS implicite est utilisé, un port spécifique est utilisé et l’échange se réalise directement via une connexion TLS.
L’encryption TLS est mise en place pour contrer les menaces suivantes :
- Faille cryptographique
- Faille de confidentialité
- Intégrité des données
- Mauvaise réputation de l'entreprise
Les logiciels anti-spam ont pour but d’inspecter le contenu de chaque message et de les classer en fonction en “autorisé” ou en “spam”. Ils peuvent se placer soit sur un serveur ou soit sur un client mail.
Les filtres des logiciels anti-spam sont basés sur plusieurs algorithmes différents. Il y a d’abord les white-lists qui sont des listes d’adresses email qui sont correctes et pour lesquelles les emails devraient correctement être envoyés. A l’inverse, on retrouve les black-lists qui sont des listes des serveurs et/ou adresses qui sont considérés comme générateurs de spam.
D’autres techniques comme l’analyse heuristique qui utilise des règles sous forme d’expressions régulières pour identifier des patterns ou des mots spécifiques qui indique la présence de spam sont également utilisées
Le filtrage anti-spam est mis en place pour contrer les menaces suivantes :
- Spam
Garder une sauvegarde dite "back-up" des différentes configurations des services disponibles sur l'hôte serveur semble essentiel en cas de perte ou d'indisponibilité de celui-ci.
La solution peut être de garder une copie soit sur un disque-dur soit sur un répertoire de partage de code (comme GitHub) en privé. Les deux solutions ont leurs défauts : la première peut poser des problèmes en cas de dommages sur le disque-dur et la seconde pourrait amener à une fuite des données en cas de mauvaise configuration du partage privé ou en cas de piratage du site hôte.
La sauvegarde des configurations de l'hôte VPS est mis en place pour contrer les menaces suivantes :
- Intégrité des hôtes
Laisser des requêtes SQL en brut dans un code public peut amener au détournement de ces requêtes pour d'autres comme le fait de récupérer les données ou encore l'arrêt de certains services.
En mettant en paramètres certaines requêtes, il ne devient plus possible d'ajouter des commandes telles quelles à la suite car ces requêtes ne sont pas valides d'elles-mêmes. Une solution supplémentaire peut être de mettre ces paramètres dans un fichier caché privé, ce qui rajoute de la sécurité.
La mise en paramètres des requêtes SQL est mis en place pour contrer les menaces suivantes :
- Attaque par injection
Une manière de vérifier qu’un email provenant de notre domaine est bien valide consiste à intégrer une signature électronique à chaque message sortant. Ce principe est mis en oeuvre via de la cryptographie asymétrique par le mécanisme DomainKeys Identified Mail (DKIM). Pour vérifier qu’un email est bien autorisé, un intervenant extérieur peut demander la clé publique du domaine à son serveur SOA, et grâce à cette clé publique, vérifier la validité de la signature.
La signature des mails du domaine est mis en place pour contrer les menaces suivantes :
- Mauvaise réputation de l'entreprise
Dans le cas d’un site dynamique qui est utilisé avec une base de données liée, il est important de séparer le serveur web et la base de données. Nous pouvons utiliser des conteneurs Docker afin de séparer virtuellement le serveur web et la base de données dans des environnements isolés ou les séparer physiquement via un autre serveur. Comme elle contient des données sensibles, la base de données ne peut absolument pas être accessible depuis l’extérieur.
En utilisant l’isolation du serveur web et de la base de données via des conteneurs Docker, la sécurité générale de l’infrastructure est améliorée. Le risque de subir une attaque visant à voler ou compromettre des informations stockées dans la base de données est considérablement réduit.
L’isolation virtuelle de la base de données est mise en place pour contrer les menaces suivantes :
- Altération/violation des données
L'utilisation d'une base de données implique la création d'utilisateur de cette base. Ainsi, pour chaque type d'accès qui sera nécessaire à cette base de données, il est utile de créer un utilisateur spécifique à cette tâche dont l'accès aux données, qui peuvent être sensibles et sont primordiales au service mis en place, est limité à ses tâches uniquement.
Pour l'accès à la base de données d'une API qui doit lire des données, il faudra créer un utilisateur n'ayant le droit de lecture uniquement sur les tables concernées par l'utilisation de l'API. Il est inutile est risqué de permettre l'écriture de nouvelles données ou même la suppression de données actuelles à cette API.
L'octroi de droits minimaux aux utilisateurs est mis en place pour contrer les menaces suivantes :
- Altération/violation des données
Sauvegarder la base de données via des "backup" est très utile pour permettre à des services essentiels de continuer de tourner en cas de corruption ou de perte de données dans la base de données principales.
La sauvegarde doit être protégée, via une limitation d'accès et/ou un firewall, et régulièrement mise à jour afin de garantir sa sécurité optimale.
L’isolation physique de la base de données est mise en place pour contrer les menaces suivantes :
- Altération/violation des données
Prévision des risques résiduels et organisation de la réaction en cas d’incident (détection, réaction et récupération)
Seront listées ici les risques qui ne sont pas encore pris en compte dans la configuration actuelle des services.
Une attaque Dos peut être détecter en cas d'arrêt net des services. Le serveur ne répond alors plus.
Une première solution peut être l'utilisation d'un pare-feu, ici Fail2Ban, afin d'empêcher à moindre mesure certaines connexions louches à l'hôte serveur (VPS). Celle-ci peut ne pas suffire.
Une attaque DoS signifie soit que les données du serveur hôte ont été récupérées soit les données sur fournisseur d'hôtes ont été récupérées. En fonction, il est intéressant de contacter le fournisseur pour avertir de la potentielle faille afin que celui-ci renforce son infrastructure anti-DoS.
Afin de récupérer les services, il est alors recommandé de changer d'hôte serveur (ou même de fournisseur d'hôtes). Pour faire ceci, il faudra alors récupérer les configurations via une sauvegarde de celles-ci pour les réadapter au nouvel hôte (sécurisation du serveur hôte, adresse IP, nom de l'hôte chez le fournisseur, ...).
Une autre solution peut être d'adapter le pare-feu aux nouveaux besoins afin d'observer un changement. Cette contre-mesure et plus simple d'application mais promet moins d'efficacité.
Un soucis dans l'intégrité des hôtes serveurs (VPS) amène à un arrêt net des services. Le serveur ne répond alors plus.
Ce problème peut techniquement aussi être détecter via les informations dans le cas ou le soucis d'intégrité ne provient pas d'un unique hôte mais d'un fournisseur entier.
Un soucis dans l'intégrité des service signifie soit un problème sur l'hôte seul soit un problème chez son fournisseur. En fonction, il est intéressant de contacter le fournisseur pour avertir de la potentielle faille afin que celui-ci renforce son infrastructure anti-DoS.
Il peut être intéressant de mettre en place préventivement un hôte serveur de secours, dit de "backup", sur le domaine pour prendre en charge les services en cas de soucis. Pour encore plus de sécurité, il est même recommandé de récupérer un hôte chez un autre fournisseur.
Pour récupérer le service, il faut alors mettre en place ou activer, si il ne l'est pas, le serveur de backup. Pour ceci on pourrait passer par un Load Balancer qui renverrait les requêtes au serveur encore intact.
Dans le cas ou il faudrait mettre ce serveur en place, une solution serait de récupérer les configurations via une sauvegarde de celles-ci pour les réadapter au nouvel hôte (sécurisation du serveur hôte, adresse IP, nom de l'hôte chez le fournisseur, ...).
Bien que le DNSSEC ne peut pas être complet à cause de notre fournisseur d'hôtes (OVH) puisqu'un hôte serveur de ce fournisseur ne peut pas fournir un ressource record DS au domaine parent direct. Toutefois, il est peut être vérifier à l'aide de l'outil DNSSEC Analyzer que tout le reste de la chaîne de vérification est fonctionnel.
Une solution serait d'avoir notre propre hôte indépendant à terme. Ce ne sera pas notre cas ici.
Le domaine n'a, pour le moment, pas de serveur de backup. Il reste, dans le groupe, encore deux hôtes serveurs (VPS) libres qui peuvent être utilisés pour se faire. Au sein des TPs ultérieurs, un de ces hôtes sera surement mis en place comme serveur de backup. Il est toutefois à noter que les hôtes serveurs libres sont du même fournisseur d'hôtes (OVH).
Faute d'informations à privatiser, le filtrage d'accès n'est pas spécialement utilisé ici. La seule réelle limite d'accès vient de sortir fichier comme la configuration du service mail dont les autorisations sont mises en écriture et en lecture uniquement aux administrateurs du hôte serveur. A noter que seule les personnes ayant soit le mot de passe soit la clé privé d'accès de l'hôte serveur peuvent accéder au VPS. A Chaque utilisateur du service mail, il est demandé un et de passe pour sécuriser leur compte.
Lorsque des données privées seront mises en ligne sur le serveur, plus de filtrage d'accès devront être mis en place comme de la création de type d'utilisateurs donnant accès à des données spécifiques. De telles méthodes pourraient d'ailleurs être mises en place sur un reverse proxy via un autre hôte serveur.
Ici, l'isolation est faite via des dockers : un pour le service DNS, 3 pour le web et un pour le mail. Ainsi, si un plante, les autres peuvent toujours tourner en arrière plan. Le principal problème vient de l'hôte serveur : si le VPS plante, tous les services plantent. La solution qui devrait alors être mis en place est la création d'un serveur de backup (voir partie précédente).
Les principaux algorithmes à mettre à jour sont nos logiciels et les images Docker. Docker se met régulièrement à jour de lui-même. Pour ce qui est des images, il est donc du devoir des administrateurs de tester chaque nouvel mise à jour pour chaque image ici utilisée afin de mettre à jour les Dockerfile après vérification. Dans le cas où la nouvelle version d'une image ne fonctionne plus avec nos services, il sera alors nécessaire de mettre à jour la configuration pour permettre la meilleure longévité à nos services.
Puisque, pour notre service web, le port 80 est utilisé et donc le service HTTP mais aussi le protocole de communication sécurisé TLS, notre service web est bien sécurisé en HTTPS. Pour plus d'informations sur l'évaluation et la maintenance de ce service, je vous dirige vers la partie dédié au cryptage TLS.
Le seul parfait qui protège nos serveurs protège l'hôte serveur de l'extérieur. C'est un pare-feu géré par le logiciel Fail2Ban. Celui-ci accompagne la sécurité mise en place par le fournisseur de notre hôte serveur via un pare-feu applicatif propre.
A terme, il pourrait être intéressant de mettre d'autre pare-feu en fonction des accès donnés à certains de nos services. Cette mise à jour devrait alors être faite sur un serveur secondaire ou encore sur un reverse proxy qui pourrait être mis en place sur d'autres hôtes serveurs.
Le protocole TLS a été active sur nos service à l'aide de l'autorité de certification "Let's Encrypt" via l'outil "certbot" qui a fourni les clé publiques et privées nécessaires à l'authentification des différents services. Pour être validé, "Let's Encrypt" a demandé de solutionner un challenge qu'il a fourni. La preuve de cette solution est présente dans la zone DNS de notre domaine.
Le certificat doit être renouvelé tous les 30 à 60 jours. Il sera donc nécessaire soit de renouveler manuellement, soit de renouveler le certificat via un autre outil comme un conteneur Docker. C'est la solution qui sera ici mis en place à terme. Il en est de même concernant la maintenance du service HTTPS.
Au sein du service mail, plusieurs sécurités anti-spam ont été mise en place. Pour ne pas faire notre service un "Open relay" qui accepteraient d'envoyer des requêtes ne provenant pas du domaine ou de recevoir des requêtes non destinées au domaine, SPF a été mis en place. Afin de signer les mails envoyés par le domaine, le service DKIM a été mis en place. Via le service DMARC, le service mail sait qu'il doit mettre les mails reçus vus comme des spams en quarantaine dans une boîte propre. Il sait aussi qu'en cas de suspicion de spam, il doit envoyer une requête à l'adresse maîtresse (postmaster) du domaine. Afin de vérifier les mails sortant, le protocole SpamAssassin a été configuré dans le fichier d'environnement du service mail.
A terme, il pourrait être intéressant de crypter de bout en bout toutes communications mails via PGP ou S-MIME.
La configuration du hôte serveur est régulièrement mis à jour sur un GitHub dédié et est régulièrement mis à jour. Pour le moment, le projet est en public. A terme il faudra le rendre privé et donner accès uniquement aux personnes concernées (administrateurs et évaluateurs).
Le projet étant un projet de cours, il est nécessaire de passer par une plateforme de partage de code. Au mieux, il faudrait limiter l'accès à la configuration de l'hôte serveur dans un intranet privé à l'équipe.
Ici, il n'y pas de requêtes SQL directement dans le code. Les seules requêtes présentes sont paramètres à l'aide de variables d'environnement cachées dans un fichier caché dédié. L'injection de requêtes SQL malveillantes est donc ici impossible.
Lors de l'amélioration den nos services, il faudra continuer à tenir une telle sécurité en place pour les autres requêtes.
Au sein du service mail, une politique de signature des mails sortants a été mis en place avec le protocole DKIM. Pour vérifier qu’un email est bien autorisé, un intervenant extérieur peut demander la clé publique du domaine à son serveur SOA, et grâce à cette clé publique, vérifier la validité de la signature.
A terme, il pourrait être intéressant de crypter de bout en bout toutes communications mails via PGP ou S-MIME.
La base de données est indispensable et critique aux services. Dans ce cas-ci, la base de données n'est isolée que virtuellement via un conteneurs Docker qui n'est lié qu'à 2 autres conteneurs via un réseau Docker et plusieurs volumes.
A terme, il pourrait être intéressant d'isoler la base de données plus efficacement via un isolement physique en hébergeant la base de données sur un autre hôte serveur, lui-même protéger par un pare-feu propre.
La base de données est, dans ce cas-ci, la base de données est uniquement parcourue en lecture pas une API écrite en PHP afin de fournir les données de la base de données "woodytoys". Pour se faire, il a été créé un utilisateur 'wt-user'@'php%' identifié 'wt-pwd' qui n'a donc que les droits de lecture sur l'ensemble des tables de la base de données "woodytoys".
Il serait plus propre de n'octroyer le droit de lecture uniquement aux tables lues. Dans ce cas-ci, toutes les tables sont lues donc ça n'amène à aucun risque réel.
Quand d'autres utilisations de la base de données seront mises en place, il faudra ainsi ajouter d'autres utilisateurs avec des droits limités pour chacune d'elles.