Introduction

Nous avions précédemment un routeur Cisco qui s’occupait du NAT, du routage, du filtrage et même du DHCP. Nous allons maintenant durcir notre infrastructure beta avec un pare-feu Stormshield. Ainsi nous aurons un filtrage plus poussé et un meilleur contrôle sur l’activité des utilisateurs.

Configuration des interfaces

Ici nous visualisons nos 4 interfaces réseaux, nous avons les 3 passerelles de nos réseaux sur le LAN ainsi que l’interface de sortie vers Internet.

Accédons maintenant au GUI de notre pare-feu via un navigateur web. Nous configurerons le NAT, les politiques de sécurité et de filtrage ainsi que le blocage de certaines URL. Nous implémenterons également un portail captif relié à l’annuaire LDAP de notre contrôleur de domaine. Nous verrons qu’il également possible pour notre pare-feu d’être un serveur DHCP.

Configuration du NAT

Nous allons tout d’abord créer notre règle :

Nous créons également une route vers le routeur FAI, sans quoi nos machines n’accèderons pas à internet

Politiques de sécurité

Les règles de filtrage protocolaire sur un pare-feu servent à contrôler quels types de trafic (HTTP, FTP, etc.) sont autorisés ou bloqués. Elles permettent de limiter les usages non sécurisés, réduire les risques d’attaque et faire respecter la politique de sécurité du réseau.

Ci-joint en détails nos règles de filtrage :

Portail captif

Les utilisateurs accèderons au réseau via un portail captif. Une fois authentifiés ils est plus facile de rendre compte de leurs actions et de monitorer les activités suspectes. Pour cela ils authentifierons grâce à l’annuaire LDAP

Connexion à l’annuaire :

Mise en place de la règle d’authentification :

Test du portail captif :

Service DHCP

Dans un premier temps nous utiliserons notre pare-feu en tant que serveur DHCP principal et nous configurons des plages pour nos 3 VLANs

Relai DHCP

Nous décidons pour plus de redondance de dédier le service DHCP à notre contrôleur de domaine et à notre serveur RADIUS. Pour cela nous devons activer le relai DHCP

Les requêtes DHCP sont envoyées en broadcast et ne traversent pas les routeurs. Un client ne peut donc pas contacter un serveur DHCP situé sur un autre réseau. Le relai DHCP récupère ces requêtes et les transmet au serveur DHCP distant afin que le client puisse obtenir une adresse IP.

Filtrage SSL

Pour des raisons propres à l’organisation, certains sites web ne sont pas autorisés depuis le réseau MSC. Nous choisirons winamax.fr et betclic.fr pour tester notre filtrage.

Création d’un objet « groupe d’url ». Nous l’appellerons forbidden

Maintenant nous allons lié cet objet à une règle de filtrage SSL

Le filtrage SSL n’est pas autorisé pour tous les sites conformément à la réglementation en vigueur, d’où la présence de l’objet « proxy SSL bypass ». Avec HTTPS, certains proxys font du « SSL inspection » en déchiffrant temporairement les données. Pour les sites bancaires par exemple cela brise le chiffrement de bout en bout et expose potentiellement des données sensibles. C’est donc interdit ou fortement encadré par la réglementation pour protéger la confidentialité et la sécurité des utilisateurs.

Finalement nous allons implémenter ce filtrage dans nos politiques de sécurité :

Effectuons un test avec le site betclic.fr :

VPN

Nous mettons en place un VPN SSL afin de permettre aux opérateurs un accès au VLAN « gestionbord » depuis une connection externe à l’organisation.

Configuration des droits d’accès :

Paramétrage du VPN :

Passons maintenant à un test. Pour simuler une connexion VPN externe, nous installons le client VPN SSL Stormshield sur une machine virtuelle Windows 10 placée dans le même VLAN que notre interface OUT. Lors du test, cette VM possède l’adresse IP 10.15.252.25.

Connexion avec l’utilisateur Hervé DURANT :

Test concluant :