Déploiement d’un pare-feu haute disponibilité Conntrackd Déploiement d’un pare-feu haute disponibilité

Notions préliminaires (rappel) Netfilter framework (part feu noyau linux) Souvent confondu avec iptables Intégré en mars 2000 (2.3) Bien documenté Bien structuré et pensé ! Système de « hooks » Fonctions de callback référençables sur les « hooks » Permet le développement aisé de modules Netfilter framework implément le part feu au niveau du noyau linux Intégré en mars 2000 (kernel version 2.3) Ecrit de zero (ancien part feu n’était plus adapté..) Bien documenté (cf Netfilter.org) Bien structuré et pensé ! Système de « hooks » : points d’acroche sur lesquel on peut référencer une fonction de callback Permet le développement aisé de modules et applications

Notions préliminaires Plus de précision sur les hooks 5 hooks Plusieurs fonctions de callback peuvent être enregistré sur chaque (système de priorité) nf_register_hook() permet d’enregistrer une fonction de callback Les fonctions de callback peuvent retourner 5 valeurs différentes qui seront utilisés par Netfilter ACCEPT : Le paquet continu son chemin DROP : Le paquet est silencieusement détruit QUEUE : Passes the packet to userspace via the nf_queue facility. Thus a userspace program will do the packet handling for us. STOLEN : Silently holds the packet until something happens, so that it temporarily does not continue to travel through the stack. This is usually used to collect defragmented IP packets. REPEAT : Forces the packet to reenter the hook. En gros, les hooks permettent d’enregistrer des fonctions qui vont gérer les paquets; les framework base ensuite sa décision sur le retour des fonctions…

Notions préliminaires Stateful vs Stateless Intérêt d’être Stateful Granularité accrue Performances accrues Protocol helpers possible (L7) Nombreuses possibilités offertes Module de connection tracking de netfilter Statefull vs Stateless Dans le cadre de firewall, Ne pas confondre avec les protocoles; TCP possède des états alors que UDP n’en possède pas et pourtant netfilter va quand même etre statefull avec UDP… Intérêt d’être Statefull Granularité accrue : il est possible de faire des rêgles plus précises, pas seulement basé sur le paquet qu’on examine mais sur ce qui c’est passé avant également Performances accrues : Du fait de l’implémentation, il est plus rapide de se référencer à la tables des états (implémenté avec une hashtable) que d’effectuer une prise de décision depuis zéro (en évaluant les rêgles une a une). Protocol helpers possible (L7) : Possibilité de créer des programmes pour permettre à certains protocoles sale de pouvoir passer le firewall (ex FTP Actif) Nombreuses possibilités offertes Le Module de connection tracking de netfilter permet de rentre le firewall statefull (rmq: ce module est également nécessaire pour le NAT)

Notions préliminaires Module de connection tracking de NF Informations mémorisées 4 Etats de connexion : New Established Related Invalid Utilise des fonction de callback Module de connection tracking de NF Informations mémorisées (IP src, IP DST, PORts SRC ET DST, Protocol, Etat, Timeout) > Prise de décision plus intéligente Ne filtre pas les paquet lui-même, se contente de mémoriser des informations 4 Etats de connexion : New : Traffic observé que dans une direction Established : Communication dans les 2 send observée Related : Connection liée à une autre ( helper ) Invalid : Paquet qui ne se sont pas comporté normalement Avec les définitions ci-dessus, UDP est statefull ! Utilise des fonction de callback (4) pour se lier à Netfilter (Creation d’une conntrack, Défragmentation, Helper, Mise a jour d’une conntrack)

Conntrack-tools Userspace tools Conntrack Conntrackd HA Statistiques Repose sur libnetfilter_conntrack Encore mis a jours, nouvelles fonctionalité, correction de bugs (7/2009) Userspace tools Conntrack : Diagnostic, affichage optimisé des informations du module de connection tracking (info dans /proc/net/ip_conntrack), possibilité de filtrer l’affichage …. Conntrackd : Permet la synchronisation de la table d’état entre plusieurs firewall; permet ainsi d’implémenter des firewall statefull à haute disponibilitée. Peut également être utilisé pour exporter des statistiques.. Repose sur libnetfilter_conntrack fournis par le projet netfilter. Cette librairie permet De lister / Recuperer / inserer/ modifier /supprimer des entrées de la table de connection tracking du noyau

Architecture à 1 Firewall Single point of failure !

2 Firewall valent mieux qu’un ! Problème : Comment faire pour que le trafic utilise l’un ou l’autre des firewall ? Autre formulation : On souhaite que le trafic passe toujours par un firewall qui marche; la transition doit être rapide et sans intervention.

Failover Plusieurs Protocoles : VRRP CARP (openBSD) … RFC 3768 IP et @MAC virtuelles (00-00-5E-00-01-XX) Priorité de 0 à 254 CARP (openBSD) Pas de RFC IP protocol 112 (choisit de force !) … VRRP RFC 3768 IP et @MAC virtuelles (00-00-5E-00-01-XX) XX étant le numéro du groupe VRRP (VRID) Un maitre et des esclaves Priorité de 0 à 254 Si le maitre ne parle plus, l’esclave avec la priorité la plus haute prend le relai Le maitre répond aux requètes ARP et à l’adresse IP l'adresse multicast 224.0.0.18 avec un numéro de protocole IP 112, CARP Philosophie similaire Né du conflit OpenBSD/Cisco (qui détient le brevet sur VRRP) OpenBSD a pris de force le numéro 112 de protocol (suite au silence de l’IANA) “We are strongly entertaining the thought of writing a OVRRP protocol (which we would design to be maximally conflicting, of course) “ Nous faisons le choix d’utiliser VRRP pour la suite du fait qu’il est documenté dans une RFC…

2 Firewall avec VRRP! L’adresse IP virtuelle 10.0.0.254 est partagée par les deux firewall sur le lan A. L’adresse IP virtuelle 10.0.1.254 est partagée par les deux firewall sur le lan B. L’adresse IP virtuelle 10.0.0.254 est partagée par les deux firewall sur le lan A. L’adresse IP virtuelle 10.0.1.254 est partagée par les deux firewall sur le lan B. Deux instance de VRRP sont exexuté sur chaque firewall (une par ip virtuelle)…

Ou en sommes nous ? Failover mis en place Si un firewall tombe, un second est là… Et la table d’états dans tout ça ? Perdue car pas de synchronisation Qu’elle est le problème ? Règles de part feu « stateful » NAT Helpers… Failover mis en place Si un firewall tombe, un second est là… Et la table d’états dans tout ça ? Perdue car pas de synchronisation Qu’elle est le problème ? Si on n’exploite pas le coté statefull : AUCUN! Règles de part feu « statefull » : Si on pert la table d’état, on a plus d’états sur les connection et les régles basé sur les états vont échoué (ESTABLISHED) NAT : Le NAT repose sur la table d’état, les communications NAT vont être coupées! Ex: Intéruption de transfert de données … Helpers…

2 Firewall en HA (conntrackd + VRRP) Apparition d’un lien de synchronisation Possibilité d’avoir plus de 2 firewall Pour le moment Actif/Passif Implémentation d’un mode Actif/Actif avec équilibrage de charge prévu… Meme structure que précédement, apparition d’un lien dédié entre les firewall destiné à la synchronisation de la table d’état Possibilité d’avoir plus de 2 firewall Pour le moment Actif/Passif Implémentation d’un mode Actif/Actif avec équilibrage de charge prévu…

Fonctionnement de conntrackd Mises à jour envoyés en multicast 3 protocoles de synchronisation (au choix) No track (best effort) Ft-fw Alarm Mises à jour envoyés en multicast : 1 seul envoi pour tous les replicas 3 protocoles de synchronisation (au choix) ; Le protocole de synchro est essentiel, il doit assurer que les tables sont constament synchronisé, sinon conntrackd ne sert a rien ! No track (best effort) : non fiable, envoie des données, pas aquitement… Ft-fw : Protocole fiable (ACK,NACK) : Dernier implémenté (plus récent) Alarm : Protocole par inondation , renvoie périodiquement l’intégralité de la table ; permet de resynchroniser rapidement mais très gourmand en bande passante.

Autres solutions Nombreuses solutions commerciales (checkpoint, juniper, arkoon, cisco, sonicwall…) Dans le monde BSD : pfsync + CARP Nombreuses solutions commerciales (checkpoint, juniper, arkoon, cisco, sonicwall…) Dans le monde BSD : pfsync + CARP pfsync equivaut a conntrackd et CARP à VRRP, pf équivaut à netfilter.

Démonstration

Des questions ?

Merci de votre attention