Problemen oplossen met veelvoorkomende fouten in e-mailbeveiliging

Inleiding

Dit document beschrijft veelvoorkomende configuratiefouten op het Cisco Email Security Appliance (ESA).

milieu

• Product: Cisco Email Security Appliance (ESA)
• Software: AsyncOS voor ESA (versie verschilt per implementatie)
• Toepassingsgebied: pas deze richtlijnen toe op het beleid voor inkomende en uitgaande e-mail, indien van toepassing; bekijk elke sectie voordat u wijzigingen aanbrengt.

Voorwaarden

• Administratieve toegang tot de ETA (GUI of CLI)
• Mogelijkheid om e-maillogs en het volgen van berichten voor validatie te controleren
• Reputatieservices SenderBase Reputatiescore SBRS ingeschakeld bij gebruik van op SBRS gebaseerde afzendergroepen
• Bewustzijn dat de Host Access Table (HAT) verbindingshosts classificeert vóór de evaluatie van het e-mailbeleid, wat van invloed is op hoe latere besturingselementen van toepassing zijn

Algemene verificatie

• Gebruik Monitor > Overzicht en het bijhouden van berichten om de verwachte indeling van de afzendergroep, beleidsovereenkomsten en leveringsresultaten na wijzigingen te bevestigen. Succes betekent dat de verwachte afzendergroep, het beleid en het leveringsresultaat na de wijziging verschijnen.
• Monitor quarantaines en false positives gedurende 7-144 dagen na het aanscherpen van reputatie- of filterinstellingen en pas indien nodig aan voor bekende zakelijke partners.

Veel voorkomende configuratiefouten op het e-mailbeveiligingsapparaat (ESA)

Gebruik deze controles om veelvoorkomende configuratiefouten op het e-mailbeveiligingsapparaat (ESA) te identificeren en te corrigeren. Elke subsectie maakt gebruik van een consistent probleem, oorzaak, oplossing en verificatiepatroon, zodat het probleem snel kan worden gediagnosticeerd en gecorrigeerd.

Host Access Table (HAT)

Symptomen

• Spam wordt geaccepteerd vanwege overdreven toegeeflijke reputatiegebaseerde afzendergroepen.
• Legitieme e-mail wordt afgeknepen of geblokkeerd vanwege te strenge verbindingscontroles.

Oorzaak

• Afzendergroepen worden geconfigureerd met onjuiste SBRS-reeksen (SenderBase Reputation Score) of DNS-verificatieinstellingen.

resolutie

1. Voeg geen positieve SBRS-waarden (bijvoorbeeld +5 of +7) toe aan de lijst Toestaan. Gebruik voor op SBRS gebaseerde allow-lijsten alleen scores van 9.0 tot 10.0 en valideer met het volgen van berichten.
2. Configureer de lijst met onbekende afzenders en de DNS-verificatiefuncties alleen wanneer dat nodig is. Schakel indien niet vereist UNKNOWNLIST, Envelope SenderDNS Verification en Connecting HostDNS Verification uit.

3. Om inconsistente instellingen per beleid te voorkomen, configureert u algemene standaardinstellingen: kies Mail Policies > Mail Flow Policies > Default Policy Parameters en stel de berichtgrootte en andere standaardparameters daar in.
4. Stel een redelijke standaard maximale verbindingswaarde in voor de meeste afzenders (bijvoorbeeld 3) en pas deze toe als de standaard voor nieuw beleid voor e-mailstromen; pas deze aan voor bekende afzenders met een hoog volume indien nodig.
5. Configureer het SBRS-bereik van de bloklijst op basis van uw risicotolerantie. In veel implementaties kan het blokkeren van SBRS -10.0 tot -2.0 resulteren in lage vals-positieve percentages. Valideren met het volgen van berichten en aanpassen voor zakelijke partners.

Beleid

Symptoom/impact

• E-mail wordt onverwacht gescand of in quarantaine geplaatst omdat het niet-standaard e-mailbeleid de algemene standaardinstellingen overschrijft.
• Uitgaande e-mail activeert onnodige antispam-/uitbraakfilteracties, waardoor de verwerkingstijd en false positives toenemen.
• Berichten worden leeg weergegeven omdat geïnfecteerde bijlagen zijn gestript en de berichttekst alleen de verwijderde inhoud bevat.

Oorzaak

• Niet-standaardbeleid dupliceert of overschrijft standaard instellingen voor antispam, antivirus, inhoudfilter of uitbraakfilter zonder een specifieke vereiste.
• Uitgaand beleid is van toepassing op inbound-gerichte scanfuncties.

resolutie

1. Geef het e-mailbeleid een naam voor de ontvangers waarop ze van toepassing zijn (bijvoorbeeld Inbound_Executives) en geef inhoudsfilters een naam voor de actie die ze ondernemen (bijvoorbeeld Q_basic_attachments en Dispovers).
2. Selecteer Standaardinstellingen gebruiken voor antispam-, antivirus-, inhoudfilters en uitbraakfilters, tenzij een gedocumenteerde uitzondering is vereist voor niet-standaardbeleid.
3. Schakel het selectievakje voor Drop geïnfecteerde bijlagen om te voorkomen dat het leveren van berichten met gestripte inhoud die leeg kan verschijnen.
4. Voor uitgaande antivirusacties moet u de afzender in plaats van de ontvanger op de hoogte stellen.
5. Schakel uitbraakfilters en antispam uit bij uitgaand e-mailbeleid, tenzij er een expliciete uitgaande use case bestaat.

Verifiëren

• Gebruik Berichttracking om te bevestigen dat het beoogde e-mailbeleid is afgestemd en dat de standaardinstellingen voor scannen worden overgenomen waar verwacht.
• Stuur een gecontroleerd uitgaand testbericht en bevestig dat antispam-/uitbraakfilters niet worden toegepast, tenzij deze bij uitzondering zijn geconfigureerd.

Inkomende relais

Symptomen

• Interne mailservers worden behandeld als externe afzenders, wat onverwachte afknijpen, filteren of op reputatie gebaseerde acties kan veroorzaken.

Oorzaak

• Interne mailserver IP-adressen of netwerken zijn niet geconfigureerd als inkomende relais of de functie Inkomende relais is uitgeschakeld.
• De interne relaishosts worden niet geclassificeerd in een speciale HAT-afzendergroep, wat kan resulteren in onbedoelde verbindingslimieten of Directory Harvest Attack Prevention (DHAP) -gedrag.

resolutie

1. Kies in de GUI Mail Policies > Incoming Relays en voeg uw interne IP-adressen of netwerken van de mailserver toe.
2. Zorg ervoor dat de functie Incoming Relay is ingeschakeld (voeg niet alleen items toe aan de tabel).
3. Maak een speciale afzendergroep voor Host Access Table (HAT) voor interne relais die in de lijst Toestaan in de vorige lijst worden vermeld voor rapportagedoeleinden. Configureer indien nodig geen snelheidsbeperking en geen Directory Harvest Attack Prevention (DHAP), terwijl het scannen van antispam en antivirussen ingeschakeld blijft zoals vereist. DHAP beperkt ongeldige pogingen tot het opsommen van ontvangers tijdens het gesprek met Simple Mail Transfer Protocol (SMTP).
4. Als u e-mail laat vallen op basis van de reputatie voor niet-gerelateerd verkeer, voegt u een berichtenfilter toe dat waar nodig gelijkwaardige verwerking toepast op e-mail. Voorbeeld:

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

Verifiëren

• In Monitor > Overzicht bevestigt u dat interne servers niet langer worden weergegeven als niet-vertrouwde externe afzenders.
• Bevestig in de logboeken voor het volgen van berichten/e-mails dat de verwachte afzendergroep is toegepast (bijvoorbeeld een interne afzendergroep van een relais).

DNS

Symptomen

• DNS-oplosserselectie of -splitsing: DNS-configuratie veroorzaakt leveringsfouten, slowSMTP-transacties of mislukte reputatiecontroles op basis van DNS.

milieu

• Is van toepassing op implementaties waarvoor een openbare DNS-resolutie, een interne DNS-resolutie of een gesplitste horizon DNS voor interne domeinen en services vereist zijn.

Symptomen

• Berichttracking toont DNSlookup-storingen / time-outs voor MX-, AAA-, PTRR- of reputatiegerelateerde query's.
• Levering van e-mail is vertraagd als gevolg van herhaalde DNS-herhalingen.

Oorzaak

• ESA is geconfigureerd om resolvers te gebruiken die de vereiste openbare records, vereiste interne records of beide niet kunnen oplossen.
• Split-horizonDNS, dat verschillende antwoorden voor hetzelfde domein retourneert op basis van het bronnetwerk, is vereist maar niet geïmplementeerd voor interne domeinen of services.

resolutie

Configureer de DNS-resolutie (Domain Name System) op basis van de plaats waar de ESA records oplost: het openbare internet, alleen interne domeinen of beide:

1. Gebruik openbare recursieve resolvers wanneer de ESA in de eerste plaats openbare DNS-records nodig heeft en het beleid dit toestaat.

2. Gebruik interne DNS of split-horizon DNS wanneer de ESA alleen interne zones, interne mailuitwisseling (MXX) records, Lightweight Directory Access Protocol (LDAPP) records of andere private services moet oplossen.

3. Publieke DNS is geschikt wanneer het toestel hoofdzakelijk internetmailrecords oplost en er geen interne zones of beleidsbeperkingen van toepassing zijn.

Gebruik InternalDNS of splitDNS wanneer dat vereist is

• Alleen-interne domeinen
• Interne MXX-records
• Split-horizonDNS (verschillende antwoorden voor hetzelfde domein op basis van het bronnetwerk)
• Nalevings- of beveiligingsbeleid vereist interne recursieve resolvers
• PrivateDNS-zones vereist voor routering
• PrivateDNS-zones vereist voor Lightweight Directory Access Protocol (LDAPP)
• PrivateDNS-zones vereist voor interne diensten die door de ESA worden gebruikt

Verifiëren

• Bevestig dat de ESA de vereiste openbare en interne hostnames kan oplossen (indien van toepassing) en dat de postbezorging en reputatiecontroles op basis van DNS slagen in het volgen van berichten.

Bericht- en inhoudfilters

De meest voorkomende fout is het toevoegen van overeenkomende voorwaarden in filters wanneer deze niet vereist zijn.

• Lege voorwaarden: Laat de voorwaarde leeg wanneer het filter moet worden uitgevoerd voor elk bericht in een bepaald e-mailbeleid.
• Evaluatiegedrag: In asyncOS-berichtfilters evalueert een lege voorwaarde tot true, zodat het filter wordt uitgevoerd op elk bericht dat het bereikt.
• Bereik: Beheerbereik door het filter aan het juiste Beleid voor inkomende of uitgaande e-mail te koppelen.
• Volgorde: Berichtenfilters evalueren berichtkenmerken en acties in volgorde. Inhoudsfilters worden meestal bestreken door het e-mailbeleid dat ze aanroept.

Voorbeelden:

• Het gebruik van de rcpt-to-voorwaarde in een berichtenfilter is meestal niet nodig wanneer het doel is om een specifieke gebruiker of groep te targeten. Geef de voorkeur aan een op ontvangers gebaseerd beleid voor inkomende e-mail en pas het inhoudsfilter toe op dat beleid wanneer de vereiste duidelijk wordt toegewezen aan ontvangers of ontvangersgroepen. Reserveer RCPT-to-voorwaarden voor uitzonderingen waarbij policy matching de vereiste niet kan uitdrukken.
• Testen op de aanwezigheid van een bijlage voordat deze wordt verwijderd, is meestal overbodig wanneer het de bedoeling is om een specifiek type bijlage te blokkeren. Configureer het filter om het doeltype van de bijlage direct te laten vallen; gebruik een test voor de aanwezigheid van de bijlage alleen wanneer verschillende acties vereist zijn, afhankelijk van het feit of een bijlage bestaat.
• Gebruik deliver() alleen wanneer het bericht de resterende filters moet omzeilen. De actie deliver() stopt de verdere filterverwerking en levert vervolgens het bericht af; om e-mail te leveren zonder resterende filters over te slaan, configureert u geen expliciete deliver() actie (impliciete levering is van toepassing).

Open-relaispreventie

Symptoom/impact

• Relay-tests van derden melden dat het apparaat onjuiste of gevaarlijke adressen van ontvangers accepteert.
• Publicatieblokkeerlijsten vermelden de verzendende IPP omdat SMTP-adresparsen patronen mogelijk maken die vaak worden gebruikt om open relais te valideren.

Oorzaak

• Simple Mail Transfer Protocol SMTP-adresparsen en tekenverwerking maken het mogelijk om ongeldige adresformaten (bijvoorbeeld dubbele @tekens) of adresletterlijke tekens te gebruiken, dit zijn IP-adressen die rechtstreeks in het adres zijn geschreven in plaats van een domeinnaam.

resolutie

Sommige services testen of de Message Transfer Agent (MTA) misvormde adressen accepteert die kunnen wijzen op een open relay-conditie. Configureer strikt parsen en afwijzingsgedrag zodat de ESA deze adressen tijdens het SMTP-gesprek afwijst.

• Voeg een speciale HAT-afzendergroep toe voor relaistestbronnen voorafgaand aan ALLOWLIST voor rapportage. Configureer geen snelheidsbeperking en geen Directory Harvest Attack Prevention (DHAP) indien van toepassing, terwijl u desgewenst antispam en antivirus ingeschakeld houdt.
• Schakel Strict Address Parsing in (Loose is de standaard) om dubbele @aanmeldingen in adressen te voorkomen.
• Ongeldige tekens weigeren (niet strippen) om te voorkomen dat onjuiste adressen worden geaccepteerd.
• Adresletterlijke tekens afwijzen (niet accepteren) en deze tekens invoeren: *%!\\/?

Verifiëren

• Voer een externe relaistest uit en bevestig dat de ESA tijdens het SMTP-gesprek misvormde adressen van ontvangers afwijst.
• Gebruik het volgen van berichten om te bevestigen dat de afzendergroep van de relaistest is gekoppeld en dat e-mail wordt verwerkt met de beoogde scaninstellingen.

Gerelateerde informatie

• Ontvang technische ondersteuning en documentatie
• AsyncOSS voor ESA-gebruikershandleidingen controleren
• Installatie- en configuratiehandleidingen voor e-mailbeveiligingsapparaten (ESA) (HAT, e-mailbeleid en berichtfilters)

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
3.0	01-Sep-2026	Hercertificering.
1.0	13-Oct-2014	Eerste vrijgave