Łączenie z Sophos Firewall przez SSH

Do wielu zadań wsparcia i troubleshootingu potrzebny jest dostęp do Sophos Firewall przez SSH. Należą do nich na przykład analizy logów, restarty usług, specjalne polecenia diagnostyczne czy praca w Advanced Shell.

Ale SSH to także dostęp do zarządzania obarczony wysokim ryzykiem. Dlatego dostęp powinien być dozwolony wyłącznie z zaufanych sieci administracyjnych, poprzez ukierunkowaną regułę wyjątku Local Service ACL lub poprzez jasno zdefiniowany dostęp do pomocy technicznej. Do ogólnego wzmocnienia lokalnych usług zapory ogniowej odpowiedni jest również Skonfiguruj poprawnie Device Access.

Wymagania

Do połączenia SSH z Sophos Firewall potrzebne są:

• Dostęp administracyjny do Sophos Firewall.
• Adres IP lub nazwa DNS zapory sieciowej.
• Dostęp do użytkownika admin.
• Zmienione i bezpiecznie udokumentowane hasło domyślnego administratora; fabryczne hasło nie może pozostać używane w środowisku produkcyjnym.
• Zaufane źródło administratora, na przykład sieć zarządzania, VPN lub stały adres IP administratora.
• W systemie macOS lub Linux: preinstalowana aplikacja Terminal z SSH.
• W systemie Windows: Terminal Windows z OpenSSH lub PuTTY.
• Dostęp SSH dozwolony w Administration > Device access lub przez Local service ACL exception rule.
• W przypadku planowanych zmian w Advanced Shell: kopia zapasowa, okno konserwacji i jasna ścieżka wycofania.

⚠️ SSH powinien być dozwolony tylko z zaufanych sieci. W środowiskach produkcyjnych lepiej jest ograniczyć dostęp do adresu IP zarządzania lub sieci administracyjnej, niż ogólnie wypuszczać SSH.

Określenie celu dostępu SSH

Nie każda analiza wymaga Advanced Shell. Przed zalogowaniem powinno być jasne, która konsola jest wymagana i jak poważna jest interwencja.

• Routing, DNS, Ping, proste polecenia systemowe: Device Console. Sophos CLI, mniej ryzykowny niż Advanced Shell.
• Szczegółowe informacje systemowe, bazy danych lub usługi systemowe: może być potrzebna Advanced Shell. Bez wiarygodnej instrukcji Sophos dotyczącej konkretnego przypadku ogranicz się do kontroli tylko do odczytu i niczego nie zmieniaj ani nie usuwaj.
• Sprawdź status usługi lub debuguj: Advanced Shell. Tylko specjalnie aktywuj debugowanie i dezaktywuj je ponownie.
• Wykonaj nieznane polecenia: Najpierw sprawdź lub otwórz zgłoszenie do pomocy technicznej. Nie próbuj w systemie produkcyjnym.

Rozróżnienie jest ważne, ponieważ Device Console i Advanced Shell używają innej składni. Wiele błędów pojawia się po prostu dlatego, że poprawne polecenie zostało wprowadzone w niewłaściwym miejscu. Szerszy przegląd jest dostępny w Sophos Firewall Rozwiązywanie problemów: Services i dzienniki.

Zezwalanie na dostęp SSH do zapory

Aby połączenie było możliwe, Sophos Firewall musi zezwalać na SSH w odpowiedniej strefie lub poprzez regułę wyjątku Local Service ACL.

1. Zaloguj się do administratora sieciowego Sophos Firewall.
2. Otworzyć Administration.
3. Wybierz Device access.
4. Sprawdź, czy SSH jest dozwolony dla żądanej strefy.

W przypadku wewnętrznych sieci administracyjnych SSH można aktywować bezpośrednio dla odpowiedniej strefy, np. dla LAN. Jeśli dostęp ma być bardziej szczegółowo ograniczony, sensowna jest reguła wyjątku ACL usługi lokalnej.

Device Access kontroluje dostęp do samej zapory sieciowej. Nie jest to to samo, co zwykła reguła zapory, która zezwala na ruch przez zaporę. Jeśli SSH w Device Access jest włączone zbyt szeroko, klient może dotrzeć do lokalnej usługi SSH zapory nawet wtedy, gdy klasyczna reguła LAN-to-WAN jest poprawnie skonfigurowana.

Ważne jest również rozróżnienie między SSH a webową CLI Console: klient SSH potrzebuje dostępu SSH przez TCP 22. Jeśli CLI Console jest otwierana z menu WebAdmin, dla odpowiedniej strefy musi być natomiast dozwolony HTTPS.

Przed zmianą zanotuj strefy, w których SSH jest obecnie włączone, oraz istniejące wyjątki SSH. Pozwoli to przywrócić stan początkowy bez usuwania innego zamierzonego zezwolenia.

W sekcji Local service ACL exception rule kliknij Add i ustaw możliwie restrykcyjne wartości:

• Name: na przykład SSH-z-sieci-admin; nazwa dowolna, ale jednoznaczna
• Rule position: pozycja wyjątku w Local Service ACL
• Description: cel, odpowiedzialny zespół i data zakończenia dostępu tymczasowego
• IP version: IPv4 lub IPv6 odpowiednio do źródła administracyjnego i adresu docelowego
• Source zone: strefa, z której odbywa się administracja
• Source Network / Host: adres IP administratora lub sieć zarządzająca
• Destination host: adres IP zapory lub interfejs, który ma być administrowany, jeśli dostęp można dodatkowo ograniczyć do konkretnego adresu docelowego
• Services: SSH
• Action: Accept

Zapisz za pomocą Save. Dla jednego systemu administracyjnego Source Network / Host może być obiektem hosta zawierającym 192.0.2.10. Jest to adres dokumentacyjny; zastąp go rzeczywistym, najlepiej stałym adresem IP administratora. Destination host ogranicza dodatkowo adres IP zapory, przez który usługa jest osiągalna. Nie obejmuj wszystkich interfejsów bez uzasadnienia operacyjnego.

Otwórz nową sesję SSH z zamierzonego źródła administracyjnego. Test kończy się powodzeniem, gdy pojawi się menu konsoli. Następnie wykonaj próbę z celowo niedozwolonej sieci i potwierdź, że sesja nie zostaje nawiązana. Przy nieoczekiwanym wyniku pozostaw istniejącą sesję WebAdmin otwartą i sprawdź źródłowy adres IP, Source zone, IP version, Destination host, pozycję reguły oraz filtry nadrzędne.

Jeśli dostęp był tymczasowy, usuń tylko ten wyjątek w Administration > Device access > Local service ACL exception rule i potwierdź przyciskiem OK. Jeśli zmieniono pole wyboru strefy, przywróć wyłącznie jego zanotowany stan i kliknij Apply. Następnie wykonaj próbę z tego samego źródła i sprawdź, czy SSH jest ponownie dostępne lub zablokowane dokładnie tak jak przed zmianą. Test potwierdza w ten sposób stan początkowy, bez zakładania, że logowanie zawsze powinno się udać albo nie udać.

SSH nie powinien być dostępny w sposób niekontrolowany z Internetu. Jeśli konieczny jest dostęp zewnętrzny, powinien on być dozwolony wyłącznie za pośrednictwem jasno określonego źródłowego adresu IP, VPN lub dedykowanego dostępu do pomocy technicznej.

Diagnostics > Support access jest osobnym mechanizmem. Nie otwiera po prostu SSH z internetu, lecz umożliwia Sophos Support tymczasowy dostęp przez kanał wsparcia zestawiany przez zaporę. Ten dostęp również powinien być ograniczony czasowo i wyłączony po zakończeniu sprawy wsparcia.

Podczas włączania Support access wybiera się czas trwania, po czym zapora generuje unikalny access ID dla Sophos Support. Sophos Support może użyć go do dostępu do WebAdmin i shell bez zwykłych poświadczeń administracyjnych. Zapora sama zestawia połączenie do Sophos Support przez TCP 22; operacyjnie jest to coś innego niż dopuszczenie przychodzącego SSH z WAN.

W WebAdmin otwiera się Diagnostics > Support access, włącza Support access i potwierdza przyciskiem OK. Następnie wybiera się czas potrzebny dla konkretnej sprawy wsparcia, klika Apply i ponownie potwierdza przyciskiem OK. Zapora zestawia bezpieczne połączenie sterujące ze swoim serwerem proxy dostępu; wygenerowany access ID znajduje się w Access status i jest przekazywany wyłącznie Sophos Support przez uzgodniony kanał wsparcia.

Sterowanie Support access z Device Console

SFOS 22 może również włączyć kanał wsparcia w 4. Device Console. Po udanej aktywacji polecenie wyświetla access ID i czas dostępu:

set support_access enable

Polecenie stanu tylko do odczytu, wykonane w tej samej Device Console, pokazuje, czy kanał jest aktywny, a jeśli tak — jego access ID i czas trwania:

show support_access

Access ID i czas trwania przekazuje się wyłącznie w powiązanej sprawie wsparcia. Nie należy kopiować ich do ogólnej dokumentacji, czatów ani magazynów haseł. Po zakończeniu analizy kanał wyłącza się niezależnie od pozostałego czasu:

set support_access disable

Następnie w Diagnostics > Support access sprawdza się, czy dostęp nie jest już aktywny. disable nie zmienia zwykłej konfiguracji SSH w Device Access ani Local Service ACL Exception Rules, dlatego tymczasowe uprawnienia administratora i SSH usuwa się oddzielnie.

Jeśli przed zaporą znajduje się dodatkowy router lub filtr ruchu wychodzącego, musi zezwalać na TCP 22 do *.apu.sophos.com. Nie wymaga to tworzenia przychodzącej reguły WAN w Sophos Firewall. Nieaktywne sesje wsparcia są zamykane po 15 minutach; wybrany całkowity czas dostępu i możliwość ręcznego wyłączenia Support access pozostają niezależne od tego limitu bezczynności.

Artykuł Sprawdzanie usług i portów wychodzących Sophos Firewall porządkuje pozostałe cele producenta dla aktualizacji, licencji, RED, Central, reporting i backupów.

Dodawanie klucza publicznego dla admin

W przypadku dostępu SSH preferowaną metodą jest uwierzytelnianie za pomocą klucza publicznego. W Sophos Firewall klucz publiczny użytkownika admin może być przechowywany pod Administration > Device access. Logowanie za pomocą hasła może być konieczne w sytuacjach awaryjnych, ale nie powinno pozostać najwygodniejszym dostępem domyślnym.

⚠️ Logowanie SSH do Sophos Firewall jest możliwe tylko z użytkownikiem admin. Inni użytkownicy WebAdmin nie mogą logować się poprzez SSH.

Ważne: Tylko domyślny administrator może zmieniać uwierzytelnianie kluczem publicznym dla SSH, tj. dodawać lub usuwać klucze. W przypadku operacji oznacza to: Kluczowe zmiany należą do udokumentowanego procesu administracyjnego i nie należy ich traktować jako spontanicznego skrótu do pomocy technicznej.

Domyślny administrator nie jest zwykłym kontem roli, które można po prostu zastąpić. Sophos wskazuje, że nazwy tego konta nie można zmienić ani go usunąć. Dlatego hasło domyślnego administratora, informacje MFA lub recovery dla interaktywnych logowań administracyjnych oraz zapisane klucze publiczne SSH powinny być zarządzane razem w procesie administracyjnym. Klucz publiczny nie zastępuje właściwego zarządzania tym kontem.

Nazwane konta administratorów WebAdmin są zarządzane oddzielnie i nie mogą logować się przez SSH przy użyciu własnej nazwy użytkownika. Artykuł Zarządzanie lokalnymi administratorami i profilami Device Access zgodnie z zasadą najmniejszych uprawnień opisuje cykl życia i uprawnienia tych kont.

Przed dodaniem klucza publicznego do zapory wygeneruj na własnym kliencie administracyjnym parę odpowiadających sobie kluczy publicznego i prywatnego za pomocą narzędzia do kluczy SSH. Można ponownie wykorzystać istniejącą, odpowiednią parę odpowiadających sobie kluczy. W kwestii typu i długości klucza stosuj się do wskazówek w następnej sekcji dotyczącej obsługiwanych typów kluczy SSH. Przechowuj i chroń klucz prywatny wyłącznie na kliencie administracyjnym; nigdy go nie udostępniaj ani nie przesyłaj do zapory. Na potrzeby kolejnych kroków skopiuj tylko klucz publiczny.

Klucz publiczny jest dodawany w obszarze Public key authentication for admin:

1. Otworzyć Administration.
2. Wybierz Device access.
3. Przewinąć do obszaru Public key authentication for admin.
4. Włączyć Enable authentication.
5. Dodaj klucz publiczny pod Authorized keys.
6. Zapisać przez Apply.

Pozostaw istniejącą sesję WebAdmin lub SSH otwartą podczas testowania nowego klucza w drugiej sesji SSH. Stary klucz można usunąć, a zapasowe logowanie hasłem zmienić dopiero po wyświetleniu menu konsoli w drugiej sesji. Jeśli test się nie powiedzie, dotychczasowy dostęp pozostaje dostępny: sprawdź typ klucza, wpis klucza publicznego, odpowiadający mu klucz prywatny i dozwolone źródło, a następnie usuń tylko nowy błędny wpis.

Klucz prywatny zawsze pozostaje w kliencie administracyjnym i nie można go udostępniać. Na zaporze przechowywany jest tylko klucz publiczny.

Jeśli wielu administratorów korzysta z SSH, ten sam klucz prywatny nie powinien być udostępniany. Lepiej mieć osobnych klientów administracyjnych, udokumentowane klucze publiczne i sprawdzić, które klucze są jeszcze potrzebne. Po zmianie personelu lub usługodawców należy sprawdzić obszar Authorized keys.

Obsługiwane typy kluczy SSH

Nie każdy nowoczesny typ klucza SSH jest równie odpowiedni dla Sophos Firewall. Przed wdrożeniem należy sprawdzić, czy typ klucza jest obsługiwany.

• RSA: Użyj co najmniej 2048 bitów.
• DSA: Co najmniej 2048 bitów, jeśli jest to konieczne ze względu na kompatybilność.
• ECDSA: Obsługiwany; ED25519 nie jest akceptowany do tego celu.
• ED25519: W przypadku SSH Public Key Authentication nie stosować w przypadku Sophos Firewall.

W przypadku nowego dostępu administracyjnego odpowiednio zarządzany klucz RSA lub obsługiwany klucz ECDSA jest zwykle bardziej pragmatyczny niż nowoczesny typ klucza, którego nie akceptuje zapora ogniowa lub starsze narzędzie SSH.

Łączenie z systemu macOS lub Linux

Klient SSH jest zwykle już obecny na systemach macOS i Linux. Połączenie zostaje nawiązane w terminalu.

Przykład:

ssh admin@192.0.2.1

192.0.2.1 zostaje zastąpiony adresem IP lub nazwą DNS Twojego własnego Sophos Firewall.

Przy pierwszym nawiązaniu połączenia klient SSH pyta, czy zaakceptować odcisk palca systemu docelowego. Należy sprawdzić ten odcisk palca, a następnie potwierdzić.Jeśli po ponownym obrazie, wymianie sprzętu lub zmianie adresu IP pojawi się ostrzeżenie o zmienionym kluczu hosta, nie należy ślepo akceptować nowego odcisku palca. Najpierw sprawdź, czy ta sama zapora sieciowa rzeczywiście została wymieniona, ponownie zainstalowana lub przeniesiona na nowy adres IP. Dopiero wtedy można wyczyścić stary wpis w ~/.ssh/known_hosts i zaakceptować nowy odcisk palca.

W zależności od konfiguracji żądane jest wówczas hasło użytkownika admin lub logowanie odbywa się przy użyciu zapisanego klucza SSH.

Jeśli ma zostać użyty konkretny klucz prywatny:

ssh -i ~/.ssh/sophos-admin-key admin@192.0.2.1

W przypadku dostępu cyklicznego należy udokumentować ścieżkę klucza, dozwolony źródłowy adres IP i cel. Wpisu known_hosts nie należy kopiować do zgłoszeń ani historii czatów; W przypadku ostrzeżeń o kluczach hosta historia zmian jest ważniejsza niż szybkie obejście.

Łączenie za pomocą PuTTY

W systemie Windows możesz użyć terminala Windows z OpenSSH lub użyć PuTTY.

W przypadku terminala Windows nawiązanie połączenia działa podobnie jak w systemie macOS lub Linux:

ssh admin@192.0.2.1

Dla PuTTY:

1. Otwórz PuTTY.
2. Wpisać adres IP lub nazwę DNS Sophos Firewall w polu Host Name.
3. Ustaw Port na 22.
4. Ustawić Connection type na SSH.
5. Połączyć się przez Open.
6. Sprawdź i potwierdź odcisk palca SSH.
7. Zaloguj się jako użytkownik admin i użyj hasła lub klucza SSH w zależności od konfiguracji.

Po zalogowaniu pojawia się menu konsoli Sophos Firewall.

Jeśli PuTTY jest używany z kluczem prywatnym, klucz musi odpowiadać kluczowi publicznemu przechowywanemu na zaporze ogniowej. Po zmianie personelu lub usługodawcy należy zmienić nie tylko hasło; stare klucze publiczne również muszą zostać usunięte z Authorized keys.

Otwieranie Device Console lub Advanced Shell

Po pomyślnym zalogowaniu się poprzez SSH, zapora wyświetli menu konsoli. Wybór opcji zależy od tego, co chcesz osiągnąć.

W przypadku wielu poleceń SFOS używasz:

4. Device Console

Do głębszych zadań związanych z Linuksem lub systemem plików użyj Advanced Shell poprzez:

5. Device Management
3. Advanced Shell

Advanced Shell oferuje bardzo szeroki dostęp do systemu. Polecenia powinny być tam wykonywane tylko wtedy, gdy jest jasne, co robią.

Według Sophos zmiany konfiguracji wykonane bezpośrednio w Advanced Shell, na przykład w interfejsach, regułach lub politykach, nie zachowują się po restarcie i nie trafiają do kopii zapasowych. Nie jest to więc zwykła metoda konfiguracji. Pliki w /tmp/ również są usuwane podczas restartu.

• Device Console: ping, dnslookup, traceroute, show, Opcje routingu lub systemu.
• Advanced Shell: szczegółowe informacje systemowe, bazy danych, usługi systemowe i diagnostyka konkretnego przypadku zlecona przez Sophos Support.

Do analizy dzienników, nazw usług i typowych wzorców błędów lepszym punktem wyjścia niż zapamiętywanie poszczególnych poleceń jest Sophos Firewall Rozwiązywanie problemów: Services i dzienniki.

Kończenie połączenia

Po zakończeniu pracy sesja SSH powinna zakończyć się czysto:

exit

Jeżeli znajdujesz się w podmenu, może zaistnieć konieczność najpierw powrotu do menu głównego, a następnie zakończenia sesji.

Sophos Firewall zamyka nieaktywne sesje SSH po 15 minutach. Nie zastępuje to czystego wylogowania: otwarte sesje, tryby debugowania i tymczasowe reguły dostępu nadal należy świadomie zamknąć albo usunąć.

Jeśli SSH został aktywowany tylko tymczasowo na potrzeby wsparcia, należy wówczas usunąć lub dezaktywować tę wersję. Jest to szczególnie prawdziwe w przypadku wyjątków ACL pochodzących z zewnętrznych adresów IP lub dostępu dostawcy usług.

Po głębokich interwencjach należy również sprawdzić:

• Czy debugowanie jest ponownie wyłączone?
• Czy tymczasowa reguła wyjątku ACL została usunięta lub wyłączona?
• Czy na zaporze nie pozostawiono niepotrzebnie plików tymczasowych, zrzutów pomocniczych lub nagrań?
• Czy wyciągi z dziennika, czas, polecenie i wynik są udokumentowane w zgłoszeniu lub zmianie?
• Czy klucz SSH był używany tylko do zaplanowanego dostępu administracyjnego lub pomocy technicznej?

Typowe problemy

Połączenie zostało odrzucone

Jeśli połączenie zostanie odrzucone, SSH zwykle nie jest dozwolony na zaporze dla wybranej strefy lub źródła. W takim przypadku należy zaznaczyć Administration > Device access. Dodatkowo sprawdź, czy reguła wyjątku ACL zezwala na źródło lub czy szersza wersja dostępu do urządzenia została celowo usunięta.

Przekroczono limit czasu połączenia

Limit czasu często wskazuje, że zapora sieciowa nie jest dostępna za pośrednictwem wybranego adresu IP, brakuje trasy lub zapora sieciowa nadrzędna blokuje dostęp.

Jeśli zapora, której konfiguracja nie została jeszcze ukończona, nadal używa fabrycznego hasła domyślnego, SFOS celowo odrzuca połączenia SSH ze strefy WAN bez komunikatu o błędzie. Jest to zabezpieczenie. Najpierw należy zmienić hasło przez dozwoloną lokalną ścieżkę administracyjną; nie wolno rozszerzać Device Access ani listy ACL jako obejścia.

Brak dostępu sieciowego do zapory

Jeśli nie jest dostępny ani WebAdmin, ani SSH, nie należy pochopnie otwierać dodatkowego dostępu z WAN lub innych stref. Czystszą ścieżką awaryjną jest lokalny dostęp konsolowy do urządzenia, na przykład przez kabel konsolowy albo, w obsługiwanych modelach, przez micro USB. Jest to szczególnie ważne, gdy Device Access, routing lub strefy interfejsów zostały ustawione nieprawidłowo.

Logowanie nie powiodło się

Jeżeli logowanie się nie powiedzie, należy sprawdzić użytkownika admin, hasło lub klucz SSH oraz dozwolone sieci źródłowe. Typowe komunikaty, takie jak Permission denied (publickey,password), wskazują nieprawidłowe hasło, nieprawidłowy klucz prywatny lub brakującą konfigurację klucza publicznego.

Jeżeli logowanie kluczem publicznym nie powiedzie się, sprawdź dodatkowo typ klucza, długość klucza, nieprawidłowy klucz prywatny, format klucza PuTTY oraz wpis pod Authorized keys. Prawidłowo dozwolona usługa SSH nie pomoże, jeśli klucz nie pasuje do zapisanego klucza publicznego.

Jeśli hasło domyślnego administratora zostało rzeczywiście utracone, artykuł Reset hasła administratora Sophos Firewall opisuje odzyskiwanie przez konsolę szeregową bez pełnego Factory Reset. Ta droga dotyczy fizycznych urządzeń ze złączem konsolowym; dla firewalli wirtualnych i cloud trzeba sprawdzić konsolę platformy oraz obsługiwaną ścieżkę odzyskiwania.

Pojawia się ostrzeżenie dotyczące klucza hosta

Ostrzeżenie o kluczu hosta może być nieszkodliwe, jeśli zapora została ponownie zainstalowana lub wymieniona. Ostrzeżenie może również wskazywać na nieprawidłowy system docelowy lub pomyłkę adresów IP. Dlatego najpierw sprawdź zaporę sieciową, adres IP, DNS i historię zmian. Dopiero wtedy należy usunąć stary wpis known_hosts.

Otwarto niewłaściwą konsolę

Jeśli udokumentowane polecenie Sophos CLI nie jest rozpoznawane, być może otwarto niewłaściwą konsolę albo składnia jest niepełna. W Device Console klawisz Tab wyświetla dostępne polecenia i argumenty, a ? ich opisy. Nie wpisuj tam instrukcji powłoki Linux ani nie testuj nieudokumentowanych poleceń w Advanced Shell.

Operacyjna lista kontrolna

• Zezwalaj na SSH tylko z zaufanych źródeł administracyjnych.
• Zmienić fabryczne hasło domyślne przed użyciem SSH w środowisku produkcyjnym.
• Jeśli to możliwe, użyj reguły wyjątków Local Service ACL zamiast zwalniania szerokiej strefy.
• Preferuj Public Key Authentication zamiast admin.
• Oddzielnie dokumentuj hasło domyślnego administratora, informacje MFA lub recovery oraz klucze SSH.
• Dokumentuj obsługiwany typ klucza i długość klucza.
• Nie udostępniaj kluczy prywatnych.
• Sprawdź odcisk palca SSH przy pierwszym logowaniu.
• Świadomie obsługuj ostrzeżenia dotyczące klucza hosta po ponownym wykonaniu obrazu lub wymianie sprzętu.
• Nie mylić Device Console i Advanced Shell.
• Zmiany w Advanced Shell wprowadzaj wyłącznie w jasno określonym celu.
• Usuń tymczasowe dostępy SSH po zgłoszeniach do pomocy technicznej.
• Usuń stare klucze publiczne po zmianie personelu lub usługodawcy.

Często zadawane pytania