Inspekcja portów niestandardowych w Sophos Firewall

Sophos Firewall sprawdza HTTP, HTTPS, FTP, SMTP/S, POP i IMAP na ich standardowych portach. Gdy aplikacja używa jednego z tych protokołów na innym porcie, service-param może dodatkowo przypisać ten port do klasycznej usługi inspekcji.

Polecenie nie otwiera portu w sposób ogólny. Nie tworzy obiektu usługi ani reguły zapory i nie włącza polityki webowej, TLS lub pocztowej. Aby ruch był sprawdzany, muszą pasować do siebie reguła, dozwolony port docelowy i właściwa ścieżka inspekcji. Dla nowych reguł webowych trzeba najpierw ustalić, czy przepływ obsługuje DPI Engine czy Web Proxy.

⚠️ service-param jest przypisaniem globalnym. Dodatkowy port nie wpływa tylko na jeden host lub jedną regułę zapory. Przed zmianą należy udokumentować istniejące zastosowania portu, objęte polityki i wykonalny sposób wycofania.

Kiedy service-param jest właściwy

Polecenie jest właściwe, gdy znana aplikacja rzeczywiście używa HTTP, HTTPS, FTP, SMTP, SMTPS, POP lub IMAP na niestandardowym porcie TCP, a odpowiednia klasyczna usługa ma sprawdzać ten ruch. Typowymi przykładami są wewnętrzny portal HTTPS na porcie 8443 lub jawna konfiguracja poczty na dodatkowym porcie.

Otwarty port TCP nie dowodzi użycia oczekiwanego protokołu. Jeśli na 8443 działa własnościowy ruch binarny, przypisanie go do HTTPS może zakłócić połączenia zamiast dodać ochronę. Dla ruchu webowego trzeba też sprawdzić, czy DPI Engine już rozpoznaje protokół, czy rzeczywiście należy dodać port usługi proxy. W przypadku poczty należy odróżnić SMTP z STARTTLS od SMTPS z TLS od początku połączenia. Mail Protection w trybie MTA opisuje właściwą ścieżkę poczty.

service-param nie jest właściwy, jeśli reguła zapory ma tylko zezwalać na dodatkowy port docelowy. W Hosts and services > Services należy utworzyć odpowiedni obiekt usługi TCP i użyć go w regule. Przypisanie inspekcji dodaje się dopiero wtedy, gdy odpowiednia usługa proxy lub poczty ma również przetwarzać port niestandardowy.

Zapisanie stanu początkowego w Device Console

Polecenie jest dostępne przez 4. Device Console. Przed każdą zmianą następujące polecenie pokazuje istniejące porty usług i inne wartości globalne:

show service-param

Pełny wynik należy zapisać z buildem SFOS, czasem i odniesieniem do zmiany. Szczególnie ważne jest sprawdzenie, czy planowany port nie jest już przypisany do innej usługi. Tego samego portu nie przypisuje się na podstawie przypuszczeń jednocześnie do HTTP, HTTPS, SMTP i SMTPS.

Sophos dokumentuje dla SFOS 22 następujące nazwy usług:

FTP
HTTP
HTTPS
IMAP
POP
SMTP
SMTPS
IM_MSN
IM_YAHOO

IM_MSN i IM_YAHOO są starszymi oznaczeniami w CLI. Nie są punktem wyjścia dla nowego projektu komunikatora. Nowe aplikacje zabezpiecza się przez reguły zapory, Application Control, TLS Inspection i faktycznie obsługiwane rozpoznawanie protokołów.

Dodawanie dodatkowego portu

Udokumentowana podstawowa składnia dla obsługiwanych usług wygląda następująco:

set service-param <service> add port <portID>
set service-param <service> delete port <portID>

Dla potwierdzonego portalu HTTPS na TCP 8443 kontrolowany pilot wygląda na przykład tak:

show service-param
set service-param HTTPS add port 8443
show service-param

Reguła zapory wymaga ponadto usługi zezwalającej na TCP 8443 jako port docelowy. Dla HTTPS trzeba ustalić, która ścieżka inspekcji odszyfrowuje, jaki certyfikat jest oczekiwany i czy aplikacja używa Certificate Pinning. Widoczna strona internetowa nie dowodzi ani odszyfrowania, ani skanowania malware.

Symbol zastępczy portID w składni Sophos jest używany w Device Console z konkretną wartością portu. Port dodaje się dopiero po potwierdzeniu protokołu i portu docelowego przez Packet Capture lub dokumentację aplikacji.

Niełączenie opcji globalnych z testem portu

Dla HTTPS Sophos wymienia także deny_unknown_proto on|off i invalid-certificate allow|block. SMTPS również ma invalid-certificate allow|block. SMTP udostępnia dalsze opcje globalne dla Failure Notifications, Fast ISP Mode, Notification Port i Strict Protocol Check.

Te wartości rozwiązują inny problem niż add port i nie są zmieniane w tym samym pilocie. Szczególnie invalid-certificate allow może globalnie tolerować błędy certyfikatów, natomiast deny_unknown_proto i strict-protocol-check zmieniają obsługę połączeń niezgodnych z protokołem. Udane połączenie po kilku jednoczesnych zmianach byłoby trudne do przypisania i mogłoby niezauważenie osłabić ochronę.

Oficjalna składnia obejmuje także:

set service-param HTTPS deny_unknown_proto <on|off>
set service-param HTTPS invalid-certificate <allow|block>
set service-param SMTPS invalid-certificate <allow|block>
set service-param SMTP failure_notification <on|off>
set service-param SMTP fast-isp-mode <on|off>
set service-param SMTP notification-port add port <portID>
set service-param SMTP strict-protocol-check <on|off>

Przed taką zmianą globalną należy oddzielnie ocenić dokładny istniejący wynik, objętych nadawców lub aplikacje webowe, wpływ na bezpieczeństwo i zalecenia wsparcia. Artykuł nie przedstawia więc tych poleceń jako zalecanych wartości domyślnych.

Sprawdzanie efektu za pomocą rzeczywistego przepływu

Test rozpoczyna się od dokładnie jednego źródła pilota i logowanej reguły zapory. Przed zmianą i po niej używa się tego samego celu, portu docelowego i nowego połączenia. W Log Viewer identyfikator Firewall Rule ID, działanie webowe lub pocztowe i czas muszą odpowiadać pilotowi.

Dla HTTPS sprawdza się również wystawcę certyfikatu, handshake TLS i oczekiwane działanie Block lub Allow. Jeśli skanowanie malware jest częścią projektu, wykonuje się kontrolowany test EICAR dokładnie przez ten port. EICAR potwierdza tylko zwykłą ścieżkę antywirusową, a nie każdą funkcję TLS, polityki lub ML. Dla SMTP, SMTPS, POP i IMAP używa się jednoznacznie rozpoznawalnej wiadomości testowej i śledzi ją w Mail Logs, Quarantine oraz w razie potrzeby Mail Spool.

Packet Capture potwierdza, że klient rzeczywiście używa zamierzonego portu docelowego. Jeśli tylko Firewall Log pokazuje Allow, nadal nie ma dowodu, że dalsza usługa proxy lub poczty sprawdziła zawartość. Kontrolowane testowanie reguł Sophos Firewall łączy dopasowanie reguł, Log Viewer i Packet Capture.

Wycofywanie przypisania portu

Rollback usuwa z właściwej usługi tylko port dodany w ramach zmiany:

set service-param HTTPS delete port 8443
show service-param

Następnie ponownie tworzy się ten sam przepływ testowy. Łączność musi wrócić do udokumentowanego stanu początkowego. Tymczasowe zezwolenia usługi zapory, reguły pilota i wyjątki usuwa się oddzielnie; delete port nie usuwa tych obiektów.

Jeśli już dodawanie portu kończy się błędem, należy zapisać błąd i show service-param. Port często jest już traktowany jako standardowy lub przypisany do innej usługi. Istniejącego wpisu nie usuwa się bez sprawdzenia, ponieważ może od niego zależeć inna ścieżka inspekcji.

Operacyjna lista kontrolna

• Aplikacja, protokół i rzeczywisty port docelowy są potwierdzone.
• show service-param i build SFOS są zapisane przed zmianą.
• Usługa zapory, dopasowanie reguły i przypisanie inspekcji są rozpatrywane oddzielnie.
• Port nie jest już przypisany do kolidującej usługi.
• W pilocie zmienia się tylko add port, a nie globalna opcja certyfikatu lub protokołu.
• Przygotowano test pozytywny, test negatywny, log inspekcji i Packet Capture.
• Odpowiednie polecenie delete port i niezmieniona ścieżka powrotna są gotowe.

FAQ