Łą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 jasno określony plan wycofania zmian w razie problemów.

⚠️ 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ż zezwalać na SSH bez ograniczeń.

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.
• Sprawdzanie stanu usługi lub debugowania: Advanced Shell. Włączaj debugowanie tylko w określonym celu i wyłącz je po zakończeniu analizy.
• 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 WebAdmin zapory Sophos Firewall.
2. Otwórz Administration.
3. Wybierz Device access.
4. W sekcji Local service ACL sprawdź, czy SSH jest dozwolone dla wybranej zaufanej strefy administracyjnej. Przed zmianą zanotuj bieżący stan.
5. Jeśli świadomie chcesz zezwolić na dostęp z całej tej strefy, włącz SSH tylko dla tej strefy i zapisz ustawienie przyciskiem Apply. Nie trzeba ponownie zmieniać ustawień, które już są odpowiednie.

Dla zaufanej wewnętrznej sieci administracyjnej odpowiednią strefą może być na przykład LAN. Zezwolenie dla strefy nie ogranicza się jednak do jednego komputera administratora. Aby ograniczyć dostęp do adresu IP administratora lub sieci zarządzania, użyj opisanej poniżej Local service ACL exception rule; szerokie zezwolenie dla strefy nie jest w tym przypadku dodatkowym wymaganym krokiem. Nie włączaj SSH dla całej strefy WAN.

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.

Przeglądarkowa konsola CLI to inna ścieżka dostępu niż klient SSH: klient SSH używa TCP 22, natomiast konsola w przeglądarce korzysta z dostępu HTTPS do WebAdmin. Aby skorzystać z konsoli w przeglądarce, otwórz Administration > Device access, sprawdź w sekcji Local service ACL uprawnienie HTTPS dla wybranej zaufanej strefy administracyjnej i w razie potrzeby włącz je przyciskiem Apply. Następnie otwórz menu rozwijane administratora w prawym górnym rogu WebAdmin i wybierz Console. Ta ścieżka dostępu nie wymaga zezwolenia na SSH. Również HTTPS nie należy udostępniać całej strefie WAN; istniejące ograniczenia źródeł dostępu pozostają w mocy.

Przy wyborze konta obowiązuje ograniczenie udokumentowane dla SFOS 22 i 23: instrukcja PuTTY wyraźnie wymaga użycia admin i wyklucza inne nazwy użytkowników, również podczas logowania za pomocą hasła. Opis profilu przyznaje wprawdzie profilowi Administrator pełny dostęp do CLI i pozwala przypisać go innym administratorom, ale nie określa metody transportu dla tego dostępu. Uprawnienie wynikające z roli nie gwarantuje zatem, że można zalogować się za pomocą konta imiennego przez sieciowe połączenie SSH. Nie potwierdzono tu również ogólnego dostępu do konsoli w przeglądarce dla każdego konta imiennego. Przed użyciem danej ścieżki dostępu jako rozwiązania awaryjnego należy sprawdzić konkretny dostęp z użyciem przewidzianego konta w zainstalowanej wersji SFOS. Jeśli brakuje Console lub dostęp zostaje odrzucony, należy pozostawić otwarte istniejące działające sesje; sprawdzić konto, profil i ścieżkę dostępu, a w razie potrzeby wyjaśnić sprawę z Sophos Support zamiast rozszerzać zezwolenia WAN lub ACL. W poniższych krokach SSH nadal używane jest admin; wyłączne zarządzanie SSH Public Keys przez domyślnego administratora stanowi odrębne uprawnienie.

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. Ten Access ID pozostaje ważny przez wybrany okres; Support access można wyłączyć wcześniej w dowolnym momencie. Sophos Support może dzięki temu uzyskać dostęp do WebAdmin i powłoki bez konieczności używania zwykłych poświadczeń administracyjnych. Zapora sama zestawia wychodzące połączenia wsparcia zarówno dla HTTPS, jak i SSH przez TCP 22; pod względem operacyjnym jest to coś innego niż zezwolenie na przychodzące połączenia SSH z WAN.

Przed każdą aktywacją — również w WebAdmin — należy najpierw sprawdzić istniejący kanał wsparcia w 4. Device Console za pomocą polecenia tylko do odczytu:

show support_access

Polecenie pokazuje, czy Support access jest aktywny, a przy aktywnym dostępie również Access ID i czas trwania. Stan początkowy oraz wyświetlony czas trwania i Access ID należy dokumentować wyłącznie w uwierzytelnionym, powiązanym zgłoszeniu do pomocy technicznej. Sam wynik polecenia nie potwierdza, do którego zgłoszenia należy kanał; to przypisanie oraz zgodę na dostęp należy ustalić z odpowiedzialnym zespołem i Sophos Support.

Jeśli aktywny jest już kanał dla innego zgłoszenia lub nie jest jasne, kto za niego odpowiada, należy przerwać działania i uzgodnić dalsze postępowanie, bez ponownego włączania, zastępowania ani wyłączania kanału. Nie należy również ponownie włączać aktywnego kanału, który został już autoryzowany dla tego samego zgłoszenia; jego dalsze użycie i zakończenie dostępu należy uzgodnić w istniejącym zgłoszeniu. Samodzielną procedurę włączania, analizy i wyłączania można rozpocząć tylko po potwierdzeniu, że kanał jest początkowo nieaktywny, i po uzyskaniu wyraźnej zgody dla tego zgłoszenia do pomocy technicznej. Ten warunek dotyczy obu opisanych poniżej ścieżek dostępu.

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 umożliwia również włączenie kanału wsparcia w 4. Device Console. Bezpośrednio przed wykonaniem polecenia zapisu należy ponownie przeprowadzić tam opisaną powyżej kontrolę za pomocą show support_access. Kanał można włączyć tylko po potwierdzeniu, że jest nieaktywny, i po uzyskaniu zgody dla tego zgłoszenia:

set support_access enable

Po pomyślnej aktywacji polecenie wyświetla Access ID i czas trwania dostępu. Faktycznie wyświetlony czas trwania należy porównać ze zgodą udzieloną dla tego zgłoszenia; udokumentowana składnia CLI nie zawiera parametru umożliwiającego ustawienie czasu trwania. Jeśli wymagany jest określony czas trwania, należy skorzystać z opisanej powyżej ścieżki przez WebAdmin po przeprowadzeniu tej samej kontroli wstępnej. Access ID i czas trwania należy przekazywać wyłącznie w uwierzytelnionym, powiązanym zgłoszeniu do pomocy technicznej i nie kopiować ich do ogólnej dokumentacji, czatów ani magazynów haseł.

Po zakończeniu analizy, niezależnie od pozostałego czasu dostępu, należy wyłączyć wyłącznie własny kanał utworzony za zgodą dla tego zgłoszenia. Wcześniej należy sprawdzić za pomocą show support_access i udokumentowanego Access ID, czy nadal jest to ten sam kanał. Jeśli jest już nieaktywny, nie należy wykonywać polecenia zapisu; jeśli ID jest inne lub nie jest jasne, kto odpowiada za kanał, należy przerwać działania i uzgodnić dalsze postępowanie zamiast wyłączać potencjalnie cudzy kanał:

set support_access disable

Następnie należy sprawdzić w Diagnostics > Support access lub za pomocą show support_access, czy własny kanał nie jest już aktywny. disable nie zmienia zwykłej konfiguracji SSH w Device Access ani Local Service ACL Exception Rules; dlatego tymczasowe zezwolenia na dostęp administracyjny i SSH należy wycofać oddzielnie, wyłącznie w zakresie własnych zmian, przywracając wcześniej zanotowany stan.

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.

Support access przez XML API: wyjaśnienie przed operacjami zapisu

Pomoc XML API dla SFOS 22 i 23 określa obiekt jako SupportAccess, ale zawiera dwie sprzeczności: W przykładzie XML tag czasu trwania nosi nazwę GrantAccessFor, natomiast w tabeli parametrów GrantAccessForr. Dla ConfigOption tabela podaje wartość domyślną ON, ale dopuszcza tylko Enable i Disable. Nie można z tego wywnioskować ani poprawnej wartości ON w żądaniu, ani domyślnie aktywnego dostępu dla pomocy technicznej. Przed zapisem ustal poprawną pisownię tagu dla zainstalowanego buildu w API help lub z Sophos Support.

Tabela oznacza oba pola jako opcjonalne wartości skalarne i wymienia okresy 1 day, 2 days, 1 week, 2 weeks, 1 month i 2 months. Nie wyjaśnia to, co faktycznie dzieje się po pominięciu pola. Dlatego przed automatyczną zmianą należy sprawdzić pomoc API dotyczącą tego konkretnego obiektu w zainstalowanym buildzie SFOS i wyjaśnić z Sophos Support otwarte kwestie dotyczące tagu, wartości lub zachowania przy pomijaniu pól. Dopóki sprzeczność nie zostanie wyjaśniona, należy wstrzymać operacje zapisu przez XML; nie należy wymyślać payloadu ani próbować obu pisowni w systemie produkcyjnym. W przypadku zatwierdzonego zgłoszenia do pomocy technicznej alternatywą pozostaje opisana powyżej ścieżka przez WebAdmin, bez rozszerzania zezwoleń WAN lub ACL.

Dokumentacja referencyjna podaje dla tej operacji 200 z Operation Successful. oraz 500 z Operation Fail.. Należy sprawdzić konkretną odpowiedź obiektu zamiast bezrefleksyjnie ponawiać nieudaną operację zapisu lub operację o niejasnym wyniku. Po potwierdzonej zmianie należy sprawdzić rzeczywisty stan aktywacji i czas trwania w Diagnostics > Support access lub za pomocą opisanego powyżej show support_access. Po zakończeniu zgłoszenia do pomocy technicznej należy wyłączyć wyłącznie własny kanał autoryzowany dla tego zgłoszenia, z zachowaniem opisanych powyżej kontroli odpowiedzialności za kanał, i sprawdzić, czy jest nieaktywny; tymczasowe uprawnienia SSH/ACL nadal należy wycofywać oddzielnie.

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, czyli dodawać lub usuwać klucze SSH. Takie zmiany kluczy SSH powinny być częścią udokumentowanego procesu administracyjnego, a nie doraźnym sposobem na przyspieszenie działań wsparcia.

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 ponownej instalacji systemu, 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 regularnego dostępu dokumentuj ścieżkę do klucza prywatnego, dozwolony źródłowy adres IP i cel dostępu. Nie kopiuj wpisu known_hosts do zgłoszeń ani historii czatów. W przypadku ostrzeżeń o kluczu hosta historia zmian jest ważniejsza niż szybkie obejście problemu.

Łą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

W przypadku PuTTY: jeśli program nie jest jeszcze dostępny, najpierw pobierz go z oficjalnej strony pobierania PuTTY i skonfiguruj na komputerze administratora. Następnie nawiąż połączenie:

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 pojawia się Main Menu. Poniższy widok ułatwia wybór opcji menu:

Main Menu

  1. Network Configuration
  2. System Configuration
  3. Route Configuration
  4. Device Console
  5. Device Management
  6. VPN Management
  7. Shutdown/Reboot Device
  0. Exit

Select Menu Number [0-7]:

Przy monicie Select Menu Number [0-7]: wpisz numer żądanej opcji menu, na przykład 1 dla Network Configuration. W przypadku poleceń diagnostycznych szczególnie ważne są dwie opisane poniżej ścieżki. 7. Shutdown/Reboot Device prowadzi do działań, które mogą przerwać pracę urządzenia; ta opcja menu nie służy do eksperymentowania.

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 są zachowywane 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.

Znaczenie rodzin poleceń set i system

W 4. Device Console set definiuje ustawienia i parametry różnych składników systemu, a system konfiguruje parametry systemowe. Obie rodziny mogą zmieniać konfigurację. Aby je poznać, korzystaj wyłącznie z pomocy, a nie z kompletnego polecenia zmieniającego ustawienia. Dokumentacja SFOS 22 i 23 przedstawia następujące ogólne schematy składni — nie są to polecenia do skopiowania:

set [command] [option 1|option 2] <value>
system [command] [option 1|option 2] <value>

• set lub system to stały prefiks, który wpisuje się dokładnie w podanej postaci.
• Zastąp [command] wybranym udokumentowanym poleceniem, na przykład advanced-firewall dla set lub firewall-acceleration dla system.
• [option 1|option 2] oznacza wybór jednej z udokumentowanych alternatyw. Nie wpisuj nawiasów kwadratowych ani |; tutaj nie oznaczają one, że można po prostu pominąć wybór.
• <value> to symbol zastępczy wartości odpowiedniej dla wybranej opcji. Zastąp go wraz z nawiasami ostrymi wymaganą wartością. O tym, jakie argumenty są rzeczywiście wymagane, decyduje pomoc konkretnego polecenia, a nie sam ogólny schemat.

Wyłącznie objaśnienie składni — nie wykonuj: w przykładzie producenta set advanced-firewall icmp-error-message allow prefiksem jest set, wybranym poleceniem advanced-firewall, opcją icmp-error-message, a konkretną wartością zastępującą <value> jest allow. To zmiana konfiguracji, nie wymagany krok dostępu SSH. Przykład system firewall-acceleration enable również nie służy do ćwiczeń: system jest prefiksem, firewall-acceleration wybranym poleceniem, a enable wybraną opcją. Ten konkretny przykład nie zawiera dodatkowej wartości; nie dopisuj bez sprawdzenia <value> ani nie włączaj akceleracji na próbę.

Aby bezpiecznie poznać dostępne ustawienia, wpisz w Device Console tylko set i naciśnij trzy razy Tab, aby wyświetlić ich listę. Tab, a następnie ?, wyświetla opisy. Powtórz to z prefiksem system, aby poznać drugą rodzinę. Oczekiwanym wynikiem jest wyświetlenie pomocy, nie zmiana ustawienia. Następnie wyczyść wiersz wejściowy bez wysyłania polecenia zmiany klawiszem Enter. Jeśli oczekiwana pomoc się nie pojawia, najpierw sprawdź konsolę i dokumentację zainstalowanej wersji SFOS zamiast testować przykładowe polecenie.

Kończenie połączenia

⚠️ Starsze polecenia Device Console enableremote i disableremote nie są normalnym sposobem wylogowania: dla SFOS 22 i 23 Sophos podaje, że disableremote nie tylko uniemożliwia nawiązywanie nowych połączeń SSH na porcie 22, ale także kończy istniejące sesje SSH. Dlatego nie wykonuj tych poleceń w celu wylogowania ani cofnięcia tymczasowego zezwolenia ACL. Przed każdym wyraźnie zatwierdzonym użyciem tych poleceń należy przetestować działającą ścieżkę dostępu awaryjnego, niezależną od sieciowego SSH: lokalną konsolę szeregową lub konsolę out-of-band w przypadku urządzeń fizycznych albo odpowiednią konsolę platformy w przypadku zapór wirtualnych lub chmurowych. Bez tego dostępu i planu przywracania potwierdzonego dla zainstalowanej wersji przerwij działania i wyjaśnij sprawę z Sophos Support. Opis enableremote wymienia port Ethernet; nie wyprowadza się z tego tutaj ani składni portu TCP, ani ogólnego polecenia odwrotnego. W przypadku tymczasowych uprawnień dostępu nadal obowiązuje opisane powyżej precyzyjne cofnięcie zmian w Administration > Device access; nawiązywany wychodząco kanał w Diagnostics > Support access jest odrębnym mechanizmem.

Aby wyjść z Advanced Shell, użyj poniższego polecenia. Nie zastępuje ono wyboru numeru w menu konsoli:

exit

Jeśli znajdujesz się w podmenu, najpierw wróć do Main Menu. Tam opcja 0. Exit kończy sesję konsoli: przy monicie menu wpisz 0. Polecenie powłoki i numer opcji menu są więc używane w różnych miejscach.

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 dostęp SSH był dozwolony tylko na potrzeby zgłoszenia do pomocy technicznej, po zakończeniu cofnij dokładnie to tymczasowe uprawnienie dostępu. Utworzoną w tym celu Local service ACL exception rule usuń zgodnie z powyższym opisem; zmienione pole wyboru strefy przywróć do wcześniej zanotowanego stanu i zapisz przyciskiem Apply. Inne nadal potrzebne uprawnienia pozostaw bez zmian. Jest to szczególnie ważne w przypadku zewnętrznych źródłowych adresów IP lub dostępu usługodawców.

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 zostaje odrzucone, często oznacza to, że SSH nie jest dozwolone dla wybranej strefy lub źródła. Dlatego w Administration > Device access sprawdź ustawienie SSH i istniejące wpisy Local service ACL exception rule. Ustal również, czy szersze zezwolenie dla strefy zostało celowo cofnięte. Nie przywracaj takiego dostępu bez uprzedniej weryfikacji.

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 włączaj pochopnie dodatkowego dostępu z WAN lub innych stref. W przypadku urządzenia fizycznego ścieżką awaryjną jest lokalna konsola szeregowa, na przykład przy błędnych ustawieniach dostępu do urządzenia, routingu lub nieprawidłowym przypisaniu interfejsów do stref. Użyj odpowiedniego kabla konsolowego RJ45 albo, w obsługiwanych modelach, Micro-USB i ustaw w programie terminalowym szybkość 38400 bodów.

Jeśli Micro-USB i RJ45 są podłączone jednocześnie, Micro-USB ma pierwszeństwo i zapora przekierowuje do niego wyjście konsoli. Jeśli terminal niczego nie wyświetla, najpierw sprawdź wybór portu szeregowego, kabel i to pierwszeństwo. Wartość 38400 bodów jest w BIOS-ie wyszarzona, aby zapobiec jej przypadkowej zmianie; nie próbuj więc jej tam zmieniać.

Szczegółowe kroki nawiązywania połączenia opisano w sekcji Nawiązywanie połączenia szeregowego. Jeśli znasz hasło konta admin, po nawiązaniu połączenia zaloguj się za jego pomocą — reset hasła nie jest potrzebny. Skorzystaj wyłącznie z kroków dotyczących połączenia w podlinkowanym artykule, a nie z procedury resetowania hasła. Potwierdzeniem powodzenia jest wyświetlenie menu konsoli; w przypadku zapór wirtualnych lub chmurowych potrzebny jest natomiast dostęp do konsoli odpowiedni dla danego typu platformy.

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.
• Zmień fabryczne hasło domyślne przed użyciem SSH w środowisku produkcyjnym.
• Jeśli to możliwe, używaj Local service ACL exception rule zamiast szerokiego zezwolenia dla strefy.
• Preferuj uwierzytelnianie kluczem publicznym dla konta admin zamiast logowania hasłem.
• Oddzielnie dokumentuj hasło domyślnego administratora, informacje dotyczące MFA i odzyskiwania dostępu oraz klucze SSH.
• Używaj obsługiwanego typu klucza i dokumentuj jego długość.
• Nie udostępniaj kluczy prywatnych.
• Sprawdź odcisk palca SSH przy pierwszym logowaniu.
• Świadomie weryfikuj ostrzeżenia o kluczu hosta po ponownej instalacji systemu lub wymianie sprzętu.
• Nie myl Device Console z Advanced Shell.
• Wprowadzaj zmiany w Advanced Shell tylko w jasno określonym celu.
• Cofaj tymczasowe uprawnienia dostępu SSH po zakończeniu spraw wsparcia.
• Usuwaj stare klucze publiczne po zmianie personelu lub usługodawcy.

Często zadawane pytania