Résumés
youtubeDJ Ware

pf Deep Dive FreeBSD 15.0

Cette vidéo présente la configuration complète d’un pare-feu PF (Packet Filter) sur FreeBSD, depuis l’installation des règles jusqu’à l’activation permanente, en insistant sur l’importance des snapshots ZFS et de la vérification des modules noyau.

Voir la source

SYNTHÈSE STRUCTURÉE

Préparation de l’environnement avec bectl

L’intervenant utilise bectl pour gérer les environnements FreeBSD sur ZFS. Il liste les snapshots existants avec bectl list et explique qu’ils servent de points de restauration en cas d’erreur. Il précise : « These give me roll back points in case something goes horribly wrong ». Cette pratique est essentielle avant toute modification sensible du système, car elle permet de revenir à un état stable sans réinstallation.

Vérification de l’absence de pare-feu existant

Avant d’activer PF, il contrôle qu’aucun autre pare-feu n’est en cours d’exécution. Il utilise service ipfw status pour GhostBSD (qui utilise IPFW) et sysrc -a | grep firewall pour lister toutes les entrées liées au pare-feu dans /etc/rc.conf. Il insiste : « We don’t have any firewall rules in there », ce qui garantit un départ propre.

Structure du fichier de règles /etc/pf.conf

Le fichier de configuration est central. L’intervenant définit d’abord des variables pour simplifier la maintenance :

extinface = "em0"
lan_net = "192.168.1.0/24"
ssh_port = "22"
jail_net = "172.25.0.0/24"

Il explique que ces variables sont ensuite utilisées dans les règles, par exemple pour le NAT : nat on $extinface from $jail_net to any -> ($extinface). Il précise que l’utilisation de variables évite les erreurs de duplication et facilite les modifications ultérieures.

Stratégie de blocage par défaut

La règle initiale est block all pour le trafic entrant et sortant. L’intervenant justifie : « I always start there because sometimes I’ll rethink my network and then I’ll just go in and re… ». Cette approche « deny by default » est une bonne pratique de sécurité : on n’autorise que ce qui est explicitement nécessaire, réduisant ainsi la surface d’attaque.

Règles d’autorisation essentielles

Il ouvre ensuite des exceptions :

  • Loopback : pass quick on lo0 all (tout autorisé sur l’interface locale).
  • Sortant : pass out proto { tcp, udp } from any to any (trafic IPv4 et IPv6 sortant).
  • Entrant : pass in on $extinface proto tcp to port $ssh_port (SSH uniquement).
  • DHCP : pass in on $extinface proto udp from any port 67 to any port 68 (pour obtenir une adresse IP).
  • ICMP : pass in inet proto icmp icmp-type echoreq (ping autorisé pour le diagnostic).

Blocage du bruit réseau

L’intervenant ajoute des règles pour bloquer les paquets indésirables, notamment ceux émis par les appareils Apple : « If you stick a Mac on your network, you automatically get these broadcasters that just yell and scream ». Il utilise block in quick on $extinface proto udp from any to any port { 137, 138, 5353 } pour filtrer les services comme NetBIOS et mDNS.

Chargement du module noyau PF

Avant d’utiliser pfctl, il faut que le module noyau soit chargé. Il vérifie avec kldstat | grep pf et kldstat | grep pflog. Il explique : « If this kldstat did not have this loaded, you would get an error here because it would fail ». Sans ces modules, PF ne peut pas fonctionner.

Activation et test avec pfctl

La commande pfctl -f /etc/pf.conf charge les règles sans les activer. Il utilise echo $? pour vérifier le code de retour (0 = succès). Ensuite, pfctl -e active le pare-feu. Il prévient : « The first time it encounters that SSH, it might hang your SSH session ». En effet, si la règle SSH n’est pas correcte, la connexion est coupée ; il faut alors utiliser la console physique.

Persistance via sysrc

Pour que PF soit actif au redémarrage, il configure les services système :

sysrc pf_enable=yes
sysrc pf_rules="/etc/pf.conf"
sysrc pflog_enable=yes

Il vérifie avec sysrc pf_enable que la valeur est bien prise en compte. Cela évite de devoir relancer manuellement après chaque reboot.

Vérification finale des règles et du NAT

Il utilise pfctl -s rules pour lister toutes les règles actives et compter leur nombre (38 dans son exemple). Pour le NAT, pfctl -s nat affiche la règle de traduction d’adresse. Enfin, un test de ping (ping -c 3 8.8.8.8) confirme que le trafic sortant fonctionne.

CONCEPTS CLÉS

  • PF (Packet Filter) : Pare-feu natif de FreeBSD, OpenBSD et macOS, fonctionnant au niveau du noyau. Il gère le filtrage de paquets, le NAT et la redirection.
  • bectl : Outil de gestion des environnements FreeBSD sur ZFS, permettant de créer et restaurer des snapshots du système racine.
  • pfctl : Utilitaire en espace utilisateur pour contrôler PF : charger des règles, activer/désactiver le pare-feu, afficher les statistiques.
  • sysrc : Commande pour lire et modifier les variables de /etc/rc.conf de manière fiable, utilisée pour la persistance des services.
  • NAT (Network Address Translation) : Technique qui traduit les adresses privées (ex. 172.25.0.0/24) en adresse publique sur l’interface externe, permettant aux machines du réseau interne d’accéder à Internet.

CONCLUSION

La configuration d’un pare-feu PF sur FreeBSD est un processus méthodique qui combine préparation (snapshots, vérification des modules), rédaction de règles claires avec des variables, activation progressive et persistance via sysrc. L’approche « deny by default » et le blocage du bruit réseau sont des pratiques de sécurité fondamentales. L’intervenant insiste sur l’importance de tester avec une VM ou une console physique pour éviter de perdre l’accès SSH. Enfin, il rappelle : « Stay secure and take your snapshots », soulignant que la sauvegarde de l’état du système est aussi cruciale que les règles elles-mêmes.

Du même canal

Tout voir