OpenBSD 7.7 comme base de pare‑feu robuste : une pf.conf et une sysctl.conf qui te couvrent

OpenBSD 7.7 comme base de pare‑feu robuste : une pf.conf et une sysctl.conf qui te couvrent

OpenBSD est réputé depuis des années pour son ethos de sécurité sans compromis : valeurs par défaut saines, code propre, et « secure by default » comme mandat, pas comme slogan. Si tu veux un pare‑feu fiable et explicable au quotidien, OpenBSD offre une base solide. En même temps, des bons défauts ne suffisent pas toujours : quelques réglages ciblés augmentent nettement le niveau de sécurité et la prévisibilité—sans transformer ton environnement en projet fragile.
Avec cet article, nous voulons te fournir une ligne de base pratique qui protège avec assurance de petits réseaux, des home‑labs et beaucoup d’environnements PME—tout en restant lisible et facile à maintenir.

Au lieu de listes interminables et de « tunings » arbitraires, tu trouveras ici des décisions argumentées avec des raisons claires. Nous t’expliquons pourquoi telle option est activée, quels risques elle adresse et quels effets secondaires garder en tête. Le but n’est pas de couvrir chaque attaque théorique, mais de te donner un point de départ fiable : des règles sobres, peu d’exceptions, un comportement prévisible.

Cette approche suit une ligne nette : autoriser explicitement ; sinon bloquer. De l’extérieur vers l’intérieur, on ne permet que ce dont le routeur a réellement besoin ; de l’intérieur vers l’extérieur, on ne laisse passer que ce que tu veux vraiment. Le DNS reste visible et contrôlable. DoH, DoT, DoQ et QUIC n’obtiennent pas de raccourcis silencieux afin d’éviter des « canaux invisibles ». Les états sont liés volontairement aux interfaces pour que les connexions restent là où elles sont nées. Cela rend le système prévisible et le dépannage supportable. Et parce que la transparence vaut mieux que dix astuces, tous les chemins critiques portent des étiquettes : en exploitation, tu vois immédiatement ce qui passe, ce qui est refusé et où resserrer la vis.

Pour rester concret, nous proposons deux profils pf parmi lesquels choisir : une variante routeur‑seul pour les scénarios LAN‑vers‑internet classiques, et une variante routeur+DMZ si tu veux isoler des services. Nous imposons le DNS des clients exclusivement vers 1.1.1.1 (avec 1.0.0.1 en secours facultatif). Ce n’est pas du pinaillage : c’est un choix d’architecture délibéré qui te redonne visibilité et contrôle. Si une application veut autre chose, ça se voit, et tu décides consciemment si et où accorder une exception.

Le fichier sysctl.conf complète cette posture au niveau du noyau. OpenBSD apporte déjà beaucoup, mais quelques commutateurs procurent un gain mesurable de robustesse : une configuration malloc durcie qui fait échouer plus tôt et plus bruyamment les bogues mémoire ; la désactivation de SMT/Hyper‑Threading quand les risques de canaux latéraux n’apportent aucun bénéfice ; W^X, qui préfère terminer les processus plutôt que de les laisser courir dans des zones grises dangereuses ; la coupure des redirections et des protocoles de tunnel non essentiels ; des options TCP modernes et des limites de débit modérées qui amortissent le « bruit » réseau sans casser les fonctions légitimes. Ce ne sont pas des « tweaks » tape‑à‑l’œil, mais de l’hygiène cohérente : moins de surface d’attaque, moins de surprises, un comportement plus stable sous charge.

Hors périmètre : les attaques très ciblées ou des déploiements IDS/IPS complets. Si tu veux du monitoring multi‑couches, de l’inspection profonde de protocoles ou des flux d’info‑menaces, cette configuration ne gêne pas ; c’est le socle sur lequel tu pourras ajouter ces briques méthodiquement plus tard. Nous omettons volontairement aussi les politiques multi‑WAN complexes, les port‑forwardings à foison ou des overlays exotiques. Tout cela est faisable, mais pas sans diluer la clarté de la baseline.

Notre parti‑pris de lisibilité implique aussi de préférer la mécanique à la magie. Le NAT est statique là où les protocoles temps‑réel en bénéficient, et dynamique là où c’est indifférent. QUIC reste dehors pour que le DNS ne se cache pas dans des flux TLS. IPv6 est bloqué au départ pour éviter « l’IPv6 à moitié »—quand les clients privilégient v6 alors que le pare‑feu ne le maîtrise pas ; plus loin, tu trouveras une recette propre pour activer IPv6 correctement si tu en as besoin. Et, quand c’est utile, nous marquons les cas limites avec des étiquettes—non pour colorer les logs, mais pour obtenir des réponses : qui a tenté de parler DoT ? Quels hôtes heurtent la règle anti‑rebind ? Qu’est‑ce qui déclenche les blocages sortants ?

Pour qui ? Pour toi si tu vois l’admin comme un métier et préfères investir une heure dans une base propre plutôt que trois semaines à chasser des effets de bord bizarres. Pour toi si tu veux comprendre ton réseau, au lieu d’être surpris par des autorisations par défaut. Et pour toi si tu te sens « entre deux chaises » : pas assez grand pour un SOC/blue team, mais trop exigeant pour un routeur de grande surface. Cette baseline n’est pas un tour de magie ; c’est un standard sensé : assez petit pour être maîtrisé, assez robuste pour durer.

Modèle de menace : contre quoi on se défend—et contre quoi non

Cette baseline vise des environnements sans équipe bleue dédiée qui veulent malgré tout des standards fiables. Elle te protège du bruit habituel qui frappe ton périmètre : scans massifs, exploits opportunistes, abus de protocoles (le « DNS au‑dessus de tout »), erreurs de configuration ou politiques de sortie (egress) généreuses qui rendent l’exfiltration possible. Elle encapsule des serveurs optionnels dans une DMZ, empêchant les mouvements latéraux vers le LAN. Ne sont pas au centre : les attaques très ciblées ou les piles IDS/IPS complètes—que tu pourras ajouter par‑dessus plus tard.

Principes de conception : petite surface d’attaque, responsabilités claires

La configuration suit des lignes directrices utiles aussi pour les futures évolutions :

Fail‑closed. Si ce n’est pas explicitement autorisé, c’est fermé—en entrée comme en sortie. Tu découvres tôt en test ce dont une appli a vraiment besoin et tu gardes la main.

États déterministes. if-bound assure qu’une connexion reste liée à l’interface d’origine. Sur routeurs mono‑WAN, finis les « états flottants » magiques : le dépannage devient plus simple.

Minimalisme sortant. De l’intérieur vers l’extérieur, seulement le nécessaire : web classique, soumission mail, plages UDP définies pour VoIP/WebRTC—et DNS uniquement vers la destination que tu choisis.

Transparence plutôt que devinettes. On bloque QUIC et aussi DoH/DoT/DoQ. Oui, c’est gênant pour certaines applis. En échange : clarté. DNS est DNS, TLS est TLS. Si quelqu’un a besoin d’un « DNS de l’ombre », ça se verra.

Valeurs par défaut robustes. Scrubbing, plafonnement MSS, IDs aléatoires, filtres bogons, anti‑spoofing, hygiène des drapeaux TCP et limites sensées pour ICMP et RST. Rien de spectaculaire ; ensemble, de l’hygiène solide.

IPv6 par choix. IPv6 est désactivé par défaut. Si tu le veux, la marche à suivre est détaillée plus loin. On évite systématiquement « l’IPv6 à moitié ».

sysctl.conf — Leviers de sécurité au niveau du noyau qui comptent vraiment

OpenBSD fournit déjà d’excellents défauts, mais quelques réglages renforcent nettement sécurité et prévisibilité. L’essentiel—sans listes interminables, avec des raisons claires.

Durcissement mémoire (vm.malloc_conf=CFGJRS). Guard pages, motifs « junk », red zones et canaries compliquent l’exploitation des bogues classiques et font échouer les processus à haute voix plutôt que de corrompre en silence. Le petit surcoût vaut la peine dans quasi tous les scénarios de routeur.

CPU/Matériel : SMT désactivé, aperture fermée. hw.smt=0 réduit les risques de canaux latéraux (Hyper‑Threading) ; sur un routeur, l’impact est généralement minime. machdep.allowaperture=0 ferme les accès type /dev/mem—idéal pour une machine headless. Si tu as besoin d’X11/KMS, tu le sais ; sinon, laisse fermé.

Routage & protocoles : IPv4 actif, IPv6 volontairement inactif. net.inet.ip.forwarding=1 transforme la machine en routeur IPv4. net.inet6.ip6.forwarding=0 empêche le routage « accidentel » IPv6. On désactive aussi des tunnels inutiles (IP‑in‑IP, GRE, ESP/AH, EtherIP). Moins de machinerie crypto/encapsulation = moins de surface d’attaque et de surprises.

Désamorcer les pièges legacy. Diffusions dirigées coupées, redirections ignorées (IPv4 et IPv6). Les redirections ICMP sont un « piège à c… » classique ; si tu veux changer les chemins, fais‑le explicitement dans le routage ou PF, pas via des détours.

ICMP avec mesure. Pas d’écho broadcast, pas de timestamp/netmask ; les paquets d’erreur ont une limite de débit raisonnable. Ça amortit le bruit DDoS sans casser les fonctions légitimes. ICMP n’est pas l’ennemi, mais a besoin de garde‑fous.

Durcissement UDP/TCP sans magie. Checksums UDP obligatoires ; tampons socket sensés évitent des pertes moches. En TCP, les fonctions modernes (window scaling, timestamps, SACK) restent actives pour la stabilité. ECN est activé ; rarement problématique et utile sous charge. Les limites de SYN cache/bucket et le rate‑limit RST absorbent les vagues de scan.

Queues, BPF et W^X. Une file d’interface plus longue réduit les pertes en rafales. Des tampons BPF plus grands sont un cadeau à ton « toi du futur » en debug. kern.wxabort=1 fait respecter W^X : un code est soit modifiable soit exécutable, jamais les deux. Les violations tuent le processus—fail‑closed, comme voulu. Le swap chiffré reste actif pour que des restes sensibles n’atterrissent jamais en clair sur disque.

Cette sélection sysctl est volontairement sobre. Elle déplace la courbe de « ça marche souvent » à « ça se comporte de façon cohérente sous stress ». Charge‑la proprement avec sysctl -f, contrôle quelques compteurs (sysctl -n net.inet6.icmp6.errppslimit, netstat -m, pfctl -s memory) et souviens‑toi : si tu modifies les budgets mbuf/cluster, ajuste éventuellement des limites PF comme set limit frags.

pf.conf : des règles que tu peux expliquer

pf t’offre des possibilités sans fin. Notre baseline prend exactement ce qu’il faut pour des standards robustes—ni plus, ni moins.

Macros, tables et étiquettes : la moitié de la bataille, c’est la structure. Définis clairement interfaces et réseaux : WAN, LAN et—dans la variante DMZ—DMZ. Ajoute des tables pour bogons, abusers, scanners et une liste de surveillance pour des endpoints DoH suspects. Ce n’est pas décoratif : avec persist, elles survivent aux reloads et, via overload, les sources bruyantes s’y ajoutent automatiquement. Des étiquettes cohérentes sur les règles t’offrent de la visibilité sans pcap massif : pfctl -vvsr ou systat pf montrent où ça bouge.

Options globales : comportement prévisible. set block-policy drop et l’optimisation « aggressive » sont des défauts conservateurs sensés. set state-policy if-bound ancre les connexions à l’interface d’entrée. On définit des limites d’états, de fragments et de src‑nodes, des timeouts adaptatifs et on active syncookies de manière adaptative—utile quand la marée monte. loginterface te donne des stats WAN ; set skip on lo0 évite l’auto‑tir.
Dans pf, IPv6 est bloqué par défaut, en phase avec sysctl, ce qui prévient « l’IPv6 à moitié ». Si tu le veux, active‑le de façon délibérée et visible.

ICMP entrant : assez ouvert pour rester en bonne santé. Sur l’interface WAN, on autorise echo et « unreachable », avec état et limite de débit. Ça aide le diagnostic (sinon, comment détecter MTU/chemin ?) tout en te protégeant des ping floods. Le reste—surtout les redirects—reste coupé.

Scrubbing : moins de fragmentation, moins de frustration. On « scrub » dans les deux sens : IDs IP aléatoires, TTL minimal conservateur, MSS plafonné à 1440 (valeur saine en pratique) et réassemblage TCP. Ça évite que des paquets fragmentés douteux encombrent les états et réduit les maux de PMTU. Du coup, l’ajustement MSS via sysctl n’est presque jamais nécessaire.

NAT : statique quand le temps réel compte ; dynamique sinon. UDP reçoit des ports statiques—de l’or pour VoIP/WebRTC, le jeu et beaucoup de protocoles temps‑réel. Le reste utilise une plage éphémère haute pour faciliter l’attribution sortante en capture et éviter les collisions. Le NAT s’applique à tout, sauf à des cibles de gestion explicitement définies—pas de chemins surprises.

Anti‑spoofing, bogons, ports nuls. antispoof veille sur toutes les interfaces pertinentes. Ce qui arrive au WAN avec source cassée est éliminé tôt. On bloque les bogons en entrée et en sortie ; du trafic, par ex. depuis 10/8 ou 127/8 vers internet, est généralement signe d’autres soucis. On nettoie aussi les ports 0 et les drapeaux TCP implausibles—rien de sorcier, mais tu t’épargnes la douleur des scanners « créatifs ».

Refus par défaut : le grand coup de balai. Après l’hygiène vient la coupe nette : block all. À partir de là, tout est exception consciente.

Entrant sur le WAN : seulement ce dont le routeur a besoin. On autorise DHCP entrant si ton upstream l’exige. Et c’est tout. Une DMZ publique atteignable depuis internet n’est pas le but de cette baseline ; pour cela, tu définirais des port‑forwards—avec parcimonie.

QUIC : HTTP/3 reste dehors. On bloque UDP 80/443 sur le WAN. QUIC s’étouffe. Pourquoi si strict ? Parce que QUIC est un tunnel pratique—y compris pour des variantes DoH et autres « tout‑en‑un flux ». Si plus tard tu as vraiment besoin d’HTTP/3 vers des cibles précises (et que tu sais pourquoi), ajoute des exceptions chirurgicales. La baseline privilégie transparence à vitesse.

Visibilité pour DoH/DoT/DoQ—avec des limites claires. DoT (853/TCP) et DoQ (784/UDP) sont bloqués en sortie et journalisés en entrée. En LAN/DMZ, nous étiquetons les connexions TLS vers des hôtes DoH connus—sans changer la politique sauf si tu choisis la variante stricte. L’idée : voir quand des clients tentent un DNS clandestin.

Accès admin au pare‑feu : serré et régulé. SSH depuis la LAN vers le pare‑feu est autorisé avec état, hygiène des drapeaux et limitation douce de débit. Les chemins de gestion en amont (p. ex. GUI d’un modem/routeur) obtiennent des passes ciblés ; des limites de taux amortissent les sprays et faux clics. Les étiquettes gardent ces chemins visibles.

Politique DNS sans résolveur local : imposer, ne pas espérer. Point central : les clients LAN (et DMZ, si présente) ne peuvent utiliser que 1.1.1.1 et éventuellement 1.0.0.1 sur le port 53/TCP+UDP. Tout le reste vers 53 est bloqué et journalisé. Ce n’est pas un « nice to have » ; c’est crucial pour la visibilité. Tu verras tout de suite les tentatives d’autres résolveurs—ou de DoH/DoT/DoQ, bloqués séparément. Tu peux remplacer par un autre résolveur externe quand tu veux ; la mécanique reste la même.

DMZ : pas de portes dérobées ni de raccourcis. Dans la variante DMZ, pas de communication intra‑DMZ, pas de retour vers la LAN, et seulement des sorties ciblées pour les services qui y vivent (web classique, soumission mail, plages UDP VoIP/WebRTC). Accéder à une GUI en amont depuis la DMZ est interdit ; ainsi un serveur compromis ne touche pas ton réseau de gestion. Le reste est bloqué—et journalisé—pour que tu trouves vite la vis manquante.

Atténuer les risques sortants : fermer les classiques. Vers l’extérieur, on bloque les suspects habituels : SMB/NetBIOS, RPC/NFS, TFTP, SNMP, RDP/VNC/WinRM et SMTP opportuniste. Chacun a sa place en interne ou sur des chemins délibérés ; sur internet, par défaut, non. Si tu as besoin d’une exception, définis‑la en conscience—avec une étiquette.

Le pare‑feu lui‑même : peut sortir, mais en restant visible. Le pare‑feu peut accéder à internet—avec états, limites et étiquettes. Tu en as besoin pour les mises à jour, paquets et la diag. N’en fais pas trop : cette machine est un routeur et un chien de garde, pas un terminal de navigation.

Anti‑rebind, LAN→DMZ et grand ménage. Entre LAN et DMZ, seuls des chemins explicites sont permis (p. ex. clients vers un service DMZ) ; le retour reste fermé. Les règles anti‑rebind évitent que des clients atteignent des cibles internes protégées via des astuces DNS au travers du pare‑feu. Ailleurs, PF dit un non clair—avec return là où une erreur immédiate aide le diagnostic.

Routeur‑seul vs. routeur+DMZ : quel profil te convient ?

Si tu veux juste raccorder un LAN à internet, routeur‑seul est idéal : compact, clair et pourtant durci. Tu obtiens anti‑spoofing, filtres bogons, posture de sortie stricte, DNS imposé vers 1.1.1.1/1.0.0.1, contrôles DoH/DoT/DoQ/QUIC, SSH admin depuis la LAN vers le pare‑feu et des défauts propres pour scrub, états et limites.

Dès que tu héberges des services—même seulement internes—routeur+DMZ a du sens. Une DMZ contient les incidents et réduit la probabilité qu’un service compromis devienne un tremplin vers ta LAN. L’intra‑DMZ reste fermé ; la sortie est en liste blanche et plus serrée qu’en LAN. Le DNS est tout aussi strict ; NTP reste fermé jusqu’à ce que tu en aies vraiment besoin.

Activer IPv6 correctement

La baseline bloque IPv6 pour qu’il n’y ait rien de « moitié ouvert ». Si tu as besoin d’IPv6, active‑le délibérément et de façon cohérente : routage via sysctl, règles inet6 pf correspondantes, un plan de sortie propre (oui, enforcement DNS ici aussi—mais pour v6), décisions claires sur RA/DHCPv6. Reflète les bonnes idées v4 : anti‑spoofing, refus par défaut, gestion QUIC/DoH/DoQ et exceptions visibles—ni plus, ni moins. Conseil clé : ne « glisse » pas v6 en douce. S’il est là, qu’il soit bien fait ; sinon, pas encore.

Exploitation, diagnostic et forensique : mesurer, ne pas deviner

Une politique stricte ne vaut que si tu peux la lire au quotidien. pf aide via trois canaux :

Étiquettes. Chaque règle pertinente porte une étiquette. Dans pfctl -vvsr, tu vois les chemins utilisés, ceux bloqués et où ça cogne. Souvent, ça suffit pour circonscrire un souci.

Tables. Avec pfctl -t <table> -T show, tu lis les entrées abusers/scanners. overload remplit ces tables automatiquement quand des clients ouvrent trop de connexions. Ce n’est pas une punition ; c’est une ceinture de sécurité.

pcap minimal. tcpdump est ton ami—utilise‑le à dessein. Pour le contrôle DNS/DoH, de brefs coups d’œil comme :
tcpdump -n -e -ttt -i $wan 'port 53 or port 853 or (udp and port 784)'
suffisent souvent. C’est de la forensique avec plan, pas du « Wireshark jusqu’aux larmes ».

Un canon de tests sain. Quand tu changes des règles, compile d’abord sans charger : pfctl -nf /etc/pf.conf. Puis pfctl -f—et si ça casse, étiquettes et tables guident la correction. Pour l’enforcement DNS : drill @1.1.1.1 openbsd.org doit réussir ; drill @9.9.9.9 openbsd.org doit être bloqué. Pour QUIC, vérifie que curl -I --http3 https://example.com ne passe pas en UDP et retombe sur HTTP/2. Valide DoT/DoQ en tentant 1.1.1.1:853 et UDP 784—ça doit échouer, et tu dois voir les compteurs sur les règles étiquetées.

Astuce pour les changements sortants. Quand tu ouvres quelque chose, marque‑le temporairement avec une étiquette explicite et regarde une semaine plus tard si c’est réellement utilisé. Si non, retire‑le. Ta baseline reste légère.

Performances sans folklore

Cet agencement n’est pas « au fil du rasoir »—il est calibré pour la stabilité. Quelques conséquences à garder :

Bloquer QUIC peut ralentir légèrement certains sites. Échange délibéré : visibilité plutôt que vitesse. Si tu as de bonnes raisons de permettre HTTP/3, fais‑le chirurgicalement (cibles en table, étiquette, terminé).

ECN activé convient à la plupart des réseaux modernes. Si une middlebox exotique n’aime pas, tu le verras vite et pourras le désactiver au cas par cas—la baseline ne se met pas en travers.

Ports NAT statiques pour UDP : un cadeau pour les protocoles temps‑réel. Quiconque a traqué des soucis WebRTC le sait : c’est précieux. Ça ne coûte rien, si ce n’est de comprendre que l’« aléatoire » de ports UDP n’est pas une fonction de sécurité.

If‑queues et tampons BPF dimensionnés avec pragmatisme : marge pour pics, sessions de debug qui ne meurent pas sur 4 KB. Si tu pousses vraiment au max, mesure et ajuste—pas l’inverse.

Pièges courants—et comment les gérer élégamment

« Mon appli ne marche qu’avec DoH ! » Alors il faut une exception ou, mieux, une évaluation honnête. DoH n’est pas mauvais en soi, mais nuit au contrôle réseau (maison/entreprise). Tu peux autoriser des hôtes précis via table ; garde‑le comme exception consciente, pas comme ouverture globale.

« Les appels vidéo saccadent. » Vérifie d’abord que les plages UDP de ton fournisseur (Zoom/Teams/WebRTC) sont couvertes. Les ports UDP statiques aident, mais sans bon corridor sortant, rien ne s’améliore. Ajuste sur mesure, pas au hasard.

« Mon client mail n’envoie pas directement. » Normal : le port 25 sortant est bloqué. Le mail doit passer par submission (465/587) vers ton fournisseur/serveur—pas directement internet. Si besoin, autorise ces ports—avec étiquette.

« IPv6 a cassé d’un coup. » Dans cette baseline, v6 est bloqué. Si des clients préfèrent v6 alors que le pare‑feu ne route pas, tu verras des timeouts. Soit tu actives v6 correctement (avec règles), soit tu informes les clients (RA/ND) que v6 n’est pas disponible.

« Comportements bizarres après une règle. » Pense aux états. Les anciens survivent par défaut. Quand tu touches la politique de fond (p. ex. nouveau port sortant), tue les états concernés (pfctl -k ...) ou, si nécessaire, vide tout (pfctl -F state). Après, le monde redevient cohérent.

Pourquoi cette baseline est « sûre »—et ce que « sécurité » veut dire ici

La sécurité n’est jamais absolue. Mais elle se mesure quand tu fixes des objectifs clairs et que tu vérifies honnêtement le chemin. Cette baseline réduit la surface d’attaque parce qu’elle :

minimise toute exposition entrante,

fait de la sortie l’exception, pas la règle,

impose et rend visible le DNS,

bloque les chemins obscurs (QUIC/DoH/DoT/DoQ),

désactive des pseudo‑fonctions (redirects, broadcasts),

applique des défauts TCP/ICMP robustes,

rend la gestion d’état déterministe,

et te fournit des outils pour observer l’usage au quotidien.

En même temps, la configuration reste maintenable. Elle n’est pas « sûre » parce qu’elle fait 3 000 lignes, mais parce que tu peux expliquer chaque ligne.

Migration : comment procéder

Si tu viens d’une config pf existante, avance par étapes :

1. sysctl d’abord. Charge le durcissement qui ne casse pas les services. Vérifie les logs pour du bruit ICMP/RST inhabituel.
2. Teste la politique pf à côté. Utilise pfctl -nf et un lab/fenêtre de maintenance. À la première activation, veille à l’SSH LAN→pare‑feu—se verrouiller dehors est douloureux.
3. Durcis la sortie. Active l’enforcement DNS et observe. Puis ferme progressivement les services risqués classiques. Une à deux semaines de monitoring aident à trouver les angles morts.
4. Introduis une DMZ (si besoin). Déplace des services, garde fermés intra‑DMZ et DMZ→LAN. N’ouvre que les sorties strictement nécessaires. Observe et affine.
5. Décide IPv6 en conscience. Soit tu l’actives proprement, soit tu le laisses coupé et tu informes les clients.

Chaque palier renforce la sécurité sans « big bang » risqué.

Ce que tu peux étendre facilement ensuite

Cette baseline est un socle, pas une cage. Extensions typiques :

• Exceptions chirurgicales pour QUIC/DoH quand tu as de bonnes raisons—toujours via tables et étiquettes.
• VPN site‑à‑site avec surface d’attaque minimale ; les sysctl par défaut ne te bloquent pas si tu autorises explicitement les protocoles.
• Monitoring/alerting. Les compteurs pf et systat pf suffisent pour des métriques de base. Pour plus, envoie les logs pf vers un système central.
• IPv6, en miroir complet de la logique v4—pas comme greffe.

Mises à jour et maintenance

OpenBSD tient ses promesses—mais lis les notes de version à chaque mise à jour, surtout côté syntaxe pf et défauts du noyau. Étiquettes, tables et macros claires accélèrent la validation inter‑versions. Garde la discipline de commenter chaque exception : pourquoi elle existe, qui en a besoin, quand tu l’as revue. Les exceptions ne sont pas un péché ; non documentées, elles deviennent de la dette technique.

Conclusion : la clarté est le meilleur durcissement

Cette baseline vise un objectif simple : la clarté avant la complexité. Tu obtiens un pare‑feu OpenBSD prévisible au quotidien, avec une surface d’attaque réduite, qui te montre—grâce aux étiquettes, tables et défauts sensés—ce qui se passe réellement. Nous privilégions des choix explicites plutôt que des effets secondaires implicites : politique sortante stricte, DNS imposé vers des résolveurs définis, pas de canaux silencieux via QUIC ou DoH/DoT/DoQ, états déterministes et leviers noyau robustes. Le résultat n’est pas une pièce académique, mais un point de départ durable sur lequel construire sereinement.

Il est important de noter que cette baseline présuppose intentionnellement pas de résolveur local et pas de service NTP local. Elle cible des contextes qui doivent se stabiliser vite, sans infrastructure additionnelle. Si plus tard tu veux plus de contrôle on‑prem, tu pourras l’ajouter sans friction—l’architecture est prête, sans renier la posture centrale.

Pour t’éviter de chercher : tu trouveras ci‑dessous les propositions de configuration complètes—les deux profils pf.conf (routeur‑seul sans DMZ et routeur+DMZ avec isolement strict) ainsi que la sysctl.conf durcie. Cet article explique les décisions ; les fichiers ci‑dessous les appliquent à la lettre. Si tu suis la séquence « valider → charger → mesurer », tu obtiendras rapidement un résultat reproductible.

Autre point : soyons honnêtes sur le périmètre. Ici, ne sont pas au centre des attaques hautement ciblées ni des scénarios IDS/IPS complets. Cela ne signifie pas s’en priver—au contraire. Ce socle est conçu pour que tu puisses les ajouter méthodiquement. Trois pistes d’extension se sont révélées utiles en pratique.

Si tu as des idées pour affiner des règles spécifiques, des besoins particuliers ou des retours d’exploitation à partager : contacte‑nous. Le feedback réel est le meilleur catalyseur d’améliorations pertinentes—et nourrira de futures évolutions. La sécurité est un processus, pas un sprint ; avec une baseline claire et une communauté qui partage son expérience, le « bien » devient vite « excellent ».

Télécharger sysctl.conf: https://www.protectstar.com/download/blog/sysctl.txt
Télécharger pf.conf (avec DMZ): https://www.protectstar.com/download/blog/pf.conf_withDMZ.txt
Télécharger pf.conf (sans DMZ): https://www.protectstar.com/download/blog/pf.conf_noDMZ.txt