Konfiguracja Client Authentication Agent na Sophos Firewall

Client Authentication Agent, w skrócie CAA, jest przeznaczony dla pojedynczych urządzeń Windows, macOS lub Linux, na których użytkownik świadomie loguje się do firewalla. Po poprawnym logowaniu tożsamość pojawia się jako Authentication agent w Current activities > Live users. Reguły firewalla i web oparte na użytkownikach lub grupach mogą następnie przypisać ruch do tej tożsamości.

Agent nie zastępuje każdej architektury SSO. Serwer terminalowy z wieloma jednoczesnymi użytkownikami wymaga SATC, a w domenie Windows STAS może obsłużyć logowanie bez agenta na urządzeniu. CAA sprawdza się przede wszystkim na kontrolowanej liczbie pojedynczych urządzeń, na których ręczne logowanie użytkownika jest akceptowalne.

Ważne: Agent musi osiągać ścieżkę uwierzytelniania udokumentowaną przez Sophos. W Administration > Device access lokalna usługa Clients musi być dozwolona dla strefy źródłowej. CAA używa TCP 9922; VPN, inna trasa domyślna lub router pośredni może poprowadzić ścieżkę do 1.2.3.4 z pominięciem firewalla. Przed szerokim wdrożeniem należy na jednym urządzeniu przetestować Local Service ACL, trasę, TLS CA, logowanie pilotażowe i rzeczywiste dopasowanie reguły.

CAA w dziesięciu krokach

1. Potwierdzić, że urządzenie reprezentuje jednego aktywnego użytkownika; dla RDS, Citrix i innych hostów wieloużytkownikowych zastosować SATC.
2. Udokumentować serwer uwierzytelniania, grupę użytkowników, politykę firewalla i lokalną metodę odzyskiwania dostępu.
3. W Administration > Device access zezwolić na Clients dla strefy źródłowej. Przez TCP 9922 zweryfikować ścieżkę do 1.2.3.4 dla Windows i macOS albo do IP firewalla ustawionego w caa.conf dla Linux.
4. W Authentication > Client downloads pobrać odpowiedniego agenta i powiązaną Server CA.
5. Przy masowej dystrybucji Windows zaplanować razem Download MSI i Download CA for MSI; instalatory indywidualne zawierają agenta i CA.
6. Zainstalować agenta na jednym urządzeniu pilotażowym, ale jeszcze nie wdrażać go szeroko.
7. W Authentication > Services > Firewall authentication methods sprawdzić właściwy serwer uwierzytelniania i jego kolejność.
8. Zalogować użytkownika pilotażowego i potwierdzić typ klienta Authentication agent w Current activities > Live users.
9. Wykonać jeden dozwolony i jeden blokowany test ruchu, a następnie sprawdzić użytkownika, politykę i Firewall Rule ID w Log Viewer.
10. Dopiero potem udokumentować deployment, działanie MFA, test HA, proces wsparcia i rollback.

Kiedy Client Authentication Agent jest odpowiedni

CAA przekazuje logowanie użytkownika z urządzenia do firewalla. Szczególnie pasuje do:

• zarządzanych pojedynczych urządzeń nieprzyłączonych do domeny;
• małych środowisk bez infrastruktury STAS;
• urządzeń, na których zmiana użytkownika ma świadomie wywoływać nowe logowanie agenta;
• polityk wymagających rzeczywistej nazwy użytkownika zamiast samego źródłowego IP.

Agent nie jest ogólnym rozwiązaniem dla wielu jednoczesnych użytkowników za tym samym adresem IP hosta. SATC na systemach Remote Desktop opisuje podejście sesyjne dla Citrix, RDS i serwerów terminalowych. W środowisku AD STAS na Sophos Firewall jest alternatywą bez klienta.

CAA uwierzytelnia użytkownika, ale nie tworzy dostępu sieciowego. Reguły firewalla, Web Policies, grupy, limity i Access-Time-Policies pozostają oddzielnymi warstwami. Widoczny Live User nie dowodzi więc jeszcze, że wymagany ruch trafia do właściwej reguły.

Przykład i wymagania

Pilot wykorzystuje:

• IP LAN firewalla: 10.20.30.1
• Urządzenie pilotażowe: 10.20.30.50
• Użytkownik pilotażowy: fw-user-pilot
• Grupa użytkowników: CAA-Pilot
• Cel agenta: 1.2.3.4
• Port TCP: 9922

10.20.30.1 i 10.20.30.50 są prywatnymi wartościami dokumentacyjnymi i należy je zastąpić rzeczywistymi adresami. Natomiast 1.2.3.4 i TCP 9922 są udokumentowaną przez Sophos ścieżką agenta dla Windows i macOS i nie zastępuje się ich tam jak zwykłych wartości środowiskowych. Dla Linux instrukcja User Portal używa osobnego pliku konfiguracyjnego i wymaga rzeczywistego adresu IP firewalla.

Przed instalacją należy wyjaśnić następujące kwestie:

• Urządzenie pilotażowe używa Sophos Firewall jako gatewaya albo ma zweryfikowaną ścieżkę do celu agenta.
• Żaden full-tunnel VPN ani zewnętrzna trasa nie przejmuje 1.2.3.4 z dala od właściwego gatewaya SFOS.
• W Administration > Device access opcja Clients jest dozwolona w kolumnie rzeczywistej strefy źródłowej. Reguła firewalla nie zastępuje tej Local Service ACL.
• Użytkownik istnieje lokalnie albo na serwerze wybranym w Firewall authentication methods.
• Grupa i polityki są przygotowane; pilot nie otrzymuje zapobiegawczo szerszych uprawnień.
• Authentication Server CA odpowiadająca instalatorowi pochodzi wyłącznie z właściwego firewalla.
• Podczas pilota pozostaje dostępna działająca alternatywna metoda logowania.
• Jeśli MFA jest aktywne, token jest zarejestrowany, a działanie agenta przetestowane oddzielnie.

W przypadku SFOS 22 zakres systemów operacyjnych obsługiwanych przez Client Authentication Agent obejmuje Windows 10 i nowsze, Ubuntu 16.4 i nowsze oraz macOS Catalina 10.15 i nowsze. Ta granica produktu, przypisana do konkretnej wersji, nie gwarantuje obsługi każdej przyszłej wersji systemu operacyjnego; dlatego przed wdrożeniem należy przetestować dokładną wersję systemu na urządzeniu końcowym.

Avanet zaleca najpierw przetestować na jednym urządzeniu dokładne połączenie wersji SFOS, pakietu agenta, wersji endpointu i ochrony endpointu. Późniejszy test negatywny i zachowanie HA również są zaleceniami operacyjnymi; Sophos nie dokumentuje w ten sposób nieprzerwanej sesji podczas failoveru.

Przygotowanie uwierzytelniania na firewallu

W Authentication > Services > Firewall authentication methods wybiera się co najmniej jeden odpowiedni serwer albo lokalną bazę danych. Przy wielu serwerach SFOS przekazuje żądanie w pokazanej kolejności. Default Group, zaimportowana grupa i status użytkownika muszą więc być ustalone przed testem agenta.

CAA jest lokalną usługą uwierzytelniania firewalla. W Administration > Device access należy włączyć Clients w kolumnie strefy źródłowej. Według Sophos wpis obejmuje CAA na TCP 9922 oraz STAS i SATC na UDP 6060. Zwykłe reguły firewalla nie udostępniają Local Services. Dla Custom Zone dostęp można również kontrolować w Network > Zones.

Dla lokalnych kont pilotażowych pomocny jest artykuł bezpieczne tworzenie i testowanie lokalnych użytkowników. W przypadku AD, LDAP lub RADIUS najpierw testuje się odpowiedni serwer zwykłym dialogiem usługi. Zielony Test connection nie dowodzi jednak późniejszej ścieżki CAA z urządzenia.

Jeśli MFA jest aktywne dla User portal, Sophos wskazuje, że wymaganie to dotyczy również Client Authentication Agents. Rejestrację i wprowadzenie tokenu testuje się więc z tym samym użytkownikiem pilotażowym. MFA nie jest włączane niespodziewanie dopiero po wdrożeniu.

Pobieranie agenta i Server CA

Administratorzy pobierają pakiety tutaj:

Authentication > Client downloads

Sophos udostępnia następujące warianty:

• Download MSI: agent Windows do automatycznej dystrybucji;
• Download CA for MSI: oddzielna Authentication Server CA dla deploymentu MSI;
• Download for Windows: instalator indywidualny z agentem i CA;
• Download for macOS: instalator indywidualny z agentem i CA;
• Download for Linux 32 lub Download for Linux 64: archiwum z agentem, konfiguracją i CA.

Uprawnieni użytkownicy mogą też samodzielnie pobrać pakiety w Download client > Authentication clients w User Portal. Dla tej ścieżki należy wybrać co najmniej właściwy serwer w Authentication > Services > User portal authentication methods, a następnie włączyć User portal w Administration > Device access tylko dla przewidzianej strefy źródłowej. Domyślny port to TCP 4443. Sophos ostrzega przed udostępnianiem User Portal ze strefy WAN; szeroki dostęp WAN tylko do pobierania nie jest potrzebny.

Po factory reset firewall generuje CA ponownie. Użytkownicy muszą wtedy ponownie zainstalować Authentication Server CA. Starego agenta ze starą CA nie naprawia się przez wyłączenie weryfikacji certyfikatów ani dodanie obcej CA; aktualny pakiet należy pobrać ponownie z właściwego firewalla.

Instalacja agenta na urządzeniu pilotażowym

Windows i macOS

W Windows uruchamia się client_auth_agent.exe z User Portal. W kreatorze wybiera się miejsce instalacji i folder menu Start; Install instaluje klienta, a Finish zamyka kreator i uruchamia agenta. Zarządzany deployment MSI musi razem dystrybuować agenta i Download CA for MSI. Sam agent bez właściwej CA nie realizuje udokumentowanej ścieżki TLS.

W macOS otwiera się Client+Authentication+Agent.dmg. Należy przeciągnąć obie ikony do odpowiadających im folderów, zamknąć instalator i uruchomić Client Authentication Agent z Applications. Również tutaj wbudowana CA musi pochodzić z firewalla, do którego użytkownik będzie się później logować.

Najpierw instaluje się pilota interaktywnie. Dystrybucję pakietu, autostart i aktualizacje automatyzuje się dopiero po udanym teście end-to-end. Nie wykorzystuje się starego agenta z backupu innego firewalla ani innego urządzenia.

Linux

Dla Linux Sophos podaje następującą ścieżkę rozpakowania, w której <FILENAME> należy zastąpić nazwą pobranego archiwum:

sudo tar -xzvf <FILENAME> -p -C $HOME
sudo mv ~/bin/caa /usr/local/bin

Następnie sprawdza się dostarczoną konfigurację w $HOME/.caa/caa.conf. Pomoc User Portal wymaga dla Linux zastąpienia wartości po Copernicus host rzeczywistym adresem IP firewalla oraz wpisania nazwy użytkownika i hasła. Rzeczywistego hasła nie umieszcza się w skrypcie wdrożeniowym, tickecie ani publicznym przykładzie. Sophos wskazuje, że agent szyfruje początkowo zapisane jawnym tekstem hasło przy pierwszym uruchomieniu.

Przed startem sprawdza się prawa plików, właściciela i zawartość $HOME/.caa/README. Następnie uruchamia się caa jako pilot. Ponieważ instrukcja Linux używa innej wartości docelowej niż ogólna ścieżka Windows i macOS, procedur platformowych nie należy mieszać.

Logowanie pilota i testowanie polityk

Pilot loguje się w agencie za pomocą przewidzianej nazwy użytkownika i hasła firewalla. Przy uwierzytelnianiu zewnętrznym dokładny zapis musi odpowiadać konfiguracji serwera. Pozytywny status agenta jest dopiero pierwszym testem.

Następnie na firewallu sprawdza się:

1. fw-user-pilot pojawia się w Current activities > Live users.
2. Typ klienta to Authentication agent.
3. Źródłowy IP i grupa użytkownika odpowiadają urządzeniu pilotażowemu oraz planowanemu mapowaniu.
4. Dozwolony ruch testowy trafia do oczekiwanej reguły opartej na użytkowniku lub grupie.
5. Świadomie niedozwolony cel pozostaje zablokowany.
6. Log firewalla pokazuje użytkownika, regułę, działanie i Firewall Rule ID.
7. Po Disconnect w Live users agent otrzymuje udokumentowane powiadomienie, a ruch zostaje ponownie oceniony.

Dla reguły testowej nie tworzy się szerokiej polityki Any. Istniejące reguły rozszerza się kontrolowanie tylko o użytkownika lub grupę pilotażową. Ogólny proces opisuje artykuł systematyczne testowanie reguł Sophos Firewall.

Sprawdzanie logów i HA

Log viewer otwiera się w prawym górnym rogu konsoli WebAdmin. W module Authentication używa się Add filter lub wyszukiwania tekstowego dla użytkownika, źródłowego IP i czasu testu. Wpis musi odpowiadać logowaniu agenta; w module Firewall sprawdza się też rzeczywisty ruch, działanie i Firewall Rule ID. Aby test pojawił się w logu, w danej regule musi być włączone Log firewall traffic. Sesja może zostać zapisana dopiero po zamknięciu, dlatego należy prawidłowo zakończyć ruch testowy lub odświeżyć widok po krótkiej chwili.

Do dokładniejszej korelacji służy access_server.log dla uwierzytelniania i autoryzacji oraz Log Viewer lub skonfigurowany cel Syslog. Pojedynczy status klienta bez odpowiadającego wpisu w logu firewalla nie jest kompletnym dowodem powodzenia.

W HA nie zakłada się bezprzerwowego utrzymania istniejącego logowania agenta. Po kontrolowanym failoverze ponownie testuje się nowe logowanie, Live User, dopasowanie polityki i rzeczywisty ruch. Logi znajdują się na node, który przetworzył zdarzenie; przy niejasnym czasie należy sprawdzić oba nodes lub widok skonsolidowany.

Rozgraniczanie błędów według objawu

Agent nie osiąga firewalla

Najpierw w Administration > Device access należy sprawdzić, czy Clients jest włączone dla strefy źródłowej. Następnie sprawdza się routing i TCP 9922. W Diagnostics > Packet capture > Configure w polu Enter BPF string należy wpisać host 1.2.3.4 and port 9922; przechwycenie pokazuje, czy ruch agenta dociera do Sophos Firewall. Dla Linux używa się IP firewalla wpisanego w caa.conf zamiast 1.2.3.4.

Jeśli problem zaczyna się dopiero po uruchomieniu innego klienta VPN, należy sprawdzić, czy jego trasa full-tunnel przejmuje cel agenta. Rozwiązaniem nie jest ślepe zastosowanie polecenia host route: najpierw ocenia się split tunnel, routing i wpływ na bezpieczeństwo w rzeczywistej topologii. Jeśli ścieżka uwierzytelniania pozostaje niejasna, wdrożenie zostaje zatrzymane.

Pojawia się błąd TLS lub CA

Instalator i CA muszą pochodzić z tego samego aktywnego firewalla. Po factory reset stara CA jest nieważna i należy ją zastąpić aktualnym pakietem. Nie wyłącza się weryfikacji certyfikatów, ochrony endpoint ani TLS jako szybkiej poprawki.

Hasło działa w portalu, ale nie w agencie

W Firewall authentication methods sprawdza się kolejność serwerów, Default Group i status użytkownika. Następnie kontroluje się wymaganie MFA, zapis nazwy użytkownika, powiązanie źródłowego IP lub MAC oraz komunikat logu Authentication. Poprawne logowanie do portalu nie dowodzi automatycznie tej samej metody ani ścieżki agenta.

Użytkownik jest live, ale działa niewłaściwa reguła

Sprawdzić kolejność reguł, Match known users, wybranego użytkownika lub grupę, usługę, cel i Firewall Rule ID. Najpierw identyfikuje się faktycznie dopasowaną regułę; szeroka reguła allow nie zastępuje diagnostyki.

Na serwerze terminalowym pojawia się tylko jedna tożsamość

CAA nie jest właściwym podejściem dla tej ścieżki wieloużytkownikowej. Wiele równoległych instancji agenta nie tworzy systemu rozpoznającego sesje. Dla RDS lub Citrix należy użyć SATC i zweryfikować go oddzielnie.

Do diagnostyki obejmującej różne metody służy artykuł systematyczne sprawdzanie uwierzytelniania Sophos Firewall.

Rollback i eksploatacja

Po nieudanym pilocie agent na urządzeniu pilotażowym jest zatrzymywany lub usuwany. Tymczasowe zmiany użytkownika, grupy, portalu i reguł przywraca się do udokumentowanego poprzedniego stanu. Jeśli Clients włączono specjalnie dla pilota, opcję wyłącza się tylko wtedy, gdy nie potrzebuje jej żadna inna instalacja CAA, STAS lub SATC w tej strefie. Następnie ponownie testuje się wcześniejszą metodę uwierzytelniania z nowym logowaniem i rzeczywistym ruchem.

Authentication Server CA nie usuwa się globalnie, dopóki korzystają z niej inne instalacje CAA. Przed factory reset, reimage lub wymianą appliance należy zaplanować aktualizację nowo wygenerowanej CA na wszystkich urządzeniach, których dotyczy zmiana.

Należy udokumentować co najmniej następujące informacje operacyjne:

• właściciel pakietu agenta i deploymentu;
• zatwierdzone wersje systemów operacyjnych;
• pochodzenie i odnawianie Authentication Server CA;
• oczekiwana ścieżka do celu agenta i TCP 9922;
• proces MFA i haseł;
• test pilotażowy i negatywny po zmianach SFOS, endpoint lub VPN;
• offboarding i usuwanie istniejących Live Sessions.

Lista kontrolna

• potwierdzono urządzenie jednego użytkownika zamiast hosta wieloużytkownikowego
• udokumentowano serwer uwierzytelniania i kolejność
• Clients w Local Service ACL włączono tylko dla wymaganej strefy źródłowej
• potwierdzono ścieżkę agenta przez Sophos Firewall
• pobrano agenta i Authentication Server CA z tego samego firewalla
• wspólnie zaplanowano MSI i oddzielną CA
• uwzględniono ograniczenia platform i specjalną ścieżkę Linux
• przygotowano użytkownika pilotażowego z minimalną grupą i polityką
• przetestowano działanie MFA
• Live User pokazuje Authentication agent
• przetestowano dozwolony i blokowany rzeczywisty ruch
• potwierdzono w logu użytkownika, działanie i Firewall Rule ID
• przetestowano zachowanie VPN i HA z nowym logowaniem
• udokumentowano wpływ factory reset na CA i rollback

Częste pytania