Sprawdzanie zarezerwowanych portów w Sophos Firewall

Sophos Firewall rezerwuje określone porty dla wewnętrznych usług systemowych. Porty te pozostają zarezerwowane nawet wtedy, gdy powiązana usługa nie jest używana. Zarezerwowanego portu nie można więc po prostu przypisać do innej funkcji firewalla.

Ma to szczególne znaczenie przy planowaniu własnego portu dla WebAdmin, User Portal, VPN Portal, SSL VPN, WAF, proxy lub innej usługi firewalla. Rezerwacja to tylko pierwsza kontrola: port spoza listy może być już używany albo otwierać nieoczekiwaną drogę dostępu przez współdzielenie portów.

⚠️ Port spoza listy rezerwacji nie stanowi jeszcze zezwolenia bezpieczeństwa. Dostępność, adres IP WAN, protokół, Administration > Device access, współdzielenie portów i nadrzędny NAT trzeba oddzielnie zaplanować i przetestować. Ruch przekazywany wymaga również odpowiednich reguł firewalla; reguły te nie sterują dostępem do lokalnych usług systemowych.

Porty zarezerwowane w SFOS 22

Lista odpowiada stanowi Sophos Firewall 22.0 sprawdzonemu 4 września 2026 r. Zakresy obejmują obie wartości graniczne.

Sophos publikuje rezerwacje jako numery portów, bez wyjątków zależnych od protokołu. Nie należy obchodzić rezerwacji przez zmianę TCP na UDP. Wyłączenie lub restart usługi również nie zwalnia numeru.

Port zarezerwowany, unikatowy czy współdzielony?

Przy sprawdzaniu kolizji liczy się kombinacja protokołu i portu: TCP 8443 oraz UDP 8443 to różne kombinacje. Rezerwacja produktu dotyczy natomiast samego numeru portu.

• Zarezerwowany: żadna lokalna funkcja firewalla nie może użyć numeru z listy.
• Unikatowy: Web admin console i User portal wymagają oddzielnych portów, domyślnie TCP 4444 i TCP 4443.
• Współdzielenie z ograniczeniami: gdy VPN Portal i SSL VPN używają tego samego portu i protokołu, Login Security nie działa, a VPN Portal jest dostępny ze stref SSL VPN. WAF musi różnić się adresem IP WAN, portem lub protokołem.

Wszystkie warunki opisuje współdzielenie portów między WebAdmin, portalami, WAF i SSL VPN. Lista rezerwacji nie zastępuje tej kontroli.

Zmiana i weryfikacja własnego portu

1. Zapisać stan i zależności

Przed zmianą zapisać port, protokół, IP WAN i strefy dozwolone w Administration > Device access. Spisać też nadrzędne reguły NAT/listenery, adresy URL, monitoring i rozdane profile VPN, aby móc dokładnie przywrócić stan.

Główne pola to Administration > Admin and user settings > Admin console HTTPS port, User portal HTTPS port i VPN portal HTTPS port. Dla SSL VPN: Remote access VPN > SSL VPN > SSL VPN global settings > Protocol i Port. TCP 10443 jest tylko przykładem; mimo braku na liście trzeba sprawdzić listenery, współdzielenie i urządzenia nadrzędne.

2. Sprawdzić dostęp i współdzielenie przed zapisem

W przypadku bezpośredniego dostępu do lokalnych usług zarządzania Administration > Device access określa dozwolone strefy. Zwykła reguła firewalla nie przyznaje tego dostępu i nie rozwiązuje lokalnej kolizji. Dla konkretnego hosta lub sieci należy użyć Local service ACL exception rule, zamiast szerokiego dostępu strefy.

⚠️ Oddzielna ścieżka przez proxy WWW: SFOS traktuje żądania HTTP i HTTPS z proxy WWW firewalla jako wewnętrzne, a nie jako żądania ze strefy klienta. Zablokowanie usługi dla tej strefy w Administration > Device access nie izoluje więc tej ścieżki przez proxy. Użytkownicy z dostępem do proxy mogą przez nią dotrzeć do lokalnych usług HTTPS, takich jak WebAdmin lub portale. Chodzi o dostępność, a nie o obejście logowania czy dostępu do tunelu SSL VPN. Przegląd portali wyjaśnia ten wyjątek Device Access.

Dla SSL VPN sprawdzić również Override hostname, przekierowanie WAN i konfiguracje klientów. Ustawienia globalne trafiają do importowanego pliku .ovpn, dlatego klienci po zmianie wymagają nowej konfiguracji.

3. Wykonać test pozytywny, negatywny i funkcjonalny

Po zapisie połączyć się z dozwolonej strefy pełnym URL-em lub nowym profilem VPN i sprawdzić logowanie, tunel oraz funkcję. Powtórzyć ze strefy zabronionej i upewnić się, że druga usługa nie stała się dostępna. Następnie zaktualizować NAT, monitoring i zakładki oraz wykonać ponowny test. Przyjęcie wartości przez interfejs dowodzi tylko zapisania ustawienia, a nie dostępności usługi ani działania logowania lub połączenia VPN.

Testy pozytywny i negatywny bezpośredniego dostępu nadal są wymagane. Jeśli klienci mogą korzystać z proxy WWW firewalla, należy dodatkowo przetestować pełny nowy adres URL HTTPS faktycznie zmienionej usługi WebAdmin lub portalu przez dokładnie to proxy: z rzeczywistej strefy klienta i zgodnie z zamierzonym dostępem. Udokumentować, czy usługa jest dostępna przez proxy i czy wynik odpowiada planowanemu zezwoleniu lub blokadzie. Odrzucone połączenie bezpośrednie nie dowodzi izolacji tej oddzielnej ścieżki; dostępna strona logowania nie dowodzi jeszcze skutecznego logowania.

4. W razie błędu przywrócić poprzedni stan

W tym samym polu wpisać zapisany port i pierwotny protokół, a reguły NAT/listenery, profile, URL-e i monitoring przywrócić do poprzednich wartości. Powtórzyć oba testy; rollback ma odtworzyć cały stan, a nie jedynie użyć innego dostępnego portu.

Połączenia wychodzące do Sophos to osobny temat: Zezwalanie na wychodzące usługi i porty Sophos.

Typowe błędy

Nie można zapisać wymaganego portu

Sprawdzić numer, w tym trzy zakresy, a następnie lokalne usługi i współdzielenie. Wolny socket ani reguła firewalla nie znoszą rezerwacji produktu.

Port nie jest zarezerwowany, ale nie jest dostępny z zewnątrz

Sprawdzić Administration > Device access, lokalne wyjątki ACL, IP WAN, protokół, NAT, filtrowanie operatora i aktywną usługę. Dla SSL VPN Override hostname musi wskazywać adres osiągalny dla klientów.

Po zmianie portu stare profile przestają działać

Profile VPN, URL-e, monitoring i przekierowania mogą zawierać stary port. Należy je zaktualizować albo wszystkie przywrócić do zapisanej wartości podczas rollbacku.

FAQ