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. Questa funzione è disponibile sia in modalità MTA sia in modalità Legacy; il percorso di menu della policy POP-IMAP opzionale è diverso. Una policy da sola non basta: 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 una policy POP-IMAP scan per mittenti, destinatari o caratteristiche dei messaggi: in Email > Policies and exceptions in modalità MTA oppure in Email > Policies in modalità Legacy.
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.

In Email > General settings > POP and IMAP TLS configuration, selezionare quindi in TLS certificate la CA che ha emesso il certificato del server di posta, precedentemente verificata e importata. Lasciare Allow invalid certificate disattivato. Disattivare la convalida non corregge una controparte non valida, scaduta o non attendibile.

Selezionare la casella Disable legacy TLS protocols per disattivare i protocolli precedenti a TLS 1.1, come documentato nella guida SFOS. 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 modalità MTA il percorso è Email > Policies and exceptions > Add policy > POP-IMAP scan; in modalità Legacy è Email > Policies > Add 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.

Per mittenti e destinatari, scegliere gruppi di indirizzi e-mail o di domini e una corrispondenza esatta o per parola chiave. Singoli indirizzi di test con corrispondenza esatta consentono un ambito pilota preciso; gruppi di domini o parole chiave possono ampliare l’ambito previsto. Verificare l’ambito reale con messaggi corrispondenti e non corrispondenti, senza presumere regole aggiuntive sui caratteri jolly o sulla distinzione tra maiuscole e minuscole.

• Inbound email is: selezionare spam, probable spam, virus outbreak o probable virus outbreak come classificazione.
• Source IP/network address: indicare l’indirizzo IP o di rete del mittente.
• Message size: definire un limite superiore o inferiore della dimensione del messaggio. Questo criterio della policy non sostituisce il limite globale Don’t scan emails greater than.
• Message header: scegliere l’header; per Other, inserire i relativi dettagli. Selezionare poi una corrispondenza esatta o per parola chiave e indicare il valore della parola chiave da confrontare.

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.

Un esempio pilota innocuo usa i propri gruppi di indirizzi di test con corrispondenza esatta e il criterio Message header: Other, dettagli Subject, corrispondenza esatta, valore della parola chiave Test email. Configurare Prefix subject con il prefisso liberamente scelto Pilot e salvare la policy. Per il messaggio corrispondente, l’oggetto atteso passa da Test email a Pilot: Test email. Un secondo messaggio tra gli stessi indirizzi di test con oggetto Control email non corrisponde al criterio dell’header e non dovrebbe ricevere questo prefisso. Adattare indirizzi e prefisso al proprio pilota; testare due messaggi nuovi sullo stesso percorso di recupero previsto. Altre policy attive non devono falsare il confronto.

Per una policy POP-IMAP scan esistente, aprire Email > Policies and exceptions in modalità MTA oppure Email > Policies in modalità Legacy. Selezionare Edit per la policy interessata, modificare le impostazioni necessarie e salvare la policy. Verificare quindi nuovamente il recupero della posta e l’effetto della policy nel percorso previsto del client.

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.

Gerarchia XML e limiti dell’automazione

Per l’automazione, l’oggetto policy si chiama POPIMAPScanningPolicy. La descrizione seguente illustra la struttura documentata per SFOS 22/23, non una richiesta POST testata o pronta per l’invio. Proteggere l’accesso alla XML API spiega come proteggere l’accesso e interpretare le risposte XML. Le opzioni di scansione della regola firewall che effettivamente corrisponde restano necessarie anche per una policy gestita tramite API.

L’esempio documentato distingue tre livelli:

• POPIMAPScanningPolicy/Name identifica la policy da gestire. POPIMAPScanningPolicy/After/Name identifica invece l’altra policy dopo la quale viene posizionata nell’esempio. Il nome della policy da gestire e il riferimento per l’ordine non devono essere confusi. L’esempio documenta questa struttura di posizionamento, ma non un ordine generale di valutazione né il comportamento in caso di riferimento mancante o di omissione di After.
• Sotto POPIMAPScanningPolicy/EmailAddress si trovano SenderEmail, SenderAction, RecipientEmail e RecipientAction. I valori degli indirizzi e gli operatori di corrispondenza appartengono quindi al nodo padre comune EmailAddress, non direttamente all’oggetto policy. La descrizione dei parametri tratta entrambi i valori degli indirizzi come singole stringhe; la selezione dei gruppi nell’interfaccia non implica un ulteriore nodo XML di tipo lista.
• Nell’esempio, FilterCriteria, Action, To e MatchIs si trovano direttamente sotto POPIMAPScanningPolicy, al di fuori di EmailAddress e After. Qui To contiene il prefisso dell’oggetto per l’azione di aggiunta del prefisso, non un indirizzo di destinatario. A seconda del criterio, MatchIs descrive la classificazione delle e-mail in ingresso oppure il valore dell’header da confrontare.

La tabella dei parametri indica Name, SenderEmail, SenderAction, RecipientEmail, RecipientAction, FilterCriteria e Action come obbligatori. Specifica per Name un massimo di 255 caratteri, per To un massimo di 300 e per MatchIs un massimo di 750 caratteri. Questi limiti descrivono i campi, non l’ambito consentito della policy; ad esempio, il valore di indirizzo Any mostrato nell’esempio non è un’impostazione adatta a un pilota circoscritto.

Altri parametri specifici dei criteri sono Address per l’IP o la rete di origine (array di stringhe, più valori), MessageSizeOperator con MessageSize (numero intero) e MessageHeaderString (massimo 765 caratteri) con MessageHeaderOperator per i confronti degli header. La tabella dei parametri elenca questi campi, ma l’esempio mostrato per le e-mail in ingresso non li contiene. Non è quindi un modello XML completo per i filtri basati su IP di origine, dimensione o header; da esso non si deducono nodi padre mancanti, unità di misura della dimensione o dipendenze obbligatorie.

⚠️ Nella descrizione dei parametri, alcuni valori consentiti sono indicati soltanto come simboli non risolti, ad esempio $POPIMAP{SENDER_MATCHTYPE_CONTAINS}, $POPIMAP{RULETYPE_INBOUND_EMAIL} e $POPIMAP{POP_IMAP_ACTION_PREFIX_SUBJECT}. Questi simboli non sono valori letterali confermati per una richiesta POST. L’esempio mostra Contains, InboundEmailIs e Prefix Subject, ma non fornisce una corrispondenza completa per tutte le costanti. Per MessageHeaderOperator, la colonna dei valori predefiniti riporta persino GreaterThan, mentre la descrizione prevede Contains/Equals. Non risolvere questa contraddizione scegliendo un operatore per supposizione e non inviare etichette dell’interfaccia o nomi di simboli come valori API senza verificarli.

Finché i valori concreti e la struttura del filtro necessaria per la build utilizzata non sono stati chiariti, la configurazione tramite l’interfaccia descritta sopra rimane il percorso sicuro e documentato. Prima di una successiva modifica API autorizzata, conservare nomi, ordine, ambito degli indirizzi, criterio e azione; dopo la modifica, leggere nuovamente lo stato salvato oppure verificarlo nell’interfaccia e recuperare nuovamente la coppia di messaggi di test, uno corrispondente e uno non corrispondente. Per Add ed Edit, la documentazione di riferimento elenca i valori di stato XML 200, 500 e 502, ma nessun messaggio esplicativo. Un esito HTTP positivo, da solo, non conferma quindi né la policy salvata né il suo effetto. In questo caso non è stata eseguita alcuna chiamata di scrittura su un’appliance.

Creare la regola firewall per il recupero della posta

Creare la regola in Rules and policies > Firewall rules. In modalità MTA è anche possibile integrare la regola firewall MTA creata automaticamente; per un test pilota ben delimitato, tuttavia, una regola dedicata e circoscritta è più facile da valutare. In modalità Legacy si crea una nuova regola firewall. 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.

Recupero, Firewall Rule ID, parametri TLS e correlazione con warren.log dimostrano insieme il percorso di recupero e TLS previsto, non l’efficacia dell’antivirus. Se è configurata una policy personalizzata Prefix subject, testare anche la coppia di messaggi descritta sopra: Pilot: Test email per il messaggio corrispondente e nessun prefisso Pilot per Control email. Documentare gli oggetti effettivamente consegnati; anche un prefisso corretto dimostra solo l’azione della policy, non l’efficacia dell’antivirus. Se il risultato differisce, controllare gruppi, tipo di corrispondenza, header e altre policy attive, quindi ripetere il test di entrambi i messaggi.

Il test del percorso comprende anche un caso negativo. Per un host pilota non autorizzato o una porta non selezionata, definire prima il trattamento previsto dalle regole, quindi controllare la Rule ID effettiva e le opzioni di scansione. Correggere una seconda regola di scansione involontariamente ampia; una protezione alternativa deliberatamente pianificata non è un difetto. Il test non richiede né un’assenza globale di protezione né un blocco indiscriminato. Se è disponibile una controparte di test appositamente preparata con una catena di certificati non valida, il tentativo di connessione o recupero deve fallire a causa della convalida di quella catena mentre Allow invalid certificate è disattivato sul firewall; 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