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. loaded bewijst alleen de modulestatus, niet dat de helper een bepaalde flow verwerkt of de fout veroorzaakt. Als SIP eerder met een aangepaste poort is geladen, leg dan ook de exacte waarde uit de bestaande configuratiedocumentatie vast. Wijzig SIP niet als die waarde niet betrouwbaar kan worden vastgesteld, want dan kan geen statusbehoudende terugweg worden voorbereid.

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 volledig uit te voeren opdrachtblok.

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 deze met de standaardinstelling geladen, laad hem dan opnieuw met de bijbehorende opdracht ... load.
• Was deze ontladen, ontlaad hem dan opnieuw met de bijbehorende opdracht ... unload.
• Was SIP op een aangepaste signaleringspoort geladen, herstel dan exact de opgeslagen 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.

Voer daarna opnieuw system system_modules show en dezelfde testflow uit. De CLI-uitvoer moet overeenkomen met de opgeslagen baseline en de test mag geen extra storing in het oorspronkelijke toepassingspad hebben veroorzaakt. Een herstart vervangt deze rollback niet.

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