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 polecenia, nawet jeśli badany jest tylko jeden moduł. Dzięki temu można ustalić, czy system po migracji lub wcześniejszych modyfikacjach odbiega od konfiguracji domyślnej. Wyświetlony stan loaded potwierdza jedynie stan modułu, a nie to, że helper obsługuje określony przepływ lub powoduje występujący w nim błąd. Nie dowodzi również, że IRC, SIP lub TFTP są skonfigurowane bez niestandardowych portów lub innych zmodyfikowanych argumentów. Przed każdą zmianą należy jednoznacznie ustalić i udokumentować, czy dany moduł ma potwierdzoną konfigurację domyślną bez niestandardowych portów lub innych zmodyfikowanych argumentów.

W przypadku IRC, SIP lub TFTP ze zmodyfikowanymi argumentami należy przed testem zapisać pełną, faktycznie skonfigurowaną konfigurację bazową oraz obsługiwaną procedurę jej dokładnego przywrócenia, potwierdzoną dla zainstalowanego buildu. W przypadku SIP obejmuje to dokładny niestandardowy port sygnalizacji ustalony na podstawie istniejącej, wiarygodnej dokumentacji konfiguracji; w przypadku IRC i TFTP obejmuje to wszystkie faktycznie skonfigurowane wartości portów i pozostałych argumentów. Sama pomoc dotycząca składni nie potwierdza bieżącej konfiguracji. Jeśli konfiguracja bazowa jest niejasna, brakuje wartości lub nie potwierdzono procedury powrotu z zachowaniem stanu, dany helper musi pozostać bez zmian. Nie należy zgadywać ani wartości domyślnych, ani poleceń przywracania.

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 służy jako zestawienie referencyjne, a nie blok poleceń do wykonania w całości. Prosta zmiana stanu za pomocą tych poleceń oraz powrót przez wykonanie operacji odwrotnej są przeznaczone wyłącznie dla wcześniej potwierdzonej domyślnej konfiguracji bazowej bez niestandardowych portów lub innych zmodyfikowanych argumentów. W przypadku niestandardowej konfiguracji IRC, SIP lub TFTP należy zamiast tego stosować wyłącznie procedurę zmiany i przywracania zapisaną przed testem i potwierdzoną dla zainstalowanego buildu; bez niej nie wolno rozpoczynać testu.

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 moduł był wcześniej załadowany i potwierdzono domyślną konfigurację bazową bez niestandardowych portów lub innych zmodyfikowanych argumentów, należy załadować go ponownie odpowiednim poleceniem ... load.
• Jeśli moduł był wcześniej wyłączony i potwierdzono domyślną konfigurację bazową bez niestandardowych portów lub innych zmodyfikowanych argumentów, należy wyłączyć go ponownie odpowiednim poleceniem ... unload. Również w tym przypadku sam stan modułu nie wystarcza do potwierdzenia braku zmodyfikowanych argumentów.
• Jeśli SIP był wcześniej załadowany na niestandardowym porcie sygnalizacji, należy przywrócić dokładnie tę zapisaną wartość poleceniem system system_modules sip load ports <previous_custom_port>. <previous_custom_port> należy zastąpić wartością z konfiguracji bazowej, a nie nową wartością przykładową. Również ta procedura powrotu musi zostać potwierdzona przed testem dla zainstalowanego buildu i przywracać pełną zapisaną konfigurację.
• W przypadku IRC lub TFTP z niestandardowymi portami lub innymi zmodyfikowanymi argumentami należy przywrócić pełną zapisaną konfigurację bazową wyłącznie za pomocą obsługiwanej procedury przywracania, wcześniej potwierdzonej dla zainstalowanego buildu, a nie przez proste wykonanie odwrotnego polecenia ładowania lub wyłączania. Jeśli taka procedura nie jest dostępna, helper musi od początku pozostać bez zmian.

Następnie należy ponownie wykonać system system_modules show i powtórzyć ten sam przepływ testowy. Wyjście CLI musi ponownie odpowiadać zapisanemu stanowi początkowemu, a test nie może powodować dodatkowych zakłóceń w pierwotnej ścieżce aplikacji. W przypadku niestandardowej konfiguracji IRC, SIP lub TFTP należy również porównać pełną skonfigurowaną konfigurację bazową, w tym wszystkie zapisane wartości argumentów, przy użyciu wcześniej potwierdzonej procedury weryfikacji; sam zgodny stan modułu nie dowodzi jej przywrócenia. Restart nie zastępuje tego 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