Konsorcium ISC verzi DHCP serveru , který nahrazuje klasický ISC DHCP. Zdrojové kódy projektu pod licencí , místo dříve používané licence ISC License pro ISC DHCP.
DHCP server Kea je založen na technologiích BIND 10 a s využitím modulární architektury, která umožňuje rozdělení funkcionality na různé procesy-zpracovatele. Produkt zahrnuje plně funkční implementaci serveru s podporou protokolů DHCPv4 a DHCPv6, která může nahradit ISC DHCP. Kea obsahuje prostředky pro dynamickou aktualizaci DNS zón (Dynamic DNS), podporuje mechanismy pro objevování serverů, přidělování adres, aktualizace a připojení, zpracování informačních požadavků, rezervaci adres pro hosty a PXE zavádění. V implementaci DHCPv6 je navíc poskytována možnost delegace prefixů. Pro interakci s externími aplikacemi je k dispozici speciální API. Je možné provádět aktualizaci konfigurace za běhu bez restartování serveru.
Informace o přidělených adresách a parametrech klientů mohou být uloženy v různých typech úložišť — aktuálně jsou poskytovány backendy pro ukládání v souborech CSV, v databázích MySQL, Apache Cassandra a PostgreSQL. Parametry rezervace hostů mohou být zadány v konfiguračním souboru ve formátu JSON nebo ve formě tabulky v MySQL a PostgreSQL. Součástí je nástroj perfdhcp pro měření výkonu DHCP serveru a komponenty pro sběr statistik. Kea vykazuje dobrý výkon, například při použití backendu MySQL server dokáže provést 1000 přidělení adres za sekundu (přibližně 4000 paketů za sekundu), a při použití backendu memfile výkon dosahuje 7500 přidělení za sekundu.
Klíčové v Kea 1.6:
- Byl implementován backend konfigurace (CB, Configuration Backend), který umožňuje centralizované řízení nastavení několika serverů DHCPv4 a DHCPv6. Backend může být použit pro uchovávání většiny nastavení Kea, včetně globálních parametrů, informací o společných sítích, podsítích, možnostech, pulzech a definicích možností. Místo uchovávání všech těchto nastavení v místním konfiguračním souboru mohou být nyní umístěna ve vnější databázi. Přičemž je možné definovat prostřednictvím CB ne všechny, ale pouze část nastavení s překrýváním parametrů z vnější databáze a místních konfiguračních souborů (například v místních souborech mohou zůstat nastavení síťových rozhraní).
Pro SÚDB pro uchovávání konfigurace je prozatím podporován pouze MySQL (pro uchovávání databází přidělení adres (leases) mohou být použity MySQL, PostgreSQL a Cassandra, a pro rezervace hostitelů MySQL a PostgreSQL). Konfigurace v DB může být měněna jak prostřednictvím přímého přístupu k SÚDB, tak prostřednictvím speciálně připravených knihoven-úrovní, které poskytují standardní sadu příkazů pro správu konfigurace, jako jsou přidání a odstranění parametrů, vazeb, DHCP možností a podsítí;
- Byla přidána nová třída zpracovatelů „DROP“ (všechny pakety související s třídou DROP jsou okamžitě odmítnuty), která může být použita k odmítnutí nežádoucího provozu, například určitých typů DHCP zpráv;
- Byly přidány nové parametry max-lease-time a min-lease-time, které umožňují definovat životnost přidělení adresy klientovi (lease) ne ve formě pevně stanovené hodnoty, ale jako přijatelný rozsah;
- Byla vylepšena kompatibilita s zařízeními, která nedodržují plně standardy pro DHCP. Pro obcházení problémů nyní Kea odesílá informace o typu zprávy DHCPv4 na začátek seznamu možností, zpracovává různé reprezentace jmen hostitelů, rozpoznává přenos prázdného jména hostitele a umožňuje definovat submožnosti s kódy od 0 do 255;
- Pro démon DDNS byl přidán samostatný řídicí socket, prostřednictvím kterého lze přímo přenášet příkazy a provádět změny v konfiguraci. Podporovány jsou následující příkazy: build-report, config-get, config-reload, config-set, config-test, config-write, list-commands, shutdown a version-get;
- Opraveny (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), které mohou být využity k uskutečnění odmítnutí služby (způsobení zhroucení serverových zpracovatelů DHCPv4 a DHCPv6) prostřednictvím zasílání požadavků s nesprávnými možnostmi a hodnotami. Největší nebezpečí představuje problém , který v případě použití pro vazby úložiště memfile, brání možnosti samostatného restartování serverového procesu, a proto k obnovení funkčnosti je zapotřebí manuální zásah administrátora (údržba databáze vazeb).
Zdroj: opennet.ru
