Firewalling sous BSD

Ivan KURZWEG Firewalling sous BSD - PF 2009 Ivan KURZWEG,ivan.kurzweg@gmail.com, 2009 Introdction (cours et TP) sur le firewall PF d'OpenBSD ... Not an How-TO !! On prendra soin de consulter le man de pfctl, et de suivre l'excellente documentation PF sur le site www.openbsd.org. Ne sont pas abordées les techniques de gestion de bande passante (AltQ).

Cantique du SyAdmin, Peter N. M. Hansteen This is my network. It is mine or technically my employer's, it is my responsibility and I care for it with all my heart there are many other networks a lot like mine, but none are just like it. I solemnly swear that I will not mindlessly paste from HOWTOs.

Firewalls Définitions, principes Un pare-feu est un élément du réseau informatique, logiciel et/ou matériel, qui a pour fonction de faire respecter la politique de sécurité du réseau, celle-ci définissant quels sont les types de communication autorisés ou interdits. (Wikipedia) Pf : OpenBSD's Packet Filter, a été intégré dans le système base d'OpenBSD 3.0 en Décembre 2009. Le développement en urgence de PF a été causé par un problème de licence sur l'ancien système de filtrage de paquets, IPFilter. Statefull : L'état peut être conservé pour un trafic spécifique. Les firewall sont configurés pour autoriser certains trafics (par exemple, le trafic sortant). L'état du trafic est mémorisé pour chaque extrémité de la connexion logique (aussi bien pour le protocole tcp (orienté connexion) que pour les protocoles udp, ou icmp) et des règles implicites sont dynamiquement chargées/retirées du firewall selon l'état de la connexion. Netfilter/Iptables : système de filtrage de paquet sous Linux, incluant firewalling statefull, nat, pat, ... Machines Firerwalls On trouve principalement deux types de matériels : Machines Unix, mais attention aux installations par défaut, qui activent des services potentiellement dangereux ... à l'existence de compte sans mot de passe. Matériels dédiés (type Cisco ... ), mais attention aux coûts ! Principes Les firewalls interviennent généralement sur plusieurs plans : Les paquets : les firewalls interviennent généralement sur la Couche 3 IP. Ainsi, ils peuvent analyser les différents champs des paquets IP. Les protocoles : les fonctionnements de UDP, ICMP et de TCP imposent aux firewalls de manipuler les paquets et de stocker éventuellement un état des transactions (statefull) Les les connexions : lors de la connexion d'un client sur un serveur, les échanges doivent être garantis par le firewall, si le traffic est autorisé Les ports : en jouant sur les ports, les firewalls filtrent le traffic, et sont capables de redirigés des flux entrants ou sortant sur des cibles différentes. Les adresses : selon les adresses sources et destinations (unicast, broadcast, network ou multicast OpenBSD pf Fonctionnalités c'est un stateful firewall (décisions basées sur l'état d'une connexion logique) il utilise la notion de macros (variables à expanser), ce qui permet de paramétrer le jeu de règle ; ce qui facilite la maintenance et améliore la portabilité ; il utilise des tables (de hachage) qui permettent de stocker de large plage d'adresses, tout en assurant un temps d'accès constant ; il implémente le NAT (ré-écriture des adresses sources en sortie) et la redirection (ré-écriture des adresses destination en entrée) ; il opère dans le mode de la « dernière correspondance gagnante », mais propose un mode de court-circuit avec le mot clé quick ; il propose une fonction de normalisation de trafic (scrub) qui annule toutes ambiguïtés dans les paquets reçus et à transmettre aux destinataires (en entrée ou en sortie) ; il supporte nativement plusieurs méthodes implémentant le contrôle de bande passante (par gestion de files de priorités selon différents algorithmes) il dispose d'un mécanisme implicite d'ordonnancement des règles ; il dispose d'un excellent mécanisme de log et de statistiques. Activation sous FreeBSD Si PF est disponible directement sous OpenBSD, sa mise en oeuvre sous FreeBSD implique généralement la recompilation du noyau, ou le chargement dynamique du module pf : Chargement manuel du module pf sous FreeBSD # kldload pf.ko Chargement automatique du module pf sous FreeBSD, fichier <filename>/boot/loader.conf</filename> Modification du noyau Dans les deux cas, il est nécessaire d'intervenir sur le fichier /etc/rc.conf pouyr activer PF au démarrage de la machine, et charger les jeux de règles : Fichier <filename>rc.conf</filename> Contrôle de PF PF possède un puissant outil de manipulation des règles, des tables et de collecte de statistiques, pftcl. pfctl [-AdeghmNnOqRrvz] [-a anchor] [-D macro= value] [-F modifier] [-f file] [-i interface] [-K host | network] [-k host | network] [-o [level]] [-p device] [-s modifier] [-t table -T command [address ...]] [-x level] Utilisations de la commande <filename>pfctl</filename> # pfctl -d //désactiver pf # pfctl -e //activer pf # pfctl -f /etc/pf.conf -n //tester le fichier de configuration # pfctl -f /etc/pf.conf -v //charger en mode verbeux le fichier de conf # pfctl -sr //afficher le jeux de règles en cours # pfctl -s info //statistiques de filtrage # pfctl -t banned -T show //afficher le contenu de la table banned # pfctl -t banned -T add 192.168.0.12/32 //ajouter un hôte à la table banned Logging Lorsque les directives de log sont activés, les paquets voulus sont envoyés vers la pseudo interface pflog0. Cette pseudo interface réseau est alors directement atteignable via les classiques outils d'analyse réseau : Analyse temps réel de l'activité de PF : # tcpdump -netvli pflog0 239.255.255.250.1900: udp 318 (ttl 127, id 51797, len 346) rule 1/(match) [uid 0, pid 2208] block in on em0: 172.17.8.6.138 > 172.17.8.127.138: udp 201 (ttl 128, id 6662, len 229) rule 1/(match) [uid 0, pid 2208] block in on em0: 172.17.8.6.138 > 172.17.8.127.138: udp 201 (ttl 128, id 6662, len 229, bad cksum 0!) .... ]]> Cette facilité d'analyse rend PF bien plus agréable à utiliser que Netfilter/Iptables sous Linux ! En effet, par la Configuration de PF D'une manière générale, les règles de PF sont définies dans un seul fichier de configuration, par défaut le fichier /etc/pf.conf. Ce fichier est composé de plusieurs sections : Les définitions en utilisant les macros, les tables et les listes les règles d'optimisation et de contrôle de bande passante les règles de NAT les règles de filtrage Listes et macros Listes Une liste permet de manipuler des valeurs de même types (liste d'adresses, liste de ports, ...). Elle sont repérées par des accolades. Exemples de listes Lors de l'analyse par PF du fichier de configuration, les listes sont décomposées en plusieurs règles, chacune avec une valeur de la liste. Les listes sont donc à utiliser dans le cas d'un nombre de valeur restreint. Macros Les macros sont des variables définies par l'utilisateur. En stockant des valeurs, elles facilitent la lecture du fichier de configuration et sa maintenance. Exemples de macros Dans le premier exemple, les macros sont définies récursivement. Les tables Une table permet le regroupement d'adresses au sein d'une même entité. Les spécificités des tables par rapport aux listes standard sont les suivantes : Utilisation directe et multiple dans les règles, comparable à une macro Les recherches d'une adresse sont beaucoup plus rapides (utilise moins de mémoire et de temps CPU qu'une simple liste) Existence qui va au-delà du fichier de configuration où elles sont définies puisqu'elles résident ensuite en mémoire ce qui permet de leur appliquer des modifications au niveau de leur contenu. Ces modifications sont immédiatement prises en compte par Packet Filter sans avoir à recharger les règles ou à procéder à une quelconque manipulation. Déclaration Le contenu d'une table est sensiblement identique à celui que l'on peut fournir comme adresse source ou de destination dans les règles en temps normal. Il peut prendre les différentes formes suivantes : Une adresse IP (version 4 comme 6), exemples : 192.168.0.1, 66.80.97.134 Une adresse en notation CIDR (version 4 comme 6) : 192.168.0.0/24 Un nom de machine qui sera automatiquement remplacé par les adresses IP correspondantes (versions 4 et 6) à condition de pouvoir effectuer cette résolution (ne pas oublier de construire des règles visant à autoriser le trafic DNS) Le nom d'une interface (sis1, lo0, etc), qui sera substituée par la liste des adresses qui lui sont attribuées Le nom d'une interface suivie de :network, :broadcast, :peer ou :0 correspondant respectivement à l'adresse réseau, l'adresse de broadcast, l'adresse d'un pair sur un lien point à point ou l'adresse principale affectée à une carte réseau (ne tient pas compte des alias) Exemples de tables const { \ 172.17.0.1/32, \ 172.17.0.239/32, \ 172.17.0.240/32 \ } table persist ]]> Dans le deuxième exemple, la tables banned est déclarée vide, mais persistante. On pourra donc ajouter à la volée des adresses dans cette table, et dans notre cas précis, interdire à des postes certains traffics. La manipulation des tables est possible en utiisant la commande pfctl (voir chapitre précédent). Options de normalisation et d'optimisations Dans un fichier de configuration de PF, il peut-être intéressant de spécifier un certrain nombre de valeurs, modifiant les réactions du firewall. Sont présentées les plus communes : block-policy : ce paramètre spécifie si les tentatives de connexion refusées sur des ports provoquent ou non un retour d'erreur (de type connexion-refused). Sa valeur peut-être drop (valeur par défaut) ou return. skip : cette directive permet d'ignorer les règles sur une interface (typiquement la boucle locale). scrub : il est possible pour PF de normaliser une partie du traffic réseau en réassemblant des paquets fragmentés ou en en éliminant certains. L'utilisation commune de cette valeur est : antispoof : cette directive permet de détecter et bloquer les tentatives d'usurpation d'adresse IP, sur les réseaux directement connectés à PF. Il permet par exemple de bloquer des paquets venant du WAN portant des adresses locales. Translations d'adresses et redirections Translation d'adresses Mécanisme indispensable à l'interconnexion de réseaux de différentes classes d'adresses, la translation d'adresse (NAT : Network Address Translation) permet de modifier les adresses sources du traffic, pour masquer par exemple la structure du LAN. Dans l'exemple proposé en TP (cf. schéma réseau), lors d'une connexion d'une machine du LAN (192.168.36/0/24) vers un serveur du WAN, la passerelle/pare-feu transmettrait le flux vers le WAN, en translatant l'adresse source vers sa propre adresse (172.17.0.1). Le traffic retour est alors automatiquement translaté de manière symétrique, et les paquets remis à la machine du LAN. Sous PF, il est possible de déifnir sur quelles interfaces, pour quels flux, la translation d'adresse doit se faire. La syntaxe générale des règles NAT est la suivante : ext_addr [pool_type] [static-port] ]]> pass : désactive le filtrage pour les paquets translatés interface : l'interface sur laquelle les paquets sont translatés ext_addr : l'adresse (ou les adresses) sur laquelle les paquets sont translatés Exemple de règle NAT ($ext_if) block all pass from { lo0, $localnet } to any keep state ]]> Redirection de ports La redirection de ports permet de rediriger les flux arrivant sur une interface, un port vers une machine physique, sur un port précis. Dans l'exemple proposé en TP (cf. schéma réseau), le serveur WEB de la DMZ doit être joignable du WAN. IL faut donc rediriger les connexions sur le port HTTP vers le serveur WEB. Exemple de règle de redirection $server \ port 80 ]]> Filtrage Les règles de filtrages sont examinées dans l'ordre d'apparition, la dernière règle correspondant au traffic examinée est appliquée. Si aucune règle ne correspond au paquet, la politique par défaut est appliquée. Dans le cas où le mot clef quick est passé dans la règle, la règle est immédiatement appliqué, sans parcourir le reste des règles. Politique par défaut De manière générale, la politique par défaut d'un firewall est de bloqué tout traffic, puis d'autoriser unqiuement ce que l'on souhaite. Politique par défaut block in all block out all Règles de filtrage La syntaxe générale des règles est la suivante : action [direction] [log] [quick] [on interface] [af] [proto protocol] \ [from src_addr [port src_port]] [to dst_addr [port dst_port]] \ [flags tcp_flags] [state] action : prend les mots clefs pass ou block quick : si le mot clef est présent et que le paquet correspond à la règle, l'action est immédiatement appliquée on interface : l'interface où a lieu le filtrage state : si la règle contient les mots clefs keep state, les paquets futurs correspondant à cet échange seront acceptés Exemples de règles TP Environnement Le TP peut-être réalisé pour des raisons de simplification de mise en oeuvre sur des machines virtuelles. Il s'agit de simuler un réseau LAN classique contenant : LAN : une ou plusieurs machines simulant des postes de travail d'un LAN DMZ : un ou plusieurs serveurs abritant par exemple un serveur WEB, accessible depuis le WAN, et depuis le LAN en HTTP et SSH WAN : une machine simulant un poste sur Internet, qui pourra jouer le rôle d'un pirate ou d'un cilent WEB, et un serveur jouant le role de "site internet" Schéma général du réseau

Schéma du réseau Travail à faire Les différents objectifs à atteindre : Mise en place des réseaux : installation des machines (éventuellement virtuelles), des services (serveurs WEB, SSH, ...) Configuration de la passerelle : interconnexion des réseaux, tests (ICMP) Configuration du Firewall : filtrage des paquets en fonctions des réseaux, des services, etc ... Charge aux stagiaires d'imaginer LEUR réseau ... Un exemple de fichier pf.conf complet pour un serveur DNS Le fichier de configuration suivant pourrait être appliqué à un serveur DNS. Certaines parties ont volontairement été supprimées. Exemples d'un fichier <filename>pf.conf</filename> < 65535 }" proxy_p="3128" ftp_RP="{ ftp, 30000:40000 }" ### ========================================================================== ### Tables: similar to macros, but more flexible for many addresses. ### ========================================================================== table const { \ 172.17.0.1/32, \ 172.17.0.239/32, \ 172.17.0.240/32 \ } table const { \ 172.17.0.1/32, \ 172.17.0.126/32, \ 172.17.0.200/32, \ 172.17.0.201/32, \ 172.17.0.223/32, \ 172.17.0.225/32, \ 172.17.0.228/31, \ 172.17.0.230/32, \ 172.17.0.231/32, \ 172.17.0.232/32, \ 172.17.0.233/32, \ 172.17.0.234/32 \ 172.17.0.237/32, \ 172.17.0.239/32, \ 172.17.0.240/28 \ } table const { \ 172.17.1.0/25, \ 172.17.2.0/25, \ 172.17.3.0/25, \ 172.17.4.0/25, \ 172.17.5.0/25, \ 172.17.6.0/25, \ } table const { 217.109.43.210/32 } table const { 172.17.0.247/32 } table const { 172.17.0.253/32 } table const { 172.17.0.234/32 } ### ========================================================================== ### Options: tune the behavior of pf, default values are given. ### ========================================================================== set limit { states 12000, frags 5000 } set loginterface $dmz_if set optimization normal set block-policy drop set require-order yes set fingerprints "/etc/pf.os" set skip on lo ### ========================================================================== ### Normalization: reassemble fragments and resolve or reduce traffic ambiguities. ### ========================================================================== scrub in all random-id scrub on $dmz_if all reassemble tcp ### ========================================================================== ### Filtering: authorized all on the loopback interface ### ========================================================================== #block quick inet6 all block in quick log on $dmz_if from block log all antispoof log quick for { lo0 $dmz_if } inet pass in quick on $dmz_if inet proto tcp from \ to $dmz_if port $ssh_port flags S/SA modulate state pass in quick on $dmz_if inet proto { tcp, udp } from \ to $dmz_if port domain keep state pass in quick on $dmz_if inet proto { tcp, udp } from \ to $dmz_if port domain keep state pass out quick on $dmz_if inet proto tcp from $dmz_if port $unPrivPorts \ to port smtp \ flags S/SA modulate state pass out quick on $dmz_if inet proto udp from $dmz_if port syslog \ to port syslog pass out quick on $dmz_if inet proto udp from $dmz_if port domain \ to port domain \ keep state pass out quick on $dmz_if inet proto udp from $dmz_if port $unPrivPorts \ to any port domain \ keep state pass out quick on $dmz_if inet proto udp from $dmz_if to \ port ntp keep state pass out quick on $dmz_if inet proto tcp from $dmz_if port $unPrivPorts \ to port $proxy_p \ flags S/SA modulate state pass out quick on $dmz_if inet proto tcp from $dmz_if port $unPrivPorts \ to port $ftp_RP \ flags S/SA modulate state pass out quick on $dmz_if inet proto tcp from $dmz_if port domain \ to port domain \ flags S/SA modulate state pass out quick on $dmz_if inet proto { tcp, udp } from $dmz_if \ to any port domain keep state pass out quick on $dmz_if inet proto icmp from $dmz_if \ to any keep state pass in quick on $vlan_if inet proto { udp, tcp } from port $unPrivPorts \ to $vlan_if port domain \ keep state pass in quick on $vlan_if inet proto icmp from \ to $vlan_if keep state pass out quick on $vlan_if inet proto icmp from $vlan_if \ to keep state ]]> Références Firewalls - Pascal Picard FAQ OpenBSD PF - Peter N. M. Hansteen The Book of PF - NO STARCH PRESS Peter N.M. Hansteen