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. 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.

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 syntaxen på installerad build med ? före körning. 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.

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. Kör därefter system system_modules show och samma testflöde igen. 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.

FAQ