Łą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.
• Czytaj pliki dziennika, tail, grep, less: Advanced Shell. Tylko do odczytu, nie modyfikuj ani nie usuwaj plików.
• 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.

W przypadku wyjątku ACL wartości należy ustawić możliwie wąsko:

• Rule position: pozycja wyjątku w Local Service ACL
• 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

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.

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.

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.

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 należy tam wykonywać tylko wtedy, gdy jest jasne, do czego służą.

• Device Console: ping, dnslookup, traceroute, show, Opcje routingu lub systemu.
• Advanced Shell: Czytaj /log, tail -f, grep, less, service -S, dzienniki debugowania.

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 polecenie nie zostanie rozpoznane, często otwierana jest niewłaściwa konsola. Polecenia takie jak system ... często należą do Device Console. Polecenia systemu plików i dziennika, takie jak tail, grep, less lub service -S należą do 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