Mise en œuvre du filtrage pour le contexte

Vous devez mettre en oeuvre une politique de filtrage protocolaire avec votre pare-feu Stormshield en tenant compte des recommandations de l'ANSSI.

Evolution de votre infrastructure

Vous devez placer dans la DMZ :

votre serveur DNS

voter serveur Web

Vous devez placer dans le VLAN Serveurs :

votre résolveur DNS

votre serveur DHCP

Pour cela respectez le plan d'adressage défini dans ces VLAN et utilisant les adresses IP statique mises à disposition de chaque équipes.
Lien : Ressources pour le APs

Modifier le rôle d'un des deux VLANS utilisateurs pour en faire un VLAN d'administration.

Placez dans ce VLAN d'administration un client Web d'administration.

Placez votre résolveurDNS dans le VLAN Serveurs ; Placez vos deux VM Web et DNS dans le VLAN DMZ ; Modifiez/verifiez leur configuration IP Vérifiez que les VM accèdent à Internet et sont également accessibles depuis le réseau utilisateurs.

Mise en oeuvre d'une politique de filtrage

La mise en oeuvre de votre politique de filtrage doit s'appuyer sur les recommandations de l'ANSII.

Complétez ce document avec les règles à mettre en oeuvre : politiquefiltrage.odt

Section 1 – Règles d’autorisation des flux à destination du pare-feu

autoriser les flux d'administration (https 443 en TCP, éventuellement ssh 22 en TCP) depuis le poste administrateur vers le SNS

autorisez les flux vers :

le serveur Web (http 80 en TCP) avec une redirection de port,

le serveur DNS (dns 53 en UDP) avec une redirection de port.

Pour des tests, les utilisateurs des autres réseaux sont autorisés à pinger l’interface externe de votre SNS ; cet événement devra lever une alarme mineure.

Section n°2 - Règles d’autorisation des flux émis par le pare-feu

Pour l'instant, ne définissez pas de règles

Section n°3 Règle de protection du pare-feu

Bloquer tout ce qui arrive sur les interfaces du SNS suite aux autorisations définies dans la section 1. Cela est impératif pour prévenir l’ouverture de flux non légitimes à destination de la passerelle.

journaliser cette règle afin de conserver la trace de ces flux illégitimes.

Section n°4 Règles d’autorisation des flux métiers

autoriser depuis le poste administrateur :

les flux d'administration (22 SSH en TCP ; 3389 RDP en TCP - bureau à distance) vers les serveurs (DNS, résolveur DNS, serveur Web)

les flux vers le serveur de temps de l'Université de Tours qui a l'adresse IP 193.52.212.3 et port UDP 123.

Interdire au PC d'administation l’accès à tout autre réseau (Ici Internet). En effet, ce poste ayant des privilèges élevés sur le réseau, le fait de lui bloquer entre autres l’accès internet permet de réduire considérablement sa surface d’attaque.

seul le serveur récursif DNS peut rediriger les requêtes des clients vers le serveur DNS cub.fr.

les autres ordinateurs doivent pouvoir utiliser le résolveur DNS du VLAN serveurs

pour l'instant autoriser les flux des réseaux internes vers Internet (http 80, https 443 en TCP).

Dans une activité ultérieure, vosu contrôlerez les accès vers le Web avec le serveur mandataire (proxy) transparent du SNS.

autoriser les flux des réseaux internes vers le serveur de temps.

les serveurs de la DMZ :

ne doivent pas avoir accès au réseau utilisateurs. En cas de compromission d’un des serveurs hébergés, il doit être impossible de pouvoir remonter vers un des VLAN de l’entreprise.

doivent pouvoir accéder à Internet et au serveur de temps

pour pouvoir effectuer des tests, autorisez le protocole ICMP depuis les réseaux internes

Section n°5 Règles “antiparasites” (facultatif)

Pour l'instant, ne définissez pas de règles

Section n°6 Règle d’interdiction finale

L’ajout d’une règle explicite d’interdiction finale journalisée garantit l’application du modèle de sécurité positif (tout ce qui n’a pas été autorisé précédemment est interdit) et permet de conserver la trace des flux non légitimes.

Retour

Mise en oeuvre de l'UTM Stormshield