Rechercher

1.7. Configuration des zones de politique de réponse dans BIND pour remplacer les enregistrements DNS

download PDF

En utilisant le blocage et le filtrage DNS, les administrateurs peuvent réécrire une réponse DNS pour bloquer l'accès à certains domaines ou hôtes. Dans BIND, les zones de politique de réponse (RPZ) offrent cette fonctionnalité. Vous pouvez configurer différentes actions pour les entrées bloquées, comme renvoyer une erreur NXDOMAIN ou ne pas répondre à la requête.

Si vous disposez de plusieurs serveurs DNS dans votre environnement, utilisez cette procédure pour configurer le RPZ sur le serveur principal, puis configurez les transferts de zone pour rendre le RPZ disponible sur vos serveurs secondaires.

Conditions préalables

  • BIND est déjà configuré, par exemple, en tant que serveur de noms avec mise en cache.
  • Le service named ou named-chroot est en cours d'exécution.

Procédure

  1. Modifiez le fichier /etc/named.conf et effectuez les changements suivants :

    1. Ajouter une définition response-policy à la déclaration options:

      options {
          ...
      
          response-policy {
              zone "rpz.local";
          };
      
          ...
      }

      Vous pouvez définir un nom personnalisé pour la zone de protection contre les incendies dans la déclaration zone sur response-policy. Cependant, vous devez utiliser le même nom dans la définition de la zone à l'étape suivante.

    2. Ajoutez une définition zone pour la ZPR que vous avez définie à l'étape précédente :

      zone "rpz.local" {
          type master;
          file "rpz.local";
          allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
          allow-transfer { none; };
      };

      Ces paramètres sont les suivants :

      • Ce serveur est le serveur primaire (type master) de la ZPR nommée rpz.local.
      • Le fichier /var/named/rpz.local est le fichier de zone. Si vous définissez un chemin d'accès relatif, comme dans cet exemple, ce chemin d'accès est relatif au répertoire que vous avez défini dans directory dans la déclaration options.
      • Tous les hôtes définis dans allow-query peuvent interroger cette zone d'accès public. Vous pouvez également spécifier des plages d'adresses IP ou des surnoms de liste de contrôle d'accès (ACL) BIND pour limiter l'accès.
      • Aucun hôte ne peut transférer la zone. N'autorisez les transferts de zone que lorsque vous configurez des serveurs secondaires et uniquement pour les adresses IP des serveurs secondaires.
  2. Vérifier la syntaxe du fichier /etc/named.conf:

    # named-checkconf

    Si la commande n'affiche aucune sortie, la syntaxe est correcte.

  3. Créez le fichier /var/named/rpz.local, par exemple, avec le contenu suivant :

    $TTL 10m
    @ IN SOA ns1.example.com. hostmaster.example.com. (
                              2022070601 ; serial number
                              1h         ; refresh period
                              1m         ; retry period
                              3d         ; expire time
                              1m )       ; minimum TTL
    
                     IN NS    ns1.example.com.
    
    example.org      IN CNAME .
    *.example.org    IN CNAME .
    example.net      IN CNAME rpz-drop.
    *.example.net    IN CNAME rpz-drop.

    Ce fichier de zone :

    • Définit la valeur par défaut du time-to-live (TTL) pour les enregistrements de ressources à 10 minutes. Sans suffixe temporel, tel que h pour heure, BIND interprète la valeur en secondes.
    • Contient l'enregistrement de ressource de début d'autorité (SOA) requis avec des détails sur la zone.
    • Définit ns1.example.com comme serveur DNS faisant autorité pour cette zone. Pour être fonctionnelle, une zone nécessite au moins un enregistrement de serveur de noms (NS). Toutefois, pour être conforme à la RFC 1912, il faut au moins deux serveurs de noms.
    • Renvoyer une erreur NXDOMAIN pour les requêtes adressées à example.org et aux hôtes de ce domaine.
    • Abandonner les requêtes vers example.net et les hôtes de ce domaine.

    Pour une liste complète d'actions et d'exemples, voir le projet de l'IETF : DNS Response Policy Zones (RPZ).

  4. Vérifier la syntaxe du fichier /var/named/rpz.local:

    # named-checkzone rpz.local /var/named/rpz.local
    zone rpz.local/IN: loaded serial 2022070601
    OK
  5. Recharger BIND :

    # systemctl reload named

    Si vous exécutez BIND dans un environnement change-root, utilisez la commande systemctl reload named-chroot pour recharger le service.

Vérification

  1. Tentative de résolution d'un hôte dans example.org, qui est configuré dans le RPZ pour renvoyer une erreur NXDOMAIN:

    # dig @localhost www.example.org
    ...
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30286
    ...

    Cet exemple suppose que BIND fonctionne sur le même hôte et répond aux requêtes sur l'interface localhost.

  2. Tentative de résolution d'un hôte dans le domaine example.net, qui est configuré dans le RPZ pour rejeter les requêtes :

    # dig @localhost www.example.net
    ...
    ;; connection timed out; no servers could be reached
    ...
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.