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.

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.

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.

Lokalny użytkownik avanet jest przeznaczony wyłącznie do konsoli WebAdmin. Własne konto pozwala lepiej przypisać zmiany w Audit Trail niż korzystanie ze wspólnego konta domyślnego administratora.

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.

Typowe wartości to Username avanet, Name Avanet oraz Email support@avanet.local. Profil Administrator zapewnia pełny dostęp do WebAdmin i CLI. Należy go używać tylko wtedy, gdy zakres zgłoszenia rzeczywiście wymaga takich uprawnień. W przypadku jasno ograniczonych zadań lepszym rozwiązaniem jest własny profil w Profiles > Device access, obejmujący jedynie wymagane uprawnienia Read-only lub Read-write.

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 należy przekazać uzgodnionym bezpiecznym kanałem i nie przechowywać go trwale w wiadomości e-mail ani w treści zgłoszenia. Jeśli stosuje się MFA dla administratorów, przed terminem prac trzeba ustalić sposób konfiguracji tokena, jego przekazania i odpowiedzialność za reset. Krótki test logowania zapobiega rozpoczynaniu właściwego okna serwisowego od problemów z hasłem, rolą lub MFA.

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

Tworzenie hosta FQDN dla support.avanet.com

Local Service ACL obsługuje hosty FQDN jako źródło. Dzięki temu kontrolowana zmiana wychodzącego adresu IP Avanet nie wymaga ręcznego dostosowywania każdej zapory. Zapora korzysta z adresów rozwiązanych przez DNS do czasu wygaśnięcia DNS-TTL. Reguły Local Service ACL Exception Rules nie obsługują symboli wieloznacznych w nazwach FQDN.

1. Otwórz Hosts and services > FQDN host.
2. Wybierz Add.
3. Ustaw Name i FQDN na support.avanet.com.
4. Zapisz za pomocą Save.

Przed przejściem dalej należy sprawdzić, czy support.avanet.com jest rozwiązywany na publiczny adres IP wsparcia podany w zgłoszeniu. Jeśli rzeczywisty wychodzący adres IP nie odpowiada wynikowi DNS, ACL prawidłowo odrzuci dostęp.

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: obiekt FQDN support.avanet.com
• 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 support.avanet.com jest rozwiązywany na rzeczywisty publiczny wychodzący adres IP?
• 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. Wyłącz lub usuń użytkownika avanet, jeśli nie uzgodniono stałego dostępu partnerskiego.
4. Wyłącz lub usuń regułę Local Service ACL Exception Rule.
5. Usuń klucz publiczny SSH przypisany do zgłoszenia.
6. Z dotychczasowego źródła wsparcia sprawdź, czy WebAdmin i SSH nie są już dostępne.

Ś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