Ispezionare le porte non standard con Sophos Firewall

Sophos Firewall ispeziona HTTP, HTTPS, FTP, SMTP/S, POP e IMAP sulle rispettive porte standard. Se un’applicazione utilizza uno di questi protocolli su una porta diversa, service-param può assegnare anche tale porta al servizio di ispezione classico.

Il comando non apre genericamente una porta. Non crea un oggetto servizio o una regola firewall e non attiva una policy web, TLS o e-mail. Affinché il traffico venga ispezionato devono coincidere la regola, la porta di destinazione consentita e il percorso di ispezione responsabile. Per le nuove regole web occorre prima stabilire se il flusso viene elaborato da DPI Engine o Web Proxy.

⚠️ service-param è un’assegnazione globale. Una porta aggiuntiva non riguarda solo un host o una regola firewall. Prima della modifica si documentano gli usi esistenti della porta, le policy interessate e un rollback eseguibile.

Quando è appropriato service-param

Il comando è appropriato quando un’applicazione nota utilizza realmente HTTP, HTTPS, FTP, SMTP, SMTPS, POP o IMAP su una porta TCP non standard e il servizio classico corrispondente deve ispezionare tale traffico. Esempi tipici sono un portale HTTPS interno sulla porta 8443 o una configurazione e-mail esplicita su una porta aggiuntiva.

Una porta TCP aperta non dimostra il protocollo atteso. Se su 8443 passa traffico binario proprietario, assegnarlo a HTTPS può interrompere le connessioni anziché aggiungere protezione. Per il traffico web si verifica inoltre se DPI Engine riconosce già il protocollo o se occorre davvero aggiungere una porta servizio al proxy. Per l’e-mail si distingue SMTP con STARTTLS da SMTPS con TLS fin dall’inizio della connessione. Mail Protection in modalità MTA descrive il percorso e-mail effettivo.

service-param non è appropriato se una regola firewall deve soltanto consentire una porta di destinazione aggiuntiva. In Hosts and services > Services si crea un oggetto servizio TCP adeguato e lo si utilizza nella regola. L’assegnazione di ispezione viene aggiunta solo quando anche il proxy o il servizio e-mail responsabile deve elaborare la porta non standard.

Registrare lo stato iniziale nella Device Console

Il comando si esegue da 4. Device Console. Prima di qualsiasi modifica, il comando seguente mostra le porte servizio esistenti e altri valori globali:

show service-param

Si registra l’output completo con build SFOS, ora e riferimento del change. È particolarmente importante verificare se la porta prevista è già assegnata a un altro servizio. La stessa porta non viene assegnata contemporaneamente e senza prove a HTTP, HTTPS, SMTP e SMTPS.

Sophos documenta questi nomi di servizio per SFOS 22:

FTP
HTTP
HTTPS
IMAP
POP
SMTP
SMTPS
IM_MSN
IM_YAHOO

IM_MSN e IM_YAHOO sono etichette legacy nella CLI. Non sono un punto di partenza per un nuovo design di messaggistica istantanea. Le nuove applicazioni vengono protette tramite regole firewall, Application Control, TLS Inspection e il rilevamento dei protocolli effettivamente supportato.

Aggiungere una porta supplementare

La sintassi di base documentata per i servizi supportati è:

set service-param <service> add port <portID>
set service-param <service> delete port <portID>

Per un portale HTTPS confermato su TCP 8443, un test pilota controllato si presenta così:

show service-param
set service-param HTTPS add port 8443
show service-param

La regola firewall richiede inoltre un servizio che consenta TCP 8443 come porta di destinazione. Per HTTPS occorre stabilire quale percorso di ispezione esegue la decrittografia, quale certificato è previsto e se l’applicazione usa Certificate Pinning. Una pagina web visibile non dimostra né la decrittografia né la scansione malware.

Il segnaposto portID nella sintassi Sophos viene utilizzato nella Device Console con il valore concreto della porta. La porta viene aggiunta solo dopo che un Packet Capture o la documentazione dell’applicazione hanno confermato protocollo e porta di destinazione.

Non mescolare le opzioni globali con il test della porta

Per HTTPS, Sophos elenca anche deny_unknown_proto on|off e invalid-certificate allow|block. Anche SMTPS dispone di invalid-certificate allow|block. SMTP offre ulteriori opzioni globali per Failure Notifications, Fast ISP Mode, Notification Port e Strict Protocol Check.

Questi valori risolvono un problema diverso da add port e non vengono modificati nello stesso test pilota. In particolare, invalid-certificate allow può tollerare globalmente errori di certificato, mentre deny_unknown_proto e strict-protocol-check cambiano la gestione delle connessioni non conformi. Una connessione riuscita dopo più modifiche simultanee sarebbe difficile da attribuire e potrebbe ridurre silenziosamente la protezione.

La sintassi ufficiale comprende anche:

set service-param HTTPS deny_unknown_proto <on|off>
set service-param HTTPS invalid-certificate <allow|block>
set service-param SMTPS invalid-certificate <allow|block>
set service-param SMTP failure_notification <on|off>
set service-param SMTP fast-isp-mode <on|off>
set service-param SMTP notification-port add port <portID>
set service-param SMTP strict-protocol-check <on|off>

Prima di una di queste modifiche globali si valutano separatamente l’output esistente esatto, i mittenti o le applicazioni web interessati, l’impatto sulla sicurezza e le indicazioni del supporto. L’articolo non presenta quindi questi comandi come valori predefiniti consigliati.

Verificare l’effetto con un flusso reale

Il test inizia con una sola sorgente pilota e una regola firewall con logging. Prima e dopo la modifica si usano la stessa destinazione, la stessa porta e una nuova connessione. In Log Viewer, Firewall Rule ID, l’azione web o e-mail e l’orario devono corrispondere al test pilota.

Per HTTPS si controllano anche l’emittente del certificato, l’handshake TLS e l’azione Block o Allow prevista. Se la scansione malware fa parte del design, si esegue un test EICAR controllato esattamente su questa porta. EICAR conferma solo il normale percorso antivirus, non ogni funzione TLS, di policy o ML. Per SMTP, SMTPS, POP e IMAP si utilizza un messaggio di test chiaramente identificabile e lo si segue in Mail Logs, Quarantine e, se applicabile, Mail Spool.

Un Packet Capture conferma che il client utilizza realmente la porta di destinazione prevista. Se solo il Firewall Log mostra Allow, non vi è ancora prova che il proxy o il servizio e-mail successivo abbia ispezionato il contenuto. Testare in modo controllato le regole Sophos Firewall combina corrispondenza delle regole, Log Viewer e Packet Capture.

Ripristinare l’assegnazione della porta

Il rollback rimuove dal servizio corretto soltanto la porta aggiunta dal change:

set service-param HTTPS delete port 8443
show service-param

Successivamente si crea di nuovo lo stesso flusso di test. La connettività deve tornare allo stato iniziale documentato. Autorizzazioni temporanee del servizio firewall, regole pilota ed eccezioni vengono rimosse separatamente; delete port non elimina questi oggetti.

Se già l’aggiunta della porta non riesce, si registrano l’errore e show service-param. Spesso la porta viene già trattata come standard o è assegnata a un altro servizio. La voce esistente non viene eliminata alla cieca, poiché un altro percorso di ispezione potrebbe dipenderne.

Checklist operativa

• Applicazione, protocollo e porta di destinazione effettiva sono confermati.
• show service-param e il build SFOS sono registrati prima della modifica.
• Servizio firewall, corrispondenza della regola e assegnazione di ispezione vengono trattati separatamente.
• La porta non è già assegnata a un servizio incompatibile.
• Nel test pilota cambia solo add port, non un’opzione globale del certificato o del protocollo.
• Test positivo, test negativo, log di ispezione e Packet Capture sono preparati.
• Il comando delete port corrispondente e il percorso di ritorno invariato sono pronti.

FAQ