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 ladda ur 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

Hela utdata sparas även om bara en modul undersöks. Då förblir det synligt om ett migrerat eller tidigare anpassat system avviker från standardkonfigurationen. Statusen loaded visar endast modulens tillstånd, inte att hjälparen bearbetar ett visst flöde eller orsakar felet i det. Den visar inte heller att IRC, SIP eller TFTP är konfigurerade utan egna portar eller andra anpassade argument. Före varje ändring ska det uttryckligen klarläggas och dokumenteras om den berörda modulen har en bekräftad standardkonfiguration utan egna portar eller andra anpassade argument.

För IRC, SIP eller TFTP med anpassade argument ska hela den faktiskt konfigurerade baslinjen sparas före testet, tillsammans med en stödd procedur för exakt återställning som har verifierats på den installerade builden. För SIP omfattar detta den exakta anpassade signaleringsporten från den befintliga, tillförlitliga konfigurationsdokumentationen; för IRC och TFTP ingår alla faktiskt konfigurerade portvärden och övriga argumentvärden. Enbart syntaxhjälp styrker inte den aktuella konfigurationen. Om baslinjen är oklar, värden saknas eller återställningsvägen som bevarar tillståndet inte har verifierats, lämnas den berörda hjälparen oförändrad. Varken standardvärden eller återställningskommandon får gissas.

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 ladda ur exakt en modul

Grundkommandona följer samma mönster. Tabellen är en referens, inte ett kommandoblock som ska köras i sin helhet. En enkel växling med dessa kommandon och återställning med det omvända kommandot är endast avsedda för en i förväg bekräftad standardbaslinje utan egna portar eller andra anpassade argument. För anpassat IRC, SIP eller TFTP gäller i stället endast den ändrings- och återställningsprocedur som sparats före testet och verifierats för den installerade builden; utan denna påbörjas inget test.

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 urladdning 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 modulen tidigare var laddad och standardbaslinjen utan egna portar eller andra anpassade argument är bekräftad, laddas den igen med motsvarande ... load-kommando.
• Om modulen tidigare inte var laddad och standardbaslinjen utan egna portar eller andra anpassade argument är bekräftad, laddas den ur igen med motsvarande ... unload-kommando. Inte heller här räcker statusen ensam som bevis för att anpassade argument saknas.
• Om SIP tidigare var laddat på en egen signaleringsport återställs exakt detta sparade värde med system system_modules sip load ports <previous_custom_port>. <previous_custom_port> ersätts med värdet från baslinjen, inte med ett nytt exempelvärde. Även denna återställningsväg måste verifieras på den installerade builden före testet och återställa hela den sparade konfigurationen.
• För IRC eller TFTP med egna portar eller andra anpassade argument återställs hela den sparade baslinjen endast med den stödda återställningsprocedur som tidigare verifierats för den installerade builden, inte med ett enkelt omvänt kommando för att ladda eller ladda ur. Om denna procedur saknas lämnas hjälparen oförändrad från början.

Därefter körs system system_modules show och samma testflöde igen. CLI-utdata måste åter motsvara det sparade ursprungstillståndet, och testet får inte ha orsakat ytterligare störningar i det ursprungliga programflödet. För anpassat IRC, SIP eller TFTP jämförs dessutom hela den konfigurerade baslinjen, inklusive alla sparade argumentvärden, med hjälp av den i förväg verifierade kontrollproceduren; en motsvarande modulstatus räcker inte i sig för att bevisa att baslinjen har återställts. En omstart ersätter inte denna återställning.

Om beteendet ändras men orsaken är oklar ska tillstånd före och efter, firmwarebuild, loggar och Packet Capture sparas. En hjälpare som har laddats ur globalt 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