Консорціум ISC реліз DHCP-сервера , що йде на зміну класичному ISC DHCP Вихідні тексти проекту під ліцензією замість раніше застосовуваної для ISC DHCP ліцензії ISC License.
DHCP-сервер Kea заснований на технологіях BIND 10 та з використанням модульної архітектури, що передбачає розбиття функціональності на різні процеси-обробники. Продукт включає повнофункціональну реалізацію сервера з підтримкою протоколів DHCPv4 і DHCPv6, здатну замінити собою ISC DHCP. У Kea вбудовані засоби динамічного оновлення DNS-зон (Dynamic DNS), підтримуються механізми виявлення серверів, призначення адрес, оновлення та перепідключення, обслуговування інформаційних запитів, резервування адрес для хостів та PXE-завантаження. У реалізації DHCPv6 додатково передбачено можливість делегування префіксів. Для взаємодії із зовнішніми програмами надається спеціальний API. Можливе оновлення конфігурації на льоту без перезапуску сервера.
Інформація про виділені адреси та параметри клієнтів може зберігатись у різних типах сховищ – в даний час надаються бекенди для зберігання у файлах CSV, СУБД MySQL, Apache Cassandra та PostgreSQL. Параметри резервування хостів можуть бути задані у файлі конфігурації у форматі JSON або у вигляді таблиці MySQL і PostgreSQL. До складу входить інструмент perfdhcp для вимірювання продуктивності сервера DHCP та компоненти для збору статистики. Kea демонструє непогану продуктивність, наприклад, при використанні бекеду MySQL сервер може виконати 1000 присвоєння адрес в секунду (близько 4000 пакетів в секунду), а при використанні бекенда memfile продуктивність досягає 7500 присвоєнь в секунду.
Ключові у Kea 1.6:
- Реалізовано бекенд конфігурації (CB, Configuration Backend), що дозволяє централізовано керувати налаштуваннями кількох серверів DHCPv4 та DHCPv6. Бекенд може застосовуватися для зберігання більшості налаштувань Kea, включаючи глобальні параметри, інформацію про загальні мережі, підмережі, опції, пули та визначення опцій. Замість зберігання всіх цих налаштувань у локальному конфігураційному файлі, вони тепер можуть розміщуватися в зовнішній базі даних. При цьому можливе визначення через CB не всіх, а частини налаштувань з накладенням параметрів із зовнішньої БД та локальних файлів конфігурації (наприклад, локальні файли можуть залишити налаштування мережевих інтерфейсів).
З СУБД для зберігання конфігурації поки що підтримується тільки MySQL (для зберігання баз присвоєння адрес (leases) можуть використовуватися MySQL, PostgreSQL і Cassandra, а для резервування хостів MySQL і PostgreSQL). Конфігурація в БД може змінюватись як через пряме звернення до СУБД, так і через спеціально підготовлені бібліотеки-прошарки, що надають типовий набір команд для керування конфігурацією, такі як додавання та видалення параметрів, прив'язок, DHCP-опцій та підмереж;
- Додано новий клас обробників «DROP» (усі пов'язані з класом DROP пакети відразу відкидаються), який може бути використаний для відкидання небажаного трафіку, наприклад певних типів DHCP-повідомлень;
- Додано нові параметри max-lease-time та min-lease-time, що дозволяють визначити час життя прив'язки адреси до клієнта (lease) не у формі жорстко заданого значення, а у вигляді допустимого діапазону;
- Покращена сумісність із пристроями, які не повністю дотримуються стандартів для DHCP. Для обходу проблем Kea тепер надсилає інформацію про тип повідомлення DHCPv4 на початку списку опцій, обробляє різні уявлення імен хостів, розпізнає передачу порожнього імені хоста і дозволяє визначати субопції з кодами з 0 по 255;
- Для демона DDNS доданий окремий сокет, через який можна безпосередньо передавати команди і вносити зміну в конфігурацію. Підтримуються такі команди: build-report, config-get, config-reload, config-set, config-test, config-write, list-commands, shutdown та version-get;
- Усунені (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), які можуть бути використані для здійснення відмови в обслуговуванні (виклик краху серверних обробників DHCPv4 та DHCPv6) через надсилання запитів з некоректними опціями та значеннями. Найбільшу небезпеку становить проблема , яка у разі використання прив'язки сховища memfile, призводить до неможливості самостійного перезапуску серверного процесу, тому для відновлення роботи потрібно ручне втручання адміністратора (чистка бази прив'язок).
Джерело: opennet.ru