Konsorcjum ISC wydanie serwera DHCP , który zastępuje klasyczny serwer ISC DHCP. Źródła projektu na licencji , w miejsce wcześniej używanej licencji ISC License dla ISC DHCP.
Serwer DHCP Kea oparty jest na technologiach BIND 10 i z wykorzystaniem architektury modułowej, która zakłada podział funkcjonalności na różne procesy-ob handlers. Produkt obejmuje w pełni funkcjonalną implementację serwera z obsługą protokołów DHCPv4 i DHCPv6, zdolną do zastąpienia ISC DHCP. W Kea wbudowane są mechanizmy dynamicznego aktualizowania stref DNS (Dynamic DNS), wspierane są mechanizmy odkrywania serwerów, przydzielania adresów, aktualizacji i ponownego połączenia, obsługi zapytań informacyjnych, rezerwacji adresów dla hostów oraz PXE boot. W implementacji DHCPv6 dodatkowo przewidziano możliwość delegacji prefiksów. W celu interakcji z aplikacjami zewnętrznymi udostępniane jest specjalne API. Możliwa jest aktualizacja konfiguracji „w locie” bez ponownego uruchamiania serwera.
Informacje o przypisanych adresach i parametrach klientów mogą być przechowywane w różnych typach magazynów — obecnie udostępniane są backendy do przechowywania w plikach CSV, bazach danych MySQL, Apache Cassandra i PostgreSQL. Parametry rezerwacji hostów mogą być zadane w pliku konfiguracyjnym w formacie JSON lub w postaci tabeli w MySQL i PostgreSQL. W skład wchodzi narzędzie perfdhcp do pomiaru wydajności serwera DHCP oraz komponenty do zbierania statystyk. Kea wykazuje dobrą wydajność, na przykład przy użyciu backendu MySQL serwer może wykonać 1000 przypisań adresów na sekundę (około 4000 pakietów na sekundę), a przy użyciu backendu memfile wydajność osiąga 7500 przypisań na sekundę.
Kluczowe w Kea 1.6:
- Zrealizowano backend konfiguracji (CB, Configuration Backend), który umożliwia centralne zarządzanie ustawieniami kilku serwerów DHCPv4 i DHCPv6. Backend może być używany do przechowywania większości ustawień Kea, w tym globalnych parametrów, informacji o sieciach ogólnych, podsieciach, opcjach, pulach i definicjach opcji. Zamiast przechowywania wszystkich tych ustawień w lokalnym pliku konfiguracyjnym, mogą one teraz być umieszczone w zewnętrznej bazie danych. Możliwe jest zdefiniowanie przez CB nie wszystkich, a jedynie części ustawień z nałożonymi parametrami z zewnętrznej bazy danych i lokalnych plików konfiguracyjnych (na przykład w lokalnych plikach mogą być pozostawione ustawienia interfejsów sieciowych).
Na razie z systemów baz danych do przechowywania konfiguracji wspierany jest tylko MySQL (do przechowywania baz przydziału adresów (leases) mogą być używane MySQL, PostgreSQL i Cassandra, a do rezerwacji hostów MySQL i PostgreSQL). Konfiguracja w bazie danych może być zmieniana zarówno przez bezpośredni dostęp do bazy danych, jak i przez specjalnie przygotowane biblioteki pośrednie, które oferują standardowy zestaw poleceń do zarządzania konfiguracją, takich jak dodawanie i usuwanie parametrów, powiązań, opcji DHCP i podsieci;
- Dodano nową klasę handlerów „DROP” (wszystkie pakiety związane z klasą DROP są odrzucane), która może być używana do odrzucania niepożądanego ruchu, na przykład określonych typów komunikatów DHCP;
- Dodano nowe parametry max-lease-time i min-lease-time, które pozwalają określić czas życia przydziału adresu do klienta (lease) nie w postaci sztywno określonej wartości, lecz w postaci dozwolonego zakresu;
- Poprawiono kompatybilność z urządzeniami, które nie w pełni przestrzegają standardów dla DHCP. W celu ominięcia problemów Kea teraz przesyła informacje o typie komunikatu DHCPv4 na początku listy opcji, obsługuje różne reprezentacje nazw hostów, rozpoznaje przesyłanie pustej nazwy hosta oraz umożliwia definiowanie subopcji z kodami od 0 do 255;
- Do demona DDNS dodano osobny socket sterujący, przez który można bezpośrednio przesyłać polecenia i wprowadzać zmiany w konfiguracji. Wspierane są następujące polecenia: build-report, config-get, config-reload, config-set, config-test, config-write, list-commands, shutdown i version-get;
- Usunięto (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), które mogą być wykorzystane do wykorzystywania odmowy usługi (spowodowanie awarii serwerowych przetworników DHCPv4 i DHCPv6) poprzez wysyłanie żądań z nieprawidłowymi opcjami i wartościami. Największe zagrożenie stanowi problem , który w przypadku użycia dla wiązań pamięci memfile, prowadzi do niemożności samodzielnego ponownego uruchomienia procesu serwera, dlatego aby przywrócić działanie, wymagane jest ręczne zaangażowanie administratora (czyszczenie bazy wiązań).
Źródło: opennet.ru
