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: osiągalność i Shared Secret do serwera TACACS+, pomyślne zewnętrzne uwierzytelnienie użytkownika oraz lokalną rolę administratora na firewallu. Zielony wynik Test connection potwierdza tylko pierwszą warstwę.

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, Shared Secret i konto pilotażowe.
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 kontrolowanie 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 kontrolowanie przetestować awarię ścieżki TACACS+.

Co SFOS kontroluje przez TACACS+

Sophos Firewall używa skonfigurowanego serwera TACACS+ jako metody uwierzytelniania dla wybranych usług. W Authentication > Services SFOS wymienia dla TACACS+ metody PAP i CHAP. Właściwą metodę należy uzgodnić z drugą stroną i potwierdzić w logu serwera.

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 dokumentacyjnymi i należy je zastąpić rzeczywistym adresem serwera oraz zatwierdzoną siecią zarządzającą. TCP 49 to zarejestrowany domyślny port TACACS+, ale port wpisany w SFOS 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.

Aktualny formularz SFOS dokumentuje dla TACACS+ adres IP, port i Shared Secret, ale nie przełącznik TLS. Klasyczny TACACS+ nie chroni zawartości pakietów tak jak nowoczesne połączenie TLS. Dlatego ścieżka do serwera nie może przebiegać bez ochrony przez Internet ani obcą sieć. 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+.
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, ż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ń.

Bezpieczne nadawanie 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. Przy kilku serwerach SFOS przekazuje żądanie w pokazanej kolejności. Kolejność jest więc częścią projektu bezpieczeństwa, a nie wartością kosmetyczną.

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

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 i wywołanych przez administratora
• 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 kontrolowanie 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