Consortium ISC Version du serveur DHCP , remplaçant le DHCP ISC classique. Sources du projet sous licence , au lieu de la licence ISC précédemment utilisée pour ISC DHCP.
Le serveur DHCP Kea est basé sur BIND 10 et en utilisant une architecture modulaire, ce qui implique de diviser les fonctionnalités en différents processus de processeur. Le produit comprend une implémentation de serveur complète avec prise en charge des protocoles DHCPv4 et DHCPv6, capable de remplacer ISC DHCP. Kea dispose d'outils intégrés pour mettre à jour dynamiquement les zones DNS (Dynamic DNS), prend en charge les mécanismes de découverte de serveur, d'attribution d'adresses, de mise à jour et de reconnexion, de traitement des demandes d'informations, de réservation d'adresses pour les hôtes et de démarrage PXE. L'implémentation DHCPv6 offre en outre la possibilité de déléguer des préfixes. Une API spéciale est fournie pour interagir avec des applications externes. Il est possible de mettre à jour la configuration à la volée sans redémarrer le serveur.
Les informations sur les adresses allouées et les paramètres client peuvent être stockées dans différents types de stockage. Actuellement, les backends sont fournis pour le stockage dans des fichiers CSV, un SGBD MySQL, Apache Cassandra et PostgreSQL. Les paramètres de réservation d'hôte peuvent être spécifiés dans un fichier de configuration au format JSON ou sous forme de tableau dans MySQL et PostgreSQL. Il comprend l'outil perfdhcp pour mesurer les performances du serveur DHCP et des composants pour collecter des statistiques. Kea démontre de bonnes performances, par exemple, lors de l'utilisation du backend MySQL, le serveur peut effectuer 1000 4000 attributions d'adresses par seconde (environ 7500 XNUMX paquets par seconde), et lors de l'utilisation du backend memfile, les performances atteignent XNUMX XNUMX attributions par seconde.
Clé dans Kéa 1.6 :
- Un backend de configuration (CB, Configuration Backend) a été implémenté, permettant de gérer de manière centralisée les paramètres de plusieurs serveurs DHCPv4 et DHCPv6. Le backend peut être utilisé pour stocker la plupart des paramètres Kea, y compris les paramètres globaux, les réseaux partagés, les sous-réseaux, les options, les pools et les définitions d'options. Au lieu de stocker tous ces paramètres dans un fichier de configuration local, ils peuvent désormais être placés dans une base de données externe. Dans ce cas, il est possible de déterminer non pas tous, mais certains paramètres via CB, en superposant les paramètres de la base de données externe et les fichiers de configuration locaux (par exemple, les paramètres de l'interface réseau peuvent être laissés dans les fichiers locaux).
Parmi les SGBD permettant de stocker la configuration, seul MySQL est actuellement pris en charge (MySQL, PostgreSQL et Cassandra peuvent être utilisés pour stocker des bases de données d'attribution d'adresses (baux), et MySQL et PostgreSQL peuvent être utilisés pour réserver des hôtes). La configuration de la base de données peut être modifiée soit via un accès direct au SGBD, soit via des bibliothèques de couches spécialement préparées qui fournissent un ensemble standard de commandes pour la gestion de la configuration, telles que l'ajout et la suppression de paramètres, de liaisons, d'options DHCP et de sous-réseaux ;
- Ajout d'une nouvelle classe de gestionnaire « DROP » (tous les paquets associés à la classe DROP sont immédiatement supprimés), qui peut être utilisée pour supprimer le trafic indésirable, par exemple certains types de messages DHCP ;
- De nouveaux paramètres max-lease-time et min-lease-time ont été ajoutés, permettant de déterminer la durée de vie de la liaison d'adresse au client (location) non pas sous la forme d'une valeur codée en dur, mais sous la forme d'un plage acceptable ;
- Compatibilité améliorée avec les appareils qui ne sont pas entièrement conformes aux normes DHCP. Pour contourner les problèmes, Kea envoie désormais des informations sur le type de message DHCPv4 au tout début de la liste d'options, gère différentes représentations des noms d'hôte, reconnaît la transmission d'un nom d'hôte vide et permet de définir les codes de sous-option 0 à 255 ;
- Un socket de contrôle distinct a été ajouté pour le démon DDNS, via lequel vous pouvez directement envoyer des commandes et apporter des modifications à la configuration. Les commandes suivantes sont prises en charge : build-report, config-get, config-reload, config-set, config-test, config-write, list-commands, shutdown et version-get ;
- Éliminé (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), qui peut être utilisé pour provoquer un déni de service (provoquant le crash des gestionnaires de serveurs DHCPv4 et DHCPv6) en envoyant des requêtes avec des options et des valeurs incorrectes. Le plus grand danger est le problème , ce qui, si le stockage memfile est utilisé pour les liaisons, rend impossible le redémarrage du processus serveur par lui-même, une intervention manuelle de l'administrateur (nettoyage de la base de données de liaison) est donc nécessaire pour restaurer le fonctionnement.
Source: opennet.ru