Souvenirs de BTS: Mise en place d’un Firecluster Watchguard

PTI 3: Mise en place d’un FireCluster WatchGuard

Les objectifs de cette activité sont de mettre en place une tolérance de panne entre deux firewall WatchGuard et sécuriser les échanges entre les réseaux LAN et WAN.

Schéma de l’activité:

Configuration du pare-feu et du proxy

Par défaut le pare-feu autorise toutes les connexions entrantes et sortantes (Dans mon cas, il s’agit de la règle 8). Apres l’avoir désactivé, il faut autoriser les protocoles qui nous sont utiles pour accéder à internet.

La notion de proxy sous WatchGuard permet de filtrer les URL et donc d’interdire l’accès à certains sites aux utilisateurs. La notion de WebBloker ne sera pas démontrée dans ce PTI car la licence n’est plus active.
Voici la fenêtre de configuration de ma règle http-Proxy-PTI (Règle n°2). On peut voir que le mot « yahoo » se retrouve dans une URL, le firewall bloquera la requête.

Configuration du FireCluster

Il existe 2 modes de FireCluster sur WatchGuard :
– L’actif/Actif qui correspond au Load Balancing ,
– L’Actif/Passif ou Actif/ En Vieille qui correspond à la continuité de service en cas de crash d’un équipement.

J’ai décidé de démontrer l’Actif/Passif dans ce PTI.

La technologie WatchGuard pour l’Actif/Passif réside sur le principe qu’un des firewall est Actif, il récupère donc toutes les connexions entrantes et sortantes et qu’un autre firewall est en standby. Les deux firewall sont reliés entre eux par un câble RJ45 croisé et sur une interface dédiée. Ils échangent des informations sur les connexions qui se déroulent actuellement. En cas de crash du Firewall Maitre (Actif) le deuxième Firewall récupère tous les paramètres du Firewall maitre (IP, Connexions en cours) et reprend donc le relai.

Ici nous pouvons voir les paramètres réseaux que se partagent les Firewall, à savoir :
L’interface externe sur eth0 : 192.168.0.49/24
L’interface LAN (Trusted) sur eth1 : 192.168.2.1/24
L’interface DMZ (Optional-1) sur eth2 : 10.0.2.1/24
L’interface eth3 (Optional-2) qui est utilisé pour le FireCluster

Test du FireCluster

Le test sera démontré sur un trafic ICMP au travers d’un ping vers un réseau extérieur.
Les étapes du test :
1/ Initialisation du trafic
2/ Simulation d’une panne d’un équipement
3/ Constat des traces
4/ Réponse du trafic

Constat/Particularité :
On peut voir qu’après 4 ping de perdu, la connexion reprend sur l’autre Firewall.
On peut voir que le Firewall maitre ne reprend pas le relai quand il est de nouveau opérationnel. La notion de Firewall Actif et Passif n’est pas fixe. Le Firewall le premier présent sur le réseau est Actif et le second sera en Passif jusqu’à arrêt du firewall maitre

Conclusion

La mise en place d’un Pare-feu permet le contrôle des protocoles entrant/sortant entre notre réseau LAN et WAN. Cela permet de prévenir le réseau LAN des attaques provenant d’Internet sur des protocoles ou ports non conventionnels.

Le FireCluster permet la tolérance de panne d’un des équipements de sécurité. Il assure une continuité de service. Ce type d’architecture devient une sécurité supplémentaire pour les entreprises travaillant sur des solutions de type SaaS, PaaS, Iaas ou avec des serveurs héberger.

A bientôt.

-Mickaël