Analizzare e testare POP3 e IMAP su Sophos Firewall

Sophos Firewall può analizzare le e-mail mentre i client le recuperano tramite POP3, POP3S, IMAP e IMAPS. Non è sufficiente creare una policy POP-IMAP. Solo una regola firewall corrispondente instrada il traffico di posta attraverso il proxy e attiva le impostazioni di scansione e TLS configurate.

Il test di accettazione più importante non è quindi un interruttore verde, ma un recupero reale dal client previsto verso il server di posta previsto. Firewall Rule ID, porta, catena di certificati, versione TLS negoziata e warren.log devono corrispondere al percorso pianificato.

⚠️ Senza Scan email content nella regola firewall che effettivamente corrisponde, SFOS non applica le impostazioni o le policy POP/IMAP. Una policy da sola non offre protezione.

Scansione POP/IMAP in otto passaggi

1. Documentare la rete client, il server di posta, i protocolli e le porte effettivamente utilizzati.
2. Selezionare una singola origine pilota e testare il recupero della posta esistente.
3. Importare in Certificates > Certificate authorities la CA che ha emesso il certificato del server di posta, se non è già attendibile.
4. Definire POP/S and IMAP/S settings e POP and IMAP TLS configuration in Email > General settings.
5. Solo se necessario, creare in Email > Policies and exceptions una policy POP-IMAP scan per mittenti, destinatari o caratteristiche dei messaggi.
6. Creare una regola firewall limitata e registrata per il client pilota e il server di posta e attivare i protocolli necessari in Scan email content.
7. Verificare recupero, connessione TLS, Firewall Rule ID e warren.log con un piccolo messaggio di test.
8. Aggiungere altri client solo dopo i test positivo e negativo e documentare il percorso di rollback.

Cosa protegge il proxy POP/IMAP

POP3 e IMAP servono per recuperare e gestire i messaggi in una casella di posta. Non sono SMTP, che trasporta i messaggi tra mittente, MTA e server di posta. La guida alla modalità MTA spiega quindi MX, routing SMTP, relay, spool e quarantena SMTP; questa guida si concentra sul recupero della posta da parte di un client.

SFOS distingue le porte non cifrate o aggiornate con STARTTLS dalle varianti che usano TLS fin dall’inizio:

• POP3: TCP 110, con passaggio opzionale a TLS mediante STARTTLS
• POP3S: TCP 995, TLS dall’inizio della connessione
• IMAP: TCP 143, con passaggio opzionale a TLS mediante STARTTLS
• IMAPS: TCP 993, TLS dall’inizio della connessione

Nei nuovi progetti i client di posta dovrebbero usare connessioni cifrate. Selezionare un protocollo in SFOS non modifica però la configurazione del client. Se il client usa una porta diversa o aggira la regola pianificata, quel traffico non viene protetto automaticamente dall’opzione standard selezionata.

La scansione POP/IMAP richiede una licenza Email Protection valida. Non sostituisce la protezione del server di posta o la scansione all’arrivo di un messaggio tramite SMTP. Soprattutto con i servizi di posta cloud, occorre prima chiarire se il provider consente ancora il recupero POP/IMAP tradizionale e se un proxy trasparente è compatibile con i suoi requisiti TLS e di autenticazione.

Definire l’esempio e il limite del test

Un pilota controllato evita che una configurazione errata del certificato o della regola coinvolga contemporaneamente tutti i client di posta. Questo esempio utilizza valori di documentazione:

• client pilota 10.20.30.50 nella zona LAN
• server di posta mail.example.net
• indirizzo di destinazione 192.0.2.25
• protocollo utilizzato IMAPS su TCP 993
• regola firewall Pilot_POP_IMAP_Scan

Sostituire 10.20.30.50, mail.example.net e 192.0.2.25 con i valori reali. L’indirizzo di destinazione appartiene all’intervallo di documentazione TEST-NET e non deve essere usato come indirizzo di un server di produzione. Il pilota dovrebbe usare una casella di test dedicata e non l’unico account di un amministratore.

Prima della modifica, recuperare un messaggio e annotare l’autorità emittente del certificato attuale. Conservare inoltre la regola firewall esistente, il relativo contatore e la configurazione del client. In questo modo sarà possibile distinguere in seguito un problema di routing, TLS, scansione proxy o server di posta.

Preparare TLS e i limiti della scansione

CA e convalida del certificato

In Certificates > Certificate authorities aggiungere la CA che ha emesso il certificato del server di posta se il firewall non la considera già attendibile. I file di CA private devono provenire esclusivamente dalla PKI dell’organizzazione o da un’altra fonte verificata. Importare certificati su Sophos Firewall spiega l’importazione generale e il controllo della catena.

Selezionare quindi il TLS certificate previsto in Email > General settings > POP and IMAP TLS configuration. Lasciare Allow invalid certificate disattivato. Disattivare la convalida non corregge una controparte non valida, scaduta o non attendibile.

Secondo la guida SFOS, Disable legacy TLS protocols disattiva i protocolli precedenti a TLS 1.1. L’opzione non dimostra che una determinata sessione utilizzi TLS 1.2 o TLS 1.3. Se lo standard di sicurezza richiede almeno TLS 1.2, verificare la versione negoziata nel percorso reale del client. Se la combinazione impiegata non soddisfa il requisito, interrompere il rollout e valutare un’architettura di protezione diversa.

Poiché il firewall elabora il traffico di posta cifrato per analizzarlo, sul client può comparire un avviso relativo al certificato. Un nuovo avviso non deve essere ignorato. Verificare nome presentato, emittente, catena e attendibilità sul client e correggere la causa prima di un rollout esteso.

Dimensione dei messaggi e header dei destinatari

In POP/S and IMAP/S settings, Don’t scan emails greater than definisce la dimensione massima dei messaggi da analizzare. Per POP/IMAP, 0 non significa illimitato; secondo la guida SFOS imposta il limite a 10,240 KB. I messaggi più grandi non vengono analizzati. Il limite deve rispecchiare gli allegati tipici, le prestazioni disponibili e il rischio residuo accettato.

I Recipient headers aiutano SFOS a identificare i destinatari per le policy POP/IMAP. Per impostazione predefinita, il firewall utilizza Delivered-To, Received e X-RCPT-TO. Aggiungere un altro header solo se il server di posta reale lo imposta in modo affidabile. Un header inventato o rimosso successivamente genera altrimenti corrispondenze di policy difficili da comprendere.

Creare una policy POP-IMAP opzionale

Con una sottoscrizione Email Protection attiva, SFOS applica automaticamente la policy predefinita default-pop-av al traffico POP3/S e IMAP/S. Rimuove gli allegati infettati da virus e sostituisce il corpo del messaggio con una notifica. Questa policy di base automatica deve essere considerata durante i test e la diagnosi prima di attribuire il comportamento a una policy personalizzata.

Una policy POP-IMAP aggiunge criteri e avvisi per gli utenti. In Email > Policies and exceptions > Add a policy > POP-IMAP scan, definire innanzitutto un nome e i gruppi di mittenti e destinatari. La policy può quindi reagire, tra gli altri criteri, a una classificazione spam, a un IP o una rete di origine, alla dimensione del messaggio o a un header.

Le azioni documentate sono Accept e Prefix subject. Prefix subject consegna il messaggio e aggiunge un avviso all’oggetto. La policy non è quindi una regola generale di quarantena o blocco. Se si seleziona None come criterio, l’azione si applica a tutti i messaggi tra i mittenti e i destinatari indicati. Esaminare consapevolmente questa portata prima di salvare.

La policy aggiuntiva può essere omessa nel primo test tecnico del proxy. In questo modo rimane chiaro se la catena di base composta da TLS, regola firewall e scansione funziona già. Aggiungere una policy solo quando è effettivamente necessaria una logica di mittente, destinatario o header.

Creare la regola firewall per il recupero della posta

Creare la regola in Rules and policies > Firewall rules. Deve contenere solo la rete client o l’host pilota previsto, la destinazione del server di posta e le porte di posta effettivamente necessarie. Una regola generale da LAN a WAN con molte funzioni di sicurezza rende difficile la verifica.

Per l’esempio Pilot_POP_IMAP_Scan sono adatti questi valori:

• Source zones: LAN
• Source networks and devices: host 10.20.30.50
• Destination zones: zona del percorso verso il server di posta, di solito WAN per un server esterno
• Destination networks: oggetto host per 192.0.2.25 o per il server di posta reale
• Services: IMAPS
• Log firewall traffic: attivato

In Scan email content attivare Scan IMAPS. Se l’ambiente utilizza realmente altri protocolli, selezionare anche Scan IMAP, Scan POP3 o Scan POP3S. Add ports aggiunge i servizi corrispondenti; successivamente devono comparire in Services nella regola.

Posizionare la regola sopra una regola più generale che corrisponde già allo stesso client e server di posta. Dopo il salvataggio è determinante la Firewall Rule ID effettiva in Log Viewer, non la posizione prevista nell’elenco. Configurare in sicurezza le regole di Sophos Firewall spiega struttura, ordine e verifica della Rule ID.

Testare il percorso completo

Inserire prima un piccolo messaggio innocuo nella casella di test privata. Il client pilota lo recupera tramite FQDN e porta previsti. In Log Viewer, IP di origine, IP di destinazione, servizio, azione e Firewall Rule ID devono corrispondere alla nuova regola. L’incremento del contatore di un’altra regola è una condizione di arresto.

Per controllare certificato e TLS si possono eseguire, ad esempio, queste connessioni di sola lettura da un client nella stessa rete:

openssl s_client -connect mail.example.net:993 -servername mail.example.net
openssl s_client -connect mail.example.net:995 -servername mail.example.net
openssl s_client -starttls imap -connect mail.example.net:143 -servername mail.example.net
openssl s_client -starttls pop3 -connect mail.example.net:110 -servername mail.example.net

Testare solo i protocolli effettivamente offerti dal server di posta. Sostituire mail.example.net con il FQDN reale. L’output conferma certificato, catena e parametri TLS, ma non un login riuscito o la scansione dei contenuti. Terminare la connessione interattiva con Ctrl+C dopo il controllo.

Ripetere quindi il recupero con il client di posta reale. Per l’analisi del proxy usare warren.log; Log Viewer e Packet Capture mostrano inoltre la corrispondenza della regola e il percorso di rete. Annotare insieme timestamp, IP client, IP server, porta e oggetto di test. Servizi e log di Sophos Firewall classifica il file e spiega l’accesso sicuro.

Un test di accettazione affidabile comprende anche un caso negativo. Un host pilota non autorizzato o una porta non selezionata non deve ottenere accidentalmente lo stesso stato di protezione attraverso un’altra regola di scansione ampia. Se è disponibile una controparte di test appositamente preparata con una catena di certificati non valida, deve fallire finché Allow invalid certificate è disattivato; non creare un errore di certificato sulla controparte di produzione per questo test.

Delimitare gli errori in base al sintomo

Il recupero funziona, ma il proxy non analizza

Controllare prima la Firewall Rule ID. Se corrisponde una regola superiore o più generale, correggere ordine, origine, destinazione e servizio. Se corrisponde la regola prevista, l’opzione pertinente Scan IMAP/IMAPS/POP3/POP3S e la porta devono essere attive in Services. Una policy POP-IMAP da sola non attiva il proxy.

Il client di posta segnala un errore di certificato dopo l’attivazione

Registrare FQDN presentato, emittente, validità e catena completa. Controllare quindi la CA selezionata in POP and IMAP TLS configuration e l’attendibilità sul client. Non attivare Allow invalid certificate come soluzione permanente. Se non è chiaro quale certificato venga presentato dal proxy o dal server, eseguire il rollback del pilota prima di coinvolgere altri client.

STARTTLS funziona, ma POP3S o IMAPS no

Controllare separatamente porte e modalità di connessione. POP3 su 110 e IMAP su 143 passano a una sessione cifrata solo mediante STARTTLS; POP3S su 995 e IMAPS su 993 iniziano con TLS. Client di posta, listener del server, servizio firewall e opzione di scansione attivata devono usare la stessa variante.

Un messaggio grande viene consegnato, ma non analizzato

Confrontare Don’t scan emails greater than con la dimensione effettiva del messaggio. Anche 0 limita la scansione POP/IMAP a 10,240 KB. Non aumentare il limite alla cieca per un singolo test senza valutare l’effetto sulle prestazioni e sul rischio accettato.

Manca il prefisso dell’oggetto

Controllare gruppi di mittenti e destinatari, tipo di corrispondenza, criterio e Recipient headers. Il messaggio può essere stato analizzato tecnicamente anche se la policy opzionale non ha corrisposto. Valutare separatamente funzionamento del proxy e azione della policy.

Esercizio e rollback

Dopo un pilota riuscito, aggiungere gradualmente altri client. Durante il rollout monitorare contatori delle regole, warren.log, errori TLS e segnalazioni all’helpdesk. Le modifiche al certificato del server di posta, al FQDN, alla porta o al profilo client devono successivamente seguire lo stesso processo di change, perché cambiano il percorso convalidato.

Per il rollback, rimuovere prima il pilota dalla regola limitata o disattivare l’opzione di scansione corrispondente. Verificare poi che il recupero originale funzioni nuovamente e che corrisponda la regola precedente prevista. Rimuovere una CA importata o un’impostazione POP/IMAP globale solo se nessun altro servizio la utilizza. Non eliminare messaggi, log o certificati come passaggio di rollback standard.

FAQ