AP SIO2 – Mise en place de DMZ dans le réseau BOULARD

Contexte

En seconde année de BTS SIO, j’ai avec 2 collègues imaginés et mis en place le réseau de l’entreprise de transport BOULARD (fictive).

L’entreprise a besoin de se mettre en avant sur Internet. Nous devions alors mettre à disposition des développeurs un environnement pour héberger le site de l’entreprise de manière sécurisé. De plus, les employés souhaités pouvoir accéder au réseau de l’entreprise à distance pour y déposer des fichiers.

La solution que nous avons choisi de mettre en place est la suivante: réaliser une DMZ contenant les différents serveurs accessible de l’extérieur et gérer finement les accès via du filtrage en politique de liste blanche.

Qu’est-ce qu’une DMZ ?

Une DeMilitarized Zone, ou Zone DéMilitarisée en français, est une partie d’un réseau bien séparé du reste des sous-réseaux d’un système d’information contenant les différents services / serveurs accessible depuis l’extérieur (serveur WEB, serveur FTP, etc…)
Elle vise à sécuriser le réseau d’une structure en plaçant les ressources les plus à risques derrière un pare-feu filtrant les requêtes extérieures.

source: barracuda.com

Réseau de l’entreprise

Sans la DMZ, voici à quoi ressemble le réseau de l’entreprise:

Filtrer le traffic entrant et sortant dans cette configuration ne permet pas de le faire dans les meilleures conditions.
Séparer les machines accessible de l’extérieur dans un réseau et VLAN différent fait parti des bonnes pratiques, assurant ainsi une indépendance totale entre ces 2 réseaux.

Deux possibilités:

Ajouter une interface réseau sur notre routeur LAN pointant vers le réseau DMZ

Ajouter un routeur avec une interface DMZ et une interconnexion

J’ai choisi la seconde option pour ne pas empiéter sur le réseau LAN avec une mauvaise règle de filtrage. Si le réseau DMZ venait à tomber, le réseau LAN n’en serait ainsi pas impacté.

IPTABLES

Nous utiliserons l’outil Iptables afin de réaliser le filtrage. Nos routeurs fonctionnent sur des système d’exploitation Debian, l’outil iptables est donc déjà présent sur les machines.
Outil puissant et complet, il permet de réaliser du filtrage et du NAT/PAT.

Iptables est l’outil utilisé par défaut sur les machines Debian jusqu’à la version 10 (Debian Buster). Ensuite, c’est l’outil nftables. Il reste toutefois possible d’utiliser iptables en modifiant les fichiers de configuration de nftables. Voir documentation.

Documentation officielle d’iptables: wiki.debian.org
Ma documentation: docs.clementgentil.fr

Définitions

Pour accéder directement aux règles de filtrage cliquer ici.

Politiques de filtrage

Il existe deux modes de fonctionnement:

Liste Blanche : tout refuser par défaut et n’autoriser que ce que l’on souhaite
- Refuser les paquets sans envoyer d’erreur, agir comme si rien ne s’était passé (POLICY DROP)
- Refuser les paquets en envoyant une erreur pour informer de la tentative infructueuse de connexion (POLICY REJECT)
Liste Noire : tout autoriser par défaut et ne refuser que ce que l’on souhaite (POLICY ACCEPT)

Pour n’importe quelle liste, les règles sont numérotées et si une règle correspond à une trame après une autre règle correspondant, c’est bien la première qui sera prise en compte.

Le fonctionnement en liste blanche DROP correspond le mieux à notre besoin (sécuriser l’infrastructure).

Tables Netfilter

Schéma explicatif du processus de routage

Table FILTER

Il existe 3 chaines principale de la table filter:

FORWARD : trames qui traverse le pare-feu pour atteindre l’intérieur / l’extérieur
INPUT: trames qui sont à destination du pare-feu en entrée
OUTPUT : trames qui sont issues directement du pare-feu en sortie

Les chaines INPUT et OUTPUT sont donc utilisées pour atteindre directement le pare-feu.

Table NAT

Elle gère la modification des adresses et/ou des ports des paquets. Il existe ainsi 3 chaînes NAT:

PREROUTING : modifie les paquets qui n’ont pas encore été traités par le processus de routage
OUTPUT : modifie les paquets générés dans la DMZ avant qu’ils ne soient routés
POSTROUTING : modifie les paquets après le routage, avant qu’ils ne soient envoyés

Table Mangle

Nous n’utiliserons pas cette table dans ce contexte.

Ports

A chaque service correspond un port ou un ensemble de ports. Ce sont les portes d’entrées / de sortie pour contacter au bon endroit les hôtes et serveurs.
Plusieurs plages de ports existent:

0 à 1023: « well-known ports » – ports bien connus, utilisés pour les services les plus courants
1 024 à 49 151: « registrered ports » – ports enregistrés, assignés par l‘IANA
49 152 à 65 535: ports dynamiques utilisés pour tout types de requêtes tcp/udp

Par exemple, le port par défaut des serveurs web est le port 80.

TCP / UDP

Protocoles de couche 4 du modèle OSI. Ils déterminent comment les données sont acheminées entre deux hôtes. Pour une requête on utilise l’un ou l’autre, pas les deux en même temps (ce serait un non-sens). Certains protocoles de plus haut niveau dans le modèle OSI utilise du TCP ou de l’UDP ou les deux en fonction des besoins. HTTP utilise du TCP pour garantir les données tandis que le DNS utilise de l’UDP (occasionnellement du TCP dans des contextes précis)

TCP: apporte du contrôle de flux, utile pour assurer la bonne réception des données
UDP: sans contrôle de flux, utile pour les communications en temps réel: VoIP, flux vidéo, etc…

Expression des besoins

Définissons maintenant les connexions à autoriser:

Autoriser l’extérieur à accéder au serveur Web de la DMZ
1. Rediriger toutes les requêtes WEB vers DMZ / réseau LAN vers serveur web DMZ
  Pour cacher efficacement, il faudrait mettre ces règles sur le routeur de groupe.
Autoriser l’extérieur à accéder au serveur FTP de la DMZ
Autoriser les connexions SSH vers les serveurs de la DMZ depuis le réseau LAN
Autoriser les serveurs de la DMZ à se mettre à jour
1. Autoriser les requêtes HTTP et HTTPS depuis les serveurs DMZ vers l’extérieur
2. Autoriser les requêtes DNS depuis les serveurs DMZ vers le
Autoriser les connexions SSH depuis le réseau LAN vers le routeur DMZ

Il faut évidemment penser à faire les règles retours si nécessaire. On peut également réaliser une règle qui indique d’autoriser les paquets s’ils sont liés a une communication déjà établie, c’est ce que l’on appelle le mode stateful. Cela permet de ne renseigner qu’une règle aller mais baisse le niveau de sécurité en acceptant systématiquement les trames retours.

Après avoir dressé cette liste, nous pouvons réfléchir d’un point de vue technique sur ces points:

Ip source
Ip destination
Port source
Port destination
Tcp / udp ?
Forward, Input, Output ?

Réalisation du filtrage

Règles au format iptables:

# Autoriser l'extérieur à accéder au serveur Web de la DMZ
    # http / 80
      iptables -t filter -A FORWARD -p tcp --dport 80 -s 192.168.40.0/24 -j ACCEPT # serveur -> client
      iptables -t filter -A FORWARD -p tcp --sport 80 -d 192.168.40.0/24 -j ACCEPT # client -> serveur
    # https / 443
      iptables -t filter -A FORWARD -p tcp --dport 443 -s 192.168.40.0/24 -j ACCEPT # serveur -> client
      iptables -t filter -A FORWARD -p tcp --sport 443 -d 192.168.40.0/24 -j ACCEPT # client -> serveur

# Autoriser les serveurs de la DMZ à se mettre à jour
    # Autoriser les requêtes HTTP depuis les serveurs DMZ vers l'extérieur
      iptables -t filter -A FORWARD -p tcp --dport 80 -s 192.168.40.0/24 -j ACCEPT # serveur -> serveurDMZ | tout derrière le routeur
      iptables -t filter -A FORWARD -p tcp --sport 80 -d 192.168.40.0/24 -j ACCEPT # serveurDMZ -> serveur | tout derrière le routeur
      iptables -t filter -A FORWARD -p tcp --dport 443 -s 192.168.40.0/24 -j ACCEPT # serveur -> serveurDMZ | tout derrière le routeur
      iptables -t filter -A FORWARD -p tcp --sport 443 -d 192.168.40.0/24 -j ACCEPT # serveurDMZ -> serveur | tout derrière le routeur
    
    # Autoriser les requêtes HTTPS depuis le routeur DMZ vers l'extérieur
      iptables -t filter -A OUTPUT -p tcp --dport 80 -s 192.168.45.245/32 -j ACCEPT # serveur -> serveurDMZ | routeurDMZ
      iptables -t filter -A INPUT -p tcp --sport 80 -d 192.168.45.245/32 -j ACCEPT # serveurDMZ -> serveur | routeurDMZ
      iptables -t filter -A OUTPUT -p tcp --dport 443 -s 192.168.45.245/32 -j ACCEPT # serveur -> serveurDMZ | routeurDMZ
      iptables -t filter -A INPUT -p tcp --sport 443 -d 192.168.45.245/32 -j ACCEPT # serveurDMZ -> serveur | routeurDMZ

    # Autoriser les requêtes DNS depuis les serveurs DMZ vers le serveur AD/DNS de l'entreprise
      iptables -t filter -A FORWARD -p udp --dport 53 -j ACCEPT # serveurDNS -> serveurDMZ | tout derrière le routeur
      iptables -t filter -A FORWARD -p udp --sport 53 -j ACCEPT # serveurDMZ -> serveurDNS | tout derrière le routeur
    
    # Autoriser les requêtes DNS depuis le routeur DMZ vers le serveur AD/DNS de l'entreprise      
      iptables -t filter -A OUTPUT -p udp -d 192.168.44.10 --dport 53 -j ACCEPT # serveurDNS -> serveurDMZ | routeurDMZ
      iptables -t filter -A INPUT -p udp -s 192.168.44.10 --sport 53 -j ACCEPT # serveurDMZ -> serveurDNS | routeurDMZ

# Autoriser l'extérieur à accéder au serveur FTP de la DMZ
      iptables -t filter -A FORWARD -p tcp --dport 20:21 -s 192.168.36.0/24 -d 192.168.40.3 -j ACCEPT # serveurFTP -> client
      iptables -t filter -A FORWARD -p tcp --sport 20:21 -s 192.168.40.3 -d 192.168.36.0/24 -j ACCEPT # client -> serveurFTP

# Autoriser SSH
      iptables -t filter -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -d 192.168.40.253 -j ACCEPT # production -> dmz | routeurDMZ
      iptables -t filter -A OUTPUT -p tcp --sport 22 -d 192.168.1.0/24 -s 192.168.40.253 -j ACCEPT # production <- dmz | routeurDMZ
      iptables -t filter -A INPUT -p tcp --dport 22 -s 192.168.36.0/24 -d 192.168.40.253 -j ACCEPT # lan -> dmz | routeurDMZ
      iptables -t filter -A OUTPUT -p tcp --sport 22 -d 192.168.36.0/24 -s 192.168.40.253 -j ACCEPT # lan <- dmz | routeurDMZ
      iptables -t filter -A FORWARD -p tcp --dport 22 -d 192.168.40.0/24 -s 192.168.36.0/24 -j ACCEPT # lan -> dmz | tout derrière le routeur
      iptables -t filter -A FORWARD -p tcp --sport 22 -d 192.168.36.0/24 -s 192.168.40.0/24 -j ACCEPT # lan <- dmz | tout derrière le routeur

# Cacher IP du serveur web
      iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT -d 192.168.45.245/32 --to-destination 192.168.40.2:80

# Stateful mode (autoriser trames de connexions entamées, remplace les règles retours)
    iptables -t filter -A FORWARD -m state --state ESTABLISHED -j ACCEPT

Simplifier la mise en place du filtrage

Différents scénarios peuvent amener le serveur à perdre ses règles de filtrage (redémarrage serveur, mise à jour, etc…)

Plusieurs méthodes s’offrent à nous pour sauvegarder sa configuration:

Scripting

Comme nous avons manuellement renseigné chaque règle, il nous suffit de réaliser un script qui répète chaque opération. De plus, nous pouvons définir un menu permettant d’activer / désactiver le filtrage et de vider la table de filtrage pour les tests.

Détail à venir …

iptables-SAVE / iptables-restore

Iptables contient une solution permettant d’exporter / importer une configuration.
Nous pouvons donc simplement exporter la configuration de filtrage dans un fichier:

iptables-save > /etc/init.d/filtrage.save

Contenu du fichier filtrage.save après sauvegarde

Restauration de la configuration sauvegardée:

iptables-restore /etc/init.d/filtrage.save

Scripting et iptables-save / iptables-restore

Nous pouvons également créer un script qui utilise la fonctionnalité save et restore d’iptables.
Le script nous expose ainsi un menu nous proposant d’exporter ou d’importer puis nous demande de spécifier le chemin du fichier à traiter.
Cela nous permet de garder plusieurs fichiers de sauvegardes différents sur le switch et de centraliser la gestion sur un seul script que nous lançons.