Konfiguracja TACACS+ dla administratorów Sophos Firewall

TACACS+ może weryfikować logowanie imiennych administratorów Sophos Firewall na centralnym serwerze. Upraszcza to polityki haseł i offboarding, ale nie zmienia automatycznie firewalla w urządzenie sieciowe w pełni sterowane przez TACACS+: przypisanie Device access profile pozostaje lokalne w SFOS.

Bezpieczna procedura rozdziela więc trzy warstwy: połączenie i dane uwierzytelniające do serwera TACACS+, pomyślne logowanie do właściwej usługi SFOS oraz lokalną rolę administratora na firewallu. Test connection potwierdza tylko połączenie z serwerem i dane użytkownika, a nie późniejszy dostęp do WebAdmin.

Ważne: Przed zmianą muszą być dostępne lokalne konto superadministratora admin, drugi działający kanał zarządzania oraz otwarta lokalna sesja administratora. TACACS+ nie może stać się jedyną metodą, zanim nie zadziałają logowanie pilotażowe, test negatywny i droga odzyskiwania dostępu.

TACACS+ w dziesięciu krokach

1. Pozytywnie przetestować lokalne konto admin, procedurę MFA lub odzyskiwania oraz dostęp administracyjny.
2. Udokumentować serwer TACACS+, adres źródłowy firewalla, port TCP i konto pilotażowe; Shared Secret przechowywać wyłącznie w zatwierdzonym magazynie sekretów, nie w zgłoszeniu wdrożeniowym.
3. Zezwolić na trasę TACACS+ wyłącznie przez zaufaną sieć zarządzającą lub chroniony tunel.
4. Dodać TACACS+ server w Authentication > Servers > Add.
5. Za pomocą Test connection sprawdzić dane logowania i osiągalność, a następnie zapisać.
6. Uwierzytelnić użytkownika pilotażowego raz przez już zatwierdzoną usługę firewalla, aby utworzyć obiekt użytkownika.
7. W Authentication > Users w kontrolowany sposób nadać użytkownikowi pilotażowemu rolę administratora i przypisać minimalny Device Access Profile.
8. W Authentication > Services > Administrator authentication methods dodać TACACS+, ustawić kolejność i zachować Local jako świadomy fallback.
9. Pozytywnie przetestować WebAdmin w prywatnym oknie przeglądarki oraz negatywnie z nieuprawnionym użytkownikiem.
10. Dopiero potem dodawać kolejnych administratorów, sprawdzić logi i w kontrolowany sposób przetestować awarię ścieżki TACACS+.

Co SFOS kontroluje przez TACACS+

Sophos Firewall używa skonfigurowanego serwera TACACS+ jako metody uwierzytelniania dla wybranych usług. Pomoc SFOS 22 wyraźnie wymienia PAP i CHAP dla TACACS+ w macierzy protokołów VPN (IPsec/dial-in/L2TP/PPTP) authentication methods. Nie oznacza to dostępności ustawienia PAP lub CHAP dla WebAdmin; administratorzy korzystają z serwera i kolejności wybranych w Administrator authentication methods.

Aktualna pomoc SFOS 22 nie dokumentuje automatycznego mapowania atrybutu TACACS+ na profil administratora Sophos. Użytkownik z zewnętrznego serwera pojawia się przy pierwszym logowaniu jako zwykły użytkownik i otrzymuje uprawnienia administratora dopiero po lokalnym przypisaniu. Microsoft Entra ID SSO jest wyraźnie udokumentowanym wyjątkiem z mapowaniem ról lub grup.

Ogólna zdolność protokołu TACACS+ do Authorization i Accounting również nie oznacza udokumentowanej autoryzacji poleceń w SFOS. W tym runbooku obowiązuje:

• TACACS+ sprawdza zewnętrzną tożsamość i hasło.
• SFOS lokalnie definiuje typ użytkownika i Device Access Profile.
• configuration-audit.log pozostaje dowodem zmian konfiguracji na firewallu.
• Sama zgoda TACACS+ nie uprawnia użytkownika do WebAdmin.

Planowanie ról lokalnych opisuje artykuł Bezpieczna konfiguracja administratorów i profili Sophos Firewall.

Przykład i wymagania

W przykładzie użyto:

• Server name: TACACS-HQ
• Server IP: 10.20.30.15
• Port: 49
• Użytkownik pilotażowy: fw-noc-pilot
• Device Access Profile: NOC-ReadOnly
• Sieć zarządzająca: 10.20.40.0/24

10.20.30.15 i 10.20.40.0/24 są prywatnymi wartościami przykładowymi i należy je zastąpić rzeczywistym adresem serwera oraz zatwierdzoną siecią zarządzającą. TCP 49 to port serwera TACACS+ przydzielony przez IANA, ale port wpisany w SFOS nadal musi dokładnie odpowiadać drugiej stronie. Shared Secret nie jest umieszczany na zrzutach ekranu, w zgłoszeniach ani w tym przykładzie.

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

• Serwer TACACS+ zna rzeczywisty adres źródłowy firewalla jako klienta lub Network Access Server.
• Routing i ścieżka firewall między firewallem a serwerem działają w obu kierunkach.
• Konto pilotażowe jest aktywne na serwerze TACACS+ i dozwolone dla planowanego typu uwierzytelniania.
• Przygotowano osobny Device Access Profile z None, Read-only i tylko wymaganymi uprawnieniami Read-write.
• WebAdmin jest osiągalny wyłącznie z planowanej sieci zarządzającej.
• Lokalne konto admin działa niezależnie od TACACS+.
• Backup, okno serwisowe i droga odzyskiwania są udokumentowane.

Minimalny profil tworzy się w Profiles > Device access > Add. Każdemu obszarowi menu należy przypisać None, Read-only lub Read-write; Expand pozwala dokładniej ustawić uprawnienia podmenu. NOC-ReadOnly jest tylko nazwą przykładową. Znaczenie ma zapisana macierz uprawnień, później przypisana użytkownikowi z User type Administrator.

Aktualny formularz SFOS dokumentuje dla TACACS+ adres IP, port i Shared Secret, ale nie przełącznik TLS. RFC 8907 określa klasyczną ochronę pakietów TACACS+ jako zaciemnianie bez nowoczesnej integralności, poufności ani ochrony przed powtórzeniem. Ścieżka do serwera powinna więc prowadzić przez oddzielną zaufaną sieć zarządzającą lub chroniony tunel, nigdy przez niezabezpieczony Internet. Jeśli dostępny jest tylko niezabezpieczony transport, wdrożenie produkcyjne należy zatrzymać.

Dodawanie serwera TACACS+ do firewalla

Ścieżka menu:

Authentication > Servers > Add

Procedura:

1. Ustawić Server type na TACACS+ server.
2. Wprowadzić jednoznaczny Server name, na przykład TACACS-HQ.
3. Wprowadzić rzeczywisty Server IP i Port skonfigurowany na serwerze.
4. Zapisać identyczny Shared secret jak po stronie serwera TACACS+. Ten ciąg znaków jest wspólnym hasłem firewalla jako klienta i serwera, a nie hasłem użytkownika pilotażowego.
5. Do Test connection użyć zatwierdzonego konta pilotażowego.
6. Zapisać dopiero po pomyślnym teście.

Test połączenia sprawdza dane użytkownika i łączność z serwerem. Nie dowodzi osobno poprawności Shared Secret, tego, że użytkownik ma już profil administratora, że WebAdmin jest osiągalny z jego sieci ani że rzeczywiste logowanie administratora działa.

Jeśli test się nie powiedzie, najpierw sprawdzić adres IP serwera, trasę, port, Shared Secret, definicję klienta i log serwera. Nie zmieniać metod uwierzytelniania ani ról administratora na podstawie przypuszczeń.

Automatyzacja przez XML API: obsługa odpowiedzi konfiguracji według wersji SFOS

Wyjaśnić sprzeczność w dokumentacji przed zapisem: Przykłady XML dla SFOS 22 i 23 zawierają AuthenticationServer/TACACSServer/Port z wartością 49 oraz AuthenticationServer/TACACSServer/ServerAddress. Tabele parametrów podają natomiast AuthenticationPort z wartością domyślną 1812 oraz ServerIP. To sprzeczność między przykładem a tabelą, a nie dowód, że nazwy tagów są wymiennymi aliasami lub że TACACS+ rzeczywiście używa takiej wartości domyślnej.

Przed każdym autoryzowanym zapisem sprawdzić dokumentację API zainstalowanego buildu i zapisany stan serwera. Jeśli schemat pozostaje niejasny, najpierw wyjaśnić go z Sophos Support; nie tworzyć na podstawie tych wpisów gotowego do skopiowania żądania XML. Port TCP nadal musi dokładnie odpowiadać drugiej stronie połączenia TACACS+. Nie przyjmować 1812 bez weryfikacji ani nie zmieniać serwera, aby dopasować go do tabeli. Po zmianie ponownie odczytać i porównać zapisany obiekt; logowanie pilotażowe i lokalny fallback nadal są wymagane.

Tabele parametrów dla SFOS 22 i 23 podają również następujące pola wymagane i ograniczenia danych wejściowych:

Te informacje opisują wyłącznie dokumentację, a nie zweryfikowane zachowanie podczas działania. Przed autoryzowaną zmianą sprawdzić również ograniczenia w dokumentacji zainstalowanego buildu. Nigdy nie skracać istniejącego Shared Secret ani nie zmieniać go tylko po to, aby dopasować go do tej tabeli. W razie rozbieżności zatrzymać zmianę i wyjaśnić dalsze postępowanie z Sophos Support.

Jeśli serwery TACACS+ są dodawane lub edytowane przez XML API, obsługa odpowiedzi musi uwzględniać wersję SFOS. Dokumentacja API rozróżnia następujące pary status/identyfikator dla Add TACACS+ server i Edit TACACS+ server:

• SFOS 22 – Add: 200/TacacsAddSuccess, 500/TacacsAddFail, 502/TacacsRecordExists, 503/TacacsAddFailDetail.
• SFOS 22 – Edit: 200/TacacsUpdateSuccess, 500/TacacsUpdateFail, 502/TacacsUpdateFailDetail.
• SFOS 23 – Add: 200/CPSuccessConfig, 400/CPInvalidRequestBody, 401/CPUnauthorized, 403/CPForbidden, 409/CPResourceConflict, 500/CPInternalServerError.
• SFOS 23 – Edit: 200/CPSuccessConfig, 400/CPInvalidRequestBody, 401/CPUnauthorized, 403/CPForbidden, 404/CPRecordNotFound, 500/CPInternalServerError.

Liczby to udokumentowane wartości statusu operacji konfiguracyjnej, a nie informacje o statusie transportu HTTP. Nazwy po / są surowymi identyfikatorami JavaScript w Message, a nie odczytanymi tekstami komunikatów. W SFOS 23 automatyzacja nie może bez zmian używać starych przypisań 502/503. Nie potwierdzono również, że 409/CPResourceConflict oznacza wyłącznie zduplikowany wpis serwera.

Przed decyzją o ponowieniu operacji zapisu zaleca się ponownie odczytać zapisany obiekt serwera i porównać go z zamierzoną konfiguracją. Lista statusów nie gwarantuje ani bezpieczeństwa powtórzenia, ani określonych zasad ponawiania. Wynik konfiguracji nie zastępuje ani Test connection, ani rzeczywistego testu akceptacyjnego WebAdmin z lokalnie przypisanym minimalnym profilem i dostępnym kontem awaryjnym. To rozróżnienie opisuje udokumentowany kontrakt API, nie test wykonany na produkcie.

XML Delete: cel i wynik sprawdzać osobno. Odrębna operacja Delete TACACS+ server identyfikuje zapisany serwer zgodnie z dokumentacją referencyjną SFOS 22/23 za pomocą ServerName, a nie domniemanego selektora adresu IP. Tabela Delete wymienia tylko to pole: maksymalnie 50 znaków, bez przecinka, UTF-8 dozwolone. Oznaczenie go w tej tabeli jako opcjonalnego nie oznacza zgody na szerokie usuwanie ani na usuwanie bez jednoznacznego celu. Przed autoryzowaną operacją należy odczytać serwer o dokładnie wskazanej nazwie, porównać go ze zleceniem usunięcia i sprawdzić, czy nadal korzysta z niego jakaś metoda uwierzytelniania lub inna funkcja. Dopóki istnieją zależności lub cel jest niejasny, nie należy usuwać wpisu. Działający lokalny fallback i otwarta lokalna sesja administratora pozostają zachowane. Następnie należy ponownie odczytać ten sam cel i sprawdzić, czy usunięto dokładnie zatwierdzony wpis.

Dla Delete poszczególne wersje dokumentują własne pary status/identyfikator:

• SFOS 22 – Delete: 200/TacacsDeleteSuccess, 500/TacacsDeleteFailed.
• SFOS 23 – Delete: 200/CPSuccessConfig, 500/CPInternalServerError.

Również tutaj liczby są udokumentowanymi wartościami statusu operacji konfiguracyjnej, a nie statusami transportu HTTP. Nazwy są nierozwiązanymi identyfikatorami JavaScript w Message, a nie komunikatami zaobserwowanymi podczas działania. Obie strony dokumentacji Delete nie zawierają przykładowej koperty XML; dlatego nie należy wymyślać żądania Delete na podstawie struktury Add/Edit. Miarodajne pozostają dokumentacja referencyjna zainstalowanego buildu oraz sprawdzenie dokładnego celu przed operacją i po niej. To wyjaśnienie oparte na dokumentacji nie stanowi deklaracji wykonania testu usuwania ani gwarancji bezpiecznych zasad ponawiania.

Bezpieczne nadawanie uprawnień administratora zewnętrznemu użytkownikowi

Użytkownicy zewnętrznych serwerów stają się widoczni w Authentication > Users po pierwszym pomyślnym zalogowaniu do usługi firewalla. W pilotażu należy użyć już zatwierdzonej usługi, na przykład User Portal lub VPN Portal. Jeżeli taka ścieżka nie istnieje, nie należy tworzyć szerokiej ekspozycji WAN wyłącznie w celu utworzenia rekordu użytkownika.

Procedura pozostaje ograniczona:

1. Zezwolić na wybrany portal lub usługę uwierzytelniania tylko z sieci zarządzającej.
2. Dodać TACACS+ dokładnie do tej metody uwierzytelniania bez usuwania istniejących fallbacków.
3. Raz pomyślnie zalogować użytkownika pilotażowego.
4. W Authentication > Users sprawdzić, czy pojawił się obiekt użytkownika zewnętrznego.
5. Otworzyć użytkownika i ustawić User type na Administrator.
6. Przypisać przygotowany profil, na przykład NOC-ReadOnly.
7. Zbędne tymczasowe uprawnienia portalu lub metody przywrócić do udokumentowanego stanu początkowego.

Nie należy zapobiegawczo przydzielać zewnętrznemu użytkownikowi pełnego profilu Administrator. Najpierw testuje się rolę tylko do odczytu lub wąsko ograniczoną. Uprawnienia zapisu otrzymują wyłącznie konta, których zadania rzeczywiście ich wymagają.

Zmiana Administrator authentication methods

Ścieżka menu:

Authentication > Services > Administrator authentication methods

Dodać TACACS+ do listy wybranych serwerów. Dla każdej metody uwierzytelniania można wybrać maksymalnie 20 serwerów. Przy kilku serwerach SFOS przekazuje żądanie w pokazanej kolejności. Ich liczba i kolejność są więc częścią projektu bezpieczeństwa.

Dla pilotażu:

1. Dodać TACACS+ do wybranej listy.
2. Przenieść serwer na zaplanowaną pozycję.
3. Zachować Local jako świadomy fallback dla imiennych administratorów lokalnych.
4. Wybrać Apply.
5. Pozostawić otwartą istniejącą sesję admin.

Administrator authentication methods wyraźnie nie dotyczą lokalnego superadministratora admin. To konto pozostaje niezależną drogą awaryjną i jest osobno chronione silnym hasłem, MFA oraz ograniczonym dostępem sieciowym.

Set authentication methods same as firewall wiąże logowanie administratora z metodami używanymi do uwierzytelniania firewalla. Opcję tę stosuje się tylko wtedy, gdy takie powiązanie jest zamierzone i udokumentowane. W jednoznacznym pilotażu administratorów jawna lista jest łatwiejsza do sprawdzenia i przywrócenia.

Walidacja WebAdmin i działania roli

WebAdmin używa domyślnie portu HTTPS 4444; port niestandardowy jest widoczny w Administration > Admin and user settings. Przed testami negatywnymi należy tam sprawdzić również Block login: po wystarczającej liczbie nieudanych prób SFOS blokuje źródłowy adres IP dla wszystkich usług, w tym WebAdmin, CLI, VPN Portal i User Portal. Próba z nieuprawnionym użytkownikiem i próba z nieprawidłowym hasłem to osobne testy negatywne. Przed każdą próbą należy uwzględnić próg blokady, okres obserwacji i dotychczasową liczbę nieudanych prób; testów nie wykonuje się bezpośrednio jeden po drugim, jeśli mogłoby to spowodować osiągnięcie progu blokady. Drugi adres źródłowy do zarządzania lub konsola pozostają dostępne. Według Sophos nieudana weryfikacja CAPTCHA nie jest liczona jako nieudana próba logowania.

Pomyślna akceptacja sprawdza więcej niż okno hasła:

1. Pozostawić otwartą lokalną sesję admin.
2. Zalogować użytkownika pilotażowego przez planowany FQDN WebAdmin w prywatnym oknie przeglądarki.
3. Sprawdzić przypisany profil: oczekiwane menu są widoczne, a niedozwolone obszary nie występują.
4. Przy Read-only kontrolowanej zmiany nie można zapisać.
5. Dla planowanej roli z prawem zapisu użyć nieszkodliwej zmiany testowej z udokumentowanym rollbackiem.
6. Prawidłowy użytkownik TACACS+ bez lokalnej roli administratora nie może otworzyć WebAdmin.
7. Nieprawidłowe hasło musi zostać odrzucone.
8. Lokalne konto admin musi nadal móc zalogować się w drugim prywatnym oknie.
9. Skorelować czasowo log serwera TACACS+, Log Viewer i configuration-audit.log.

Osiągalność WebAdmin jest kontrolowana osobno w Administration > Device access lub przez wąski wyjątek Local Service ACL. TACACS+ i MFA nie uzasadniają szerokiej ekspozycji WAN. Bezpieczną ścieżkę sieciową opisuje Device Access i Local Service ACL.

Sprawdzanie logów i HA

W Log viewer filtrować według użytkownika pilotażowego, adresu źródłowego i czasu testu. Do głębszej analizy służą:

• access_server.log dla uwierzytelniania, autoryzacji i Accounting w SFOS
• configuration-audit.log dla zmian, administratora i czasu
• syslog.log dla zdarzeń systemowych na poziomie jądra; zdarzenia systemowe i wywołane przez administratora należy sprawdzać w Log viewer
• log serwera TACACS+ dla adresu klienta, użytkownika, metody i wyniku

W klastrze HA nie należy zakładać, że istniejąca sesja WebAdmin przetrwa failover bez przerwy. Po planowanej zmianie ról należy wykonać nowe logowanie i sprawdzić, jaki adres źródłowy firewalla rzeczywiście pojawia się na serwerze TACACS+. Jeżeli serwer dopuszcza klientów według adresu źródłowego, świadomie zezwala się na wszystkie adresy występujące w rzeczywistej ścieżce HA.

Logi znajdują się na węźle, który przetworzył zdarzenie. W przypadku HA z niepewnym czasem należy sprawdzić oba węzły lub widok skonsolidowany.

Diagnozowanie według objawu

Test connection kończy się niepowodzeniem

Sprawdzić IP serwera, trasę, port TCP, Shared Secret, definicję klienta i stan serwera. Packet capture może pokazać, czy firewall dociera do serwera i jakiego IP źródłowego używa. Przy braku odpowiedzi lub nieoczekiwanym IP źródłowym nie należy przechodzić do ról użytkowników.

Test connection działa, ale WebAdmin odrzuca użytkownika

Jest to zgodne z brakiem lokalnego profilu administratora. W Authentication > Users sprawdzić, czy użytkownik istnieje, czy ustawiono User type: Administrator i czy przypisano właściwy Device Access Profile. Następnie sprawdzić kolejność w Administrator authentication methods oraz ACL WebAdmin.

Serwer akceptuje hasło, ale działa niewłaściwy profil

W tym przepływie SFOS TACACS+ nie przypisuje automatycznie lokalnego profilu Sophos. Sprawdzić obiekt użytkownika i profil na firewallu. Nie wymyślać atrybutów serwera ani nie nadawać pełnego profilu Administrator jako szybkiego testu.

Logowanie działa tylko do failoveru HA

Na serwerze TACACS+ sprawdzić rzeczywisty adres źródłowy nowego logowania. Następnie zweryfikować trasę, port, definicję klienta i Shared Secret dla aktywnej ścieżki. Stara sesja przeglądarki nie jest dowodem powodzenia; należy użyć nowej sesji.

Nie działa żadne logowanie zewnętrznego administratora

Zalogować się lokalnym kontem admin, sprawdzić stan serwera i kolejność metod, a w razie potrzeby w kontrolowany sposób usunąć TACACS+ z listy administratorów. Nie rozszerzać Device Access do Any ani nie restartować usługi uwierzytelniania jako pierwszego kroku.

Diagnostykę wielu metod opisuje Systematyczne sprawdzanie uwierzytelniania Sophos Firewall.

Offboarding i rollback

Przy offboardingu najpierw zablokować użytkownika na serwerze TACACS+. Następnie sprawdzić na firewallu, czy nadal istnieje aktywna sesja i czy lokalny obiekt użytkownika zewnętrznego nadal ma profil administratora. Blokada po stronie serwera nie gwarantuje natychmiastowego zakończenia każdej istniejącej sesji WebAdmin.

Po teście negatywnym usunąć lokalny profil administratora lub dezaktywować użytkownika. Udokumentować logi audytu i serwera wraz ze zgłoszeniem i czasem. Konto superadministratora admin nie należy do normalnego procesu offboardingu.

Rollback po nieudanym pilotażu:

1. Użyć otwartej lokalnej sesji administratora.
2. Usunąć TACACS+ z Administrator authentication methods lub przywrócić jego udokumentowaną wcześniejszą pozycję.
3. Przywrócić wcześniejszy stan tymczasowych uprawnień portalu i Device Access.
4. Odebrać użytkownikowi pilotażowemu lokalną rolę administratora lub go dezaktywować.
5. Przetestować nowe logowanie lokalnego administratora i normalną ścieżkę uwierzytelniania.
6. Dopiero wtedy usunąć wpis serwera TACACS+, jeżeli nie korzysta z niego żadna inna funkcja.

Lista kontrolna

• lokalne konto admin, MFA i droga odzyskiwania przetestowane
• rzeczywisty adres źródłowy firewalla znany na serwerze TACACS+
• port TCP i Shared Secret są zgodne
• ścieżka do serwera znajduje się w zaufanej lub chronionej sieci
• Test connection zakończony powodzeniem, ale nieuznany za dowód WebAdmin
• użytkownik pilotażowy widoczny jako zewnętrzny obiekt użytkownika
• lokalnie przypisane User type: Administrator i minimalny profil
• Local zachowany jako świadomy fallback
• pozytywny i negatywny test WebAdmin zakończone powodzeniem
• WebAdmin osiągalny tylko z planowanej sieci zarządzającej
• access_server.log, log serwera i Audit Trail skorelowane
• HA lub failover przetestowany przy nowym logowaniu
• offboarding i rollback udokumentowane

Często zadawane pytania