---
date: 2020-11-23T12:00:01+01:00
description: "Traduction du 'Guide du Routeur OpenBSD' du site unixsheikh.com"
draft: false
tags: ['Traduction','OpenBSD','Guide','Routeur']
title: "Guide du Routeur OpenBSD"
---
# Guide du Routeur OpenBSD
Pare-feu segmentant un réseau, avec DHCP, DNS (Unbound), blocage de domaine
et bien plus encore.
* OpenBSD: 6.9 · Publié : 2020-11-05 · Mis-à-jour : 2021-07-21 · Version : 1.9.4
## Introduction
Dans ce guide, nous verrons comment nous pouvons utiliser du matériel
"bas de gamme" bon marché pour construire un routeur OpenBSD terrible
avec des capacités de pare-feu, des réseaux locaux segmentés, du DNS
avec blocage de noms de domaines, du DHCP et bien plus.
Nous commencerons par paramétrer les segments réseaux (LAN) par trois
réseaux séparés, un pour les adultes à la maison, un pour les enfants
et un pour les serveurs face à Internet (comme une [DMZ](https://fr.wikipedia.org/wiki/Zone_d%C3%A9militaris%C3%A9e_(informatique))),
tel qu'un serveur web ou serveur mail privé.
Nous chercherons à voir comment nous pouvons utiliser DNS pour bloquer
les publicités, le porno, et d'autres sites sur Internet. Le routeur OpenBSD
peut aussi être utilisé dans de petites ou moyennes entreprises.
## Conventions typographiques utilisées dans ce guide
- La police à `largeur fixe` (mono-espacement) est utilisée pour les commandes
en console, les noms de fichiers et leurs chemins, les paramètres de
configuration, etc…
- Les commandes en console qui doivent être tapées en tant qu'utilisateur
`root` sont préfixées du symbole dièse `#` et la commande apparaît en
**gras** dans le texte.
- Les commandes en console qui doivent être tapées en tant qu'utilisateur
normal sont préfixées du symbole dollar `$` et la commande apparaît en
**gras** dans le texte.
## Pourquoi un pare-feu ?
{{< note info >}}
Actuellement ce guide aborde IPv4, car la plupart des personnes
n'utilisent pas IPv6 et beaucoup de FAI - *Fournisseur d'Accès à Internet* -
utilisent seulement IPv4, mais IPv6 est planifié dans le contexte d'une
future mise à jour de ce guide.
{{}}
Peu importe comment vous vous connectez à Internet depuis votre domicile
ou votre bureau, vous avez besoin d'un vrai pare-feu entre vous et le modem
ou routeur que vous fourni votre FAI.
Il est très rare que les modems ou routeurs grand public reçoivent des
mises à jour du micrologiciel et sont souvent vulnérables aux attaques
réseau qui transforment ces appareils en [Botnet](https://fr.wikipedia.org/wiki/Botnet),
tel que le fait le [logiciel malveillant Mirai](https://fr.wikipedia.org/wiki/Mirai_(logiciel_malveillant)).
De nombreux modems et routeurs grand public sont à blâmer à propos de
certaines [attaques par déni de service de grande envergure (DOS)](https://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service)
Un pare-feu entre vous et le modem ou routeur de votre FAI ne peut pas
protéger votre dispositif modem ou routeur contre de telles attaques,
mais il peut protéger vos ordinateurs et dispositifs à l'intérieur du
réseau, et il peut vous aider à surveiller et contrôler le trafic qui
arrive vers votre réseau local et qui en part.
Sans un pare-feu entre votre réseau local et le modem ou routeur du FAI,
vous pouvez considérer basiquement que votre porte est grande ouverte,
comme laisser grande ouverte la porte de votre maison, ainsi vous ne pouvez
pas faire confiance en l'équipement de votre FAI.
C'est toujours réellement une bonne idée de mettre un vrai pare-feu entre
votre réseau local et Internet, et avec OpenBSD vous avez une solution très
solide.
## Le Matériel
Vous n'avez pas besoin d'acheter du matériel cher pour avoir un routeur
et un pare-feu efficaces pour votre maison ou votre bureau.
Même avec du matériel "bas de gamme" bon marché, vous pouvez avoir une
solution très solide.
J'ai créé de multiples solutions avec la carte-mère
[ASRock Q1900DC-ITX](https://www.asrock.com/mb/Intel/Q1900DC-ITX/) qui est
fournie avec un processeur Intel Celeron Quadri-Cœur.
{{< img a="ASRock Q1900DC-ITX" s="unixsheikh.com/asrock-q1900dc-itx.png" >}}
Je l'admet, c'est une carte-mère assez "pourrie", mais elle fait le boulot
et j'ai de nombreuses solutions très solides qui fonctionnent depuis de
nombreuses années sur des réseaux Gigabit avec saturation complète et le
pare-feu, DNS, faisant des "heures supplémentaires" et où le CPU ne chauffe
pas.
La carte-mère ASRock Q1900DC-ITX a pour avantage qu'elle est fournie
avec une prise jack DC-In (entrée électrique) qui est compatible avec
un adaptateur électrique 9-19V, ce qui la rend très économe en énergie.
Malheureusement, la carte-mère ASRock Q1900DC-ITX n'est plus fabriquée,
mais comme je l'utilise juste comme exemple ;
j'ai utilisé de nombreuses autres carte-mères bon marché tout aussi bien.
{{< note info >}}
Beaucoup d'autres carte-mères faites par d'autres fabricants
consommant peu peuvent être aussi bien utilisées, tel le fameux [APU2](https://www.pcengines.ch/apu2.htm).
{{}}
J'ai aussi utilisé l'ASRock Q1900-ITX (qui est fournie sans la prise jack
DC-In) combinée à un PicoPSU.
{{< img a="PicoPSU" s="/unixsheikh.com/picopsu.png" >}}
Vous pouvez trouvez différentes marques et version du PicoPSU, certains
sont de meilleurs qualités que d'autres. J'ai deux marques différentes,
l'original et une copie moins chère, toutes deux sont très performants et
permettent d'économiser par mal d'énergie contrairement à une alimentation
normale.
Enfin, j'utilise une carte réseau quadruple port Intel bon marché, trouvé
sur Ebay, tel que celle-ci :
{{< img a="Quad NIC Intel" s="/unixsheikh.com/intel-quad-nic.png" >}}
Je sais, il est préférable d'utiliser du matériel de qualité, spécifiquement
sur un réseau dont vous avez à prendre soin, mais ce tutoriel est relatif
au fait de comment vous pouvez vous en sortir en utilisant du matériel
bon marché tout en ayant un produit extrêmement utile qui continue à bien
vous servir pendant de nombreuses années - du moins, telle est mon expérience.
Je vous recommande de chercher une carte mini-ITX dont le matériel est
[pris en charge par OpenBSD](https://www.openbsd.org/amd64.html), tel qu'un
CPU Intel Celeron ou Intel i3. Ces cartes-mères sont typiquement peu chères,
peu gourmandes d'énergie, et ne prennent pas beaucoup de place.
Je ne recommande pas l'utilisation d'un CPU Intel Atom si vous avez un réseau
Gigabit, car il ne peut pas gérer la quantité de trafic.
Vous pourriez également avoir besoin de quelques commutateurs Gigabit
bon marché pour segmenter votre réseau local, au moins si vous avez plus
d'un ordinateur connecté sur le même LAN :)
## Pourquoi OpenBSD ?
En vérité, vous pouvez avoir le même paramétrage avec une autre saveur
BSD ou une des différentes [distributions Linux](https://fr.wikipedia.org/wiki/Distribution_Linux),
mais [OpenBSD](https://www.openbsd.org/) est spécifiquement très bien
adapté et conçu pour ce genre de tâche.
Non seulement il est livré avec tous les logiciels nécessaires dans
l'installation de base, mais il offre également une sécurité nettement
supérieure, et des tonnes de mesure d'atténuation améliorées déjà intégrées
dans le système d'exploitation.
Je [recommande chaudement](https://www.unixsheikh.com/articles/openbsd-is-fantastic.html)
OpenBSD plutôt que tout autre système d'exploitation pour ce genre de
tâches.
Ce guide ne vous montre pas comment installer OpenBSD.
Si vous ne savez pas faire, je vous recommande de faire fonctionner une
machine virtuelle avant ou de voir si vous avez du matériel inutilisé et
pris en charge avec lequel vous pourriez tester.
OpenBSD est un des systèmes d'exploitations des plus faciles et rapides à
installer.
N'ayez pas peur de l'approche sans GUI (interface utilisateur) ; une fois
que vous l'avez essayé, vous apprécierez vraiment sa simplicité.
Dans le doute, utilisez les paramètres par défaut.
Avant de commencer ce voyage, assurez-vous de consulter la documentation
d'OpenBSD !
Non seulement, chaque chose est très bien documentée, mais vous trouverez
très probablement toutes les réponses dont vous avez besoin.
Lisez la [FAQ OpenBSD](https://www.openbsd.org/faq/index.html),
regardez les différentes [pages de manuels](https://man.openbsd.org/) à
propos des différents logiciels que nous allons utiliser.
Un autre endroit vraiment utile où trouver des informations générales à
propos d'OpenBSD sont les [archives des listes de diffusions d'OpenBSD](https://marc.info/?l=openbsd-misc).
Aussi assurez-vous de rester à jour des informations pertinentes en
souscrivant à la liste de diffusion des [Annonces et avis de sécurité](https://www.openbsd.org/mail.html).
{{< note tip >}}
Veuillez considérer de [soutenir OpenBSD](https://www.openbsd.org/donations.html) !
Même si vous n'utilisez pas quotidiennement OpenBSD, vous
utilisez peut-être déjà [OpenSSH](https://www.openssh.com/) sur Linux,
alors vous utilisez vraiment un logiciel du projet OpenBSD.
Considérez de faire un petit, mais régulier, don pour soutenir le développement
de tous les excellents logiciels que les développeurs d'OpenBSD font.
{{}}
## Le réseau
Un routeur est basiquement un dispositif qui régule le trafic réseau entre
deux ou plusieurs réseaux séparés.
Le routeur garantira que le trafic réseau à destination du réseau local
ne circule pas sur Internet, et que le trafic sur Internet, qui n'est pas
à destination de votre réseau local, reste sur Internet.
{{< note info >}}
Un routeur est parfois aussi appelé passerelle, ce qui est généralement
le terme, mais en vérité une véritable passerelle joint des systèmes
différents, alors qu'un routeur joint des réseaux similaires.
Un exemple de passerelle serait un dispositif qui joint un réseau PC avec
un réseau télécom.
{{}}
Dans ce tutoriel, nous construirons un routeur et nous avons 4 réseaux
de même type à faire travailler ensemble.
L'un est Internet, et les trois autres sont segmentés intentionnellement
en réseaux locaux (LAN).
Certaines personnes préfèrent travailler avec des LAN virtuels (VLAN),
mais dans ce tutoriel nous utiliserons une interface réseau 4 ports,
telle que vue sur l'illustration ci-dessus.
Vous pouvez arriver au même résultat en utilisant de multiples cartes réseau
à port unique, si vous préférez ; vous devez juste vous assurez d'avoir
assez de place et de slot PCI libre sur la carte-mère.
Vous pouvez aussi utiliser le port Ethernet de la carte-mère, mais cela
dépend du pilote et de la prise en charge du dispositif.
Je n'ai pas de problème à utiliser un contrôleur Ethernet Gigabit PCI Realtek
qui est fourni avec beaucoup de carte-mères, bien que je recommande plutôt Intel.
Bien sûr, vous n'avez pas à segmenter le réseau en de nombreuses parties
si vous n'avez pas besoin de cela, et il serait très facile de changer les
paramètres de ce guide, mais j'ai décidé d'utiliser cette approche avant
de vous montrer comment vous pouvez protéger vos enfants en segmentant
leur réseau dans un LAN séparé qui permet non seulement de bloquer la
publicité et la pornographie grâce au blocage des DNS (tous les segments
en bénéficient), mais vous pouvez même mettre sur une liste blanche les
partie de l'Internet auxquelles vous voulez qu'ils aient accès.
La dernière partie à propos des listes blanches est difficile et n'est
généralement pas recommandé à moins que vos enfants aient besoin d'un
accès très limité, mais c'est faisable avec un peu de travail, et le guide
va vous montrer une façon de faire.
Ceci est une illustration du réseau que nous allons paramétrer :
Internet
|
xxx.xxx.xxx.xxx
Modem FAI (WAN)
10.24.0.23
|
OpenBSD
10.24.0.50
(routeur/parefeu)
|
┌────────────────────+────────────────────┐
| | |
NIC1 NIC2 NIC3 (DMZ)
192.168.1.1 192.168.2.1 192.168.3.1
LAN1 switch LAN2 switch LAN3 switch
| | |
└─ 192.168.1.x ├─ 192.168.2.x └─ 192.168.3.2
PC Adultes | PC1 Enfant Public web server
|
└─ 192.168.2.x
PC2 Enfant
Les adresses IP qui commencent par 10.24.0 sont n'importe quelle adresse
IP que le routeur ou modem de votre FAI vous donne ; elles peuvent être
très différentes. Les adresses IP commençant par 192.168 sont les adresses
IP que nous allons utiliser dans ce guide pour notre réseau local (LAN).
Ce guide ne s'occupe en aucun cas de connectivité Wifi.
Les micrologiciels des puces sans fil sont notoirement bogués et exploitables ;
je vous recommande de n'utiliser aucun type de connectivité sans fil, si
vous pouvez vous en passer.
Si vous avez besoin de la connectivité sans fil, je recommande chaudement
que vous désactiviez l'accès Wifi du modem ou routeur du FAI (si possible),
et ensuite d'acheter le meilleur routeur Wifi que vous pouvez trouver puis
de le mettre derrière le pare-feu dans un segment isolé.
Ainsi, si jamais votre appareil sans fil est compromis, vous pourrez mieux
contrôler le résultat et limiter les dégâts.
Vous pouvez en outre configurer le routeur sans fil de telle sorte que
tout appareil, qui y est connecté, dispose de ses propres adresses IP
qui passent directement par le routeur sans fil, tout en bloquant le
trafic provenant du routeur sans fil lui-même.
De cette façon, vous pouvez empêcher le routeur sans fil de "téléphoner à la maison".
Vous pouvez aussi avoir un adaptateur Wifi supporté par OpenBSD et que
votre routeur OpenBSD agisse en tant que point d'accès, toutefois je préfère
de beaucoup segmenter la partie Wifi soit par un routeur sans fil séparé,
soit par une autre machine OpenBSD servant de point d'accès Wifi derrière
le pare-feu lui-même.
{{< note info >}}
Actuellement, autant que je le sache, aucun des pilotes Wifi d'
OpenBSD ne posent pas encore de problèmes.
{{}}
### Paramétrer le réseau
La première chose que nous allons paramétrer sont les différentes interfaces
réseaux de notre routeur OpenBSD.
Sur ma machine, j'ai désactivé l'interface réseau qui est livré avec la
carte-mère via le BIOS, et je n'utilise que l'interface réseau 4 ports d'Intel.
Si vous suivez ce tutoriel et que vous souhaitez seulement un pare-feu
basique alors vous avez au moins besoin de deux interfaces réseaux séparées.
Avant de commencer, assurez-vous de lire et de comprendre les différentes
options de la page de manuel [hostname.if](https://man.openbsd.org/hostname.if).
Prenez aussi le temps de lire la section réseau de la [FAQ d'OpenBSD](https://www.openbsd.org/faq/faq6.html).
Puisque j'utilise Intel, le pilote [em](https://man.openbsd.org/em) est
celui qu'OpenBSD charge sur chacun des ports de cette interface réseau,
qui sont listés comme étant des cartes séparées.
Cela signifie que chaque carte est listée en tant qu'`emX` où X est le
numéro actuel du port de la carte.
`dmesg` liste ma carte réseau avec 4 ports de telle manière :
```
# dmesg
em0 at pci2 dev 0 function 0 "Intel I350" rev 0x01: msi, address a0:36:9f:a1:66:b8
em1 at pci2 dev 0 function 1 "Intel I350" rev 0x01: msi, address a0:36:9f:a1:66:b9
em2 at pci2 dev 0 function 2 "Intel I350" rev 0x01: msi, address a0:36:9f:a1:66:ba
em3 at pci2 dev 0 function 3 "Intel I350" rev 0x01: msi, address a0:36:9f:a1:66:bb
```
Ce qui montre que ma carte est reconnu comme étant une Intel I350-T4 PCI Express Quad Port Gigabit NIC.
Il faut ensuite déterminer quel est le port correspondant physiquement au
numéro indiqué ci-dessus.
Vous pouvez le faire en connectant manuellement un câble Ethernet, connecté
sur un commutateur actif, un modem ou un routeur, sur chacun des ports,
un à la fois, afin de voir quel port est activé et le noter ensuite quelque part.
Vous pouvez vérifier le statuts d'activité avec la commande `ifconfig`.
Un port sans câble Ethernet sera listé comme ayant le champ `status` notifié
`no carrier` alors qu'un port avec un câble attaché sera listé en `active`.
Tel que :
```
# ifconfig
em1: flags=8843 mtu 1500
lladdr a0:36:9f:a1:66:b9
index 2 priority 0 llprio 3
media: Ethernet autoselect (none)
status: active
em2: flags=8843 mtu 1500
lladdr a0:36:9f:a1:66:ba
index 3 priority 0 llprio 3
media: Ethernet autoselect (none)
status: no carrier
```
Nous allons utiliser le port `em0` afin de le connecter au modem ou routeur
de votre FAI, vers Internet.
Dans mon cas, j'ai une adresse IP publique fournie par mon FAI ; vous en
aurez besoin si vous voulez faire fonctionner un serveur web depuis votre
maison, mais si ce n'est pas le cas, vous n'en avez pas besoin, ainsi vous
pouvez paramétrer la carte par DHCP.
Dans mon cas, j'ai besoin de spécifier une adresse IP fixe pour `em0` qui
recevra alors le trafic redirigé depuis mon FAI vers mon adresse IP publique.
Pour faire cela, je paramètre `em0` avec l'information suivante :
```
# echo 'inet 10.24.0.50 255.255.254.0 NONE' > /etc/hostname.em0
```
Si vous n'avez pas besoin d'une adresse IP publique et que votre adresse
IP est obtenue par votre FAI via DHCP, alors écrivez juste `dhcp` à la place :
```
# echo 'dhcp' > /etc/hostname.em0
```
Ensuite, je paramètre le reste des ports de l'interface réseau avec leurs
adresses IP, tel que je l'ai précédemment illustré.
```
# echo 'inet 192.168.1.1 255.255.254.0 NONE' > /etc/hostname.em1
# echo 'inet 192.168.2.1 255.255.254.0 NONE' > /etc/hostname.em2
# echo 'inet 192.168.3.1 255.255.254.0 NONE' > /etc/hostname.em3
```
Regardez la page du manuel [hostname.if](https://man.openbsd.org/hostname.if)
pour avoir plus d'informations.
Ensuite, j'ai besoin de paramétrer l'IP de la passerelle du FAI.
Selon le paramétrage de votre FAI, cela peut être une autre adresse IP que
celle du modem ou routeur du FAI.
Si vous n'ajoutez pas le fichier `/etc/mygate` alors aucune passerelle par
défaut ne sera ajouté à la [table de routage](https://fr.wikipedia.org/wiki/Table_de_routage).
Vous n'avez pas besoin de `/etc/mygate` si votre IP est fournie par le
modem ou routeur de votre FAI via DHCP.
Si vous utilisez la directive `dhcp` dans n'importe quel fichier `hostname.ifX`
alors l'entrée dans le fichier `/etc/mygate` sera ignorée.
Cela est parce que la carte obtient son adresse IP depuis un serveur DHCP
qui fournira aussi l'information de routage vers la passerelle.
Enfin, mais pas des moindres, nous avons besoin d'activer la redirection IP.
La redirection IP est le processus qui dirige les paquets IP qui voyagent
entre les interfaces réseaux du routeur.
Par défaut, OpenBSD ne fera pas de redirection des paquets IP entre les
différentes interfaces réseaux.
En d'autres mots, les fonctions de routage (appelées aussi fonctions de
passerelles) sont désactivées.
Nous pouvons activer la redirection d'IP en utilisant les commandes suivantes :
```
# sysctl net.inet.ip.forwarding=1
# echo 'net.inet.ip.forwarding=1' >> /etc/sysctl.conf
```
Maintenant OpenBSD sera capable de rediriger les paquets IPv4 depuis une
interface réseau vers une autre.
Ou, tel dans notre cas avec les 4 ports, d'un port à l'autre.
Regardez la page du manuel si vous avez besoin d'IPv6.
## DHCP
Maintenant nous sommes prêts à paramétrer le service [DHCP](https://fr.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol)
que nous exécuterons pour nos différents PC et dispositifs attachés aux
différents LAN.
Avant, assurons-nous de lire et de comprendre les différentes options de
la page du manuel [dhcp.conf](https://man.openbsd.org/dhcpd.conf).
Prenons aussi le temps de regarder la page de manuel [dhcp-options](https://man.openbsd.org/dhcp-options)
à propos des options que prend en charge dhcpd.
Nous avons une option pour cacher des adresses IP à de PC ou dispositifs
spécifiques qui se connectent sur nos différents ports.
Cela est nécessaire si nous voulons rediriger le trafic qui vient d'Internet
vers quelque chose comme un serveur web.
Nous pouvons cacher une adresse IP spécifique vers un PC spécifique via
l'adresse [MAC](https://en.wikipedia.org/wiki/MAC_address) de l'interface
réseau de la machine concernée.
Dans ce cas, je réserverais toutes les adresses IP dans un ensemble allant
de 10 à 254 pour le DHCP, tandis que je laisserais les autres qui restent
pour les éventuelles adresses fixes dont je pourrais avoir besoin.
Éditer le fichier `/etc/dhcpd.conf` avec votre éditeur de texte favori et
adapter le à vos besoins.
```
subnet 192.168.1.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.1.1;
option routers 192.168.1.1;
range 192.168.1.10 192.168.1.254;
}
subnet 192.168.2.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.2.1;
option routers 192.168.2.1;
range 192.168.2.10 192.168.2.254;
}
subnet 192.168.3.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.3.1;
option routers 192.168.3.1;
range 192.168.3.10 192.168.3.254;
host web.example.com {
fixed-address 191.168.3.2;
hardware ethernet 61:20:42:39:61:AF;
option host-name "webserver";
}
}
```
La ligne `option domain-name-servers` spécifie le serveur DNS que nous allons
faire fonctionner sur notre routeur.
De plus l'ordinateur qui est notre serveur web sur le LAN publique
a une adresse IP fixe et un nom d'hôte fixé.
De même, si vous ne voulez pas segmenter le réseau en différentes parties,
mais que vous avez seulement besoin d'un LAN alors vous pouvez juste laisser
de côté les autres sous-réseaux pour avoir juste cela :
```
subnet 192.168.1.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.1.1;
option routers 192.168.1.1;
range 192.168.1.10 192.168.1.254;
}
```
Ensuite, nous avons simplement besoin de nous assurer d'activer et de démarrer
le service `dhcpd` :
```
# rcctl enable dhcpd
# rcctl start dhcpd
```
{{< note info >}}
Regardez le chapitre {{< anchor "Ajouter l'option domain-name à DHCP et utiliser un FQDN" "Ajouter l'option domain-name à DHCP et utiliser un FQDN" >}} dans
l'appendice pour savoir comment ajouter facilement un [nom de domaine pleinement qualifié (FQDN)](https://fr.wikipedia.org/wiki/Fully_qualified_domain_name)
à votre paramétrage et comment vous pouvez utiliser l'option `domain-name`
dans DHCP afin d'éviter à avoir à écrire le FQDN à chaque fois que vous
en avez besoin.
Ce chapitre vous montrera aussi comment vous pouvez éviter d'avoir à vous
souvenir des adresses IP si votre LAN a de multiples ordinateurs ou
dispositifs connectés.
{{}}
## PF - un pare-feu filtrant
Un pare-feu filtrant examine chaque paquet qui croise le pare-feu et décide
quel paquet accepter ou refuser, selon l'examen des champs dans l'IP et
les entêtes de protocole du paquet, et selon l'ensemble des règles que
vous spécifiez.
Le filtrage de paquets fonctionne par inspection des adresses IP et du
port source et de destination contenus dans chaque paquet du protocole
TCP/IP (Transmission Control Protocol / Internet Protocol).
Les ports TCP/IP sont des numéros assignés à des services spécifiques
qui identifie pour quel service chaque paquet est destiné.
Une faiblesse commune des pare-feux simples à filtrage de paquets est que
le pare-feu examine chaque paquet de manière isolée sans tenir compte des
paquets qui ont déjà traversé le pare-feu et de ceux qui pourraient le
suivre.
Ils sont appelés pare-feu "sans état".
Exploiter un filtrage de paquets sans état est assez facile.
PF d'OpenBSD **n'est pas** un pare-feu sans états, c'est un
[pare-feu à états](https://fr.wikipedia.org/wiki/Pare-feu_%C3%A0_%C3%A9tats).
Un pare-feu à états garde trace des connexions ouvertes et permet seulement
le trafic correspondant à une connexion existante ou ouvre une nouvelle
connexion permise.
Quand l'état est spécifié par une règle correspondante, le pare-feu génère
dynamiquement des règles internes pour que chaque paquet anticipé puisse
être échangé durant la session.
Il a suffisamment de capacité de correspondance pour déterminer si un paquet
est valide pour une session.
Tout paquet qui ne correspond pas au modèle de session sera automatiquement
rejeté.
Un des avantages du filtrage à états est que c'est très rapide.
Il vous permet de vous focaliser sur le fait de bloquer ou laisser passer
de nouvelles sessions.
Si une nouvelle session est passée, tous les paquets conséquents sont
automatiquement alloués et tout paquet imposteur sera automatiquement
rejeté.
Si une nouvelle session est bloquée, aucun des paquets conséquents n'est
autorisé.
Le filtrage à états fournit aussi des capacités avancées de correspondance
capables de se défendre contre le flood de différentes méthodes d'attaques
employées par des attaquants.
La Traduction d'Adresse Réseau (NAT) permet à un réseau privé derrière le
pare-feu de partager une adresse IP publique unique.
La NAT permet à chaque ordinateur du réseau privé d'avoir un accès à Internet,
sans avoir besoin de comptes multiples à Internet, ou de multiples adresses
IP publiques.
La NAT traduira automatiquement l'adresse IP du réseau privé pour les
ordinateurs et dispositifs sur le réseau vers l'unique adresse IP publique
lorsque les paquets sortent du pare-feu vers Internet.
La NAT assume aussi la traduction inverse pour les paquets de retour.
Avec la NAT, vous pouvez rediriger un trafic spécifique, couramment déterminé
par un numéro de port ou un ensemble de numéros de port, entrant depuis
votre adresse IP publique depuis Internet vers le ou les serveurs spécifiques
localisés quelque part dans votre réseau local.
[PF - Packet Filter](https://man.openbsd.org/pf) est le système de pare-feu
d'OpenBSD pour le filtrage du trafic TCP/IP et faisant de la NAT.
PF est aussi capable de normaliser ou conditionner le trafic TCP/IP, aussi
bien que gérer le contrôle de la bande passante ou la priorisation de paquets.
PF est activement maintenu et développé par l'entière équipe d'OpenBSD.
### Paramétrage de PF
Avant que nous commencions, je présume que vous avez lu à la fois et le
[Guide de l'Utilisateur de PF](https://www.openbsd.org/faq/pf/index.html)
et la page du manuel [pf.conf](https://man.openbsd.org/pf.conf), spécifiquement
la page du manuel qui est très importante.
Même si vous ne comprenez pas toutes les différentes options, assurez-vous
de lire la documentation !
Lisez la page du manuel [pf](https://man.openbsd.org/pf) pour avoir une
complète compréhension en profondeur de ce que PF peut faire.
De plus, laissez-moi commencer par vous dire que même si la syntaxe de PF
est très lisible, il est **très facile** de faire des erreurs lors de l'écriture
des règles de pare-feu.
Même des seniors et des administrateurs systèmes expérimentés font des
erreurs lors de l'écriture des règles de pare-feu.
Écrire des règles de pare-feu requiert que vous ayez planifié vos buts
avec attention, compris comment implémenter les différentes règles avant
d'obtenir le résultat attendu, et en même temps de prendre vos précautions
afin de vous éviter de vous tromper et de vous déconnecter accidentellement :)
Je pense que nous l'avons tous fait à un moment ou l'autre, que ce soit
dans la précipitation, la fatigue ou simplement par erreur.
J'ai vécu cela de nombreuses fois.
{{< note info >}}
Veuillez noter que j'ai fait de mon mieux pour garder les choses simples
autant que possible et que j'utilise autant de commentaires afin d'expliquer
ce que fait chaque règle. En même temps, j'ai testé chaque règle et surveillé
l'impact et fait de mon mieux pour éviter les complications et erreurs.
{{}}
La partie la plus importante est de ne pas faire de suppositions.
Testez toujours vos règles de manière approfondie.
Si quelque chose ne fonctionne pas, essayez de supprimer autant de règles
que possible pour ne garder que le strict minimum. Puis introduisez une
règle à la fois jusqu'à trouver la règle qui pose problème.
Enfin, continuez avec le paramétrage étape par étape.
La partie réellement difficile est de se souvenir de comment les paquets
arrivent sur une interface, comment ils sont rediriger vers une machine
sur une autre interface, et de relier correctement ce "voyage" aux termes
**pass in**, **pass out**, **block in**, **block out**, **from** et **to**.
Souvent, ces termes ne fonctionnent pas exactement comme nous avons tendance
à le penser.
### Éclaircissements
Je tiens à démarrer en clarifiant certains des paramètres communs par défaut
et des mots clés dans PF.
Quand nous parlons du traffic **pass in** ou **pass out**, une bonne manière
de se rappeler ce dont il s'agit est de penser en terme de paquets de données.
Nous utilisons **pass in** pour les paquets de données entrants qui viennent
d'ordinateurs vers une interface réseau (les ordinateurs étant rattachés
à ce périphérique réseau) et **pass out** pour les paquets de données venant
de l'interface réseau vers les ordinateurs.
Le format est soit que nous filtrons les paquets de données sur la destination :
```
from source IP to destination IP [on] port
```
Soit que nous filtrons les paquets de données sur la source :
```
from source IP [on] port to destination
```
Veuillez noter que la partie `[on]` n'est pas une partie de la syntaxe.
* `quick`
* Si un paquet correspond à une règle `pass`, `block` ou `match` avec
le critère `quick`, le paquet **est passé sans inspection des règles de
filtrage conséquentes**.
La règle avec le critère `quick` devient la dernière règle correspondante.
* `keep state`
* Vous n'avez pas besoin de spécifier le critère `keep state` pour des
règles spécifiques `pass` ou `block`.
La première fois où un paquet correspond à une règle `pass` ou `block`,
**un état d'entrée est créé par défaut**.
Seulement si aucune règle ne correspond au paquet, l'action par défaut
est **de passer le paquet sans créer d'état**.
* `on` interface/`any`
* Cette règle s'applique seulement aux paquets **qui sont entrants**,
ou **qui passent au-travers** de cette interface en particulier ou d'un
groupe d'interface.
Le critère `on any` correspondra à toute interface existante, exceptée
celles de bouclage loopback.
* `inet`/`inet6`
* Les critères `inet` et `inet6` signifie que cette règle s'applique
seulement aux paquets **entrants**, ou **passant au-travers** ce domaine
particulier de routage, soit IPv4, soit IPv6.
Vous pouvez appliquer des règles pour des domaines particuliers de routage
sans spécifier l'interface réseau. Dans de ce cas, la règle correspondra
à tout trafic de toute nature sur toutes les interfaces réseaux. En
spécifiant `inet`, vous adressez explicitement le trafic IPv4 seulement.
* `proto`
* Se limiter à un protocole est faisable en utilisant le critère `proto`.
Une règle s'applique **seulement aux paquets de ce protocole**, les autres
protocoles ne sont pas affectés. Vous pouvez chercher les protocoles
dans le fichier `/etc/protocols`. Les protocoles communs sont [ICMP](https://fr.wikipedia.org/wiki/Internet_Control_Message_Protocol)
[TCP](https://fr.wikipedia.org/wiki/Transmission_Control_Protocol) et
[UDP](https://fr.wikipedia.org/wiki/User_Datagram_Protocol).
* `in` et `out`
* C'est l'une des parties les plus faciles où se tromper : la direction
du trafic. Un paquet **entre** ou **sort** toujours par le port sur
l'interface Ethernet. `in` et `out` s'applique aux paquets entrants
et sortants au-travers du port Ethernet physique auquel est attaché
le câble Ethernet. **Si rien n'est spécifié, la règle correspondra
aux paquets dans les deux directions**.
`in` et `out` ne sont **jamais** utilisé pour gérer le trafic venant
d' une interface réseau vers une autre, ce qui est fait par la NAT, en
utilisant les options `nat-to` et `rdr-to`. `in` et `out` gèrent
seulement le trafic **entrant** et **sortant** du port Ethernet physique
d'une même carte.
* `from` et `to`
* Les critères `from` et `to` s'appliquent **seulement aux paquets avec
une adresse et des ports source et destination spécifiés**.
Des deux, du nom d'hôte ou de l'adresse IP, ou du port, voire les
spécifications OS sont optionnels.
Quand nous avons affaire avec un routeur ayant de multiples interfaces
réseaux, il est facile de penser cela :
*Je veux passer les paquets entrants depuis l'interface externe
(l'interface réseau attachée à Internet) puis qu'ils aillent sur la
première interface LAN et de là vers un PC spécifique sur le LAN*
signifiant que nous suivront le "chemin des données" dans notre esprit,
et alors nous écrivons quelque chose comme cela :
`pass in on $ext_if from $ext_if to $dmz port 80`.
Mais cela ne fait pas apparaître "par magie" le trafic HTTP sur le port 80
au PC ayant l'adresse IP spécifique sur le LAN. Il nous faudrait aussi une
règle `pass out` spécifique et déterminer exactement sur quelle machine
nous voulons que les données arrivent.
À moins que vous n'ayez affaire à une exigence très spécifique, vous
n'aurez jamais besoin d'une telle règle dans votre jeu de règles !
Les fonctionnalités [uRPF (Unicast Reverse Path Forwardint)](https://www.openbsd.org/faq/pf/filter.html#urpf)
de PF protégeront votre réseau interne aussi bien avec un paramétrage
de base de NAT, avec l'option `nat-to` et une redirection avec l'option
`rdr-to`, PF gérera les paquets venant de l'intérieur vers l'extérieur
et vice-versa.
Le paramètre `all` est équivalent à l'écriture `from any to any`.
**Sans une direction explicitement déclarée, la règle par défaut est
`from any to any`**. Cette règle : `pass in on $p_lan proto udp to port dns`
se traduit par : `pass in on em3 inet proto udp from any to any port = 53`.
Il n'est pas non plus nécessaire d'utiliser `to any port dns`, la
partie `any` étant celle par défaut. Vous avez cependant besoin de
`to port dns`.
* `nat-to` et `rdr-to`
* Les options NAT **modifient soit l'adresse et le port source ou destination
des paquets associées à une connexion d'états**.
PF modifie l'adresse spécifié et/ou le port dans le paquet et recalcule
les sommes de contrôle IP, TCP et UDP nécessaires.
Une option `nat-to` spécifie **que les adresses IP ont été changées car
le paquet traverse l'interface donnée**.
Cette technique permet à une ou plusieurs adresses IP sur l'hôte traduisant
(le routeur OpenBSD) de prendre en charge le trafic réseau pour un ensemble
plus grand de machines sur le réseau **interne**, tel qu'un LAN.
L'option `nat-to` est habituellement appliqué à la sortie, signifiant
**redirigé depuis le réseau interne vers Internet**.
`nat-to` vers une adresse IP locale **n'est pas pris en charge**.
L'option `rdr-to` est appliquée généralement à l'entrée, signifiant
**redirigé depuis Internet vers le réseau interne**.
* Liste d'éléments et d'ensemble d'adresses et de ports
* Quand vous avez besoin de spécifier de multiples éléments, e.g. de
multiples numéros de ports, vous pouvez les séparer avec une espace
ou une virgule.
Tel que `port { 53 853 }` ou `port { 53, 853 }`.
Un ensemble d'adresses est spécifié en utilisant l'opérateur `-`.
e.g. `192.168.1.2 - 192.168.1.10` signifie toutes les adresses IP
de 192.168.1.2 à 192.168.1.10, incluant les deux.
Un ensemble de ports a de multiples paramètres ; regardez la page du
manuel [pf.conf](https://man.openbsd.org/pf.conf) et cherchez le texte
*"Ports and ranges of ports are specified using these operators"*.
{{< note warning >}}
Veuillez noter que chaque fois qu'un paquet traité par PF arrive ou part
d'une interface, les règles de filtrage sont évaluées dans un ordre séquentiel,
de la première à la dernière.
Concernant `block` et `pass`, **la dernière règle correspondante décide
de quelle action prise**.
Si aucune règle ne correspond au paquet, l'action par défaut est de laisser
passer le paquet sans créer d'état.
Pour `match`, les règles sont évaluées **chaque fois qu'elles correspondent**.
{{}}
### Résolution de nom de domaine ou d'hôte
Si vous décidez d'utiliser des noms d'hôtes et/ou des noms de domaines
dans votre paramétrage de PF, vous avez besoin de savoir que **la résolution
de tout nom de domaine ou d'hôte est faite au moment du chargement du jeu
de règles**.
Cela signifie que quand l'adresse IP d'un hôte ou d'un nom de domaine change,
le jeu de règles **doit être rechargé pour que le changement soit pris en
compte par le noyau**.
Il n'est pas possible qu'à chaque fois qu'une règle s'applique, pour un
nom d'hôte ou de domaine listé, que PF fasse une nouvelle requête DNS pour
ce nom d'hôte ou de domaine particulier.
La requête DNS s'effectue seulement lors du chargement du jeu de règles.
Cela signifie aussi que vous devez vous assurer que le serveur DNS que vous
utiliser soit actif et fonctionnel **avant** que PF ne démarre, autrement
PF échouera à charger le jeu de règles car il ne peut résoudre le nom d'
hôte ou de domaine.
Sur OpenBSD, PF démarre **avant** Unbound ou tout autre service DNS installé,
ce qui est la bonne manière de faire d'un point de vue de la sécurité.
Je vous conseille d'éviter l'utilisation de noms d'hôtes ou de noms de
domaines lorsque vous utilisez les règles PF et de privilégier les adresses
IP, si possible.
Il est possible d'utiliser les noms d'hôtes et noms de domaines, mais
l'adressage d'IP directement est de loin le plus facile et le plus sûr.
### Un jeu de règles
C'est une bonne idée de tester votre jeu de règles sur une machine de test.
Il y a presque toujours plus d'une manière de faire pour arriver au même
résultat. Selon mon humble avis, la meilleure manière est celle qui vous
permet d'être le plus clair (i.e. facile à comprendre).
{{< note warning >}}
Ne jamais écrire de nouveaux jeux de règles sur un dispositif à
distance où vous êtes actif à moins de savoir ce que vous faites.
Être déconnecté d'une machine à distance n'est jamais agréable.
{{}}
Essayez de trouver comment vous pouvez faire en sorte que vos règles soient
aussi claires et simples que possible, en utilisant les valeurs par
défaut, quand c'est possible.
N'ayez pas peur de spécifier des critères qui rendent les règles plus
claires à comprendre, quand bien même ils sont identiques aux valeurs par
défaut.
Une valeur par défaut peut être `any to any`, et vous pouvez laisser cela
de côté, mais il serait plus facile de comprendre une règle particulière
quand il est écrit `any to any` textuellement dans le fichier de configuration.
Vous pouvez toujours analyser le jeu de règles et vérifier les erreurs
sans qu'il soit déployé avec la commande `pfctl -nf /etc/pf.conf`.
Une fois que vous avez chargé le jeu de règles avec la commande `pfctl -f /etc/pf.conf`,
vous pouvez voir comment le jeu de règles a été traduit par PF avec la
commande `pfctl -s rules`, que je vous conseille d'utiliser régulièrement.
Je préfère organiser mon jeu de règles par section et commentaires, je
ferais ainsi dans cet exemple.
Utilisez votre éditeur de texte favori et ouvrez le fichier `/etc/pf.conf`.
En premier, nous paramétrons quelques macros pour mieux se souvenir quelles
interfaces réseaux nous utilisons.
Utiliser des macros pour les interfaces réseaux rend aussi plus facile le
changement du nom du pilote de la carte si vous achetez une nouvelle carte,
ou de multiples nouvelles cartes.
```
#---------------------------------#
# Macros
#---------------------------------#
ext_if="em0" # Interface externe connectée au modem du FAI (Internet).
g_lan="em1" # LAN PC Adultes
c_lan="em2" # LAN PC Enfants
p_lan="em3" # LAN Publique.
```
Ensuite, nous paramétrons une table pour les adresses IP non routable.
Nous faisons cela, car une mauvaise configuration réseau courante est
celle qui permet du trafic avec des adresses non routable vers Internet.
Nous utiliserons la table dans notre jeu de règles afin de bloquer
tout essai d'initier un contact avec les adresses non routable au-travers
de l'interface externe du routeur.
```
#---------------------------------#
# Tables
#---------------------------------#
# Ceci est une table d'adresses IP privées non routables.
table { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \
203.0.113.0/24 }
```
{{< note warning >}}
Veuillez noter que les macros et les tables sont toujours écrites en début
du fichier `/etc/pf.conf`.
{{}}
Alors, commençons avec une **politique de blocage par défaut** et
activons une série de fonctionnalités de protection.
```
#---------------------------------#
# Protect and block by default
#---------------------------------#
set skip on lo0
# Protection vs l'usurpation d'adresses sur toutes les interfaces réseaux.
block in from no-route
block in quick from urpf-failed
# Bloquage des adresses privées non routable.
# Utilisation du paramétre "quick" pour que cette règle soit la dernière traversée.
block in quick on $ext_if from to any
block return out quick on $ext_if from any to
# Bloquage par défaut de tout trafic sur toutes les interfaces réseaux.
block return in on { $g_lan $c_lan $dmz }
# Bloquage par défaut de tout trafic sur l'interface reliée à Internet
# avec journalisation
block drop in log on $ext_if
# Autoriser ICMP.
match in on $ext_if inet proto icmp icmp-type {echoreq } tag ICMP_IN
block drop in on $ext_if proto icmp
pass in proto icmp tagged ICMP_IN max-pkt-rate 100/10
# Autoriser le routeur à accéder à Internet, au-travers de son interface réseau dédiée
pass out inet from $ext_if
```
Les adresses IP contenues dans la macro `martians` constituent les adresses
référencées dans la [RFC1918](https://tools.ietf.org/html/rfc1918) qui ne
doivent pas être utilisées sur Internet.
Le trafic venant ou allant vers de telles adresses doit être abandonné
sur l'interface externe du routeur.
Dans les précédentes versions de ce guide (avant la version 1.5.0), j'avais
l'habitude d'utiliser l'instruction [scrub](https://man.openbsd.org/pf.conf#Scrub)
dans le paramétrage ci-dessus, toutefois après avoir consulté l'équipe
OpenBSD avec [Henning Brauer](http://henningbrauer.com/) (Merci à Henning !)
et fais de plus amples recherches, j'ai décidé de la supprimer car elle
ne traite que des cas très spécifiques (veuillez lire la documentation).
Vous aurez besoin de la règle `scrub` seulement si un hôte sur votre réseau
génére des paquets fragmentés avec le drapeau "dont-fragment".
Le comportement par défaut de PF sans la règle `scrub` est mieux adapté
à un usage général.
La [FAQ](https://www.openbsd.org/faq/pf/example1.html) d'OpenBSD contient
un exemple de paramétrage pour un routeur très basique, avec certaines
valeurs spécifiques pour `scrub`, mais ma recommandation est d'utiliser
seulement `scrub` là où vous savez en avoir besoin.
Si vous n'en avez pas besoin, insérez-la dans la configuration après la
règle `set skip` pour l'interface de bouclage locale, tel que :
```
set skip on lo0
match in all scrub
```
Et ensuite ajoutez les paramètres à la règle `scrub` dont vous avez besoin.
J'utilisais aussi la règle [antispoof](https://man.openbsd.org/pf.conf#Blocking_Spoofed_Traffic)
suivante dans la section de protection contre l'usurpation :
```
antispoof quick for { $g_lan $c_lan $dmz }
```
J'ai depuis supprimé la règle `antispoof` puisque la fonctionnalité
[uRPF (Unicast Reverse Path Forwarding)](https://www.openbsd.org/faq/pf/filter.html#urpf)
que PF fournit a la même fonctionnalité, et en tant que tel nous n'en avons
plus besoin, à la place nous utilisons juste la règle `block in quick from urpf-failed`.
L'information suivante à-propos du critère `antispoof` est gardée à des
fins d'éducation.
L'usurpation est lorsque quelqu'un fabrique une adresse IP. Le critère
`antispoof` s'étend à un ensemble de règles de filtrage qui empêcheront
tout trafic avec une adresse IP source du réseau (directement connecté
à l'interface spécifiée) entrant sur le système par une autre interface.
Cela est parfois appelé "bleeding over" ou "bleeding through".
La directive `antispoof` est traduite par PF par ce qui suit :
```
block drop in quick on ! em1 inet from 192.168.1.0/24 to any
block drop in quick inet from 192.168.1.1 to any
block drop in quick on ! em2 inet from 192.168.2.0/24 to any
block drop in quick inet from 192.168.2.1 to any
block drop in quick on ! em3 inet from 192.168.3.0/24 to any
block drop in quick inet from 192.168.3.1 to any
```
Si nous prenons, e.g., la règle `block drop in quick on ! em1 inet from 192.168.1.0/24 to any`
de l'interface réseau `em1` qui signifie alors : *bloque tout trafic venant
du réseau ayant une adresse IP comprise entre 192.168.1.1 et 192.168.1.255,
qui n'est pas originaire depuis l'interface em1 elle-même, et qui va ailleurs*.
Puisque l'interface `em1` est l'interface réseau en charge de toutes les
adresses IP dans cet ensemble spécifique, alors aucun trafic avec de telles
adresses IP ne pourra être originaire de toute autre interface réseau.
{{< note warning >}}
L'utilisation d'`antispoof` doit être **restreinte** aux interfaces qui
ont une adresse IP assignée, ce qui signifie que si vous avez des interfaces
réseaux inutilisées, ou des ports d'une interface réseau, assurez-vous
d'assigner une adresse IP à chacune ou de ne pas les inclure dans l'option
`antispoof`.
{{}}
Ainsi que je l'ai mentionnée, j'ai supprimé la règle `antispoof` et nous
utiliserons à la place la vérification stricte d'uRPF.
Lorsqu'un paquet passe dans la vérification d'uRPF, l'adresse IP source
du paquet est recherchée dans la table de routage.
Si l'interface de sortie est trouvée dans la table de routage et que l'entrée
est la même que l'interface du paquet qui vient juste d'entrer, alors la
vérification d'uRPF autorise.
Autrement, il est possible que le paquet ait son adresse IP source usurpée
ainsi il sera bloqué.
Nous allons permettre [ICMP](https://fr.wikipedia.org/wiki/Internet_Control_Message_Protocol)
dans notre paramétrage, quand bien même des administrateurs réseaux bloquent
complètement ICMP.
La plupart des personnes bloquent complètement ICMP à cause d'actions
injustifiées telles que les attaques par découverte de réseaux, les canaux
de communication, le [ping sweep](https://en.wikipedia.org/wiki/Ping_sweep),
le [ping flood](https://fr.wikipedia.org/wiki/Ping_flood), le [tunnel d'ICMP](https://en.wikipedia.org/wiki/ICMP_tunnel),
et la [redirection d'ICMP](https://fr.wikipedia.org/wiki/Internet_Control_Message_Protocol#Signification_du_type_5_(redirection)).
Toutefois, ICMP est bien plus que répondre à des ping.
Si nous bloquons complètement ICMP, les diagnostics, la fiabilité, et la
performance réseau peuvent être défectueuses puisque des mécanismes importants
sont désactivés lorsque le protocole ICMP est restreint.
Voici certaines raisons pour lesquelles ICMP ne devrait pas être bloqué :
- La découverte Path MTU (PMTUD) est utilisée pour déterminer la taille
maximale de l'unité de transmission pour les dispositifs réseau qui relient
la source et la destination afin d'éviter la fragmentation IP.
TCP dépend des paquets ICMP de type 3 code 4 pour "Path MTU Discovery".
ICMP type 3 code 4 et la taille maximale des paquets sont retournés quand
un paquet excède la taille MTU d'un dispositif réseau connecté.
Quand les messages ICMP sont bloqués, le système de destination requête
continuellement des paquets non délivrés et le système source continue à
les renvoyer indéfiniment mais en vain.
Ce comportement peut avoir pour résultat un [trou noir](https://fr.wikipedia.org/wiki/Black_hole_(informatique))
ICMP (des connexions IP congestionnées et des transmissions cassées).
- Time to live (TTL) définit le temps de vie d'un paquet de données.
Un réseau où ICMP est bloqué ne recevra pas le message de type 11, temps
écoulé, code 0, temps écoulé dans le transit des messages d'erreur.
Cela signifie que l'hôte source ne sera pas notifié pour augmenter le temps
de vie des données afin d'atteindre l'hôte de destination, si le datagram
échoue à atteindre l'hôte de destination.
- Une mauvaise performance du fait de bloquer la redirection ICMP.
La redirection ICMP est utilisée par un routeur pour informer un hôte d'un
chemin direct entre l'hôte source et celui de destination.
Cela réduit le nombre de saut que les données ont à faire pour atteindre
la destination.
Avec ICMP bloqué, l'hôte ne fera jamais attention à la route la plus optimale
vers la destination.
Dans le paramétrage ci-dessus, nous permettons ICMP, mais nous mettons une
"limite de taux" du nombre de requêtes ping auxquelles le routeur répondra.
Avec le critère `max-pkt-rate 100/10`, le routeur arrêtera de répondre aux
ping si nous en avons plus de 100 en 10 secondes.
{{< note info >}}
Si vous souhaitez toujours bloquer complètement ICMP pour une raison quelconque,
il suffit de supprimer les 3 règles après le commentaire "Allow ICMP".
{{}}
Maintenant paramétrons le segment LAN pour les adultes de la maison.
```
#---------------------------------#
# Paramétrage du réseau LAN adulte
#---------------------------------#
# Autoriser tout ordinateur ou dispositif sur le LAN adulte à envoyer des
# paquets de données entrants dans l'interface réseau. Cela signifie que
# tout ordinateur attaché à cette interface réseau peut envoyer des données
# partout, i.e. sur Internet ou tout ordinateur attaché au routeur.
pass in on $g_lan
# Toujours bloquer les requêtes DNS non adressées à notre serveur DNS.
block return in quick on $g_lan proto { udp tcp } to ! $g_lan port { 53 853 }
# J'ai une imprimante réseau et je ne veux pas qu'elle "téléphone maison".
# L'imprimange réseau à l'adresse IP 192.168.1.8.
block in quick on $g_lan from 192.168.1.8
# Autoriser les paquets de données venant du routeur à sortir par l'interface
# réseau vers les ordinateurs et dispositifs attachés à l'interface du
# réseau Adultes.
# Sans cela nous ne pouvons même pas pingués les ordinateurs attachés à
# l'interface du réseau Adultes depuis le routeur lui-même.
pass out on $g_lan inet keep state
```
Dans cet exemple, j'ai une imprimante réseau attachée au réseau des adultes
et je ne veux pas qu'elle accéde à Internet ou ailleurs (juste en cas où
il y aurait une sorte de micrologiciel espion).
Nous le faisons en disant : *bloque toutes les données entrantes sur em1
venant de l'adresse IP 192.168.1.8 allant vers toute adresse IP*.
De plus, nous nous assurons que toutes les requêtes DNS sur les ports 53
(DNS régulier) et 853 (DNS sur TLS) soient toujours bloquées si elles ne
viennent pas de notre serveur DNS.
{{< note info >}}
Avant, j'utilisais la redirection du trafic sur le port 53 non adressé à
notre serveur DNS vers notre serveur DNS.
Je faisais cela parce que nous bloquions toute requête DNS sur le port 53,
soit avec `return` ou `drop`, la requête prenant un délai sur le client,
ce qui avait pour conséquence que beaucoup de clients obtenaient un délai
sur la réponse.
Depuis j'ai changé cela en block parce que je crois que c'est une meilleure
approche.
Tous les clients DNS ont besoin de réaliser que la communication sur le
port 53 est bloqué, à moins qu'elle ne soit adressée à notre serveur DNS.
C'est aussi important quand nous avons des problèmes sur notre réseau.
Si nous avons une réponse redirigée vers notre serveur DNS, nous pourrions
ne pas être averti que nous avons été redirigé.
{{}}
{{< note info >}}
DNS utilise en premier UDP (User Datagram Protocol) sur le port 53 pour
servir les requêtes, mais quand la longueur de la réponse excède 512 bits
et que le client et le serveur prennent en charge EDNS, des paquets UDP
plus grands sont utilisés.
Toutefois, la requête est envoyée en utilisant TCP (Transmission Control Protocol).
Certaines implémentations de résolveurs DNS utilisent TCP pour toutes les
requêtes.
Ainsi nous avons besoin des deux protocoles UDP et TCP dans la règle pour
le port 53.
{{}}
Le réseau LAN pour les enfants est très similaire.
```
#---------------------------------#
# Paramétrage LAN enfants
#---------------------------------#
# Autoriser tout PC du LAN Enfant à envoyer des données au-travers du port
# de l'interface réseau
pass in on $c_lan
# Toujours bloquer les requêtes DNS qui ne sont pas adressées à notre
# serveur DNS.
block return in quick on $c_lan proto { udp tcp} to ! $c_lan port { 53 853 }
# Autorise les paquets de données à passer venant du routeur au-travers
# l'interface réseau vers les ordinateurs ou dispositifs attachés au
# LAN Enfants.
# Sans cela, nous ne pourrions même pas pingués les ordinateurs depuis
# le routeur lui-même
pass out on $c_lan inet keep state
```
Actuellement les deux réseaux Adultes et Enfants ont le même accès à Internet.
Un paramétrage plus restrictif est mentionné dans le chapitre
"{{< anchor "Liste Blanche pour enfants" "une liste blanche pour les enfants" >}}".
Occupons nous alors de la DMZ, i.e. de l'interface réseau qui répond publiquement
au serveur web.
Puisque nous avons un serveur web publique, nous allons définir un certain
nombre de restrictions.
Si le serveur web est compromis, l'intrus aura du mal à trouver ce qui est
localisé dans notre réseau interne.
Nous bloquons tous les accès excepté le DHCP, afin que le serveur web
ait une adresse IP depuis notre routeur, et alors d'ouvrir **seulement
manuellement** certaines choses pour quand nous avons besoin de mettre à
jour la machine ou quoi que ce soit d'autres.
J'ai commenté les options dont nous avons besoins, quand nous avons besoin
de telles choses, laissant les parties restreintes actives.
Quand vous aurez besoin de mettre à jour le serveur, ouvrez l'accès DNS
et l'accès général à Internet.
{{< note info >}}
Plutôt que changer manuellement le jeu de règles à chaque fois où nous avons
besoin de mettre à jour le serveur web, nous pouvons aussi utiliser une
[ancre](https://man.openbsd.org/pf.conf#ANCHORS), mais par esprit de
simplification, nous ne ferons pas cela ici.
{{}}
```
#---------------------------------#
# Paramétrage DMZ
#---------------------------------#
# Autorise tout ordinateur ou dispositif attaché à l'interface réseau DMZ
# à obtenir une adresse IP venant du DHCP depuis le routeur
pass in on $dmz inet proto udp from any port 67
# Autorise tout ordinateur ou dispositif attaché à l'interface réseau DMZ
# à faire des requêtes DNS. (décommentez si besoin)
#pass in on $dmz inet proto udp from any port 53
# Toujours bloquer les requêtes DNS non adressées à notre serveur DNS.
block return in quick on $dmz proto { udp tcp} to ! $dmz port { 53 853 }
# Pour autoriser tout ordinateur attaché à l'interface réseau DMZ à accéder
# à Internet, décommentez la ligne ci-dessous.
# (Cela est pertinent pour les màj)
#pass in on $dmz inet
# No matter what, we do not want the DMZ segment to reach any of the other
# network segments so we explicitly use a block last.
#
# We have several options. If we use this:
#
# block drop in on $dmz to 192.168/16
#
# Then we block for all subnets, but this also means that the computers
# attached to the DMZ NIC cannot do DNS queries when they need to be upgraded.
#
# In my opinion it is much better to be explicit and block the specific
# segments we want blocked.
#
# Bloque les ordinateurs depuis l'interface réseau DMZ essayant d'atteindre
# les autres sur les deux autres segments réseaux
block drop in on $dmz to { $g_lan:network $c_lan:network }
# En dernier, autorisons les paquets à sortir s'ils viennent de l'interface
# réseau DMZ vers les ordinateurs attachés, autrement pas de "discussion".
# Sans cela nous ne pouvons même pas pinguer les ordinateurs attachés à
# l'interface réseau DMZ depuis le routeur lui-même
pass out on $dmz inet keep state
```
Maintenant, occupons nous de la NAT.
C'est là où le routeur route les paquets venant d'un segment du réseau
vers un autre, dans le cas spécifique venant de notre réseau interne vers
Internet, et alors toute réponse venant d'Internet, à destination de
l'initiateur de la transmission.
Je préfère le paramètre `:network` qui traduit le(s) réseau(x)
attaché(s) à l'interface, et je préfère être spécifique avec une règle
pour chaque segment concerné.
```
#---------------------------------#
# NAT
#---------------------------------#
pass out on $ext_if inet from $g_lan:network to any nat-to ($ext_if)
pass out on $ext_if inet from $c_lan:network to any nat-to ($ext_if)
pass out on $ext_if inet from $dmz:network to any nat-to ($ext_if)
```
PF gardera une trace de tout le trafic, et quand, e.g. un navigateur web sur
le LAN Adultes demandera une page web de certains sites sur Internet,
la réponse venant du serveur web depuis Internet sera routé au-travers de
l'interface externe vers l'interface interne du LAN Adultes, et alors
directement vers le PC qui a initié la requête.
Enfin, occupons-nous de la partie relative à la redirection dans notre
jeu de règles.
C'est là où nous permettons le trafic venant d'Internet vers notre serveur
web publique sur l'interface réseau DMZ.
Vous devriez, bien sûr, laisser cette partie si vous n'avez pas de serveurs
publiques qui nécessitent de redirection.
Dans cet exemple, j'ai seulement permis le trafic IPv4.
```
#---------------------------------#
# Redirects
#---------------------------------#
# Our web server - let the Internet access it.
pass in on $ext_if inet proto tcp to $ext_if port { 80 443 } rdr-to 192.168.3.2
```
{{< note warning >}}
La redirection arrive toujours en dernier dans le jeu de règles !
{{}}
C'est tout concernant le paramétrage basique de nos règles filtrantes.
#### Une liste blanche pour les enfants
Si vous voulez bloquer tout Internet pour les enfants, exceptés peut être
quelques sites web ou certains serveurs de jeux, vous avez besoin de
connaître quelles adresses IP ces services ont et de créer une liste
blanche utilisant ces adresses IP.
Si c'est un simple site web avec une adresse IP unique, c'est très facile
et vous pouvez le faire avec cette règle placée en dernier dans le bloc
pour enfants (vous devez remplacer la partie x.x.x.x avec l'adresse IP
pertinente) :
```
#---------------------------------#
# Childrens LAN Setup
#---------------------------------#
# Allow any computer or device attached to the childrens NIC to get an IP
# address from DHCP on the router.
pass in on $c_lan inet proto udp from any port 67
# Allow any computer or device attached to the childrens NIC to make DNS
# queries.
pass in on $c_lan inet proto udp from any port 53
# Always block DNS queries not addressed to our DNS server.
block return in quick on $c_lan proto { udp tcp} to ! $c_lan port { 53 853 }
# Then allow any computer or device attached on the childrens LAN to reach
# the IP address x.x.x.x only.
pass in on $c_lan to x.x.x.x
```
Si le site web a de multiples adresses IP, nous devons comprendre lesquelles.
Parfois une requête de nom de domaine peut révéler toutes les adresses IP
concernées en une fois.
D'autres fois, nous avons besoin de répéter de multiples fois les requêtes
à différentes intervalles de la journée avant d'obtenir l'ensemble complet
des adresses IP.
Vous pouvez faire cela en mettant en place un script automatisé.
Parfois, nous aurons besoin de contacter l'entreprise en question et de
demander si nous pouvons avec l'ensemble des adresses IP pour notre liste
blanche (certaines compagnies publient publiquement l'information, d'autres
refusent de livrer l'information par peur d'un usage malicieux).
Une fois que vous avez déterminé quel est l'ensemble d'adresses IP, vous
pouvez faire une `table` PF pour l'utiliser.
Dans cet exemple, nous ajoutons une nouvelle table dans la section table
des règles et nous changeons les paramètres des règles pour enfants.
```
#---------------------------------#
# Tables
#---------------------------------#
…
# Whitelist for the children.
table { x.x.x.x y.y.y.y z.z.z.z }
```
Et ensuite dans la section pour enfants, changez :
```
pass in on $c_lan to x.x.x.x
```
en :
```
pass in on $c_lan to
```
Il n'est pas toujours possible d'avoir toutes les adresses IP dans une
liste blanche en une fois, mais en surveillant le réseau, en utilisant e.g.
[tcpdump](https://man.openbsd.org/tcpdump), quand le jeu essaye d’accéder
au serveur, vous pouvez établir une liste, bit après bit.
J'ai fait cela avec les serveurs de connexion Mojan et Minecraft et de
multiples autres serveurs de jeux.
##### Utilisation d'une table persistante
Une autre approche pour collecter les IP est d'utiliser une [table persistante](https://man.openbsd.org/pf.conf#TABLES)
en combinaison avec `/etc/rc.local` et les requêtes de noms de domaine.
`/etc/rc.local` est seulement exécuté **après** que PF soit démarré ainsi
les problèmes de résolution de DNS n'entraîneront pas des problèmes pour
PF.
Si vous souhaitez utiliser la solution des tables persistantes, vous pouvez
le faire en ajoutant une table persistante dans la section des tables
dans `/etc/pf.conf` :
```
table persist
```
Dans la section pour enfants, nous avons besoin de passer les données
qui viennent de la liste blanche ci-dessus :
```
pass in on $c_lan to
```
Alors, dans `/etc/rc.local`, nous pouvons ajouter la commande suivante :
```
pfctl -t whitelist -T add example.com
```
Où `example.com` est le domaine que PF doit chercher.
Quand vos enfants ne peuvent pas avoir accès parce que l'adresse IP valide
pourrait avoir changé, vous pouvez vous connecter au pare-feu et alors
mettre à jour manuellement la table avec plus d'adresses IP en exécutant
la commande :
```
pfctl -t whitelist -T add examples.com
```
Si vous voulez voir ce qui a été ajouté à cette liste, vous pouvez faire
ceci :
```
# pfctl -t whitelist -T show
74.6.143.25
74.6.143.26
74.6.231.20
74.6.231.21
98.137.11.163
98.137.11.164
216.58.208.110
2001:4998:24:120d::1:0
2001:4998:24:120d::1:1
2001:4998:44:3507::8000
2001:4998:44:3507::8001
2001:4998:124:1507::f000
2001:4998:124:1507::f001
2a00:1450:400e:80e::200e
```
Éventuellement, vous pouvez ajouter toutes les adresses IP que vous collectez
(avant qu'elles ne soient purgées) dans un fichier physique afin que l'option
`persist` prenne en entrée ce fichier, tel que :
```
table persist file "/etc/pf-whitelist.txt"
```
{{< note info >}}
Le fichier ne devra pas avoir d'adresses IP ajoutées en utilisant
l'option `add` à `pfctl`.
Une table persistante réside soit en mémoire, soit dans un fichier, mais
l'option `add` ne peut écrire sur le disque, seulement dans la mémoire.
Une table persistante depuis un fichier est ce dont vous avez besoin afin
de l'éditer manuellement depuis un éditeur de texte.
{{}}
### Chargement des règles
Une fois que vous avez fini de paramétrer votre jeu de règles, vous pouvez
le tester avec :
```
# pfctl -nf /etc/pf.conf
```
Si tout est bon, chargez votre jeu de règles en supprimant l'option `-n` :
```
# pfctl -f /etc/pf.conf
```
Regardez le résultat traduit avec :
```
# pfctl -s rules
```
### Journalisation et Monitoring
Ceci est un exemple de sortie venant du journal de PF des essais bloqués
accédant à l'interface externe, selon mon paramétrage. J'ai nettoyé la
sortie et supprimé quelques données spécifiques, et bien sûr 0.0.0.0 n'est
pas mon adresse IP publique, mais vous savez déjà cela ;)
```
# tcpdump -n -e -ttt -r /var/log/pflog
23:11:12 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3422: S 1501043655:1501043655(0) win 1024
23:11:12 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3481: S 311078394:311078394(0) win 1024
23:11:31 rule 14/(match) block in on em0: 176.214.44.229.25197 > 0.0.0.0.23: S 2084440900:2084440900(0) win 33620
23:11:33 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3431: S 2774981044:2774981044(0) win 1024
23:11:43 rule 14/(match) block in on em0: 81.68.114.52.17191 > 0.0.0.0.23: S 1346864438:1346864438(0) win 26375
23:12:08 rule 14/(match) block in on em0: 193.27.229.26.53865 > 0.0.0.0.443: S 1057596009:1057596009(0) win 1024
23:12:31 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.4186: S 1233742605:1233742605(0) win 1024
23:12:44 rule 14/(match) block in on em0: 74.120.14.70.65509 > 0.0.0.0.9125: S 1836577847:1836577847(0) win 1024 [tos 0x20]
23:12:44 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.4128: S 2112968453:2112968453(0) win 1024
23:13:15 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3669: S 3627248539:3627248539(0) win 1024
23:13:19 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3654: S 3889665614:3889665614(0) win 1024
23:13:29 rule 14/(match) block in on em0: 45.129.33.129.42239 > 0.0.0.0.4997: S 2249816896:2249816896(0) win 1024
23:13:37 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3612: S 3797528151:3797528151(0) win 1024
23:14:03 rule 14/(match) block in on em0: 190.207.89.17.64372 > 0.0.0.0.445: S 1097568353:1097568353(0) win 8192 (DF)
23:14:15 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.4219: S 2834775769:2834775769(0) win 1024
23:14:39 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.3702: S 1855726637:1855726637(0) win 1024
23:14:39 rule 14/(match) block in on em0: 45.129.33.4.45980 > 0.0.0.0.4210: S 3052103070:3052103070(0) win 1024
```
Comme vous pouvez le voir, il est un peu occupé, d'autant que je n'ai rien
en cours d'exécution qui soit publiquement sur Internet dans ce paramétrage.
Vous pouvez aussi monitorer PF en temps réel avec :
```
# tcpdump -n -e -ttt -i pflog0
```
## DNS
[DNS (Domain Name Service)](https://fr.wikipedia.org/wiki/Domain_Name_System)
est utilisé pour traduire un nom de domaine dans une adresse IP ou vice-versa.
Par exemple, quand vous écrivez [wikipedia.org](https://wikipedia.org/)
dans la barre d'adresse de votre navigateur web, un serveur DNS faisant
autorité traduit le nom de domaine "wikipedia.org" en une adresse IPv4,
telle que 91.198.174.192, et/ou une adresse IPv6, telle que 2620:0:862:ed1a::1.
DNS est aussi utilisé, en plus d'autres choses, pour stocker des informations
sur les serveurs de messagerie appartenant à un nom de domaine particulier,
le cas échéant.
Si vous utilisez un système d'exploitation de type UNIX, vous pouvez
démarrer un terminal et essayer de faire une recherche manuelle de nom
de domaine avec `host` :
```
$ host wikipedia.org
wikipedia.org has address 91.198.174.192
wikipedia.org has IPv6 address 2620:0:862:ed1a::1
wikipedia.org mail is handled by 10 mx1001.wikimedia.org.
wikipedia.org mail is handled by 50 mx2001.wikimedia.org.
```
{{< note info >}}
Si `host` n'est pas installé, ce qui dépend de votre plateforme, vous aurez
besoin d'installer [bind](https://www.isc.org/bind/) ou `dnsutils`.
Vous pouvez aussi utiliser quelque chose comme [dig](https://man.openbsd.org/dig),
qui vient de [bind](https://www.isc.org/bind/), ou [drill](https://linux.die.net/man/1/drill)
venant de [ldns](https://nlnetlabs.nl/projects/ldns/about/).
{{}}
La liste qui suit décrit certains des termes associés à DNS :
- `Forward DNS`
- Correspondance des noms d'hôtes ou de domaines avec les adresses IP.
- `Reverse DNS`
- Correspondance des adresses IP avec les noms d'hôtes ou de domaines.
- `Resolver`
- Un système par lequel une machine requiert un serveur de nom pour
la zone d'information, i.e. un autre nom pour "Serveur DNS".
- `Root zone`
- Le début de la hiérarchie des zones Internet. Toutes les zones sont
sous la [zone racine](https://en.wikipedia.org/wiki/DNS_root_zone),
similaire à ce que sont tous les fichiers dans un système de fichier
sous la hiérarchie racine /.
Ceci est un exemple de zone :
- `.` (un point) est la manière dont la zone racine est habituellement
référée dans la documentation.
- `org.` est le [TLD (Top-Level Domain)](https://fr.wikipedia.org/wiki/Domaine_de_premier_niveau)
sous la zone root.
- `wikipedia.org.` est la zone sous le TLD `org.`.
- `1.168.192.in-addr.arpa` est la zone référençant toutes les adresses IP
qui sont dans l'espace d'adresse IP `192.168.1.*`.
Quand un ordinateur sur Internet a besoin de résoudre un nom de domaine,
le résolveur découpe le nom dans ses labels de la droite vers la gauche.
Le premier composant, le TLD, est demandé en utilisant un serveur racine
pour obtenir le serveur faisant autorité responsable.
Les requêtes pour chaque label retournent des serveurs de noms plus
spécifiques jusqu'à ce qu'un serveur de noms renvoie la réponse à la
requête originale.
Même si un serveur DNS local peut implémenter ses propres serveurs de noms
racines privés, le terme "serveur racine de noms" est utilisé pour décrire
[les 13 serveur racines de noms bien connus](https://fr.wikipedia.org/wiki/Serveur_racine_du_DNS#Les_serveurs_racine_du_DNS)
qui mettent en œuvre le domaine de l'espace racine des noms pour la mise
en œuvre mondiale officielle du système de noms de domaine d'Internet.
Les résolveurs utilisent un petit fichier nommé `root.hints` de 3 Ko,
publié par [Internic](https://fr.wikipedia.org/wiki/InterNIC) pour amorcer
cette liste initiale d'adresses des serveurs racines.
Pour beaucoup de logiciels, incluant Unbound, cette liste est intégrée à
l'intérieur du logiciel.
Sur la [base de données de la zone racine](https://www.iana.org/domains/root/db),
vous pouvez chercher les détails de délégation des domaines TLD, incluant
des TLD tels que .com, .org, et des TLD ayant des codes de pays, tels que
.uk, .de.
{{< note info >}}
Puisque vous pouvez chercher les détails de délégation des domaines TLD,
vous pourriez vous attendre à ce qu'il soit possible d'aller en profondeur
et de chercher actuellement pour chaque domaine un serveur de domaine
en particulier qui a enregistré dans sa base de données.
Puisque nous avons, pour l'exemple, pris une liste des serveurs de noms
TLD responsables pour le TLD [.dk](https://www.iana.org/domains/root/db/dk.html),
nous pourrions nous attendre à ce qu'il soit possible d'interroger l'un de
ces serveurs de noms listés pour l'ensemble de la base de données des
serveurs faisant autorité, puis d'interroger l'un d'entre eux pour tous
les domaines enregistrés dans sa base de données.
Mais ce n'est pas comme cela que fonctionne DNS.
Il y a seulement deux manières pour obtenir la cartographie complète des
serveurs DNS.
Soit vous avez accès aux fichiers de la zone concernée, soit vous avez
besoin de construire physiquement une base de donnée en examinant le trafic
DNS au-travers un serveur DNS récursif et alors de reconstituer les données
de la zone à partir des données recueillies, jusqu'à ce que vous obteniez
tout, ce qui est très peu probable.
{{}}
Il y a deux types de configuration de serveur DNS :
- `Autorité`
- [Les serveurs de noms faisant autorité] publie les adresses pour les
domaines sous leur contrôle. Ces serveurs sont listés au début de la
chaîne d'autorité pour leurs domaines respectifs, et sont capables de
fournir une réponse définitive.
Les serveurs de noms faisant autorité peuvent être les serveurs de noms
primaires, connus aussi en tant que serveurs maîtres, i.e. ils contiennent
le jeu original des données, ou être des serveurs de noms secondaires
ou esclaves, contenant des copies des données habituellement obtenues
par synchronisation directe avec le serveur primaire.
Un serveur de nom faisant autorité est un serveur de nom qui donne
seulement des réponses aux requêtes DNS venant de données qui ont été
configurées par une source originale, par exemple, l'administrateur
de domaine.
Chaque zone DNS doit être assignée à un ensemble de serveurs de noms
faisant autorité.
Cet ensemble de serveurs est enregistré dans la zone de domaine parente
des enregistrements du serveur de noms (NS).
Un serveur faisant autorité indique son statut de fournisseur de
réponses définitives, considérées comme faisant autorité, en posant
un drapeau de protocole, appelé bit "Authoritative Answer" (AA), dans
ses réponses.
Vous pouvez utiliser un outil réseau, tel que [dig](https://man.openbsd.org/dig)
ou [drill](https://linux.die.net/man/1/drill) pour interroger un nom
de domaine ; l'outil répondra avec un drapeau faisant autorité qui
révèle si le serveur DNS vous avez interrogé est celui qui fait autorité.
- `Récursif`
- [Les serveurs récursifs](https://fr.wikipedia.org/wiki/Domain_Name_System)
parfois appelés "DNS caches" ou "serveurs de noms de cache seulement"
fournissent la résolution de noms DNS pour les applications, en relayant
les requêtes de l'application cliente vers la chaîne des serveurs de
noms faisant autorité afin de résoudre pleinement un nom de domaine.
(Typiquement) ils mettent en cache le résultat pour répondre a de
futures requêtes potentielles dans une certaine période de temps avant
expiration.
La plupart des utilisateurs d'Internet accèdent à un serveur DNS récursif
publique fournit par leur FAI ou un fournisseur de service DNS publique.
En théorie, les serveurs de noms faisant autorité sont suffisant pour
opérer sur Internet.
Toutefois, avec seulement les serveurs de noms faisant autorité opérant,
chaque requête DNS doit démarrer avec des requêtes successives à la
zone racine du système de nom de domaine et chaque utilisateur système
devrait avoir à implémenter un logiciel résolveur capable d'opérations
de résolution.
Pour améliorer l'efficacité, réduire le trafic DNS sur Internet, et
augmenter la performance des applications utilisateurs, le système de
noms de domaine prend en charge les résolveurs récursifs.
Une requête d'un DNS récursif est celle pour laquelle un serveur DNS
répond complètement à la requête en interrogeant d'autres serveurs
de noms, selon ses besoins.
Un serveur de noms peut être à la fois faisant autorité et récursif, mais
il n'est pas recommandé de combiner la configuration des deux types.
Pour être en mesure d'effectuer leur travail, les serveurs faisant autorité
doivent être disponibles à tous les clients, tout le temps.
D'un autre côté, étant donné que la requête récursive prend plus de temps
qu'une réponse faisant autorité, les serveurs récursifs devraient être
restreints à un nombre de clients seulement, car ils sont enclins à des
[attaques par déni de service distribué (DDoS)](https://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service).
{{< note info >}}
Si besoin, je vous recommande de lire "How DNS Works" du
[chapitre 6 du Guide de l'Administrateur Réseau Linux](https://tldp.org/LDP/nag2/x-087-2-resolv.howdnsworks.html).
Je recommande aussi de lire l'article [DNS](https://fr.wikipedia.org/wiki/Domain_Name_System) sur Wikipédia.
{{}}
### Je vous présente Unbound
[Unbound](https://nlnetlabs.nl/projects/unbound/about/) est un résolveur
DNS Open Source récursif, cache et validant avec les fonctionnalités
suivantes :
- Cache avec possibilité de récupèrer des éléments populaires avant qu'ils
expirent.
- Serveur et Redirection DoT (DNS over TLS), avec validation de domaine
- DoH (DNS over HTTPS)
- Minimisation du nom de la requête
- Utilisation aggressive du cache validé par DNSSEC.
- Zones faisant autorité, pour une copie locale de la zone racine.
- DNS64
- DNSCrypt
- Validation DNSSEC
- Client de sous-réseau EDNS
Unbound est conçu pour être rapide et sécurisé et incorpore des fonctionnalités
modernes basées sur des normes ouvertes. Fin 2019, Unbound a été
[rigoureusement audité](https://ostif.org/wp-content/uploads/2019/12/X41-Unbound-Security-Audit-2019-Final-Report.pdf).
{{< note tip >}}
Une des principales raisons d'utiliser Unbound plutôt que de nombreux autres
résolveurs cache seulement, tel que [dnsmasq](https://fr.wikipedia.org/wiki/Dnsmasq)
par exemple, est que si vous n'utilisez pas l'option **forward** dans la
configuration d'Unbound, Unbound **fera des requêtes directement aux serveurs
racines** en utilisant leurs adresses IP enregistrées et listées dans le
[fichier Root Hints](https://www.iana.org/domains/root/files).
Ceci vous libèrera des serveurs DNS de votre FAI, et de tout serveur DNS
publique, tel que Google ou Cloudflare, et tout enregistrement, vente et
manipulation de données, tels qu'ils le font sera évité.
Un simple serveur cache tel que dnsmasq devra toujours rediriger ses requêtes
vers un autre serveur, là où Unbound interrogera les serveurs racines
directement et suivra la chaîne des domaines jusqu'à ce qu'il obtienne
l'enregistrement pertinent depuis le serveur DNS faisant autorité pour le
domaine concerné.
Cela signifie que le serveur DNS qui sait spécifiquement ce que vous
recherchez soit aussi celui qui fait autorité pour répondre à la question.
{{}}
{{< note warning >}}
Si votre FAI fait du détournement de trafic DNS, Unbound ne vous aidera
en aucune manière.
Lisez la section {{< anchor "Détournement de DNS" "Détournement de DNS" >}} concernant
l'information afin que vous puissiez déterminer sir le trafic
de votre DNS est détourné.
{{}}
Dans notre paramétrage avec Unbound, une requête pour un domaine tel que
"wikipedia.org" ressemblera à ceci :
1. Votre navigateur envoie une requête au système d'exploitation, avec
la question "Quelle est l'adresse IP de wikipedia.org ?"
2. Le système d'exploitation, plus spécifiquement les routines du résolveur
dans la bibliothèque C, qui fournit l'accès au Système de Noms de Domaines
sur Internet, redirigera la requête DNS vers le(s) serveur(s) de noms de
domaine listé dans [/etc/resolv.conf](https://man.openbsd.org/resolv.conf)
(sur des systèmes d'exploitation de type UNIX)
3. Unbound reçoit la requête et en premier cherche "wikipedia.org" dans son
cache et s'il ne le trouve pas, interroge un des serveurs racines listés
dans son fichier Root Hints pour le domaine TLD ".org".
4. Le serveur racine répond par une référence aux serveurs concernés du
domaine TLD ".org".
5. Unbound envoie alors une requête à l'un des serveurs concernés demandant
quels sont les serveurs DNS faisant autorité pour "wikipedia.org".
6. Le serveur répond avec une référence aux serveurs de noms faisant autorité
enregistrés pour "wikipedia.org".
7. Unbound envoie alors une requête à l'un des serveurs de noms faisant
autorité et demande l'adresse IP pour "wikipedia.org".
8. Le serveur de noms faisant autorité répond par l'envoi de l'adresse IP
listée dans les enregistrements "A" et/ou "AAAA" pour le domaine
"wikipedia.org".
9. Unbound reçoit l'adresse IP du serveur de noms faisant autorité et
retourne la réponse au client.
10. Si cela est activé, Unbound met en cache alors l'information pour une
longueur de temps prédéterminée pour de futures requêtes pour le même nom
de domaine.
Vous pouvez essayer de faire une `trace` DNS par vous-mêmes pour voir le
propos ci-dessus. J'utilise [drill](https://linux.die.net/man/1/drill)
dans cet exemple avec l'option `trace` activée.
```
# drill -T wikipedia.org
. 518400 IN NS l.root-servers.net.
. 518400 IN NS k.root-servers.net.
. 518400 IN NS e.root-servers.net.
. 518400 IN NS a.root-servers.net.
. 518400 IN NS m.root-servers.net.
. 518400 IN NS h.root-servers.net.
. 518400 IN NS i.root-servers.net.
. 518400 IN NS f.root-servers.net.
. 518400 IN NS c.root-servers.net.
. 518400 IN NS b.root-servers.net.
. 518400 IN NS g.root-servers.net.
. 518400 IN NS d.root-servers.net.
. 518400 IN NS j.root-servers.net.
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.
wikipedia.org. 86400 IN NS ns0.wikimedia.org.
wikipedia.org. 86400 IN NS ns1.wikimedia.org.
wikipedia.org. 86400 IN NS ns2.wikimedia.org.
wikipedia.org. 600 IN A 91.198.174.192
```
{{< note info >}}
Unbound a la capacité de valider les réponses qu'il reçoit comme correctes.
C'est habituellement accompli par l'utilisation de
[DNSSEC](https://fr.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)
ou l'utilisation de bits aléatoires encodés 0x20 dans la requête pour
déjouer les tentatives d'usurpation d'identité.
À l'exception des [bits aléatoires encodés 0x20](https://man.openbsd.org/unbound.conf#use~3),
tous les autres paramétres de validation tel que [harden-glue](https://man.openbsd.org/unbound.conf#harden~3)
et [hardened dnssec-stripped data](https://man.openbsd.org/unbound.conf#harden~4)
sont tous activés par défaut dans Unbound pour OpenBSD.
{{}}
### Blocage par DNS
Le blocage par DNS, appelé aussi filtrage ou usurpation DNS, est le processus
qui vous permet de fournir une "fausse" réponse au client qui effectue
la requête.
Nous bloquons une requête pour une adresse IP valide soit en répondant avec
un [NXDOMAIN](https://tools.ietf.org/html/rfc8020), signifiant nom de domaine
inexistant, ou soit en redirigeant vers une autre adresse IP que celle prévue
par le propriétaire du domaine.
Cela nous oblige à créer une liste, ou des listes multiples, de domaines
que nous voulons bloquer et plutôt que de fournir à l'utilisateur l'adresse
IP correcte pour un certain domaine, nous renvoyons le message que le
domaine est "inexistant", ce qui bloquera toute communication vers la
destination prévue pour l'application.
Normalement, toutes les requêtes DNS sont envoyés vers le port 53 soit sur
le protocole UDP, soit TCP, lors de la mise en place du serveur DNS, ce que
nous faisons avec Unbound, et en s'assurant que tout le trafic du port 53
atteigne notre serveur DNS ou autrement soit bloqué ; nous pouvons nous
assurer que toutes les réponses DNS viennent de notre serveur Unbound interne
à notre routeur OpenBSD.
{{< note info >}}
Vous ne pouvez pas pleinement faire confiance au blocage par DNS car le
blocage par DNS peut être contourné.
Même en ayant une solide approche en place, il est toujours possible pour
quelqu'un d'utiliser un [service VPN](https://fr.wikipedia.org/wiki/R%C3%A9seau_priv%C3%A9_virtuel)
pour contourner cela.
Nous n'essayons pas de construire un système 100% infaillible - même si
nous y reviendrons un peu plus loin dans ce guide - nous essayons juste
de protéger nos familles de la meilleure manière.
Il y a toujours aussi les autres points d'accès à Internet que nous devons
considérer, tels que les téléphones, ceux des amis ou leur maison, les
accès publique à Internet, etc.
{{}}
#### NXDOMAIN vs redirection
Quand nous voulons bloquer un domaine en utilisant DNS, nous pouvons choisir
entre différentes méthodes, mais les deux plus populaires sont soit de
rediriger la requête DNS vers une adresse IP locale, tel que 127.0.0.1 ou
0.0.0.0, ou de répondre par une définition NXDOMAIN.
NXDOMAIN est une norme de réponse pour un "nom de domaine Intranet ou
Internet non existant".
Si le nom de domaine est incapable d'être résolu en utilisant DNS, une
condition appellée NXDOMAIN est obtenue.
Nous pouvons essayer de résoudre un domaine non existant avec la commande
`host` :
```
$ host a1b7c3n9m3b0.com
Host a1b7c3n9m3b0.com not found: 3(NXDOMAIN)
```
Puisque le nom de domaine "a1b7c3n9m3b0.com" n'est enregistré par personne
(au moins pas durant le temps où j'écris cela), nous obtenons une réponse
"NXDOMAIN".
Nous pouvons aussi utiliser `drill`. L'information pertinente depuis la
sortie de `drill` est le champ `rcode` dans la section "HEADER" :
```
$ drill a1b7c3n9m3b0.com
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 39710
…
```
Ou si vous préférez `dig`, alors l'information pertinente est localisée
dans le champ `status` dans la section "HEADER" :
```
$ dig a1b7c3n9m3b0.com
; <<>> DiG 9.16.8 <<>> +search a1b7c3n9m3b0.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48858
…
```
Utiliser une réponse NXDOMAIN n'est pas seulement la manière correcte de
bloquer un domaine, en accord avec la [RFC8020](https://tools.ietf.org/html/rfc8020),
mais c'est aussi la meilleure manière de le faire puisque une redirection
vers une adresse IP, telle que 127.0.0.1 ou 0.0.0.0 fera simplement que
le client qui initie la requête DNS se parlera à lui-même.
Il se peut que le navigateur réponde avec quelque chose comme :
`Firefox can't establish a connection to the server at 0.0.0.0.`.
Toutefois, puisque l'adresse IP 0.0.0.0 se traduit simplement par notre
machine locale, nous pouvons toujours envoyé un ping à cette adresse, car
elle est synonyme d'un ping à 127.0.0.1 :
```
$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.049 ms
```
Et puisque je recommande que vous utilisiez une réponse NXDOMAIN, c'est
ce que nous allons utiliser dans ce tutoriel.
{{< note tip >}}
Unbound peut gérer des listes énormes de domaines bloqués avec une réponse
NXDOMAIN, mais il ne peut pas gérer de grandes listes de domaines qui ont
besoin d'être redirigés aussi bien.
Si pour certaines raisons, vous devriez insister sur la redirection plutôt
que d'utiliser NXDOMAIN, je vous recommande de paramétrer
[dnsmasq](http://www.thekelleys.org.uk/dnsmasq/doc.html)
avec l'option **--addn-hosts=\**, pour qu'il écoute le port 53 et
qu'il redirige tous les domaines bloqués, pendant qu'il redirige les requêtes
DNS normales vers Unbound. Cela demande de paramétrer Unbound afin d'écouter
sur un port non standard, tel que le port 5353.
Contrairement à Unbound, dnsmasq peut gérer d'énormes listes de redirection
très bien, mais il ne peut gérer de grandes liste de domaines NXDOMAIN
aussi bien, devenant extrêmement lent.
{{}}
### Le problème avec DNS sur HTTPS (DOH)
Avec l'introduction de [DoH (DNS over HTTPS)](https://fr.wikipedia.org/wiki/DNS_over_HTTPS),
le blocage par DNS est devenu beaucoup plus difficile, et, bien que j'ai
un certain respect pour l'idée originale derrière la promotion de DoH du
point de vue de la confidentialité, DoH est mal construit d'un point de
vue de la sécurité, et c'est une **MAUVAISE** approche.
Avec le nombre déjà croissant de serveurs DNS publiques capable de servir
du DNS sur HTTPs, toute application peut maintenant utiliser DoH et
contourner complétement le blocage par DNS au niveau privé et entreprise.
Non seulement cela, mais DoH a ouvert une large porte pour les dévelopeurs
d'application afin de paramétrer leurs propres serveurs DoH et de les
utiliser dans leurs applications au lieu du serveur DNS régulier attaché
au réseau interne.
C'est spécifiquement un problème pour le
[logiciel propriétaire](https://fr.wikipedia.org/wiki/Logiciel_propri%C3%A9taire)
dont nous ne pouvons pas voir le code source, mais dont nous ne pouvons
pas aussi changer les paramétres DoH.
À cause de DoH, nous ne pouvons plus bloquer simplement des domaines, tels
que les publicitaires ou le porno, nous devons aussi commencer à bloquer
les serveurs DoH publiques via le pare-feu.
Toutefois, bien que garder une liste croissante d'un nombre d'adresses IP
de serveurs DoH publique soit assez problèmatique, garder une liste de
serveurs DoH publiques inconnus, qui peuvent être utilisé par du logiciel
propriétaire, tel que du micro-logiciel dans des dispositifs
[IoT](https://fr.wikipedia.org/wiki/Internet_des_objets), est impossible.
DoH est aussi un complet cauchemard pour les entreprises car il rend
basiquement possible de surpasser les paramétres DNS imposés centralement.
Cela rend impossible de fournir des solutions de filtrage, telle que
celle que nous faisons, pour bloquer la publicité et le porno, et rend
impossible pour les administrateurs systèmes de surveiller les paramétres
DNS du système d'exploitation afin de prévenir les attaques de
[manipulation DNS](https://fr.wikipedia.org/wiki/Manipulation_de_l%27espace_des_noms_de_domaine).
Avoir de multiples applications qui ont leur unique paramétre DoH est un
cauchemar.
DoH gène complétement l'analyse réseau et la surveillance du trafic DNS
à des fins de sécurité.
En 2019, Godlua, un bot Linux DDoS, était le premier
[logiciel malveillant](https://fr.wikipedia.org/wiki/Logiciel_malveillant)
vu à [utiliser DoH pour cacher son trafic DNS](https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/).
De plus, et c'est peut-être l'aspect le plus important, DoH **n'empêche
aucunément le suivi des utilisateurs**.
Certaines parties de la connection HTTPS ne sont pas chiffrées, tels que
les [champs SNI](https://fr.wikipedia.org/wiki/Server_Name_Indication)
(mais on y arrive lentement), les [connexions OCSP](https://fr.wikipedia.org/wiki/Online_Certificate_Status_Protocol),
et bien sûr **les adresses IP de destination**, ce qui à mon humble avis
est le point le plus crucial de la communication qui a besoin d'être caché !
Les personnes qui ont vraiment besoin de confidentialité, tels que les
journalistes dans des pays ayant une politique de confidentialité compromise,
ne peuvent faire confiance à DoH !
L'adresse IP du serveur de destination ne peut pas être caché avec DoH,
même si tout le trafic est lui-même chiffré.
Si quelqu'un a vraiment besoin de chiffrer la communication, il a besoin
d'une stratégie complétement différente de DoH.
Cela me fait me demander qui a pensé que DoH était une bonne idée au départ ?!
Ne comprennent-ils pas les bases derrière les communications avec HTTPS,
ou peut-être est-ce l'agenda poussé par quelques entreprises privées de
service DNS, tel que Cloudflare, qui tire profit en collectant davantage
de données utilisateurs ?
Certains fournisseurs de service DNS publique status que d'un point de vue
de la confidentialité, DoH est meilleur que d'autres alternatives, telle
[DoT (DNS over TLS)](https://en.wikipedia.org/wiki/DNS_over_TLS), puisque
les requêtes DNS sont cachées dans le large flux du trafic HTTPS.
Cela donne aux administrateurs réseaux moins de visibilité mais fournit
aux utilisateurs plus de confidentialité.
Ce message est problématique.
Bien qu'il soit vrai que la recherche initiale d'un nom de domaine soit
caché dans le trafic HTTPS, l'adresse IP de destination fournit par le
serveur DoH ne l'est pas.
Quand l'application cliente visite l'adresse IP de destination, les deux
adresses IP, celle de source et celle de destination, sont journalisées
au niveau du FAI (et possiblement à de multiples autres niveaux, aussi bien).
Bien qu'il ne soit pas immédiatement possible de déterminer exactement
quel nom de domaine l'utilisateur essaye d'atteindre, spécifiquement si
le serveur web fait fonctionner de multiples domaines sur la même adresse
IP, ce n'est définitivement pas impossible voire n'est même pas difficile.
{{< note info >}}
Dans l'appendice, vous pouvez trouver un chapitre appellé
{{< anchor "Inspecter DNS sur HTTPS (DOH)" "Inspecter DNS sur HTTPS (DOH)" >}},
dans laquelle nous ferons une démonstration de comment l'adresse IP de
destination est révélée dans la communication DoH.
Vous pouvez aussi trouver un chapitre appellé
{{< anchor "Bloquer DNS sur HTTPS (DOH)" "Bloquer DNS sur HTTPS (DOH)" >}} dans
laquelle nous utilisons le pare-feu PF pour bloquer les serveurs DoH publiques.
{{}}
### Paramétrage d'Unbound
#### Paramétrages de base
Paramètrer Unbound est très facile, car Unbound est fourni avec les meilleurs
paramètres par défaut, mais est aussi très bien documenté.
Avant que nous commencions, je vous recommande de regarder les pages des
manuels OpenBSD pour [unbound](https://man.openbsd.org/unbound),
[unbound-checkconf](https://man.openbsd.org/unbound-checkconf)
et [unbound.conf](https://man.openbsd.org/unbound.conf).
Du fait qu'Unbound soit [chrooté](https://fr.wikipedia.org/wiki/Chroot)
sur OpenBSD, le fichier de configuration `unbound.conf` ne réside pas
dans `/etc`, là où il devrait être normalement, mais à la place réside
dans `/var/unbound/etc/`.
Copiez le fichier de configuration existant d'Unbound :
```
# mv /var/unbound/etc/unbound.conf /var/unbound/etc/unbound.conf.backup
```
Ensuite, utilisez votre éditeur texte favori et créer un nouveau fichier
`/var/unbound/etc/unbound.conf` et remplissez-le avec le contenu suivant :
```
server:
# Logging (default is no).
# Uncomment this section if you want to enable logging.
# Note enabling logging makes the server (significantly) slower.
# verbosity: 2
# log-queries: yes
# log-replies: yes
# log-tag-queryreply: yes
# log-local-actions: yes
interface: 127.0.0.1
interface: 192.168.1.1
interface: 192.168.2.1
interface: 192.168.3.1
# In case you need Unbound to listen on an alternative port, this is the
# syntax:
# interface: 127.0.0.1@5353
# Control who has access.
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse
access-control: 127.0.0.0/8 allow
access-control: ::1 allow
access-control: 192.168.1.0/24 allow
access-control: 192.168.2.0/24 allow
access-control: 192.168.3.0/24 allow
# "id.server" and "hostname.bind" queries are refused.
hide-identity: yes
# "version.server" and "version.bind" queries are refused.
hide-version: yes
# Cache elements are prefetched before they expire to keep the cache up to date.
prefetch: yes
# Our LAN segments.
private-address: 192.168.0.0/16
# We want DNSSEC validation.
auto-trust-anchor-file: "/var/unbound/db/root.key"
# Enable the usage of the unbound-control command.
remote-control:
control-enable: yes
control-interface: /var/run/unbound.sock
```
J'ai commenté les options ci-dessus, mais si vous avez besoin d'explications
plus profondes concernant la configuration, regardez la page du manuel
[unbound.conf](https://man.openbsd.org/unbound.conf).
La journalisation est faite par défaut vers syslog.
Si vous voulez changer cela, vous pouvez créer un fichier log dans le
chroot d'Unbound et ainsi avoir le journal d'Unbound :
```
# mkdir /var/unbound/log
# touch /var/unbound/log/unbound.log
# chown -R root._unbound /var/unbound/log
# chmod -R 774 /var/unbound/log
```
Et, dans le fichier `unbound.conf`, ajoutez les options suivantes vers la
section de journalisation :
```
logfile: "/log/unbound.log"
use-syslog: no
log-time-ascii: yes
```
{{< note info >}}
Nous n'utilisons pas le chemin complet du fichier de log parce qu'Unbound
est chrooté.
Avec l'option `logfile` ci-dessus, le fichier log se retrouve dans
`/var/unbound/log/unbound.log`.
{{}}
Puis, redémarrez Unbound :
```
# rcctl restart unbound
```
Dans les paramétres ci-dessus, j'ai autorisé Unbound à écouter l'interface
loopback (127.0.0.1) en premier afin que les applications réseaux locales
soient capables de faire des recherches si besoin.
Dans le fichier `etc/resolv.conf` de notre routeur OpenBSD, j'ai listé
notre serveur DNS Unbound, car je ne veux rien sur le routeur qui interroge
les serveurs DNS du FAI :
```
nameserver 127.0.0.1
```
Si vous utilisez DHCP sur l'interface externe (l'interface connecté au
modem ou routeur de votre FAI), vous devez vous assurez que [dhclient](https://man.openbsd.org/dhclient)
ne change pas la configuration du fichier `/etc/resolv.conf`.
Éditez le fichier `/etc/dhclient.conf` et ajoutez :
```
supersede domain-name-servers 127.0.0.1;
```
Cela permettra de s'assurer que nous avons notre serveur DNS local listé.
Activez Unbound avec :
```
# rcctl enable unbound
```
Lorsque vous changez la configuration d'Unbound, vous pouvez soit juste
redémarrer Unbound avec :
```
# rcctl restart unbound
```
ou simplement recharger les options de configuration (ce qui purge aussi
le cache) :
```
# unbound-control reload
```
Vous pouvez lister avec quels paramétres Unbound est démarré par la commande
suivante (qui est fourni pour tout service sous OpenBSD) :
```
# rcctl get unbound
```
Si vous voulez avec certaines statitiques des données, vous pouvez exécuter :
```
# unbound-control stats_noreset
thread0.num.queries=2056
thread0.num.queries_ip_ratelimited=0
thread0.num.cachehits=678
thread0.num.cachemiss=1378
thread0.num.prefetch=15
thread0.num.expired=0
…
```
Vous pouvez aussi avoir un dump du cache :
```
# unbound-control dump_cache|less
```
Si vous voulez voir quelles sont les requêtes du serveur de nom Unbound
fait pour un domaine spécifique, vous pouvez faire cela avec :
```
# unbound-control lookup wikipedia.org
```
Si vous voulez purger le cache pour un domaine spécifique, vous pouvez
faire cela avec :
```
# unbound-control flush example.com
```
Prenez le temps de regarder la page du manuel d'[unbound-control](https://man.openbsd.org/unbound-control)
pour les autres options et commandes.
#### Ignorer les réglages TTL ridiculeusement bas
Une chose qui crée une grande nuisance est le paramétrage de certaines
personnes sur des valeurs TTL ridiculeusement basses pour leurs domaines.
Pour certaines raisons, il est presque tendance d'avoir une valeur par
défaut de 60 secondes.
Le problème avec un TTL très bas est que cela rend complétement inutile
le DNS cache.
Une requête utilisera seulement la réponse en cache aussi longtemps que
le TTL ne soit pas expiré.
Même au-travers des RFC qui disent qu'un TTL doit être respecté, de telles
valeurs basses rend le DNS extrêmement inefficace.
Je recommande toutefois que vous surchargiez le paramétrage TTL par celui
d'une heure par défaut.
Une autre amélioration dans la vitesse de requête de DNS est de réduire
la latence en se servant des enregistrements périmés avant de les mettre
à jour d'une autre manière au lieu de faire l'inverse.
```
cache-min-ttl: 3600
serve-expired: yes
```
Un problème théorique avec l'augmentation du TTL est que le domaine pourrait
obtenir une nouvelle adresse IP qui ne peut pas être résolu puisque
l'ancienne entrée est dans le cache.
Toutefois, dans la pratique le risque de fonctionner sur un domaine périmé
est minime et ça vaut la peine d'améliorer l'utilisation du cache en fixant
un TTL d'une heure minimum par défaut.
#### Bloquons certains domaines !
Maintenant, intéressons-nous à la partie du blocage de domaines.
J'ai créé un simple script shell appelé [DNSBlockBuster](https://codeberg.org/unixsheikh/dnsblockbuster)
qui télécharge automatiquement un jeu de fichiers hosts depuis diverses
sources en-ligne, les concaténant ensemble en une seule, la nettoyant,
et convertissant le résultat en une liste de blocage de domaines pour
Unbound et dnsmasq.
Elle bloque principalement les publicités, les sites de porno et de pistage.
Avec DNSBlockBuster, vous avez l'option de créer une liste blanche, si pour
vous l'un des domaines listés dans les fichiers hosts est un faux positif,
et vous pouvez ajouter votre propre liste de blocage dans le cas où vous
voulez bloquer manuellement certains domaines qui ne sont pas listés dans
les fichiers hosts.
Vous pouvez facilement ajouter de nouvelles listes de blocage ou supprimer
l'une des listes de blocage fournies.
Bien sûr, vous n'avez pas besoin d'utiliser mon script, mais je l'utiliserais
dans ce tutoriel.
Actuellement le script créé une énorme liste de domaines avec plus de deux
millions de domaines listés et Unbound prend près de 705 Mo de mémoire au
total quand la liste de blocage est chargée en entier.
Afin d'éviter qu'Unbound tombe en panne lors du chargement de la liste,
éditez `/etc/rc.conf.local` et ajoutez ce qui suit :
```
unbound_timeout=240
```
Puis redémarrez Unbound :
```
# rcctl restart unbound
```
Regardez la section [Usage](https://codeberg.org/unixsheikh/dnsblockbuster#user-content-usage)
dans la documentation de DNSBlockBuster pour savoir comment l'utiliser.
C'est simple et facile.
Une fois que vous avez créé votre liste de blocage pour Unbound, placez
la dans `/var/unbound/etc/` et éditez le fichier de configuration d'Unbound
`/var/unbound/etc/unbound.conf` pour insérer quelque chose comme :
```
include: "/var/unbound/etc/unbound-blocked-hosts.conf"
```
Maintenant rechargez Unbound avec :
```
# unbound-control reload
```
Si vous exécutez la commande `top` dans un autre terminal, vous remarquerez
qu'Unbound consomme pas mal de ressources CPU lors du chargement initial
de la liste.
Remarquez aussi la consommation mémoire.
Vous pouvez maintenant tester notre blocage DNS en faisant une requête
vers un domaine bloqué de la liste :
```
$ drill 3lift.com
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 55906
…
```
Essayez le même avec le serveur DNS de Cloudflare :
```
$ drill 3lift.com @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 48771
…
```
Comme nous pouvons le voir, notre serveur DNS bloque l'accès au domaine
3lift.com en répondant avec un NXDOMAIN, alors que le serveur DNS de
Cloudflare répond avec l'adresse IP correcte.
### Sécurité DNS
La sécurité DNS est un vaste sujet.
Dans cette section, nous allons discuter de certains des sujets qui nous
concernent plus particulièrement à propos de notre propre serveur DNS.
Le protocole DNS n'est pas chiffré et ne tient, par défaut, aucun compte
de la confidentialité, de l'intégrité ou de l'authentification.
Si vous utilisez un réseau non fiable, ou un FAI malveillant, vos requêtes
DNS peuvent être écoutées et les réponses manipulées.
En outre, les FAI peuvent procéder à des détournements de DNS.
#### Détournement de DNS
Le détournement de DNS signifie que les requêtes DNS que vous faites sont
redirigées vers un autre serveur DNS.
C'est typiquement fait en redirigeant tout le trafic sur le port 53 à
destination d'un autre.
Un des manières les plus simples pour déterminer si votre FAI détourne
votre trafic DNS est d'interroger directement un serveur DNS faisant autorité.
Nous pouvons utiliser de multiples outils pour cela.
Dans cet exemple, nous utiliserons en premier `drill`.
Ces options, dans cet exemple, sont les mêmes pour `dig`.
Nous utiliserons encore le domaine "wikipedia.org".
En premier, nous avons besoin d'avoir les serveurs faisant autorité.
Ils apparaîtront dans la section "ANSWER SECTION" :
```
$ drill NS wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 28789
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; wikipedia.org. IN NS
;; ANSWER SECTION:
wikipedia.org. 85948 IN NS ns2.wikimedia.org.
wikipedia.org. 85948 IN NS ns0.wikimedia.org.
wikipedia.org. 85948 IN NS ns1.wikimedia.org.
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 1 msec
;; SERVER: 127.0.0.1
;; WHEN: Thu Nov 5 07:53:19 2020
;; MSG SIZE rcvd: 95
```
Alors nous devons interroger l'un de ses serveurs faisant autorité directement.
Le champ important auquel nous devons faire attention est flags dans le
champ "HEADER".
Pour que la réponse fasse autorité, le drapeau `aa` doit être listé.
```
$ drill @ns1.wikimedia.org wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 57611
;; flags: qr aa rd ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; wikipedia.org. IN A
;; ANSWER SECTION:
wikipedia.org. 600 IN A 91.198.174.192
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 127 msec
;; SERVER: 208.80.153.231
;; WHEN: Thu Nov 5 07:56:10 2020
;; MSG SIZE rcvd: 47
```
Cela montre que la réponse que nous avons n'a pas été détournée puisque
la réponse fait autorité.
Essayons de l'obtenir depuis le serveur DNS publique de Cloudflare avec
la même requête :
```
$ drill @1.1.1.1 wikipedia.org
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 40562
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; wikipedia.org. IN A
;; ANSWER SECTION:
wikipedia.org. 555 IN A 91.198.174.192
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; Query time: 3 msec
;; SERVER: 1.1.1.1
;; WHEN: Thu Nov 5 08:02:58 2020
;; MSG SIZE rcvd: 47
```
Notez que le drapeau `aa` est manquant dans le champ "HEADER".
Cela signifie que la réponse ne fait pas autorité.
Un autre outil simple est [nslookup](https://man.openbsd.org/nslookup).
En premier interrogeons les serveurs de noms faisant autorité :
```
nslookup -querytype=NS wikipedia.org
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
wikipedia.org nameserver = ns1.wikimedia.org.
wikipedia.org nameserver = ns2.wikimedia.org.
wikipedia.org nameserver = ns0.wikimedia.org.
```
Essayons alors d'interroger notre propre serveur DNS pour le domaine :
```
$ nslookup wikipedia.org
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: wikipedia.org
Address: 91.198.174.192
Server: ns2.wikimedia.org
Address: 91.198.174.239#53
Name: wikipedia.org
Address: 91.198.174.192
```
Le message `Non-authoritative` montre clairement que la réponse n'est pas
faite depuis un serveur DNS faisant autorité.
C'est très bien, puisque nous avons interrogé notre propre serveur DNS.
Essayons d'interroger un des serveurs faisant autorité directement :
```
$ nslookup wikipedia.org ns0.wikimedia.org
Server: ns0.wikimedia.org
Address: 208.80.154.238#53
Name: wikipedia.org
Address: 91.198.174.192
```
Le message `Non-authoritative` n'est plus là, la réponse que nous avons
obtenu **faisait autorité**, ce qui signifie que notre requête DNS n'a pas
été détournée.
J'ai maintenant activé un service VPN que je connais pour intercepter les
requêtes DNS afin de protéger les clients contre la [fuite DNS](https://en.wikipedia.org/wiki/DNS_leak)
puis je fais une requête à nouveau vers les serveurs faisant autorité :
```
$ nslookup wikipedia.org ns0.wikimedia.org
Server: ns0.wikimedia.org
Address: 208.80.154.238#53
Non-authoritative answer:
Name: wikipedia.org
Address: 91.198.174.192
Name: wikipedia.org
Address: 2620:0:862:ed1a::1
```
Comme attendu la réponse ne fait pas autorité quand bien même j'ai interrogé
directement le serveur faisant autorité.
Le trafic DNS **a été détourné** et la réponse a été redirigé depuis un
autre serveur DNS inconnu.
Le détournement DNS, qu'il soit effectué par un FAI ou par quelqu'un d'autre,
est hautement problèmatique.
Tout d'abord, nous ne pouvons avoir pleinement confiance aux réponses que
nous obtenons depuis le serveur DNS.
En second, même si la réponse DNS fournit des données non falsifiées,
le trafic DNS a été détourné pour une raison inconnue, qui peut être de
la collecte et de l'enregistrement de données, ou pour une raison
complètement différente.
{{< note info >}}
Certains FAI, tels qu'Optimum Online, Comcast, Time Warner, Cox Communications,
RCN, Rogers, Charter Communications, Verizon, Virgin Media, Frontier Communications,
Bell Sympatico, Airtel, OpenDNS et d'autres ont commencé leurs pratiques
de détournement de DNS sur des noms de domaines inexistants (NXDOMAIN)
pour monétiser l'affichage de publicités.
Le serveur DNS redirigait une requête pour un nom de domaine non existant
vers une fausse adresse IP qui contenait un site web avec publicités.
Je ne sais pas combien de FAI et fournisseurs de service DNS publique le
font encore.
{{}}
##### Prévention contre le détournement de DNS
Si vous avez découvert que votre trafic DNS sur le port 53 est détourné,
vous avez basiquement seulement trois options afin de vous protéger :
1. Si cela vous est possible, changez de FAI !
Votre FAI ne devrait pas détourner votre trafic DNS.
2. Paramétrez votre propre serveur DNS à distance dans un centre d'hébergement
qui ne fait pas de détournement ou ne bloque pas le port 53.
Ensuite, que votre serveur DNS à distance écoute vos connexions DNS sur
un port non standard et rediriger toutes vos requêtes DNS vers votre
serveur DNS à distance.
3. Utilisez un VPN de confiance qui ne détourne pas le trafic DNS, ou s'il
le fait, assurez-vous que vous pouvez faire confiance à leur politique
de non journalisation.
#### Usurpation de DNS
L'usurpation de DNS, aussi appelé empoisonnement du cache DNS, est différent
du détournement de DNS.
Alors que le trafic est redirigé d'une destination vers une autre dans
une attaque de détournement de DNS, c'est la donnée elle-même qui est
manipulée dans une attaque d'usurpation DNS.
Souvent ces deux stratégies d'attaques sont combinées.
Dans une attaque d'usurpation de DNS, la donnée manipulée est introduite
dans le cache du résolveur DNS, résultant que le serveur de nom retourne
un résultat incorrect, e.g. une mauvaise adresse IP.
##### Prévention contre l'usurpation de DNS
Ce type d'attaque peut être atténuée au niveau de la couche transport ou
de la couche application en effectuant une validation de bout en bout une
fois qu'une connexion est établie.
Un exemple courant de cela est l'utilisation de TLS et des signatures digitales.
[DNSSEC](https://fr.wikipedia.org/wiki/Domain_Name_System_Security_Extensions)
utilise des signatures digitales cryptographiques avec un certificat de clé
publique de confiance pour déterminer l'authenticité des données.
DNSSEC peut protéger contre l'usurpation de DNS, toutefois beaucoup
d'administrateurs DNS ne l'ont pas encore implémenté.
À partir de 2020, tous les TLD originaux prennent en charge DNSSEC, comme
le font les TLD de code de pays, mais de nombreux TLD de code de pays ne
le font toujours pas.
## Appendices
### Inspecter DNS sur HTTPS (DOH)
Je veux illustrer le fait que DoH ne fournit pas réellement une véritable
confidentialité autant de l'adresse IP source que celle de destination,
qui peuvent être vues clairement dans la communication HTTPS.
En premier, je m'assure que DoH soit désactivé dans Firefox, sur un des
ordinateurs du LAN pour adultes, et je surveille le trafic sur l'interface
`em1` par l'utilisation de [tcdump](https://man.openbsd.org/tcpdump).
J'ai aussi activé la journalisation dans Unbound, juste pour éviter de
remplir inutilement syslog avec trop de bruits DNS, et j'ai utilisé
[tail](https://man.openbsd.org/tail) pour surveiller le journal.
J'irais sur "wikipedia.org" dans le navigateur et voir ce que révèle la
surveillance sur le routeur.
```
# tcpdump -n -i em1 src host 192.168.1.5 and not arp
tcpdump: listening on em1, link-type EN10MB
23:30:33.494352 192.168.1.5.55724 > 192.168.1.1.53: 58136+ A? wikipedia.org.(31) (DF)
23:30:33.774439 192.168.1.5.58372 > 192.168.1.1.53: 58448+ A? www.wikipedia.org.(35) (DF)
23:30:34.184287 192.168.1.5.46639 > 192.168.1.1.53: 15167+ A? www.wikipedia.org.(35) (DF)
…
```
```
# tail -f /var/unbound/log/unbound.log
Nov 05 23:30:33 unbound[12636:0] query: 192.168.1.5 wikipedia.org. A IN
Nov 05 23:30:33 unbound[12636:0] reply: 192.168.1.5 wikipedia.org. A IN NOERROR 0.097209 0 47
Nov 05 23:30:33 unbound[12636:0] query: 192.168.1.5 www.wikipedia.org. A IN
Nov 05 23:30:33 unbound[12636:0] reply: 192.168.1.5 www.wikipedia.org. A IN NOERROR 0.154989 0 80
Nov 05 23:30:34 unbound[12636:0] query: 192.168.1.5 www.wikipedia.org. A IN
Nov 05 23:30:34 unbound[12636:0] reply: 192.168.1.5 www.wikipedia.org. A IN NOERROR 0.000000 1 80
…
```
Naturellement nous avons vu la requête autant dans le trafic de l'interface
que dans le journal d'Unbound.
J'ai activé alors DoH et désactivé le DNS régulier dans Firefox, en
paramétrant la valeur de `network.trr.mode` à `4`.
J'ai alors changé les `paramétres réseaux` et paramétré Cloudflare en
tant que fournisseur DoH.
{{< note tip >}}
Si vous activez juste DoH via les préférences, Firefox utilisera toujours
le DNS régulier comme solution de repli.
Avant de forcer Firefox à utiliser seulement DoH, vous devez paramétrer
la value de `network.trr.mode`.
Écrivez `about:config` dans la barre d'adresses et pressez la touche
Entrée pour accéder au panneau de configuration caché de Firefox.
Étape 2 : Cherchez le paramétre `network.trr.mode`.
Il contrôle la prise en charge de DoH.
Ce paramétre a 4 valeurs :
1. DoH est désactivé, par défaut
2. DoH est actif, mais Firefox utilise à la fois DoH et le DNS régulier
selon la rapidité de la réponse retournée.
3. DoH est actif, et le DNS régulier fonctionne en repli.
4. DoH est actif, et le DNS régulier est désactivé
5. DoH est désactivé, par choix.
Étape 3 : Cherchez le paramétre `network.trr.bootstrapAddress`.
Il contrôle l'adresse IP numérique de votre serveur DoH.
Entrez la valeur `1.1.1.1` et appuyez sur la touche Entrée.
{{}}
Cette fois, je visiterais "freebsd.org".
```
# tcpdump -n -i em1 src 192.168.1.5 and not arp
tcpdump: listening on em1, link-type EN10MB
00:21:10.944243 192.168.1.5.32856 > 1.1.1.1.443: P 2223446146:2223446202(56) ack 157857007 win 501 (DF)
00:21:10.948719 192.168.1.5.46584 > 96.47.72.84.80: S 922508523:922508523(0) win 64240 (DF)
00:21:11.133801 192.168.1.5.33298 > 96.47.72.84.443: S 3275123911:3275123911(0) win 64240 (DF)
…
```
```
# tail -f /var/unbound/log/unbound.log
Nov 05 23:30:33 unbound[12636:0] query: 192.168.1.5 wikipedia.org. A IN
Nov 05 23:30:33 unbound[12636:0] reply: 192.168.1.5 wikipedia.org. A IN NOERROR 0.097209 0 47
Nov 05 23:30:33 unbound[12636:0] query: 192.168.1.5 www.wikipedia.org. A IN
Nov 05 23:30:33 unbound[12636:0] reply: 192.168.1.5 www.wikipedia.org. A IN NOERROR 0.154989 0 80
Nov 05 23:30:34 unbound[12636:0] query: 192.168.1.5 www.wikipedia.org. A IN
Nov 05 23:30:34 unbound[12636:0] reply: 192.168.1.5 www.wikipedia.org. A IN NOERROR 0.000000 1 80
…
```
Cela révèle, depuis la surveillance de l'interface réseau, qu'une connexion
a été faite vers le serveur DNS de Cloudflare à l'adresse 1.1.1.1 sur le
port 443 (HTTPS) et que nous avons visité l'adresse IP de destination
96.47.72.84 juste après.
Dans le même temps, rien n'est arrivé dans le journal d'Unbound, `tail`
nous montrant juste toujours la requête précédente.
Si nous faisons une requête au DNS régulier sur le serveur, nous pouvons
vérifier que l'adresse IP 96.47.72.84 est bien l'adresse IP de "freebsd.org".
De plus, dans cet exemple spécifique, nous pouvons même accéder au site
web de "freebsd.org" en écrivant juste l'adresse IP de destination
96.47.72.84 dans le champ de la barre d'adresse du navigateur.
Cela démontre que même si DoH bypasse la requête d'un DNS régulier, il
n'est pas capable de cacher l'adresse IP de destination qui est toujours
présente en clair dans le trafic de la communication.
### Bloquer DNS sur HTTPS (DOH)
Auparavant, le script [DNSBlockBuster](https://codeberg.org/unixsheikh/dnsblockbuster)
comportait certains noms de domaines DoH dans la liste, que j'avais ajouté
aléatoirement, mais j'ai depuis supprimé le blocage DoH du serveur DNS, car
il faut vraiment que cela soit géré au niveau du pare-feu.
Bloquer DoH via les noms de domaine n'a pas beaucoup de sens à mon humble
opinion car un nom de domaine peut être cherché en premier lieu.
La plupart des clients qui utilisent DoH ont l'adresse IP de l'hôte du
serveur DoH encodé directement dans leur code source.
J'ai cherché sur de multiples sites sur Internet, mais aucun n'a trouvé
une simple manière de mettre à jour la liste des serveurs publiques DoH,
ainsi j'ai décidé de faire ma propre liste appelée [DoHBlockBuster](https://codeberg.org/unixsheikh/dohblockbuster).
Toutefois c'est une tâche énorme, dont je sais que je n'aurais pas le
temps de tenir à jour à l'avenir, à moins que d'autres personnnes ne s'y
mettent ; alors si vous avez du temps libre, aidez à tenir à jour les
listes (en faisant une demande de retrait ou en m'envoyant un courriel).
En outre, cette liste n'est en aucun cas exhaustive.
Si vous n'utilisez pas IPv6, vous pouvez bloquer tout le trafic IPv6, et
utilisez alors seulement la liste IPv4 de DoHBlockBuster.
Changez le paramétre `pass out`, dans la section "Default protect and block"
de `/etc/pf.conf` en `pass out inet`.
C'est la manière pour permettre seulement le trafic IPv4 sortant, sans
avoir à bloquer spécifiquement les adresses IPv6 relatives à DoH.
Téléchargez les listes depuis [DoHBlockBuster](https://codeberg.org/unixsheikh/dohblockbuster)
et éditez les selon vos besoins et enregistrez les quelque part sur le
disque.
J'ai fait un sous-répertoire à `/etc/pf-block-lists` où j'ai placé toutes
les listes de blocage dont j'ai besoin pour PF.
Créez alors un fichier persistant pour PF dans la section "Tables" de
`/etc/pf.conf` :
```
# Public DoH servers.
table persist file "/etc/pf-block-lists/dohblockbuster-ipv4.txt"
```
Si vous avez besoin d'IPv6, ajoutez alors cela aussi :
```
table persist file "/etc/pf-block-lists/dohblockbuster-ipv4.txt" file "/etc/pf-block-lists/dohblockbuster-ipv6.txt"
```
Et, alors ajoutez un `block` à la section "Protect and block by default"
du pare-feu :
```
# Let's block DoH.
block in quick on { $g_lan $c_lan $dmz } to
```
Rechargez PF :
```
# pfctl -f /etc/pf.conf
```
Vérifiez la liste avec :
```
# pfctl -vvt block_doh -T show
```
Si - après quelques temps - vous voulez voir quelles adresses IP sont
actuellement bloquées, vous pouvez filtrer la sortie :
```
# pfctl -vvt block_doh -T show | awk '/\[/ {p+=$4; b+=$6} END {print p, b}'
```
Comme mentionné précédemment, cette solution ne prend pas en considération
les serveurs DoH inconnus.
De plus afin que la liste soit efficace, elle a besoin d'être tenue à jour.
### Ajouter l'option domain-name à DHCP et utiliser un FQDN
Si nous paramétrons notre réseau de telle manière que tous les ordinateurs
et dispositifs aient leurs adresses IP fixes et noms d'hôtes, beaucoup
d'outils ne fonctionneront pas nativement avec ces noms d'hôtes sans ajouter
un nom de domaine au serveur DNS.
Cela est dû à des outils tel que `host` qui s'attend à ce que la recherche
vers un nom d'hôte soit
[un nom de domaine pleinement qualifié (FQDN)](https://fr.wikipedia.org/wiki/Fully_qualified_domain_name).
Disons que j'ai paramétré un ordinateur sur mon LAN ayant pour nom d'hôte
"foo" et l'adresse IP fixée à 192.168.1.7.
Je ne me souviens peut être pas que "foo" est l'ordinateur avec telle
adresse, ou je ne me souviens pas quel hôte a l'adresse IP 192.168.1.7
associée.
Avec un FQDN, nous pouvons faire une recherche telle que :
```
$ host foo.example.com
foo.example.com has address 192.168.1.7
```
Alors nous pouvons faire :
```
# host 192.168.1.7
7.1.168.192.in-addr.arpa domain name pointer foo.example.com
```
Toutefois, il est ennuyeux de devoir écrire le nom de domaine complet à
chaque fois.
Si nous ajoutons l'option [domain-name](https://man.openbsd.org/dhcp-options#option~24)
à `/etc/resolv.conf` le nom de domaine sera automatiquement ajouté.
Ainsi, nous pouvons faire juste cela :
```
$ host foo
foo.example.com has address 192.168.1.7
```
Certaines personnes recommandent d'enregistrer un nom de domaine et de
l'utiliser en interne sur votre LAN, et bien que ce soit certainement
fonctionnel, ce n'est pas intéressant du tout.
Pour l'utilisation à la maison, vous pouvez utilisez les TLD `.intranet`,
`.home` ou `.lan`, en accord avec la
[RFC 6762](https://tools.ietf.org/html/rfc6762#appendix-G) sans aucun
problème.
Toutefois, n'utilisez pas `.local`.
Démarrons en faisant quelques changements dans la configuration de `/etc/dhcpd.conf`.
Juste pour faire simple, j'utiliserais le serveur web de notre LAN publique
en exemple, mais vous pouvez étendre cela à tout segment où vous le désirez,
et vous pouvez aussi l'utiliser sur plusieurs segments si besoin.
Dans notre paramétrage actuel, nous avons déjà le domaine `example.com`
attaché à notre serveur web ainsi nous pouvons juste l'utiliser.
Mais si vous n'avez pas de serveur publique qui a un réel nom de domaine,
changez-le juste par quelque chose comme `net.home`.
J'ai changé le nom de notre serveur web par "lilo" (oui, de Lilo & Stitch,
parce que c'est plus cool que "Luke" ou "Yoda" !).
```
subnet 192.168.1.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.1.1;
option domain-name "example.com";
option routers 192.168.1.1;
range 192.168.1.10 192.168.1.254;
}
subnet 192.168.2.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.2.1;
option domain-name "example.com";
option routers 192.168.2.1;
range 192.168.2.10 192.168.2.254;
}
subnet 192.168.3.0 netmask 255.255.255.0 {
option domain-name-servers 192.168.3.1;
option domain-name "example.com";
option routers 192.168.3.1;
range 192.168.3.10 192.168.3.254;
host lilo.example.com {
fixed-address 191.168.3.2;
hardware ethernet 61:20:42:39:61:AF;
option host-name "lilo";
}
}
```
Si vous préférez utiliser de multiples domaines plutôt qu'un seul, dites-vous
que `example.com` est pour votre développement web professionnel, et que
`net.home` pour votre LAN privé, vous pouvez faire une [recherche de domaine](https://en.wikipedia.org/wiki/Search_domain)
avec l'option `domain-search` dans `/etc/dhcpd.conf` au lieu de l'option
`domain-name`.
La différence entre les deux est qu'avec `domain-name`, seulement un seul
domaine est ajouté, alors qu'avec l'option `domain-search`, de multiples
domaines peuvent être ajoutés et sont alors "cherchés" un par un jusqu'à
ce que l'hôte soit trouvé.
L'option `domain-search` ressemble à ceci :
```
option domain-search "example.com", "net.home"
```
Alors nous avons besoin de paramétrer Unbound pour gérer nos adresses IP
fixes.
Dans cet exemple, nous avons seulement le serveur web, mais nous pouvons
utiliser autant d'hôtes que nécessaires.
Vous pouvez juste éditer le fichier de configuration principale d'Unbound,
mais je préfére mettre cela dans un fichier séparé et l'inclure dans le
fichier principal.
Créez un nouveau fichier appelé tel que `/var/unbound/etc/unbound-local.conf`,
par exemple, et paramétrez vos hôtes :
```
local-data: "lilo.example.com IN A 192.168.3.2"
local-data-ptr: "192.168.3.2 lilo.example.com"
```
Ou, si vous utilisez la version `net.home` :
```
local-data: "lilo.net.home IN A 192.168.3.2"
local-data-ptr: "192.168.3.2 lilo.net.home"
```
Notez comment l'adresse IP dans le champ `local-data-ptr` est retourné,
ce qui n'est pas une erreur.
Ajoutez alors ce qui suit à notre `/var/unbound/etc/unbound.conf` :
```
private-address: 192.168.0.0/16
private-domain: example.com # Use net.home instead if you need that.
include: "/var/unbound/etc/unbound-local.conf"
```
Redémarrez dhcpd et Unbound :
```
# rcctl restart dhcpd
# rcctl restart unbound
```
Si vous retirez le câble Ethernet de l'un des ordinateurs connectés à l'un
des LAN et le connectez à nouveau, vous serez notifié que `/etc/resolv.conf`
a ajouté l'option `domain` :
```
domain example.com
nameserver 192.168.1.1
```
Vous pouvez étendre cet exemple ci-dessus à de multiples domaines et de
multiples dans tous les segments.
### Ajouter pf-badhost
Lorsque vous avez paramétré votre routeur OpenBSD, je vous encourage
fortement à paramétrer [pf-badhost](https://www.geoghegan.ca/pfbadhost.html) !
pf-badhost est un script de sécurité léger fait par [Jordan Geoghegan](https://www.geoghegan.ca/about.html)
qui bloque les plus grandes choses irritantes d'Internet.
Les désagréments tels les brute-forceurs SSH et SMTP sont largement éliminés
par ce script.
pf-badhost ajoute périodiqument des addresses IP depuis des bases de données
de spammeurs d'IP bien connus, tel Spamhaus, Firehol, Emerging Threats
and Binary Defense, où ces mauvaises adressses IP sont fréquemment
journalisées.
pf-badhost les ajoute alors aux adresses IP collectées vers le pare-feu
PF dans une table qui est bloquée par défaut.
### Lectures recommandées
- [OpenBSD PF - User's Guide](https://www.openbsd.org/faq/pf/index.html)
de la FAQ d'OpenBSD *(et sa version FR : [Guide de l'Utilisateur PF](https://wiki.openbsd.fr.eu.org/doku.php/openbsd.org/faq/pf/start) officieuse)*
- [Absolute OpenBSD, 2nd edition](https://mwl.io/nonfiction/os#ao2e) de
Michael Warren Lucas.
Certaines syntaxes de PF ont déjà changées depuis que Michael a écrit le
livre, mais il est toujours très utile.
- [Networking for System Administrators](https://mwl.io/nonfiction/networking#n4sa)
de Michael Warren Lucas.
- [OpenBSD and You](https://mwl.io/nonfiction/networking#n4sa)
- [Stop using ridiculously low DNS TTLs](https://blog.apnic.net/2019/11/12/stop-using-ridiculously-low-dns-ttls/)
### Comment contribuer à ce guide ?
Veuillez considérer de contribuer si vous avez n'importe quel commentaire,
correction, ou changement que vous considéré comme approprié.
- Faites un clone sur [Github](https://github.com/unixsheikh/openbsd-router-guide)
- Soumettez un PR pour examen
Vous pouvez aussi juste envoyer un [courriel](https://www.unixsheikh.com/contact.html).
### Traductions de ce guide
Veuillez noter que les traductions listées ici sont commitées par d'autres
personnes contribuant généreusement à ce guide. De fait, je ne suis pas
responsable de garder à jour ces traductions.
- [Français](https://doc.huc.fr.eu.org/fr/trad/unixsheikh.com/guide-du-routeur-openbsd/)
---
Créé et maintenu par
[Unix Sheikh](https://unixsheikh.com/)
Le [Guide du Routeur OpenBSD](https://openbsdrouterguide.net/)
est sous licence [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/).
Si vous trouvez ce contenu utile, soutenez-moi sur [Patreon](https://patreon.com/unixsheikh).
---
#### Contribuer à la version FR
Cette version traduite du Guide du Routeur OpenBSD est faite par [mes soins](https://huc.fr.eu.org).
Vous pouvez contribuer au-travers de mon dépôt [Framagit.org](https://framagit.org/sh-web/hugo/doc.huc.fr.eu.org/raw/master/content/fr/trad/unixsheikh.com/Guide-du-Routeur-OpenBSD.md).
Par facilité, cette traduction est placée aussi sous licence [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/).
Vous pouvez soutenir mon effort de traduction en me payant un {{< inside "don" "bon café à l'italienne comme je les <3" >}}… :D
---