LDAP Channel Binding and LDAP Signing Requirements

LDAP Channel Binding and LDAP Signing Requirements

Dostępność jest funkcją bezpieczeństwa” ten truizm powinien zostać wyryty w świadomości każdej osoby zajmującej się IT, zwłaszcza decydujących o zmianach systemowych podyktowanych bezpieczeństwem a mających wpływ na dostępność systemów/usług/rozwiązań.

Skąd takie stwierdzenie? W nawiązaniu do planów Microsoftu dotyczących fundamentalnych zmian w usłudze Active Directory i powiązanych z nią protokołów LDAP i LDAPS: Zmiany w usłudze Active Directory.

Pierwszy zarzut do Microsoftu dotyczy akcji informacyjnej o tak istotnych zmianach. Oprócz wspomnianego artykułu i zdawkowych informacji w Security Advisorze ciężko szukać w internecie szczegółów przeprowadzenia całej akcji oraz podłoża technologicznego, które na szczęście po naciskach klientów korporacyjnych uległo racjonalizacji w stosunku do pierwotnego zamysłu grupy produktowej. Niemniej nadal pozostaje nienagłośnione przez producenta a może nieść ze sobą katastrofalne skutki dla ciągłości biznesowej wielu organizacji zwłaszcza wykorzystujących systemy legacy czy realizujących filtrowanie ruchu sieciowego bazując na konkretnych portach TCP/UDP (w warstwie 4 OSI/ISO). Świadomość planowanych zmian wśród dostawców oprogramowania działającego w oparciu o usługi Active Directory jest również niestety znikoma…

Co się konkretnie zmieni? Jak to wpłynie na Twój biznes? Kiedy nastanie dzień „0”? Jaką zmianą/poprawką zostanie to wprowadzone? Czy jest opcja wycofania zmian? Na te pytania odpowiedzi znajdziesz niżej.

Co się konkretnie zmieni?

Otóż zmienią się 2 istotne rzeczy w Active Directory:

  1. LDAP Channel Binding – mechanizm, który był odpowiedzią Microsoftu na podatności LDAP Relay (CVE-2017-8563) i wprowadzał możliwość zwiększenia bezpieczeństwa zapytań LDAP w sieci. Wprowadzał racjonalną opcję wykorzystania mechanizmu dla klientów, którzy potrafią z niej poprawnie skorzystać tj:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
    DWORD: LdapEnforceChannelBinding = 0

    Gdzie jest haczyk?
    – Klienci niepotrafiący skorzystać z tego mechanizmu (Windows XP, Windows Server 2003, Windows Vista, WIndows Server 2008, klienci *NIX, urządzenia wielofunkcyjne etc.
    Na szczęście tutaj pod naciskiem klientów korporacyjnych Microsoft w poprawce wprowadzi właśnie wspomnianą racjonalną opcję, więc nic nie przestanie działać. Brawo MS!
  2. LDAP Signing Requirements – czyli podpisywanie zapytań LDAP. Funkcjonalność istniejąca w Active Directory od lat. W typ wypadku temat jest bardziej złożony – Jak każda z usług działając w sieci składa się z komponentu klienckiego (LDAP Client) oraz serwerowego (LDAP Server). O ile modyfikacja ustawień klienta jest w miarę prosta i bezpieczna (ponieważ przede wszystkim posiada ustawienie negocjacji a w przypadku wymuszenia można ją wykonywać iteracyjnie, w małych partiach i bez zauważalnego wpływu na ciągłość działania biznesu) o tyle ustawienia serwerowe są zero-jedynkowe. Albo podpisywanie jest wymuszone albo nie. Nie ma tutaj racjonalnej opcji „jeśli klient obsługuje” – wielka szkoda…
Rys.1 Ustawienia LDAP Client pozwalające na negocjowanie podpisywania LDAP
Rys.2. Ustawienia LDAP Server bez możliwości negocjowania podpisywania LDAP

W czeluściach systemu za ustawienie podpisywania LDAP po stronie serwerowej odpowiada klucz rejestru:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity

Może on przyjmować wartości:

  • 0 – podpisywanie wyłączone (GPO = Not Defined/Nie zdefiniowane)
  • 1 – podpisywanie wyłączone (GPO = None/Brak)
  • 2 – podpisywanie włączone (GPO = Require Signing/Podpisywanie wymagane)

Poniżej tabelka obrazująca jak zmieni się świat po zainstalowaniu poprawki bezpieczeństwa:

Obecna wartość rejestruObecne ustawienie GPOObecny wpływ na LDAPNowy wpływ na LDAPNowa wartość rejestru
BRAKNie zdefiniowaneBrak podpisywania LDAPPodpisywanie WymaganeBRAK
0n/dBrak podpisywania LDAP Brak podpisywania LDAP 0
1BrakBrak podpisywania LDAP Podpisywanie Wymagane1
2Podpisywanie wymagane Podpisywanie wymagane Podpisywanie Wymagane2

Wnioski nasuwają się co najmniej 2:

  1. Jeśli jawnie nie wyłączysz podpisywania LDAP („0”) to po uszczęśliwieniu poprawką bezpieczeństwa podpisywanie w Twojej organizacji będzie wymagane. Co więcej nie wystarczy obecne ustawienie w GPO = „Brak” !!!
  2. Nie ma możliwości wyłączenia podpisywania LDAP z poziomu dostępnych ustawień GPO – trzeba tego dokonać w rejestrze systemowym (lub za pomocą wpisu do rejestru w GPO)

Ale o co właściwie tyle krzyku można by pomyśleć. Podpisywanie to nie szyfrowanie – jakoś to będzie? Otóż „krzyk” jest o to, że podpisywanie LDAP żeby działało to co do zasady musi zmienić port komunikacji sieciowej ze standardowego LDAP (389 TCP/UDP) na port LDAPS (636 TCP) – wyjaśnienie w tabelce niżej. Co z tego wynika? Co najmniej 2 problemy:

  1. Większość aplikacji, końcówek, systemów *NIX musi zacząć komunikować się LDAPS zamiast standardowego LDAP – czyli całe IT w firmie biega, identyfikuje, testuje i wdraża zmiany w systemach.
  2. W ściśle kontrolowanym środowisku, gdzie filtrowany jest ruch sieciowy po portach TCP/UDP – należy zidentyfikować i zmodyfikować setki reguł firewall na dziesiątkach jeśli nie setkach urządzeń sieciowych.

Świetne zadanie w sam raz na początek Nowego Roku chciałoby się rzec…

Gwoli wyjaśnienia – poniżej tabelka z metodami uwierzytelnienia LDAP oraz informacjami o tym jak przekłada się to na LDAP/LDAPS oraz port sieciowy:

Typ uwierzytelnienia LDAPDziała przy braku wymuszenia podpisywania LDAPDziała przy wymuszonym podpisywaniu LDAPPort sieciowy
Simple BindTAKNIE389 TCP/UDP
Simple Bind over TLS/SSLTAKTAK636 TCP
Niepodpisany SASLTAKNIE389 TCP/UDP
SASL over TLS/SSL TAKTAK636 TCP
SASL + wbudowane szyfrowanieTAKTAK389 TCP/UDP

Jak to wpłynie na Twój biznes?

Jakie są wnioski z powyższej tabelki? Pomijając narzędzia i aplikacje Microsoftu, które potrafią wykorzystać SASL z wbudowanym szyfrowaniem większość infrastruktury zależnej od Active Directory albo:

a. zacznie komunikować się innym portem sieciowym niż dotychczas. Jeśli będzie zablokowany to masz murowany paraliż sieci

b. przestanie móc się poprawnie uwierzytelniać w LDAP

Chyba, że podejmiesz działania mające na celu zapobiec takim wypadkom, czyli zidentyfikujesz i zmienisz działanie aplikacji i systemów w sieci organizacji aby obsługiwały podpisywanie LDAP lub wyłączysz na stałe wymuszenie tego mechanizmu.

Kiedy nastanie dzień „0”

Na dobrą sprawę nadal nie wiadomo… Pierwsze plany mówiły o styczniu 2020. Obecne informacje wykazują na Marzec 2020 ale data może się jeszcze przesunąć jeśli świadomość zmian będzie szersza i społeczność wywrze na Microsofcie konieczność racjonalizacji podejścia w zakresie LDAP Signing.

Jaką zmianą/poprawką zostanie to wprowadzone?

To jest w zasadzie najciekawszy punkt – w publicznym Internecie chyba nie sposób dowiedzieć się jaka konkretnie poprawka spowoduje wdrożenie zmian w Active Directory. Zastanawiające dlaczego…
Rzeczoną poprawką specjalnej troski ma być KB4520412 – przeciek z Grupy Produktowej 😉

Instynkt samozachowawczy podpowiada aby ją wykluczyć z automatycznych instalacji i poczekać kilka dni, może tydzień lub dwa na innych żeby zobaczyć co się stało, co się zepsuło i czy producent przypadkiem się z tej poprawki nie wycofał.

Czy jest opcja wycofania zmian?

Na szczęście tak i nie wymaga de-instalacji poprawek (co w modelu Cumulative Update’ów byłoby karkołomne) tylko wprowadzenia np. w GPO zmian:

  1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
    DWORD: LdapEnforceChannelBinding = 0
  2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
    DWORD: LDAPServerIntegrity = 0

Monitoring/Audyt kompatybilności systemów ze zmianami

Na wszystkich kontrolerach domeny należy włączyć zbieranie zdarzeń poprzez wykonanie polecenia:

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

A następnie szukać zdarzeń ID:

  • 3039 oraz 3040 w przypadku zapytań nieobsługujących poprawnie LDAP Channel Binding
  • 2889 – informacja o klientach (z adresem IP oraz kontem użytkownika) korzystających z niepodpisywanych zapytań LDAP
  • 2887 – dzienne podsumowanie ilości „niebezpiecznych” czyli nie wykorzystujących podpisywania zapytań LDAP
  • 2888 – informacja o odrzuconych zapytaniach LDAP bez podpisywania

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.