GuiguiAbloc

Pour les serveurs qui possèdent 2 cartes ethernet avec des adresses IP dans des VLAN différents et sans configuration supplémentaire, les trames IP qui arrivent sur l’interface eth1 ont les réponses qui partent sur eth0, qui est l’interface qui dispose de la gateway par défaut.

Ceci peut poser des problèmes de routage et de contrôle des accès.

Pour remédier à cela, je vous propose une solution qui à l’air de fonctionner et fait passer les trames aller/retour sur la même interface:

1) ajouter dans le fichier /etc/iproute2/rt_tables les lignes “<numéro table> <nom table>”

2) Si un serveur du vlan eth1 se connecte à l’adresse eth0 du serveur, pour que les paquets retour de la connexion utilisent l’interface eth0 comme les paquets aller et non eth1:

ip route add default via <gateway vlan eth0> dev eth0 table <nom table 1>
ip rule add from <vlan eth0> to <vlan eth1> table <nom table 1> priority <niveau 1>

3) Pour une connexion entre 2 serveurs du vlan eth1, pour que les paquets passent par l’interface eth1 sans contacter la gateway d’eth1 qui sera définie dans la règle suivante et éviter ainsi le filtrage de la gateway:

ip route add dev eth1 table <nom table 2>
ip rule add from <vlan eth1> to <vlan eth1> table <nom table 2> priority <niveau 2>

4) Si un serveur hors du vlan eth1 se connecte à l’adresse eth1 du serveur, pour que les paquets retour passent par eth1 et non la default gateway de eth0.

ATTENTION: cette règle doit obligatoirement avoir un niveau de priorité supérieur à la règle précédente:

ip route add default via <gateway vlan eth1> dev eth1 table <nom table 3>
ip rule add from <vlan eth1> table <nom table 3> priority <niveau 2> + 1

5) faire un flush des routes:

ip route flush cache

6) pour que les définitions soient ajoutées/supprimées lors des activations/désactivations des interfaces, il faut créer les scripts shell /sbin/ifup-local et /sbin/ifdown-local.

Le premier script contiendra les règles vues précédemment et le second les même règles en modifiant “add” par “del”.

Ces scripts sont automatiquement appelés par les scripts de manipulation des interfaces réseaux et sont lancés avec comme paramètre le nom de l’interface.

Dans les scripts c’est le test de ce paramètre (exemple eth1) qui permettra de créer/supprimer les règles de routage.

Les commandes pour vérifier la configuration:

1. pour voir les règles: ip rule show

2. pour voir le routage: ip route show table vlan124

Exemple d’un serveur avec le vlan 51 sur eth0 et le vlan 124 sur eth1:

1) fichier rt_tables:

51 	vlan51
124	vlan124
125	vlan124out

2) Pour que les paquets qui sortent de 10.144.51 vers 10.144.124 utilisent eth0 et non eth1 (cas des paquets retour d’une connexion d’un serveur 10.144.124 vers l’interface 10.144.51)

ip route add default via 10.144.51.254 dev eth0 table vlan51
ip rule add from 10.144.51.0/24 to 10.144.124.0/22 table vlan51 priority 51

3) Pour que les paquets de 10.144.124 vers 10.144.124 passent par l’interface eth1 sans contacter la gateway

ip route add dev eth1 table vlan124
ip rule add from 10.144.124.0/22 to 10.144.124.0/22 table vlan124 priority 124

4) Pour que les paquets qui sortent de 10.144.124 passent par eth1 et la gateway (cas d’une connexion d’un poste hors vlan 124 vers le vlan 124) avec nécessairement une priorité supérieure à la règle précédente

ip route add default via 10.144.127.254 dev eth1 table vlan124out
ip rule add from 10.144.124.0/22 table vlan124out priority 125

Avec l’ajout de nouveaux serveurs, pc, équipements dans votre réseau, la centralisation des logs sur une seule machine devient une évidence.

Passer 1 heure a se connecter en ssh, minicom ou autre sur chaque bestiole pour vérifier les logs devient vite fastidieux et la mise en place d’un « Syslog Host » (terme que j’emploierai pour désigner le serveur de récupération des logs) coule de source.

Heureusement, ce genre de déploiement est assez simple car déjà inclus nativement sur nos Linux / *BSD préféré.

Le choix du serveur de logs n’est pas non plus à prendre a la légère. Outre le volume de données a stocker/traiter, la criticité d’une telle machine ne doit pas être oubliée.

1. Vous vous exposez à une « attaque » de type Syslog Bombing
2. Certains logs peuvent être sensible et ne pas être donné en pature a n’importe quel lecteur

Prévoyez donc une partition dédiée (type /var/log) suffisamment dimensionnée et réservée aux logs.

Côté sécurité réseau, les flux Syslog utilisent le protocole UDP sur le port 514, a vous donc de positionner vos ACL et/ou règles Firewall en conséquences et bien entendu à ne pas l’exposer au réseau Internet.

L’idéal étant bien évidemment de positionner le SyslogHost dans un VLAN dédié ou vous n’autoriserez que l’UDP port 514 et le SSH depuis le poste de management.

(Petite parenthèse d’humour paranoïaque :
La sécurité ultime étant justement d’utiliser la particularité du protocole UDP qui travaille en mode non-connecté pour couper physiquement le fil TX du câble réseau côté carte du SyslogHost

Bon OK, là c’est vraiment Parano

fin de la parenthèse qui sert à rien)

Activation du démon Syslogd

Sur votre Pingouin, il suffit de rajouter l’option « -r » a Syslog.

Debian Like : /etc/default/syslogd

RedHat Like : /etc/sysconfig/syslog

Relancer syslog.

Sur le Poisson qui pique, ajouter le flag -u dans votre /etc/rc.conf :

syslogd_flags= »-u »

Killer le process Syslogd et relancer le en mode -u : syslogd -u

Un netstat -an | grep 514 vous confirmera l’écoute :

udp 0 0 *.514 *.*

Sur les clients, il suffit maintenant de modifier le fichier /etc/syslog.conf pour lui demander de tout envoyer au Syslog Host :

Ex: *.* @192.168.0.1

Bien sur vous pouvez peaufiner ce que vous voulez envoyer comme logs. (lire cet article par exemple).

N’oubliez surtout pas de configurer la rotation automatique des logs !!!

Avec logrotate.d sur Linux et Newsyslog sur OpenBSD (MAN est votre ami)…

Remontée les logs Cisco

Les Ciscos savent envoyer leurs logs ves un Syslog host.

Sur un routeur :

logging 192.168.0.1

Sur un Pix :

logging host inside 192.168.0.1

Par défaut, les Ciscos envoient leurs logs avec le niveau local.7

Il peut être intéressant de peaufiner le traitement des logs et de séparer les logs « syslog » des machines, des logs équipements.

Pour un Pix par exemple, nous pouvons utiliser le tableau suivant :

Facility	Logging Facility Command Value	local 0	16
local 1	17
local 2	18
local 3	19
local 4	20
local 5	21
local 6	22
local 7	23

 

1. Préparons le SyslogHost a recevoir les logs : local3.debug /var/log/cisco.log (dans le syslog.conf)
2. Sur le Pix ou le routeur Cisco :

logging trap informational
logging facility 19

Car facility 19 = local 3

NB : Il s’agit simplement d’une traduction du binaire :-p

• 16 = 00010000 = local0
• 17 = 00010001 = local1
• 18 = 00010010 = local2
• 19 = 00010011 = local3
• 20 = 00010100 = local4
• 21 = 00010101 = local5
• 22 = 00010110 = local6
• 23 = 00010111 = local7

On utilise les 4 derniers bits, exemple 22 = 00010110, les 4 derniers =0110 = en décimal 6, c’est du local 6.

Le flag Trap est le niveau de log voulu :

alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
warnings Warning conditions (severity=4)

Les commandes suivantes ne sont pas négligeables à rajouter :

service timestamps log datetime localtime (Cisco routeur)

logging timestamp (Cisco PIX)

Si cela vous amuse vous pouvez également coloriser vos logs qui s’afficheront (voir l’article ICI ).

Traitement des logs

Se coltiner des flux continus de logs qui défilent n’est pas des plus agréables et une information Critique peut vous échapper si vous ne lisez pas vos logs ou ne les traiter pas automatiquement.

Il existe des multitudes de script vous permettant de parser vos logs et d’en extraire les informations essentielles, je vous laisse avec Google pour faire le plein de bonne solution.

Personnellement, comme je l’avais expliqué dans un billet précédent, j’utilise Prelude comme centralisateur d’informations et en installant un module Prelude-LML (LML : Log Monitoring Lackey) sur le SyslogHost, je remonte tout cela sur le Prelude Manager et une bonne moulinette maison me permet d’être alerté en temps réel en cas d’incident.

J’espère que vous prendrez conscience de l’utilité et de l’importance de la centralisation des logs qui n’a été que rapidement approchée dans ce billet mais que vous pourrez étendre beaucoup plus loin (remontée des logs applicatives par exemple (qui a dit Log4j ??? ) etc..

Bon courage

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.

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…

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…