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 😉
Et meeerde.. je suis aussi pervers que l’auteur de ce blog. mais en fait non. t’es encore plus pervers de filer un lien piégé. méchant :p
Bon sinon il est sympa ton nouveau joujou… comment donc t’es tu débrouillé pour avoir ça chez toi ?
le man in the middle en ssl est redoutable… c’est vrai que c’est bien pour filter de manière « préventive » mais y’a qu’un pas pour en détourner l’utilisation.
J’ai eu la chance d’être l’intermédiaire dans une phase de présentation 😉
C’est vrai que le détournement de son utilisation peut être dangereux mais bon, c’est le genre d’information dont dispose les équipes réseaux (logs proxy par exemple…), après c’est une question d’éthique.
Le problème de Palo ALto c’est le prix 🙂 Pour avoir demandé des devis, tu prends peur, un cluster Palo Alto coûte plus chers qu’un cluster Juniper ^^. Tu vas me dire il faut bien payer les fonctionnalités mais quand même !
Merci pour cet article bien sympathique.
Intéressant ; j’ai une question et une remarque 🙂
1) Question : tu dis qu’il suffit de faire signer le certificat SSL par une autorité de certification. Tu en es sûr ? Si je veux faire signer un certificat « mail.google.com », je pense que Verisign va gentiment me dire d’aller me faire cuire chez les grecs. En revanche, je pense que les boîtes qui déploient ça doivent installer un certificat racine « maison » dans les navigateurs de leurs utilisateurs. Ça implique quand même d’avoir une confiance sur-absolue en son employeur (et en Palo Alto Networks). Par exemple si le midi je commande des pizzas en ligne pour bouffer avec les collègues, mon numéro de carte est décrypté par le firewall. Spooky !
2) Remarque : c’est marrant d’appeler ça « un Palo Alto », parce que comme tu le sais sûrement, Palo Alto c’est une ville de la Silicon Valley ; et pour quelqu’un qui vit dans le coin, c’est comme l’appeler « un Grenoble » ou « un Bordeaux » (quoi que « pour des raisons de sécurité on va maintenant se servir un coup de Bordeaux » ça me branche bien, tiens…)
@Pro21 ca reste quand même moins cher que du Checkpoint 😉
@Jérome : 1- ce n’est pas le certificat du serveur que tu fais signer, mais celui du boitier ! exemple ca.guiguiabloc.fr, signé par une autorité reconnu par le navigateur pour éviter l’alerte. Le boitier reconstruit ensuite un certificat pour le client avec ce certificat et celui du serveur qu’il intercepte (reprenant la durée de validité, l’url pour lequel il est valable etc…). Si tu savais ce qui est visible dans les trames du Firewall tu serais plus effrayé que cela 😀 (il y a meme une fonction de recherche sur les numéros de CB justement…).
C’est comme tout équipement filtrant dans un réseau d’entreprise, l’équipe réseau en sait/voit beaucoup…
2- le nom complet est Palo Alto Networks, simplifié en PAN ou en Palo Alto. Parait meme qu’il existe une boite qui a appelé son produit phare « fenêtres » 😀
et bien dis donc tu t’es fais plaisir dans cette article !
merci j’ai appris pas mal de chose, que je vais devoir creuser ! le filtrage des appli à l’air redoutable !
question à partir de quelle taille de structure / organisation ce type de matériel est justifié ?
nota : tatiana a de belles jambes lol
Sebastien
existe t il des equivalents de filtrage niveau 7 open source? j’ai l’impression que l’investissement pour produire de telles solutions reste assez consecent.
iptables fait du filtrage au niveau 7 en le patchant (http://l7-filter.sourceforge.net)
EN IPS/IDS, il existe SNORT. Vyatta, également fait du niveau 7.
@sebastien désolé pour le retard pour l’approbation de ton post qui a trainer dans les spams :/
Le modèle que j’ai testé coute 18 000 euros et est clairement destiné a des entreprises de bonne tailles (tu trouveras les caracs sur le site du fabricant). Il existe des modèles pour tout les types d’infra, après, est-ce justifié ?… telle est la question 🙂
Merci (tardif) pour ce post, toujours très didactique et plein de peps. Je reste fan, tant sur le fond que la forme 😉
Je m’attendais à pire pour Tatiana 😉
merci 🙂
Ah ah ah, c’est vrai j’aurais pu faire pire :p
Je corrige juste un petit détail:
le fait de faire signer le certificat SSL par Verisign ne supprimera pas le warning du certificat du navigateur.
En effet le navigateur vérifie que le nom du certificat correspond au site web de l’URL, sinon warning. Et je ne pense pas que Verisign soit prêt à vous delivrer un certificat ayant comme nom mail.google.com … ou alors j’en veux un aussi:)
La seule solution est de rajouter le certificat du Palo Alto (signé par un CA ou non) comme autorité de certification approuvé par le navigateur, ce qui nécessite quand même des droits sur le poste client.
Ca peux rassurer ceux qui utilisent leur ordinateur personnel, mais pas les ordinateurs des réseaux d’entreprise ou se genre de paramètre peut être ajouté par les administrateurs.
@Manuman Je suis mal exprimé. Dans ce ca on se moque royalement de l’url du site web inclus dans le certificat.
Le PaloAlto fait tampon entre le client et le serveur et réécrit le certificat a la volée, SAUF l’autorité racine.
Si le certificat du PaloAlto est autosigné par Verisign avec l’url paloalto.guiguiabloc.fr, le client verra un certificat Verisign et l’url demandé (aka mail.google.com) est-ce plus clair ?
Salut à tous, je sui en train de faire des tests sur un paloalto pa-500 et j’aimerais tester le man in the middle SSL mais je n’y arrive pas. Pourrais-je avoir quelques infos supplémentaires sur la procédure à suivre?
La documentation complete et la KB sont disponibles sur le site de PaloAlto, rubrique support.
Le PAN produit dynamiquement un certificat X509 dont le DN est celui du site cible, et dont l’émetteur (issuer) est l’AC qu’il y a dedans.
Soit cette AC est « de confiance » pour le navigateur, et il n’y a pas de warning, soit cette AC doit être la fille d’une AC de confiance.
Ca pose quand même des problèmes éthiques voire juridiques de déchiffrer les communications SSL de ses employés, surtout quand elles contiennent des informations réputées confidentielles… De même, je ne sais pas trop si les sites cibles (surtout les sites bancaires) aiment beaucoup qu’on se fasse passer pour eux, même temporairement.
Bien sûr, ici, on a du MIDM passif (écoute et analyse du trafic) ou semi actif (blocage des flux identifiés comme « menaces » – mais la notion de menace est à la discrétion de l’admin), mais rien n’empêche, demain de faire de la réécriture. Et pouf, mon virement de 10E est devenu un virement de 10000E. La banque dira que tu es identifié convenablement, et tu auras du mal à faire réparer le préjudice.
Pingback: GuiGui's show » Toujours bon à savoir
Bonjour,
j’ai bien aimé ce blog, mais je vois une grosse erreur que beaucoup de gens font :
crypter/décrypter n’existe pas en français !! c’est de l’angliscime !!
donc il faut utiliser : chiffrer/déchiffrer :p (tous les vrais acteurs de la sécurité parlent de chiffrement et déchiffrement, et une personne en sécurité qui vous parler de crypter/décrypter est soit anglais, soit … :Dà
@Pierre-Antoine et oui je sais 🙂 comme on dit pare-feu et pas firewall, a etat de sessions et pas statefull etc.. C’est plutot par généralité que par francisation que j’ai ecris cela, mais je note la remarque 🙂
Pour chiffrer on parle effectivement de chiffrement. Pour déchiffrer on parle de déchiffrement quand on a la clé et qu’on fait ça à la régulière, et bien de décryptage quand on n’a pas la clé et qu’on essaye de casser le chiffrement.