Bezpieczne zarządzanie System Modules w Sophos Firewall

Sophos Firewall wykorzystuje System Modules jako helpery protokołów dla ruchu, w którym firewall musi śledzić dodatkowe informacje lub uwzględniać połączenia dynamiczne. SFOS 22 wymienia dns, h323, irc, pptp, sip i tftp. Moduły te są domyślnie załadowane.

Załadowany moduł nie jest regułą firewalla ani zaleceniem używania danego protokołu. Nie zastępuje właściwej reguły NAT, trasy ani polityki bezpieczeństwa. Wyłączanie wszystkich pozornie nieużywanych helperów również nie jest rozsądnym utwardzeniem. Ustawienie działa globalnie i może nieoczekiwanie wpłynąć na istniejące aplikacje.

⚠️ Zasada operacyjna: Najpierw należy zapisać stan i konkretny wadliwy przepływ. Następnie zmienić najwyżej jeden moduł, powtórzyć ten sam przepływ i przywrócić stan początkowy, jeżeli nie nastąpi poprawa.

Prawidłowa klasyfikacja sześciu modułów

W przypadku sip i h323 helper jest często zbyt szybko uznawany za przyczynę lub rozwiązanie. Pełny proces obejmujący NAT, RTP, timeouty, niestandardowy port SIP, Packet Capture i rzeczywiste połączenia testowe opisano w Rozwiązywanie problemów VoIP z SIP i RTP.

Zapis stanu bazowego w Device Console

Polecenia wykonuje się w 4. Device Console, a nie w Advanced Shell. Dostęp jest możliwy przez SSH albo przez admin > Console w prawym górnym rogu WebAdmin. Dla SSH trzeba zezwolić na SSH dla wymaganej strefy w Administration > Device access > Local service ACL; konsola internetowa wymaga tam HTTPS. Nie należy otwierać dostępu szerzej, niż wymaga tego źródło administracyjne.

Przed zmianą należy odczytać stan globalny:

system system_modules show

Należy zachować pełne wyjście, nawet jeśli badany jest tylko jeden moduł. Pozwala to wykryć, czy migrowany lub wcześniej zmieniany system odbiega od ustawienia domyślnego. loaded potwierdza jedynie stan modułu, nie dowodzi, że helper obsługuje dany przepływ lub powoduje jego błąd. Jeśli SIP był wcześniej załadowany z niestandardowym portem, trzeba również zapisać jego dokładną wartość z istniejącej dokumentacji konfiguracji. Nie należy zmieniać SIP, jeśli tej wartości nie można wiarygodnie ustalić, ponieważ nie da się wtedy przygotować powrotu z zachowaniem stanu.

Trzeba również zapisać źródłowy i docelowy adres IP, port, protokół, Rule ID, NAT ID, czas oraz dokładny test aplikacji. Bez odtwarzalnego przepływu nie da się wiarygodnie ocenić zmiany globalnej. Log Viewer, Policy Test i Packet Capture nadają się do weryfikacji technicznej.

Ładowanie lub wyłączanie dokładnie jednego modułu

Podstawowe polecenia mają ten sam wzorzec. Tabela jest referencją, a nie blokiem do wykonania w całości.

Przed wykonaniem należy sprawdzić zainstalowany build za pomocą wbudowanej pomocy: wpisać zamierzone polecenie i użyć ?, aby wyświetlić obsługiwane argumenty. Nie należy wysyłać niepełnych wariantów na próbę; Sophos ostrzega, że niepełne polecenie Device Console może zablokować daemon access_server. Po dokładnie jednej zmianie ponownie uruchomić system system_modules show, a następnie powtórzyć wcześniej zapisany przepływ. Równoległe zmiany NAT, reguł, routingu, timeoutów lub PBX utrudniają przypisanie wyniku i powinny być unikane.

Sophos wyraźnie dokumentuje, że SIP load i unload zachowują stan po restarcie. Strona SFOS 22 nie podaje równie dokładnej informacji o trwałości pozostałych modułów. Po planowanym restarcie należy ponownie odczytać ich stan zamiast zakładać trwałość.

Nie wyprowadzać portów niestandardowych z niepełnej skróconej składni

Strona wymienia dla IRC, SIP i TFTP dodatkowe terminy, takie jak port, portname, default lub show, ale nie wyjaśnia w pełni ich dokładnej formy. Nie należy zgadywać tych wartości. Device Console pokazuje składnię zainstalowanego buildu po użyciu ?.

Dla SIP Sophos publikuje osobno dokładne polecenie system system_modules sip load ports <custom_port>. Decyzja ta należy do analizy VoIP, a nie do ogólnego testu helpera. Placeholder należy zastąpić portem sygnalizacyjnym faktycznie używanym przez operatora lub PBX.

Ograniczenia SIP, które trzeba znać przed testem

Domyślnie helper SIP używa portu UDP 5060. Tłumaczy lokalne adresy IP w nagłówku SIP na adresy publiczne i tworzy w firewallu oczekiwane dynamiczne połączenie głosowe. Jego działanie wykracza więc poza samo rozpoznawanie sygnalizacji.

W diagnostyce kluczowe są dwa ograniczenia:

• Helper obsługuje porty mediów SIP wyłącznie w zakresie 1024–65535. Jeśli skonfigurowany port mediów znajduje się poza tym zakresem, firewall odrzuca pakiety, a Event Log pokazuje Invalid Traffic.
• Helper nie obsługuje wiadomości SIP lub SDP rozłożonej na więcej niż jeden pakiet. Może się to zdarzyć przy SIP przez TCP. Sophos wskazuje połączenie sterujące SIP przez UDP jako obejście; można go użyć tylko wtedy, gdy obsługuje je operator, PBX lub SBC.

Niestandardowy port sygnalizacji i zakres mediów RTP to różne wartości. <custom_port> w poleceniu ładowania oznacza faktycznie używany port sygnalizacji SIP; nie należy wyprowadzać z niego zakresu RTP.

Weryfikacja działania i drogi powrotnej

Rzetelny test obejmuje więcej niż wyjście CLI. Po załadowaniu lub wyłączeniu należy sprawdzić zestawienie konkretnego połączenia, ruch w obu kierunkach, Rule i NAT ID, dropy oraz aplikację. Dla SIP lub H.323 obejmuje to rejestrację, połączenia przychodzące i wychodzące oraz media w obu kierunkach. Dla DNS sprawdza się zapytanie i odpowiedź z oczekiwaną nazwą. Dla TFTP również transfer pliku.

Jeśli objaw nie zmienia się lub pojawiają się nowe błędy, tylko zmodyfikowany moduł należy przywrócić do wcześniej zapisanego stanu:

• Jeśli był załadowany z ustawieniem domyślnym, załadować go ponownie odpowiednim poleceniem ... load.
• Jeśli był wyłączony, wyłączyć go ponownie odpowiednim poleceniem ... unload.
• Jeśli SIP był załadowany na niestandardowym porcie sygnalizacji, przywrócić dokładnie zapisany port poleceniem system system_modules sip load ports <previous_custom_port>. <previous_custom_port> należy zastąpić wartością z baseline, a nie nową wartością przykładową.

Następnie ponownie wykonać system system_modules show i ten sam przepływ testowy. Wyjście CLI musi odpowiadać zapisanej baseline, a test nie może pozostawić dodatkowej usterki w pierwotnej ścieżce aplikacji. Restart nie zastępuje rollbacku.

Jeśli zachowanie się zmienia, lecz przyczyna pozostaje niejasna, trzeba zachować stan przed i po, build firmware, logi oraz Packet Capture. Globalnie wyłączony helper nie powinien pozostać rozwiązaniem stałym tylko dlatego, że jeden krótki test wyglądał lepiej.

W przypadku SIP objaw wskazuje kolejny krok: Invalid Traffic przy braku mediów kieruje najpierw do skonfigurowanego portu mediów i zakresu 1024–65535. Jeśli rejestracja przez TCP nie działa lub długie wiadomości SIP/SDP są przerywane, trzeba sprawdzić ograniczenie do jednego pakietu. Jeśli wyświetlany stan modułu jest prawidłowy, lecz zachowanie się nie zmienia, najpierw należy potwierdzić faktycznie używany port sygnalizacji oraz właściwą ścieżkę Rule/NAT.

FAQ