Avr 08

Anatomie d’une architecture (5)

Ecrit le 8 avril 2008 par guiguiabloc

Intégration d’un Firewall Vert

Je vous avez déjà parler des VLANs dans un billet précédent et pour la suite de cet article, je vais m’y attarder un peu plus.

Pour gérer et contrôler mes VLANs, je me sert bien évidemment de cette fonction sur le switch Cisco CATALYST.

La création se fait en deux lignes de commandes :

catalyst#vlan database

catalyst(vlan)#vlan 66 name mon-vlan
VLAN 66 added:
Name: mon-vlan

Apply et voila, le vlan est créé 🙂

Il ne reste plus qu’à l’affecter à un port physique :

catalyst#conf t
Enter configuration commands, one per line. End with CNTL/Z.
catalyst(config)#int f
catalyst(config)#int fastEthernet 0/1
catalyst(config-if)#switchport access vlan 66

Et c’est tout, le serveur/poste relié sur le port 1 du switch Catalyst sera dans le vlan 66.

C’est bien beau tout cela, mais ca ne fait pas grand chose, a part isoler vos réseaux LANs.

Nous allons donc rajouter un équipement supplémentaire qui fera office de routeur (et donc de passerelle pour chaque VLAN), mais également de Firewall Vert.

C’est à dire qu’il gèrera les accès entre les VLANs (un poste dans le vlan 2 voulant voir le site web du serveur dans le vlan 30) et également, fera office de firewall sortant (toutes les machines de mon LAN vers le méchant NainTernet).

L’équipement que j’ai choisi est le Cisco 2611 XM.

Cisco 2600

Toujours pour Elwina 😉 je l’ai acheté 180,00 euros + 17,00 euros de Frais de Port sur eBay.

N.B. : Si vous décidez d’achetez un routeur Cisco de la série 2600 (2610,2611, etc.), soyez attentif :

Tout vendeur sérieux affichera un « show version » du routeur qui vous donnera les informations nécessaires. Voila à quoi cela ressemble et les points qu’il faut surveiller (en gras) :

routeur#show version
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(18), RELEASE SOFTWARE (fc1)

la version de l’IOS présent, je vous en reparlerais
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Fri 30-Nov-07 15:38 by prod_rel_team

ROM: System Bootstrap, Version 12.2(7r) [cmong 7r], RELEASE SOFTWARE (fc1)

routeur uptime is 6 weeks, 20 hours, 32 minutes
System returned to ROM by power-on
System restarted at 18:12:55 GMT+1 Mon Feb 25 2008
System image file is « flash:c2600-adventerprisek9-mz.124-18.bin »
L’emplacement et la version de l’IOS
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco 2611XM (MPC860P) processor (revision 1.0) with 127308K/3764K bytes of memory.

La quantité de RAM installée, si vous voulez utilisez les fonctions de cryptage, 128 Mo comme ici, est un minimum.
Processor board ID xxxxxxxxx
M860 processor: part number 5, mask 2
2 FastEthernet interfaces Le nombre et le type d’interface Réseau (fastEthernet = 100 Mbps, Ethernet = 10 Mbps)
1 Serial interface
32K bytes of NVRAM.
32768K bytes of processor board System flash (Read/Write)

La taille de la mémoire Flash, TRES IMPORTANT, pour un IOS décent, il vous faut au moins 16Mo (avec 8Mo vous aurez les fonctions de base IP), comptez 32 Mo comme ici pour un IOS avec fonctionnalités Firewall

Pour résumé, vérifier que votre interface (ou vos interfaces) réseau est en 100 mbps minimum, que la quantité de mémoire FLASH et RAM est suffisante pour pouvoir évoluer.

La mémoire pour routeur Cisco est assez chère donc prévoyez d’avance. De plus, une grande partie des routeurs 2600 vendus sur eBay n’ont que les fonctions basiques et ne dispose que de 8Mo de mémoire FLASH.

J’oubliez une autre chose TRES importante :

Un équipement CISCO comme le 2600 (ou même le Catalyst d’ailleurs) est très bruyant (grosse ventilation).

Je vous aurais prévenu 😀

A suivre…

Classé dans cisco, réseau | Commentaires fermés sur Anatomie d’une architecture (5)
Mar 21

Anatomie d’une architecture (4)

Ecrit le 21 mars 2008 par guiguiabloc

Conception d’un Firewall Rouge en Haute-Disponiblité (2ème Partie)

Je considère que vos deux futures firewalls son prêt, sous OpenBSD et dispose au minimum de 3 cartes réseaux.

CARP est un protocole permettant à un même groupe d’hôtes de partager la même adresse IP.

Il supporte Ipv4 et Ipv6, mais personnellement, je bloque tout les flux ipv6 actuellement.

NB : je vous invite si vous avez le temps à lire l’Ipv6 Security Guide de Juniper.

Si vous avez activé PF (PacketFilter), n’oubliez pas d’autoriser le protocole CARP :

pass out on $carp_dev proto carp keep state

Dans votre fichier /etc/sysctl.conf, ajouter les entrées suivantes :

net.inet.carp.preempt=1
net.inet.carp.allow=1

Pour les insérer à chaud :

# sysctl -w net.inet.carp.allow=1

Maintenant sur chaque Firewall, nous allons créer l’interface CARP côté rouge :

# ifconfig carp0 create

Puis configurer l’interface (dans un fichier également hostname.carp0 pour qu’il soit effectif au reboot) :

#ifconfig carp0 vhid 1 pass motdepasse carpdev sis0 advskew 1 192.168.0.1 netmask 255.255.255.0

Dans le fichier :

inet 192.168.0.1 255.255.255.0 192.168.0.255 vhid 1 carpdev sis0 advskew 1 pass motdepasse

Sur le deuxième Firewall, changer la valeur advskew de 1 à 100.

Explications :

VHID : C’est l’identifiant unique qui unit les deux interfaces du groupe de firewall.

CARPDEV : l’interface sur laquelle monter le CARP

ADVSKEW : Plus grand est ce nombre moins de chance cette interface à d’être le maître au démarrage

ADVBASE (optionnel): délai en seconde de vérification de l’état des cartes (1 seconde par défaut)

Un petit ifconfig sur le maître (advskew = 1) :

carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:01
carp: MASTER carpdev sis0 vhid 1 advbase 1 advskew 1
groups: carp
inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0x6
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255

Sur l’esclave :

carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:01
carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100
groups: carp
inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0x6
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255

Maintenant, débrancher le cable réseau , arreter le ou un ifconfig carp0 down sur le maître :

# ifconfig carp0 down

#ifconfig

carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:01
carp: INIT carpdev sis0 vhid 1 advbase 1 advskew 1
groups: carp
inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0x6
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255

Sur l’esclave, vous devriez voir l’interface CARP0 passée en MASTER en 1 seconde et si vous faites un test ping d’une autre machine sur le 192.168.0.1, vous ne devriez quasiment rien voir.

Magique 😀

Mais maintenant vous vous dites, « oui mais si j’ai du trafic sur mon firewall-A ??? » et là je vous réponds « pfsync ».

Pfsync permet de synchroniser les états firewalls entre les deux noeuds du cluster.

Dans la cas d’un basculement, le trafic n’est pas interrompu.

Comme pour CARP, nous autorisons PFSYNC dans nos règles PF :

pass on $sync_if proto pfsync

Sur les deux firewalls, nous dédions une interface réseau à pfsync (les deux FW reliés par un cable croisé par exemple) :

# ifconfig pfsync0 syncdev sis2
# ifconfig pfsync0 up

PS: Cela marche aussi sur un lien série 😉

Par défaut psync fait du multicast. Je vous conseille fortement d’utiliser l’attribut « syncpeer x.x.x.x » pour spécifier l’ip de l’autre Firewall :

# ifconfig pfsync0 syncpeer 192.168.0.5 syncdev sis2


Dans une politique de sécurité poussée, vous devriez utiliser IPsec pour encapsuler les flux psync entre les deux firewalls.


Et voila comment en quelques minutes, vous avez montée un Firewall en haute-disponibilité et entièrement redondant.


Vous ferez les mêmes manipulations côtés pattes Vertes afin d’avoir une HA coté LAN aussi :


    +----|   WAN/Internet |-------+
         |                        |
     sis0|                        |sis0
      +-----+                  +-----+
      | fw1 |-sis2--------sis2-| fw2 |
      +-----+                  +-----+
     sis1|                        |sis1
         |                        |
      ---+----------LAN-----------+---






Nous avons donc maintenant une VIP coté rouge en 192.168.0.1


C’est sur cette IP que vous allez configurér la Freebox en mode… DMZ.


Tout ce qui arrivera sur votre Freebox en entrée, sera redirigé sur votre cluster de Firewall. Ce qui vous permettra de gérer vos translations de port sans avoir à rebooter la Freebox…  Ni vos Firewalls d’ailleurs, il est abérant de devoir rebooter un équipement réseau pour appliquer une règle réseau.


NB: Vous pouvez également ne rediriger sur 192.168.0.1 que des plages de porst, l’avantage est de laisser la Freebox bloquer les ports « pourris » (135,139 etc…) et donc d’avoir un premier étage Rouge de blocage.


Ne vous reste plus qu’à configurer votre /etc/pf.conf (le fichier de configuration de PacketFilter) :


Lire PF pour les nuls


Exemple de règle sur une interface CARP :


pass in quick inet proto udp from any to carp1 port 123


Je vous laisse peaufiner votre fichier de configuration PF afin de répondre au mieux à vos propres règles firewall.


A faire, ajouter une autre carte réseau sur vos deux firewalls et monter une interface CARP2 Jaune pour votre DMZ 😀


Petit exemple en dessin :


Schema


Prochaine étape, monter le Firewall Vert qui contrôlera les flux inter-vlans et les sorties sur Internet.

							

	
			

									
						Classé dans OpenBSD, sécurité					
					|
												Commentaires fermés sur Anatomie d’une architecture (4)
				 
			

		


		
	


			

										

					Mar
					18
				
			
Anatomie d’une architecture (3)


			

				Ecrit le 18 mars 2008 par 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.


soekris1


soekris2


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…

							

	
			

									
						Classé dans OpenBSD, réseau, sécurité					
					|
												Commentaires fermés sur Anatomie d’une architecture (3)
				 
			

		


		
	


			

										

					Mar
					17
				
			
Anatomie d’une architecture (2)


			

				Ecrit le 17 mars 2008 par guiguiabloc			


				

				
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 :


Freebox-connexion1


– 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 ).


2924-xl


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 :


Freebox-connexion2


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…

							

	
			

									
						Classé dans cisco, réseau					
					|
												6 Commentaires