Konfigurowanie dostępu wsparcia Avanet na Sophos Firewall

W przypadkach wsparcia, planowanych zmianach lub wspólnej analizie błędów może być sensowne tymczasowe udzielenie Avanet dostępu do Sophos Firewall. Taki dostęp nie powinien jednak polegać na tym, że WebAdmin lub SSH są ogólnie dostępne z Internetu. Lepszym rozwiązaniem jest jasno ograniczony dostęp wsparcia z własnym użytkownikiem administracyjnym, zdefiniowanym źródłem i udokumentowanym wycofaniem.

Niniejsza instrukcja opisuje typowy przebieg dostępu przez HTTPS/WebAdmin i opcjonalnie SSH. Dla ogólnych podstaw dotyczących lokalnych usług firewall dodatkowo pasuje Device Access i Local Service ACL na Sophos Firewall. Jeśli używane jest SSH, warto również znać Łączenie się z Sophos Firewall przez SSH.

⚠️ Dostęp wsparcia to administracyjny dostęp do firewalla. Powinien być aktywny tylko przez potrzebny czas, możliwie ściśle ograniczony do źródła wsparcia i po zakończeniu sprawy ponownie sprawdzony lub usunięty.

Ustalenia przed konfiguracją

Przed udzieleniem dostępu warto krótko ustalić, jaki dostęp jest naprawdę potrzebny. Do wielu zadań wystarczy HTTPS/WebAdmin. SSH powinno być aktywowane tylko wtedy, gdy naprawdę potrzebne są pliki logów, CLI lub Advanced Shell. Ponadto należy ustalić, z jakiego źródła dostęp będzie dozwolony, kiedy dostęp zostanie usunięty i czy przed większymi zmianami istnieje aktualna kopia zapasowa.

Jeśli już istnieje ogólne konto administratora lub partnera, nie powinno się po prostu tworzyć kolejnego trwałego konta. W takich przypadkach lepiej jest sprawdzić istniejący dostęp, kontrolować MFA i role oraz tylko tymczasowo zezwolić na źródło.

Model bezpieczeństwa dla dostępu supportowego

Dostępu supportowego nie należy traktować jak zwykłego stałego konta. To dostęp operacyjny, który powinien być jasny, ograniczony i łatwy do usunięcia po zakończeniu sprawy.

Możliwe warianty:

• Tymczasowy użytkownik avanet: przydatny, gdy zaplanowano termin supportu i dostęp ma zostać potem usunięty.
• Dedykowany admin supportowy: przydatny przy regularnym supportcie, ale tylko z silnym hasłem, MFA i ograniczonymi źródłami dostępu.
• Krótkotrwałe włączenie SSH lub WebAdmin: przydatne dla konkretnego okna troubleshooting, ale potem należy je wyłączyć lub ponownie ograniczyć.
• Dostęp przez Sophos Central lub sesję zdalną: przydatny, gdy nie chce się otwierać bezpośredniego inbound management access.

Ważne jest, aby przed terminem zdefiniować dostęp, metodę uwierzytelniania, ograniczenie źródeł i rollback. Przy zmianach na firewallach produkcyjnych musi też być jasne, kto zatwierdza zmianę i gdzie jest dokumentowana. Dla śladów audytowych przydatne są configuration audit logs, a przy większych zmianach Config Studio.

Ustal hasło, MFA i sposób przekazania

Dostęp techniczny to tylko część przygotowania supportu. Równie ważne jest, jak przekazywane są dane dostępowe i jak dostęp jest chroniony.

• Użyć unikalnego hasła tylko dla tego firewalla i tego dostępu supportowego.
• Nie wysyłać hasła razem ze wszystkimi szczegółami dostępu tym samym kanałem.
• Włączyć MFA, jeśli konto pozostaje aktywne dłużej lub pozwala na dostęp WebAdmin.
• Udokumentować, czy dostęp jest tymczasowy czy stały.
• Ustalić, kto dezaktywuje lub usuwa konto po sprawie supportowej.
• Jeśli potrzebny jest SSH, preferować public key authentication, gdy to możliwe.

Dla kont adminów właściwym artykułem uzupełniającym jest MFA dla Sophos Firewall. Dla SSH metoda public key jest lepsza, jeśli pasuje do workflow supportu.

Dodawanie użytkownika avanet

Użytkownik avanet jest przeznaczony do dostępu WebAdmin. Dzięki temu w Audit Trail można lepiej śledzić, że zmiana została dokonana w ramach sprawy wsparcia. Użytkownik powinien otrzymać silne hasło i być aktywny tylko tak długo, jak jest potrzebny.

1. Otwórz Authentication w lewym menu nawigacyjnym.
2. Wybierz Users.
3. Kliknij Add.

Typowe wartości:

• Username: avanet
• Full name: Avanet
• Profile: Administrator, jeśli Avanet musi w pełni sprawdzić lub zmienić firewall
• Password: silne jednorazowe lub hasło wsparcia z menedżera haseł
• Email: na przykład service@avanet.com

Następnie zapisz za pomocą Save lub Add.

Jeśli planowane są tylko bardzo ograniczone zadania, bardziej odpowiedni może być węższy profil administratora. W wielu przypadkach wsparcia Avanet potrzebuje jednak tymczasowo pełnych uprawnień, ponieważ przyczyna, logi, reguły, NAT, VPN, routing i stan systemu często muszą być sprawdzane razem.

Tworzenie hosta FQDN dla support.avanet.com

Aby reguła ACL nie dotyczyła dowolnych źródeł internetowych, najpierw tworzony jest obiekt hosta dla źródła wsparcia Avanet.

1. Otwórz Hosts and services.
2. Wybierz FQDN hosts.

Następnie dodaj nowy obiekt FQDN:

• Name: support.avanet.com
• FQDN: support.avanet.com
• Description: Dostęp wsparcia Avanet

Zapisz za pomocą Save. Firewall rozwiązuje FQDN przez DNS i używa obiektu jako źródła w lokalnej regule ACL.

Konfigurowanie reguły wyjątku Local Service ACL

Dostępy do WebAdmin i SSH to lokalne usługi firewalla. Nie są one obsługiwane przez normalne reguły firewalla, lecz przez Administration > Device access i Local service ACL exception rule.

1. Otwórz Administration.
2. Wybierz Device access.
3. Przewiń do sekcji Local service ACL exception rule.
4. Kliknij Add.

Reguła powinna być ustawiona możliwie jak najściślej:

• Rule name: Avanet Support
• Rule position: odpowiednia do istniejącej struktury ACL, często Bottom
• IP version: IPv4, lub dodatkowo IPv6, jeśli jest to wyraźnie potrzebne
• Source zone: Strefa, z której pochodzi dostęp wsparcia, często WAN
• Source Network / Host: Obiekt FQDN support.avanet.com
• Destination host: Any lub konkretnie adres firewalla, w zależności od środowiska
• Services: HTTPS; SSH tylko jeśli naprawdę potrzebne
• Action: Accept

Następnie zapisz i sprawdź pozycję reguły. Jeśli powyżej znajduje się szersza reguła odrzucenia lub wyjątku, nowa reguła może być nieskuteczna.

⚠️ Any jako źródło nie jest dobrym rozwiązaniem dla dostępu wsparcia do WebAdmin lub SSH. Jeśli źródło nie jest ustalone, najpierw należy skonsultować się z Avanet, jakie źródło wsparcia będzie używane. Szerokie udostępnienie natychmiast zwiększa powierzchnię ataku firewalla.

Opcjonalnie: Dodanie klucza publicznego SSH

SSH jest potrzebne tylko wtedy, gdy konieczna jest analiza przez Device Console, pliki logów lub Advanced Shell. W wielu przypadkach wsparcia wystarcza WebAdmin.

Ważne jest rozróżnienie: wcześniej dodany użytkownik avanet jest użytkownikiem WebAdmin. Dostęp SSH do Sophos Firewall odbywa się zazwyczaj za pomocą użytkownika admin. Klucz publiczny SSH jest zatem umieszczany 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, jeśli uwierzytelnianie kluczem publicznym nie jest jeszcze aktywne.
5. Dodaj dostarczony przez Avanet klucz publiczny w Authorized keys.
6. Zapisz.

Przykład klucza publicznego Avanet:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCktco/uC29KdU+Hf7GjcYXFumGJvt11MPxhdpnYA2XVEbnsI9r/XrW9J9K2ugvVGNoOD4IlN/bWZ1z3W6UqFKGgHUYkQu2h+0PFzP5I12Pu9I/3qIWwOhdA2j523FzneGQFptNCHHLQwma/zYJJwcVqsiJo/mg6W8jUbS30jFP6zDJvGRzbA2ATC7XzGNfa/CYr/AKoqdvm87RThOT7uh86w39x9VQTZH7d217K2UVuUrSppvnRaw5NCwukamWDDs8EtsVIFNkkxMl/SdJTC1SOSfO6mw8erXm1RhmNT5+wN/87f+DQioQPuWSrC3EHkgqw9BjoU3aLtYUw9AAItf6jJeUnZBfBCeJ1fJAzYpR8STdbaI8RXP1QMOr4omtmCakfnEH8kZ1BAYXxVzrJBXQ+sDVLZtWNDPqg8jIpdJ6bRNk/m7B+LAwsofHVLH1VSxoOEYdJGQvPfwonqo2JR+vosYhoHG89eh5EL/X9z5amvfVCShf6icstYwmaUmT/9lUTd8tkJZeTxNoezyspHhMryfB93653vb6wPS/n0ITkfu6rSfSrE1A1Y1dD5QtsFF6oEZxPqo8qQajtGhI3vZdHZSx53PqFqInra75xFHc+EjEsoLjt2wQdHr+ttEKvfrjfQmyXaWzqqE6bxmbbcMPtqY+pzMf83nEGwepJka0uw==

Klucz prywatny nie jest przechowywany na firewallu i nigdy nie powinien być przekazywany przez e-mail lub czat. Na firewallu tylko klucz publiczny powinien być umieszczony w polu dla autoryzowanych kluczy.

Testowanie dostępu

Po zapisaniu nie należy uznawać dostępu za zakończony bez testu. Warto przeprowadzić krótki test funkcjonalny:

1. Przetestuj dostęp WebAdmin przez uzgodnione źródło wsparcia Avanet.
2. Sprawdź logowanie za pomocą użytkownika avanet.
3. Jeśli SSH jest potrzebne: przetestuj połączenie z admin i kluczem publicznym.
4. W Log viewer i ewentualnie w Audit Trail sprawdź, czy logowanie i późniejsze zmiany są śledzone.
5. Udokumentuj, kiedy dostęp zostanie wyłączony lub usunięty.

Jeśli dostęp nie działa, najpierw sprawdź źródło i regułę ACL. Następnie sprawdź rozwiązywanie DNS obiektu FQDN, pozycję reguły, Device Access, urządzenia NAT i routing.

Wycofanie dostępu po zakończeniu wsparcia

Po zakończeniu sprawy wsparcia dostęp nie powinien pozostać niezmieniony na stałe. W zależności od umowy istnieją trzy czyste warianty:

• Dezaktywacja użytkownika: Jeśli w przyszłości przewidywane jest dalsze wsparcie, ale obecnie nie jest potrzebny dostęp.
• Dezaktywacja reguły ACL: Jeśli konto ma pozostać, ale nie może być możliwy zewnętrzny dostęp.
• Usunięcie użytkownika i reguły ACL: Jeśli dostęp był potrzebny tylko jednorazowo.

Dodatkowo należy sprawdzić, czy klucz publiczny SSH można usunąć. Jeśli dokonano zmian na firewallu, do kontroli pasują Backup i Restore na Sophos Firewall, Audit Trail Logs i przy zmianach w regułach Config Studio.

Lista kontrolna

• Utworzono użytkownika avanet z silnym hasłem.
• Świadomie wybrano i udokumentowano profil administratora.
• Utworzono hosta FQDN support.avanet.com.
• Reguła wyjątku Local Service ACL ograniczona do źródła wsparcia Avanet.
• Zezwolono tylko na potrzebne usługi: HTTPS, SSH tylko w razie potrzeby.
• Klucz publiczny SSH umieszczony tylko w sekcji Public key authentication for admin.
• Przetestowano dostęp i udokumentowano w zgłoszeniu.
• Zaplanowano wycofanie lub dezaktywację po zakończeniu.

Często zadawane pytania