réseau
Anatomie d’une architecture (3)
par guiguiabloc le 18 mar, 2008, sous OpenBSD, réseau, sécurité
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…
Anatomie d’une architecture (2)
par guiguiabloc le 17 mar, 2008, sous cisco, réseau
Nous avons donc notre accès Internet, représenté par une Freebox en mode routeur dont l’ip LAN sera dans mon exemple : 192.168.0.254
J’ai laissé le DHCP actif pour des raisons que nous verrons peut-être plus tard, et concernant les redirections des ports, pour le moment, ne touchons à rien, nous verrons cela quand les Firewalls Rouge seront prêts.
NB : Je dis « les » Firewalls Rouge car dans l’architecture que je vous présente, j’ai 2 firewalls en haute-disponibilité. Si l’un venait à tomber en panne, l’autre reprend la main dans la seconde qui suit.
Où je la branche ma Freebox ???
(non, non, je l’ai pas faite, même si j’y ai pensé très très fort
)
Là je vous laisse 2 choix possible (je sais je suis magnanime…) :
- Relier la Freebox sur un HUB
Pas un switch hein
Vous trouverez des hubs 5 ou 8 ports chez n’importe quel broker informatique pour 5 euros, au pire, fouillez les poubelles des copains :-p.
Pourquoi un hub ? Tout simplement parce que dessus nous allons reliés les pattes rouges de nos 2 firewalls (voir plus bas), mais cela vous permet également d’y brancher votre sonde SNORT
, et donc d’analyser le trafic entrant et sortant sur le Rouge.
Bien entendu, vous n’affecterez pas d’ip a la carte réseau de la sonde et vous ferez en sorte qu’elle ne réponde pas aux requètes ARP…
Ce qui nous donne le schéma suivant :
- Relier la Freebox sur un switch supportant les VLAN
C’est le choix que j’ai fait en achetant un switch Cisco 2924 XL chez Price Minister (pour Elwina qui me demande « combien ça coute ? » (ah les filles…
), je l’ai acheté 197,90 euros d’occasion ).
Avoir du matériel Cisco chez soi est un excellent apprentissage vu qu’il y a de fortes chances que vous retrouviez ce type d’équipement en entreprise. De plus, la puissance de l’ IOS n’est plus à démontrer.
Ce switch permet de gérer 4096 VLAN et possède également le mode SPAN, qui permet de « sniffer » sur une interface, tout ce qui transite sur les interfaces surveillées, idéal donc pour ma sonde réseau.
j’ai créer un VLAN dédié au Rouge dans lequel sont reliés :
la freebox
la patte rouge du firewall-rouge-A
la patte rouge du firewall-rouge-B
la sonde SNORT en mode SPAN sur les 3 interfaces précédentes.
Un petit schéma maison pour mieux comprendre :
Voilà pour aujourd’hui, en espérant avoir été assez clair
, si ce n’est pas le cas, vous savez quoi faire
La prochaine fois, nous nous attaquerons à la réalisation de nos firewalls Rouge…
Anatomie d’une architecture
par guiguiabloc le 16 mar, 2008, sous réseau
Il n’est pas évident de concevoir son réseau personnel. Au fil du temps, il est fréquent de le modifier, le défaire, le reconstruire, la plupart du temps suite à la lecture d’articles techniques, d’expériences personnelles et/ou professionnelles, de rencontres diverses, etc…
Mais peu à peu, on arrive a construire une base qui ma foi, est fort satisfaisante.
Je discute souvent avec d’autres geeks fous personnes passionnées de systèmes et réseaux et les échanges, parfois trolliens, parfois amusants, se construisent sur un but commun : le partage d’expérience.
Je ne pense pas, loin de là, avoir construit une architecture réseau parfaite, mais elle a le mérite d’exister et pour m’en servir tout les jours, elle me permet de m’amuser (oui, oui, on s’amuse avec des serveurs, des flux, des firewalls etc… je vous assure…) et de s’approcher d’un environnement de production.
Quand je parle d’environnement de production, je fais référence a ce que l’on peut rencontré en entreprise, dans des SI d’importance et dont la disponibilité des services est critique.
Reproduire à plus petite échelle un système informatique d’entreprise chez soi est très instructif et, fait non négligeable, permet de s’entrainer ou de tester de nouvelles choses sans trop de risques.
Donc, pour répondre tout d’abord à plusieurs personnes qui me demande de détailler plus en avant mon architecture réseau personnel et vous faire part de mes expériences, j’ai décider d’aborder point par point les différents niveaux, services, serveurs qui composent mon système informatique personnel.
J’avais penser tout d’abord à vous donner une vue globale, mais je trouve plus instructif de commencer petit à petit, comme un puzzle, assemblant les pièces qui composeront votre infrastructure informatique.
Bien évidemment, je vous laisse modifier à votre guise les différentes données afin de concevoir votre propre architecture, vous avez surement des équipements que je n’ai pas et vice-versa.
Pour commencer, et pour répondre à une demande de mon ami « Argos » (et oui, encore lui, je le sentais dépité, proche de la déprime et surtout, pire que tout, près à sortir de chez lui, voir le ciel, le soleil, bref des trucs horribles pour un geek et il me fallait l’en empêcher au plus vite !!!), nous allons voir comment construire un cluster de firewall qui se positionnera en porte d’entrée de notre réseau.
Afin d’avoir les mêmes termes et que l’on se comprenne bien, je vais appliquer une règle simple (et généralement appliquée en sécurité informatique), les étages et les couleurs.
Le rouge désigne l’internet en général, soit les flux entrant ou sortant sur internet.
Le vert désigne le réseau local, le LAN.
Le jaune désigne la DMZ, soit les serveurs dans notre réseau local qui sont isoler dans un réseau particulier et qui « servent » du contenu ou des services sur le réseau internet (serveur web, de messagerie, etc…)
Le bleu (que l’on rencontre parfois), désigne le réseau wifi local.
Les étages sont comme dans une maison, les différents niveaux pour arriver dans une pièce.
Dans « mon » architecture, je désignerais principalement l’étage Rouge, qui correspond aux firewalls internet et l’étage Vert qui correspond au firewalls du LAN et intra VLAN (oui, oui, vous verrais que nous construirons des vlans dans notre réseau et donc un firewall vert qui réglementera les accès entre chez que VLAN mais également la sortie vers le Rouge).
En résumé, nous avons un cluster de firewall Rouge qui filtre les accès Internet entrant sur la DMZ et/ou le LAN (à éviter bien entendu ce dernier
) et un firewall Vert qui filtre les accès entre chaque VLAN et les sorties sur Internet.
Si je ne suis pas assez clair ou confus dans mes explications, n’hésitez pas a m’en faire part
L’Accès Internet :
Je suis abonné ADSL en non-dégroupé sans Ip fixe. Habitant à 320m du NRA, autant vous dire que je suis au débit maximum, soit 8 Mbps IP (environ 1,05 Mo/sec de débit descendant) et 1mbps en Upload.
Pour ma connexion, j’utilise principalement une Freebox v4 en mode routeur.
Mais il m’arrive de basculer sur un autre routeur ADSL (même ip dans le LAN), afin de me connecter à Orange au lieu de Free, ou à d’autres Fournisseur d’Accès Internet.
Et oui, le gros avantage d’être non-dégroupé, c’est que vous pouvez changer de connexion sur votre ligne ADSL.
En clair, je suis abonné chez Free, mais je peux m’authentifier avec un compte Orange ADSL sur ma ligne (bien sur le plus « dur » étant d’avoir un compte ADSL d’un autre FAI sans abonnement physique ADSL, mais ça, je vous laisse trouver les moyens de le faire
).
Voici en résumé, mon accès Internet :
A suivre…
VMware Serveur et 802.1q
par guiguiabloc le 26 fév, 2008, sous réseau
Une des fonctionnalités intéressante de VMware ESX est la gestion des VLANs.
En effet, il n’est pas évident d’avoir autant de cartes réseaux sur son serveur que de VLANs dans son réseau.
Je me suis demandé si VMware serveur pouvait faire la même chose et bien… oui !
Je suppose, bien évidemment, que vous avez déjà des VLANs dans votre réseau (via votre Cisco préféré ou vos serveurs Linux), si ce n’est pas le cas, je vous conseille cet excellent tuto :
Introduction au Routage InterVlan
Pour pouvoir utiliser le 802.1q avec VMware serveur, vous devez patcher les sources avec l’excellent vmware-any-any-update que vous trouverez ci dessous :
Ce patch vous permet également de faire tourner VMware si votre kernel est trop récent pour lui, bref, un patch donc on ne peut plus se passer.
Ensuite, la configuration du reseau se fait en appelant vmware-config.pl.
Il ne vous reste plus qu’a associer vos ethx.x à vos Vmnet (ci-dessous ma configuration apres bascule) :
The following virtual networks have been defined:
. vmnet1 is bridged to eth1
. vmnet2 is bridged to eth3.2
. vmnet10 is bridged to eth3.10
. vmnet20 is bridged to eth1.20
. vmnet51 is bridged to eth2
. vmnet99 is bridged to eth1.99
Dans vos *.vmx de vos machines vituels, il ne reste plus qu’à affecter le vlan qui va bien :
Ethernet0.vnet = « /dev/vmnet99″ (pour mon vlan 99 par exemple)
Et voila, avec 1 ou 2 cartes réseaux et VMware serveur, vous pouvez désormais monter une infrastructure personnel (ou même professionnel), assez… amusante