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 rozszerzyć inspekcję protokołu na ten port.

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.

Najpierw wybór ścieżki inspekcji

Dodatkowy port docelowy i inspekcja tego przepływu to dwie odrębne decyzje. W Hosts and services > Services obiekt usługi TCP określa port docelowy dopasowywany przez regułę zapory. Podczas tworzenia go w Hosts and services > Services > Add należy zwykle pozostawić Source port jako 1:65535, ponieważ aplikacje dynamicznie wybierają port źródłowy. Sam obiekt nie włącza inspekcji treści.

Dla ruchu webowego service-param zwykle nie jest pierwszym krokiem w SFOS 22:

• DPI Engine wykrywa HTTP i SSL/TLS na wszystkich portach. Portal HTTPS na TCP 8443 wymaga zatem pasującej usługi w regule zapory, planowanej polityki webowej oraz odpowiednich ustawień skanowania. Jeśli potrzebne jest odszyfrowanie, musi też pasować reguła w Rules and policies > SSL/TLS inspection rules. Reguły te wykrywają TLS na każdym porcie TCP i wspólnie oceniają źródło, cel, użytkownika, usługę oraz kryteria witryn.
• Po wybraniu Use web proxy instead of DPI engine funkcja Transparent Web Proxy przetwarza tylko HTTP na porcie 80 i HTTPS na porcie 443. Ruch HTTP i TLS na innych portach pozostaje w DPI Engine. service-param nie służy więc do ogólnego rozszerzania transparentnego proxy na kolejne porty.
• Przy Direct Web Proxy klient łączy się z listenerem skonfigurowanym w Web > General settings > Web proxy configuration. Ta jawna ścieżka proxy działa niezależnie od wybrania Use web proxy instead of DPI engine w regule zapory.

IPS również stanowi odrębną ścieżkę. Intrusion prevention > IPS policies musi być globalnie włączone, wymaga aktywnej subskrypcji Network Protection lub licencji próbnej, a planowana polityka IPS musi być ustawiona w pasującej regule zapory. service-param nie włącza IPS i nie pokazuje, czy sygnatura rozpoznała przepływ. W tym celu należy skorelować Firewall Rule ID i zdarzenie IPS w Log Viewer.

service-param pozostaje więc przede wszystkim rozwiązaniem, gdy udokumentowana przez Sophos usługa właściwa dla protokołu ma przetwarzać dodatkowy port, na przykład FTP lub protokół pocztowy. Dla samej inspekcji webowej lub TLS przez DPI należy poprawnie skonfigurować ścieżkę reguł.

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, sprawdzenie ścieżki inspekcji nie doprowadziło już do rozwiązania DPI, a usługa właściwa dla protokołu ma przetwarzać ten ruch. Typowymi przykładami są FTP na TCP 2121 lub uzgodniona konfiguracja SMTP na TCP 2525.

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. Jeśli używany jest Mail Protection w trybie MTA, ruch podąża inną ścieżką wyznaczaną przez MTA.

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 połączenia SMTP na TCP 2525 kontrolowany pilot wygląda na przykład tak:

show service-param
set service-param SMTP add port 2525
show service-param

Ten przykład dotyczy inspekcji przezroczystego proxy pocztowego w Legacy mode. Reguła zapory wymaga ponadto usługi zezwalającej na TCP 2525 jako port docelowy; w sekcji Scan email content należy wybrać SMTP i skonfigurować odpowiednią politykę pocztową. Przed zmianą należy potwierdzić, że port przenosi SMTP, i ustalić, czy używa STARTTLS. Samo udane połączenie TCP lub dostarczenie poczty nie dowodzi inspekcji treści. W MTA mode nie należy na potrzeby tego pilota zmieniać automatycznie utworzonej reguły zapory MTA.

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 SMTP delete port 2525
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 dodawanie portu kończy się błędem, należy zapisać błąd i show service-param. Na tej podstawie należy ustalić, czy port 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