Gestire in sicurezza i System Modules di Sophos Firewall

Sophos Firewall utilizza i System Modules come helper di protocollo quando il firewall deve seguire informazioni aggiuntive o considerare connessioni dinamiche. SFOS 22 elenca dns, h323, irc, pptp, sip e tftp. Questi moduli sono caricati per impostazione predefinita.

Un modulo caricato non è una regola firewall né una raccomandazione a utilizzare il relativo protocollo. Non sostituisce una regola NAT, una route o una policy di sicurezza. Anche scaricare tutti gli helper apparentemente inutilizzati non è una misura di hardening sensata. L’impostazione è globale e può modificare in modo imprevisto applicazioni esistenti.

⚠️ Regola operativa: Documentare prima lo stato e il flusso specifico che presenta l’errore. Modificare al massimo un modulo, ripetere lo stesso flusso e ripristinare lo stato originale se non si ottiene un miglioramento.

Distinguere correttamente i sei moduli

Per sip e h323, l’helper viene spesso indicato troppo rapidamente come causa o soluzione. Il processo completo con NAT, RTP, timeout, porta SIP personalizzata, Packet Capture e chiamate di prova è descritto in Risolvere i problemi VoIP con SIP e RTP.

Salvare la baseline in Device Console

I comandi appartengono a 4. Device Console, non ad Advanced Shell. L’accesso avviene tramite SSH oppure da admin > Console nell’angolo in alto a destra di WebAdmin. Per SSH, consentire SSH per la zona necessaria in Administration > Device access > Local service ACL; la console web richiede HTTPS nella stessa sezione. Non ampliare l’accesso oltre la sorgente di amministrazione necessaria.

Prima di una modifica si legge lo stato globale:

system system_modules show

Conservare l’intero output anche quando si analizza un solo modulo. In questo modo rimane visibile se un sistema migrato o modificato in passato differisce dal default. loaded dimostra solo lo stato del modulo, non che l’helper elabori un flusso specifico o ne causi l’errore. Se SIP era stato caricato con una porta personalizzata, registrare anche il valore esatto dalla documentazione di configurazione esistente. Non modificare SIP se tale valore non può essere determinato in modo affidabile, perché non sarebbe possibile preparare un ritorno allo stato precedente.

Registrare anche IP sorgente e destinazione, porta, protocollo, Rule ID, NAT ID, orario e test applicativo esatto. Senza un flusso riproducibile non è possibile valutare una modifica globale. Log Viewer, Policy Test e Packet Capture sono adatti alla verifica tecnica.

Caricare o scaricare esattamente un modulo

I comandi di base seguono lo stesso schema. La tabella è un riferimento, non un blocco da eseguire integralmente.

Prima dell’esecuzione, controllare il build installato con l’help integrato: digitare il comando previsto e usare ? per visualizzare gli argomenti supportati. Non inviare varianti incomplete per tentativi; Sophos avverte che un comando Device Console incompleto può bloccare il daemon access_server. Dopo una sola modifica, eseguire nuovamente system system_modules show e ripetere il flusso applicativo documentato. Modifiche parallele a NAT, regole, routing, timeout o PBX rendono difficile attribuire il risultato e vanno evitate.

Sophos documenta espressamente che load e unload per SIP persistono dopo un riavvio. La pagina SFOS 22 non fornisce la stessa indicazione precisa per gli altri moduli. Leggere nuovamente il loro stato dopo un riavvio pianificato invece di presumere la persistenza.

Non dedurre le porte personalizzate da una sintassi abbreviata incompleta

La pagina elenca per IRC, SIP e TFTP termini aggiuntivi come port, portname, default o show, ma non ne spiega completamente la forma esatta. Questi valori non vanno indovinati. Device Console mostra la sintassi del build installato con ?.

Per SIP, Sophos pubblica separatamente il comando esatto system system_modules sip load ports <custom_port>. Questa decisione appartiene all’analisi VoIP, non a un test generale degli helper. Il placeholder va sostituito con la porta di segnalazione realmente usata dal provider o dal PBX.

Conoscere i limiti SIP prima del test

Per impostazione predefinita, il SIP helper usa la porta UDP 5060. Traduce gli indirizzi IP locali nell’header SIP in indirizzi pubblici e crea nel firewall una connessione voce dinamica attesa. Il suo effetto va quindi oltre il semplice riconoscimento della segnalazione.

Due limiti sono essenziali nella diagnosi:

• L’helper supporta le porte media SIP solo nell’intervallo 1024–65535. Se una porta media configurata è esterna all’intervallo, il firewall scarta i pacchetti e l’Event Log indica Invalid Traffic.
• L’helper non supporta messaggi SIP o SDP distribuiti su più pacchetti. Ciò può avvenire con SIP su TCP. Sophos indica come workaround una connessione di controllo SIP UDP, utilizzabile solo se supportata da provider, PBX o SBC.

Una porta di segnalazione personalizzata e l’intervallo media RTP sono valori distinti. <custom_port> nel comando di caricamento è la porta di segnalazione SIP realmente usata; da essa non si ricava un intervallo RTP.

Verificare effetto e ritorno allo stato iniziale

Un test utile controlla più del solo output CLI. Dopo il caricamento o lo scaricamento, verificare la connessione, il traffico bidirezionale, Rule e NAT ID, i drop e l’applicazione interessata. Per SIP o H.323, controllare registrazione, connessioni in entrata e uscita e media bidirezionali. Per DNS verificare richiesta e risposta con il nome atteso. Per TFTP verificare anche il trasferimento del file.

Se il sintomo rimane invariato o compaiono nuovi problemi, riportare solo il modulo modificato allo stato registrato in precedenza:

• Se era caricato con l’impostazione predefinita, ricaricarlo con il relativo comando ... load.
• Se era scaricato, scaricarlo di nuovo con il relativo comando ... unload.
• Se SIP era caricato su una porta di segnalazione personalizzata, ripristinare esattamente il valore salvato con system system_modules sip load ports <previous_custom_port>. Sostituire <previous_custom_port> con il valore della baseline, non con un nuovo valore di esempio.

Eseguire quindi system system_modules show e lo stesso flusso di test. L’output CLI deve corrispondere alla baseline salvata e il test non deve aver introdotto un ulteriore guasto nel percorso applicativo originale. Un riavvio non sostituisce questo rollback.

Se il comportamento cambia ma la causa rimane incerta, conservare gli stati prima e dopo, il build del firmware, i log e il Packet Capture. Un helper scaricato globalmente non dovrebbe restare una soluzione permanente solo perché un breve test sembra migliore.

Per SIP, il sintomo indica il controllo successivo: Invalid Traffic con media assenti porta prima alla porta media configurata e all’intervallo 1024–65535. Se la registrazione TCP non riesce o i messaggi SIP/SDP lunghi si interrompono, controllare il limite di un solo pacchetto. Se lo stato del modulo visualizzato è corretto ma il comportamento non cambia, confermare prima la porta di segnalazione effettivamente usata e il percorso Rule/NAT interessato.

FAQ