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 dalla configurazione predefinita. Lo stato loaded visualizzato dimostra solo lo stato del modulo, non che l’helper elabori un flusso specifico o ne causi l’errore. Non dimostra neppure che IRC, SIP o TFTP siano configurati senza porte personalizzate o altri argomenti personalizzati. Prima di ogni modifica, verificare esplicitamente e documentare se il modulo interessato presenta una configurazione predefinita confermata, senza porte personalizzate o altri argomenti personalizzati.

Per IRC, SIP o TFTP con argomenti personalizzati, prima del test conservare la baseline completa effettivamente configurata e una procedura supportata per il ripristino esatto, confermata sul build installato. Per SIP, questo include l’esatta porta di segnalazione personalizzata ricavata dalla documentazione di configurazione esistente e affidabile; per IRC e TFTP, include tutti i valori delle porte e degli altri argomenti effettivamente configurati. Il solo help della sintassi non dimostra la configurazione corrente. Se la baseline non è chiara, mancano valori o non è confermata la procedura di ritorno che preserva lo stato, lasciare invariato l’helper interessato. Non dedurre per tentativi né i valori predefiniti né i comandi di ripristino.

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 di comandi da eseguire integralmente. La semplice modifica con questi comandi e il ripristino tramite il comando inverso sono previsti solo per una baseline predefinita confermata in anticipo, senza porte personalizzate o altri argomenti personalizzati. Per IRC, SIP o TFTP personalizzati, utilizzare invece esclusivamente la procedura di modifica e ripristino conservata prima del test e confermata per il build installato; senza tale procedura, non iniziare alcun test.

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 il modulo era precedentemente caricato e la baseline predefinita senza porte personalizzate o altri argomenti personalizzati è confermata, ricaricarlo con il relativo comando ... load.
• Se il modulo era precedentemente scaricato e la baseline predefinita senza porte personalizzate o altri argomenti personalizzati è confermata, scaricarlo nuovamente con il relativo comando ... unload. Anche in questo caso, il solo stato non è sufficiente a dimostrare l’assenza di argomenti personalizzati.
• Se SIP era precedentemente 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. Anche questa procedura di ritorno deve essere confermata sul build installato prima del test e deve ripristinare l’intera configurazione salvata.
• Per IRC o TFTP con porte personalizzate o altri argomenti personalizzati, ripristinare l’intera baseline salvata esclusivamente con la procedura di ripristino supportata e precedentemente confermata per il build installato, non con un semplice comando inverso di caricamento o scaricamento. Se tale procedura manca, lasciare l’helper invariato fin dall’inizio.

Eseguire quindi nuovamente system system_modules show e lo stesso flusso di test. L’output CLI deve tornare a corrispondere allo stato iniziale salvato e il test non deve aver causato ulteriori problemi al percorso applicativo originale. Per IRC, SIP o TFTP personalizzati, confrontare inoltre l’intera baseline configurata, inclusi tutti i valori degli argomenti salvati, utilizzando la procedura di verifica confermata in anticipo; il solo stato del modulo corrispondente non ne dimostra il ripristino. 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