Sophos Firewall System Modules veilig beheren

Sophos Firewall gebruikt System Modules als protocolhelpers voor verkeer waarbij de firewall extra protocolinformatie moet volgen of rekening moet houden met dynamische verbindingen. SFOS 22 noemt dns, h323, irc, pptp, sip en tftp. Deze modules zijn standaard geladen.

Een geladen module is geen firewallregel en ook geen aanbeveling om het betreffende protocol te gebruiken. De module vervangt geen NAT-regel, route of security policy. Omgekeerd is het ontladen van alle schijnbaar ongebruikte helpers geen zinvolle hardeningmaatregel. De instelling werkt globaal en kan bestaande toepassingen onverwacht beïnvloeden.

⚠️ Beheerregel: Leg eerst de status en de specifieke foutieve flow vast. Wijzig maximaal één module, herhaal dezelfde flow en herstel de oorspronkelijke status als de wijziging geen verbetering oplevert.

De zes modules correct indelen

Bij sip en h323 wordt de helper vaak te snel als oorzaak of oplossing genoemd. De volledige werkwijze met NAT, RTP, time-outs, aangepaste SIP-poort, Packet Capture en echte testgesprekken staat in VoIP-problemen met SIP en RTP oplossen.

De uitgangsstatus in Device Console vastleggen

Deze opdrachten horen in 4. Device Console, niet in Advanced Shell. Open deze via SSH of via admin > Console rechtsboven in WebAdmin. Sta voor SSH in Administration > Device access > Local service ACL SSH toe voor de benodigde zone; de webconsole vereist daar HTTPS. Geef niet ruimer toegang dan voor de beheerbron nodig is.

Lees vóór een wijziging de globale status:

system system_modules show

Bewaar de volledige uitvoer, ook als slechts één module wordt onderzocht. Zo blijft zichtbaar of een gemigreerd of eerder aangepast systeem van de standaard afwijkt. De weergegeven status loaded bewijst alleen de modulestatus, niet dat de helper een bepaalde flow verwerkt of de fout daarin veroorzaakt. Deze status bewijst evenmin dat IRC, SIP of TFTP zonder aangepaste poorten of andere aangepaste argumenten is geconfigureerd. Stel vóór elke wijziging voor de betreffende module expliciet vast en leg vast of er sprake is van een bevestigde standaardconfiguratie zonder aangepaste poorten of andere aangepaste argumenten.

Leg bij IRC, SIP of TFTP met aangepaste argumenten vóór de test de volledige, daadwerkelijk geconfigureerde baseline vast, samen met een ondersteunde procedure voor exact herstel waarvan de werking op de geïnstalleerde build is bevestigd. Voor SIP omvat dit de exacte aangepaste signaleringspoort uit de bestaande betrouwbare configuratiedocumentatie; voor IRC en TFTP omvat dit alle daadwerkelijk geconfigureerde poortwaarden en overige argumentwaarden. Alleen syntaxishelp toont de huidige configuratie niet aan. Als de baseline onduidelijk is, waarden ontbreken of de terugweg met behoud van de oorspronkelijke toestand niet is bevestigd, blijft de betreffende helper ongewijzigd. Raad geen standaardwaarden of herstelopdrachten.

Leg ook bron- en doel-IP, poort, protocol, Rule ID, NAT ID, tijdstip en de exacte toepassingstest vast. Zonder reproduceerbare flow kan een globale wijziging niet betrouwbaar worden beoordeeld. Log Viewer, Policy Test en Packet Capture zijn geschikt voor technische acceptatie.

Precies één module laden of ontladen

De basisopdrachten volgen hetzelfde patroon. De tabel is een referentie, geen opdrachtblok dat volledig moet worden uitgevoerd. De eenvoudige wijziging met deze opdrachten en de omgekeerde bewerking om terug te keren naar de oorspronkelijke toestand zijn uitsluitend bedoeld voor een vooraf bevestigde standaardbaseline zonder aangepaste poorten of andere aangepaste argumenten. Voor aangepast IRC, SIP of TFTP geldt in plaats daarvan uitsluitend de wijzigings- en herstelprocedure die vóór de test is vastgelegd en voor de geïnstalleerde build is bevestigd; zonder deze procedure wordt geen test gestart.

Controleer vóór uitvoering de geïnstalleerde build met de ingebouwde help: voer de bedoelde opdracht in en gebruik ? om de ondersteunde argumenten te tonen. Verstuur niet op goed geluk onvolledige varianten; Sophos waarschuwt dat een onvolledige Device Console-opdracht de daemon access_server kan laten vastlopen. Voer na precies één wijziging opnieuw system system_modules show uit en herhaal daarna de vastgelegde toepassingstest. Parallelle wijzigingen aan NAT, firewallregels, routing, time-outs of PBX bemoeilijken de toewijzing en worden vermeden.

Sophos documenteert expliciet dat SIP load en unload een herstart overleven. De SFOS 22-pagina maakt voor de andere modules niet dezelfde precieze uitspraak over persistentie. Lees hun status na een geplande herstart opnieuw in plaats van persistentie aan te nemen.

Geen aangepaste poorten afleiden uit onvolledige korte syntaxis

De pagina noemt voor IRC, SIP en TFTP extra termen zoals port, portname, default of show, maar legt de exacte invoervorm niet volledig uit. Raad deze waarden niet. Device Console toont met ? de syntaxis van de geïnstalleerde build.

Voor SIP publiceert Sophos afzonderlijk de exacte opdracht system system_modules sip load ports <custom_port>. Deze beslissing hoort bij de VoIP-analyse, niet bij een algemene helpertest. Vervang de placeholder door de signaleringspoort die de provider of PBX werkelijk gebruikt.

Ken de SIP-grenzen vóór de test

De SIP-helper gebruikt standaard UDP-poort 5060. Deze vertaalt lokale IP-adressen in de SIP-header naar openbare adressen en maakt in de firewall een verwachte dynamische spraakverbinding aan. De werking gaat dus verder dan alleen het herkennen van signalering.

Twee grenzen zijn essentieel bij diagnose:

• De helper ondersteunt SIP-mediapoorten alleen in het bereik 1024–65535. Als een geconfigureerde mediapoort daarbuiten valt, verwijdert de firewall de pakketten en meldt het Event Log Invalid Traffic.
• De helper ondersteunt geen SIP- of SDP-bericht dat over meer dan één pakket is verdeeld. Dit kan voorkomen bij SIP via TCP. Sophos noemt een SIP-UDP-controlverbinding als workaround; gebruik die alleen als provider, PBX of SBC dit ondersteunt.

Een aangepaste signaleringspoort en het RTP-mediabereik zijn verschillende waarden. <custom_port> in de laadopdracht is de werkelijk gebruikte SIP-signaleringspoort; leid daar geen RTP-bereik uit af.

Effect en terugweg controleren

Een zinvolle test controleert meer dan de CLI-uitvoer. Controleer na laden of ontladen de specifieke verbindingsopbouw, verkeer in beide richtingen, Rule en NAT ID, drops en de betrokken toepassing. Voor SIP of H.323 omvat dit registratie, inkomende en uitgaande verbindingen en media in beide richtingen. Controleer bij DNS aanvraag en antwoord met de verwachte naam. Controleer bij TFTP ook de bestandsoverdracht.

Blijft het symptoom gelijk of ontstaan nieuwe fouten, zet dan alleen de gewijzigde module terug naar de eerder vastgelegde status:

• Was de module eerder geladen en is de standaardbaseline zonder aangepaste poorten of andere aangepaste argumenten bevestigd, laad de module dan opnieuw met de bijbehorende opdracht ... load.
• Was de module eerder ontladen en is de standaardbaseline zonder aangepaste poorten of andere aangepaste argumenten bevestigd, ontlaad de module dan opnieuw met de bijbehorende opdracht ... unload. Ook hier volstaat de status alleen niet als bewijs dat er geen aangepaste argumenten zijn.
• Was SIP eerder op een aangepaste signaleringspoort geladen, herstel dan exact die vastgelegde waarde met system system_modules sip load ports <previous_custom_port>. Vervang <previous_custom_port> door de waarde uit de baseline, niet door een nieuwe voorbeeldwaarde. Ook deze terugweg moet vóór de test op de geïnstalleerde build zijn bevestigd en de volledige vastgelegde configuratie herstellen.
• Herstel bij IRC of TFTP met aangepaste poorten of andere aangepaste argumenten de volledige vastgelegde baseline uitsluitend met de ondersteunde herstelprocedure die vooraf voor de geïnstalleerde build is bevestigd, niet met een eenvoudige omgekeerde laad- of ontlaadopdracht. Ontbreekt deze procedure, dan blijft de helper vanaf het begin ongewijzigd.

Voer daarna opnieuw system system_modules show uit en herhaal dezelfde testflow. De CLI-uitvoer moet weer overeenkomen met de vastgelegde uitgangstoestand en de test mag het oorspronkelijke toepassingspad niet extra hebben verstoord. Vergelijk bij aangepast IRC, SIP of TFTP daarnaast de volledige geconfigureerde baseline, inclusief alle vastgelegde argumentwaarden, met behulp van de vooraf bevestigde controleprocedure; een overeenkomende modulestatus alleen bewijst niet dat deze configuratie is hersteld. Een herstart is geen vervanging voor deze rollback.

Als het gedrag verandert maar de oorzaak onduidelijk blijft, bewaar dan de status vóór en na, firmwarebuild, logs en Packet Capture. Een globaal ontladen helper mag niet als permanente oplossing blijven staan alleen omdat één korte test beter leek.

Bij SIP bepaalt het symptoom de volgende controle: Invalid Traffic bij ontbrekende media leidt eerst naar de geconfigureerde mediapoort en het bereik 1024–65535. Mislukt TCP-registratie of breken lange SIP-/SDP-berichten af, controleer dan de limiet van één pakket. Als de getoonde modulestatus klopt maar het gedrag niet verandert, bevestig dan eerst de werkelijk gebruikte signaleringspoort en het betrokken Rule-/NAT-pad.

FAQ