Présentation
Dans cet article pratique, nous vous guiderons dans l'installation d'un serveur DNS faisant autorité BIND9 sécurisé sur CentOS 7
Qu'est-ce que BIND ?
BIND est un logiciel open source qui implémente les protocoles DNS (Domain Name System) pour Internet. Il s'agit d'une implémentation de référence de ces protocoles, mais il s'agit également d'un logiciel de production, adapté à une utilisation dans des applications à haut volume et à haute fiabilité.
– ISC (Internet Systems Consortium)
Aperçu des étapes de configuration
- Préparation de base du serveur.
- Installation des progiciels BIND.
- Configuration des progiciels BIND.
- Ajout d'une zone de test (domaine)
- Test de votre serveur DNS
Prérequis
Avant de commencer cet article pratique, vous devez d'abord vous assurer que ces conditions préalables sont remplies.
– Serveur CentOS 7 – Si vous n'avez pas de serveur disponible, vous pouvez en créer un via notre page de services d'hébergement VPS.
– Votre éditeur de texte préféré installé – Nous utiliserons nano dans ce tutoriel.
.
1 – Préparation de base du serveur
Tout d'abord, assurez-vous que vous êtes connecté en tant que compte d'utilisateur root.
sudo su -
Ensuite, nous allons nous assurer que le système d'exploitation principal est entièrement mis à jour.
yum update -y
Maintenant que votre système est entièrement mis à jour, nous allons mettre à jour le pare-feu (activé par défaut ) pour permettre au DNS (Port TCP 53 / Port UDP 53) d'accéder à votre serveur.
firewall-cmd --permanent --zone public --add-port 53/tcp firewall-cmd --permanent --zone public --add-port 53/udp firewall-cmd --reload
2 - Installation des packages logiciels DNS BIND
Nous sommes maintenant prêts à installer les packages logiciels BIND sur votre serveur.
yum install -y bind bind-utils bind-chroot
- lier : Le serveur DNS (Domain Name System) de Berkeley Internet Name Domain (BIND)
- bind-utils : Utilitaires pour interroger les serveurs de noms DNS
- lier-chroot : Un environnement d'exécution chroot pour le serveur DNS ISC BIND
Maintenant que vous avez installé les packages logiciels BIND requis, nous sommes prêts à démarrer les services BIND et à les configurer pour qu'ils démarrent automatiquement lors du redémarrage du serveur.
systemctl start named systemctl enable named
.
3 - Configuration du serveur DNS BIND
Au démarrage du serveur DNS BIND, le paquet chroot monte automatiquement tous les fichiers de configuration dans le /var/named/chroot répertoire de votre serveur. Lorsque vous exécutez BIND (ou tout autre processus) dans une prison chroot, le processus est tout simplement incapable de voir une partie du système de fichiers en dehors de la prison.
Pour référence, le répertoire de base dans lequel vous travaillerez pour toutes les configurations BIND est /var/named/chroot
Passons d'abord à ce répertoire pour le reste de ces étapes.
cd /var/named/chroot
Maintenant, créons des répertoires et un fichier de paramètres de configuration pour votre nouveau serveur et définissons la propriété. Ces répertoires seront utilisés pour stocker les fichiers de zone avant et arrière pour votre serveur DNS.
mkdir var/named/fwd-zones mkdir var/named/rev-zones chown -R named:named var/named/fwd-zones chown -R named:named var/named/rev-zones touch etc/zones.conf chown root:named etc/zones.conf
Ensuite, nous allons modifier le etc/named.conf fichier de configuration. Nous vous guiderons tout au long de la configuration afin que vous compreniez ce que chaque option fait pour votre serveur.
nano etc/named.conf
Lors de l'installation initiale, le fichier de configuration par défaut sera celui ci-dessous (si vous souhaitez passer au dernier etc/named.conf , vous pouvez le trouver ci-dessous):
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; };
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
Les paramètres de configuration et les options disponibles dans BIND sont très étendus. Dans cet article, nous ne couvrirons que les options permettant de configurer votre serveur en tant que serveur DNS faisant autorité et de sécuriser votre serveur contre les attaques d'amplification DNS récursives.
Pour une explication plus approfondie de toutes ces options, nous vous recommandons les gens de Zytrax.com.
Options d'écoute
La première option de configuration que nous allons changer concerne les options d'écoute de votre serveur. Par défaut, le serveur est configuré pour écouter uniquement sur l'adresse de bouclage locale (127.0.0.1). Nous allons changer cela pour écouter sur toutes les interfaces de votre serveur. Remplacez les lignes suivantes à l'intérieur des options { } clause du fichier de configuration.
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
ACL (listes de contrôle d'accès)
Nous allons maintenant ajouter quelques règles ACL (Access Control List) à la configuration. Ces ACL seront utilisées pour étendre les paramètres de sécurité pour les options de recherche de requête ainsi que les options de requête récursive. La première règle - que nous appellerons "requêtes autorisées" - sera utilisée pour autoriser n'importe quelle adresse source à interroger votre serveur DNS. La deuxième règle - nous l'appellerons "récursion autorisée" - sera utilisée pour limiter la recherche récursive à l'adresse localhost uniquement.
Ajoutez les règles de stratégie ACL ci-dessous juste au-dessus des options { } clause.
// ACL - Allow queries from ANY source address
acl "allowed-queries" {
any;
};
// ACL - Allow recursion from LOCALHOST only.
acl "allowed-recursion" {
127.0.0.1;
::1;
};
options {
...
};
Ensuite, nous allons changer la valeur de configuration du allow-query variable d'instruction pour utiliser la nouvelle ACL que nous venons de créer. Le allow-query définit qui (c'est-à-dire les réseaux sources) est autorisé à interroger votre serveur DNS. Remplacez la ligne suivante à l'intérieur des options { } clause du fichier de configuration.
allow-query { "allowed-queries"; }; Restreindre la récursivité
Nous devons maintenant sécuriser l'autorisation de recherche de récursivité sur votre serveur. La récursivité est une technique dans laquelle un serveur DNS interroge d'autres serveurs DNS au nom du client demandeur pour résoudre complètement le nom, puis renvoie une réponse au client. Les attaquants peuvent utiliser cette technique pour amener les serveurs DNS avec la récursivité ouverte activée à participer involontairement à une attaque DDoS (Distributed Denial of Service). Par conséquent, si un serveur DNS de votre réseau n'est pas destiné à recevoir des requêtes récursives, la récursivité doit être désactivée sur ce serveur ou sécurisée pour ne pas permettre à des sources non autorisées d'utiliser cette technique.
recursion yes;
allow-recursion { "allowed-recursion"; };
Nous allons maintenant ajouter une instruction include au fichier de configuration. Cette déclaration sera utilisée pour inclure les données de zone faisant autorité (domaines) auxquelles votre serveur sera configuré pour répondre. Ajoutez la ligne suivante sous la fin de l'option { } clause, juste après la dernière instruction include.
include "/etc/zones.conf";
Nous avons maintenant terminé les changements de configuration dans le etc/named.conf fichier de configuration. Vous pouvez maintenant enregistrer et quitter vos modifications.
.
Nouveau fichier named.conf
Pour examen, votre etc/named.conf le fichier de configuration devrait maintenant ressembler à ce qui suit :
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
// ACL - Allow queries from ANY source address
acl "allowed-queries" {
any;
};
// ACL - Allow recursion from LOCALHOST only.
acl "allowed-recursion" {
127.0.0.1;
::1;
};
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { "allowed-queries"; };
recursion yes;
allow-recursion { "allowed-recursion"; };
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/zones.conf";
.
4 – Ajouter votre première zone (domaine)
Nous allons maintenant ajouter votre première zone pour laquelle votre serveur DNS fera autorité. Nous allons utiliser un domaine de test (example.tld ) pour cette étape comme exemple.
Tout d'abord, nous allons créer un nouveau fichier dans le répertoire var/named/fwd-zones que nous avons créé précédemment.
touch var/named/fwd-zones/example.tld.zone; chown named:named var/named/fwd-zones/example.tld.zone;
Ensuite, nous allons ajouter l'exemple de données d'enregistrement de zone pour ce domaine. Modifiez le nouveau fichier que nous venons de créer et ajoutez les données de zone au fichier de configuration.
nano var/named/fwd-zones/example.tld.zone
Données de zone
; zone file for example.tld
$TTL 14400 ; 4 hours - default TTL for zone
$ORIGIN example.tld.
;; SOA Resource Record
@ IN SOA ns1.example.tld. hostmaster.example.tld. (
2015010100 ; se = serial number
12h ; ref = refresh
15m ; ret = update retry
3w ; ex = expiry
3h ; min = minimum
)
;; Name Servers
IN NS ns1.example.com.
ns1 IN A 192.0.2.3
;; Mail Exchange Resource Records
@ IN MX 10 mail.example.tld.
;; Web Server Resource Records
@ IN A 192.0.2.3
www IN CNAME @
;; FTP Server Resource Records
ftp IN A 192.0.2.3
Une fois que vous avez effectué toutes les modifications nécessaires, enregistrez et quittez.
Nous allons maintenant éditer le etc/zones.conf fichier de configuration pour inclure le nouveau domaine que nous venons de créer.
nano etc/zones.conf
Ajoutez maintenant les paramètres ci-dessous au fichier de configuration.
zone "example.tld" in {
type master;
file "fwd-zones/example.tld.zone";
allow-transfer { none; };
}; Une fois cela fait, enregistrez et quittez ce fichier.
Nous sommes maintenant prêts à redémarrer vos services DNS afin que toutes les nouvelles configurations se chargent.
systemctl restart named
Si tout a redémarré avec succès, sans aucune erreur, vous devriez recevoir la réponse suivante :
Stopping named: . [ OK ] Starting named: [ OK ]
.
5 – Tester votre serveur DNS
Nous sommes maintenant prêts à tester la fonctionnalité de votre nouveau serveur DNS. Tout d'abord, nous allons vérifier que votre serveur DNS répond pour la zone (domaine) que nous venons de créer. Exécutez la commande suivante :
dig example.tld -t ANY @localhost
Vous devriez voir la sortie de réponse similaire ci-dessous de votre serveur. Les valeurs de réponse clés à rechercher sont ;; ANSWER SECTION: valeurs. Cette sortie vous permet de savoir que le serveur a répondu à votre demande avec les données d'enregistrement que vous avez entrées dans les étapes précédentes.
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2 <<>> example.tld -t ANY @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61421 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;example.tld. IN ANY ;; ANSWER SECTION: example.tld. 14400 IN SOA ns1.example.tld. hostmaster.example.tld. 2015010100 43200 900 1814400 10800 example.tld. 14400 IN NS ns1.example.tld. example.tld. 14400 IN MX 10 mail.example.tld. example.tld. 14400 IN A 192.0.2.3 ;; ADDITIONAL SECTION: ns1.example.tld. 14400 IN A 192.0.2.3 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: ;; MSG SIZE rcvd: 147
Le deuxième test que nous allons faire est de vérifier que votre serveur répond aux recherches récursives de l'hôte local. Exécutez la commande ci-dessous pour commencer le test :
dig google.com -t ANY @localhost
Si le serveur est configuré comme prévu, vous devriez recevoir un ;; ANSWER SECTION: réponse.
;; ANSWER SECTION: google.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. 4294967295 7200 1800 1209600 300 google.com. 600 IN MX 50 alt4.aspmx.l.google.com. google.com. 600 IN MX 40 alt3.aspmx.l.google.com. google.com. 600 IN MX 10 aspmx.l.google.com. google.com. 600 IN MX 20 alt1.aspmx.l.google.com. google.com. 600 IN MX 30 alt2.aspmx.l.google.com. google.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all" google.com. 86400 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D google.com. 300 IN AAAA 2607:f8b0:4008:804::200e google.com. 300 IN A 216.58.219.78 google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. google.com. 172800 IN NS ns2.google.com. ;; AUTHORITY SECTION: google.com. 172800 IN NS ns4.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns2.google.com. ;; ADDITIONAL SECTION: ns2.google.com. 172800 IN A 216.239.34.10 ns1.google.com. 172800 IN A 216.239.32.10 ns4.google.com. 172800 IN A 216.239.38.10 ns3.google.com. 172800 IN A 216.239.36.10
Le dernier test que nous allons faire est de valider que votre serveur n'est PAS ouvert à une attaque par amplification DNS. Les gens d'openresolver.com ont mis en place un test simple que vous pouvez utiliser avec dig :
dig +short test.openresolver.com TXT @1.2.3.4
(replace 1.2.3.4 with the IP address or domain name of the DNS server you are testing)
Une réponse de "open-resolver-detected" indique que la récursivité est activée. Aucune réponse, dans ce cas, est une bonne chose .
Le site openresolver.com dispose également d'un outil basé sur un navigateur disponible pour tester cette vulnérabilité.
Lors du test avec votre adresse IP publique, vous devriez recevoir la réponse similaire suivante :
Test de résolveur DNS récursif ouvert réussi
Félicitations !
Vous avez maintenant un serveur DNS faisant autorité configuré et en cours d'exécution. Merci pour la lecture! Consultez certains des articles connexes ci-dessous et merci d'avoir essayé nos solutions d'hébergement VPS fiables sur Atlantic.Net.