Risoluzione dei problemi relativi a Common Email Security Appliance

Introduzione

Questo documento descrive gli errori di configurazione comuni di Cisco Email Security Appliance (ESA).

Ambiente

• Prodotto:Cisco Email Security Appliance (ESA)
• Software:AsyncOS per ESA (versione variabile in base alla distribuzione)
• Ambito: Applicare le presenti linee guida ai criteri di posta in entrata e in uscita, se applicabili; rivedere ogni sezione prima di apportare modifiche.

Prerequisiti

• Accesso amministrativo all'ESA (GUI o CLI)
• Possibilità di esaminare i log di posta e la verifica dei messaggi per la convalida
• Servizi di reputazione SenderBase Punteggio reputazione SBRS abilitato se si utilizzano gruppi di mittenti basati su SBRS
• La tabella Host Access Table (HAT) classifica gli host di connessione prima della valutazione del criterio di posta, che influisce sull'applicazione dei controlli successivi

Verifica generale

• Utilizzare Monitoraggio > Panoramica e verifica messaggi per confermare la classificazione del gruppo di mittenti prevista, le corrispondenze ai criteri e i risultati del recapito dopo le modifiche. Se l'operazione ha esito positivo, dopo la modifica verranno visualizzati il gruppo di mittenti, il criterio e il risultato del recapito previsti.
• Monitoraggio delle quarantene e dei falsi positivi per 7-14 giorni dopo aver ristretto la reputazione o le impostazioni di filtraggio e regolazione per i partner aziendali conosciuti, se necessario.

Errori comuni di configurazione su Email Security Appliance (ESA)

Utilizzare questi controlli per identificare e correggere gli errori di configurazione comuni in Email Security Appliance (ESA). Ciascuna sottosezione utilizza un modello coerente di problema, causa, risoluzione e verifica in modo che il problema possa essere diagnosticato e corretto rapidamente.

HAT (Host Access Table)

Sintomi

• La posta indesiderata è accettata a causa di gruppi di mittenti troppo permissivi e basati sulla reputazione.
• La posta legale è limitata o bloccata a causa di controlli di connessione troppo rigidi.

Causa

• I gruppi di mittenti sono configurati con intervalli SBRS (SenderBase Reputation Score) o impostazioni di verifica DNS (Domain Name System) inappropriati.

Risoluzione

1. Non aggiungere valori SBRS positivi (ad esempio, +5 o +7) all'elenco Consenti. Per gli elenchi Consenti basati su SBRS, utilizza solo i punteggi compresi tra 9,0 e 10,0 e convalida con verifica messaggi.
2. Configurare l'elenco dei mittenti sconosciuti e le funzionalità di verifica DNS solo quando necessario. Se non è necessario, disabilitare UNKNOWNLIST, Envelope SenderDNS Verification e Connecting HostDNS Verification.

3. Per evitare impostazioni incoerenti per i criteri, configurare le impostazioni predefinite globali: scegliere Mail Policies > Mail Flow Policies > Default Policy Parameters (Policy di posta > Parametri criteri predefiniti) e impostare qui le dimensioni dei messaggi e altri parametri predefiniti.
4. Impostare un valore massimo di connessioni predefinito ragionevole per la maggior parte dei mittenti (ad esempio, 3) e applicarlo come valore predefinito per i nuovi criteri di flusso di posta; eseguire la regolazione in base alle esigenze per i mittenti di grandi volumi noti.
5. Configurare l'intervallo SBRS dell'elenco di blocco in base alla tolleranza al rischio. In molte distribuzioni, il blocco di SBRS da -10,0 a -2,0 può determinare basse percentuali di falsi positivi. Convalida con verifica dei messaggi ed adattamento per i partner commerciali.

Policy

Sintomo/Impatto

• La posta viene analizzata o messa in quarantena in modo imprevisto perché i criteri di posta non predefiniti sostituiscono i valori predefiniti globali.
• La posta in uscita attiva operazioni non necessarie del filtro antispam/epidemie, aumentando i tempi di elaborazione e i falsi positivi.
• I messaggi vengono visualizzati vuoti perché gli allegati infetti vengono eliminati e il corpo del messaggio contiene solo il contenuto rimosso.

Causa

• I criteri non predefiniti duplicano o sostituiscono le impostazioni predefinite di protezione da posta indesiderata, antivirus, filtro contenuti o filtro epidemie senza un requisito specifico.
• I criteri in uscita applicano le funzionalità di analisi specifiche per il traffico in entrata.

Risoluzione

1. I criteri di posta elettronica dei nomi per i destinatari a cui si applicano (ad esempio, Inbound_Executives) e i filtri del contenuto dei nomi per l'azione che intraprendono (ad esempio, Q_basic_attachments e Dspoofers).
2. Per i criteri non predefiniti, selezionare Usa impostazioni predefinite per antispam, antivirus, filtri contenuti ed epidemie, a meno che non sia necessaria un'eccezione documentata.
3. Deselezionare la casella di controllo Elimina allegati infetti per evitare di recapitare messaggi con contenuto rimosso che può apparire vuoto.
4. Per le azioni antivirus in uscita, inviare una notifica al mittente anziché al destinatario.
5. Disabilitare i filtri epidemie e la protezione dalla posta indesiderata sui criteri della posta in uscita a meno che non esista uno Use Case in uscita esplicito.

Verifica

• Utilizzare la verifica dei messaggi per verificare che il criterio di posta corrisponda e che le impostazioni di digitalizzazione predefinite vengano ereditate dove previsto.
• Inviare un messaggio di test in uscita controllato e confermare che i filtri antispam ed epidemie non sono applicati a meno che non siano configurati da un'eccezione.

Relay in ingresso

Sintomi

• I server di posta interni vengono trattati come mittenti esterni, il che può causare limitazioni impreviste, operazioni di filtro o azioni basate sulla reputazione.

Causa

• Gli indirizzi IP o le reti del server di posta interna non sono configurati come inoltri in ingresso oppure la funzionalità Inoltro in ingresso è disabilitata.
• Gli host di inoltro interni non sono classificati in un gruppo di mittenti HAT dedicato e ciò può determinare limiti di connessione non intenzionali o un comportamento di prevenzione degli attacchi di tipo DAP (Directory Harvest Attack Prevention).

Risoluzione

1. Nella GUI, selezionare Mail Policies > Incoming Relays (Policy di posta > Inoltri in arrivo), quindi aggiungere gli indirizzi IP o le reti del server di posta interno.
2. Verificare che la funzionalità Incoming Relay sia abilitata (non aggiungere solo voci alla tabella).
3. Creare un gruppo di mittenti HAT (Host Access Table) dedicato per i relay interni elencati nell'elenco Consenti dell'elenco precedente a scopo di report. Se necessario, configurare nessuna limitazione della velocità e nessuna prevenzione degli attacchi di tipo DAP (Directory Harvest Attack Prevention), mantenendo abilitata la scansione antispam e antivirus come richiesto. Il protocollo DHCP limita i tentativi di enumerazione dei destinatari non validi durante la conversazione SMTP (Simple Mail Transfer Protocol).
4. Se la posta viene eliminata in base alla reputazione per il traffico non inoltrato, aggiungere un filtro messaggi che applichi la gestione equivalente alla posta inoltrata, dove richiesto. Esempio:

Drop_Low_Reputation_Relayed_Mail:
if reputation <= -2.0
{ drop(); }

Verifica

• In Monitor > Panoramica, verificare che i server interni non vengano più visualizzati come mittenti esterni non attendibili.
• Nei log di verifica messaggi/posta, verificare che sia applicato il gruppo di mittenti previsto, ad esempio un gruppo di mittenti interni di inoltro.

DNS

Sintomi

• Selezione o divisione del resolver DNS: la configurazione DNS causa errori di recapito, transazioni SMTP lente o controlli basati su DNS di reputazione non riusciti.

Ambiente

• Si applica alle distribuzioni che richiedono la risoluzione DNS pubblica, la risoluzione DNS solo interna o split-horizonDNS per i domini e i servizi interni.

Sintomi

• Il monitoraggio dei messaggi mostra errori/timeout di ricerca DNS per query MX, AAA, PTRR o relative alla reputazione.
• Recapito della posta ritardato a causa di ripetuti tentativi DNS.

Causa

• ESA è configurato per l'utilizzo di resolver che non sono in grado di risolvere i record pubblici, i record interni richiesti o entrambi.
• Split-horizonDNS, che restituisce risposte diverse per lo stesso dominio in base alla rete di origine, è necessario ma non implementato per i domini o i servizi interni.

Risoluzione

Configurare la risoluzione DNS (Domain Name System) in base alla posizione in cui l'ESA risolve i record: Internet pubblica, domini solo interni o entrambi:

1. Utilizzare i resolver ricorsivi pubblici quando l'ESA necessita principalmente di record DNS pubblici e il criterio lo consente.

2. Utilizzare il DNS interno o il DNS ad orizzonte diviso quando l'ESA deve risolvere zone di sola lettura interne, record di scambio di posta interna (MXX), record del protocollo Lightweight Directory Access Protocol (LDAPP) o altri servizi privati.

3. Il DNS pubblico è appropriato quando l'accessorio risolve principalmente i record di posta Internet e non si applicano zone riservate interne o restrizioni delle policy.

Usa InternalDNS o splitDNS quando richiesto

• Domini solo interni
• Record InternalMX
• Split-horizonDNS (risposte diverse per lo stesso dominio in base alla rete di origine)
• I criteri di conformità o sicurezza richiedono resolver ricorsivi interni
• Zone DNS private necessarie per il routing
• Zone DNS private necessarie per Lightweight Directory Access Protocol (LDAPP)
• Zone DNS private necessarie per i servizi interni utilizzati dall'ESA

Verifica

• Confermare che l'ESA è in grado di risolvere i nomi host pubblici e interni richiesti (se applicabile) e che il recapito della posta e la reputazioneControlli basati su DNS riescono a tenere traccia dei messaggi.

Filtri messaggi e contenuti

L'errore più comune consiste nell'aggiungere condizioni corrispondenti nei filtri quando non sono necessarie.

• Condizioni vuote: Lasciare vuota la condizione quando il filtro deve essere eseguito per ogni messaggio in un determinato criterio di posta.
• Comportamento della valutazione: Nei filtri dei messaggi asincroni, una condizione vuota restituisce true, quindi il filtro viene eseguito su ogni messaggio che lo raggiunge.
• Ambito: Controllare l'ambito associando il filtro al criterio di posta in arrivo o in uscita appropriato.
• Ordine: I filtri messaggi valutano gli attributi e le azioni dei messaggi in sequenza. I filtri del contenuto sono in genere nell'ambito dei criteri di posta che li chiamano.

Esempi:

• L'utilizzo della condizione rcpt-to in un filtro messaggi non è in genere necessario se l'obiettivo è quello di individuare un utente o un gruppo specifico. Preferire un criterio Posta in arrivo basato sul destinatario e applicare il filtro contenuti a tale criterio quando il requisito è mappato correttamente ai destinatari o ai gruppi di destinatari. Riservare le condizioni di ricezione per le eccezioni in cui la corrispondenza dei criteri non è in grado di esprimere il requisito.
• La verifica della presenza di un allegato prima di rilasciarlo è in genere ridondante quando si intende bloccare un tipo di allegato specifico. Configurare il filtro per eliminare direttamente il tipo di allegato di destinazione. utilizzare un test di presenza degli allegati solo quando sono necessarie azioni diverse a seconda che esista o meno un allegato.
• Utilizzare delivery() solo quando il messaggio deve ignorare i filtri rimanenti. L'azione recapita() interrompe l'ulteriore elaborazione del filtro e recapita il messaggio; per recapitare la posta senza ignorare i filtri rimanenti, non configurare un'azione delivery() esplicita (si applica il recapito implicito).

Prevenzione inoltro aperto

Sintomo/Impatto

• I test di inoltro eseguiti da terze parti segnalano che l'accessorio accetta indirizzi dei destinatari errati o pericolosi.
• Gli elenchi di blocco pubblico elencano l'IPP di invio perché l'analisi degli indirizzi SMTP consente i modelli comunemente utilizzati per convalidare i relay aperti.

Causa

• L'analisi degli indirizzi SMTP e la gestione dei caratteri del protocollo SMTP di Simple Mail Transfer Protocol consentono formati di indirizzo non validi (ad esempio, segni doppi@) o valori letterali di indirizzo, ovvero indirizzi IP scritti direttamente nell'indirizzo anziché in un nome di dominio.

Risoluzione

Alcuni servizi verificano se l'agente di trasferimento messaggi accetta indirizzi in formato non valido che possono indicare una condizione di inoltro aperto. Configurare un comportamento rigoroso di analisi e rifiuto in modo che l'ESA rifiuti questi indirizzi durante la conversazione SMTP.

• Aggiungere un gruppo mittente HAT dedicato per le origini test di inoltro prima di ALLOWLIST per la segnalazione. Se necessario, non configurare alcuna limitazione della velocità e nessuna prevenzione degli attacchi tramite il servizio Directory Harvest Prevention (DHAP), mantenendo la funzionalità Anti-Spam e Anti-Virus abilitata in base alle esigenze.
• Abilitare l'analisi degli indirizzi rigidi (l'impostazione predefinita è Loose) per impedire l'inserimento di doppi @ negli indirizzi.
• Rifiuta (non eliminare) i caratteri non validi per impedire l'accettazione di indirizzi non validi.
• Rifiutare (non accettare) i valori letterali dell'indirizzo e immettere i caratteri seguenti: *%!\\/?

Verifica

• Eseguire un test di inoltro esterno e confermare che l'ESA rifiuta gli indirizzi dei destinatari in formato non valido durante la conversazione SMTP.
• Utilizzare la verifica messaggi per verificare che il gruppo di mittenti del test di inoltro corrisponda e che la posta sia elaborata con le impostazioni di digitalizzazione previste.

Informazioni correlate

• Documentazione e supporto tecnico
• Guide per l'utente ReviewAsyncOSS for ESA
• Guide all'installazione e alla configurazione di Email Security Appliance (ESA) (HAT, policy di posta e filtri messaggi)

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
3.0	01-Sep-2026	Certificazione.
1.0	13-Oct-2014	Versione iniziale