20T45 Clearpass Klaster L3 6.9.0

Więcej miejsc do posłuchania:

Zmiana wymagań dla klastra od wersji 6.8

Próbowałeś zestawić klaster Clearpass’a i otrzymujesz komunikat błędu?

Setting up local machine as a subscriber to 10.253.253.130
WARNING - 10.253.253.130: echo GET failed. Will retry...
WARNING - 10.253.253.130: echo GET failed. Will retry...
ERROR - Publisher connection failed
ERROR - Connection to publisher failed. Please check that:
ERROR - 1) Publisher IP address and cluster password is valid and
synchronized
ERROR - 2) Publisher is up and accessible from this machine
ERROR - 3) License is active
ERROR - Setting up subscriber failed
Make subscriber complete. Re-login after sometime

Problemem jest podwyższenie bezpieczeństwa od wersji 6.8.0. Producent zdecydował, że będzie sprawdzał wiarygodność certyfikatów wymaganych do komunikacji między członkami klastra.

Wymagane jest wiarygodne połączenie 2 typami certyfikatów:

• HTTPS
• Database

Sprawdzanie certyfikatów bez wątpienia podnosi poziom bezpieczeństwa, ale w tym przypadku spowodowało również duże zamieszanie w przypadku aktualizacji systemów.

Od wersji 6.8.2 wprowadzono automatyczną walidację poprawności certyfikatu bazy danych, natomiast dla HTTPS wymagane jest dodanie do zaufanych urzędów podpisujących certyfikat HTTPS.

Nie chodzi tutaj o działanie dostępu administracyjnego, ten będzie działał niezależnie od zaufanych urzędów. Chodzi o komunikację klastra realizowaną przez port TCP 443, z weryfikacją wiarygodności partnera.

Tutaj warto wspomnieć że połączenie odbywa się od strony Subscriber’a do Publisher’a. Rekomenduję jednak na zezwolenie na firewall’u ruchu w dwóch kierunkach. To na wypadek gdyby nastąpiło przełączenie funkcji Clearpassa’a i promocja o roli Publisher’a.

UWAGA, masz 5 lat

Jak widzisz, ważność certyfikatów jest kluczowa dla działania klastra Clearpass’ów. Jeżeli wymienisz certyfikat zwróć uwagę na jego ważność i wymień zanim wygaśnie.

Jeżeli pozostawisz certyfikat DB domyślny to jego ważność skończy się po 5 latach i klaster przestanie się komunikować.

Dobre praktyki planowania klastra L3

Urządzenia końcowe powinny być w pobliżu obsługującego go Clearpass’a. Co to znaczy? Przy testach RTT (Routd Trip Time) opóznienie poniżej 600 ms nie wykazywało timou po wyżej 1 sekundy pojawiły się problemy z uwierzytelenieniem

Oprócz tego klaster L3 oznacza brak możliwości zastosowania wirtualnych adresów IP, bazujących na VRRP oraz L2.

Przy uwierzytelnieniach Radius, nie jest to problemem, można użyć listy serwerów Clearpass na urządzaniach sieciowych. W przypadku uwierzytelnień gości, takiej możliwości niema, trzeba zastosować albo LoadBalancer, lub manualny tryb przełączenia w DNS. Wybór będzie zależał od zasobności portfela, oraz krytyczności realizowanych usług.

Zalecam ze względu bezpieczeństwa rozdzielić funkcję portalu gościnnego, na wydzielony klaster Clearpass’ów dedykowanych do tego celu i umieszczonych w DMZ.

3 Kroki zestawiania klastra

Zakładam, że już masz nadaną adresację i zainstalowane co najmniej 2 serwery Clearpass.

1. Import i zaufanie urzędom certyfikacji powiązanym z certyfikatem dla Clearpass’ów

Loguję się do obu moich Clearpass’ów i przechodzę do sekcji:

Administration » Certificates » Trust List

Następnie importuję wcześniej przygotowany certyfikat mojego urzędu głównego. W prawym górnym rogu jest przycisk dodaj certyfikat.

Jak widzisz przy imporcie certyfikatu, trzeba wybrać jaki rodzaj użycia będzie powiązany z danym certyfikatem. Do importu certyfikatu w tym scenariuszu wymagana jest opcja „Other”. Wybór ten można później modyfikować.

2. Import certyfikatu do Clearpass’a

Następnie przechodzę do konfiguracji:

Administration » Certificates » Certificate Store

Na tej stronie w prawym górnym rogu jest link „Import Certificate”.

Wybieram:

Certificate Type:	Server Certificate
Server:	Clearpass-NAP-2 (10.17.17.130)
Usage:	HTTPS
Upload Method:	Upload Certificate and Private Key Files

Ostatnim parametrem jest hasło klucza prywatnego, nawet jeżeli masz klucz prywatny bez hasła, to trzeba w tym oknie wpisać dowolny ciąg znaków, żeby zaimportować certyfikat.

Na koniec sprawdzenie jaki certyfikat jest używany dla serwera WWW:

UWAGA

Jeżeli importujesz urząd i certyfikat upewnij się, że na stacji administracyjnej z której się łączysz, użyte urzędy są zaufane w systemie/przeglądarce.

3. Zestawienie klastra

Mając już właściwie przypisane certyfikaty i zaufane urzędy certyfikacji, mogę przejść do utworzenia klastra.

Administration » Server Manager » Server Configuration

Po prawej stronie w górnym rogu wymieram opcję „Make Subscriber”

Wpisuję adres IP Clearpass’a w roli Publishera dodaję hasło i klikam „Save”

Po kilku minutach i braku błędów, potwierdzam czy klaster się prawidłowo zestawił:

Jak widzisz Clerpass-NAP-1 jest w roli Publisher’a, natomiast Clearpass-NAP-2 jest w roli Subscriber’a. Oba serwery są dostępne, proces przebiegł prawidłowo.

Środowisko testowe

Przedstawiłem proces tworzenia klastra w formie produkcyjnej, z zastosowaniem zabezpieczenia w formie zaufanych certyfikatów oraz urzędów.

Do zastosowań testowych istnieje łatwiejszy sposób, można dołączyć Subscriber’a do Publishera bez sprawdzania certyfikatu.

Wystarczy zalogować się na podrzędny serwer Clearpass’a przez SSH i wydać polecenie:

cluster make-subscriber -i <Publisher IP> -V

W tym przypadku ignorowane jest zaufanie certyfikatu do połączenia.

Podsumowanie

Zwiększenie bezpieczeństwa jest zawsze związane z utrudnieniem pracy administratora. Trzeba lepiej rozumieć jak działa dane narzędzie, żeby je lepiej zabezpieczyć.

W rozwiązaniach łączonych przez L3, zazwyczaj będziemy mieli jeszcze różne firewall’e pomiędzy, trzeba przeanalizować koncepcję wdrożenia i zastosować odpowiednie reguły stosowne do naszej indywidualnej koncepcji wdrożenia.