Conception sécurisé de réseaux

Zone démilitarisée

En sécurité informatique, une DMZ ou zone démilitarisée est un sous-réseau physique ou logique qui contient et expose les services externes d’une organisation à un réseau non fiable, généralement plus vaste, tel que l’Internet. L’objectif d’une DMZ est d’ajouter une couche de sécurité supplémentaire au réseau local (LAN) d’une organisation : un hôte externe ne peut accéder qu’à ce qui est exposé dans la DMZ, tandis que le reste du réseau de l’organisation est protégé derrière un pare-feu. Une DMZ fonctionne comme un petit réseau isolé placé entre l’Internet et le réseau privé.

Tout service fourni aux utilisateurs du réseau externe peut être placé dans la zone démilitarisée. Les services les plus courants :

  • les serveurs web
  • les serveurs de messagerie
  • les serveurs FTP
  • ServeursVoIP

Architecture

Il existe de nombreuses façons de concevoir un réseau avec une zone démilitarisée. Deux des méthodes les plus élémentaires consistent à utiliser un seul pare-feu, également connu sous le nom de modèle à trois pattes (three legged model), et deux pare-feu, également connus sous le nom de back to back.

Architecture à un seul pare-feu

“DMZ avec un pare-feu” “DMZ avec un pare-feu”

Un seul pare-feu doté d’au moins trois interfaces réseau peut être utilisé pour créer une architecture réseau contenant une zone démilitarisée.

  • Le réseau externe (WAN) est connecté au pare-feu sur la première interface réseau,

  • le réseau interne est connecté à la deuxième interface réseau

  • La DMZ est formée à partir de la troisième interface réseau.

L’inconvénient : Le pare-feu devient un point de défaillance unique (single point of failure) pour le réseau et doit être capable de gérer tout le trafic allant vers la DMZ mais aussi le trafic allant vers le réseau interne.

Architecture à deux pare-feu

“DMZ avec deux pare-feu” “DMZ avec deux pare-feu”

L’approche la plus sûre consiste à utiliser deux pare-feu pour créer une zone démilitarisée. Le premier pare-feu doit être configuré de manière à n’autoriser que le trafic destiné à la zone démilitarisée. Le second pare-feu (également appelé « back-end » ou pare-feu « interne ») n’autorise le trafic vers la DMZ qu’à partir du réseau interne. Cette configuration est considérée comme plus sûre, car il faudrait que deux dispositifs soient compromis.

Inconvénients de cette architecture : elle est plus coûteuse, tant à l’achat qu’à la gestion La pratique consistant à utiliser différents pare-feu de différents fournisseurs est parfois décrite comme un élément d’une stratégie de sécurité de type « défense en profondeur » (defense in depth).

Les systèmes de détection/prévention d’intrusion (IDS/IPS)

Détection et prévention d’intrusion

La détection et la prévention d’intrusion se font en reniflant ce qui se passe sur le réseau et peuvent être basés sur:

  • Les signatures (similaire aux antivirus): ce sont les éléments distinctifs permettant d’identifier un exploit. Il faut qu’il y ait déjà eu des victimes de l’exploit et qu’il ait été détecté. Nécessite des bibliothèques de signatures et des mises à jour très régulières.

  • Les anomalies: le système connait le comportement normal du réseau et génèrera des alertes lorsque ce comportement s’éloignera de la norme définie. Risque élevé de faux positif si la normale n’est pas définie correctement.

Signatures Anomalies
Mises à jour fréquentes Oui Non
Risque de 0-day Oui Moins
Faux positifs Peu Beaucoup

Différence entre IDS (Intrusion Detection System) et IPS (Intrusion Prevention System)

  • À droite: détection.

  • À gauche: prévention.

Quel est le plus efficace?

Fonctionnement:

  1. Capture

  2. Analyse

  3. Recherche de motif

  4. Alertes

HTTP HTTP

Renifleurs de paquets

Exemple de renifleurs

  • Wireshark (Windows)

  • Snoop (Unix Solaris)

  • Tcpdump, Ethereal (Linux)

  • Scapy (Python)

  • Snort (Linux)

SNORT fonctionne en 3 modes:

  • Renifleur de paquets

  • Logueur de paquets

  • IDS/IPS

Snort

Mode IDS/IPS: il faut des règles!

Peuvent être créées ou téléchargées sur le site de SNORT.

Composition d’une règle:

  • Action: alert, log, pass, activate, dynamic, drop, reject, sdrop.

  • Protocol: TCP, UDP, ICMP, IP

  • IP source (pas de nom) ou any

  • Port source ou any

  • Direction: ->, <> (ATTENTION: pas de <-)

  • IP destination ou any

  • Port destination ou any

  • Options: msg (message de l’alerte), sid (identifiant), content (contenu du paquet), logto (fichier pour loguer la règle)

Composition d’un règle:

[Action] [protocol] [IP source] [port source] [direction] [IP dest] [port dest] [options]

Exemple:

Règle qui alerte de tous traffic ICMP (ping)

alert icmp any any -> any any ( msg:"Traffic ICMP détecté"; sid:1; metadata:policy security-ips alert; )

Règle qui alerte si une machine tente de faire une connexion SSH

alert tcp any any -> any 22 ( msg:"Tentative de connexion SSH"; sid:2; metadata:policy security-ips alert; )

Ouvrez la machine Ubuntu fournie. Snort y est déjà installé.

Configurez 3 interfaces :

  • Une en NAT
  • Deux en LAN Segment (192.168.10.0/24 et 192.168.20.0/24)

Attribuez des adresses IP statiques aux deux interfaces LAN Segment :

sudo nmcli con mod ens37 ipv4.addresses 192.168.10.1/24
sudo nmcli con mod ens37 ipv4.method manual
sudo nmcli con down ens37 
sudo nmcli con up ens37
sudo nmcli con mod ens36 ipv4.addresses 192.168.20.1/24
sudo nmcli con mod ens36 ipv4.method manual
sudo nmcli con down ens36 
sudo nmcli con up ens36

Laboratoire 1 : Snort en mode passive

Les règles doivent être écrites dans le fichier /etc/rules/rules.local

écrivez une règle pour alerter sur tout traffic ICMP

alert icmp any <> any ( msg:"Traffic ICMP détecté"; sid:1; metadata:policy security-ips alert; )

Puis lancez SNORT sur l’interface en NAT :

sudo snort -c /etc/snort/snort.lua -A alert_fast -i ens33

Faites un ping de votre machine vers la VM Ubuntu. Des alertes doivent apparaître.

Laboratoire 1bis - utilisation de OpenAppId

OpenAppId est un module de Snort qui permet la détection d’applications et de services. OpenAppID identifie le trafic au niveau de la couche application (couche 7) et permet de construire des règles sur ce trafic (par exemple, pour interdire l’utilisation de Facebook).

Exemple de règles qui détecte le traffic vers Facebook :

alert tcp any any -> any any ( msg:"Facebook Detecté"; appids:"Facebook"; sid:3; metadata:policy security-ips alert; )

Copiez cette règle dans le fichier rules.local et lancez snort :

snort -c /etc/snort/snort.lua -i ens33 -A alert_fast -s 65535 -k none

Ouvrez un navigateur et allez sur Facebook, vous verrez que Snort détecte ce traffic.

Utilisation des signatures Snort

Mise à jour des règles à partir des signatures fournies par SNORT

Il existe deux types de signatures fournies par Snort :

  • Signatures communautaires (Community rules) : des signatures maintenues par la communauté.
  • Registered rules : Il faut créer un compte pour les télécharger.

Dans la VM Ubuntu fournie, les registered rules et community rules sont déjà téléchargées : fichier/etc/rules/snort3-community-rules/snort3-community.rules et répertoire /etc/rules/registered-rules/so-rules respectivement.

Pour utiliser les signatures de la communauté Snort :

sudo snort -c /etc/snort/snort.lua -R /etc/rules/snort3-community-rules/snort3-community.rules -A alert_fast -i ens33 -s 65535 -k none

Pour utiliser les Registered rules, naviguez dans le répertoire /etc/rules/registered-rules/so-rules/ et choisissez celles que vous désirez tester.

Laboratoire 2 - Snort en mode inline

Snort est en mode passive par défaut (il renifle sur une interface), mais peut aussi être utilisé en mode inline

Ouvrez une machine client avec une seule inteface sur le premier LAN segment (disons 192.168.10.0/24), assignez-lui une adresse IP statique et donnez lui comme passerelle par défaut 192.168.10.1.

Lancez Snort avec la commande donnée ci-dessus.

sudo snort -c /etc/snort/snort.lua -Q -i "ens37:ens38" -A alert_fast --daq afpacket
  • -Q et --daq afpacket pour activer le mode inline
  • -i "ens37:ens38" pour les 2 interfaces sur lesquelles snort va agir en tant que bridge.

Essayez de ping 192.168.20.1 depuis votre client. Que remarquez-vous ?

Vous devriez voir des alertes apparaître.

VPN

Les VPN permettent à une organisation d’utiliser des réseaux publics (WAN) pour fournir une connexion sécurisée entre les réseaux étendus de l’organisation.

Dans le passé, on utilisait des connexions dédiés pour relier différents batiments d’une même entreprise. Maintenant, au lieu de payer un lien dédié, les entreprises utilisent leur connexion Internet pour interconnecter deux sites en encryptant la communication.

En utilisant l’internet comme passerelle, un réseau privé virtuel (VPN) peut relier de manière sécuritaire tous les bureaux d’une entreprise, les télétravailleurs, les travailleurs mobiles, les clients, les partenaires et les fournisseurs.

Un VPN doit assurer les quatre fonctions suivantes :

  • Authentification - garantir que les données proviennent de la source qu’elles revendiquent.
  • Contrôle d’accès - limiter l’accès des utilisateurs non autorisés au réseau.
  • Confidentialité - Empêcher quiconque de lire les données lorsqu’elles transitent par le réseau.
  • Intégrité des données - Empêcher quiconque d’altérer les données lorsqu’elles transitent par le réseau.

Passerelle et tunnels VPN

  • Une passerelle VPN est un dispositif réseau qui fournit un service de chiffrement et d’authentification à une multitude d’hôtes qui s’y connectent.
  • Depuis l’extérieur (Internet), toutes les communications adressées aux hôtes internes passent par la passerelle.

Deux types de tunnels VPN :

  • Ordinateur-à-passerelle (Computer-to-Gateway) - mis en place pour permettre à un utilisateur distant de se connecter au réseau interne de l’entreprise.
  • Passerelle-à-passerelle (Gateway-to-Gateway) réseau d’entreprise à entreprise (par exemple, connecter des succursales de banques entre elles). Dans ce cas, le tunnel est fait entre deux passerelles.

Exemple de communication :

“VPN sur Internet” “VPN sur Internet”

Un hôte distant (adresse IP 1.2.3.4) souhaite se connecter à un serveur au sein d’un réseau d’entreprise.

  • Le serveur possède l’adresse privée 192.168.1.10 et n’est pas accessible au public.

  • Avant que le client puisse atteindre ce serveur, il doit passer par un serveur VPN dont l’adresse IP publique est 5.6.7.8 et l’adresse interne 192.168.1.1.

  • Toutes les données échangées entre le client et le serveur devront rester confidentielles.

  • Le client se connecte à un serveur VPN via son interface dans le réseau publique.

  • Le serveur VPN attribue une adresse IP au client à partir du sous-réseau du serveur VPN.

  • Le client obtient l’adresse IP interne 192.168.1.50,

  • Le client crée une interface réseau virtuelle à travers laquelle il enverra des paquets cryptés à l’autre point du tunnel.

  • Cette interface reçoit également l’adresse 192.168.1.50.

  • Lorsque le client VPN souhaite communiquer avec le serveur de l’entreprise, il prépare un paquet adressé à 192.168.1.10, le chiffre et l’encapsule dans un paquet IPSec :

“Encapsulation IPSec” “Encapsulation IPSec”

  • Ce paquet est ensuite envoyé au serveur VPN à l’adresse IP 5.6.7.8 via l’internet.
  • Le paquet est crypté de sorte que même si quelqu’un intercepte le paquet sur l’internet, il ne peut en tirer aucune information. Il peut voir que l’hôte distant communique avec un serveur VPN, mais pas le contenu de la communication. Le paquet chiffré “interne” a pour adresse source 192.168.1.50 et pour adresse de destination 192.168.1.10.
  • Le paquet “extérieur” a pour adresse source 1.2.3.4 et pour adresse de destination 5.6.7.8.
  • Lorsque le paquet atteint le serveur VPN à partir d’Internet, le serveur VPN décapsule le paquet interne, le décrypte, trouve que l’adresse de destination est 192.168.1.10 puis le transmet au serveur d’adresse interne 192.168.1.10.

Après un certain temps, le serveur VPN reçoit un paquet de réponse de 192.168.1.10, destiné à 192.168.1.50 :

  • Le serveur VPN consulte sa table de routage, et voit que ce paquet est destiné à un hôte distant qui doit passer par le VPN.
  • Le serveur VPN crypte ce paquet de réponse, l’encapsule dans un paquet VPN et l’envoie sur Internet.
  • Le paquet chiffré “interne” a pour adresse source 192.168.1.10 et pour adresse de destination 192.168.1.50.
  • Le paquet VPN “externe” a pour adresse source 5.6.7.8 et pour adresse de destination 1.2.3.4.
  • L’hôte distant reçoit le paquet. Le client VPN désencapsule le paquet interne, le déchiffre et le transmet au logiciel approprié.