Konfiguracja dostępu serwisowego Avanet do Sophos Firewall

W ramach zgłoszenia serwisowego Avanet może potrzebować tymczasowego, bezpośredniego dostępu do konsoli WebAdmin zapory Sophos Firewall. Taki dostęp jest bezpieczny tylko wtedy, gdy ogranicza się go do znanego źródła wsparcia, niezbędnej usługi i jasno określonego czasu. Globalny dostęp do HTTPS i SSH ze strefy WAN pozostaje przy tym wyłączony; połączenie jest dozwalane za pomocą precyzyjnej reguły Local service ACL exception rule.

W wielu przypadkach wystarczy udostępnienie ekranu albo istniejący, kontrolowany dostęp partnerski. Nowy bezpośredni dostęp z WAN ma sens tylko wtedy, gdy Avanet musi samodzielnie przeprowadzić analizę lub wprowadzić zmiany. SSH należy dodać dopiero wtedy, gdy potrzebny jest dostęp do Device Console, Advanced Shell lub plików dziennika.

Podstawy techniczne opisano w artykule Device Access i Local Service ACL w Sophos Firewall. Przed wprowadzeniem zmian powinna być również dostępna aktualna kopia zapasowa Sophos Firewall.

Ważne: Dostęp serwisowy zapewnia administracyjny dostęp do zapory. Po zakończeniu zgłoszenia użytkownik, reguła ACL i klucz SSH muszą zostać wyłączone lub usunięte, o ile nie uzgodniono stałego dostępu.

Diagnostics > Support access nie zastępuje tej procedury. Funkcja generuje czasowy identyfikator wyłącznie dla Sophos Support, zapewniając dostęp do WebAdmin i powłoki bez danych logowania administratora. Identyfikatora nie wolno przekazywać Avanet.

Ustalenie zakresu i czasu dostępu

Przed konfiguracją należy odnotować w zgłoszeniu:

• jakie działania Avanet może wykonać,
• czy wystarczy WebAdmin, czy potrzebne jest również SSH,
• kiedy dostęp się rozpoczyna i kończy,
• jakie źródło wsparcia Avanet będzie używane,
• kto zatwierdza dostęp i kontroluje jego wycofanie.

Avanet musi podać w uwierzytelnionym zgłoszeniu dokładny publiczny adres wyjściowy albo wyraźnie przeznaczony do tego FQDN. Nie należy zgadywać źródła ani wyprowadzać go ze strony WWW. Przed zmianą trzeba otworzyć i przetestować niezależny dostęp przez konsolę, zarządzającą sieć LAN, VPN administratora lub Sophos Fusion (dawniej Sophos Central).

Istniejącego konta Avanet lub konta partnerskiego nie należy uzupełniać drugim kontem stałym. Zamiast tego trzeba sprawdzić profil, MFA, ograniczenie źródła i status istniejącego konta. Wspólna analiza z udostępnieniem ekranu, bez bezpośredniego logowania, jest często wariantem o najmniejszym ryzyku.

Konfiguracja użytkownika WebAdmin

Ogólny proces dotyczący osobistych kont, profili, MFA i offboardingu opisuje artykuł Bezpieczna konfiguracja administratorów i profili Sophos Firewall. Ten rozdział uzupełnia go o szczególny przypadek wsparcia z okresem dostępu, źródłem wsparcia i kontrolowanym wycofaniem.

Lokalne konto zgłoszenia, na przykład avanet-<ticket>, służy wyłącznie do WebAdmin i ułatwia przypisanie zmian w Audit Trail. SFOS zapisuje nazwę małymi literami i nie pozwala jej później zmienić.

1. Otwórz Authentication > Users.
2. Wybierz Add.
3. Wprowadź nazwę użytkownika i nazwę wyświetlaną.
4. Ustaw User type na Administrator.
5. Wybierz odpowiedni Profile.
6. Wprowadź silne hasło przeznaczone wyłącznie do tego dostępu oraz adres e-mail.

Jako Username można użyć avanet-<ticket>, zastępując <ticket> wewnętrznym numerem. Instrukcja celowo nie publikuje hasła ani adresu wsparcia. Profil Administrator daje pełny dostęp do WebAdmin i powinien być używany tylko w razie konieczności. W innym przypadku w Profiles > Device access należy zacząć od Read-only, a Read-write nadać tylko dla zatwierdzonych zmian.

W sekcji Administrator advanced settings dostępne są dwa dodatkowe ograniczenia:

• Schedule for device access: zezwala na logowanie do konsoli WebAdmin tylko w ramach wybranego harmonogramu.
• Login restriction for device access: zezwala na logowanie wyłącznie z wybranych adresów IPv4 lub zakresu IPv4.

Jeśli stały adres IP wsparcia jest znany, należy dodatkowo dodać go jako Login restriction for device access. Local Service ACL ogranicza wówczas dostępność konsoli, a ograniczenie użytkownika dodatkowo kontroluje możliwość logowania na to konto. Zapisz ustawienia za pomocą Save.

Wcześniejsze sprawdzenie hasła i MFA

Hasło przekazuje się bezpiecznym kanałem i nie umieszcza w e-mailu ani zgłoszeniu. W Authentication > Multi-factor authentication należy wybrać Specific users and groups dla OTP, dodać konto zgłoszenia i zaznaczyć Web admin console w Require MFA for. Sekret, kod QR i kody jednorazowe nie należą do zgłoszenia. Jeśli MFA jest technicznie niemożliwe, należy użyć udostępniania ekranu lub VPN. Zobacz MFA dla administratorów.

Ograniczenie źródła wsparcia i Local Service ACL

Tworzenie obiektu źródłowego potwierdzonego w zgłoszeniu

Na krótkie okno prac najmniejszy zakres zaufania daje host IP zawierający tylko potwierdzony adres publiczny. Jeżeli zgłoszenie wyraźnie wskazuje FQDN, Local Service ACL obsługuje także host FQDN i ufa wszystkim rozwiązanym adresom do wygaśnięcia TTL DNS. Symbole wieloznaczne nie są obsługiwane.

1. Dla stałego IP otwórz Hosts and services > IP host, wybierz Add i zapisz potwierdzony adres jako pojedynczy host IPv4.
2. Tylko dla potwierdzonego FQDN otwórz Hosts and services > FQDN host i wybierz Add.
3. Wprowadź Name związane ze zgłoszeniem i skopiuj dokładną wartość ticketu do FQDN.
4. Zapisz przez Save, ponownie otwórz obiekt i go sprawdź.

Dla FQDN trzeba porównać wszystkie rozwiązane adresy ze zgłoszeniem. Nieoczekiwany lub niepotwierdzony adres jest warunkiem zatrzymania: należy użyć pojedynczego potwierdzonego IP albo poprosić Avanet o wyjaśnienie.

Tworzenie reguły Local Service ACL Exception Rule

HTTPS i SSH są usługami lokalnymi zapory. Zwykłe reguły zapory nie sterują tym ruchem. Dlatego dostęp konfiguruje się w Administration > Device access.

1. Otwórz Administration > Device access.
2. W sekcji Local service ACL upewnij się, że HTTPS i SSH nie są globalnie włączone dla WAN.
3. Przewiń do sekcji Local service ACL exception rule i wybierz Add.
4. Utwórz regułę z poniższymi wartościami.

• Rule name: Avanet-Support
• Rule position: Top
• Description: numer zgłoszenia, cel i planowana data zakończenia
• IP version: IPv4
• Source zone: WAN
• Source Network / Host: dokładnie potwierdzony obiekt IP lub FQDN
• Destination host: publiczny adres zapory lub Any, jeśli zapora musi być dostępna przez kilka odpowiednich adresów WAN
• Services: HTTPS; SSH tylko po potwierdzeniu takiej potrzeby; Ping/Ping6 wyłącznie do konkretnej diagnostyki
• Action: Accept

Zapisz za pomocą Save. Pozycja Top sprawia, że precyzyjna reguła zezwalająca jest sprawdzana przed nakładającą się regułą odrzucającą. Mimo to należy skontrolować istniejące reguły wyjątków: szersza reguła Accept umieszczona wyżej albo niewłaściwa strefa źródłowa mogą zmienić zamierzony model bezpieczeństwa.

Nie używaj: Any ani 0.0.0.0 jako Source. Sophos nie bez powodu uniemożliwia globalne udostępnienie konsoli WebAdmin ze strefy WAN. W tym scenariuszu nie wolno również zaznaczać pola WAN dla HTTPS ani SSH.

Dodawanie SSH tylko w razie potrzeby

SSH zapewnia dostęp do Device Console i Advanced Shell, dlatego ma znacznie szerszy zakres niż ograniczony profil WebAdmin. W wielu zgłoszeniach serwisowych Services pozostaje zatem ograniczone do HTTPS.

Użytkownika avanet nie można używać do połączeń SSH. Sophos Firewall akceptuje w CLI wyłącznie domyślnego użytkownika admin. Klucza publicznego nie przypisuje się zatem do użytkownika avanet, lecz dodaje globalnie w sekcji Public key authentication for admin.

1. Otwórz Administration.
2. Wybierz Device access.
3. Przewiń do sekcji Public key authentication for admin.
4. Włącz Enable authentication.
5. Wklej klucz publiczny zatwierdzony dla bieżącego zgłoszenia w polu Authorized keys i dodaj go za pomocą symbolu plus.
6. Wybierz Apply.

Tylko domyślny administrator może dodawać lub usuwać klucze SSH; w przypadku niestandardowego administratora przycisk Apply nie jest wyświetlany. Sophos obsługuje klucze RSA o długości co najmniej 2048 bitów oraz wybrane klucze DSA i ECDSA, ale nie obsługuje ED25519. Nowy klucz serwisowy powinien być nowoczesny, odpowiednio silny i obsługiwany przez używanego klienta SSH.

Przykładowa struktura klucza publicznego:

ssh-rsa <base64-public-key> avanet-support-<ticket>

Klucz prywatny pozostaje u technika wsparcia i nigdy nie jest przechowywany na zaporze. Po zakończeniu zgłoszenia przypisany do niego klucz publiczny należy usunąć, a SSH wykreślić z reguły wyjątków, o ile nie uzgodniono stałego dostępu. Praktyczny sposób logowania opisano w artykule Łączenie się z Sophos Firewall przez SSH.

Testowanie dostępu i diagnozowanie błędów

Samo pomyślne logowanie z dozwolonego źródła nie wystarcza do odbioru konfiguracji. Trzeba również sprawdzić, czy dostęp z innego źródła internetowego pozostaje zablokowany.

1. Otwórz WebAdmin z uzgodnionego źródła wsparcia Avanet, używając skonfigurowanego portu administratora. Domyślny port to TCP 4444, ale mógł zostać zmieniony w Administration > Admin and user settings.
2. Zaloguj się jako avanet i sprawdź, czy wybrany profil zapewnia dostęp do wymaganych menu.
3. Użyj drugiego, niedozwolonego źródła internetowego. Konsola WebAdmin nie może być z niego dostępna.
4. Jeśli włączono SSH, przetestuj logowanie jako admin za pomocą klucza prywatnego przypisanego do zgłoszenia. Hasło SSH nie jest potrzebne do tego testu.
5. Sprawdź zdarzenia uwierzytelniania w Log viewer. Zmiany konfiguracji należy dodatkowo zweryfikować w Audit Trail.
6. Udokumentuj wynik testu i czas zakończenia dostępu w zgłoszeniu.

Gdy WebAdmin jest niedostępny

Diagnostykę należy rozpocząć od źródła i stopniowo przechodzić w kierunku zapory:

• Czy rzeczywisty adres wyjściowy odpowiada obiektowi źródłowemu i, dla FQDN, aktualnemu wynikowi DNS?
• Czy dostęp rzeczywiście pochodzi ze strefy wybranej w Source zone?
• Czy używany adres WAN odpowiada ustawieniu Destination host?
• Czy reguła wyjątków znajduje się na pozycji Top i obejmuje HTTPS?
• Czy używany jest właściwy port WebAdmin?
• Czy router operatora, urządzenie NAT przed zaporą lub nadrzędna reguła ACL blokują dostęp?
• Czy Login restriction for device access nie blokuje wprawdzie połączenia TCP, ale uniemożliwia zalogowanie użytkownika?

W ramach diagnostyki nie należy włączać globalnych pól WAN dla HTTPS ani SSH. Jeśli reguła wyjątków jest poprawna, nie są one potrzebne do tego precyzyjnie ograniczonego dostępu.

Gdy logowanie się nie udaje

Jeśli konsola jest dostępna, ale logowanie się nie udaje, należy sprawdzić status użytkownika, hasło, MFA, profil, Schedule for device access, Login restriction for device access oraz systemowe ustawienia blokowania logowania w Administration > Admin and user settings. Po kilku nieudanych próbach Sophos Firewall może tymczasowo zablokować źródłowy adres IP dla wszystkich usług logowania.

Kontrolowane wycofanie dostępu

Po zakończeniu zgłoszenia serwisowego należy oddzielnie sprawdzić uzgodnione zmiany oraz sam dostęp:

1. W Audit Trail sprawdź, jakie zmiany konfiguracji zostały wprowadzone przez użytkownika avanet.
2. Przy większych zmianach reguł Sophos Firewall Config Studio może ułatwić porównanie stanu przed zmianami i po nich.
3. Najpierw wyłącz lub usuń Local Service ACL Exception Rule, aby zamknąć ścieżkę zewnętrzną.
4. Z poprzedniego źródła potwierdź brak dostępu do WebAdmin i SSH oraz działanie niezależnej ścieżki administracyjnej.
5. Usuń tylko klucz SSH tego zgłoszenia; wyłącz Enable authentication wyłącznie wtedy, gdy inne klucze go nie potrzebują.
6. Wyłącz lub usuń konto zgłoszenia i jego token MFA, chyba że stały dostęp zatwierdzono wyraźnie.
7. Druga osoba porównuje ACL, konto, klucze, Audit Trail i zgłoszenie ze stanem początkowym.

Świadomie pozostawiony dostęp partnerski nadal wymaga MFA, ściśle ograniczonego źródła, wskazania osoby odpowiedzialnej i regularnych przeglądów. Nieaktywne zgłoszenie nie uzasadnia pozostawienia stale otwartego dostępu administracyjnego.

Często zadawane pytania