RAPPORT SUR LES CAPACITÉS DE PF POUR LA HAUTE DISPONIBILITÉ

Transcription

1 RAPPORT SUR LES CAPACITÉS DE PF POUR LA HAUTE DISPONIBILITÉ Projet SRS, EPITA Promotion Bertrand Pallier Cyrille Barthelemy Julien Gremillot 6 novembre 2004

2 Sommaire 1 Introduction Présentation de PF Problèmes liés aux firewalls pour la haute disponibilité Présentation des solutions Disponibilité et diffusion Architecture de PF Utilisation de PF Règles de filtrage Table d état Journalisation Performances et sécurité Normalisation de paquets Répartition de charge Performances Architecture de CARP Présentation de CARP Mise en place de CARP sysctl ifconfig Exemple d utilisation Limitations et futur de CARP

3 4 Synchronisation des firewalls : PFsync Fonctionnement Général Considération de sécurité Description de l architecture Protocole et implémentation Base Exemple de synchronisation Exemple de traitement d un paquet PFsync Vision concrète de la synchronisation Intégration dans un parc hétérogène PFsync dans l avenir Etude de cas Architecture réseau Configuration firewall Mise en évidence des capacités pour la haute disponibilité Conclusion 25 Glossaire 26 Bibliographie 27 Page 1

4 CHAPITRE 1. INTRODUCTION Chapitre 1 Introduction 1.1 Présentation de PF PF (Packet Filter) est le firewall d OpenBSD depuis la version 3.0, il est fourni avec le noyau de base (GENERIC), l ancienne solution de filtrage / NAT d OpenBSD n étant plus supportée pour des raisons de licence. PF est actuellement capable d effectuer un filtrage du trafic, des opérations de traduction IP, de normaliser le trafic, de le conditionner ainsi que de fournir des opérations de contrôle de la bande passante et de gestion des priorités sur les paquets. Récemment, avec la version 3.5 sortie en mai 2004, OpenBSD et PF supportent des mécanismes qui permettent d envisager le support de problématiques de l ordre de la haute disponibilité. Ce rapport présente les problématiques liées à un firewall en terme de haute disponibilité, les solutions apportés par OpenBSD et PF, l architecture de ces solutions, ainsi qu une étude de cas concrète de la solution et quelques tests de performance effectués sur la solution. 1.2 Problèmes liés aux firewalls pour la haute disponibilité Sur beaucoup de réseaux le firewall se présente comme un point de rupture (Single Point Of Failure); de nombreuses architectures reposent sur cet unique élément à un point précis de leur réseau. Pour un service de télécoms et réseaux devant fournir un SLA 1 élevé, le firewall devient alors une source de rupture de service importante. Ce point est d autant plus important à prendre en compte avec le rôle du firewall (élément directement impliqué dans la politique de sécurité du réseau) qui se retrouve à 1. Service Level Agreement Page 2

5 CHAPITRE 1. INTRODUCTION la fois point sensible en terme de disponibilité et de type de trafic (étant en première ligne d un réseau à priori hostile). La chute du firewall pouvant représenter divers risques (arrêt du service de consultation du web pour les utilisateurs, indisponibilité des services proposé à l extérieur, mail, dns, serveur web,... ), qui ont généralement un coût financier non négligeable, il est primordial de se pencher sur les problématiques de haute disponibilité quand bien même l environnement ne présente pas de risques apparents. 1.3 Présentation des solutions OpenBSD 3.5 et PF permettent de répondre aux solutions de haute disponibilité pour un firewall en implémentant différentes solutions : construction d un cluster de firewall création d interfaces virtuelles communes aux noeuds du cluster synchronisation de l état interne du firewall constitué par les différents noeuds du cluster L utilisation conjointe de ces solutions via le protocole CARP pour la création d interfaces virtuelles redondantes ainsi que de pfsync pour la synchronisation de l état de PF permet d envisager le maintient du service dans le cas ou l un des noeuds du firewall viendrait à tomber après la concrétisation d un risque quelconque (coupure de courant, erreur matérielle, dénis de service dans une certaine mesure (ciblé sur un noeud par exemple)). Par ailleurs les autres caractéristiques de PF permettent de créer des solutions modifiables finement tant au niveau de la gestion du traffic que de l authentification, on pourra notamment retenir : ALTQ (gestion de la bande passante) AuthPF (passerelle authentifiée) 1.4 Disponibilité et diffusion Ce document est placé sous licence FDL. 2 Merci de prévenir les auteurs pour pour toute utilisation faite de ce document Page 3

6 CHAPITRE 2. ARCHITECTURE DE PF Chapitre 2 Architecture de PF 2.1 Utilisation de PF PF fait donc partie du noyau d OpenBSD depuis OpenBSD 3.0. Il est venu remplacer IPFilter, dont la licence ne correspondait plus aux idéaux des développeurs OpenBSD. Le but premier de PF est, comme tout bon firewall, d assurer la protection d un réseau envers les attaques issues d un réseau différent. Cela passe par l inspection des paquets transmis d un réseau à l autre, en imposant un certain nombre de contraintes à respecter pour obtenir ce passage, contraintes pouvant être aussi bien au niveau du type de paquet, que du contenu ou de la destination de celui-ci Règles de filtrage Les règles de filtrage consistent en une évaluation des paquets. Tout paquet, entrant ou sortant, peut être amené à être vérifié par les règles définies. Une règle consiste en la vérification d informations concernant le paquet (adresses IP, ports,...). Un paquet à vérifier passe de facon linéaire par toutes les règles définies (hors optimisations effectuées par PF ou par l utilisateur par l intermédiaire du mot clé quick), le traitement à effectuer est alors déterminé. Une règle stipule en effet le traitement réservé à un paquet validé par ses soins : soit il doit être rejeté, soit il doit être accepté. Un paquet peut être rejeté catégoriquement avec l envoi une réponse, ou silencieusement. Un paquet validé peut être transmis tel quel ou modifié. Si un paquet vérifie plusieurs des règles définies dans la liste, c est la dernière règle validée qui l emporte, ce qui permet un système assimilable à un tamis dont la granularité Page 4

7 CHAPITRE 2. ARCHITECTURE DE PF irait en se réduisant au fur et à mesure des étages (la maille tend à se ressérer, la maille la plus fine possible retenant la pierre). On commence donc par citer des règles grossières qu on affine ensuite, l exemple typique étant le bloquage par défaut de tout paquet, puis une mise en place de règles suivantes laissant passer des paquets spécifiques. Une règle pourra cependant être définie comme finale, ce qui impliquera pour tout paquet la vérifiant la non évaluation des règles suivantes, ce sera donc l action qui lui est attachée qui sera effectuée Table d état Tout paquet ne sera pas forcément passé au crible des règles. Il existe en effet des situations dans lesquelles il est superflu de procéder á une vérification systématique qui sont celles notamment de connexions établies entre deux ordinateurs et dont le flux passe par PF. C est à ce niveau qu intervient la table d état, en gardant une trace des connexions établies pour ne pas avoir à réaliser le coûteux traitement des règles. Chaque règle laissant passer un paquet crée une entrée dans la table d état Ainsi chaque paquet arrivant sera vérifié postérieurement à son évaluation afin de définir si il fait partie d une connexion ou non. Si il y a présence d une connexion établie dans la table d état, il ne sera pas évalué et passera directement. Suivant les protocoles, le traitement diffère. En TCP par exemple, qui est un mode connecté, le suivi de connexion est bien plus aisé qu avec des modes non connectés (UDP, ICMP...). En mode non connecté, la connexion établie est en quelque sorte émulée avec l aide d un timeout, très faible lors du passage du premier paquet puis qui augmente lorsque l on a acquis la certitude qu il s agit d un véritable échange. Une sécurité a été mise en place en ce qui concerne TCP afin de d éviter les attaques sur les numéros de séquence des paquets. Cette sécurité met en oeuvre la vérification de la fenêtre TCP établie, et s applique pour tous les paquets TCP supposés faire partie d une connexion. Page 5

8 CHAPITRE 2. ARCHITECTURE DE PF /* * Trouver des differences entre le dernier * paquet verifie et celui-ci * ip_state.c, v 1.16 */ seq = nthol (tcp->th_seq); ack = nthol (tcp->th_ack); source = (ip->ip_src.s_addr == is->is_src.s_addr); if (source) { seqskew = seq - is->is_seq; ackskew = (ack - 1) - is->is_ack; } else { ackskew = seq - is->is_ack; seqskew = (ack - 1) - is->is_ack; } /* [snip] rendre les valeurs ackskew et seqskew absolues */ /* * si la difference entre sequence et ack se trouve dans la taille * de la fenetre, on enregistre les donnees et on verifie le paquet */ win = ntohs (tcp->th_win); if ((seqskew <= is->is_dwin) && (ackskew <= is->is_swin)) { /* le paquet remplit les conditions de la table d etat */ if (source) { is->is_seq = seq; is->is_ack = ack; if (win!= 0) is->is_swin = win; } else { is->is_seq = ack; is->is_ack = seq; if (win!= 0) is->is_dwin = win; } statistiques ; valeurs de timeout ; autorisation du paquet; } /* le paquet ne correspond pas a l enregistrement de la table d etat */ paquet ne passe pas; Page 6

9 CHAPITRE 2. ARCHITECTURE DE PF En ce qui concerne les protocoles non connectés, la vérification d appartenance à une connexion se fait sur l adresse de l hôte et le port uniquement. Quant aux paquets ICMP contenant des messages d erreur concernant une connexion établie dans la table d état, ils passent directement (ce qui n est pas le cas des paquets ICMP standards qui recoivent le traitement habituel des paquets dont le protocole est non connecté, ce qui permet aux applications telles ping et traceroute de fonctionner). Les états sont stockés dans un AVL afin de garantir un traitement rapide grâce à des algorithmes à la complexité moindre que sur un tableau par exemple, ce qui est très avantageux dans le cadre d un nombre d entrees importantes.. (de l ordre de log(n)) Le NAT est bien entendu supporté. La table d état contient alors trois paires d adresses/ports : interne, gateway et externe, stockées dans deux arbres différents (le premier avec les paires internes et externes et le second avec les paires externes et gateway) afin de pouvoir traiter le paquet en une seule passe. Le PAT est également supporté Journalisation PF présente un système de journalisation tout à fait original. Celui-ci est en effet basé sur une sorte d émulation d un matériel réseau consultable via l interface pflog. Ceci permet par exemple la vérification en temps réel de ce qui se passe dans le firewall grace à la commande tcpdump lancée sur cette interface. L enregistrement peut se configurer et s effectuer par l intermédiaire de pflogd. Chaque paquet sur l interface a un header associé, documentant le paquet, et dont la structure se trouve dans <net/if_pflog.h>. Page 7

10 CHAPITRE 2. ARCHITECTURE DE PF 2.2 Performances et sécurité Normalisation de paquets PF possède une fonctionnalité appellée scrubbing, correspondant à la possibilité qu il a, suivant le mode selon lequel il est configuré, de vérifier certaines données sensibles d un paquet, telle une ambiguïté dans l interprétation d un paquet, le réassemblage des paquets fragmentés ou encore le refus de paquets TCP dont les drapeaux sont positionnés de manière invalide. Le traffic NFS, des protocoles étranges ou des jeux en réseaux peuvent être incompatibles avec l utilisation de scrub. Il est cependant recommandé de l installer dans la mesure du possible. Scrub permet d éviter les attaques basées sur la fragmentation de paquets. Les systèmes *BSD ne sont pas vulnérables à ce type d attaques, mais cela protège les machines équipées de piles IP plus faibles. Une autre des fonctionnalités de sécurité est de permettre de contrer la prédiction d ID pouvant être utilisée pour attaquer certains systèmes d exploitation. Ceci est géré en générant pour le paquet sortant un ID aléatoire Répartition de charge Le load balancing permet de répartir la charge entre n serveurs situés sur un sousréseau. Depuis novembre 2002 cette fonctionnalité est gérée. Il manque cependant certaines fonctionnalités avancées, telles que la gestion d incidents lorsqu un des serveurs tombe Performances Les performances dépendent beaucoup de l utilisation faite du firewall. Bien sûr, des contraintes de puissance processeur, et tous les éléments matériels entrant en ligne de compte, le nombre de bits à traiter chaque seconde sont importants, mais les critères principaux à retenir sont sans nul doute le nombre de requêtes à traiter chaque seconde ainsi que la complexité de la liste de règles à appliquer. Le traitement d un paquet ne variera guère quelle que soit sa taille. La carte réseau est importante. Pour la plupart des utilisations, un ordinateur de récupération avec une carte réseau de qualité donnera d excellentes performances. Page 8

11 CHAPITRE 3. ARCHITECTURE DE CARP Chapitre 3 Architecture de CARP 3.1 Présentation de CARP CARP (Common Address Redundancy Protocol) est un outil permettant à plusieurs machines de partager une interface réseau unique entre elles, afin de pouvoir partager la charge, ou obtenir de la redondance. Historiquement, c est un protocole qui a été développé pour remplacer VRPP (Virtual Router Redundancy Protocol), non seulement à cause de problèmes juridiques liés à un brevet de CISCO, mais aussi afin d obtenir un protocole supérieur (notamment l intégration de la cryptographie, le support d IPv6... ). C est un protocole qui se situe à l intersection de la couche 2 et 3 du modèle OSI (niveau lien et IP). Chaque groupe CARP possède une adresse MAC virtuelle, ainsi que une ou plusieurs adresses IP virtuelles. Les hôtes CARP répondent aux requêtes ARP pour les adresses communes avec l adresse MAC virtuelle, et les paquets d annoncement sont envoyés avec l adresse MAC virtuelle en source,ce qui permets aux switch de facilement savoir à un instant donné sur quel port se situe l adresse MAC virtuelle. Le maître de l adresse envoie régulièrement des paquets d annonce CARP via multicast en utilisant le protocole CARP (protocole IP 112), et les hôtes esclaves reçoivent ces annonces. Quand l annonce s arrête, les hôtes esclaves se mettent à envoyer leurs propres annonces, et celui qui s annonce le plus fréquemment est celui qui deviendra le maître. Page 9

12 CHAPITRE 3. ARCHITECTURE DE CARP 3.2 Mise en place de CARP Le contrôle de CARP s effectue grâce à sysctl et ifconfig sysctl Les variables sysctls qui sont disponibles sont: net.inet.carp.allow - Définit si l hôte gère ou pas les paquets CARP. net.inet.carp.arpbalance - Utilisé pour le load balancing. Un hash de l adresse IP source est utilisée pour sélectionner à partir du groupe l hôte virtuel qui prendra en compte la requête. net.inet.carp.log - Journalisation des erreurs CARP net.inet.carp.preempt - Active la sélection automatique du maître parmis les hôte CARP. Celui qui s annonce le plus fréquemment devient le maître ifconfig Les quatres commandes utilisés par CARP sont advbase - définit le nombre de secondes entre chaque annoncement advskew - divisée par 255, cette valeur est ajouté à advbase pour obtenir une plus grande précision pass - le mot de passe (shared secret) vhid - l ID d hôte virtuel du groupe CARP Les deux premières valeurs définissent la fréquence à laquelle l hôte va s annoncer. La formule exacte, en seconde est T = advbase + (advskew/255). Cela permet de contrôler précisement le temps entre chaque annoncement pour chaque hôte, et donc de définir qui sera le maître (grâce à la sélection automatique du maître, net.inet.carp.preempt). pass définit le mot de passe utilisé pour le hash SHA-1 MAC de signature, tandis que vhid est le numéro d identification d hôte virtuel du groupe CARP. Chaque groupe CARP doit avoir un ID unique, même si ils partagent la même adresse IP. CARP est limité à 255 groupes. Page 10

13 CHAPITRE 3. ARCHITECTURE DE CARP Exemple d utilisation Imaginons que l on dispose de deux serveurs DNS identiques, que l on souhaite utiliser avec CARP. L adresse IP du serveur virtuel sera dans cet exemple. Tout d abord, les commandes suivantes créent l interface carp0, lui assigne un ID de 1 et un mot de passe 8ball. hal9000# ifconfig carp0 create hal9000# ifconfig carp0 vhid 1 pass 8ball Ensuite, la création d un fichier /etc/hostname.carp0 rends la configuration effectuée ci-dessus permanente: inet vhid 1 pass 8ball Une fois ces opérations effectuées sur les deux machines, CARP est en place, et le premier système à démarrer son interface CARP deviendra le maître. 3.3 Limitations et futur de CARP CARP est un protocole multicast, ce qui pose problème dans le cas de cartes réseaux qui ne le supporte pas. De plus, comme CARP manipule directement les adresses MAC, certains switchs vieux ou fonctionnant mal peuvent avoir des problèmes avec CARP (par exemple, un rafraichissement des tables pas assez rapide rallongeant le temps offline ) 1. CARP ne procure aucune redondance à des niveaux plus élevés de la pile (par exemple nécessité d utiliser pfsync pour le firewall). Enfin, CARP ne sait pas gérer tout seul les situations ou une seule des interfaces tombe, mais pas toutes. Par exemple, dans le cas de deux firewalls, celui qui fonctionne encore parfaitement prend le relais du côté où l interface est tombée, mais pas sur l autre. Le problème vient du fait que la communication CARP s effectuant du côté qui est coupé, les deux firewalls ne voyant pas les annoncements de l autre pensent tout deux être maître. Il n y a cependant pas de moyen de résoudre ce problème sans faire appel à une troisième ressource, comme la passerelle, pour savoir quel firewall est en position de router le traffic. Ce dernier problème est assez rare mais l équipe des développeurs OpenBSD est en train de travailler sur ifstated qui permettra de le résoudre. 1. Des améliorations ont été apportées par la version 3.6 d OpenBSD Page 11

14 CHAPITRE 4. SYNCHRONISATION DES FIREWALLS : PFSYNC Chapitre 4 Synchronisation des firewalls : PFsync 4.1 Fonctionnement Général PFsync permet de mettre en parallèle deux firewalls sous PF ou plus. L ensemble du traffic passe par le firewall primaire, quand celui-ci devient indisponible, un firewall de secours prends le relai dans la gestion du filtrage du traffic. L ensemble des connections existantes sont préservées. PFsync va permettre de maintenir à jour sur un ensemble de machines les informations suivantes concernant la table d état utilisée pour l inspection des paquets en mode statefull : insertion mise à jour suppression PFsync est logiquement un protocole multicast, destinant la même information à un groupe de machines. Chaque firewall peut émettre des messages visant à mettre à jour les tables d états des différents noeuds du cluster, et écoute également l arrivée de messages émis par d autres noeuds. 4.2 Considération de sécurité Afin de répondre à des problèmes de performances (synchronisation et latence), il n y a ni cryptographie ni processus d authentification dans l échange des messages entre les firewalls. C est pourquoi il est fortement recommandé de relié les noeuds du cluster sur un brin réseau privé, ou dans le cas d un petit nombre de noeuds par l intermédiaire de cartes réseaux dédiées et de câbles réseaux croisés. Page 12

15 CHAPITRE 4. SYNCHRONISATION DES FIREWALLS : PFSYNC 4.3 Description de l architecture Concrètement sur le système le mécanisme de synchronisation passe par un pseudo device pfsyncx. Lorsque l interface virtuelle est associée à une interface physique, le mécanisme émet des messages multicast 1 afin d annoncer les changements aux autres noeuds du cluster. L association se fait simplement par la commande suivante : root@pfclus1 # ifconfig pfsync0 syncif vr0 up Par défaut toute modification de la table d état est annoncée aux autres noeuds, sauf si la connexion est liée à une règle comportant la directive no-sync. Diverses optimisations sont implémentées afin de réduire le traffic PFsync, notamment sur la bufferisation des messages afin de réduire le nombre d émission. 4.4 Protocole et implémentation Base Les fichiers suivant contiennent suffisamment de code relatif à PFsync pour en voir le fonctionnement en détail: sbin/ifconfig.c sys/net/if pfsync.c sys/net/if pfsync.h sys/net/pf.c sys/net/pf ioctl.c sys/net/pfvar.h On peut notamment consulter en détails les différentes actions que deux noeuds synchronisés par pfsync peuvent effectuer l un sur l autre : nettoyer tous les états (PFSYNC_ACT_CLR), insérer un état (PFSYNC_ACT_INS), mettre à jour un état (PFSYNC_ACT_UPD), supprimer un état (PFSYNC_ACT_DEL), mettre à jour un état à partir d un message composé (plusieurs informations dans un message) (PFSYNC_ACT_UPD_C), supprimer un état à partir d un message composé (PFSYNC_ACT_DEL_C), 1. le groupe multicast utilisé est Page 13

16 CHAPITRE 4. SYNCHRONISATION DES FIREWALLS : PFSYNC insérer un fragment (PFSYNC_ACT_INS_F), supprimer un fragment (PFSYNC_ACT_DEL_F), demander l envoi d états non composés (PFSYNC_ACT_UREQ), mise à jour de l état des Bulk (PFSYNC_ACT_BUS) Exemple de synchronisation Lors de l insertion d un état au sein de PF (après l ouverture complète d une session TCP par exemple), un appel à l API de PFsync est effectué : /* sys/net/pf.c */ int pf_insert_state(struct pfi_kif *kif, struct pf_state *state) {... #if NPFSYNC pfsync_insert_state(state); #endif } Exemple de traitement d un paquet PFsync La donnée est simplement traitée par la fonction pfsync_input, qui est appelée pour le traitement d un paquet arrivant sur l interface concernée. La fonction effectue un certain nombre de tests afin d assurer l intégrité des données : y a t-il une interface pfsync active? le paquet est-il bien arrivé par une interface pfsync? le ttl est-il égal à 255? (permet de s assurer que le paquet à au moins été émis localement 2 ) Les données sont ensuite extraites, notamment le code de l action à effectuer (cf. listing précédent), qui permet ensuite de traiter le reste des données. 2. cela complique au moins les moyens d attaque du système, même si ce n est pas invulnérable Page 14

17 CHAPITRE 4. SYNCHRONISATION DES FIREWALLS : PFSYNC Vision concrète de la synchronisation La capture correspond à la création d une connection vers un serveur ssh protégé par le cluster de firewall. root@pfclus1 # tcpdump -i pfsync0 -s vv 15:45: UPD ST: self carp > vrrp.mcast.net SINGLE:NO_TRAFFIC age 00:00:16, expires in 00:00:00, 16:0 pkts, 896:0 bytes, rule 1 id: a creatorid: 61c92b99 updates: 0 15:45: INS ST: self tcp :22 < :22 < :32787 CLOSED:SYN_SENT [0 + 1] [ ] age 00:00:00, expires in 00:00:00, 0:0 pkts, 0:0 bytes id: a creatorid: 61c92b99 15:45: UPD ST: self tcp :22 < :22 < :32787 ESTABLISHED:ESTABLISHED [ ] wscale 7 [ ] wscale 0 age 00:00:00, expires in 00:00:00, 1:0 pkts, 60:0 bytes id: a creatorid: 61c92b99 updates: 27 self carp > vrrp.mcast.net SINGLE:NO_TRAFFIC age 00:00:17, expires in 00:00:00, 17:0 pkts, 952:0 bytes, rule 1 id: a creatorid: 61c92b99 updates: 0 15:45: UPD ST: self carp > vrrp.mcast.net SINGLE:NO_TRAFFIC age 00:00:20, expires in 00:00:00, 19:0 pkts, 1064:0 bytes, rule 1 id: a creatorid: 61c92b99 updates: 0 self tcp :22 < :22 < :32787 ESTABLISHED:ESTABLISHED [ ] wscale 7 [ ] wscale 0 age 00:00:03, expires in 00:00:00, 14:15 pkts, 1758:2228 bytes id: a creatorid: 61c92b99 updates: 12 15:45: UPD ST: self carp > vrrp.mcast.net SINGLE:NO_TRAFFIC age 00:00:22, expires in 00:00:00, 21:0 pkts, 1176:0 bytes, rule 1 id: a creatorid: 61c92b99 updates: 0 self tcp :22 < :22 < :32787 FIN_WAIT_2:FIN_WAIT_2 [ ] wscale 7 [ ] wscale 0 age 00:00:05, expires in 00:00:00, 21:21 pkts, 2730:3004 bytes id: a creatorid: 61c92b99 updates: 10 Page 15

18 CHAPITRE 4. SYNCHRONISATION DES FIREWALLS : PFSYNC On a donc l occasion de voir le passage du message indiquant une nouvelle connexion (15:45: INS ST), l établissement de la connexion (15:45: UPD ST), puis plus tard la fermeture de la connexion (15:45: UPD ST). On a d ailleurs plusieurs exemples de la concaténation de plusieurs messages d états au sein d une seule émission. Cette synchronisation se confirme d ailleurs plus simplement en examinant les informations données par PF sur les deux noeuds à un même moment : root@pfclus1 # pfctl -s state STATES: self tcp :22 < :22 < :32787 ESTAB self carp > SINGLE:NO_TRAFFIC self carp > SINGLE:NO_TRAFFIC root@pfclus2 # pfctl -s state STATES: self tcp :22 < :22 < :32787 ESTAB self carp > SINGLE:NO_TRAFFIC self carp > SINGLE:NO_TRAFFIC 4.5 Intégration dans un parc hétérogène On pourra considérer l outil PFFLOWD [1], qui permet de convertir les messages de synchronisation émis par le mécanisme pfsync vers des datagrammes Cisco Netflow. Cela permet notamment de synchroniser les statistiques de flux et d expiration de connexion. La solution n est pas parfaite, principalement du à des problèmes de capacités des compteurs de flux dans le kernel d OpenBSD, mais le problème reste mineur. Il s agit en tout cas d une solution à prendre à considération, surtout en regard de sa facilité de mise en oeuvre. Exemple d envoi de synchronisation vers un routeur Cisco Netflow v5 adressé en : root@pfclus1 # pfflowd -n :1030 -i pfsync0 -v 5 -d 4.6 PFsync dans l avenir La nouvelle version d OpenBSD sortie le 1er novembre 2004, apporte quelques modifications à pfsync notamment sur la gestion de timeouts adaptatifs. Page 16

19 CHAPITRE 4. SYNCHRONISATION DES FIREWALLS : PFSYNC Les développeurs d OpenBSD prévoit les fonctionnalités suivantes dans les futures versions de pfsync : mécanisme d authentification pour l échange des messages support d autres fonctionnalité de PF (altq, tables etc... ) coopération avec CARP (meilleure réactivité) Page 17

20 CHAPITRE 5. ETUDE DE CAS Chapitre 5 Etude de cas Ce chapitre présente une mise en place d un cluster de firewalls basé sur PF, CARP et pfsync. Le but de l étude était de considérer concrètement la mise en place de l architecture ainsi que de faire quelques tests afin de constater concrètement la stabilité du système. Le lecteur intéressé par des tests plus complet sur les firewalls, pourra s orienter sur la RFC3511. Cette dernière est consacrée à la présentation d une méthodologie pour la réalisation de tests de performances sur des firewalls. Plus détails sur cette RFC sont disponibles dans les documents suivants : [2] et [3]. 5.1 Architecture réseau L architecture réseau décrite ici sert à simuler un modèle classique isolant deux réseaux distincts, qui peut éventuellement servir à isoler simplement un réseau privé d un réseau non sûr (local-dmz, local-internet, dmz-internet...) ou bien être intégré dans une infrastructure plus grande. Les postes utilisés dans les deux réseaux séparés par le clusters ont servis à simuler des clients classiques, des serveurs publics ainsi que des postes hostiles. Les deux serveurs ont les configurations suivantes: pfclus1 pfclus2 CPU Celeron 400 Mhz P3 1Ghz RAM 196 Mo 512 Mo NIC lan interne Dlink D390 Dlink D390 NIC lan externe Realtek 3Com 3c905c NIC PFsync Dlink D390 Dlink 390 Page 18

21 CHAPITRE 5. ETUDE DE CAS 5.2 Configuration firewall Les deux machines ont des configurations miroirs, à faire varier selon le nom des interfaces réseaux concernées. Dans notre cas, c est la machine pfclus1 qui servira d exemple : Le tableau suivant précise la configuration des interfaces réseaux : Nom Réseau Configuration IP vr1 lan interne /24 ne3 lan externe /24 vr0 PFsync /24 À cela viennent s ajouter 3 interfaces virtuelles crées lors de la configuration de CARP et pfsync : Page 19

22 CHAPITRE 5. ETUDE DE CAS L interface carp0 servant de front-end virtuel sur le LAN privé, crée par le fichier suivant : root@pfclus1 # cat /etc/hostname.carp0 inet vhid 1 pass p4sscarp0 De la même manière, l interface carp1 pour le LAN externe, crée par le fichier suivant : root@pfclus1 # cat /etc/hostname.carp1 inet vhid 2 pass p4sscarp1 Le champ vhid détermine un identifiant commun à toutes les interfaces physiques appartenant au groupe de cette interface CARP. Le champ pass définit un mot de passe pour le groupe. D autre part la synchronisation des firewalls est mise en place par la création du fichier suivant : root@pfclus1 # cat /etc/hostname.pfsync0 up syncif vr0 Par ailleurs il est nécessaire de paramétrer le système via les deux entrées suivantes : root@pfclus1 # cat /etc/sysctl.conf net.inet.ip.forwarding=1... root@pfclus1 # cat /etc/rc.conf pf=yes... pf_rules=/etc/pf.conf Enfin en dernier lieu, il est nécessaire de configurer le firewall. Lors de la création du firewall, il est important de prendre en compte certaines informations relatives aux interfaces virtuelles crées par le système : Autoriser le traffic pfsync sur l interface de synchronisation. Autoriser le traffic carp sur les interfaces physiques. Lorsque l on travaille en contexte d interface, on utilise uniquement des interfaces physiques. Lorsque l on travaille en contexte d adresse on peut utiliser les adresses relatives aux interfaces virtuelles. Ci-dessous un fichier de configuration d exemple de pf, il est totalement incomplet pour un cas réel, mais suffisant pour le cas de l étude, sous réserve d adapter le jeu de Page 20