ISC konsorcijs DHCP servera izlaišana , aizstājot klasisko ISC DHCP. Projekta avoti saskaņā ar licenci , nevis ISC Licence, kas iepriekš tika izmantota ISC DHCP.
Kea DHCP serveris ir balstīts uz BIND 10 un izmantojot modulāru arhitektūru, kas nozīmē funkcionalitātes sadalīšanu dažādos procesora procesos. Produkts ietver pilnvērtīgu servera ieviešanu ar DHCPv4 un DHCPv6 protokolu atbalstu, kas spēj aizstāt ISC DHCP. Kea ir iebūvēti rīki DNS zonu dinamiskai atjaunināšanai (Dynamic DNS), atbalsta mehānismus servera noteikšanai, adrešu piešķiršanai, atjaunināšanai un atkārtotai savienošanai, informācijas pieprasījumu apkalpošanai, adrešu rezervēšanai saimniekiem un PXE sāknēšanai. DHCPv6 ieviešana papildus nodrošina iespēju deleģēt prefiksus. Lai mijiedarbotos ar ārējām lietojumprogrammām, tiek nodrošināta īpaša API. Konfigurāciju ir iespējams atjaunināt lidojuma laikā, nerestartējot serveri.
Informāciju par piešķirtajām adresēm un klienta parametriem var glabāt dažāda veida krātuvēs – šobrīd aizmugursistēmas tiek nodrošinātas glabāšanai CSV failos, MySQL DBVS, Apache Cassandra un PostgreSQL. Resursdatora rezervēšanas parametrus var norādīt konfigurācijas failā JSON formātā vai tabulā MySQL un PostgreSQL. Tas ietver perfdhcp rīku DHCP servera veiktspējas mērīšanai un komponentus statistikas vākšanai. Kea demonstrē labu veiktspēju, piemēram, izmantojot MySQL aizmugursistēmu, serveris var veikt 1000 adrešu piešķiršanas sekundē (apmēram 4000 pakešu sekundē), bet, izmantojot memfile aizmugursistēmu, veiktspēja sasniedz 7500 uzdevumus sekundē.
Atslēga Kea 1.6:
- Ir ieviesta konfigurācijas aizmugursistēma (CB, Configuration Backend), kas ļauj centralizēti pārvaldīt vairāku DHCPv4 un DHCPv6 serveru iestatījumus. Aizmugursistēmu var izmantot, lai saglabātu lielāko daļu Kea iestatījumu, tostarp globālos iestatījumus, koplietotos tīklus, apakštīklus, opcijas, pūlus un opciju definīcijas. Tā vietā, lai visus šos iestatījumus saglabātu vietējā konfigurācijas failā, tos tagad var ievietot ārējā datu bāzē. Šajā gadījumā ir iespējams noteikt ne visus, bet dažus iestatījumus, izmantojot CB, pārklājot parametrus no ārējās datu bāzes un lokālajiem konfigurācijas failiem (piemēram, tīkla interfeisa iestatījumus var atstāt lokālajos failos).
No konfigurācijas glabāšanas DBVS pašlaik tiek atbalstīts tikai MySQL (MySQL, PostgreSQL un Cassandra var izmantot, lai saglabātu adrešu piešķiršanas datu bāzes (nomas), un MySQL un PostgreSQL var izmantot saimniekdatoru rezervēšanai). Konfigurāciju datu bāzē var mainīt vai nu ar tiešu piekļuvi DBVS, vai arī ar speciāli sagatavotām slāņu bibliotēkām, kas nodrošina standarta komandu kopu konfigurācijas pārvaldībai, piemēram, parametru, saišu, DHCP opciju un apakštīklu pievienošanai un dzēšanai;
- Pievienota jauna "DROP" apdarinātāja klase (uzreiz tiek atmestas visas ar DROP klasi saistītās paketes), ar kuras palīdzību var nomest nevēlamu trafiku, piemēram, noteikta veida DHCP ziņojumus;
- Ir pievienoti jauni parametri max-lease-time un min-lease-time, kas ļauj noteikt klientam saistošās adreses kalpošanas laiku (lease) nevis šifrētas vērtības veidā, bet gan kā pieņemams diapazons;
- Uzlabota saderība ar ierīcēm, kas pilnībā neatbilst DHCP standartiem. Lai novērstu problēmas, Kea tagad nosūta DHCPv4 ziņojuma veida informāciju opciju saraksta pašā sākumā, apstrādā dažādus resursdatora nosaukumu attēlojumus, atpazīst tukša resursdatora nosaukuma pārsūtīšanu un ļauj definēt apakšopciju kodus no 0 līdz 255;
- DDNS dēmonam ir pievienota atsevišķa vadības ligzda, caur kuru var tieši nosūtīt komandas un veikt konfigurācijas izmaiņas. Tiek atbalstītas šādas komandas: build-report, config-get, config-reload, config-set, config-test, config-write, list-commands, shutdown un version-get;
- Likvidēts (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), ko var izmantot, lai izraisītu pakalpojuma atteikumu (izraisot DHCPv4 un DHCPv6 servera apdarinātāju avāriju), nosūtot pieprasījumus ar nepareizām opcijām un vērtībām. Lielākās briesmas ir problēma , kas, ja saistīšanai tiek izmantota memfile atmiņa, neļauj patstāvīgi restartēt servera procesu, tāpēc darbības atjaunošanai ir nepieciešama administratora manuāla iejaukšanās (saistīšanas datu bāzes tīrīšana).
Avots: opennet.ru