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. Klienty Windows i macOS komunikują się przez 1.2.3.4 i TCP 9922; VPN, inna trasa domyślna lub router pośredni może poprowadzić tę ścieżkę z pominięciem firewalla. Przed szerokim wdrożeniem należy na jednym urządzeniu przetestować 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. Z urządzenia pilotażowego zweryfikować ścieżkę do 1.2.3.4 przez Sophos Firewall i TCP 9922.
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 aktualna 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.
• 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.

Aktualna pomoc SFOS 22 wymienia jako obsługiwane systemy Windows 10 i nowsze, Ubuntu 16.4 i nowsze oraz macOS Catalina 10.15 i nowsze. Jest to granica aktualnej dokumentacji produktu, a nie gwarancja dla każdej przyszłej wersji systemu operacyjnego. Przed wdrożeniem należy pilotażowo przetestować dokładne połączenie wersji SFOS, pakietu agenta i wersji urządzenia.

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.

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. Dostęp do User Portal udostępnia się tylko z przewidzianych sieci. 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. 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 i przenosi agenta do przewidzianego folderu aplikacji. 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. Aktualna 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

W Log viewer filtruje się Authentication według użytkownika, źródłowego IP i czasu testu. Pole klienta musi wskazywać Authentication Agent. Dodatkowo sprawdza się rzeczywisty ruch firewalla i jego Firewall Rule ID.

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 sprawdza się ścieżkę routingu do udokumentowanego celu agenta i TCP 9922. Kontrolowany packet capture z filtrem host 1.2.3.4 and port 9922 może pokazać, czy ruch Windows lub macOS dociera do Sophos Firewall. Dla Linux sprawdza się zamiast tego IP firewalla wpisane w caa.conf.

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. 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ść
• 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