Infrastructures de sécurité

Généralités

Les systèmes d'information (SI) sont de plus en plus incontournables dans nos sociétés. Il est indispensable d'en garantir le bon fonctionnement au regard de leur criticité dans notre vie quotidienne. Les interconnexions entre les différents systèmes permises par le développement d'Internet les rendent interdépendant les uns des autres et vulnérables aux attaques.

Pour parer à cela, il est nécessaire de déployer une politique de Sécurité des Systèmes d'Information (PSSI). Cela se traduit par la mise en place de moyens humains, techniques, organisationnels et juridiques pour garantir, conserver et rétablir la sécurité d'un système, notamment en termes de disponibilité, d'intégrité et de confidentialité.

Il existe plusieurs types de vulnérabilités au sein d'un SI :

Les vulnérabilités humaines

C'est le maillon le plus faible de la sécurité du SI. L'être humain est sujet à des erreurs, des négligences, des incompétences qui peuvent mener à des failles de sécurité exploitables.

Les vulnérabilités technologiques

Il s'agit dans les SI d'erreurs de conception, de développement, de configuration, de maintenance, etc.

Les vulnérabilités organisationnelles

Ce sont essentiellement des manques de procédures, de documentations ou de circuits de validation pour faire face aux incidents de sécurité (sauvegarde, escalade de problèmes, etc.)

Un SI est soumis à plusieurs types de menaces :

Les menaces naturelles

Incendies, inondations, séismes, épidémies, météo, etc.

Les menaces humaines

Vol d'informations, sabotage, chantage, usurpation d'identité, espionnage, grèves, etc.

Les menaces juridiques

Les réglementations pouvant régir votre SI (notamment dans le cas d'un SI sur plusieurs pays)

Ces menaces peuvent porter sur un ou plusieurs indicateurs du SI (indicateurs DICP) :

Disponibilité

S'assurer que le service soit fonctionnel lorsque les utilisateurs en ont besoin. La disponibilité se mesure en divisant la durée de fonctionnement effectif par la durée de fonctionnement prévu. Par exemple, une disponibilité minimale de 99,999 % ne permet que 5 minutes et 15 secondes d'indisponibilité.

Intégrité

Les données traitées doivent être celles attendues, sans altération ou destruction volontaire ou accidentelle.

Confidentialité

Les données doivent être accessibles uniquement aux personnes dont l'accès est autorisé.

Preuve ou Traçabilité

Il doit être possible de remonter de manière sûre et fiable les origines d'un évènement. Cela inclut également la non-répudiation : un utilisateur ne peut pas nier avoir effectué une opération ou reçu une information.

Les attaques

On peut distinguer trois cibles d'attaques visant un SI :

• Attaques sur les clients (ordinateur, smartphone, tablette, objets connectés, etc.)
• Attaques sur les serveurs
• Attaques sur le réseau (équipements réseaux ou sur les paquets en eux-mêmes)

On désigne par exploit l'ensemble des techniques permettant d'exploiter une faille dans un SI. On retrouve ici les injections de code, les dépassements de pile mémoire, les injections SQL, les XSS (cross-site scripting) etc.

Les logiciels malveillants

Le terme malware en anglais désigne les logiciels malveillants dans le but de nuire à un SI. On peut distinguer différents types de malwares :

Virus

Le virus s'insère dans un logiciel légitime (nommé hôte) et se propage vers d'autres ordinateurs (via le réseau ou les périphériques de stockage externes).

Ver

Le ver (worm en anglais) est similaire au virus à la différence qu'il n'a pas besoin d'un programme hôte pour se propager.

Cheval de Troie

À l'instar de cet épisode de la mythologie grecque, le cheval de Troie (Trojan horse en anglais) informatique dissimule ses mauvaises intentions sous une apparente légitimité. L'utilisateur dupé l'installe sur son ordinateur et permet au code malveillant de s'exécuter. Ils peuvent prendre la forme d'un document, d'un logiciel légitime, etc.

Rootkit

Ce terme désigne les techniques mises en œuvre par un pirate pour maintenir un accès frauduleux sur une machine.

Les impacts de ces malwares peuvent être très variés :

• Vol d'informations
• Saturation des ressources des ordinateurs ou du réseau
• Utilisation frauduleuse de ressources (par exemple minage de cryptomonnaies)
• Enrôlement dans un botnet : un réseau d'ordinateurs infectés dans le but d'effectuer une attaque sur une autre cible (en général de l'envoi de spam ou une attaque par déni de service distribué).
• Altération ou destruction de données
• Destruction du matériel
• Chantage (rançongiciel ou ransomware en anglais)

Certains malwares sont conçus pour une cible très spécifique dans le cas d'attaques organisées (le ver Stuxnet, développé par la NSA et découvert en 2010 visait les automates industriels Siemens utilisés dans les centrifugeuses d'enrichissement d'uranium en Iran).

L’ingénierie sociale

Il s'agit de techniques de manipulation psychologique visant à exploiter les faiblesses de l'utilisateur d'un SI. Elles exploitent les faiblesses psychologiques, sociales et organisationnelles des personnes ou des organisations dans le but d'obtenir frauduleusement quelque chose.

Les objectifs de ce type d'attaques sont très variés :

• Escroquerie
• Vol d'informations
• Propagation de malwares
• Accès au SI
• etc.

Les méthodes d'attaques sont très variées : on connaît surtout les courriels ou sites frauduleux (hameçonnage ou phishing en anglais), mais cela peut passer également par des appels téléphoniques, des SMS, des courriers, des affiches, etc.

Une bonne sensibilisation et formation des utilisateurs du SI permettent de limiter les risques de ce type d'attaques. Cependant, les attaques d'ingénierie sociales peuvent être spécialement conçues pour viser une organisation, ce qui les rend plus difficilement identifiables par les utilisateurs.

L'exploitation de failles

On retrouve ici différentes techniques visant à utiliser les failles d'un système (matériel, système d'exploitation, site Web, services, etc.) à des fins malveillantes. Voici quelques exemples des techniques employables :

Injections SQL

Insérer dans une requête SQL légitime du code malveillant.

Cross-site scripting

Abrégé XSS pour Cross-site scripting en anglais. Injecte du contenu dans une page Web en vue d'être exécuté sur le navigateur de la ou des victimes.

Débordement de tampon

Un bug écrit dans une zone mémoire à l'extérieur de la zone prévue et permet à un attaquant d'exécuter du code malveillant.

Les attaques du réseau

Sont regroupées sous cette appellation l'ensemble des techniques visant à attaquer un SI par son réseau. On retrouve les attaques suivantes :

Sniffing

Cette technique consiste à écouter le trafic réseau en vue de collecter des informations (mots de passe, données, etc.)

Usurpation d'adresse IP ou MAC

Utilisée par un attaquant visant à se faire passer pour une autre machine en vue de collecter des informations ou de fournir de fausses informations à un client (empoisonnement DNS, etc.)

Déni de service

Dans une attaque par déni de service (denial of service (DoS) en anglais), l'attaquant cherche à saturer les réseaux ou les serveurs cibles afin de rendre le service inopérant. Si on utilise plusieurs sources pour effectuer l'attaque, comme dans le cas de l'utilisation d'un botnet, on parle de déni de service distribué (distributed denial of service (DDoS) en anglais).

Bonnes pratiques

À tous les niveaux d'un SI, tant dans le milieu professionnel que personnel, il est important d'adopter des bonnes pratiques afin de garantir un bon niveau de sécurité et de se prémunir des attaques. En voici quelques unes qu'il est bon d'adopter et de partager à l'ensemble des collaborateurs de votre organisation et à votre entourage.

• Former et sensibiliser les parties prenantes du réseau. Les équipes opérationnelles ayant un accès privilégié au réseau doivent suivre des formations particulières liées à leurs droits forts, ainsi qu'à leurs responsabilités. Chaque utilisateur est un maillon essentiel de la sécurité du SI.
• Effectuer un inventaire précis de votre SI : les serveurs, le schéma du réseau, les comptes utilisateurs, etc.
• Prévoir des procédures d'arrivée, de départ et de mutation claires pour fournir les bonnes permissions aux bonnes personnes au bon moment.
• N'autoriser sur le réseau uniquement les équipements maîtrisés.
• Verrouiller et attacher le poste lorsque vous n'êtes pas présent.
• Ne pas connecter de périphérique d'origine inconnue (clef USB, disque dur, etc.).
• Identifier nommément chaque personne accédant au SI avec des droits restreints uniquement aux besoins des utilisateurs. Ne fournissez pas de compte générique et retirez les droits administrateurs au maximum d'utilisateurs.
• Choisir des mots de passe forts, uniques pour chaque service et individuels. L'utilisation d'un coffre-fort de mots de passe (exemple : KeePass) permet de stocker les mots de passe de manière sécurisée. L'utilisateur n'a plus qu'à retenir le mot de passe du coffre. Ne stocker ni ses mots de passe en clair, ni sur un document papier accessible.
  Un mot de passe est comme un slip : c'est personnel, ça se change souvent et on ne le laisse pas traîner sur son bureau !
• Changer les éléments d'authentification par défaut des équipements et des services.
• Activer dès que cela est possible l'authentification forte.
• Sécuriser les équipements du réseau (pare-feu, anti-virus, limiter les applications et extensions installées à l'essentiel, chiffrer les données sensibles, etc.)
• Sauvegarder régulièrement sur un système hors ligne les données importantes.
• Limiter l'utilisation des WiFi publics et si cela est nécessaire, chiffrer les communications avec un VPN.
• Chiffrer les communications (notamment sur Internet) et choisir les protocoles sécurisés quand cela est possible.
• Cloisonner le réseau en zones distinctes en fonction des usages (bureautique, DMZ, etc.). N'exposer que les services nécessaires sur Internet.
• Mettre en place une passerelle d'accès sécurisé à Internet (pare-feu, proxy).
• Choisir un système de sécurité du WiFi robuste et segmenter les différents réseaux (visiteurs, bureautique, etc.)
• Sécuriser l'accès physique aux salles serveurs et locaux techniques.
• Utiliser un réseau dédié et couper l'accès à Internet aux postes et serveurs utilisés pour l'administration du SI.
• Sécuriser les connexion réseau pour les équipements nomades (VPN).
• Appliquer les mises à jour des logiciels sur l'ensemble du SI.
• Journaliser les événements sur les serveurs et équipements réseau du SI.
• Contrôler régulièrement l'application des règles de sécurité.
• Définir une procédure en cas d'incident de sécurité.

Ces quelques préconisations sont issues du guide d'hygiène informatique fourni par l'ANSSI. Le document complet est disponible sur : https://www.ssi.gouv.fr/guide/guide-dhygiene-informatique/

Le chiffrement et la signature cryptographique

Les procédés de signature et de chiffrement cryptographiques permettent d'apporter respectivement l'intégrité d'un message et la confidentialité d'un message.

Les standards de chiffrement et de signature les plus courants se basent sur la cryptographie asymétrique.

Le fonctionnement, décrit ici pour des messages, fonctionne de la même manière pour la communication entre un client et un serveur d'un service chiffré (HTTPS, SMTPS, etc.).

Contrairement au chiffrement symétrique qui utilise la même clef pour chiffrer et déchiffrer, le chiffrement asymétrique utilise deux clefs :

• La clef publique pouvant être diffusée auprès des tiers avec lesquels on communique.
• La clef privée devant être gardée secrète.

Ainsi, il est nécessaire à ce que l'expéditeur possède la clef publique du destinataire afin de chiffrer ou signer un message lui étant destiné.

Voici la terminologie à employer :

• chiffrer : Transformer un message en clair en un message inintelligible pour assurer le secret de sa transmission.
• déchiffrer : Traduire en clair un message chiffré à l'aide de la clef de déchiffrement.
• décrypter : Traduire en clair un message chiffré en ignorant la clef de déchiffrement.

Le chiffrement

Le chiffrement permet de rendre illisible le contenu du message à toute personne ne possédant pas la clef de déchiffrement (clef privée dans le cas d'un chiffrement asymétrique).

L'envoi d'un message chiffré de A vers B se fait comme suit :

1. Le message en clair est chiffré à l'aide de la clef publique de B.
2. Le message chiffré est envoyé à B.
3. Le message est déchiffré par la clef privée de B.

La signature numérique

La signature numérique permet de garantir l'origine du message et son intégrité. Elle possède les avantages suivants :

• Elle est authentique et infalsifiable : le signataire est identifié et son identité ne peut être usurpée.
• La signature est à usage unique : on ne peut pas réutiliser la signature d'un message pour en signer un second.
• Le document est inaltérable : s'il est modifié, la signature devient invalide.
• La signature est irrévocable : le signataire ne peut pas nier la signature vu qu'il est seul a posséder la clef privée.

Ainsi, la signature numérique propose de nombreux avantages par rapport à la signature manuscrite.

L'envoi d'un courriel signé entre A et B s'effectue comme suit :

1. Une empreinte du message est calculée à l'aide d'une fonction de hachage. Une fonction de hachage produit une empreinte unique pour un contenu. Il s'agit d'une fonction à sens unique qui ne permet pas à partir de l'empreinte de retrouver le contenu originel. Quelques fonctions de hachages courantes : MD5, SHA1, SHA256, SHA512. Certaines sont a éviter telles que le MD5 et SHA1 car il y a risque de collision (le fait que deux contenus différents aient la même empreinte).
2. L'empreinte est chiffrée avec la clef privée de l'émetteur. On obtient la signature du message.
3. La signature est ajoutée au message en clair.
4. Le message signé est envoyé.
5. La signature est séparée du message.
6. La signature est déchiffréestrong> avec la clef publique de l'émetteur.
7. L'empreinte du message est calculée à l'aide de la même fonction de hachage que lors de la création de la signature.
8. L'empreinte obtenue en hachant le message en clair et l'empreinte obtenue en déchiffrant la signature sont comparées. Si elles sont identiques, le message est authentique.

Les certificats

Les certificats sont l'équivalent d'une carte d'identité numérique pouvant être attribuée à des entités dont on souhaite vérifier l'identité (personnes, serveur, client, etc.).

Un certificat regroupe plusieurs éléments :

• La clef publique de l'entité à identifier
• Des informations à propos du propriétaire du certificat (nom, adresse courriel, localisation, etc.)
• Des informations sur le certificat lui-même (version, algorithme de signature, etc.)
• La signature de l'autorité de certification qui a produit le certificat. La signature est produite à partir des informations précédentes et avec la clef privée de l'autorité de certification.

La création d'un certificat s'effectue comme suit :

1. Une demande de certificat (Certificate Signing Request en anglais, abrégé CSR) est produite. Elle regroupe les informations à propos de l'entité qui demande le certificat, ainsi que sa clef publique.
2. La demande de certificat est passée dans une fonction de hachage (par exemple SHA-256) pour obtenir une empreinte.
3. Cette empreinte est chiffrée à l'aide de la clef privée de l'autorité de certification. On obtient une signature.
4. La signature est ajoutée à la demande de certificat. On obtient ainsi un certificat signé.

Voici le certificat de Wikipedia avec une partie des informations contenues :

Le certificat apporte plusieurs garanties :

Infalsifiable

Le certificat étant signé, toute modification est impossible.

Certifié

Il est approuvé par une autorité de certification faisant foi.

Nominatif

Il est délivré à une et une seule entité.

Deux standards majeurs cohabitent afin de définir leur format et leur contenu :

X.509

Ce standard, créé en 1988 par l'Union Internationale des Télécommunications (UIT), est défini par la RFC 5280. Il s'appuie sur une hiérarchie des autorités de certification et n’admet qu'une seule signature d'autorité de certification.

OpenPGP

Ce standard, créé en 1998 par l'IETF, est défini dans la RFC 2440. Il permet de signer un certificat par plusieurs autres certificats OpenPGP et ainsi construire une toile de confiance.

La vérification de la validité d'un certificat se fait en vérifiant les deux éléments suivants :

• Les informations portées par le certificat lui-même : période de validité, la signature du certificat, l'entité déclarée est bien celle qui vous a remis le certificat, etc.

L'autorité qui a signé le certificat : vous faites confiance directement à l'autorité émettrice ou bien à l'autorité de niveau supérieur.

Un certificat auto-signé est un certificat signé par lui-même. C'est à vous de déterminer si oui ou non vous faites confiance au propriétaire du certificat.

Une autorité de certification qui émet un certificat possède également elle-même un certificat. Le certificat de l'autorité de certification peut être lui-même émis par une autre autorité de certification ou être auto-signé. En haut de la chaîne de confiance, on retrouve les autorités racines. On y retrouve :

• Les autorités de certification de votre entreprise, dans le cadre d'une infrastructure professionnelle.
• Des autorités publiques connues de tous telles que les services publics ou des autorités payantes (des sociétés privées dont le but est de susciter confiance et émettre, moyennant un paiement, des certificats).

Si un certificat ne peut pas être validé (lui-même et l'ensemble des autorités de la chaîne de confiance), l'utilisateur a le choix de lui faire tout de même confiance ou non.

Les certificats des autorités auxquels l'utilisateur fait confiance sont stockés dans un magasin des certificats où il est possible d'ajouter et de supprimer des certificats auxquels on fait confiance. Il est fourni par défaut avec une grande partie des autorités de certification publiques.

Les infrastructures à clefs publiques

Une Infrastructure à clefs publiques ou Public Key Infrastructure (PKI) en anglais désigne l'ensemble des composants, fonctions et procédures mis en place pour la création, la gestion ou la révocation des certificats à clefs publiques.

Le déploiement d'une PKI permet de centraliser et de simplifier la gestion des identités numériques, l'intégrité des documents et des échanges, l'assurance de la non répudiation.

Différentes composantes de la PKI remplissent des fonctions différentes :

Autorité d'enregistrement

(Registry Authority abrégé en RA) Elle reçoit les demandes de certificats (Certificate Signing Request abrégé en CSR) de la part des utilisateurs, vérifie les informations communiquées par le demandeur et fournit une requête de certificat (un certificat non signé). Elle collecte également les demandes de révocation des certificats.

Autorité de certification

(Certificate Authority abrégé en CA) Ce service reçoit les requêtes de certificats de l'autorité d'enregistrement et les signe. Par cette opération, l'autorité de certification transforme la requête en véritable certificat valide. Elle signe également les listes de révocation fournies par l'autorité d’enregistrement. De par sa criticité, l'autorité de certification nécessite un haut niveau de sécurisation.

Autorité de validation

(Validation Authority abrégé en VA) Elle est en charge de recevoir les demandes de vérification de certificats et de répondre si un certificat est encore valide. Cette autorité est en charge notamment de vérifier si un certificat n'a pas été révoqué. Il est possible de télécharger localement la liste des certificats révoqués. Mais pour réduire le trafic réseau, le protocole OCSP est utilisé pour vérifier la validité d'un certificat auprès de l'autorité de validation.

Archivage

La législation française impose un archivage des certificats (révoqués ou non), des clefs associées et des listes de révocation de certificats. Cette mesure vise a permettre l'exploitation de données à des fins judiciaires, même si le certificat est révoqué.

La création d'un certificat dans une PKI se fait comme suit :

1. Le demandeur fournit les informations nécessaires à la création de son certificat à l'autorité d'enregistrement (en général au moyen d'un formulaire Web). Cette autorité va effectuer les vérifications nécessaires pour confirmer la validité des informations fournies.
2. Si les informations sont validées, l'autorité d'enregistrement va créer une demande de certificat et la communique à l'autorité de certification.
3. Selon le procédé vu précédemment, l'autorité de certification signe la demande de certificat et transmet le certificat au demandeur.
4. Le certificat est archivé pour des besoins légaux.

La vérification des certificats par le client pose plusieurs problèmes :

• Le traitement par le client est long et nécessite beaucoup d'interrogations auprès des différentes parties de la chaîne de confiance.
• La propagation des listes de révocation auprès des clients prend du temps et est très coûteuse en trafic.

La centralisation de la tâche de vérification permet de palier à ces problèmes : une autorité de vérification se charge de faire les vérifications sur les certificats. Ce service, basé sur le protocole OCSP, se chargera de collecter les listes de révocation, de faire les contrôles sur les certificats et de répondre aux demandes des clients qui n'ont plus besoin de le faire.

La vérification de la validité d'un certificat dans le cadre d'une PKI se fait comme suit :

1. L'autorité de validation récupère de manière régulière les listes des certificats révoqués (CRL) de la part de l'autorité de certification. Les listes sont également archivées à des fins légales.
2. Un expéditeur fournit son certificat à un destinataire (par exemple, un serveur Web à un client Web).
3. Le destinataire interroge l'autorité de validation afin de vérifier les informations contenues dans le certificat et si celui-ci n'est pas révoqué.
4. L'autorité de validation réponds si oui ou non le certificat est valide. Cette réponse est bien sûr chiffrée avec la clef privée de l'autorité de vérification afin d'éviter toute attaque.

Voici une architecture recommandée dans le déploiement d'une PKI afin de garantir un maximum de sécurité :

• Une autorité de certification racine très protégée. Pour cela, le mieux est qu'elle soit hors ligne, mais son certificat auto-signé est publié.
• Cette autorité racine produit les certificats d'autorités de certification filles qui seront en ligne et qui signeront les demandes de certificats des utilisateurs.
• Si une autorité fille est corrompue, son certificat est révoqué. L'ensemble du système fonctionne toujours car l'autorité racine est préservée. Il suffit alors de produire une nouvelle autorité de certification fille pour continuer à fournir le service.

Le serveur proxy

Un serveur proxy ou serveur mandataire est un équipement placé entre un client et un serveur pouvant remplir plusieurs fonctions :

• Supervision et filtrage du trafic (censure, blocage des publicités, blocage des menaces, etc.)
• Mise en cache pour améliorer les performances
• Anonymisation des données
• Détection des menaces
• Etc.

De par sa position, un serveur proxy peut également être utilisé à des fins dangereuses. En effet, on peut placer un serveur proxy dans le cas d'un réseau WiFi ouvert afin de collecter des données personnelles, renvoyer de fausses informations, injecter des malwares, etc.

Un proxy transparent est un proxy ne nécessitant pas de paramétrage sur le client et qui n'est pas visible pour l'utilisateur.

L'interception du trafic chiffré est vue comme étant une attaque man in the middle. L'interception des flux chiffrés se fait en chiffrant/déchiffrant les flux au niveau du serveur proxy, ce dernier ayant sa propre autorité de certification afin de re-chiffrer la liaison entre le client et lui-même :

1. Au préalable, le client doit ajouter le certificat du serveur proxy dans son magasin de certificats de confiance.
2. Le client envoie sa requête au serveur destinataire.
3. Le serveur proxy intercepte la requête, l'analyse et la transmet au serveur destinataire comme si elle provenait de lui.
4. Le serveur destinataire réponds au serveur proxy en fournissant sa clef publique.
5. Le serveur proxy déchiffre la communication et l'analyse.
6. Il chiffre la réponse avec un certificat généré à la volée pour le domaine et la transmet au client.
7. Le client déchiffre la réponse avec la clef publique du proxy.

Un proxy inverse est un serveur proxy placé avant un service Web. Un utilisateur du service contactera le serveur proxy inverse pour accéder au service Web. Il permet d'effectuer les opérations suivantes :

• Mise en cache du contenu
• Équilibrage de charge entre plusieurs serveurs Web
• Assurer le chiffrement de la communication
• Gérer l'authentification du service Web

Le pare-feu et les ACL

Un pare-feu (ou firewall en anglais) est un dispositif matériel et/ou logiciel permettant de contrôler et filtrer les flux réseaux. Il permet notamment de filtrer le trafic entre le réseau interne et le réseau public. On parle alors d'une passerelle filtrante. On retrouve également des pare-feu à l'intersection des différentes zones réseau. Il protège des connexions et attaques malveillantes, il empêche la prolifération des attaques en cloisonnant le réseau.

Le pare-feu permet également d'auditer ou surveiller les flux entrants et sortants d'une zone car il s'agit du point de passage obligé pour passer d'une zone à l'autre.

Une Access Control List (ACL) est une liste de règles autorisant ou interdisant un trafic particulier sur un pare-feu, un routeur ou un serveur. Elles sont exécutées de haut en bas.

Il existe deux politiques possibles pour un pare-feu :

Liste noire

Tout ce qui n'est pas interdit est autorisé. Ce mode de fonctionnement est à bannir.

Liste banche

Tout ce qui n'est pas autorisé est interdit. Ce mode de fonctionnement est à adopter.

Chaque règle de pare-feu est composée des éléments suivants :

• Adresse IP source
• Adresse IP destination
• Type (TCP, UDP, ICMP, IP, etc.)
• Numéro de port
• L'action à effectuer (ACCEPT, REJECT ou DROP)

Il existe plusieurs types de pare-feu :

Pare-feu sans état

Il s'agit de la méthode la plus simple et la plus ancienne de filtrage du trafic. Le pare-feu analyse les paquets individuellement, indépendamment les uns des autres. Il filtre selon les adresses IP source et destination, le port source et destination et le protocole réseau. Le fait d'analyser les paquets de manière individuelle ne permet pas de gérer la notion de session et est de moins en moins utilisé. Cela reste néanmoins un moyen simple de gérer quels services sont exposés.

Pare-feu à états

Cette méthode suit la connexion entre le client et le serveur et tient compte des anciens paquets. On filtre selon l'adresse IP source et destination, le protocole et seulement le port destination à filtrer car le port source est choisi aléatoirement lors de l'établissement de la connexion.

Pare-feu applicatif

Il s'agit du proxy, abordé plus en détail dans le chapitre dédié de ce cours. Il filtre le flux par application et vérifie que les requêtes sont bien conformes aux protocoles. Il s'agit du type de pare-feu permettant la plus grande finesse de règles et le plus consommateur en ressources. Ainsi, il convient de le placer en aval et sur une machine distincte d'un pare-feu dynamique pour limiter les requêtes à traiter en effectuant un premier tri. Ce type de pare-feu interprétant les requêtes transmises, il est vulnérables aux attaques sur la couche application.

Pour être efficace, l'intégralité des flux entrants et sortants d'une zone doivent transiter par le pare-feu. Il doit être incontournable. Il peut également constituer un point unique de défaillance : s'il vient à être hors service, la zone est soit coupée du reste du réseau, soit accessible sans aucune restriction.

Le VPN

Ce cours n'est sponsorisé par aucun service de VPN commercial, contrairement aux vidéos YouTube.

Le réseau privé virtuel, en anglais Virtual Private Network (VPN), est un réseau créé virtuellement en utilisant le réseau Internet. Il permet de créer un lien direct entre deux machines distantes et isole leurs communications entre-elles du reste du réseau public.

Le VPN est une solution à moindre frais de raccorder de manière sécurisée différents sites d'une entreprise, une entreprise à un partenaire ou de permettre aux employés d'avoir recours au télétravail ou au travail nomade. Les données transitent de manière chiffrée dans un tunnel VPN.

Un VPN permet de se prémunir des attaques suivantes :

Écoute et modification du trafic

La communication étant chiffrée, la confidentialité des communications est assurée.

Usurpation d'identité

L'authentification mutuelle entre les deux réseaux empêche les attaques du type man in the middle.

Rejeu de la communication

Il est impossible de rejouer une session.

Attaques par rebond

Le tunnel est ouvert uniquement entre les réseaux autorisés.

Il existe différent protocoles VPN dont voici les plus courants :

L2TP

Protocole de couche 2 normalisé par les RFC 2661 et RFC 3931 permettant de transporter des sessions PPP, notamment entre les opérateurs de collecte de trafic et les FAI.

IPsec

Protocole de couche 3, issu des travaux de l'IETF. Il permet de transporter des données chiffrées pour les réseaux IP. Il s'agit du protocole le plus utilisé.

MPLS

Il est possible de créer des VPN distribués sur un coeur de réseau MPLS pour les couches 2 et 3. Cette solution est utilisée par les opérateurs pour fournir aux clients professionnels des solutions de liaisons entre leurs différents sites.

SSL/TLS

Cela désigne à la fois les VPN en client léger (sur navigateur Web, ne nécessitant pas d'installation de logiciel spécifique), ainsi que des technologies de VPN telles que OpenVPN.

Concernant les services de VPN commerciaux, il est important de prendre en compte que la communication est chiffrée entre le client et l'extrémité du tunnel VPN. Une fois à l'extérieur du tunnel, la communication peux-être de nouveau vulnérable aux attaques citées ci-dessus. Le fournisseur de service VPN accède aux communications en clair car il se charge du déchiffrement. Ainsi, il est primordial de s'assurer de l'usage fait par le fournisseur de VPN des données qui transitent.

Architectures réseau sécurisées et DMZ

Les règles d'architecture réseau décrites ici sont dérivées du guide "Recommandations relatives à l'interconnexion d'un système d'information à Internet", disponible sur le site de l'ANSSI : https://www.ssi.gouv.fr/uploads/2020/06/anssi-guide-passerelle_internet_securisee-v3.pdf

Afin d'isoler et appliquer les politiques adaptées aux différents usages (bureautique, serveurs à usages internes, serveurs à usages externes, etc.), il est nécessaire de segmenter le réseau en plusieurs zones distinctes séparées par des routeurs et pare-feu assurant la jonction et le filtrage des flux interzones.

Une première règle à respecter dans le déploiement d'un réseau d'entreprise est de séparer le SI interne du reste d'Internet par une zone démilitarisée (DMZ). Cette zone, faisant office de tampon assurant un filtrage efficace des flux, est connectée de part et d'autre par des routeurs et des pare-feu distincts et maîtrisés, c'est-à-dire gérés intégralement par votre organisation. Les services exposés sur Internet seront situés dans cette DMZ et sur une infrastructure physique dédiée. Il est vivement recommandé que ces routeurs et pare-feu soient sur des infrastructures physiques différentes. La DMZ ne doit pas contenir de services essentiels pour le fonctionnement de la société et doit être considérée comme perdable. Il faut également que les différents équipements de sécurité (pare-feu, proxy, routeur, annuaire, etc.) soient sur des équipements physiques distincts.

Les flux entre le SI interne et Internet doivent également transiter par un serveur proxy situé en DMZ. Celui-ci doit être incontournable, en mode explicite, configuré en local sur chaque poste client et sera en charge du filtrage du trafic et de la journalisation des activités. Votre serveur proxy se chargera de la rupture de flux (agir en intermédiaire entre le client et le serveur finaux d'une communication en empêchant un lien direct entre ceux-ci) et appliquera les règles de sécurité de votre entreprise.

Il est crucial pour la sécurité de votre SI que les éléments situés en DMZ ne puissent pas requêter directement l'annuaire situé dans le SI interne. Vous pouvez pour résoudre cela :

• Créer une copie minimaliste et en lecture seule de l'annuaire interne.
• Créer un serveur proxy entre vos services et l'annuaire.
• Créer un serveur proxy en charge de l'authentification au sein de votre SI interne pour les services en DMZ nécessitant une authentification.

Vous pouvez découper votre DMZ en plusieurs zones remplissant différentes fonctions. On peut retrouver :

1. La zone d'accès interne avec le serveur proxy et le filtrage depuis et vers la zone interne
2. La zone des services internes avec le résolveur DNS (voir plus loin) et la copie d'annuaire pour le proxy
3. La zone des services exposés sur Internet
4. La zone des services relais comporte la rupture des flux, l'analyse du trafic depuis et vers Internet, les terminaisons VPN, les proxy Web et le relais de messagerie (voir plus loin).
5. La zone d'accès externes en charge du filtrage du trafic

Il est recommandé de séparer ces différentes zones par des pare-feu et d'utiliser des commutateurs dédiés au sein de chaque zone (ou à défaut, des VLAN différents).

Les clients internes du SI ne doivent pas être en mesure de requêter de serveur DNS autre que celui du SI interne dédié aux domaines locaux. Seul le serveur proxy doit être en mesure de requêter un résolveur DNS placé dans la DMZ.

Dans le cas d'une organisation comprenant plusieurs sites, chaque site doit disposer de sa DMZ propre. L'interconnexion VPN entre les différents sites, un cloud privé ou tout autre service étant interconnecté via Internet ne doit pas aboutir dans le SI interne, mais dans la DMZ comme un flux provenant de l'extérieur, dans la zone des services relais. Si les différents sites accèdent à Internet, s'assurer que la politique de sécurité est homogène.

Les routeurs, hors du routeur d'interconnexion vers Internet, doivent être configurés statiquement et ne doivent pas permettre l'usage des protocoles de routage dynamique (RIP, OSPF, etc.). Les pare-feu doivent être configurés pour ignorer les paquets et non les refuser. Configurez l'ensemble des services afin qu'ils communiquent le moins d'informations possibles sur votre infrastructure. Chaque personne se voit attribuer un compte nominatif et personnel (pas de comptes génériques). Centralisez les journaux de vos équipements dans un serveur unique renforcé.

Pour les services Web, des proxy inverses doivent être mis en place pour assurer l'authentification des accès, le chiffrement de la communication, le contrôle d'accès, la journalisation, etc.

Pour les services de messagerie, le Mail Transfer Agent (MTA, serveur d'envoi) et le Mail Delivery Agent (MDA, serveur stockant les boîtes de messagerie) doivent être séparés. Le MTA doit être placé dans la zone des services relais alors que le MDA doit être situé dans le SI interne. Le MTA doit analyser et filtrer les messages entrant et sortants (spam, virus, etc.). Éviter le déploiement d'un service Webmail qui engendrerait un flux jusque dans le SI interne \inclfigure{dmz8}. Seuls les protocoles chiffrés doivent être utilisables par les clients (SMTPS, IMAPS et POPS). Comme vu pendant le cours de services réseaux avancés, déployez le SPF, DKIM, DMARC et DNSSEC.

Sécurisation des services réseaux

Au-delà des durcissements à réaliser sur votre réseau, ainsi que sur le système d'exploitation, des opérations sont à effectuer sur les services s'exécutant sur vos serveurs :

Effectuer régulièrement les mises à jour

Les mises à jour publiées par les différents éditeurs corrigent des failles et apportent des améliorations de sécurité. Il est primordial d'appliquer régulièrement les mises à jours de système d'exploitation, ainsi que des logiciels installés sur le serveur.

Supprimer ou désactiver tout ce qui est inutile

Afin de réduire la surface d'attaque, il est nécessaire de désactiver et supprimer tout ce qui n’est pas strictement nécessaire au bon fonctionnement du serveur. Tout service, fichier, application superflu offrent une surface d'attaque potentielle à un attaquant. Par exemple, une interface graphique sur un serveur Linux est superflu. N'activer que les modules de vos services qui sont nécessaires.

Changer le port d'écoute quand cela est possible

À part pour les services exposés aux utilisateurs (internes ou externes), il est recommandé de changer le port d'écoute par défaut des services. Cela est notamment vrai pour SSH, qui est particulièrement ciblé par les attaquants.

Limiter les interfaces et adresses d'écoute

Lorsqu'un service n'est utilisé que par un réseau spécifique, comme le réseau interne ou en rebouclage du serveur, il est recommandé de limiter l'écoute des services aux adresses IP autorisées et aux interfaces sur lesquelles les requêtes légitimes arrivent.

Installer fail2ban

Cet outil analyse les journaux des services et bloque les attaques en force brute. Il est rapide à installer, facile à configurer et apporte une protection supplémentaire.

Ne pas exécuter les services en root

En cas de corruption d'un service, il convient de limiter le champ d'action de l'attaque en exécutant les services réseaux avec des comptes techniques n'ayant accès qu'à ce qui est nécessaire pour fonctionner. L'usage du compte root pour l'exécution des services réseaux est à proscrire.

Isoler les services sur des machines séparées

Pour limiter la propagation d'une attaque, il convient d'isoler les services réseaux sur des machines (virtuelles ou physiques). À défaut, l'usage de conteneurs permet d'apporter une meilleure isolation que d'exécuter directement tous les services sur une machine unique.

Forcer le chiffrement des communications

Pour sécuriser les communications entre les clients et le serveur, il est primordial d'activer le chiffrement des communications et de désactiver la version non chiffrée. Pour HTTP, il est possible de paramétrer le serveur Web pour rediriger le trafic vers HTTPS. Pour Apache, cela se configure comme suit :

RewriteEngine On
RewriteCond %{SERVER_NAME} =<votre domaine>
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Appliquer une politique de moindre habilitation

Chaque utilisateur peut être, volontairement ou non, source d'une attaque (connexion à partir d'un poste infecté, erreurs, acte malveillant). Ainsi, il convient d'habiliter les utilisateurs uniquement aux services auxquels ils ont besoin. Il ne faut pas confondre besoin et envie : un utilisateur peut dire avoir besoin d'un service, il faut alors vérifier la nécessité de l'habilitation demandée avant de la lui accorder. Une fois qu'un utilisateur n'a plus besoin des habilitations (mutation, départ, etc.), il est primordial de les lui retirer.

Journaliser les événements sur un serveur de journalisation

Lors de la compromission d'un service, ce dernier conservera trace dans les journaux. Ainsi, il convient d'activer la journalisation des services et faire une copie des journaux vers un serveur de journalisation dédié et correctement sécurisé.

Sécuriser l'accès physique aux serveurs

Lorsqu'un attaquant a un accès physique au serveur, il est très aisé pour lui d'effectuer une action malveillante dessus. Il convient alors d'isoler physiquement les serveurs dans un local dédié, fermé et sécurisé et dont les accès sont attribués aux seules personnes ayant nécessité de pénétrer dans le local. Un serveur ne doit en aucun cas être mutualisé avec un poste utilisateur.

Mettre en place une supervision des services

Il est nécessaire de surveiller le bon fonctionnement des services réseaux, ainsi que la bonne santé des serveurs les exécutant. Pour cela, une solution de supervision, qui indiquera en temps réel toute anomalie afin de réagir le plus rapidement possible, sera mise en place.

Pour aller plus loin

De nombreux guides, fournis par l'Agence Nationale de la Sécurité des Systèmes d'Information, expliquent plus en détails comment installer et configurer les différents composants d'un réseau d'entreprise de manière sécurisée.

Les guides sont disponibles ici : https://www.ssi.gouv.fr/entreprise/bonnes-pratiques