GuiguiAbloc

Photographe:Cpl Barry Lloyd RLC Crédit : www.defenceimages.mod.uk

Aujourd’hui je vous propose de vous parler d’une nouvelle génération de Firewall mais aussi, je l’espère, vous pousser à la réflexion sur notre conception du firewall telle qu’on l’a aujourd’hui en se demandant, si, après tout, on n’est pas un peu rétrograde.

Petit historique.

Palo Alto Networks est une société créée en 2005 par un monsieur très connu du monde de la sécurité : Nir Zuk.
Si son nom ne vous dit rien (bouh ! Honte à vous, que vous soyez flageller sur la place publique et que les corbeaux viennent écorcher votre peau blanchâtre (euh non, je suis un peu trop extrémiste là…) ), sachez que Nir Zuk est l’un des créateurs du Stateful inspection de Checkpoint, l’ancien directeur technique de Netscreen Technologies (racheté par Juniper) et aussi créateur d’un des premiers IPS du marché via son ancienne société OneSecure. Bref, un type qui s’y connait « un peu »

Notre vision généraliste du Firewall telle qu’on l’a aujourd’hui, est un filtrage de niveau 3 et 4, parfois 7 de la couche OSI (allez hop, pour ceux qui aurait rater mes anciens billets vous martelant d’avoir un minimum de connaissance des couches OSI, on y retourne), ce à quoi l’on va rajouter, bien sûr, cette fameuse inspection stateful.

pause

« Mais dites moi Monsieur Abloc, c’est quoi ça l’inspection Stateful ??? »

« Je te remercie de poser la question, jeune padawan, mais vu que tu es un fidèle lecteur, dans ma grande mansuétude, je t’autorise à m’appeler guiguiabloc. »

« Oh merci vous êtes bien bon avec moi ! C’est trop d’honneur »
« De rien mon petit, vas en paix et écoute »

(désolé, une crise passagère…)

Dans un firewall vous allez, au niveau  3, par exemple, autoriser telle adresse ip à accéder à telle autre adresse ip. Au niveau 4, vous allez autoriser cette ip source à accéder depuis un port tcp supérieur à 1023 à accéder au serveur web de l’autre adresse ip sur le port 80.

(pourquoi supérieur à 1023 ? parce qu’une requête cliente vers un serveur prend aléatoirement un port source supérieur à ce nombre, les ports inférieurs à 1023 ne pouvant être « réservé » qu’à des services reconnus (je simplifie hein !)).

D’ailleurs il vous suffit de regarder vos connexions établies pour le voir :

guiguiabloc@Thanatos:~$ netstat -tan | grep 80
tcp        0      0 192.168.8.201:44450     174.36.30.59:80         ESTABLISHED

où 192.168.8.201 est le client et 174.36.30.59, le serveur web.

Donc, remarque aux gens qui configurent leurs firewalls pour la première fois, autoriser le 80 depuis l’extérieur vers l’intérieur pour surfer, bah ça sert à rien (on le voit souvent :p)

Jusqu’à maintenant on est en mode « stateless ».

Le mode stateful va allez jusqu’à la notion de session du protocole TCP.

Quand Kevin veut se connecter au serveur web de Tatiana (qui offre avec gentillesse des apercus non négligeable de son architecture)), en tcp (donc niveau 4 ), il envoit un SYN  (je veux me connecter à toi, Tatiana, t’es trop de la balle), le serveur de Tatiana répond SYN/ACK (j’ai pris connaissance de ton désir passionné de venir visiter mes zolies pages et de contempler la façon dont j’enroule mes câbles), le pc de Kevin renvoit un ACK (oh oui, je veux voir tes zolies pages et tes câbles si bien disposés, merci de me répondre Tatiana (flap,flap, flap)).

C’est ce qu’on appelle un triple-handshake (ou poignée de main à 3 temps). (NB: le flap flap flap ne faisant pas partie de la négociation et je vous interdit dans vos esprits pervers de faire un quelconque rapport entre « hand » et « shake » dans l’exemple ci-dessus ! Ignoble individu que vous êtes !)

En plus, lors de cet échange, des numéros de séquence sont générés et par le client (numéro de séquence initial), repris par le serveur (+1) qui y rajoute ses numéros d’acquittement, que le client reprend aussi.

(je vais pas vous faire un cours sur tcp, Google est votre ami )

A cet instant, nous avons une session d’établie que le firewall, en mode stateful connait.

Il va donc considérer que vu que le flux existe et que la session est établie, il est désormais inutile d’analyser les paquets entre le client et le serveur pour cette session tcp, il considère que c’est autorisé (c’est du filtrage dynamique).

En mode Stateful, le firewall a donc connaissance de l’existence ou non d’une session entre deux ips. Il rejettera un paquet tcp de type SYN/ACK s’il n’a pas vu un SYN du client sur cette session auparavant.

L’inspection stateful permet donc un filtrage avancé sur les connexions établies ou non, même si le port tcp est ouvert, il ne sera pas forcément accepté par le firewall.

Exemple d’intrusion en mode stateless (schématiser sans NAT/PAT toussa) :

Le pc client (Thanatos, 192.168.8.201) a un vnc server sur son poste en écoute sur le port 5900.

Le firewall entre lui et internet à une règle de type :

permit tcp host ip client gt 1023 any eq 80

(le client en source port supérieur à 1023 peut aller voir des sites en http sur le port 80).

Je suis sur internet, j’initie une connexion depuis le port 80 (serveur Alixe, 192.168.43.100) vers l’ip du client sur le port 5900, et bien ca passe…

Un firewall stateful, lui,  rejettera ce genre de trafic puisque le SYN ne peut venir que du client, pas du serveur web.

NB : Pour les curieux qui voudrait savoir comment j’ai reproduit un mode stateless/stateful dans cet exemple via des ACLs Cisco, voici les règles utilisées (192.168.8.201 est le client, 192.168.43.100 est le serveur)  :

Exemple 1 (stateless) :

permit tcp host 192.168.43.100 eq www any gt 1023

Exemple 2 (stateful) :

permit tcp host 192.168.43.100 eq www any gt 1023 established

Sous votre *BSD favori, il vous suffit de positionner l’option « flags » (S/SA pour un SYN/SYN-ACK).

Bien entendu je simplifie à l’extrème (d’autres éléments entre en jeux) mais j’espère avoir éclairer ceux qui ne connaissait pas ce mode de suivi de transaction entre deux machines.

fin de la pause

Sauf qu’au bout d’un moment, le stateful inspection, le filtrage de niveau 4, on en atteint vite les limites.

Alors, on va rajouter des couches et des couches d’IDS, d’IPS, au détriment souvent des performances du firewall.

Palo Alto Networks propose donc une nouvelle génération de Firewall, avec des  filtrages portant sur :

- l’identifiant de l’utilisateur (on ne gère plus l’ip du poste client mais son identification propre par corrélation avec un ActiveDirectory ou un LDAP, ou au pire en le renvoyant sur un portail captif pour une authentification Radius) (User-id)

- l’application utilisée (j’ouvre le http et j’autorise skype mais pas facebook), mais aussi le contenu qui passe dans le flux (ouh la toi tu fais du tunneling ssh dans du http avec Corkscrew, je te l’interdit) (app-id). Sachez que la liste des applications reconnues par le Palo Alto est assez conséquente et que bien sûr, vous pouvez vous même y définir vos propres applications.

- le contenu des trames cyptées en faisant du « Man-in-the-Middle » SSL pour décrypter en temps réel les flux SSL/HTTPS et regarder ce qu’il y ‘a dedans pour vérifier sa dangerosité (nan nan, ton facebook par SSL, non plus, tu passeras pas)

- l’analyse du contenu des paquets (charge virale, DoS, filtrage URL etc…) (Content-id). Evidemment le Palo Alto ne se base pas uniquement sur l’extension d’un fichier pour en connaitre le contenu

Bien sûr; quitte a faire tout cela bien et rapidement, on va traiter le flux en  1 seule passe et côté hardware, dédier des CPUs à chaque usage avec quelques FPGA pour faire bonne mesure.

Intéressant non ?

« D’accord mon grand, t’es gentil, mais pourquoi tu nous causes de ça ? »

Parce que çà  :

Et oui, j’ai eu la chance d’avoir un des ses boîtiers a la maison

Après une formation condensée et efficace (merci Philippe ), on se positionne le PaloAlto en mode bridge derrière la freeteuse.

(Rassurez vous, le boîtier a rapidement rejoint un environnement de production digne de ce nom pour subir la batterie de tests habituels.)

Mais qu’en est-il des premiers résultats ?

Le Firewall Palo Alto peut fonctionner en plusieurs mode :

- le mode TAP, vous le branchez sur un port mirroring ou un boitier TAP justement et il vous ressort l’ensemble du trafic qu’il voit passer (analyse etc…). C’est forcément une première étape pour le brancher dans votre infrastructure. Non intrusif, ce mode vous permet d’avoir déjà une première idée de ce qui passe dans votre réseau (applications utilisées, statistiques de consommation par flux et application etc…)

- le mode bridge (appelé VirtualWire chez eux), en passerelle transparente. Les flux entrent d’un côté et ressortent de l’autre. A ce niveau la, vous coder une règle autorisant tout et vous pouvez petit à petit alimenter les « policy » suivant le trafic que vous voyez.

- le mode routeur/firewall (en couche 3 donc) que tout le monde connait, avec ses interfaces à configurer, ses vlans, ses routes etc… La il remplace votre firewall actuel.

Le Palo Alto a un processeur et une interface dédié au Management.

La CLI ne surprendra pas les habitués de Juniper. C’est clairement du Netscreen OS (rassurez vous, si vous utilisez Vyatta, c’est sensiblement pareil).

Ce qui est flagrant de sa parenté avec les Netscreen, ce sont ses couches VSYS et VROUTER (virtual system et virtual routeur de Netscreen/Juniper). Les zones de type Trust/Untrust sont également là. Bref, clairement, c’est la touche Netscreen qui prédomine.

Côté administration graphique, c’est du web, en ajax… Et là, vous le verrez plus loin, c’est la partie noire du produit.

Quand on prend la bête en main pour la première fois via le port console (standard 9600/8/1 comme pour un Cisco), on configure l’ip de management, gateway, dns pour rapidement pouvoir prendre la main, puis on « pousse » la conf par un « commit ».

Première surprise, le commit, montre en main, prend plus de 2 minutes !

Euh la on commence a avoir des angoisses, un commit à vide (pas de règles, une conf de base)  qui prend tant de temps c’est angoissant. On se dit que ca ira mieux plus tard…

Bref, on laisse tourner et on regarde.

Là les premiers résultats sont bluffants. Tout est clairement identifié, les flux bien sûr, mais également les applications utilisées,

mes tunnels ssh dans le proxy,

les attaques de types Naphta/Slowloris que j’ai envoyé sur un serveur Web, etc..

En testant des règles génériques de types « deny application deezer », c’est redoutable

Petit bonus à tester, le man-in-the-middle SSL.

On se génère un certicat SSL dans le boîtier.

On pose un filtrage SSL avec décryption.

Et hop, on teste depuis un navigateur client. Le truc tout bête, allez télécharger le fichier EICAR antivirus en https.

Surprise, le certificat serveur sur le poste client à changer, en regardant en détail , on retrouve notre certificat SSL généré sur le Palo Alto en tant qu’émetteur, et les informations du certificat serveur dans les restes du contenu.

Côté détection, le Palo Alto a décrypter le flux SSL et à trouver la fausse charge virale dans le contenu. Bluffant.

Il se comporte donc comme un proxy forward SSL, agissant en temps qu’intermédiaire entre le serveur et le client, et en profitant pour analyser le contenu qu’il peut bien sur décrypter.

Cela marche également sur https://mail.google.com… Effrayant

Alors bien sûr le navigateur client remonte une alerte sur le certificat qui n’est pas reconnu en tant que Root CA connue mais rien ne vous interdit de signer votre certificat SSL du Palo Alto par une autorité reconnue par les navigateurs, Verisign par exemple).

Maintenant j’en pense quoi ?…

Palo Alto Networks nous pousse vers une nouvelle façon de surveiller et de gérer les flux réseau dans notre infrastructure.

Il est évident que l’on n’a pas attendu leur venue pour faire du filtrage au niveau 7, pour filtrer les requètes SQL via GreenSQL , faire du firewall authentifiant ou du décryptage SSL.

Maintenant, plutôt que réécrire ce qui a été dit, je vous invite à lire les différents documents et comparatifs que Palo Alto a pondu :

http://www.paloaltonetworks.com/literature/index.php

Toutefois, c’est clairement le type de Firewall a positionner entre vos utilisateurs et vos serveurs.

En frontal Internet pour protéger l’accès à vos DMZ cela ne changera rien à un bon Checkpoint/ASA/OpenBSD (après tout, si l’on ouvre l’accès public à une application depuis internet, cela n’a pas de sens d’utiliser le User-id ou l’App-id. Quand au filtrage du contenu, ou effectivement vous mettez votre Palo Alto pour cela, ou vous continuez à utiliser votre IPS).

C’est vrai qu’en y réfléchissant, l’accès de vos utilisateurs à vos ressources internes demande à dépasser ce niveau de filtrage basique.

L’équipe de développeurs du projet A, que je reconnais par leurs User-Id, ne peut accèder qu’aux applications les concernants et pas aux applications d’un autre projet B, même s’ils sont dans le même vlan (oui oui, le fameux tcp/3306 autorisé pour l’ensemble des dev sur le vlan de bases de données ).

Cibler l’accès à des applications suivant le profil des utilisateurs, c’est peut être cela qui nous manquait aujourd’hui.

Quand a filtrer l’accès des utilisateurs sur Internet, c’est une question de politique d’entreprise. Certains vont laisser ouvert (en passant par un proxy filtrant (type SquidGuard), d’autres vont refuser toute utilisation d’outils sociaux perturbant la rentabilité de l’entreprise (par exemple). Question de choix. Ce n’est pas à nous d’en décider, mais dans ce cas, Palo Alto répond clairement au besoin.

Si par contre je devais remonter un point noir, c’est l’interface d’administration du Palo Atlo. Que ce soit pour coder des règles de filtrages et surtout les appliquer (2minutes 30 à vide alors que sur mes Checkpoint avec plus de 1000 règles de filtrage et autant de NAT cela me prend moins de temps), c’est inutilisable au quotidien par une équipe habituée à pousser de nombreuses règles par jour. A régler donc.

En résumé, par la découverte de cette nouvelle génération de Firewall, il est évident qu’il nous faut repenser la façon de filtrer les différents éléments de nos infrastructures.

Si le danger vient beaucoup de l’extérieur, il existe aussi clairement à l’intérieur d’un SI, que le suivi des utilisateurs par autre chose que leurs adresses IPs, que l’accès précis aux applications doit être un devenir du rôle du firewall interne, c’est sûrement un axe de réflexion à avoir dès maintenant, car comme dirait Nir Zuk :

« Votre choix : innover ou disparaître. »

Bonne réflexion

Ah vous m’avez manqué J’avoue avoir un peu délaissé mon blog dernièrement et a force de me faire houspiller (ah oui, ahan, encore, fais-moi mal (pardon)), je vous propose donc un petit billet technique sous forme d’atelier @home.

Comme vous l’avez deviné au titre  de ce billet (dont le jeu de mot bien pourri est digne de la lignée des meilleurs calembours Carambar), nous allons parler d’IPsec.

Bien évidemment, comme je ne fais pas comme tout le monde, j’ai du faire face à une situation un peu différente de ce que l’on rencontre généralement.

Je dispose @home, derrière la Freeteuse, d’un Cisco PIX, et je souhaite me connecter en IPsec, en mode tunnel (LAN to LAN) sur mes serveurs dédiés sous linux, ou sur des serveurs derrière d’autres équipements (dans le cas de ce billet, me connecter a un réseau local chez un pote derrière un Netopia R9100.

Seul petit point à souligner, je suis en ip dynamique et les autres en ip fixe (ca change ).

Nous allons donc voir  différentes approches d’une connexion IPsec, le Cisco Pix en client, les Linux avec Racoon en serveurs, et le Netopia R9100 en serveur également.

Bien évidemment, comme je ne veux pas exposer les plans d’adressage ip de mon LAN, je vais NATer et filtrer tout ce qui part dans les tunnels.

Un petit dessin valant mieux qu’un grand discours :

Allez, maintenant au boulot.

J’ai décider d’utiliser les plans d’adressages suivant :

10.250.250.0/24 pour NATer mes ressources internes (comment les serveurs de mon LAN sont vus par les autres au travers du tunnel IPsec).

10.40.0.0/24 les ressources du serveur_dédié vu par mon LAN

10.10.150.0/24 les ressources du LAN derrière le Netopia du copain vu depuis mon LAN

Tout ces plans d’adressage vont devenir nos Domaines d’Encryption.

Linux IPsec Tools et RACOON

Sous Linux, la configuration IPsec se fait grace a la suite d’outils IPsec-Tools.

Cette suite d’outil comprend 2 élements importatns :

- Setkey : un outil pour interagir avec la couche ipsec du kernel

- Racoon : un démon IKE pour gérer les clés de connexion IPsec

Sur votre serveur Debian :

apt-get install ipsec-tools racoon

on se créé un fichier /etc/ipsec-tools.conf dans lequel on va détailler notre tunnel IPsec (mode ESP) :

spdadd 10.40.0.0/24 10.250.250.0/24 any -P out ipsec
esp/tunnel/99.99.99.1-0.0.0.0/require;
spdadd 10.250.250.0/24 10.40.0.0/24 any -P in ipsec
esp/tunnel/0.0.0.0-99.99.99.1/require;

Nous définissons donc nos 2 domaines d’encryptions et les deux extrémités du tunnel.

Comme j’ai une ip dynamique, je spéficie 0.0.0.0 (c’est a dire, n’importe qui).

On charge : setkey -f  /etc/ipsec-tools.conf

Vous pouvez jeter un oeil aux SA avec : setkey -D

Pour racoon :

/etc/racoon/racoon.conf
 
...
path pre_shared_key "/etc/racoon/psk.txt";
timer {
phase1 60 seconds ;
phase2 60 seconds ;
}
remote anonymous {
exchange_mode aggressive ;
doi ipsec_doi ;
situation identity_only ;
lifetime time 1 hour ;
generate_policy on;
passive on;
my_identifier address 99.99.99.1 ;
peers_identifier fqdn "pix.guiguiabloc.fr" ;
proposal {
encryption_algorithm aes 256;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
proposal_check obey ;
}
sainfo anonymous {
pfs_group modp1024;
lifetime time 1 hour ;
encryption_algorithm aes 256;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}

Explication :

On défini ici les différents paramètres de sécurité du tunnel pour les Phase 1 (IKE) et 2 (IPsec) a savoir les méthodes de chiffrement, de hachage, les temps de vie, l’activation du PFS (pour échanger des clés supplémentaires ) etc…

Je ne vais pas entrer dans les détails d’IPsec, donc un peu de lecture :

http://www.securiteinfo.com/cryptographie/IPSec.shtml

http://www.tcpipguide.com/free/t_IPSecurityIPSecProtocols.htm

La partie importante qui nous intéresse ici est le mode « Agressive » et non « Main ». En effet, j’ai une ip dynamique et je ne peux donc pas me baser dessus pour la négociation. J’utilise donc le fqdn de mon Pix (pix.guiguiabloc.fr) comme identifiant, et pour faire du fqdn+ pre-shared key, bah il faut etre en mode Agressive

Enfin dans le fichier /etc/racoon/psk.txt je renseigne la Pre-shared key (le mot de passe si vous préférez) :

pix.guiguiabloc.fr motdepassesupersecretamoi

Vous pouvez lancer Racoon : /etc/init.d/racoon start et le démon doit écouter sur les ports UDP 4500 et 500.

NETOPIA R9100

Le Netopia R9100 est un vieux routeur qui fait papa/maman. On peut le retrouver dans certaines TPE/PME ou chez des potes Geek qui font de la récupération :p , c’est le cas ici.

Ouf….

Allez on s’occupe de la maison.

On NAT notre pc 192.168.100.1 en une ip du domaine d’encryption

r-backbone
 
int fa 0/0 (interne)
 
ip nat inside
 
int fa 0/1 (externe)
 
ip nat outside
 
ip nat inside source static 192.168.100.1 10.250.250.1
 
ip route 10.250.250.0 255.255.255.0 FastEthernet0/0

On route les domaines d’encyptions des serveurs distants :

ip route 10.40.0.0 255.255.255.0 10.254.254.254
 
ip route 10.10.150.0 255.255.255.0 10.254.254.254
 
Coeur de Réseau
 
ip route 10.40.0.0 255.255.255.0 10.144.1.254
 
ip route 10.10.150.0 255.255.255.0 10.144.1.254

Cisco PIX

# Les ACLS qui vont bien
access-list outside-ipsec extended permit ip 10.250.250.0 255.255.255.0 10.10.150.0 255.255.255.0
access-list outside-ipsec extended permit ip 10.250.250.0 255.255.255.0 10.40.0.0 255.255.255.0
 
access-list outside_serveur extended permit ip 10.250.250.0 255.255.255.0 10.40.0.0 255.255.255.0
access-list outside-pote extended permit ip 10.250.250.0 255.255.255.0 10.10.150.0 255.255.255.0
 
 
# on ne natte pas les ips des domaines d'encryption
 
nat (inside-test) 0 access-list outside-ipsec
 
# La partie IPSEC elle meme
 
crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac
crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac
crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac
crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac
crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac
crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map map-ipsec 1 match address outside_serveur
crypto map map-ipsec 1 set pfs
crypto map map-ipsec 1 set peer 99.99.99.1
crypto map map-ipsec 1 set transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5
crypto map map-ipsec 1 set nat-t-disable
crypto map map-ipsec 1 set phase1-mode aggressive
crypto map map-ipsec 20 match address outside-pote
crypto map map-ipsec 20 set pfs
crypto map map-ipsec 20 set peer 88.88.88.88
crypto map map-ipsec 20 set transform-set ESP-3DES-SHA
crypto map map-ipsec 20 set nat-t-disable
crypto map map-ipsec 20 set phase1-mode aggressive
crypto map map-ipsec interface outside
crypto isakmp identity hostname
crypto isakmp enable outside
crypto isakmp policy 5
authentication pre-share
encryption 3des
hash sha
group 2
lifetime 86400
crypto isakmp policy 10
authentication pre-share
encryption des
hash sha
group 2
lifetime 86400
crypto isakmp policy 20
authentication pre-share
encryption aes-256
hash sha
group 2
lifetime 86400
 
group-policy IPSEC_POLICY internal
group-policy IPSEC_POLICY attributes
vpn-filter none
vpn-tunnel-protocol IPSec
tunnel-group 99.99.99.1 type ipsec-l2l
tunnel-group 99.99.99.1 general-attributes
default-group-policy IPSEC_POLICY
tunnel-group 99.99.99.1 ipsec-attributes
pre-shared-key *
tunnel-group 88.88.88.88 type ipsec-l2l
tunnel-group 88.88.88.88 general-attributes
default-group-policy IPSEC_POLICY
tunnel-group 88.88.88.88 ipsec-attributes
pre-shared-key *

N’oubliez pas que vous ne pouvez avoir qu’1 crypto map par Interface, il faut donc juste rajouter un identifant numerique supplémentaire pour chaque nouveau tunnel (ici 1 pour le premier tunnel, 20 le deuxieme).

Et beh..

Allez maintenant on test :

ssh 10.10.150.1

Mar 27 18:12:58 pix Mar 27 2011 18:12:58: %PIX-5-713041: IP = 88.88.88.88, IKE Initiator: New Phase 1, Intf inside-test, IKE Peer 88.88.88.88  local Proxy Address 10.250.250.0, remote Proxy Address 10.10.150.0,  Crypto map (map-ipsec)
Mar 27 18:13:01 pix Mar 27 2011 18:13:01: %PIX-6-713219: IP = 88.88.88.88, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Mar 27 18:13:07 pix Mar 27 2011 18:13:07: %PIX-6-713219: IP = 88.88.88.88, Queuing KEY-ACQUIRE messages to be processed when P1 SA is complete.
Mar 27 18:13:11 pix Mar 27 2011 18:13:11: %PIX-6-113009: AAA retrieved default group policy (IPSEC_POLICY) for user = 88.88.88.88
Mar 27 18:13:11 pix Mar 27 2011 18:13:11: %PIX-5-713119: Group = 88.88.88.88, IP = 88.88.88.88, PHASE 1 COMPLETED
Mar 27 18:13:11 pix Mar 27 2011 18:13:11: %PIX-3-713122: IP = 88.88.88.88, Keep-alives configured on but peer does not support keep-alives (type = None)
Mar 27 18:13:11 pix Mar 27 2011 18:13:11: %PIX-6-713220: Group = 88.88.88.88, IP = 88.88.88.88, De-queuing KEY-ACQUIRE messages that were left pending.
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-5-713073: Group = 88.88.88.88, IP = 88.88.88.88, Responder forcing change of IPSec rekeying duration from 28800 to 3600 seconds
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-5-713049: Group = 88.88.88.88, IP = 88.88.88.88, Security negotiation complete for LAN-to-LAN Group (88.88.88.88)  Initiator, Inbound SPI = 0xe4e88f39, Outbound SPI = 0x94160878
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-6-602303: IPSEC: An outbound LAN-to-LAN SA (SPI= 0x94160878) between 192.168.1.250 and 88.88.88.88 (user= 88.88.88.88) has been created.
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-6-602303: IPSEC: An inbound LAN-to-LAN SA (SPI= 0xE4E88F39) between 192.168.1.250 and 88.88.88.88 (user= 88.88.88.88) has been created.
Mar 27 18:13:24 pix Mar 27 2011 18:13:24: %PIX-5-713120: Group = 88.88.88.88, IP = 88.88.88.88, PHASE 2 COMPLETED (msgid=f0cb61bd)

Rhââ Lovely

Idem l’autre tunnel avec un ping 10.40.0.1 par exemple

Si vous voulez filtrer les paquets dans vos tunnels ipsec, utilisez des ACLS de type :

access-list acl-ipsec extended permit tcp 10.40.0.0 255.255.255.0 eq www 10.250.250.0 255.255.255.0 gt 1023

(le reseau distant d’abord, puis votre propre reseau ensuite).

Dans le Pix, modifier l’éntrée vpn-filter none par :

vpn-filter value acl-ipsec

Amusez vous bien

Ah la la, le temps passe et forcément, je délaisse un peu le blog….

En fait pas vraiment, je continue a répondre aux diverses questions et variées qui m’arrivent dans ma boite mail mais surtout, je continue a tester des nouveaux trucs et plus précisément, j’ai mis en place ma deuxième salle machine (aussi appeler « Datacenter salle E » par mon entourage ou projet Level 0 pour moi :-p )

Comme j’en suis pas peu fier, autant que je vous en fasse profiter (même si vous vous en foutez royalement )

La baie principal du bureau (Level 1 désormais) a un peu changé :

Baie Level 1

J’avais auparavant un routeur 2611XM et un Catalyst 2924 en « Coeur de Réseau », remplacé depuis par un Cisco 3550-48.

Dans la suite, de haut en bas, on trouve,  le Catalyst 2924 en spare,  le Soekris sous OpenBSD ,  le Cisco 2611XM qui devient firewal stateless, le Cisco PIX (firewall Statefull), un cisco 2620 (en maquette), un Cisco 3620 qui devient routeur de backbone entre le level 1 et le level 0.

L’interconnexion entre le bureau et le sous-sol se fait par une fibre optique Multimode.

Passage Fibre

Pour passer la fibre entre mon bureau et le sous-sol, j’ai condamné l’ancienne évacuation d’eau du bureau (auparavant un coin cuisine http://blog.guiguiabloc.fr/index.php/2008/01/30/montage-de-la-baie/ ). Les deux cables noirs en plus sont les coax des caméras filaires du sous-sol et de l’entrée du garage.

Enfin, la baie du sous-sol (Level 0 )

Baie Level 0

Sympa hein

L’électricité au sous-sol de ce côté etait déplorable, j’ai refait tout cela au propre :

Un petit tableau avec un disjoncteur de 16A et un différentiel 30mA (récup). Pour l’alimentation générale de la Baie, j’ai greffé un module AW12 en X10 dans une boite de dérivation qui me permet d’allumer/éteindre la baie par télécommande ou ordre X10 sur mon serveur Domotique.

La baie équipée (que de la récup’ ) :

Baie Level 0

De haut en bas :

- Serveur Dell 750 en attente

- Dell 750, Firewall Checkpoint SecurePlaform  FW-1 (Firewall  et Routeur de la zone level 0)

- HP Procurve 4000M : Switch Niveau 2 (extension du Level 1) avec son interco Fibre SX avec l’étage

- Cisco 2950, Switch Niveau 2 du Level 0

- Cisco 3620 , routeur du backbone Level0-Level1

- des Switchs SAN Brocade en attente de maquette

Classe non ?

En attente, le cablage cuivre point a point entre le routeur de backbone level 0 et le routeur de backbone level 1.

Le routage est donc déporté sur ses deux routeurs interconnectés entre le Level 0 et le level 1.

Je vous reparlerais plus tard de la partie réseau de cette nouvelle installation (en OSPF bien sûr) et de la mise en oeuvre du Firewall Checkpoint FW-1 dans l’infra maison

Bref, de grands moments de plaisir (et de galère) a mettre tout cela en place

A bientôt

Petit billet rapide suite à la sortie de l’offre MiniCloud d’OVH http://www.kimsufi.com/cloud/

Bien évidemment, cette technique ne s’applique pas seulement à cette offre, elle est juste… bien utile.

En effet, les MiniCloud d’OVH changent d’adresse IP quand on les éteints et qu’on les rallument. C’est assez gênant de courir après la nouvelle adresse ip du cloud n°24, mais heureusement, afin d’éviter ceci, le DNS est notre ami.

Vous connaissez tous DynDNS, un service gratuit, très utilisé par les gens qui disposent d’une adresse IP dynamique chez eux, et qui permet, lors du changement d’adresse, de mettre a jour une entrée DNS de type chezmoi.dyndns.com.

Ce que je vous propose, c’est de faire la même chose sur vos serveurs DNS, et donc de changer dynamiquement une entrée de type A en cas de changement d’adresse IP (de votre MiniCloud par exemple).

Je considère déjà que vous savez comment fonctionne un DNS et que le votre est fonctionnel et opérationnel pour votre ou vos domaines.

• BIND

Pré-requis, les packages dns-utils et bind9  (pour les distributions Debian)

Première étape, créer une paire de clés pour permettre de mettre à jour le DNS à distance en toute sécurité :

dnssec-keygen -a HMAC-MD5 -b 512 -n USER -r /dev/urandom dnscloud.guiguiabloc.fr
Kdnscloud.guiguiabloc.fr.+157+06250

Vous avez désormais 2 clés, 1 privée et 1 publique (comme pour ssh)

serveur:~# ll K*
-rw------- 1 root root 130 jun  1 09:41 Kdnscloud.guiguiabloc.fr.+157+06250.key
-rw------- 1 root root 156 jun  1 09:41 Kdnscloud.guiguiabloc.fr.+157+06250.private

On récupère la clé :

serveur:~# cat Kdnscloud.guiguiabloc.fr.+157+06250.private | grep Key
Key: GaC4ezsL0c/gWqG7nzH4iYyWPqYS2tC3H78ZYkyuvj5LJyq6JZjh4f+KKhuL/A5gTnc1K0rRw2u/3z+eXA76XA==

Ajouter la clé dans le fichier named.conf (ou named.conf.local tout dépend de votre façon de travailler ) :

key "dnscloud.guiguiabloc.fr." {
   algorithm hmac-md5;
   secret "GaC4ezsL0c/gWqG7nzH4iYyWPqYS2tC3H78ZYkyuvj5LJyq6JZjh4f+KKhuL/A5gTnc1K0rRw2u/3z+eXA76XA==";
   };

Ensuite, nous allons autoriser cette clé a mettre à jour notre domaine (ou sous-domaine si vous avez séparé vos entrées)

zone "guiguiabloc.fr" {
type master;
file "/etc/bind/zone.guiguiabloc.fr";
allow-update { key dnscloud.guiguiabloc.; };
allow-query { any; };
};

Dans votre fichier de zone, ajouter votre entrée de type A :

$TTL 180        ; 3 minutes
cloud01                 A       91.12.34.56

Vous remarquerez que je force un TTL a  180 secondes (important, par défaut les entrées sont valables 24h…)

On reload Bind et on tente une mise à jour à distance :

serveur# nsupdate -d -k ./Kdnscloud.guiguiabloc.fr.+157+06250.private
   Creating key...
   > server ns.guiguiabloc.org.
   before getaddrinfo()
   > update delete cloud01.guiguiabloc.org.
   > update add cloud01.guiguiabloc.org. 180 A 212.56.43.21
   > send
...
Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  60872
;; flags: qr ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; TSIG PSEUDOSECTION:
cloud1.guiguiabloc.fr.     0       ANY     TSIG    hmac-md5.sig-alg.reg.int. 1275379509 300 16 X3gUWw/uLyIJL4RykJbp24w== 60872 NOERROR 0

Et dans les logs de votre serveur Bind :

Jun  1 10:05:09 NS named[2224]: client 82.247.168.242#26928: signer "dnscloud.guiguiabloc.fr" approved
Jun  1 10:05:09 NS named[2224]: client 82.247.168.242#26928: updating zone 'guiguiabloc.fr.fr/IN': delete all rrsets from name 'cloud01.guiguiabloc.fr'
Jun  1 10:05:09 NS named[2224]: client 82.247.168.242#26928: updating zone 'guiguiabloc.fr/IN': adding an RR at 'cloud01.guiguiabloc.fr' A

Magique

Ne reste qu’a scripter tout cela.

2 techniques pour récuperer l’ip (a vous de choisir celle qui vous convient ) :

1. On se créer une petite page php sur un de nos serveurs web qui nous donne l’ip depuis la laquelle nous nous présentons :

cat index.php
 
<?PHP
echo $_SERVER["REMOTE_ADDR"];
?>

On l’héberge sur un nom style ip.guiguiabloc.fr et il suffit d’appeler (via Curl) l’adresse ip.guiguiabloc.fr pour récuperer notre ip fixe.

1. On récupère l’adresse IP via ifconfig

ifconfig eth0 | egrep 'inet adr:'| cut -d: -f2 | awk '{ print $1}'

Le script :

cloud# cat update_cloud.sh
#!/bin/bash
IP=`curl -s ip.guiguiabloc.fr`
 
# Si ifconfig
 
# IP=`ifconfig eth0 | egrep 'inet adr:'| cut -d: -f2 | awk '{ print $1}'`
 
# check si changement
ACTUALIP=`/usr/bin/dig +short cloud01.guiguiabloc.fr @ns.guiguiabloc.fr | /usr/bin/tail -n1 `
 
if test "$ACTUALIP" = "$IP"
then exit 0
else
 
cat > /var/scripts/majdnscloud.txt << EOF
server ns.guiguiabloc.fr
zone guiguiabloc.fr
update delete cloud01.guiguiabloc.fr. A
update add cloud01.guiguiabloc.fr. 180 A $IP
show
send
EOF
 
nsupdate -k /var/scripts/Kdnscloud.guiguiabloc.fr.+157+06250.private -v /var/scripts/majdnscloud.txt
fi

Et hop, on se met a au démarrage du cloud (genre a la fin et rc.local) et au reboot du cloud, le dns sera mis automatiquement à jour.

• DJBDNS

Si vous n’utilisez pas Bind mais l’excellent DJBDNS, il existe un tutorial très bien fait pour appliquer la même technique :

http://qmail.jms1.net/djbdns/dyndns.shtml

Voilà, j’espère que cette technique vous servira, non seulement pour vos serveurs amenés à changer d’adresse IP, mais également chez vous, si vous avez une IP dynamique et vous souhaitez utiliser vos propres noms de domaines.

Amusez vous bien