Hantera Sophos Firewall System Modules säkert

Sophos Firewall använder System Modules som protokollhjälpare för trafik där brandväggen behöver följa ytterligare protokollinformation eller ta hänsyn till dynamiska anslutningar. SFOS 22 listar dns, h323, irc, pptp, sip och tftp. Modulerna är laddade som standard.

En laddad modul är varken en brandväggsregel eller en rekommendation att använda motsvarande protokoll. Den ersätter inte en NAT-regel, route eller säkerhetspolicy. Att avlasta alla till synes oanvända hjälpare är inte heller en lämplig hardeningåtgärd. Inställningen gäller globalt och kan oväntat påverka befintliga program.

⚠️ Driftregel: Dokumentera först status och det konkreta flöde som misslyckas. Ändra högst en modul, upprepa samma flöde och återställ ursprungligt tillstånd om ändringen inte ger en förbättring.

Klassificera de sex modulerna korrekt

För sip och h323 anges hjälparen ofta för snabbt som orsak eller lösning. Det fullständiga arbetsflödet med NAT, RTP, timeouter, anpassad SIP-port, Packet Capture och riktiga testsamtal finns i Felsök VoIP-problem med SIP och RTP.

Spara baslinjen i Device Console

Kommandona hör hemma i 4. Device Console, inte i Advanced Shell. Öppna den via SSH eller via admin > Console längst upp till höger i WebAdmin. För SSH måste SSH tillåtas för den nödvändiga zonen under Administration > Device access > Local service ACL; webbkonsolen kräver HTTPS där. Öppna inte åtkomsten bredare än vad som krävs för administrationskällan.

Läs det globala tillståndet före en ändring:

system system_modules show

Spara hela utdata även om bara en modul undersöks. Då syns om ett migrerat eller tidigare ändrat system avviker från standardvärdet. loaded bevisar endast modulens tillstånd, inte att hjälparen bearbetar ett visst flöde eller orsakar felet. Om SIP tidigare har laddats med en anpassad port ska dess exakta värde också dokumenteras från den befintliga konfigurationsdokumentationen. Ändra inte SIP om värdet inte kan fastställas tillförlitligt, eftersom en återställning som bevarar tillståndet då inte kan förberedas.

Dokumentera även käll- och destinations-IP, port, protokoll, Rule ID, NAT ID, tidpunkt och exakt programtest. Utan ett reproducerbart flöde kan en global ändring inte bedömas tillförlitligt. Log Viewer, Policy Test och Packet Capture lämpar sig för teknisk verifiering.

Ladda eller avlasta exakt en modul

Grundkommandona följer samma mönster. Tabellen är en referens, inte ett helt kommandoblock som ska köras.

Kontrollera installerad build med den inbyggda hjälpen före körning: skriv det avsedda kommandot och använd ? för att visa argumenten som stöds. Skicka inte ofullständiga varianter på prov; Sophos varnar för att ett ofullständigt Device Console-kommando kan få daemonen access_server att sluta svara. Kör system system_modules show igen efter exakt en ändring och upprepa därefter det dokumenterade programflödet. Parallella ändringar i NAT, brandväggsregler, routing, timeouter eller PBX försvårar bedömningen och bör undvikas.

Sophos dokumenterar uttryckligen att SIP load och unload behåller tillståndet efter en omstart. SFOS 22-sidan gör inte samma exakta uttalande om de andra modulerna. Läs deras tillstånd igen efter en planerad omstart i stället för att anta beständighet.

Härled inte anpassade portar från ofullständig kortsyntax

Sidan listar ytterligare termer som port, portname, default och show för IRC, SIP och TFTP men förklarar inte den exakta inmatningsformen fullständigt. Gissa inte värdena. Device Console visar syntaxen för installerad build med ?.

För SIP publicerar Sophos separat det exakta kommandot system system_modules sip load ports <custom_port>. Beslutet hör hemma i VoIP-analysen, inte i ett generellt hjälpartest. Ersätt platshållaren med den signaleringsport som leverantören eller PBX faktiskt använder.

Känn till SIP-gränserna före testet

SIP-hjälparen använder som standard UDP-port 5060. Den översätter lokala IP-adresser i SIP-headern till publika adresser och skapar en förväntad dynamisk röstanslutning i brandväggen. Effekten går alltså längre än att bara känna igen signalering.

Två gränser är avgörande vid felsökning:

• Hjälparen stöder endast SIP-medieportar i intervallet 1024–65535. Om en konfigurerad medieport ligger utanför intervallet kasserar brandväggen paketen och Event Log visar Invalid Traffic.
• Hjälparen stöder inte SIP- eller SDP-meddelanden som sträcker sig över mer än ett paket. Detta kan inträffa med SIP över TCP. Sophos anger en SIP-UDP-kontrollanslutning som lösning; använd den bara om leverantören, PBX eller SBC stöder den.

En anpassad signaleringsport och RTP-medieintervallet är olika värden. <custom_port> i laddningskommandot är den SIP-signaleringsport som faktiskt används; härled inte ett RTP-intervall från den.

Verifiera effekt och återställningsväg

Ett meningsfullt test kontrollerar mer än CLI-utdata. Efter laddning eller avlastning kontrolleras den konkreta anslutningen, trafik i båda riktningarna, Rule och NAT ID, drops samt det berörda programmet. För SIP eller H.323 ingår registrering, inkommande och utgående anslutningar och media i båda riktningarna. För DNS kontrolleras fråga och svar med förväntat namn. För TFTP kontrolleras även filöverföringen.

Om symptomet är oförändrat eller nya fel uppstår ska endast den ändrade modulen återställas till det tidigare dokumenterade tillståndet:

• Om den var laddad med standardinställningen ska den laddas igen med motsvarande kommando ... load.
• Om den var avlastad ska den avlastas igen med motsvarande kommando ... unload.
• Om SIP var laddat på en anpassad signaleringsport ska exakt det sparade värdet återställas med system system_modules sip load ports <previous_custom_port>. Ersätt <previous_custom_port> med värdet från baslinjen, inte med ett nytt exempelvärde.

Kör därefter system system_modules show och samma testflöde igen. CLI-utdata måste motsvara den sparade baslinjen och testet får inte ha skapat ett ytterligare fel i det ursprungliga programflödet. En omstart ersätter inte denna rollback.

Om beteendet ändras men orsaken är oklar ska tillstånd före och efter, firmwarebuild, loggar och Packet Capture sparas. En globalt avlastad hjälpare bör inte lämnas som permanent lösning bara för att ett kort test såg bättre ut.

För SIP avgör symptomet nästa kontroll: Invalid Traffic när media saknas leder först till den konfigurerade medieporten och intervallet 1024–65535. Om TCP-registreringen misslyckas eller långa SIP-/SDP-meddelanden bryts ska gränsen på ett paket kontrolleras. Om visad modulstatus är korrekt men beteendet inte ändras ska först den signaleringsport som faktiskt används och den berörda Rule-/NAT-sökvägen bekräftas.

FAQ