Consortium ISC release du serveur DHCP , remplaçant le classique ISC DHCP. Les 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 les technologies BIND 10 et utilise une architecture modulaire, permettant de diviser la fonctionnalité en différents processus gestionnaires. Le produit inclut une implémentation complète du serveur prenant en charge les protocoles DHCPv4 et DHCPv6, capable de remplacer ISC DHCP. Kea intègre des outils de mise à jour dynamique des zones DNS (Dynamic DNS), prend en charge les mécanismes de détection de serveurs, de distribution d'adresses, de mise à jour et de reconnexion, de gestion des requêtes d'information, de réservation d'adresses pour les hôtes et de boot PXE. Dans l'implémentation de DHCPv6, la possibilité de déléguer des préfixes est également prévue. Un API spécifique est disponible pour interagir avec les applications externes. La configuration peut être mise à jour à chaud sans reboot du serveur.
Les informations sur les adresses attribuées et les paramètres des clients peuvent être stockées dans différents types de dépôts — actuellement, des backends sont fournis pour le stockage dans des fichiers CSV, des bases de données MySQL, Apache Cassandra et PostgreSQL. Les paramètres de réservation des hôtes peuvent être spécifiés dans un fichier de configuration au format JSON ou sous forme de table dans MySQL et PostgreSQL. Le package comprend l'outil perfdhcp pour mesurer les performances du serveur DHCP et des composants pour la collecte de statistiques. Kea démontre de bonnes performances, par exemple, en utilisant le backend MySQL, le serveur peut effectuer 1000 attributions d'adresses par seconde (environ 4000 paquets par seconde), tandis qu'avec le backend memfile, les performances atteignent 7500 attributions par seconde.
Améliorations clés dans Kea 1.6 :
- Un backend de configuration (CB, Configuration Backend) a été mis en œuvre, 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 de Kea, y compris les paramètres globaux, les informations sur 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 maintenant être hébergés dans une base de données externe. Il est possible de définir à travers le CB non pas tous, mais une partie des paramètres avec des superpositions provenant de la base de données externe et des fichiers de configuration locaux (par exemple, les fichiers locaux peuvent conserver les paramètres des interfaces réseau).
Actuellement, seule MySQL est prise en charge comme SGBD pour le stockage de la configuration (pour le stockage des baux d'adresses, MySQL, PostgreSQL et Cassandra peuvent être utilisés, et pour la réservation des hôtes, MySQL et PostgreSQL). La configuration dans la base de données peut changer à la fois via des requêtes directes à la base de données et via des bibliothèques intermédiaires spécialement préparées qui fournissent un ensemble type de commandes pour gérer la configuration, telles que l'ajout et la suppression de paramètres, de liaisons, d'options DHCP et de sous-réseaux.
- Une nouvelle classe de gestionnaires « DROP » a été ajoutée (tous les paquets associés à la classe DROP sont immédiatement rejetés), qui peut être utilisée pour rejeter le trafic indésirable, comme certains types de messages DHCP.
- De nouveaux paramètres max-lease-time et min-lease-time ont été ajoutés, permettant de définir la durée de vie du bail d'adresse pour un client non pas sous la forme d'une valeur fixe, mais sous la forme d'une plage acceptable.
- La compatibilité avec des appareils ne respectant pas complètement les normes pour DHCP a été améliorée. Pour contourner les problèmes, Kea envoie désormais l'information sur le type de message DHCPv4 au tout début de la liste des options, gère différentes représentations des noms d'hôtes, reconnaît l'envoi d'un nom d'hôte vide et permet de définir des sous-options avec des codes de 0 à 255.
- Pour le démon DDNS, un socket de contrôle séparé a été ajouté, par lequel des commandes peuvent être envoyées directement et les modifications de configuration apportées. 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.
- Résolus (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), qui peuvent être utilisées pour provoquer un déni de service (en provoquant l'écrasement des gestionnaires de serveur DHCPv4 et DHCPv6) en envoyant des requêtes avec des options et des valeurs incorrectes. Le problème le plus dangereux est , qui, lorsqu'elle est utilisée pour des liaisons de stockage memfile, entraîne l'incapacité de redémarrer le processus serveur de manière autonome, nécessitant ainsi l'intervention manuelle de l'administrateur (nettoyage de la base de liaisons).
Source : opennet.ru
