Guide du Routeur OpenBSD

Article publié, le et modifié le
79 minute(s) de lecture

Cet article contient 16687 mots.
Source brute de l'article : MD

Guide du Routeur OpenBSD

Pare-feu segmentant un réseau, avec DHCP, DNS (Unbound), blocage de domaine et bien plus encore.

  • OpenBSD : 6.8 - Version : 1.4.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 plus.

Nous commencerons par paramétrer les segments réseaux (LAN) par trois réseaux séparés, un pour les adultes, un pour les enfants et un pour les serveurs face à Internet, 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 autres sites sur Internet. Le routeur OpenBSD peut aussi être utilisé dans de petites ou moyennes entreprises.

Pourquoi un pare-feu ?

Peu importe comment vous vous connectez à l’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 zombies, tel que le fait le logiciel malveillant Mirai. De nombreux modems et routeurs grand public sont à blâmer à propos de certaines attaques par déni de service de grande envergure (DOS)

Un pare-feu entre vous et le modem, 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 ; vous ne pouvez pas faire confiant à l’équipement de votre FAI.

C’est toujours 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.

Info

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 qui est fournie avec un processeur Intel Celeron Quad-Cœur.

ASRock Q1900DC-ITX
ASRock Q1900DC-ITX

Je l’admet, c’est une carte-mère assez “pourrie”, mais elle fait le boulot et j’ai de nombreuses solutions très solide qui fonctionnent depuis de nombreuses années sur des réseaux Gigabit avec saturation complète et pare-feu, DNS, faisant des “heures supplémentaires” où le CPU ne transpire 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 c’est juste un exemple, j’ai utilisé de nombreuses autres carte-mères bon marché aussi bien.

Info

J’ai aussi utilisé l’ASRock Q1900-ITX (qui est fournie sans la prise jack DC-In) combinée à un PicoPSU.

PicoPSU
PicoPSU

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. Tous 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é, tel que :

Quad NIC Intel
Quad NIC Intel

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, 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, mais OpenBSD 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 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 tourner une machine virtuelle avant ou de voir si vous avez du matériel inutilisé et pris en charge avec lequel vous pourriez jouer. 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, regardez les différentes pages de manuels à propos des différents logiciels que vous utilisez.

Un autre endroit vraiment utile où trouver des informations générales à propos d’OpenBSD sont les archives des listes de diffusions d’OpenBSD. Aussi assurez-vous de rester à jour des informations pertinentes en souscrivant à la liste de diffusion des Annonces et avis de sécurité.

Enfin, mais pas des moindres, veuillez considérer de soutenir OpenBSD ! Même si vous n’utilisez pas quotidiennement OpenBSD, vous utilisez peut-être déjà OpenSSH 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 grands 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

Info

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 allons utiliser 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 cela ; vous devez juste vous assurez d’avoir assez de ROM et de slot PCI 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
                    ISP Modem (WAN)
                      10.24.0.23
                          |
                       OpenBSD
                      10.24.0.50
                  (router/firewall)
                          |
     -------------------------------------------
     |                    |                    |
    NIC1                 NIC2                 NIC3
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
     |  Grown-up PC       |  Child PC1         |  Public web server
                          |
                          -- 192.168.2.x
                          |  Child PC2

Les adresses IP qui commencent par 10.24.0 sont n’importe quelle adresse IP que le routeur ou modem de votre FAI vous donnera ; 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.

Info

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. Prenez aussi le temps de lire la section réseau de la FAQ d’OpenBSD.

Puisque j’utilise Intel, le pilote 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 avec emX où X est le numéro actuel du port sur 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, avant 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 étant no carrier dans le champ status alors qu’un port avec un câble attaché sera listé en active. Tel que :

# ifconfig
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr a0:36:9f:a1:66:b9
        index 2 priority 0 llprio 3
        media: Ethernet autoselect (none)
        status: active
em2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 illustré précédemment.

# 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 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. Vous n’avez pas besoin de /etc/mygate si votre IP est fournie par le modem, routeur de votre FAI via DHCP. Si vous utilisez la directive dhcp dans n’importe quel hostname.ifX alors l’entrée dans /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 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 que nous exécuterons pour nos différents PC et dispositifs attachés aux différents LAN. Avant assurons-nous de lire et les comprendre les différentes options de la page du manuel dhcp.conf. Prenons aussi le temps de regarder la page de manuel dhcp-options à propos des options que prend en charge dhcpd.

Nous avons une option pour cacher des adresses IP à de spécifiques PC ou dispositifs 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, tel un serveur web. Nous pouvons cacher une adresse IP spécifique vers un PC spécifique via l’adresse MAC 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 la machine agissant en tant que notre serveur web sur le LAN publique a obtenu une adresse IP fixe et un nom d’hôte fixé.

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 et juste avoir 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;
}

Alors nous avons juste besoin de nous assurer d’activer et de démarrer le service dhcpd :

# rcctl enable dhcpd
# rcctl start dhcpd
Info

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. 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.

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 subséquents sont automatiquement alloués et tout paquet imposteur sera automatiquement rejeté. Si une nouvelle session est bloquée, aucun des paquets subsé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és 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 est le système de pare-feu d’OpenBSD pour le filtrage du trafic TCP/IP et faisant du 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 et la page du manuel 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 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 PF. 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.

Éclaircissements

Je tiens à démarrer en clarifiant certains des paramètres communs par défaut et des mots clés dans PF.

Le format est que nous filtrons soit sur la destination :

from source IP to destination IP [on]  port

Soit que nous filtrons sur la source :

from source IP [on] port to destination

Veuillez noter que la partie [on] n’est pas une part 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 ultérieures. 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 à destination, 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 tels 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 TCP et UDP.
  • in et out

    • C’est l’une des parties les plus faciles à se tromper : la direction du trafic. Un paquet entre ou sort toujours par le port ou 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 aucun 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 du 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, du port, et 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 $p_lan 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 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 de PF antispoof et scrub 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 et cherchez le texte “Ports and ranges of ports are specified using these operators”.
Attention

Nom de domaine ou résolution de nom 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 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. De plus, 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" # External NIC connected to the ISP modem (Internet).
g_lan="em1"  # Grown-ups LAN.
c_lan="em2"  # Children's LAN.
p_lan="em3"  # Public LAN.

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
#---------------------------------#

# This is a table of non-routable private addresses.
table <martians> { 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 }
Attention

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
match in all scrub (max-mss 1440)

# Spoofing protection for all interfaces.
antispoof quick for { $g_lan $c_lan $p_lan }
block in from no-route
block in quick from urpf-failed

# Block non-routable private addresses.
# We use the "quick" parameter here to make this rule the last.
block in quick on $ext_if from <martians> to any
block return out quick on $ext_if from any to <martians>

# Default blocking all traffic in on all LAN NICs from any PC or device.
block return in on { $g_lan $c_lan $p_lan }

# Default blocking all traffic in on the external interface from the Internet.
# Let's log that too.
block drop in log on $ext_if

# Allow 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
pass in on $ext_if inet proto icmp icmp-type { 3 code 4, 11 code 0}

# Default allow all NICs to pass out data through the Ethernet port.
pass out inet

scrub active un “nettoyage” du contenu des paquets, permettant aux paquets fragmentés d’être assemblés. scrub fournit aussi certaines protections contre certaines formes d’attaques basées sur une gestion incorrecte des fragments de paquets.

Le critère antispoof est une protection très importante. L’usurpation est quand quelqu’un fausse une adresse IP. Le critère antispoof s’étend à un ensemble de règles de filtrage qui empêcheront tout trafic avec une IP source venant du réseau, directement connectée à l’interface spécifiée, d’entrer dans le système par tout autre interface. C’est ce qu’on appelle parfois “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.

Attention

Les adresses IP de la macro martians sont constituées des adresses qui ne doivent pas être utilisées sur Internet, selon la RFC1918. Le trafic venant de ou allant vers de telles adresses doivent être supprimés sur l’interface externe des routeurs.

Nous allons permettre ICMP 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 clandestins, le ping sweep, le ping flood, le tunnel d’ICMP, et la redirection d’ICMP. 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ées 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 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 les redirections ICMP. La redirection ICMP est utilisé 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 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.

Si vous souhaitez toujours bloquer complètement ICMP pour certaines raisons, enlevez simplement la 4ème règle après le commentaire “Allow ICMP”.

Maintenant paramétrons le segment LAN pour les adultes de la maison.

#---------------------------------#
# Grown-ups LAN Setup
#---------------------------------#

# Allow any PC on the grown-ups LAN to send data in through the NICs Ethernet
# port.
pass in on $g_lan

# Always block DNS queries not addressed to our DNS server.
block return in quick on $g_lan proto { udp tcp } to ! $g_lan port { 53 853 }

# Block the network printer from "phoning home".
block in quick on $g_lan from 192.168.1.8

Dans cet exemple, nous avons une imprimante réseau attachée au réseau des adultes dont nous ne voulons pas l’accès à 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.

Info
Info

Le réseau LAN pour les enfants est très similaire (un paramétrage plus restreint est démontré dans la section liste blanche pour les enfants .

#---------------------------------#
# Children's LAN Setup
#---------------------------------#

# Allow any PC on the children's LAN to send data in through the NICs Ethernet
# port.
pass in on $c_lan

# 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 }

Ensuite, nous nous occupons du LAN avec un serveur web publique. Puisque nous avons un serveur web publique, nous paramétrons un couple de restrictions. Si jamais 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.

Info
#---------------------------------#
# Public LAN Setup
#---------------------------------#

# Allow access to DHCP.
pass in on $p_lan inet proto udp from any port 67

# Allow access to the Internet by removing the comment.
# This rule will also block access to our two other segments, the grown-ups LAN
# and the children's LAN.
# pass in on $p_lan to { ! 192.168.1.0/24 ! 192.168.2.0/24 }

# Always block DNS queries not addressed to our DNS server.
block return in quick on $p_lan proto { udp tcp} to ! $p_lan port { 53 853 }

Dans ce paramétrage, la seule chose que le serveur web peut faire est d’avoir une adresse IP depuis le routeur. Il ne peut faire de ping ou avoir un autre contact depuis une autre machine sur notre réseau interne, et il ne peut avoir accès à Internet à moins que le commentaire soit supprimé de la règle pass in on $p_lan to { ! 192.168.1.0/24 ! 192.168.2.0/24 }.

Ces restrictions ne signifient pas que le serveur web ne peut pas répondre à des requêtes entrantes. La raison de cela est que nous ajoutons une règle dans la section de redirection qui permet aux clients sur Internet d’accéder à notre serveur web publique, quand la réponse venant du serveur web devient une partie de la connexion établie par une connexion originalement établie d’un client extérieur, auquel le serveur web aura le droit de répondre.

Maintenant, nous allons nous occupons 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 $p_lan: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 pour adultes demandera une page web de certains sites sur Internet, la réponse venant du serveur web depuis Internet sera routé par l’interface externe vers l’interface interne du LAN pour 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 le LAN publique. 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
Attention

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) :

#---------------------------------#
# Children's LAN Setup
#---------------------------------#

# Allow any PC on the children's LAN to only reach x.x.x.x.
pass in on $c_lan to x.x.x.x

# 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 }

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
#---------------------------------#

# This is a table of non-routable private addresses.
table <martians> { 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 }

# Whitelist for the children.
table <whitelist> { x.x.x.x y.y.y.y z.z.z.z }

Et ensuite dans la section pour enfants :

#---------------------------------#
# Children's LAN Setup
#---------------------------------#

# Allow any PC on the children's LAN to only access whitelisted IPs.
pass in on $c_lan to <whitelist>

# 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 }

Il n’est pas toujours possible d’avoir toutes les adresses IP dans une liste blanche en une fois, mais la surveillance réseau, en utilisant e.g. tcpdump, quand le jeu essaye d’accéder au serveur, vous pouvez établir une liste, bit après bit.

Utilisation d’une table persistante

Une autre approche pour collecter les IP est d’utiliser une table persistante 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 <whitelist> 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 <whitelist>

Alors, dans /etc/rc.local, nous pouvons ajouter la commande suivante :

pfctl -t whitelist -T add foo.bar

foo.bar 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 foo.bar

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

Dans l’exemple ci-dessus, j’ai utilisé les adresses IP de yahoo.com

Vous pouvez éventuellement ajouter toutes les adresses IP que vous collectez (avant qu’elles soient purgées) dans un fichier physique afin que l’option persist prenne en entrée ce fichier, tel que :

table <whitelist> persist file "/etc/pf-whitelist.txt"
Info

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 Surveillance

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 <mss 1460> [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 <mss 1460,nop,wscale 2,nop,nop,sackOK> (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) est utilisé pour traduire un nom de domaine dans une adresse IP ou vice-versa. Par exemple, quand vous écrivez 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 stockeur 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.
Info

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, 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) 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 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 pour amorcer cette liste initiale d’adresses des serveurs racines. Pour beaucoup de logiciels, dont Unbound, cette liste est intégrée à l’intérieur du logiciel.

Sur la base de données de la zone racine, 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.

Info

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 ou 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 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).

Info

Je vous présente Unbound

Unbound 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 Transfert 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é.

Astuce
Attention

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 (sur des systèmes d’exploitation de type UNIX)
  3. Unbound reçoit la requête et en premier cherche “wikipedia.or” 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 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
Info

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, 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.

Info

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, 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.

Astuce

Le problème avec DNS sur HTTPS (DOH)

Avec l’introduction de DoH (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 DoH, 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 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, est impossible.

DoH est aussi un complet cauchermar 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. 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 vu à utiliser DoH pour cacher son trafic DNS.

De plus, et 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 (mais on y arrive lentement), les connexions OCSP, 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), 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 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és 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.

Info

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, unbound-checkconf et unbound.conf.

Du fait qu’Unbound soit chrooté dans 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

Puis, 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: 127.0.0.0/8 allow
    access-control: ::0/0 refuse
    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.

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
Info

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 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 assure que nous avons juste 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

Prenez le temps de regarder la page du manuel d’unbound-control pour les autres options et commandes.

Bloquons certains domaines !

Maintenant, intéressons-nous à la partie du blocage de domaines.

J’ai créé un simple script shell appelé 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 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 bloque 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. 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é.

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 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.

Info
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 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 dont le trafic est surveillé sur l’interface em1 par l’usage de tcdump. 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 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 mis Cloudflare en tant que fournisseur DoH.

Astuce

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 <mss 1460,sackOK,timestamp 1673624773 0,nop,wscale 7> (DF)
00:21:11.133801 192.168.1.5.33298 > 96.47.72.84.443: S 3275123911:3275123911(0) win 64240 <mss 1460,sackOK,timestamp 1673624958 0,nop,wscale 7> (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 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. 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.

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 <block_doh> persist file "/etc/pf-block-lists/dohblockbuster-ipv4.txt"

Si vous avez besoin d’IPv6, ajoutez alors cela aussi :

table <block_doh> 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 $p_lan } to <block_doh>

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}'

Ainsi que 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).

Disons que j’ai paramétré un ordinateur sur mon LAN ayant “foo” pour nom d’hôte 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 à /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 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” !).

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 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.

Lectures recommandées

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 Coderberg
  • Soumettez un PR pour examen

Vous pouvez aussi juste envoyer un courriel.

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.


Créé et maintenu par

Unix Sheikh

Le Guide du Routeur OpenBSD est sous licence Creative Commons Attribution 4.0 International.

Si vous trouvez ce contenu utile, soutenez-moi sur Patreon.


Contribuer à la version FR

Cette version traduite du Guide du Routeur OpenBSD est faite par mes soins.

Vous pouvez contribuer au-travers de mon dépôt Framagit.org.

Par facilité, cette traduction est placée aussi sous licence Creative Commons Attribution 4.0 International.

Vous pouvez soutenir mon effort de traduction en me payant un bon café à l'italienne comme je les <3… :D