Serveur DHCP / DNS (Linux)

Le sujet d’article d’aujourd’hui se portera sur comment installer un couple serveur DHCP / DNS en tenant compte de l’auto-update DNS lors de l’enregistrement DHCP d’un équipement.
La base de travail est une VM portant une Debian Wheezy en 7.5 (donc full-update). Pour ce qui est des deux serveurs en question, on utiliser deux daemons qui sont éprouvé depuis pas mal de temps maintenant : * isc-dhcp-server pour la partie DHCP * bind9 pour le DNS

Tout d’abord, on installe les paquets debian qui vont bien pour faire ce qu’on cherche.

# apt-get install isc-dhcp-server bind9

Ensuite, il va falloir générer une clef qui va nous permettre de faire l’update du DNS de puis le DHCP, mais sans laisser trop de porte ouverte. Seul les daemon possédats cette clef seront capable de faire l’update d’un champ DNS.

# dnssec-keygen -a « encodage » -b keylenght -r /dev/urandom -n USER « keyname »

Ici vous faudra remplacer encodage,keylenght et keyname parce ce que vous préfèrerez. (Pour la suite, le keyname n’est pas spécialement important, mais il est obligatoire)
Pour ma part, je suis parti avec les options suivantes :

# dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DDNS_UPDATE

Et si on attaquait les choses sérieuse ?

Bind9

D’abord, le DNS vu que c’est lui qui sert quand même de backend.

On va éditer le fichier /etc/bind/named.conf.options pour ajouter une ligne dans les options :

dnssec-enable true;

Ensuite, on bascule dans le fichier /etc/bind/named.conf.local pour déclarer nos zones et tout ce qui vas aller bien pour que le DNS soit fonctionnel.
On va ajouter la déclaration de la clef que nous avons précédemment créé et qui va nous servir pour l’authentification lors des mises à jour du DNS.

key DDNS_UPDATE {
	algorithm HMAC-MD5.SIG-ALG.REG.INT;
	secret "«le dernier champ du fichier .key prédemment créé»"
}

Pour la partie déclaration de la key, c’est tout.
Maintenant, il faut déclarer les zones DNS

zone "example.org" { //La zone de déclaration pour le domaine example.org
	type master; // On indique que ce serveur est le server primaire de cette zone
	file "/etc/bind/example.org/db-example.org"; // On déclare le fichier qui sert de database à la zone
	allow-update { key "DDNS_UPDATE"; }; // On déclare notre fameuse clef nous permettant l’update dynamique de la zone
}

zone "0.168.192.in-addr.arpa" { //La zone de recherche inverse
	type master; // On indique que ce serveur est le server primaire de cette zone
	file "/etc/bind/example.org/db-example.org.inv"; // On déclare le fichier qui sert de database à la zone
	allow-update { key "DDNS_UPDATE"; }; // On déclare notre fameuse clef nous permettant l’update dynamique de la zone
}

Donc, le fichier de configuration complet ressemble à ça :

key DDNS_UPDATE {
	algorithm HMAC-MD5.SIG-ALG.REG.INT;
	secret "«le dernier champ du fichier .key prédemment créé»"
}

zone "example.org" {
	type master;
	file "/etc/bind/example.org/db-example.org";
	allow-update { key "DDNS_UPDATE"; };
}

zone "0.168.192.in-addr.arpa" {
	type master;
	file "/etc/bind/example.org/db-example.org.inv";
	allow-update { key "DDNS_UPDATE"; };
}

Après ça, il faut bien sur configurer les deux database DNS. db-example.org :

$TTL 86400; 1 day before expiration
example.org IN SOA dns.example.org. root.example.org. (
	3; serial (increase to each update)
	3600; refresh 1h
	86400; retry 1 day
	86400; expire 1 day
	3600; minimum ttl 1h
)
NS dns.example.org.
dns	IN A 192.168.0.1
db-example.org.inv :
$TTL 86400; 1 day before expiration
example.org IN SOA dns.example.org. root.example.org. (
	3; serial (increase to each update)
	3600; refresh 1h
	86400; retry 1 day
	86400; expire 1 day
	3600; minimum ttl 1h
)
1 IN PTR dns.example.org.

Pensez à une chose, il faut bien remettre les droit à l’user bind. Sinon, l’update ne fonctionnera pas correctement (chown -R bind:bind /etc/bind).
On en a fini avec le DNS. Tout ce qui se fera après dedans sera automatique (Sauf si vous souhaitez rajouter des enregistrements statiques.

Isc-dhcp-server

C’est ici la partie la plus intéressante parce qu’elle nous permet donc de fournir un service DHCP au machines de notre réseau, mais aussi de faire automatiquement un rescencement DNS de ces machines, à condition qu’elles fournissent leurs noms propre.

Tout ce passe dans le fichier /etc/dhcp/dhcpd.conf C’est le fichier par défaut lors de l’installation du paquet. Même s’il n’y a pas grand chose d’intéressant dedans, je vous conseille quand même de le sauvegarder, on ne sais jamais.

Pour ce qui est de la configuration, je vous montre une configuration finale avec les commentaires qui vont bien. dhcpd.conf :

ddns-updates on; # On permet au serveur DHCP de faire des updates DNS pour chaque validation d’attribution d’addresse non connue
ddns-update-style interim; # Définit que le serveur DHCP fait parti des registrar DNS.
ignore client-updates; # On ne permet pas au client de forcer les updates DNS.
update-static-leases; # Met à jour les enregistrements DNS pour les IP statiques qui sont déclarées.

default-lease-time 3600; # Définit le bail par défaut à 1h
max-lease-time 10800; # Définit le bail maximal à 3h
authoritative; # Définit le serveur DHCP comme principal sur le LAN
log-facility local7; # Option de log

# Déclaration de la clef qui va nous permettre de faire l’auto-update DNS
key "DDNS_UPDATE" {
	algorithm HMAC-MD5.SIG-ALG.REG.INT ;
	secret "«le dernier champ du fichier .key prédemment créé»"
}

# Déclaration des zone DNS correspondantes à celle que l’on va distribuer
zone example.org. {
	primary 127.0.0.1;
	key DDNS_UPDATE;
}
zone 0.168.192.in-addr.arpa {
	primary 127.0.0.1;
	key DDNS_UPDATE;
}

##################### Si vous souhaitez l’ajout de sécurité par mac address #############################
#class "allocation-to-non-restrictive-lan" {								#
#	match if (substring(hardware,0,7) = 1:xx:xx:xx:xx:xx:xx);					#
#}													#
#########################################################################################################

# Déclaration du subnet DHCP
subnet 192.168.0.0 netmask 255.255.255.0 {
	pool {
		#allow members of "allocation-to-non-restrictive-lan"; # Si vous activez les sécuritées
		range 192.168.0.100 192.168.0.150; # On défini une plage de 50 adresses alouables
		option subnet-mask 255.255.255.0; # On déclare le masque de sous-réseau de la plage
		option domain-name-servers 192.168.0.1; # On déclare le DNS de la zone
		option routers 192.168.0.1; # On déclare la gateway du sous-réseau
		option broadcast-address 192.168.0.255; # On déclare l’adresse de broadcast du subnet
		option domain-name "example.local"; # On déclare le domaine réseau
		option domain-search "example.local", "example.org"; # On déclare le/les domaines de recherche directe
		ddns-domainname "example.local"; # On déclare le domaine de DDNS
		ddns-rev-domainname "in-addr.arpa"; # On déclare le domaine de DDNS inverse
	}
}

Relancez les services et testez.

service bind9 restart && service isc-dhcp-server restart

Petit plus ?

Allons bon, je vous le lâche. Il est possible de dire au serveur DHCP de distribuer plusieurs subnet sur la même interface (sans VLAN), à condition que votre interface porte les subnets en question.
Dans quel but me direz-vous ?
Simplement pour pouvoir faire de la « ségrégation » ou de la sécurité.

Un exemple, vous avez à la maison un réseau Wi-Fi, un réseau ethernet, et pourquoi pas de la VOIP.
Il est intéréssant d’un point de vue sécurité de pouvoir séparer proprement les trois.
On peut donc simplement en jouer en ajoutant les options suivantes dans le dhcpd.conf

shared-network name-of-shared-network {
	subnet 192.168.0.0 netmask 255.255.255.0 {	#
		…					#	Ici pour l’ethernet
	}						#

	subnet 172.16.0.0 netmask 255.255.0.0 {		#
		…					#	Ici pour le Wi-Fi
	}						#

	subnet 10.0.0.0 netmask 255.0.0.0 {		#
		…					#	Ou encore là pour la VOIP
	}						#

}

Le tout combiné au filtrage MAC comme évoqué au dessus, on peut faire quelque chose de vraiment sympatique.

Pour ma part, j’ai ça en place pour séparer ethernet/Wifi.
Celà me permet de filtrer le Wi-Fi ainsi que les machines en ethrnet que je ne connais pas, en fournissant un débit vraiment minimum, juste pour du net. Et là, pas de filtrage MAC.
Et d’avoir un réseau privilégié en ethernet où j’ai du filtrage MAC, et ainsi d’avoir un full-access.
La VOIP, pas assez d’équipements pour présenter un intéret.