GuiguiAbloc

Conception d’un Firewall Rouge en Haute-Disponiblité (1ère Partie)

En matière de Firewall, il existe pléthore de solutions payantes ou libres, packagées ou non.

Vous trouverez bien entendu les solutions propriétaires, matérielles ou logicielles, telles que CheckPoint, Pix, WatchGuard, Juniper, Arkoon etc… et des solutions libres « tout en un », comme Ipcop, M0n0wall, PfSense etc…

Bref, je ne ferais pas le tour, Google est votre ami, mais dans notre architecture, nous avons principalement deux choix : Iptables sous Linux ou PacketFilter sour *BSD.

Mon choix s’est porté sur PacketFilter sous OpenBSD.

Je ne m’engagerais pas dans une longue discussion sur les différences Iptables/PacketFilter, mais pour avoir longuement utilisé les deux, ma préférence va vers PacketFilter.

Je vous conseille d’ailleurs la lecture de cet excellent article :

http://www.unixgarden.com/index.php/securite/pf-pour-les-nuls

Mise au point : Avant tout, je veux que vous preniez pleinement conscience qu’un Firewall ne réglera pas définitivement vos problèmes de sécurité.

Ce n’est qu’un élément parmi tant d’autres et la façon dont vous allez l’utiliser contribuera également à votre protection.

D’ailleurs, je vais vous donner un petit exemple (l’analogie est tordue je l’avoue, mais moi aussi ) :

Imaginons que vous décidiez de faire une fête chez vous (ou le chez vous est votre LAN).

Vous embauchez un type baraqué, tout en muscles, qui se chargera de vérifier que les gens entrent bien par la porte d’entrée et non par les fenêtres ou la porte arrière et qu’ils ne se baladent pas non plus dans votre chambre ou des pièces de la maison qui n’ont rien à voir avec la fête.

On peut dire que c’est le comportement basique d’un firewall.

Par contre, tout le monde vient et pas forcément des gens que vous souhaitiez voir. Donc vous décidez de ne laisser entrer que les gens que vous avez invité et votre Mastodonte vous aide à ne laisser assister à votre fête que les gens dûment accrédités.

Là, vous vous dites, « ouais super, pas de soucis ». Erreur, jeune padawan…

Ne laisser entrer que les gens invités est une bonne chose (et un comportement un peu plus évolué de votre firewall), mais votre pote qui 4 heures plus tard, complètement bourré, vomi sur votre canapé, vous regrettez amérement de l’avoir invité…

Si vous l’aviez fouillé à l’entrée et découvert une bouteille de whisky dans son blouson, cela vous aurait peut-être mis la puce à l’oreille sur ses intentions futures.

Et même s’il n’avait rien, jeter un petit coup d’oeil sur lui durant la soirée et voir qu’il abuse un peu des verres présents, vous aurez peut-être alerté et permettre d’intervenir avant qu’il salisse votre beau canapé en tissu

Bref, vous voyez que la sécurité de ne se limite pas à controler qui entre et qui sort, mais également à surveiller le comportement des invités . Le pire étant, quand vous vous interrogerez sur votre sûreté, de vous demander pourquoi votre copine à son pull à l’envers à la fin de la soirée…

Je sais l’exemple est facile et un peu large, mais il a le mérite d’essayer de vous faire comprendre que votre Firewall ne fera pas tout.

Sur ce, commencons.

J’ai décidé de dédier des équipements au rôle de Firewall.

Pour cela, vous pouvez très bien récupérer de vieux Pentium 266 Mhz qui feront très bien l’affaire (quoiqu’un peu bruyant ).

Personnellement, j’ai choisi la solution Soekris.

Les boitiers Soekris sont des « mini-pc » (communément appelé Appliance) composé d’un processeur 266 Mhz (pour le mien), de 256 Mo de RAM et de 3 ports ethernet.

Ils ont l’avantage d’être totalement silencieux (pas de ventilateur) et ne consomme qu’environ 15 W.

Je l’ai acheté chez KD85 , le site de l’excellent Wim, personnage déjà emblématique du monde OpenBSD en Europe
Toujours pour Elwina , je l’ai acheté :

Total: EUR 275.00 + Shipping (EUR 19.98) + VAT (21% EUR 61.95)= EUR 356.93

(4801-60 + boitier + alim + support disque ) .

L’idéal pour notre infrastructure étant d’en avoir 2 (pour la haute disponibilité).

Le coût de la « bête » étant assez élevé, le deuxième firewall peut très bien (et c’est ce que j’ai fait), tourné dans une machine virtuelle (VMware, Xen etc…) a qui l’ont aura affacté des cartes réseaux dédiés.

L’installation d’OpenBSD 4.2 sur Soekris ne pose vraiment aucun soucis et vous trouverez des tutos à foison sur le Net (idem pour l’installation sous VMware).

Personnellement, j’ai opté pour une installation sur un disque dur de 40Go via PXE.

Côté configuration de base, j’ai affecté aux pattes rouges sisO et em0 (carte ethernet coté Freebox), l’ip 192.168.0.5 pour le firewall-a et 192.168.0.15 pour le firewall-b.

Les interfaces côté Vert ont pour ip 192.168.1.5 et 192.168.1.15.

Nous gardons la troisième interface pour la synchronisation des états firewall que nous allons voir plus loin.

Nos deux « firewalls » installés et configurés sous OpenBSD 4.2, nous allons maintenant monté notre haute disponibilité avec un concept de tuerie : CARP.

A suivre…

Si vous utilisez OpenBSD (c’est bien déjà ) vous avez sûrement entendu parler ou jouer avec CARP

Si ce n’est pas le cas, dépêchez vous de vous y mettre, vous passez à côté d’un mécanisme de redondance très puissant.

Sans entrer dans les détails, la FAQ d’OpenBSD vous éclairera plus, CARP permet d’assigner une VIP (ip virtuelle) que se partage deux serveurs. En cas de défaillance de l’un, l’autre prend la relève dans la seconde. Si en plus je vous dis que vous pouvez synchroniser vos états de sessions Firewall PF en même temps, là je suis certain que vous êtes déjà en train d’éplucher la documentation. (oui, oui, si j’ai le temps, je ferais un petit billet sur CARP et pfsync, même si d’autres personnes ont fait d’excellents tutos la dessus).

Bref, ce n’est pas le but de ce billet mais un petit « bug » anodin que je vous propose de corriger si vous décidez d’utiliser VMware pour monter l’un ou les deux serveurs OpenBSD.

Pour être fonctionnel, CARP a besoin de passer les interfaces sur lesquelles il écoute en mode Promiscuous afin d’ « écouter » le trafic.

Sur une carte réseau normale, pas de soucis, cela se fait naturellement. Par contre, sous VMware, vous ne vous adressez pas directement au matériel mais à une couche d’émulation qui elle, s’adresse au hardware.

C’est là que les soucis arrivent…

En effet, dans le *bsd, on voit bien la carte passer dans ce mode :

Puffy:~# ifconfig sis1
sis1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
Mais la véritable carte réseau, elle ne passe pas dans ce mode.

Ceci est tout simplement un problème de droits d’accès au périphériques /dev/vmnet*

Pour remédier a cela, un simple :
vmbox:# chgrp <newgroup> /dev/vmnet0
vmbox:# chmod g+rw /dev/vmnet0
vmbox:# /etc/init.d/vmware restart

corrigera le problème.

Bien sûr, « newgroup » correspond à un groupe dans lequel fait parti l’utilisateur faisant tourner le serveur VMware.

Vous trouverez plus d’infos sur le site de VMware.