Fehlerbehebung bei häufigen Fehlern der E-Mail-Security-Appliance

Einleitung

In diesem Dokument werden häufige Konfigurationsfehler auf der Cisco E-Mail Security Appliance (ESA) beschrieben.

Umwelt

• Produkt: Cisco E-Mail Security Appliance (ESA)
• Software:AsyncOS für ESA (Version variiert je nach Bereitstellung)
• Geltungsbereich: Wenden Sie diesen Leitfaden bei Bedarf auf Richtlinien für eingehende und ausgehende E-Mails an. Überprüfen Sie jeden Abschnitt, bevor Sie Änderungen vornehmen.

Voraussetzungen

• Administrationszugriff auf die ESA (GUI oder CLI)
• Überprüfung von E-Mail-Protokollen und Nachrichtenverfolgung zur Validierung
• SenderBase Reputation SBRS für Reputationsdienste aktiviert, wenn SBRS-basierte Absendergruppen verwendet werden
• Bekanntheit, dass die Host Access Table (HAT) verbindende Hosts vor der Bewertung der E-Mail-Richtlinien klassifiziert, was sich darauf auswirkt, wie spätere Kontrollen angewendet werden

Allgemeine Überprüfung

• Verwenden Sie Überwachen > Übersicht und Nachrichtenverfolgung, um die erwartete Absendergruppenklassifizierung, Richtlinienübereinstimmungen und Zustellungsergebnisse nach Änderungen zu bestätigen. Erfolgreich bedeutet, dass die erwartete Absendergruppe, Richtlinie und das erwartete Übermittlungsergebnis nach der Änderung angezeigt werden.
• Überwachung von Quarantänen und Fehlalarmen für 7-144 Tage nach Verschärfung der Reputations- oder Filtereinstellungen und Anpassung an bekannte Geschäftspartner bei Bedarf

Häufige Konfigurationsfehler auf der E-Mail-Security-Appliance (ESA)

Verwenden Sie diese Prüfungen, um häufige Konfigurationsfehler auf der E-Mail Security Appliance (ESA) zu erkennen und zu korrigieren. In jedem Unterabschnitt werden ein konsistentes Problem, eine konsistente Ursache, eine konsistente Problemlösung und ein konsistentes Verifizierungsmuster verwendet, sodass das Problem schnell diagnostiziert und behoben werden kann.

Host Access Table (HAT)

Symptome

• Spam wird aufgrund zu großzügiger, reputationsbasierter Absendergruppen akzeptiert.
• Zulässige E-Mails werden aufgrund zu strenger Verbindungskontrollen eingeschränkt oder blockiert.

Ursache

• Absendergruppen werden mit ungeeigneten SBRS-Bereichen (SenderBase Reputation Score) oder DNS-Verifizierungseinstellungen (Domain Name System) konfiguriert.

Auflösung

1. Fügen Sie der Zulassungsliste keine positiven SBRS-Werte (z. B. +5 oder +7) hinzu. Verwenden Sie für SBRS-basierte Zulassungslisten nur Bewertungen von 9.0 bis 10.0, und validieren Sie diese mit Nachrichtenverfolgung.
2. Konfigurieren Sie die Liste unbekannter Absender und die DNS-Verifizierungsfunktionen nur, wenn dies erforderlich ist. Wenn nicht erforderlich, deaktivieren Sie UNKNOWNLIST, Envelope SenderDNS-Verifizierung und Connecting HostDNS-Verifizierung.

3. Um inkonsistente richtlinienbasierte Einstellungen zu vermeiden, konfigurieren Sie die globalen Standardeinstellungen: Wählen Sie Mail-Policys > Mail Flow-Policys > Standard-Policy-Parameter, und legen Sie die Nachrichtengröße und andere Standardparameter fest.
4. Legen Sie für die meisten Absender einen vernünftigen Standardwert für die maximale Anzahl von Verbindungen fest (z. B. 3), und wenden Sie ihn als Standard für neue Mail Flow-Richtlinien an. bei Bedarf für bekannte Absender mit hohem Datenvolumen anpassen.
5. Konfigurieren Sie den SBRS-Bereich der Sperrliste basierend auf Ihrer Risikotoleranz. In vielen Bereitstellungen kann die Blockierung von SBRS -10,0 bis -2,0 zu geringen Fehlalarmquoten führen. Mit Nachrichtenverfolgung validieren und für Geschäftspartner anpassen.

Richtlinie

Symptome/Auswirkungen

• E-Mails werden unerwartet gescannt oder in Quarantäne gestellt, da nicht standardmäßige E-Mail-Richtlinien globale Standardeinstellungen außer Kraft setzen.
• Ausgehende E-Mails lösen unnötige Anti-Spam-/Outbreak-Filter-Aktionen aus und erhöhen so die Verarbeitungszeit und Fehlalarme.
• Nachrichten werden leer angezeigt, da infizierte Anhänge entfernt werden und der Nachrichtentext nur den entfernten Inhalt enthält.

Ursache

• Nicht standardmäßige Richtlinien duplizieren oder überschreiben standardmäßige Anti-Spam-, Anti-Virus-, Content-Filter- oder Outbreak-Filtereinstellungen ohne eine bestimmte Anforderung.
• Richtlinien für ausgehenden Datenverkehr wenden Scan-Funktionen für eingehenden Datenverkehr an.

Auflösung

1. Benennen Sie E-Mail-Richtlinien für die Empfänger, auf die sie angewendet werden (z. B. Inbound_Executives), und benennen Sie Content-Filter für die von ihnen ergriffenen Maßnahmen (z. B. Q_basic_attachment und Despofer).
2. Wählen Sie für nicht standardmäßige Richtlinien die Option Standardeinstellungen für Anti-Spam, Anti-Virus, Inhaltsfilter und Outbreak-Filter verwenden, es sei denn, eine dokumentierte Ausnahme ist erforderlich.
3. Deaktivieren Sie das Kontrollkästchen Infizierte Anhänge löschen, um Nachrichten mit gelöschten Inhalten, die leer angezeigt werden können, nicht zuzustellen.
4. Bei ausgehenden Anti-Virus-Aktionen benachrichtigen Sie den Absender und nicht den Empfänger.
5. Deaktivieren Sie Outbreak-Filter und Anti-Spam für Richtlinien für ausgehende E-Mails, sofern kein expliziter Anwendungsfall für ausgehende E-Mails vorliegt.

Überprüfung

• Verwenden Sie die Nachrichtenverfolgung, um zu bestätigen, dass die beabsichtigte E-Mail-Richtlinie zugeordnet wurde und dass die Standardscannereinstellungen bei Bedarf übernommen werden.
• Senden Sie eine kontrollierte ausgehende Testnachricht, und bestätigen Sie, dass die Anti-Spam-/Outbreak-Filter nur nach einer Ausnahmekonfiguration angewendet werden.

Eingehende Relays

Symptome

• Interne Mail-Server werden als externe Absender behandelt, was zu unerwarteten Drosselungs-, Filter- oder reputationsbasierten Aktionen führen kann.

Ursache

• Interne IP-Adressen oder Netzwerke des Mail-Servers sind nicht als eingehende Relays konfiguriert, oder die Funktion für eingehende Relays ist deaktiviert.
• Die internen Relay-Hosts werden nicht als dedizierte HAT-Absendergruppe klassifiziert. Dies kann zu unbeabsichtigten Verbindungsbeschränkungen oder DHAP-Verhalten (Directory Harvest Attack Prevention) führen.

Auflösung

1. Wählen Sie in der GUI Mail Policies > Incoming Relays (Mail-Richtlinien > Eingehende Relays), und fügen Sie Ihre internen IP-Adressen oder Netzwerke des Mail-Servers hinzu.
2. Stellen Sie sicher, dass die Funktion "Incoming Relay" aktiviert ist (fügen Sie der Tabelle nicht nur Einträge hinzu).
3. Erstellen Sie zu Berichtszwecken eine dedizierte Host Access Table (HAT)-Absendergruppe für interne Relays, die in der Zulassungsliste in der vorherigen Liste aufgeführt sind. Konfigurieren Sie ggf. keine Ratenbeschränkung und keinen DHAP (Directory Harvest Attack Prevention), und aktivieren Sie bei Bedarf Anti-Spam- und Anti-Virus-Scanning.DHAP beschränkt ungültige Aufzählungsversuche während der SMTP-Konversation (Simple Mail Transfer Protocol).
4. Wenn Sie E-Mails basierend auf der Reputation für nicht weitergeleiteten Datenverkehr verwerfen, fügen Sie einen Nachrichtenfilter hinzu, der bei Bedarf eine gleichwertige Behandlung für weitergeleitete E-Mails bereitstellt. Beispiel:

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

Überprüfung

• Bestätigen Sie in Monitor > Overview, dass interne Server nicht mehr als nicht vertrauenswürdige externe Absender angezeigt werden.
• Überprüfen Sie in Nachrichtenverfolgungs-/Mail-Protokollen, ob die erwartete Absendergruppe angewendet wurde (z. B. eine interne Relays-Absendergruppe).

DNS

Symptome

• Auswahl oder Aufteilung von DNS-Resolvern: Die DNS-Konfiguration verursacht Zustellungsfehler, langsame SMTP-Transaktionen oder fehlgeschlagene reputationsbasierte DNS-Prüfungen.

Umwelt

• Gilt für Bereitstellungen, die eine öffentliche DNS-Auflösung, eine interne DNS-Auflösung oder Split-HorizonDNS für interne Domänen und Services erfordern.

Symptome

• Die Nachrichtenverfolgung zeigt DNS-Suchfehler/Timeouts für MX-, AAA-, PTRR- oder reputationsbezogene Abfragen an.
• Die Zustellung von E-Mails verzögert sich aufgrund wiederholter DNS-Versuche.

Ursache

• Die ESA ist für die Verwendung von Resolvern konfiguriert, die erforderliche öffentliche Datensätze, erforderliche interne Datensätze oder beides nicht auflösen können.
• Split-horizonDNS, das je nach Quellnetzwerk unterschiedliche Antworten für dieselbe Domäne zurückgibt, ist für interne Domänen oder Dienste erforderlich, jedoch nicht implementiert.

Auflösung

Konfigurieren Sie die DNS-Auflösung (Domain Name System) basierend auf dem Ort, an dem die ESA Datensätze auflöst: das öffentliche Internet, interne Domänen oder beides:

1. Verwenden Sie öffentliche rekursive Resolver, wenn die ESA primär öffentliche DNS-Einträge benötigt und die Richtlinie dies zulässt.

2. Verwenden Sie InternalDNS oder Split-Horizon DNS, wenn die ESA nur interne Zonen, interne Mail Exchange (MXX)-Datensätze, Lightweight Directory Access Protocol (LDAPP)-Datensätze oder andere private Dienste auflösen muss.

3. Öffentliches DNS ist angemessen, wenn die Appliance hauptsächlich Internet-Mail-Datensätze auflöst und keine internen Zonen oder Richtlinieneinschränkungen gelten.

Bei Bedarf InternalDNS oder splitDNS verwenden

• Nur interne Domänen
• InterneMXX-Datensätze
• Split-horizonDNS (unterschiedliche Antworten für dieselbe Domain, abhängig vom Quellnetzwerk)
• Compliance- oder Sicherheitsrichtlinien erfordern interne rekursive Resolver.
• PrivateDNS-Zonen für Routing erforderlich
• PrivateDNS-Zonen für Lightweight Directory Access Protocol (LDAPP) erforderlich
• PrivateDNS-Zonen für interne Dienste der ESA erforderlich

Überprüfung

• Vergewissern Sie sich, dass die ESA die erforderlichen öffentlichen und internen Hostnamen (sofern zutreffend) auflösen kann und dass die Nachrichtenverfolgung durch DNS-basierte Überprüfungen für die Zustellung und Reputation von E-Mails erfolgreich ist.

Nachrichten- und Inhaltsfilter

Der häufigste Fehler besteht darin, passende Bedingungen in Filtern hinzuzufügen, wenn sie nicht erforderlich sind.

• Leere Bedingungen: Lassen Sie die Bedingung leer, wenn der Filter für jede Nachricht in einer bestimmten Mail-Policy ausgeführt werden muss.
• Bewertungsverhalten: In asyncOS-Nachrichtenfiltern wird eine leere Bedingung zu true ausgewertet, sodass der Filter für jede Nachricht ausgeführt wird, die ihn erreicht.
• Geltungsbereich: Sie können den Bereich steuern, indem Sie den Filter an die entsprechende Mail-Policy für \"Eingehend\" oder \"Ausgehend\" anhängen.
• Order: Nachrichtenfilter werten Nachrichtenattribute und Aktionen nacheinander aus. Content-Filter werden in der Regel von der Mail-Richtlinie, die sie aufruft, in den Gültigkeitsbereich einbezogen.

Beispiele:

• Die Verwendung der rcpt-to-Bedingung in einem Nachrichtenfilter ist normalerweise nicht erforderlich, wenn das Ziel darin besteht, einen bestimmten Benutzer oder eine Gruppe anzuvisieren. Bevorzugen Sie eine empfängerbasierte Richtlinie für eingehende E-Mails, und wenden Sie den Content-Filter auf diese Richtlinie an, wenn die Anforderung Empfänger oder Empfängergruppen eindeutig zugeordnet ist. Reservieren Sie die Bedingungen für die Bestätigung für Ausnahmen, bei denen die Anforderung nicht durch die Richtlinienzuordnung ausgedrückt werden kann.
• Das Testen, ob eine Anlage vorhanden ist, bevor sie gelöscht wird, ist normalerweise redundant, wenn ein bestimmter Anlagentyp blockiert werden soll. Konfigurieren Sie den Filter, um den gewünschten Anlagetyp direkt zu löschen. Verwenden Sie einen Anhangsannahmetest nur, wenn je nach Anlage unterschiedliche Aktionen erforderlich sind.
• Verwenden Sie deliver() nur, wenn die Nachricht die verbleibenden Filter umgehen muss. Die Aktion deliver() beendet die weitere Filterverarbeitung und sendet die Nachricht. Um E-Mails zu versenden, ohne die verbleibenden Filter zu überspringen, konfigurieren Sie keine explizite deliver()-Aktion (implizite Zustellung gilt).

Schutz vor offenen Relays

Symptome/Auswirkungen

• Relay-Tests von Drittanbietern zeigen an, dass die Appliance falsch formatierte oder gefährliche Empfängeradressen akzeptiert.
• Publicblocklists listen die sendenden IP-Adressen auf, da das Parsen von SMTP-Adressen allgemein verwendete Muster zum Validieren geöffneter Relays zulässt.

Ursache

• Simple Mail Transfer Protocol SMTP-Adressenanalyse und Zeichenbehandlung ermöglichen ungültige Adressformate (z. B. double @sign) oder Adressliterale, bei denen es sich um IP-Adressen handelt, die direkt in die Adresse geschrieben werden, anstatt um einen Domänennamen.

Auflösung

Einige Dienste testen, ob der Message Transfer Agent (MTA) falsch formatierte Adressen akzeptiert, die auf eine offene Relay-Bedingung hinweisen können. Konfigurieren Sie ein striktes Parsing- und Ablehnungsverhalten, sodass die ESA diese Adressen während der SMTP-Konversation ablehnt.

• Fügen Sie vor ALLOWLIST eine dedizierte HAT-Absendergruppe für Relay-Test-Quellen für die Berichterstellung hinzu. Konfigurieren Sie ggf. keine Ratenbeschränkung und kein DHAP (Directory Harvest Attack Prevention), und aktivieren Sie bei Bedarf Anti-Spam und Anti-Virus.
• Aktivieren Sie Strict Address Parsing (Standardeinstellung ist Loose), um doppelte @Vorzeichen in Adressen zu verhindern.
• Ablehnen (nicht entfernen) ungültiger Zeichen, um zu verhindern, dass falsch formatierte Adressen akzeptiert werden.
• Ablehnen (nicht akzeptieren) von Adresswörtern und geben Sie die folgenden Zeichen ein: *%!\\/?

Überprüfung

• Führen Sie einen externen Relay-Test aus, und bestätigen Sie, dass die ESA falsch formatierte Empfängeradressen während der SMTP-Konversation zurückweist.
• Verwenden Sie die Nachrichtenverfolgung, um zu bestätigen, dass die Absendergruppe für den Relay-Test zugeordnet ist und dass E-Mails mit den beabsichtigten Scaneinstellungen verarbeitet werden.

Zugehörige Informationen

• Hier erhalten Sie technischen Support und Dokumente.
• ReviewAsyncOSS fürESA-Benutzerhandbücher
• Email Security Appliance (ESA) Installations- und Konfigurationsanleitungen (HAT, Mail-Richtlinien und Nachrichtenfilter)

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
3.0	01-Sep-2026	Rezertifizierung.
1.0	13-Oct-2014	Erstveröffentlichung