Zmiany w obsłudze komunikacji LDAP - część 5/5

Artykuł jest ostatnią częścią serii „Zmiany w obsłudze komunikacji LDAP”. Odnośniki do poprzednich części znajdziecie na końcu. Dzisiaj pokażę wam przykłady testowania połączeń z usługą LDAP, po jej utwardzeniu, zgodnie z docelowymi ustawieniami Windows Server po zastosowaniu poprawek zaplanowanych na marzec 2020. 

Jakich aplikacji użyć, aby wydajnie weryfikować oraz testować stan zabezpieczeń komunikacji LDAP?

Podstawowa zasada brzmi, użyj znanego sobie oprogramowania, a to z kilku powodów. Prawie na pewno jest już zainstalowane i dozwolone w firmie. Używaliście go już nie raz, więc interfejs i możliwości są wam znane. Można skupić się na pracy, a nie narzędziu do jej wykonania. 

Jeśli do tej pory nie wykonywaliście takich testów lub po prostu jesteście ciekawi, co polecam, zachęcam do zapoznania się z poniższą listą. 

PowerShell – jeśli chcecie zrobić coś wsadowo lub uruchamiać automatycznie, np. z poziomu platformy do monitorowania, to wybór jest dość oczywisty. Koniecznie zapoznajcie się z dokumentacją ADSI adaptera oraz przestrzenią nazw  System.DirectoryServices.

LdapAdmin – darmowy klient oraz narzędzie do administracji katalogami LDAP dla Windows. Pozwala na podstawowe operacje (przeglądanie, wyszukiwania, modyfikację, tworzenie i usuwanie obiektów) oraz bardziej zaawansowane operacje (takie jak kopiowanie i przenoszenie obiektów pomiędzy serwerami).

LDAPExplorerTool – wieloplatformowa przeglądarka i edytor LDAP z graficznym interfejsem użytkownika. Program jest testowany przez twórców w systemach Windows i kilku dystrybucjach Linuksa (m.in. Debian, Red Hat).

JXplorer – wieloplatformowy klient usługi i edytor LDAP napisany w Javie (wymaga JRE). Program jest testowany przez twórców w systemach Windows, Solaris, Linux i OSX, ale gotowe paczki dostępne są także dla HPUX, AIX, BSD i wszystkiego, co uciągnie JRE.  

Jak wyglądają scenariusze testów?

Testy powinny być miarodajne (pokazywać, że coś działa (w ogóle lub w oczekiwany sposób) lub że nie działa). W przypadku naszego ćwiczenia, testowanie ma na celu potwierdzenie, że nowe utwardzone ustawienia kontrolera domeny pozwalają na bezpieczne oraz blokują niebezpieczne metody komunikacji LDAP.

Testy połączeń LDAP

Przetestujmy poszczególne rodzaje połączeń wykorzystując jednego z wcześniej opisanych klientów LDAP. Jeśli testy będą powtarzane, wówczas poszczególne konfiguracje połączeń najlepiej zapisać jako szablon, z którego będziemy mogli skorzystać w przyszłości. 

Logowanie anonimowe (Anonymous)

W oknie kreatora połączenia należy wprowadzić adres docelowego kontrolera domeny oraz port (domyślnie jest to port TCP 389) oraz wskazać Anonymous jako docelowy poziom zabezpieczeń dla połączenia. 

Połączenie do utwardzonego kontrolera domeny powinno zakończyć się niepowodzeniem. A to dlatego, że wymaga on poprawnego uwierzytelnienia, aby przeglądać zawartość katalogu LDAP. 

Pierwszy test zakończony sukcesem. Przeanalizujmy jeszcze ruch sieciowy, co będzie szczególnie użyteczne, gdy klient LDAP (w prawdziwym środowisku) nie oferuje obsługi błędów i wyświetla komunikat w stylu „Połączenie nie powiodło się, skontaktuj się z administratorem”. 

W przypadku dostępu anonimowego, klient bezpośrednio wysyła zapytanie (searchRequest) do wskazanego serwera LDAP. 

O tym nie może być jednak mowy. Uprawnienie odczytu informacji z katalogu (general read, GR) domyślnie posiadają tylko zalogowani użytkownicy.

Odpowiedź serwera może być tylko odmowna - choć informuje on od razu w czym rzecz (errorMessage 000004DC: LdapError: DSID-0C090A37). Większość monitorów sieciowych posiada wbudowane parsery, na załączonym zrzucie ekranu Wireshark dodaje komentarz (comment: In order to perform this operation a successful bind must be completed on the connection). 

Proste uwierzytelniania - Simple bind 

W kreatorze połączenia, ponownie wskazujemy utwardzony kontroler domeny jako cel, wykorzystując przy tym podstawowy port usługi LDAP TCP 389. Wybrany poziom bezpieczeństwa to User + Password, w kreatorze podajemy DN użytkownika oraz jego hasło. 

 I w tym przypadku spodziewamy się zobaczyć błąd połączenia. Klient zostaje poinformowany o konieczności zestawienia połączenia SSL\TLS, aby poświadczenia nie były przesyłane jawnym tekstem. 

Zobaczmy jak wygląda komunikacja zarejestrowana podczas próby połączenia w Wiresharku. 

Klient przesłał nazwę użytkownika oraz jego hasło jawnym tekstem, co pozwoliło na przechwycenie jego poświadczeń. 

Jeśli użytkownik posiada istotne uprawnienia w Active Directory lub firmowych aplikacjach, pozyskane w ten sposób poświadczenia mogą zostać wykorzystane bez jego wiedzy.

Serwer odrzucił żądanie oraz wskazał powód swojego zachowania (errorMessage: 00002028: LdapErr: DSID-0C09023C, comment: The server requires binds to turn on integritychecking if SSL\TLS are not already active on the connection).  

Z tej perspektywy ważne jest, aby utwardzić nie tylko kontrolery domeny, ale także klientów. To, że serwer nie akceptuje połączeń, nie znaczy, że klienci nie będą próbować się nimi posługiwać i narażać poświadczenia na podsłuchanie i przechwycenie. 

Uwierzytelnianie w tunelu SSL/TLS  – LDAPS bind

Testy połączeń SSL/TLS zaczynamy od weryfikacji obecności poprawnych certyfikatów na kontrolerach domeny. W tym celu możemy posłużyć się skryptem Audit-DcTlsCertificate. Skrypt połączyć się z wszystkim dostępnymi kontrolerami domeny na porcie 636, pobierze certyfikaty oraz wyświetli listę w oknie wynikowym (OGV).  

.\Audit-DcTlsCertificate.ps1

Kluczowe jest, aby certyfikaty były poprawne (przede wszystkim, aby zgadzała się nazwa serwera, z którym będziemy się łączyć (FQDN) oraz nazwa podmiotu dla którego wystawiono certyfikat (CN) oraz okres ważności (Valid from i Valid to). Zwróćcie też uwagę, by certyfikat obsługiwał obsługę uwierzytelnienia serwera (Server authentication, 1.3.6.1.5.5.7.3.1).

Jeśli testy chcemy ograniczyć do pojedynczego serwera (np. tylko testowo utwardzonego kontrolera domeny), możemy użyć skryptu Retrieve-ServerCertFromSocket. Pozwoli pobrać certyfikat z wskazanego kontrolera domeny, a także zweryfikować bezpośrednio na kliencie. 

Retrieve-ServerCertFromSocket pfe-dc1.pfe.academy 636 | Export-Certificate -FilePath C:\temp\test.cer ; start c:\temp\test.cer

Test-Certificate $(Retrieve-ServerCertFromSocket pfe-dc1.pfe.academy 636)

Windows ufa tylko certyfikatom wydanym przez urzędy, których certyfikaty są zintegrowane z systemem (wbudowane lub zostały doinstalowane, na przykład w czasie dodawanie do domeny Active Directory). 

W naszym przypadku, certyfikat pochodzi z zaufanego, wewnątrzorganizacyjnego centrum certyfikatów oraz spełnia pozostałe kryteria. 

Możemy zatem przystąpić do testów połączeń w programie JExplorer. Tutaj jednak czeka nas rozczarowanie, bo aplikacje Java (oraz kilku innych bibliotek lub platform) nie wykorzystują systemowego magazynu certyfikatów. Zatem podczas próby połączenia zobaczmy błąd.

Wystarczy dodać certyfikat serwera (np. gdy ten jest samopodpisany (self-signed) lub całego urzędu certyfikatów (np. gdy wewnętrznie dostępne serwery używają certyfikatów wydanych przez organizacyjne CA). 

W tym celu należy przejść do Security > Trusted Servers and CAs, aby w pierwszej kolejności przekonać się o zaufanych certyfikatach (i braku tych związanych z usługą LDAP). 

A następnie dodać stosowny certyfikat (najlepiej root-ca).

Jeśli certyfikat pochodzi z zaufanego głównego lub podrzędnego urzędu certyfikatów, odpowiednia informacja znajdzie się w jego właściwościach. 

Teraz możemy przejść do właściwych testów połączeń LDAP. 

W kreatorze połączenia wskazujemy utwardzony kontroler domeny na porcie 636 oraz poziom zabezpieczeń SSL + User + Password. 

Nazwa użytkownika oraz hasło w dalszym ciągu przesyłane są tekstem, ale informacje są zenkapsulowane w bezpiecznym tunelu SSL/TLS, przez co nie da się ich podsłuchać w sieci. Połącznie dochodzi do skutku. 

Rzućmy jeszcze okien na przebieg komunikacji zarejestrowany w Wiresharku. 

W pierwszej kolejności zestawiane jest połączenie TLS. Klient żąda zestawienia sesji, którą należy uzgodnić. Przesyła więc komunikat Client Hello, a w nim pożądana wersję protokołu (TLS 1.2) oraz zestaw wspieranych przez siebie algorytmów kryptograficznych, w postaci uporządkowanej listy (od najbardziej preferowanego).

W odpowiedzi na żądanie, serwer wysyła odpowiedź Server Hello dostarczając klientowi klucz publiczny swojego certyfikatu. Pierwsza część komunikacji w tunelu TLS szyfrowana jest asymetrycznie (z wykorzystaniem pary kluczy, prywatnego oraz publicznego - komunikaty zaszyfrowane jednym mogą być odszyfrowane tylko drugim). 

Kiedy obie strony mogą wymienić się kluczem, sesja przechodzi na szyfrowanie symetryczne (co zmniejsza zużycie czasu procesora po obu stronach komunikacji). 

Dalsza część komunikacji odbywa się w przygotowanym tunelu SSL\TLS. 

Poświadczeń, zapytań oraz odpowiedzi LDAP nie da się podsłuchać. Integralność i poufność komunikacji są zapewnione dzięki opakowaniu połączenia protokołu LDAP w tunelu TLS.

Uwierzytelnianie z użyciem bibliotek SASL 

Simple Authentication and Security Layer (SASL) to metoda dodania warstwy uwierzytelniania użytkownika m.in. dla protokołu LDAP. Ciężar uwierzytelniania oraz zabezpieczania komunikacji LDAP przesuwa się na jeden z wspieranych przez SASL mechanizmów. 

W pierwszej kolejności sprawdźmy jakie mechanizmy SASL są obsługiwane przez Active Directory. 

Get-ADRootDSE | select rootDomainNamingContext,supportedSASLMechanisms |ft -AutoSize

Wygląda obiecująco, sprawdźmy, z czego może skorzystać klient. 

Generic Security Service Application Program Interface (GSSAPI, czasami nazywany też GSS-API) to interfejs programistyczny pozwalający aplikacjom uzyskiwać dostęp do usług bezpieczeństwa, za pośrednictwem których realizowane jest uwierzytelniania, np. z użyciem protokołu Kerberos.

Oznacza to, że nie musimy tunelować połącznia i używamy standardowego portu 389. 

Po wytypowaniu tego poziomu zabezpieczeń w kliencie, otrzymujemy pytanie o nazwę użytkownika oraz jego hasło. Posłużą one do pozyskania biletów kerberosowych. 

Utwardzony kontroler domeny bez problemowo obsługuje żądanie klienta.

Tutaj przebieg komunikacji sieciowej jest zdecydowanie najciekawszy, rzućmy okiem na ruch przechwycony za pomocą Wireshark. 

Na początek klient ustala właściwy serwer, który obsłuży uwierzytelnianie domenowe. W tym celu odszukuje za pomocą zapytań dns-owych właściwy dla swojej podsieci kontroler domeny (rekord SRV dla nazwy _kerberos._udp.pfe.academy). 

Następnie wysyła żądanie uwierzytelnienia użytkownika, co pozwoli pozyskać bazowy bilet kerberosowy (ticket granding tickets, TGT). 

Poświadczenia użytkownika nie są wysyłane tekstowo, zamiast tego (w dużym uproszczeniu) klient szyfruje skrótem swojego hasła informację, którą z użyciem tego samego skrótu zapisanego w bazie AD kontroler rozszyfrowuje. 

Jeśli użytkownik podał poprawne hasło (udało się z niego wyliczyć właściwy skrót do zaszyfrowania komunikatu), kontroler domeny wydaje tiket TGT.

To jednak dopiero połowa drogi, użytkownik jest uwierzytelniony w domenie. Tymczasem usiłuje dostać się do konkretnej usługi na kontrolerze domeny. W tym celu musi zażądać od kontrolera domeny tiketu TGS. 

W żądaniu klient jasno precyzuje nazwę usługi i serwer, co pozwala wydać poprawny bilet, zaszyfrowany skrótem hasła wskazanego serwera, tak aby tylko on mógł otworzyć jego zawartość.

Dopiero teraz klient jest uzbrojony i żąda uwierzytelnienia w usłudze LDAP z użycie posiadanego już biletu. 

Kontroler domeny poprawnie obsługuje żądanie, a nazwa użytkownika oraz członkostwo w grupach zabezpieczeń zawarte w tikecie TGS wyznaczają kontekst po stronie serwera LDAP.

Bilety kerberosowe pozyskane przez oprogramowanie, które wykorzystuje biblioteki systemowe można podejrzeć za pomocą programu klist. 

klist

Pamiętajcie, że raz otrzymane bilety mają określoną ważność i przy następnym połączeniu do tego samego serwera LDAP nie będzie konieczności ich ponownego pozyskania. 

Jeśli ominęły was poprzednie części z serii poniżej znajdziecie odnośniki. 

Zmiany w obsłudze komunikacji LDAP - część 1/5

Zmiany w obsłudze komunikacji LDAP - część 2/5

Zmiany w domyślnych ustawieniach komunikacji LDAP (PDF) - część 3/5

Zmiany w domyślnych ustawieniach komunikacji LDAP (wideo) - część 4/5

Ma href=“https://blog.pfe.academy/post/190408395313/zmiany-w-obs%C5%82udze-komunikacji-ldap-cz%C4%99%C5%9B%C4%87-55”>Zmiany w obsłudze komunikacji LDAP - część 5/5

Udanych testów!