![\"\"](\"http:\/\/blog.guiguiabloc.fr\/wp-content\/2011\/04\/Come_on_guys.jpg\" "\\"Come_on_guys\\"")
<\/a>Photographe:Cpl Barry Lloyd RLC Cr\u00e9dit : www.defenceimages.mod.uk<\/p><\/div>\n
Aujourd’hui je vous propose de vous parler d’une nouvelle g\u00e9n\u00e9ration de Firewall mais aussi, je l’esp\u00e8re, vous pousser \u00e0 la r\u00e9flexion sur notre conception du firewall telle qu’on l’a aujourd’hui en se demandant, si, apr\u00e8s tout, on n’est pas un peu r\u00e9trograde.<\/p>\n
Petit historique.<\/p>\n
Palo Alto Networks<\/a> est une soci\u00e9t\u00e9 cr\u00e9\u00e9e en 2005 par un monsieur tr\u00e8s connu du monde de la s\u00e9curit\u00e9 : Nir Zuk. Notre vision g\u00e9n\u00e9raliste 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<\/a>), ce \u00e0 quoi l’on va rajouter, bien s\u00fbr, cette fameuse inspection stateful.<\/p>\n pause<\/em><\/p>\n \u00ab\u00a0Mais dites moi Monsieur Abloc, c’est quoi \u00e7a l’inspection Stateful ???\u00a0\u00bb<\/em> <\/em><\/p>\n \u00ab\u00a0Je te remercie de poser la question, jeune padawan, mais vu que tu es un fid\u00e8le lecteur, dans ma grande mansu\u00e9tude, je t’autorise \u00e0 m’appeler guiguiabloc.\u00a0\u00bb<\/em><\/p>\n <\/em>\u00ab\u00a0Oh merci vous \u00eates bien bon avec moi ! C’est trop d’honneur\u00a0\u00bb (d\u00e9sol\u00e9, une crise passag\u00e8re…)<\/p>\n Dans un firewall vous allez, au niveau\u00a0 3, par exemple, autoriser telle adresse ip \u00e0 acc\u00e9der \u00e0 telle autre adresse ip. Au niveau 4, vous allez autoriser cette ip source \u00e0 acc\u00e9der depuis un port tcp sup\u00e9rieur \u00e0 1023 \u00e0 acc\u00e9der au serveur web de l’autre adresse ip sur le port 80.<\/p>\n (pourquoi sup\u00e9rieur \u00e0 1023 ? parce qu’une requ\u00eate cliente vers un serveur prend al\u00e9atoirement un port source sup\u00e9rieur \u00e0 ce nombre, les ports inf\u00e9rieurs \u00e0 1023 ne pouvant \u00eatre \u00ab\u00a0r\u00e9serv\u00e9\u00a0\u00bb qu’\u00e0 des services reconnus (je simplifie hein !)).<\/p>\n D’ailleurs il vous suffit de regarder vos connexions \u00e9tablies pour le voir :<\/p>\n guiguiabloc@Thanatos:~$ netstat -tan | grep 80 o\u00f9 192.168.8.201 est le client et 174.36.30.59, le serveur web.<\/p>\n Donc, remarque aux gens qui configurent leurs firewalls pour la premi\u00e8re fois, autoriser le 80 depuis l’ext\u00e9rieur vers l’int\u00e9rieur pour surfer, bah \u00e7a sert \u00e0 rien (on le voit souvent :p)<\/p>\n Jusqu’\u00e0 maintenant on est en mode \u00ab\u00a0stateless\u00a0\u00bb.<\/p>\n Le mode stateful va allez jusqu’\u00e0 la notion de session du protocole TCP.<\/p>\n Quand Kevin veut se connecter au serveur web de Tatiana<\/a> (qui offre avec gentillesse des apercus non n\u00e9gligeable de son architecture)), en tcp (donc niveau 4 \ud83d\ude09 ), il envoit un SYN\u00a0 (je veux me connecter \u00e0 toi, Tatiana, t’es trop de la balle), le serveur de Tatiana r\u00e9pond SYN\/ACK (j’ai pris connaissance de ton d\u00e9sir passionn\u00e9 de venir visiter mes zolies pages et de contempler la fa\u00e7on dont j’enroule mes c\u00e2bles), le pc de Kevin renvoit un ACK (oh oui, je veux voir tes zolies pages et tes c\u00e2bles si bien dispos\u00e9s, merci de me r\u00e9pondre Tatiana (flap,flap, flap)).<\/p>\n C’est ce qu’on appelle un triple-handshake (ou poign\u00e9e de main \u00e0 3 temps). (NB: le flap flap flap ne faisant pas partie de la n\u00e9gociation et je vous interdit dans vos esprits pervers de faire un quelconque rapport entre \u00ab\u00a0hand\u00a0\u00bb et \u00ab\u00a0shake\u00a0\u00bb dans l’exemple ci-dessus ! Ignoble individu que vous \u00eates !)<\/p>\n En plus, lors de cet \u00e9change, des num\u00e9ros de s\u00e9quence sont g\u00e9n\u00e9r\u00e9s et par le client (num\u00e9ro de s\u00e9quence initial), repris par le serveur (+1) qui y rajoute ses num\u00e9ros d’acquittement, que le client reprend aussi.<\/p>\n (je vais pas vous faire un cours sur tcp, Google est votre ami \ud83d\ude42 )<\/p>\n A cet instant, nous avons une session d’\u00e9tablie que le firewall, en mode stateful connait.<\/p>\n Il va donc consid\u00e9rer que vu que le flux existe et que la session est \u00e9tablie, il est d\u00e9sormais inutile d’analyser les paquets entre le client et le serveur pour cette session tcp, il consid\u00e8re que c’est autoris\u00e9 (c’est du filtrage dynamique).<\/p>\n 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.<\/p>\n L’inspection stateful permet donc un filtrage avanc\u00e9 sur les connexions \u00e9tablies ou non, m\u00eame si le port tcp est ouvert, il ne sera pas forc\u00e9ment accept\u00e9 par le firewall.<\/p>\n Exemple d’intrusion en mode stateless (sch\u00e9matiser sans NAT\/PAT toussa)<\/strong> :<\/p>\n Le pc client (Thanatos, 192.168.8.201) a un vnc server sur son poste en \u00e9coute sur le port 5900.<\/p>\n Le firewall entre lui et internet \u00e0 une r\u00e8gle de type :<\/p>\n permit tcp host ip client gt 1023 any eq 80<\/p>\n (le client en source port sup\u00e9rieur \u00e0 1023 peut aller voir des sites en http sur le port 80).<\/p>\n 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… \ud83d\ude00<\/p>\n Un firewall stateful, lui,\u00a0 rejettera ce genre de trafic puisque le SYN ne peut venir que du client, pas du serveur web.<\/p>\n NB<\/strong> : Pour les curieux qui voudrait savoir comment j’ai reproduit un mode stateless\/stateful dans cet exemple via des ACLs Cisco, voici les r\u00e8gles utilis\u00e9es (192.168.8.201 est le client, 192.168.43.100 est le serveur)\u00a0 :<\/p>\n Exemple 1 (stateless) :<\/p>\n permit tcp host 192.168.43.100 eq www any gt 1023<\/p>\n Exemple 2 (stateful) :<\/p>\n permit tcp host 192.168.43.100 eq www any gt 1023 established<\/p>\n Sous votre *BSD favori, il vous suffit de positionner l’option \u00ab\u00a0flags\u00a0\u00bb (S\/SA pour un SYN\/SYN-ACK).<\/p>\n Bien entendu je simplifie \u00e0 l’extr\u00e8me (d’autres \u00e9l\u00e9ments entre en jeux) mais j’esp\u00e8re avoir \u00e9clairer ceux qui ne connaissait pas ce mode de suivi de transaction entre deux machines.<\/p>\n fin de la pause<\/em><\/p>\n Sauf qu’au bout d’un moment, le stateful inspection, le filtrage de niveau 4, on en atteint vite les limites.<\/p>\n Alors, on va rajouter des couches et des couches d’IDS, d’IPS, au d\u00e9triment souvent des performances du firewall.<\/p>\n Palo Alto Networks propose donc une nouvelle g\u00e9n\u00e9ration de Firewall, avec des\u00a0 filtrages portant sur :<\/p>\n – l’identifiant de l’utilisateur (on ne g\u00e8re plus l’ip du poste client mais son identification propre par corr\u00e9lation avec un ActiveDirectory ou un LDAP, ou au pire en le renvoyant sur un portail captif pour une authentification Radius) (User-id<\/a>)<\/p>\n – l’application utilis\u00e9e (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<\/a>). Sachez que la liste des applications reconnues par le Palo Alto est assez cons\u00e9quente et que bien s\u00fbr, vous pouvez vous m\u00eame y d\u00e9finir vos propres applications.<\/p>\n – le contenu des trames cypt\u00e9es en faisant du \u00ab\u00a0Man-in-the-Middle\u00a0\u00bb SSL pour d\u00e9crypter en temps r\u00e9el les flux SSL\/HTTPS et regarder ce qu’il y ‘a dedans pour v\u00e9rifier sa dangerosit\u00e9 (nan nan, ton facebook par SSL, non plus, tu passeras pas)<\/p>\n – l’analyse du contenu des paquets (charge virale, DoS, filtrage URL etc…) (Content-id<\/a>). Evidemment le Palo Alto ne se base pas uniquement sur l’extension d’un fichier pour en connaitre le contenu \ud83d\ude09<\/p>\n Bien s\u00fbr; quitte a faire tout cela bien et rapidement, on va traiter le flux en\u00a0 1 seule passe et c\u00f4t\u00e9 hardware, d\u00e9dier des CPUs \u00e0 chaque usage avec quelques FPGA<\/a> pour faire bonne mesure.<\/p>\n Int\u00e9ressant non ?<\/p>\n \u00ab\u00a0D’accord mon grand, t’es gentil, mais pourquoi tu nous causes de \u00e7a ?\u00a0\u00bb<\/em><\/p>\n Parce que \u00e7\u00e0\u00a0 :<\/p>\n Et oui, j’ai eu la chance d’avoir un des ses bo\u00eetiers a la maison \ud83d\ude00<\/p>\n Apr\u00e8s une formation condens\u00e9e et efficace (merci Philippe \ud83d\ude09 ), on se positionne le PaloAlto en mode bridge derri\u00e8re la freeteuse.<\/p>\n (Rassurez vous, le bo\u00eetier a rapidement rejoint un environnement de production digne de ce nom pour subir la batterie de tests habituels.)<\/p>\n Mais qu’en est-il des premiers r\u00e9sultats ?<\/p>\n Le Firewall Palo Alto peut fonctionner en plusieurs mode :<\/p>\n – 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\u00e9ment une premi\u00e8re \u00e9tape pour le brancher dans votre infrastructure. Non intrusif, ce mode vous permet d’avoir d\u00e9j\u00e0 une premi\u00e8re id\u00e9e de ce qui passe dans votre r\u00e9seau (applications utilis\u00e9es, statistiques de consommation par flux et application etc…)<\/p>\n – le mode bridge (appel\u00e9 VirtualWire chez eux), en passerelle transparente. Les flux entrent d’un c\u00f4t\u00e9 et ressortent de l’autre. A ce niveau la, vous coder une r\u00e8gle autorisant tout et vous pouvez petit \u00e0 petit alimenter les \u00ab\u00a0policy\u00a0\u00bb suivant le trafic que vous voyez.<\/p>\n – le mode routeur\/firewall (en couche 3 donc) que tout le monde connait, avec ses interfaces \u00e0 configurer, ses vlans, ses routes etc… La il remplace votre firewall actuel.<\/p>\n Le Palo Alto a un processeur et une interface d\u00e9di\u00e9 au Management.<\/p>\n La CLI ne surprendra pas les habitu\u00e9s de Juniper. C’est clairement du Netscreen OS (rassurez vous, si vous utilisez Vyatta, c’est sensiblement pareil).<\/p>\n Ce qui est flagrant de sa parent\u00e9 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 \u00e9galement l\u00e0. Bref, clairement, c’est la touche Netscreen qui pr\u00e9domine.<\/p>\n C\u00f4t\u00e9 administration graphique, c’est du web, en ajax… Et l\u00e0, vous le verrez plus loin, c’est la partie noire du produit.<\/p>\n Quand on prend la b\u00eate en main pour la premi\u00e8re 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 \u00ab\u00a0pousse\u00a0\u00bb la conf par un \u00ab\u00a0commit\u00a0\u00bb.<\/p>\n Premi\u00e8re surprise, le commit, montre en main, prend plus de 2 minutes ! \ud83d\ude2e<\/p>\n Euh la on commence a avoir des angoisses, un commit \u00e0 vide (pas de r\u00e8gles, une conf de base)\u00a0 qui prend tant de temps c’est angoissant. On se dit que ca ira mieux plus tard…<\/p>\n Bref, on laisse tourner et on regarde.<\/p>\n L\u00e0 les premiers r\u00e9sultats sont bluffants. Tout est clairement identifi\u00e9, les flux bien s\u00fbr, mais \u00e9galement les applications utilis\u00e9es,<\/p>\n mes tunnels ssh dans le proxy,<\/p>\n les attaques de types Naphta\/Slowloris que j’ai envoy\u00e9 sur un serveur Web, etc..<\/p>\n En testant des r\u00e8gles g\u00e9n\u00e9riques de types \u00ab\u00a0deny application deezer\u00a0\u00bb, c’est redoutable \ud83d\ude42<\/p>\n Petit bonus \u00e0 tester, le man-in-the-middle SSL.<\/p>\n On se g\u00e9n\u00e8re un certicat SSL dans le bo\u00eetier.<\/p>\n On pose un filtrage SSL avec d\u00e9cryption.<\/p>\n Et hop, on teste depuis un navigateur client. Le truc tout b\u00eate, allez t\u00e9l\u00e9charger le fichier EICAR<\/a> antivirus en https.<\/p>\n Surprise, le certificat serveur sur le poste client \u00e0 changer, en regardant en d\u00e9tail , on retrouve notre certificat SSL g\u00e9n\u00e9r\u00e9 sur le Palo Alto en tant qu’\u00e9metteur, et les informations du certificat serveur dans les restes du contenu.<\/p>\n C\u00f4t\u00e9 d\u00e9tection, le Palo Alto a d\u00e9crypter le flux SSL et \u00e0 trouver la fausse charge virale dans le contenu. Bluffant.<\/p>\n Il se comporte donc comme un proxy forward SSL, agissant en temps qu’interm\u00e9diaire entre le serveur et le client, et en profitant pour analyser le contenu qu’il peut bien sur d\u00e9crypter.<\/p>\n Cela marche \u00e9galement sur https:\/\/mail.google.com… Effrayant \ud83d\ude09<\/p>\n Alors bien s\u00fbr 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\u00e9 reconnue par les navigateurs, Verisign par exemple).<\/p>\n Maintenant j’en pense quoi ?…<\/p>\n Palo Alto Networks nous pousse vers une nouvelle fa\u00e7on de surveiller et de g\u00e9rer les flux r\u00e9seau dans notre infrastructure.<\/p>\n Il est \u00e9vident que l’on n’a pas attendu leur venue pour faire du filtrage au niveau 7, pour filtrer les requ\u00e8tes SQL via GreenSQL<\/a> , faire du firewall authentifiant<\/a> ou du d\u00e9cryptage SSL<\/a>.<\/p>\n Maintenant, plut\u00f4t que r\u00e9\u00e9crire ce qui a \u00e9t\u00e9 dit, je vous invite \u00e0 lire les diff\u00e9rents documents et comparatifs que Palo Alto a pondu :<\/p>\n http:\/\/www.paloaltonetworks.com\/literature\/index.php<\/a><\/p>\n Toutefois, c’est clairement le type de Firewall a positionner entre vos utilisateurs et vos serveurs.<\/p>\n En frontal Internet pour prot\u00e9ger l’acc\u00e8s \u00e0 vos DMZ cela ne changera rien \u00e0 un bon Checkpoint\/ASA\/OpenBSD (apr\u00e8s tout, si l’on ouvre l’acc\u00e8s public \u00e0 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 \u00e0 utiliser votre IPS).<\/p>\n C’est vrai qu’en y r\u00e9fl\u00e9chissant, l’acc\u00e8s de vos utilisateurs \u00e0 vos ressources internes demande \u00e0 d\u00e9passer ce niveau de filtrage basique.<\/p>\n L’\u00e9quipe de d\u00e9veloppeurs du projet A, que je reconnais par leurs User-Id, ne peut acc\u00e8der qu’aux applications les concernants et pas aux applications d’un autre projet B, m\u00eame s’ils sont dans le m\u00eame vlan (oui oui, le fameux tcp\/3306 autoris\u00e9 pour l’ensemble des dev sur le vlan de bases de donn\u00e9es \ud83d\ude09 ).<\/p>\n Cibler l’acc\u00e8s \u00e0 des applications suivant le profil des utilisateurs, c’est peut \u00eatre cela qui nous manquait aujourd’hui.<\/p>\n Quand a filtrer l’acc\u00e8s 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\u00e9 de l’entreprise (par exemple). Question de choix. Ce n’est pas \u00e0 nous d’en d\u00e9cider, mais dans ce cas, Palo Alto r\u00e9pond clairement au besoin.<\/p>\n 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\u00e8gles de filtrages et surtout les appliquer (2minutes 30 \u00e0 vide alors que sur mes Checkpoint avec plus de 1000 r\u00e8gles de filtrage et autant de NAT cela me prend moins de temps), c’est inutilisable au quotidien par une \u00e9quipe habitu\u00e9e \u00e0 pousser de nombreuses r\u00e8gles par jour. A r\u00e9gler donc.<\/p>\n En r\u00e9sum\u00e9, par la d\u00e9couverte de cette nouvelle g\u00e9n\u00e9ration de Firewall, il est \u00e9vident qu’il nous faut repenser la fa\u00e7on de filtrer les diff\u00e9rents \u00e9l\u00e9ments de nos infrastructures.<\/p>\n Si le danger vient beaucoup de l’ext\u00e9rieur, il existe aussi clairement \u00e0 l’int\u00e9rieur d’un SI, que le suivi des utilisateurs par autre chose que leurs adresses IPs, que l’acc\u00e8s pr\u00e9cis aux applications doit \u00eatre un devenir du r\u00f4le du firewall interne, c’est s\u00fbrement un axe de r\u00e9flexion \u00e0 avoir d\u00e8s maintenant, car comme dirait Nir Zuk :<\/p>\n \u00ab\u00a0Votre choix : innover ou dispara\u00eetre.\u00a0\u00bb<\/p>\n Bonne r\u00e9flexion \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":" Aujourd’hui je vous propose de vous parler d’une nouvelle g\u00e9n\u00e9ration de Firewall mais aussi, je l’esp\u00e8re, vous pousser \u00e0 la r\u00e9flexion sur notre conception du firewall telle qu’on l’a aujourd’hui en se demandant, si, apr\u00e8s tout, on n’est pas un … Read More
\nSi son nom ne vous dit rien (bouh ! Honte \u00e0 vous, que vous soyez flageller sur la place publique et que les corbeaux viennent \u00e9corcher votre peau blanch\u00e2tre (euh non, je suis un peu trop extr\u00e9miste l\u00e0…) ), sachez que Nir Zuk est l’un des cr\u00e9ateurs du Stateful inspection de Checkpoint,<\/a> l’ancien directeur technique de Netscreen Technologies (rachet\u00e9 par Juniper<\/a>) et aussi cr\u00e9ateur d’un des premiers IPS du march\u00e9 via son ancienne soci\u00e9t\u00e9 OneSecure. Bref, un type qui s’y connait \u00ab\u00a0un peu\u00a0\u00bb \ud83d\ude09<\/p>\n
\n\u00ab\u00a0De rien mon petit, vas en paix et \u00e9coute\u00a0\u00bb<\/em><\/p>\n
\ntcp\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0\u00a0\u00a0\u00a0\u00a0\u00a0 0 192.168.8.201:44450\u00a0\u00a0\u00a0\u00a0 174.36.30.59:80\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ESTABLISHED<\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n