Configurare Mail Protection di Sophos Firewall in Legacy mode

In Legacy mode, Sophos Firewall funziona come proxy di posta trasparente. Il mail server interno rimane l’endpoint SMTP effettivo; il firewall inoltra il traffico attraverso le regole firewall e NAT esistenti e nel frattempo lo controlla per spam, malware, tipi di file o corrispondenze Data Control.

Questo comportamento è sostanzialmente diverso dal MTA mode. Il firewall non diventa un Mail Transfer Agent, non assume la consegna dei messaggi per i domini protetti e non fornisce un MTA mail spool per questo percorso. Un test positivo della porta SMTP non dimostra quindi né la scansione proxy né l’applicazione della policy corretta.

⚠️ La modifica dello SMTP Deployment Mode è un cambiamento globale del percorso di protezione della posta. Prima di commutare devono essere documentati il backup, le policy esistenti, le regole firewall e NAT e un percorso di ripristino testato. Un problema MTA non è un motivo per passare al Legacy mode senza pianificazione.

Legacy mode in nove passaggi

Documentare il percorso SMTP in entrata e in uscita esistente con indirizzi IP, porte, NAT e Firewall Rule IDs.
Verificare se il proxy trasparente è davvero più adatto del MTA mode.
Assicurare un backup della configurazione e un accesso di gestione indipendente.
In Email > General settings, selezionare Switch to legacy mode.
Definire SMTP hostname, limiti di dimensione, azione per i messaggi sovradimensionati, IP Reputation, limiti DoS, porte e comportamento TLS.
Creare solo le policy SMTP malware e SMTP spam necessarie oppure verificarne l’ordine.
Limitare i percorsi DNAT in entrata e SNAT in uscita al mail server effettivo.
Attivare Scan SMTP o Scan SMTPS nelle regole firewall che vengono realmente applicate.
Verificare i messaggi di test in entrata e in uscita mediante Rule ID, risultato della policy, certificato e log del proxy Legacy.

Scegliere Legacy mode o MTA mode

Legacy mode è adatto soprattutto agli ambienti esistenti in cui il mail server interno è già pubblicato direttamente tramite NAT e questo percorso deve essere mantenuto. SFOS si colloca in modo trasparente tra il peer remoto e il server. Destinazione MX, accettazione SMTP e logica di consegna rimangono parte del design del mail server esistente.

MTA mode è invece la scelta più adatta quando il firewall deve accettare direttamente i messaggi, instradarli per dominio protetto, inoltrarli e conservarli in uno spool in caso di errori temporanei di consegna. Mail logs e mail spool appartengono esplicitamente a questo modello operativo. La configurazione completa è descritta in Configurare Mail Protection in MTA mode.

Secondo la guida di SFOS 22, MTA mode non è disponibile su XGS 87/87w e XGS 88/88w. Questo non rende però automaticamente Legacy mode una buona architettura per la posta cloud. Microsoft 365, Google Workspace e i moderni servizi in hosting utilizzano requisiti propri per TLS, autenticazione e protezione dagli abusi. Prima di introdurre un proxy trasparente è necessario verificarne il supporto.

In breve: MTA mode dispone di un proprio flusso di posta. Legacy mode protegge un percorso SMTP già funzionante. Confondere i due modelli porta a cercare nel log sbagliato, nella destinazione NAT errata o in uno spool inesistente.

Topologia di esempio e percorso di ripristino

L’esempio seguente utilizza valori di documentazione e deve essere adattato all’ambiente reale prima dell’implementazione:

mail server interno 10.20.30.25 nella zona DMZ
indirizzo SMTP pubblico 192.0.2.25 sul percorso WAN
servizio SMTP in entrata TCP 25
SMTPS facoltativo su TCP 465, solo se i peer e il server utilizzano realmente questa variante
regole firewall SMTP_In_Legacy e SMTP_Out_Legacy

192.0.2.25 appartiene all’intervallo TEST-NET e non è un valore di produzione. Prima della modifica si eseguono un test in entrata dall’esterno e un test in uscita con timestamp. Si salvano le Rule IDs attualmente applicate, l’indirizzo sorgente pubblico usato dal server in uscita e la catena di certificati.

Il percorso di ripristino non consiste soltanto nel ricambiare la modalità. Anche le nuove opzioni di scansione, l’ordine delle policy, il DNAT, le regole SNAT reflexive o manuali e i test temporanei devono poter essere ripristinati allo stato precedente documentato.

Definire le impostazioni email globali

Dove MTA mode è disponibile, la guida lo indica come modalità predefinita. In Email > General settings, selezionare consapevolmente Switch to legacy mode dopo aver assicurato il percorso di ripristino documentato. Il solo cambio di modalità non crea un percorso email Legacy verificato.

In Email > General settings, SMTP hostname si applica solo alle notifiche generate dal sistema nelle stringhe HELO e del banner SMTP; il valore predefinito è SMTP. Non sostituisce né il FQDN del mail server di produzione né il relativo DNS pubblico. Se lo si modifica, occorre validare una notifica SFOS e non soltanto un normale messaggio generato dal server.

Verifica dell’API XML: La documentazione di SFOS 23 elenca lo stato dell’operazione 506 per Email Configuration, associato a Message.AVGeneralConfInvalidSmtpNtfyHostname. Si tratta di una chiave di messaggio non risolta, non di un messaggio di errore in inglese né di un codice di stato HTTP. Se questo stato compare nella risposta effettiva dell’API XML, controllare il nome host inviato per le notifiche, la risposta dell’operazione e la configurazione salvata prima di considerare la modifica riuscita. La chiave non permette di dedurre regole di validazione specifiche. La voce aggiuntiva nella documentazione non dimostra che il comportamento sia stato introdotto con SFOS 23 né che si applichi a REST.

Limite di dimensione, azione per i messaggi sovradimensionati e protezione DoS

In Email > General settings > SMTP settings, Don’t scan emails greater than definisce la dimensione massima dei messaggi da sottoporre a scansione. Nel percorso SMTP, secondo la guida di SFOS 22, il valore 0 significa 51,200 KB e non illimitato. Per i messaggi più grandi sono disponibili Accept, Reject e Drop.

Accept consegna un messaggio sovradimensionato senza analizzarlo. Reject lo rifiuta e informa il mittente, mentre Drop lo elimina senza notifica. Questa scelta è una decisione consapevole in termini di rischio e operatività. Un Drop non testato complica la diagnosi; un Accept non valutato crea una lacuna di scansione che deve essere documentata.

Verify sender’s IP reputation verifica l’IP del mittente prima dei criteri antispam della policy SMTP e rifiuta i messaggi provenienti da indirizzi IP con cattiva reputazione. In SFOS 22 i sei campi SMTP DoS accettano questi intervalli:

Maximum connections: da 1 a 20000 connessioni al mail server
Maximum connections/host: da 1 a 10000 connessioni da un host
Maximum emails/connection: da 1 a 1000 messaggi per connessione
Maximum recipients/email: da 1 a 256 destinatari per messaggio
Emails rate: da 1 a 20000 messaggi da un host al minuto
Connections rate: da 1 a 20000 connessioni da un host al secondo

Un valore ammesso non è automaticamente adatto. I limiti di produzione vanno ricavati dal volume reale e da una baseline, per evitare che picchi legittimi siano trattati come un DoS.

Bypass spam check for SMTP/S authenticated connections ignora globalmente il controllo antispam per le connessioni che il server email segnala come autenticate. Questa scelta è accettabile solo dopo aver verificato autenticazione, sorgenti consentite e protezione dagli abusi del percorso. Un accesso riuscito non sostituisce né la scansione antimalware né un test negativo con una connessione non autenticata. Anche i domini in Spam check exceptions costituiscono un bypass globale e non vengono usati come rapido sostituto di un’eccezione strettamente limitata.

Il banner globale offre Inline, no conversion, MIME part e Off. Inline, no conversion aggiunge il testo direttamente ai messaggi in uscita; MIME part lo aggiunge come parte MIME separata. Off non aggiunge alcun banner. Inserire solo testo in Email banner, ad esempio una breve nota di riservatezza. Il banner richiede la scansione SMTP o SMTPS nella regola corrispondente. Controllare un messaggio di testo e uno HTML presso il destinatario per verificare contenuto, struttura MIME e presentazione. Poiché la modifica del corpo può invalidare una firma DKIM esistente, verificare anche gli header del percorso in uscita reale.

Pianificare separatamente POP/IMAP e le porte

POP/IMAP dispone di una selezione CA TLS certificate separata in POP and IMAP TLS configuration. Lasciare Allow invalid certificate disattivato per rifiutare certificati server non validi; anche qui Disable legacy TLS protocols blocca solo i protocolli precedenti a TLS 1.1. Le impostazioni SMTP non sostituiscono questa configurazione. Il percorso di accesso alla posta è descritto in Scansione email POP/IMAP, mentre CA e certificati sono trattati in Gestione dei certificati.

Legacy mode comprende anche la scansione trasparente POP3/S e IMAP/S. In POP/S and IMAP/S settings, 0 in Don’t scan emails greater than significa 10,240 KB. Recipient headers determina in quali header SFOS cerca i destinatari usati dalle policy POP/IMAP; i valori predefiniti sono Delivered-To, Received e X-RCPT-TO. Vanno modificati solo se lo giustifica un header acquisito dal server in uso.

Le porte standard documentate sono SMTP 25, SMTPS 465, POP3 con STARTTLS 110, POP3S 995, IMAP con STARTTLS 143 e IMAPS 993. SFOS può analizzare l’email anche su altre porte; la guida cita espressamente la 587. Una porta alternativa deve comparire come servizio nella regola firewall corrispondente ed essere associata al protocollo di scansione attivato. Cambiare soltanto porta non trasforma TLS implicito in STARTTLS o viceversa.

Una policy POP-IMAP scan può combinare gruppi di mittenti e destinatari con criteri quali classificazione in ingresso, indirizzo IP sorgente, dimensione del messaggio o header. Le sole azioni disponibili sono Accept e Prefix subject. La policy non attiva da sola il proxy: in Scan email content della regola firewall corrispondente deve essere selezionato anche il protocollo POP3, POP3S, IMAP o IMAPS effettivamente utilizzato.

Non sopravvalutare TLS per una casella selezionata

In SMTP TLS configuration si seleziona il certificato CA o server previsto per la scansione. Allow invalid certificate rimane disattivato. Secondo la guida, Disable legacy TLS protocols disattiva soltanto i protocolli precedenti a TLS 1.1 e non dimostra una specifica sessione TLS 1.2 o TLS 1.3.

Sophos segnala inoltre un’importante limitazione del Legacy mode: il firewall stabilisce la connessione TLS usando l’indirizzo IP del dominio anziché il nome del dominio. Se più domini condividono lo stesso indirizzo IP, la convalida del certificato può fallire. In questo caso Sophos consiglia un percorso di protezione diverso, come Sophos Email Security. Il controllo non viene aggirato con Allow invalid certificate.

Require TLS negotiation impone TLS per i Remote Hosts o le reti selezionate; Require sender email domains lo impone per i domini mittenti. Se la connessione TLS non può essere stabilita, SFOS elimina i messaggi interessati. Skip TLS negotiation consente intenzionalmente connessioni SMTP non cifrate verso i peer selezionati e deve essere usato solo per eccezioni documentate. Secondo la guida, ogni campo accetta fino a 512 voci host; prima di usare liste estese si escludono sovrapposizioni tra obblighi ed esclusioni.

Utilizzare consapevolmente le policy di scansione

Senza una sottoscrizione Email Protection valida, il traffico email può restare consentito, ma non riceve Email Protection. La raggiungibilità non dimostra quindi né la licenza né la scansione. Le impostazioni globali vengono elaborate prima delle policy SMTP e POP-IMAP. In Email > General settings > SMTP settings, attivare la reputazione IP in Legacy mode con Verify sender’s IP reputation e salvare con Apply; il controllo MTA si chiama invece Reject based on IP reputation. Il banner globale delle email in uscita supporta solo testo.

Dopo l’attivazione della sottoscrizione Email Protection, Sophos Firewall applica automaticamente la policy predefinita default-smtp-av al traffico SMTP in Legacy mode. Le policy personalizzate vengono create in Email > Policies ed elaborate nell’ordine dell’elenco. Occorre quindi verificare innanzitutto quale policy esistente corrisponde al mittente e al destinatario interessati.

Creare nuove policy SMTP in modalità Legacy in Email > Policies > Add policy, scegliendo SMTP malware scan o SMTP spam scan. Per una policy esistente, aprire Email > Policies, selezionare Edit per la policy interessata, modificare le impostazioni necessarie e salvare la policy. Verificare quindi nuovamente l’ordine delle policy e ripetere i test positivo e negativo.

In Email > General settings > Malware protection si seleziona globalmente Sophos o Avira come motore antivirus primario. Se si sceglie Avira, SFOS disattiva Zero-day Protection nelle policy SMTP con Single antivirus. Prima di cambiare motore si inventariano tutte le policy interessate e dopo il cambio le si convalida nuovamente.

SMTP malware scan

Modificare l’ordine trascinando le voci nell’elenco delle policy. Annotare la posizione precedente e ripetere entrambi i test: una policy pilota ristretta non deve essere nascosta dietro una policy più ampia che corrisponde già al traffico.

Durante la creazione, specificare un nome chiaro e i gruppi di indirizzi email o domini di mittenti e destinatari. In Block file types, scegliere gli allegati da bloccare; Ctrl+Shift consente di selezionare più tipi. MIME whitelist permette le intestazioni MIME selezionate, mentre gli altri tipi vengono bloccati secondo la guida. Questa autorizzazione dei tipi di file non aggira l’antivirus. Disable, invece, significa esplicitamente che le email non vengono analizzate.

Delivery option for recipient si applica agli allegati infetti, protetti e sospetti:

Don’t deliver: non invia al destinatario né il messaggio né una notifica.
Deliver original: invia il messaggio originale al destinatario, senza ripulirlo.
Remove and deliver: rimuove l’allegato infetto, notifica la rimozione e consegna il messaggio. Questa azione non si applica ai tipi indicati in Block file types; ciò non consente di dedurre un’altra azione di consegna per i tipi bloccati.

Gli allegati protetti non vengono analizzati; la notifica al destinatario è prevista per impostazione predefinita, salvo configurazione diversa. Salvare con Save e verificare gli esiti reali di consegna e notifica con casi positivi e negativi innocui.

Una policy SMTP malware scan controlla i tipi di file bloccati, le eccezioni MIME, la scansione antivirus e le azioni di consegna. Con Single antivirus, secondo la guida il motore selezionato si applica solo ai messaggi in entrata; quelli in uscita vengono analizzati da entrambi i motori. Dual antivirus esegue in sequenza il motore primario e quello secondario.

L’azione Quarantine viene combinata con le azioni per il destinatario e l’amministratore. Don’t deliver, Deliver original e Remove and deliver hanno conseguenze molto diverse. Un allegato protetto o non analizzabile non deve essere automaticamente equiparato a malware. Ogni azione richiede quindi un messaggio di test, uno stato previsto per il destinatario e un percorso di rilascio documentato.

Quarantine non significa automaticamente che il destinatario non riceva alcun messaggio; la Delivery option for recipient resta determinante. Secondo Sophos, Notify sender funziona solo insieme a Don’t deliver. Gli allegati protetti non vengono analizzati, ma possono attivare una notifica. In Delivery option for administrator, Don’t deliver non notifica gli amministratori; Send original invia loro il messaggio originale. Questo può contenere allegati pericolosi o non analizzati e non sostituisce una notifica sicura. Verificare separatamente gli esiti per mittente, destinatario, amministratore e quarantena.

⚠️ Remove attachment in Delivery option for administrator è escluso da questa guida: il nome del campo suggerisce un’azione per l’amministratore, ma la descrizione indica un messaggio senza allegato al destinatario e una notifica di rimozione agli amministratori. Non ne deriva un’associazione di consegna sicura. Non attivare questa opzione per la prima volta in produzione. Per una prova pilota isolata di allegati infetti, usare Don’t deliver per destinatari e amministratori, monitorare separatamente la quarantena e verificare con modelli di test innocui. Modificare un’impostazione Remove attachment già esistente solo dopo un chiarimento documentato con Sophos Support e una verifica controllata; non presumere né innocuità né pulizia automatica.

Una prova pilota limitata anziché una policy di esempio non verificata

Per il server 10.20.30.25, limitare inizialmente una policy con nome chiaro a un gruppo di destinatari di test del dominio di esempio example.net; sostituire dominio e gruppo con valori propri controllati. Se il dominio manca nella rubrica, aggiungerlo con Create new. In Block file types, scegliere ad esempio Executable files, selezionare Dual antivirus e Quarantine e pianificare separatamente le azioni per destinatario e amministratore indicate sopra. Aggiungere un’autorizzazione MIME solo se giustificata. Un allegato protetto resta non analizzato; non copiare alla cieca Send original per questi allegati da una policy di esempio.

Il limite di esempio 2048 KB appartiene a Don’t scan emails greater than nelle impostazioni SMTP globali, non alla policy pilota né a un valore predefinito fisso. Limita la scansione ai messaggi piccoli. Prima di adottarlo, pianificare l’azione per messaggi sovradimensionati e un test appena sopra il limite in base al volume reale; altrimenti Accept crea una lacuna di scansione oppure Reject e Drop causano problemi di consegna. Le policy SMTP spam e POP/IMAP personalizzate sono integrazioni facoltative secondo necessità, non prerequisiti per creare il solo percorso NAT.

SMTP spam scan

Specificare un nome e i gruppi di indirizzi email o domini di mittenti e destinatari. Scegliere consapevolmente una corrispondenza esatta o per parola chiave per questi gruppi: la ricerca per parola chiave non deve ampliare involontariamente l’ambito. Non presumere sintassi regex, caratteri jolly o regole AND/OR non documentate.

Inbound email is e Outbound email is: scegliere separatamente la direzione; i criteri sono spam, probable spam, virus outbreak o probable virus outbreak.
Source IP/network address e Destination IP/network address: indicare l’IP o la rete richiesta del mittente o destinatario.
Sender remote blacklist: selezionare il gruppo RBL appropriato per il mittente.
Message size: definire un limite superiore o inferiore; non confonderlo con il limite globale per i messaggi sovradimensionati.
Message header: scegliere l’intestazione; per Other, inserire i dettagli, scegliere la corrispondenza esatta o per parola chiave e specificare il valore della parola chiave.

Reject rifiuta il messaggio e informa il mittente. Accept lo consegna. Prefix subject aggiunge un prefisso all’oggetto e consegna il messaggio; ad esempio, Probable spam identifica una prova controllata. Drop scarta senza avvisare il mittente; Quarantine conserva il messaggio in quarantena. La selezione del modello SPX è documentata per Accept e Prefix subject, esclusivamente per le email in uscita. Questo non dimostra il supporto SPX delle altre azioni né la cifratura automatica di ogni messaggio accettato. Salvare con Save e verificare separatamente corrispondenza e azione.

Una policy SMTP spam scan può corrispondere alla classificazione spam, alla sorgente o destinazione, a una RBL, alla dimensione del messaggio, agli header o a una Data Control List. A seconda del percorso, sono disponibili le azioni Reject, Accept, Change recipient, Prefix subject, Drop e Quarantine.

Il criterio Data control list e l’assegnazione SPX in questa policy si applicano solo ai messaggi in uscita. None, invece, applica l’azione selezionata a tutti i messaggi tra i gruppi di mittenti e destinatari specificati. Change recipient non consegna anche al destinatario originale, ma lo sostituisce con la destinazione configurata. Questi tre ambiti vengono verificati con un caso destinatario positivo e uno negativo prima di collocare la policy nell’ordine di produzione.

Preparare tipi di file personalizzati e Data Control

Le categorie predefinite di file per la posta sono Audio files, Backup files, Compressed files, Configuration files, Database files, Developer files, Disk image files, Document files, Dynamic files, Encoded files, Executable files, Image files, Page layout files, Plugin files, System files, Video files e Web files. Classificano per estensione o intestazione MIME e non attestano la sicurezza del file. Ad esempio, Executable files comprende exe, cmd, bat e com; pdf compare in Document files e Page layout files, mentre application/octet-stream compare in più categorie. Non considerare le categorie mutuamente esclusive e non consentire in modo ampio un’intestazione MIME generica per risolvere un singolo allegato. Il riferimento interno dettagliato è in Web Protection; verificare i valori nell’installazione di destinazione prima di scegliere un modello o creare un tipo personalizzato ristretto.

Le CCL possono rilevare modelli come numeri di carte di credito o di previdenza sociale, indirizzi postali e indirizzi email. Usare dati sintetici nella prova pilota, mai dati personali reali. Includere solo modelli adeguati allo scopo e alla regione; una corrispondenza non dimostra autenticità dei dati né classificazione giuridica.

Assegnare un nome al tipo di file personalizzato e salvare l’oggetto con Save prima di modificare la policy. Il percorso di creazione separato per MTA è Email > Policies and exceptions > File type > Add; non sostituisce quello Legacy. I tipi di file sono usati anche nelle policy web; la configurazione appartiene a Web Protection. Assegnare anche un nome chiaro alla Data Control List e selezionare Save dopo la scelta delle CCL.

In Legacy mode, i tipi di file personalizzati si creano in Email > Policies > File type > Add a partire da un template, da estensioni o da tipi MIME. Le estensioni vanno inserite senza il punto iniziale e solo i tipi personalizzati sono modificabili. Un nuovo tipo non viene aggiunto automaticamente alle policy esistenti. Occorre aprire la scan policy interessata, aggiungere il tipo e salvarla nuovamente. Un test positivo con un allegato e un test negativo simile mostrano se viene applicata davvero l’azione prevista.

Una Data Control List si crea in Email > Data control list > Add a partire dalle Content Control List necessarie. I filtri Type e Region aiutano a selezionare solo i modelli pertinenti di dati finanziari, di identità o di altri dati sensibili. Il match della lista non stabilisce ancora un’azione; questa viene configurata nella scan policy collegata. Una piccola lista pilota con un test positivo e uno negativo è più sicura di un’ampia raccolta di CCL non verificate.

In Legacy mode è possibile selezionare SPX in questa policy per i messaggi in uscita. Il modello di password, il portale e la verifica costituiscono tuttavia un processo di sicurezza separato, descritto in Configurare la crittografia email SPX. Alla prima prova di base del proxy non si aggiungono una Data Control List o un’assegnazione SPX.

Una classificazione errata confermata non si risolve disattivando una policy di ampia portata. In modalità Legacy, modificare in modo mirato la policy SMTP malware scan o SMTP spam scan pertinente; un test positivo e un test negativo al di fuori dell’ambito previsto devono confermarne l’effetto. Creare e testare in sicurezza le eccezioni email descrive invece esclusivamente l’oggetto eccezione in modalità MTA: sorgente, mittente o destinatario sono criteri alternativi (OR), non una condizione AND che richiede la corrispondenza esatta di tutte e tre le caratteristiche. Questo oggetto eccezione MTA non è un controllo della modalità Legacy.

Corrispondenze documentate dei tipi di file

Questo riferimento conserva le corrispondenze delle categorie email; non è un elenco di elementi consentiti né una prova di malware. Verificare i valori nell’installazione di destinazione prima delle modifiche. I token MIME tecnici restano invariati, comprese grafie documentate insolite come text/x-script.phyton; ciò non dimostra conformità agli standard né definisce una nuova regola MIME personalizzata.

Audio files

Estensioni: gsm, sd2, qcp, kar, smf, midi, mid, ulw, snd, aifc, aif, aiff, m3url, m3u, wav, rm, au, ram, mp3, wmv.
Intestazioni MIME: audio/x-gsm, audio/vnd.qcelp, audio/x-midi, application/x-midi, audio/midi, audio/x-mid, x-music/x-midi, audio/basic, audio/x-adpcm, audio/aiff, audio/x-aiff, audio/x-mpequrl, audio/wav, audio/x-wav, application/vnd.rn-realmedia, audio/x-au, audio/x-pn-realaudio, audio/mpeg3, audio/x-mpeg-3, audio/x-ms-wmv.

Backup files

Estensioni: asd, bak, bkp, bup, dba, dbk, fbw, gho, nba, old, ori, sqb, tlg, tmp.
Intestazioni MIME: application/octet-stream.

Compressed files

Estensioni: 7z, alz, deb, gz, pkg, pup, rar, rpm, sea, sfx, sit, sitx, tar.gz, tgz, war, zip, zipx.
Intestazioni MIME: application/x-7z-compressed, application/x-alz, application/x-deb, application/x-gzip, application/x-newton-compatible-pkg, application/x-rar-compressed, application/sea, application/x-sea, application/x-sit, application/x-stuffit, application/gnutar, application/x-compressed, application/x-zip-compressed, application/zip, multipart/x-zip.

Configuration files

Estensioni: cfg, clg, dbb, ini, keychain, prf, prx, psf, rdf, reg, thmx, vmx, wfc.
Intestazioni MIME: application/pics-rules, application/octet-stream, application/vnd.ms-officetheme.

Database files

Estensioni: accdb, db, dsn, mdb, mdf, pdb, sql, sqlite.
Intestazioni MIME: application/msaccess, application/x-msaccess, application/vnd.msaccess, application/vnd.ms-access, application/mdb, application/x-mdb, chemical/x-pdb.

Developer files

Estensioni: as, asc, c, cbl, cc, class, cp, cpp, cs, csproj, dev, dtd, f, fs, fsproj, fsx, ftl, gem, h, hpp, ise, ism, java, m, ocx, pas, pod, pro, py, r, rb, sh, src, tcl, trx, v, vbproj, vcproj, vtm, xcodeproj.
Intestazioni MIME: text/plain, text/x-c, application/java, application/java-byte-code, application/x-java-class, text/xml, text/x-fortran, text/x-h, text/x-java-source, text/x-m, application/octet-stream, text/pascal, text/x-script.phyton, application/x-bsh, application/x-sh, application/x-shar, text/x-script.sh, application/x-wais-source, application/x-tcl, text/x-script.tcl.

Disk image files

Estensioni: dmg, iso, mdf, nrg, nri, pvm, toast, vcd, vmdk.
Intestazioni MIME: application/x-cdlink.

Document files

Estensioni: doc, docx, wbk, xls, xlsx, ppt, pptx, oft, pub, msg, one, xsf, xsn, grv, mpp, mpt, acl, pip, thmx, aw, bld, blg, bvp, cdd, cdf, contact, csv, dat, dif, dmsp, efx, epub, epw, exif, exp, fdb, fxp, gbr, gpi, hdf, id2, lib, mat, mcd, menc, mw, ndx, not, notebook, out, ovf, pdx, pfc, pps, ppsx, pptm, prj, qbw, sdf, svf, tar, tsv, vcf, vdb, vxml, windowslivecontact, wlmp, xfd, xml, xsl, xslt, lit, log, lst, odt, opml, pages, rtf, sig, tex, txt, wpd, wps, pdf.
Intestazioni MIME: application/msword, application/vnd.openxmlformats-officedocument.wordprocessingml.document, application/excel, application/vnd.ms-excel, application/x-excel, application/x-msexcel, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, application/mspowerpoint, application/powerpoint, application/vnd.ms-powerpoint, application/x-mspowerpoint, application/vnd.openxmlformats-officedocument.presentationml.presentation, application/x-mspublisher, application/onenote, application/octet-stream, application/vnd.ms-project, application/x-project, application/vnd.ms-officetheme, application/cdf, application/x-cdf, application/x-netcdf, text/comma-separated-values, text/csv, application/csv, video/x-dv, application/x-hdf, application/mcad, application/x-mathcad, application/vnd.openxmlformats-officedocument.presentationml.slideshow, application/vnd.ms-powerpoint.presentation.macroEnabled.12, image/vnd.dwg, image/x-dwg, application/x-tar, text/tab-separated-values, text/x-vcard, application/xml, text/xml, application/x-ms-reader, text/plain, application/rtf, application/x-rtf, text/richtext, application/x-tex, application/wordperfect, application/x-wpwin, application/vnd.ms-works, application/pdf.

Dynamic files

Estensioni: pl, jsp, asp, php, cgi, shtml.
Intestazioni MIME: text/x-script.perl, text/asp, text/x-server-parsed-html, text/html.

Encoded files

Estensioni: bin, enc, hex, hqx, mim, mime, uue.
Intestazioni MIME: application/mac-binary, application/macbinary, application/octet-stream, application/x-binary, application/x-macbinary, application/binhex, application/binhex4, application/mac-binhex, application/mac-binhex40, application/x-binhex40, application/x-mac-binhex40, message/rfc822, www/mime, text/x-uuencode.

Executable files

Estensioni: exe, cmd, bat, com.
Intestazioni MIME: application/bat, application/x-bat, application/x-msdos-program, application/textedit, application/octet-stream, text/plain.

Image files

Estensioni: bmp, gif, jpeg, jpg, pcx, png, heic, heif.
Intestazioni MIME: image/bmp, image/x-windows-bmp, image/gif, image/pjpeg, image/jpeg, image/x-pcx, image/png, image/heif.

Page layout files

Estensioni: idml, indd, inx, isd, mdi, pct, pdf, pmd, ptx, pub, qxb, qxd, qxp, rels, xps.
Intestazioni MIME: image/x-pict, application/pdf, application/x-mspublisher, application/octet-stream, application/vnd.ms-xpsdocument.

Plugin files

Estensioni: 8bi, arx, crx, plugin, vst, xll.
Intestazioni MIME: application/x-visio, application/excel, application/vnd.ms-excel, application/x-excel.

System files

Estensioni: bashrc, cab, cpl, cur, dll, dmp, drv, hlp, ico, key, lnk, msp, prf, profile, scf, scr, sys.
Intestazioni MIME: application/vnd.ms-cab-compressed, application/octet-stream, application/x-msdownload, application/hlp, application/x-helpfile, application/x-winhelp, image/x-icon.

Video files

Estensioni: dat, mov, avi, qt, smi, sml, smil, flc, fli, vfw, mpeg, mpg, m15, m1u, m1a, m75, mls, mp2, mpm, mp, rm, wmv, flv, swf.
Intestazioni MIME: application/octet-stream, application/x-troff-msvideo, video/avi, video/msvideo, video/x-msvideo, video/quicktime, application/smil, application/x-simile, video/flc, video/fli, video/x-fli, video/mpeg, video/x-mpeg, video/x-mpeq2a, application/vnd.rn-realmedia, video/flv, application/x-shockwave-flash.

Web files

Estensioni: alx, asax, asmx, aspx, atom, att, axd, chm, dwt.
Intestazioni MIME: application/atom+xml.

Utilizzare l’email journaling opzionale nel rispetto della protezione dei dati

Assegnare un nome chiaro alla voce di journaling e salvare la selezione dei destinatari e la destinazione del journal con Save prima delle prove seguenti.

In Email > General settings > Email journaling > Add, SFOS può inviare le copie dei messaggi SMTP/S in entrata destinati a utenti o gruppi di indirizzi selezionati a un indirizzo di journaling separato. La selezione Any include tutti i messaggi in entrata. La funzione si applica solo a SMTP/S e non registra il traffico POP o IMAP.

Il journaling crea una copia aggiuntiva dell’email. Non costituisce automaticamente un archivio a prova di manomissione e non dimostra il rispetto degli obblighi legali di conservazione. Prima di attivarlo si definiscono lo scopo, i destinatari autorizzati, l’accesso alla casella di journaling, la crittografia, il periodo di conservazione, lo spazio necessario e il responsabile.

Per il primo test si seleziona una sola casella di prova invece di Any. Un messaggio in entrata destinato a questa casella deve comparire nella destinazione normale e nella casella di journaling; un messaggio per un destinatario non selezionato non deve generare alcuna copia. L’indirizzo di journaling non deve attivare un flusso che rinvia la copia a SFOS e crea un loop.

La selezione dei destinatari viene ampliata solo dopo i test positivo e negativo. Per il rollback si rimuove la voce di journaling oppure si ripristina lo stato precedente documentato. Le copie già recapitate rimangono nella casella di journaling e devono essere gestite secondo le relative regole di conservazione.

Associare in sicurezza gli oggetti email Legacy tramite API XML

I riferimenti dell’API XML per SFOS 22 e 23 descrivono oggetti email specifici per Legacy mode. Un percorso di menu di MTA Mode, una tabella di parametri piatta o un esempio con alternative separate da barre non costituiscono una richiesta pronta da copiare. Accesso API, trasporto, stato dell’operazione, chiavi di messaggio non risolte e controlli dopo la scrittura sono spiegati in Proteggere l’accesso all’API XML. Le associazioni seguenti aiutano a leggere una configurazione esistente; non attestano una chiamata di scrittura testata e non si applicano automaticamente a REST o alla Central API.

Prima di una modifica, salvare il backup, il contenuto attuale dell’oggetto, le policy che lo referenziano e il loro ordine. Chiarire la richiesta concreta e i valori di campo contraddittori sulla base della guida API del build installato o con Sophos Support. Verificare poi separatamente gli oggetti salvati e l’effetto effettivo sulla posta. Il fatto che un campo sia obbligatorio nella tabella non indica se l’omissione di altri campi ne preservi il valore precedente. Non sono dimostrati neppure lo svuotamento, la sostituzione o l’unione di liste, né le modifiche atomiche.

EmailConfiguration: protocollo e contesto TLS fanno parte del campo

In EmailConfiguration, i campi con lo stesso nome sono distinti dai rispettivi elementi padre:

GeneralSettings/EmailSignature e GeneralSettings/EmailBannerMode riguardano il banner in uscita. La tabella API indica i valori di modalità inline_plain, mimepart e off; l’esempio contiene invece alternative simili alle etichette UI. Non trattare questi testi come valori API identici senza verificarli. EmailSignature è una stringa con un massimo di 2000 caratteri secondo la tabella API.
SMTPSSettings/DontScanEmailsGreaterThan è il limite di scansione SMTP in KB; SMTPSSettings/ActionForOversizeEmails è l’azione separata Accept, Reject o Drop. Anche BypassSpamCheck, VerifySendersIPReputation, SMTPSDosSettings e i sei limiti DoS si trovano in SMTPSSettings.
POPIMAPSettings/DontScanEmailsGreaterThan è un altro limite intero in KB. POPIMAPSettings/RecipientHeaders/Header è una lista di stringhe di header per il rilevamento dei destinatari, non una lista di destinatari SMTP.
SMTPTLSConfiguration e POPSIMAPTLSConfiguration contengono ciascuno i propri TLSCertificate, AllowInvalidCertificate e DisableTLS1. Il certificato SMTP non sostituisce quello POP/IMAP. RequireTLSWithHost, RequireTLSWithSenderDomain e SkipTLSHosts si trovano nel contesto TLS SMTP; sono liste separate di stringhe, non un’eccezione comune di attivazione/disattivazione. Non confondere il limite UI di 512 voci host con l’indicazione della tabella API di un massimo di 512 caratteri.

Tenere separati tabella API, esempio e riferimento UI: la tabella API indica 1024 come valore predefinito per entrambi i limiti di scansione. Per MaximumConnections, MaximumConnectionsHost, MaximumEmailsConnection, MaximumRecepientsEmail, EmailsRate e ConnectionsRate indica, nell’ordine, 5000, 100, 100, 100, 1000 e 100. L’esempio utilizza invece 1000 per MaximumEmailsConnection; a sua volta, l’esempio UI 2048 KB illustrato sopra non è un valore predefinito. Il significato di 0 resta quello del riferimento UI specifico per protocollo descritto sopra, non un’impostazione illimitata dedotta dall’esempio API.

La tabella API ammette da 1 a 512 per MaximumRecepientsEmail, mentre il riferimento UI indica da 1 a 256 per Maximum recipients/email. La grafia API MaximumRecepientsEmail resta invariata; non dedurne né un nome di campo corretto né la sicura validità di 512 nella UI. Gli altri cinque intervalli DoS coincidono con quelli UI indicati sopra. Restano determinanti lo stato salvato e la guida del build di destinazione.

Ulteriori conflitti impediscono di adottare ciecamente l’esempio: per VerifySendersIPReputation, la tabella indica on/off e riporta Disable come valore predefinito, mentre l’esempio mostra Enable. Per SMTPSDosSettings, il tipo di dato INTEGER compare accanto al valore predefinito della tabella Disable e al valore dell’esempio Enable. Secondo la tabella, BypassSpamCheck ha il valore predefinito Disable, ma l’esempio lo attiva. Nell’esempio, entrambi i contesti TLS consentono certificati non validi. Non adottare queste impostazioni non sicure dell’esempio e non costruire un payload presuntamente valido a partire dalle indicazioni contraddittorie; resta valida la decisione sicura su TLS e bypass descritta sopra.

Per l’operazione Email Configuration sono documentati 200 con Message.AVGeneralConfUpdateSuccess, 500 con Message.AVGeneralConfUpdateFail e 505 con Message.ASConfigSubOperationFail. SFOS 23 aggiunge l’associazione già illustrata sopra di 506 con Message.AVGeneralConfInvalidSmtpNtfyHostname. Si tratta di stati dell’operazione e chiavi non risolte, non di codici HTTP o testi confermati in fase di esecuzione. In particolare, dopo 505, rileggere prima le impostazioni SMTP, POP/IMAP e TLS; non presumere né un rollback completo né un salvataggio completo e non ripetere ciecamente la chiamata.

Malware SMTP: gestire destinatari e amministratori in modo indipendente

L’oggetto si chiama AntiVirusMailSMTPScanningRules. Name identifica la policy, After/Name il riferimento al predecessore mostrato nell’esempio. SenderList/Sender e ReceiverList/Receiver sono liste separate; BlockFileTypes/FileType è la lista dei tipi di file bloccati. La tabella API riporta inoltre WhiteList come lista MIME, ma nell’esempio non mostra la relativa struttura annidata. Non inventare quindi un ulteriore nodo padre XML.

Per Scanning, la tabella API indica Single Anti-Virus (Maximum Performance), Dual Anti-Virus (Maximum Security) e Disable, con valore predefinito Disable. L’esempio Disable/Disable non è né un’enumerazione completa né un valore utilizzabile per la scansione antivirus desiderata. Quarantine e NotifySender sono controlli indipendenti con Enable/Disable; secondo la tabella API, il valore predefinito di entrambi è Disable. Questi valori della tabella non sostituiscono né la policy predefinita esistente né una prova dello stato attuale della scansione.

Per gli allegati infetti, sospetti e protetti sono previste, in ciascun caso, due azioni scelte indipendentemente:

Destinatari: ReceiverActionInfected, ReceiverActionSuspicious, ReceiverActionProtectedAttachment con Don'tDeliver, DeliverOriginal o RemoveAndDeliver.
Amministratori: NotifyAdministratorInfected, NotifyAdministratorSuspicious, NotifyAdministratorProtectedAttachment con Don'tDeliver, SendOriginal o RemoveAttachment.

La tabella API indica Don'tDeliver come valore predefinito per tutti e sei i campi di azione. Questo non equivale alla descrizione UI di una notifica predefinita per gli allegati protetti e non dimostra alcuno stato attuale di consegna. Restano determinanti gli effetti e i limiti illustrati sopra: DeliverOriginal o SendOriginal possono inoltrare allegati non analizzati o pericolosi; la quarantena non dimostra che la consegna al destinatario sia stata impedita. L’opzione per gli amministratori RemoveAttachment, ancora non chiarita, resta esclusa anche se l’API la elenca tra i valori. Controllare separatamente gli esiti per mittente, destinatario, amministratore e quarantena.

AntiSpamRules: non confondere corrispondenza, ordine e azione

In AntiSpamRules, Name identifica la regola. After/Name è il riferimento mostrato nell’esempio per collocarla dopo un’altra regola. Prima di Add, Edit o Order, salvare l’ordine effettivo e il nome della regola referenziata; la documentazione non descrive automaticamente una sintassi per la prima posizione o per predecessori inesistenti.

RecipientList/Action con RecipientEmail e SenderEmailList/Action con SenderEmail controllano separatamente la corrispondenza del destinatario e del mittente. La tabella API indica Equals o Contains per entrambe le azioni di corrispondenza, con valore predefinito della tabella Contains. Non sono l’azione di consegna. MarkSpamIf contiene invece Condition e i relativi OtherHeader, Operator e MatchIs. Una dimensione del messaggio richiede un confronto di dimensioni; un header una corrispondenza testuale; una classificazione un valore di classificazione. La riga della tabella piatta descrive MatchIs come dimensione intera del messaggio, ma l’esempio utilizza Spam. Non dedurne che ogni tipo di condizione sia numerico. Il valore della tabella 4 e i diversi identificatori di condizione nell’esempio non costituiscono una base per inventare un’associazione di header o valori enumerati.

SMTPAction/Action e SMTPAction/ActionParameter determinano l’azione SMTP e il relativo valore aggiuntivo; SMTPAction/Quarantine è separato da questi. POPIMAPAction/Action e POPIMAPAction/ActionParameter appartengono al percorso di accesso alla posta, il cui esempio mostra solo Accept e Prefix Subject. Non trasferire un’azione SMTP a POP/IMAP. Per Change recipient, il parametro è la destinazione di consegna sostitutiva, non un indirizzo di journaling aggiuntivo. Restano valide le limitazioni descritte sopra per Data Control in uscita e SPX.

Anche qui esempio e tabella sono in conflitto: per Quarantine, l’esempio mostra Enable/Disable, mentre la tabella ammette 0 e Enable. La tabella delle azioni SMTP riporta inoltre Accept With SPX; non dedurre questa grafia API dall’etichetta UI o da un normale Accept. Prima di una chiamata di scrittura, chiarire il valore concreto dipendente dalla condizione anziché inviare le alternative dell’esempio separate da barre.

Per Order SMTP Scanning Policy sono riportati 200 con Message.SpamRuleUpdateRuleOrderSuccess e sia 500 sia 505 con Message.SpamRuleUpdateRuleOrderFail. La stessa chiave identifica quindi due righe di stato, senza spiegarne la causa. Per Add SMTP Scanning Policy è documentato 502 con Message.SpamRuleRecordExists. Prima di ripetere Add o Order, controllare il nome esistente, il contenuto e l’ordine salvato; anche qui valgono la verifica centrale della sicurezza API e i test positivo e negativo della policy.

DataControlList: le firme non sono ancora un’azione di consegna

L’oggetto Legacy DataControlList contiene Name e Signatures/Signature, una lista di nomi di firme CCL. La tabella piatta usa a questo scopo le denominazioni name e signaturename; ciò non giustifica la ridenominazione tacita dei tag XML mostrati nell’esempio. La tabella indica il nome come stringa obbligatoria con un massimo di 255 caratteri e le firme come lista facoltativa di stringhe. Utilizzare il nome effettivo della firma dalla propria selezione CCL disponibile, senza copiarlo dall’esempio relativo ai paesi. L’azione continua a derivare solo dalla policy collegata. Non usare l’altro oggetto MTADataControlList al posto di questo oggetto Legacy.

Per Add Data Control List e Update Data Control List, entrambi i riferimenti riportano 502 con Message.DLPAddSameName e 545 con Message.MTAModeDisableCheck. 545 è un’associazione documentata tra stato e chiave, non un’affermazione verificata secondo cui Legacy Mode vieterebbe questa funzione o sarebbe necessario cambiare modalità. Non cambiare quindi modalità per risolvere l’errore. Controllare la lista salvata e i relativi riferimenti prima di ripetere Add o Update e chiarire la risposta effettiva con la guida del build installato o con Sophos Support.

AVASAddressGroup: esattamente un ramo dipendente dal tipo

AVASAddressGroup è il gruppo di indirizzi Legacy per queste regole email, non un oggetto la cui equivalenza sia dimostrata da un percorso di menu MTA. Name identifica il gruppo; la tabella API indica un massimo di 50 caratteri e, per la Description facoltativa, un massimo di 255. La tabella di GroupType indica RBLIPv4, RBLIPv6, IPAddress e EmailAddressOrDomain, mentre l’esempio usa genericamente RBL. Non normalizzare tacitamente queste grafie.

Il commento nell’esempio richiede esattamente un ramo appropriato al tipo: RBLList/RBLName o RBLFile, IPAddressList/IPAddressNetwork o IPAddressFile, oppure EmailAddressList/EmailAddressDomain o EmailAddressFile. Le voci delle liste sono stringhe; la tabella indica valori multipli e duplicati ignorati. L’esempio mostra insieme le alternative, ma non invita a inviare tutte le liste e tutti i file. Per i gruppi di email/domini, EmailImportType distingue i valori Manual e Import. La tabella indica i formati csv e txt per EmailAddressFile, ma descrive contraddittoriamente il campo come inserimento manuale; l’esempio rimanda al nome del file di una richiesta multipart. Nessuna delle due indicazioni dimostra un’associazione multipart completa o una chiamata di importazione sicura. Chiarire questi dettagli per il build specifico prima di un’importazione.

Per Add Address Group sono documentati 502 con Message.AddrGrpRecordExists, 541 con Message.AddrGrpImportFailed, 542 con Message.AddrGrpEmptyFile1 e 543 con Message.AddrGrpSomeEmailNotImported. Non dedurre dalle chiavi non risolte né quali voci siano state effettivamente importate né un rollback completo. Prima dell’importazione successiva, confrontare i membri salvati con la lista prevista.

Per Delete Address Group, 504, 505 e 506 hanno la stessa chiave Message.AddrGrpForeignKeyExists; 507 è associato a Message.AddrGrpEmailArcKeyExists. Le chiavi non distinguono con certezza i singoli oggetti che referenziano il gruppo. Inventariare policy e riferimenti di journaling prima dell’eliminazione, analizzare la risposta esatta dell’operazione e verificare poi la presenza del gruppo. Non rimuovere ciecamente una policy di protezione collegata per forzare una chiamata di eliminazione.

TrustedDomain, journaling e selezione del motore hanno ambiti diversi

AntiSpamTrustedDomain/DomainList/DomainName è una lista di stringhe di dominio. Add e Delete usano DomainName come identità della lista. La descrizione API parla di un bypass della scansione per i messaggi provenienti da domini attendibili, ma non specifica esattamente quali scanner vengano aggirati. La UI descrive Spam check exceptions come bypass antispam. Non estendere queste due affermazioni né a una garanzia per tutte le scansioni né a un’equivalenza esatta e dimostrata tra API e UI. Gestire i domini solo con uno scopo documentato e un ambito ristretto; prima e dopo Add o Delete, controllare la lista e l’effetto di protezione previsto. Non inventare una richiesta XML completa mancante a partire dalla pagina Delete.

AntiSpamEmailArchiver genera invece copie: Name identifica la voce, RecipientList/Recipient limita i destinatari originali e SendCopyOfEmailTo è l’indirizzo separato per le copie. Secondo la tabella API, nome, destinatari e indirizzo per le copie sono obbligatori; nome e indirizzo per le copie possono avere un massimo di 50 caratteri. La riga del destinatario è descritta come stringa scalare, mentre l’esempio la mostra all’interno di un elemento padre di lista. Non risolvere questa discrepanza con un payload catch-all inventato. La prova pilota su una singola casella descritta sopra, con protezione dei dati, prevenzione dei loop e test negativo, vale anche per l’automazione; una modifica dei destinatari non è una modifica dell’indirizzo per le copie.

MalwareProtection/PrimaryAntiVirusEngine è invece un selettore globale scalare del motore, non un filtro dei destinatari né una singola policy di scansione. La tabella API indica Sophos come valore predefinito; l’esempio Sophos/Avira mostra alternative, non un valore combinato da inviare. Resta da verificare l’effetto di Avira su Zero-day Protection nelle policy SMTP con Single antivirus illustrato sopra. Dopo un cambio, controllare il valore globale salvato e tutte le policy interessate; percorsi documentali separati non ne fanno configurazioni indipendenti dei motori.

Combinare NAT e regole firewall

Pubblicare il percorso SMTP in entrata

In Rules and policies > NAT rules, scegliere la famiglia IP appropriata e aprire Add NAT rule. Deve esistere un oggetto IP host del server interno in Hosts and services > IP host per selezionarlo in Translated destination (DNAT). Nell’esempio in entrata semplice, Translated source (SNAT) e Translated service (PAT) restano Original; in Original service, scegliere solo i servizi SMTP usati, ad esempio SMTP e SMTP[S]. Controllare tutti i campi prima di Save. La traduzione della destinazione NAT non equivale al campo firewall Destination networks, trattato separatamente sotto.

Per i messaggi in entrata, una regola DNAT traduce l’indirizzo WAN pubblico verso il mail server interno. Original Source viene limitato per quanto consentito dal design della posta; Original Destination è l’indirizzo pubblico previsto; Translated Destination è 10.20.30.25 o il mail server effettivo. Original service e translated service restano limitati alle porte SMTP realmente offerte.

Una regola reflexive crea inoltre SNAT per la direzione opposta. Viene selezionata solo se questa esatta identità sorgente pubblica è prevista per il percorso in uscita. Più collegamenti WAN, smarthost o percorsi provider differenti richiedono un design specifico di routing e SNAT. L’ordine generale e la zona di destinazione dopo il NAT sono spiegati in Pubblicare un server tramite DNAT.

Utilizzare due regole firewall ristrette

Per creare una regola in Rules and policies > Firewall rules, scegliere la famiglia di protocollo effettiva IPv4 o IPv6 e aprire Add firewall rule > New firewall rule. Definire il nome e i campi richiesti, poi salvare con Save. Non riutilizzare gli indirizzi IPv4 di esempio di questo articolo in una regola IPv6.

⚠️ Le descrizioni di Destination networks sono in conflitto: l’esempio email Legacy indica il server interno, mentre il percorso generale DNAT basa la corrispondenza firewall sulla destinazione pubblica originale. Questa guida non decide il caso specifico del proxy per supposizione. Documentare la regola in entrata già dimostrata funzionante e mantenerla per la prova pilota. Non creare una nuova regola in entrata di produzione da nessuna delle due associazioni né cambiare la destinazione per tentativi. Per un nuovo percorso, chiarire con Sophos Support o una verifica controllata adeguata prima dell’approvazione, con Rule ID, hit DNAT e catture prima e dopo la traduzione. La variante SNAT in uscita non risolve il conflitto.

Per la verifica, due regole separate sono più comprensibili di una regola bidirezionale con più zone e oggetti Any:

In entrata: da WAN alla zona del server interno, endpoint SMTP 10.20.30.25, solo i servizi SMTP necessari, logging attivato. L’endpoint non prescrive un valore per il campo non risolto Destination networks.
In uscita: zona e host del mail server interno verso WAN o lo smarthost specifico, solo i servizi SMTP necessari, logging attivato

In Scan email content si attiva Scan SMTP in entrambe le direzioni necessarie e Scan SMTPS solo quando SMTPS viene realmente utilizzato. Se in Services manca la porta standard del protocollo selezionato, SFOS propone Add ports. Per una porta non standard si definisce invece deliberatamente il servizio corrispondente. Servizio, NAT, listener del server e opzione di scansione devono descrivere lo stesso percorso; Add ports non sostituisce questa verifica.

Le regole vengono posizionate sopra quelle più generali che corrispondono già allo stesso traffico. Dopo il salvataggio, è determinante la Firewall Rule ID registrata. Struttura delle regole, zona NAT e ordine sono approfonditi in Configurare in sicurezza le regole di Sophos Firewall.

Opzionale: usare un altro indirizzo sorgente pubblico in uscita

Nella regola firewall in uscita, During scheduled time determina quando la regola si applica. Scegliere consapevolmente All the time per un server sempre disponibile. Un orario ristretto può modificare la regola corrispondente fuori dalla finestra; verificare anche allora Rule ID e flusso di posta. Non è una pianificazione della regola SNAT. La regola creata automaticamente all’attivazione di MTA mode appartiene a un altro flusso e non sostituisce questa regola server Legacy; usare la guida MTA per quel percorso.

Questa configurazione riguarda il traffico SMTP inoltrato dal server interno, non i messaggi MTA generati dal sistema. Serve quando è richiesta un’altra identità pubblica assegnata anziché l’indirizzo MASQ WAN. Assegnazione del provider, routing, SPF, RDNS e autorizzazioni del provider devono corrispondere a questa identità; SNAT non modifica tali prerequisiti.

In Network > Interfaces > Add interface > Add alias, scegliere l’interfaccia WAN fisica effettiva, IP version IPv4 e l’indirizzo assegnato con il valore IPv4/Netmask corretto; Save. Percorso del provider, Device Access e controlli dell’alias sono descritti in Configurare un IP alias.
In Hosts and services > IP host > Add, creare un host con nome per lo stesso indirizzo pubblico: IP family IPv4, Type IP, IP address l’indirizzo assegnato; Save. Un oggetto host da solo non associa un indirizzo all’interfaccia.
In Rules and policies > NAT rules > New NAT rule, limitare Original source al server interno effettivo e impostare Translated source (SNAT) sull’host IP pubblico. Limitare Original destination alle destinazioni necessarie o allo smarthost e Original service ai servizi SMTP richiesti. Translated destination (DNAT) e Translated service (PAT) restano Original. Inbound interface e Outbound interface devono corrispondere al percorso reale server-WAN. Salvare con Save e posizionare la regola sopra altre SNAT che corrispondono allo stesso traffico; verificare separatamente gli ordini NAT e firewall. Fondamenti di NAT spiega il principio della prima corrispondenza. Any, Top, Port1 e Port2 negli esempi non sono valori obbligatori.
In Rules and policies > Firewall rules > Add firewall rule > New firewall rule, creare una regola IPv4 in uscita adeguata o verificare quella ristretta esistente: Action Accept, zona e host effettivi del server come sorgente, WAN e destinazioni necessarie, solo i servizi SMTP richiesti, Log firewall traffic attivato. Scegliere Scan SMTP e, se pertinente, Scan SMTPS come sopra; Save e verificare l’ordine firewall indipendentemente da NAT.
Creare una nuova connessione SMTP verso un destinatario esterno controllato. Verificare insieme Firewall Rule ID, NAT Rule ID, IP sorgente tradotto nella cattura o presso il destinatario esterno e consegna effettiva. Una sessione esistente o una prova della porta SMTP non bastano. Provare anche un caso negativo con sorgente fuori ambito o servizio non consentito.

Per il ripristino, ristabilire prima le regole documentate e il relativo ordine, quindi verificare l’IP sorgente precedente e la consegna con una nuova connessione. Rimuovere alias e host IP solo se nessun altro servizio ne dipende.

Verificare il flusso di posta e la scansione proxy

Per prima cosa si invia un piccolo messaggio esterno a una casella di test. In seguito il mail server interno invia un secondo messaggio a un destinatario esterno controllato. Entrambi i test ricevono oggetti univoci e timestamp UTC.

Per STARTTLS sulla porta 25 e una connessione TLS diretta sulla porta 465, da un sistema di test autorizzato possono essere utili i seguenti controlli in sola lettura:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

Sostituire mail.example.net con il FQDN effettivo e testare solo le porte realmente offerte. Questi comandi OpenSSL mostrano la catena di certificati presentata e i parametri TLS negoziati; esaminare eventuali errori di verifica dei certificati. Non verificano esplicitamente il nome host atteso e possono proseguire nonostante gli errori di verifica, quindi una connessione non dimostra che l’autenticazione del certificato sia riuscita. Non dimostrano né la consegna riuscita della posta né la scansione malware, spam o Data Control.

In Log Viewer, sorgente, destinazione, servizio, azione e Firewall Rule ID devono corrispondere alle nuove regole. Per il proxy SMTP/S Legacy, awarrensmtp.log e awarrenmta.log vengono correlati con lo stesso timestamp. I file di log sono descritti in Servizi e log di Sophos Firewall.

Eseguire quindi test negativi separati per l’ambito della regola firewall e la corrispondenza con la policy dei messaggi. Una sorgente o un servizio al di fuori dell’ambito del progetto pilota non deve corrispondere alla regola firewall del progetto pilota e deve seguire l’esito documentato di autorizzazione o blocco; un’altra regola autorizzata può comunque fornire protezione. Un messaggio di test privo del criterio della policy del progetto pilota non deve corrispondere a tale policy né riceverne l’azione specifica, mantenendo tuttavia qualsiasi scansione predefinita o altra scansione applicabile. Per ogni caso, registrare la Firewall Rule ID, la policy e l’esito di consegna attesi e confrontarli con il risultato osservato. Non usare malware reale nei test di produzione; utilizzare modelli di test innocui consolidati e una casella di posta controllata per validare la scansione.

Circoscrivere gli errori in base al sintomo

SMTP funziona, ma la policy non viene applicata

Verificare innanzitutto la Firewall Rule ID. Se corrisponde un’altra regola, correggere ordine, sorgente, destinazione, destinazione NAT e servizio. Se corrisponde la regola prevista, Scan SMTP o Scan SMTPS, ordine delle policy e gruppi di mittenti e destinatari devono essere coerenti con il test. Una policy da sola non attiva il proxy trasparente.

La posta in entrata non raggiunge il server

Controllare separatamente l’indirizzo di destinazione pubblico, l’hit DNAT, la translated destination, la zona di destinazione, il listener del server e il percorso di ritorno. Una connessione TCP aperta fino al firewall non dimostra che DNAT e la regola firewall raggiungano il server interno. Packet Capture e Rule ID devono mostrare ingresso e inoltro.

La posta in uscita usa l’indirizzo IP pubblico sbagliato

Controllare SNAT, la regola reflexive, il gateway WAN, la rotta SD-WAN e il comportamento dei reply packets. Il proxy Legacy non seleziona automaticamente l’indirizzo sorgente pubblico richiesto per SPF, RDNS o l’autorizzazione del provider. Prima di una modifica globale di Route Precedence, dimostrare il percorso specifico.

TLS non funziona dopo l’attivazione della scansione

Registrare FQDN, IP di destinazione, certificato, emittente, catena e versione negoziata. Con più domini su un indirizzo IP, il controllo del certificato basato sull’IP documentato può essere la causa. Allow invalid certificate non viene attivato come soluzione rapida.

Manca un messaggio e nel MTA mail spool non compare nulla

Questo non è un criterio di successo utile in Legacy mode, perché mail spool e i mail logs specifici dell’MTA appartengono al MTA mode. La catena rilevante comprende la regola firewall, il NAT, i log del server SMTP, Log Viewer, awarrensmtp.log e awarrenmta.log. I messaggi in quarantena vengono controllati separatamente in Email > SMTP quarantine.

Eseguire un rollback sicuro

Per il rollback si ripristinano innanzitutto le regole pilota e le opzioni di scansione allo stato precedente documentato. In seguito si rimuovono le nuove assegnazioni delle policy oppure se ne ripristina l’ordine. Le modifiche temporanee a DNAT, SNAT o certificati vengono rimosse solo se nessun altro servizio ne dipende.

Solo dopo si ripristina lo SMTP Deployment Mode, se il change includeva questa commutazione. Il flusso di posta originale in entrata e in uscita deve tornare a funzionare con le Rule IDs, gli indirizzi pubblici e i log server previsti. Messaggi, contenuti della quarantena o log del proxy non vengono eliminati come operazione standard di rollback.

Checklist operativa

Il proxy trasparente è stato scelto consapevolmente e i requisiti MTA sono stati esclusi.
Backup, accesso di gestione e Rule IDs originali sono documentati.
SMTP hostname, limiti SMTP e POP/IMAP, azione per i messaggi sovradimensionati, IP Reputation e limiti DoS sono motivati.
Le porte standard o alternative usate e i POP/IMAP recipient headers corrispondono al percorso reale del server.
Sono stati verificati il motore antivirus primario e il suo effetto su Zero-day Protection nelle policy Single antivirus.
Certificato, eccezioni TLS e domini interessati sono stati verificati.
DNAT, SNAT, zona di destinazione e porte reali del server corrispondono.
Le regole firewall in entrata e in uscita sono ristrette, registrate e la loro corrispondenza è stata dimostrata.
Le policy predefinite e personalizzate hanno un ordine tracciabile.
Il journaling opzionale è limitato ai destinatari necessari e ha uno scopo documentato di protezione e conservazione dei dati.
I test positivo, negativo, TLS e di consegna sono riusciti.
I log del proxy Legacy e del mail server possono essere correlati temporalmente.
Responsabile, data di revisione e percorso di ripristino completo sono registrati.

FAQ

Legacy mode è più semplice e quindi migliore di MTA mode?

Non in generale. Legacy mode protegge un percorso SMTP esistente come proxy trasparente. MTA mode accetta direttamente i messaggi, li instrada per dominio protetto e fornisce mail logs e mail spool. La scelta corretta dipende dal flusso di posta previsto.

Una policy SMTP malware o spam è sufficiente per la scansione?

No. La regola firewall effettivamente applicata deve attivare il protocollo SMTP utilizzato in Scan email content. Policy, servizio, NAT e corrispondenza della regola devono essere coerenti.

Perché non trovo il messaggio in mail spool in Legacy mode?

Perché mail spool e i mail logs specifici dell’MTA appartengono al MTA mode. In Legacy mode si controllano il percorso firewall e NAT, i log del mail server, Log Viewer, awarrensmtp.log e awarrenmta.log.