Barracuda Email Gateway Defense: Architektur, DNS-Konfiguration und Alternativen

⚡TL;DR

• 🛡️ Barracuda Email Gateway Defense (EGD) ist das Cloud-SEG, das historisch auf KMU und MSP ausgerichtet ist, mit über 200 000 Kunden weltweit. Es schaltet sich per MX-Umleitung vor Microsoft 365, Google Workspace oder Exchange und filtert 100 % des eingehenden Verkehrs.
• 🔧 Spezifische DNS-Auswirkungen: MX im Format <kunden-id>.ess.barracudanetworks.com (Priorität 99 für die Testphase, dann Umschaltung), regionaler SPF-Include (spf.ess.barracudanetworks.com in den USA, Varianten DE/UK/CA/AU/IN), in der Konsole signiertes DKIM und DMARC, das schrittweise auf p=reject zu steuern ist.
• ⚠️ Entscheidende Produktunterscheidung: Die CVE-2023-2868 (CVSS 9,8, von UNC4841 ausgenutzt) betraf die Legacy-ESG-Appliance, nicht den Cloud-Dienst EGD. Verwechseln Sie die beiden Produktlinien nicht: Barracuda empfiehlt die Migration von ESG zu EGD.
• 📊 Positionierung: Visionär im Gartner Magic Quadrant Email Security im 2. Jahr in Folge (1. Dezember 2025), zu unterscheiden von den im Quadranten 2025 als Leader positionierten Anbietern. 2022 von KKR übernommen (rund 4 Mrd. $) nach Thoma Bravo. Zielgruppe: KMU, Mittelstand und Multi-Tenant-MSP.

Wenn Sie ein KMU, eine Kommune, eine Kanzlei oder ein MSP sind, das mehrere Dutzend Kunden betreut, ist die Wahrscheinlichkeit hoch, dass Ihnen Barracuda bereits begegnet ist. Der kalifornische Anbieter beansprucht über 200 000 Kunden und hat sich als einer der am weitesten verbreiteten E-Mail-Sicherheitsanbieter außerhalb des Großkundensegments etabliert. Während Proofpoint die Fortune 100 dominiert und Mimecast die Mittelständler mit vielfältigen Anforderungen anspricht, verfolgt Barracuda einen anderen Ansatz: einfach bereitzustellende Cloud, ein solides MSP-Programm und eine Preisstruktur, die für Organisationen ohne dediziertes SOC-Team gedacht ist.

Doch der Name "Barracuda" steht in Wirklichkeit für zwei sehr unterschiedliche Produkte, die ständig verwechselt werden. Auf der einen Seite Email Gateway Defense (EGD), das Cloud-SEG, um das es in diesem Artikel geht, gehostet unter *.ess.barracudanetworks.com. Auf der anderen Seite Email Security Gateway (ESG), die physische oder virtuelle Legacy-Appliance, die 2023 mit einer kritischen, von einem staatlichen Akteur ausgenutzten Schwachstelle für Schlagzeilen sorgte. Diese Verwechslung ist nicht harmlos: Sie führt regelmäßig dazu, dass Entscheider Barracuda aufgrund eines Vorfalls ausschließen, der gar nicht das Cloud-Produkt betraf, das sie in Erwägung zogen.

Das Problem ist alles andere als theoretisch. Der 2025 Email Threats Report von Barracuda, der auf fast 670 Millionen analysierten E-Mails basiert, beziffert den Anteil bösartiger oder unerwünschter Nachrichten auf 24 %, stellt fest, dass sich in 68 % der präparierten PDFs und 83 % der verseuchten Office-Dokumente ein Phishing-QR-Code verbirgt, und konstatiert, dass 47 % der E-Mail-Domains noch immer kein DMARC konfiguriert haben. Den eingehenden Verkehr zu filtern bringt nichts, wenn Ihre Domain mangels Authentifizierung weiterhin gefälscht werden kann: Prüfen Sie zuerst Ihren Stand mit dem CaptainDNS DMARC-Syntax-Checker.

Bei CaptainDNS analysieren wir Barracuda aus dem Blickwinkel, der uns beschäftigt: die Auswirkungen auf Ihre DNS-Einträge und Ihre E-Mail-Authentifizierung. EGD bereitzustellen bedeutet nicht, ein Sicherheitshäkchen zu setzen. Es bedeutet, Ihre MX zu ess.barracudanetworks.com umzuleiten, Ihr SPF mit dem richtigen regionalen Include anzupassen, Ihren DKIM-Schlüssel zu veröffentlichen und Ihr DMARC zu steuern. Dieser Leitfaden deckt alles ab: Architektur, detaillierte DNS-Konfiguration mit den realen Werten, Methode zur Erkennung einer Domain hinter Barracuda, Unterscheidung EGD/ESG, sachliche Behandlung der CVE-2023-2868, Vergleich und Aktionsplan.

📌 Was ist das Cloud-E-Mail-Gateway von Barracuda?

Barracuda Email Gateway Defense ist ein Cloud Secure Email Gateway, das 100 % des eingehenden E-Mail-Verkehrs filtert, bevor er Ihren Mailserver erreicht. Sie leiten Ihre MX-Einträge zur Barracuda-Infrastruktur um, die jede Nachricht prüft und dann nur den sauberen Verkehr an Microsoft 365, Google Workspace oder Exchange weiterleitet.

Für die Grundlagen eines SEG (Gateway-Modell, MX-Umleitung, Unterschied zu API-nativen ICES-Lösungen) verweisen wir auf unseren vollständigen Artikel zu Mimecast, der diese Grundlagen im Detail behandelt. Was Sie wissen müssen: Ein SEG schaltet sich zwischen das Internet und Ihre Messaging-Infrastruktur, sieht den gesamten eingehenden Verkehr und blockiert Bedrohungen vor der Zustellung statt nachträglich.

Wo Barracuda Wachsamkeit erfordert, ist bei der Produktnomenklatur. Drei Namen tauchen in der Dokumentation ständig auf, und sie zu verwechseln führt zu kostspieligen Konfigurationsfehlern.

Email Gateway Defense (EGD) ist der Cloud-SEG-Dienst, früher unter den Namen Barracuda Email Security Service (BESS) oder "Email Security Essentials" vermarktet. Das ist das Thema dieses Artikels. Alles wird bei Barracuda unter der Domain ess.barracudanetworks.com gehostet. Keine Appliance zu verwalten, kein Patch auf Kundenseite anzuwenden. Der Dienst läuft in regionalen, von Barracuda betriebenen Rechenzentren.

Email Security Gateway (ESG) ist eine ganz andere Produktlinie: eine physische Appliance (rackbare Hardware) oder virtuelle Appliance, die on-premise oder in der Cloud des Kunden bereitgestellt wird und die die Organisation selbst administriert. Es ist ein Legacy-Produkt am Ende seines kommerziellen Zyklus, und es ist diese Produktlinie, die von der CVE-2023-2868 betroffen war. Barracuda treibt die Migration von ESG-Kunden zu EGD über sein Programm "ESG Elevate" aktiv voran.

Barracuda Email Protection ist die übergreifende Suite. Sie gliedert sich in drei Pläne: Advanced, Premium und Premium Plus. EGD bildet den Basisbaustein. Die höheren Pläne fügen Module wie den Schutz vor Domain-Betrug (Advanced DMARC), Impersonation Protection, Nutzersensibilisierung (Security Awareness Training), Zero Trust Access und Cloud-to-Cloud Backup hinzu.

🏢 Barracuda: das Unternehmen im Überblick

Barracuda Networks wurde 2003 in Kalifornien gegründet und 2022 von KKR zu rund 4 Milliarden Dollar übernommen. Aus einem Anti-Spam-Appliance-Hersteller der 2000er-Jahre wurde so ein Cloud-Akteur mit über 200 000 Kunden: Der Weg umfasst zwanzig Jahre Pivots und zwei Übernahmen durch Private-Equity-Fonds.

Barracuda Networks wurde 2003 in Campbell, Kalifornien, gegründet. Das Unternehmen machte sich zunächst durch seine Spam Firewall einen Namen, eine Hardware-Appliance, die die Anti-Spam-Filterung für KMU zu einer Zeit demokratisierte, als konkurrierende Lösungen teuer und komplex waren. Dieses Modell "einfache Appliance, erschwinglicher Preis" prägte die DNA des Anbieters ein Jahrzehnt lang: einfach bereitzustellende Hardware für Organisationen ohne großes IT-Team.

Die Cloud-Wende kam in den 2010er-Jahren schrittweise mit der Einführung des Barracuda Email Security Service, dem direkten Vorläufer des heutigen Email Gateway Defense. Statt eine Box zu verkaufen, die ins Rack gesteckt wird, hostet Barracuda die Filterung in seinen eigenen Rechenzentren. Der Kunde leitet einfach seine MX um. Dieser Pivot begleitet den allgemeinen Marktwechsel hin zu Microsoft 365 und Google Workspace, wo die On-Premise-Appliance keinen Sinn mehr ergibt.

Kapitalseitig hat Barracuda zwei große Transaktionen erlebt. Thoma Bravo übernahm das Unternehmen 2017 für rund 1,6 Milliarden Dollar und nahm es von der Börse. Dann erwarb 2022 KKR Barracuda von Thoma Bravo zu einer Bewertung von etwa 4 Milliarden Dollar, also mehr als das Doppelte in fünf Jahren. Dieser Übergang zu KKR begleitete die Neupositionierung von Barracuda als Cybersicherheitsplattform mit Ausrichtung auf Mittelstand und MSP, über die reine E-Mail hinaus.

Heute beansprucht Barracuda über 200 000 Kunden weltweit, mit starker Konzentration auf KMU, Mittelständler und ein besonders ausgeprägtes MSP-Ökosystem. Das MSP-Partnerprogramm ermöglicht es einem Dienstleister, die E-Mail-Sicherheit von Dutzenden Kunden über eine Multi-Tenant-Konsole zu verwalten, mit Massen-Remediation und nutzungsbasierter Abrechnung. Das ist eines der differenzierendsten Argumente von Barracuda gegenüber Wettbewerbern, die historisch für den einzelnen Endkunden gedacht waren.

Analystenseitig wird Barracuda im 2. Jahr in Folge als Visionär im Gartner Magic Quadrant Email Security eingestuft (Ausgabe vom 1. Dezember 2025). Die Nuance zählt: Ein Visionär hat eine anerkannte Produktvision, aber eine Ausführungsfähigkeit, die unter den als Leader im selben Quadranten positionierten Akteuren (insbesondere Proofpoint, Mimecast und Microsoft) eingestuft wird. Barracuda spielt also nicht in der Liga von Proofpoint bei der erstklassigen Threat Intelligence. Bei den Kundenbewertungen erreicht es dennoch 4,6/5 bei 439 Bewertungen auf Gartner Peer Insights für den Markt Email Security Platforms. Beim Verhältnis Einfachheit/Preis/Abdeckung hält es eine solide Position für das anvisierte Segment.

⚙️ Technische Architektur: wie Barracuda Ihre E-Mails filtert

Bevor jede Nachricht Ihren Server erreicht, durchläuft sie eine Vorfilterungskette, die in den regionalen Rechenzentren von Barracuda gehostet wird. Hinzu kommen Module für erweiterte Analyse und, in den höheren Plänen, eine Schicht zur verhaltensbasierten Erkennung per API. Wir gehen das Ganze durch.

Gateway-Modell: die MX-Umleitung zu ess.barracudanetworks.com

Wie jedes traditionelle SEG basiert EGD auf der MX-Umleitung. Ihre MX-Einträge zeigen auf die Barracuda Cloud-Infrastruktur, gehostet unter ess.barracudanetworks.com. Wenn ein Absender eine E-Mail an contact@captaindns.com schickt, löst sein Server den MX auf, findet einen Barracuda-Host und stellt die Nachricht dort zu. Barracuda wendet seine Erkennungskette an und leitet die validierte Nachricht dann an Ihren echten Server weiter.

Der Fluss läuft in fünf Schritten ab:

1. Ein Absender schickt eine E-Mail an contact@captaindns.com
2. Sein Server führt eine DNS-MX-Anfrage für captaindns.com durch
3. Das DNS gibt den Barracuda-MX zurück (zum Beispiel d9307303a.ess.barracudanetworks.com)
4. Die Nachricht kommt bei Barracuda an, das sie seiner Inspektionskette unterwirft (Reputation, Anti-Spam, Anti-Malware, ATP, Anti-Phishing)
5. Wird die Nachricht freigegeben, leitet Barracuda sie an Ihren echten Mailserver weiter (Microsoft 365, Google Workspace, Exchange on-premise)

Der Vorteil ist direkt: Barracuda sieht 100 % des eingehenden Verkehrs und blockiert Bedrohungen, bevor sie Ihre Infrastruktur berühren. Ihr Server erhält nur bereits gefilterten Verkehr.

Die Cloud-Vorfilterung: Reputation, Anti-Spam, Anti-Malware

Die erste Verteidigungslinie von Barracuda ist eine Vorfilterungsstufe, die das Hintergrundrauschen vor jeder kostspieligen Analyse eliminiert. Der Dienst bewertet die Reputation der Quell-IP zum Zeitpunkt der SMTP-Verbindung, gestützt auf die von Barracuda gepflegten Reputationsströme (der Anbieter betreibt im Übrigen seine eigene Barracuda Reputation Block List, eine historische Blacklist, die weit über die eigenen Produkte hinaus genutzt wird). Verbindungen von bekannten Botnets oder massiv gemeldeten IPs werden bereits beim Handshake abgelehnt, ohne den Inhalt überhaupt zu analysieren.

Es folgt die klassische Anti-Spam- und Anti-Malware-Analyse: Signaturen, Heuristiken, Multi-Engine-Antivirenscan. Diese Schicht verarbeitet das Volumen schnell und eliminiert bekannte Bedrohungen. Das ist wirksam gegen Massen-Spam und katalogisierte Malware, aber unzureichend gegen gezielte Bedrohungen und unbekannte Anhänge, daher die folgenden Stufen.

Die ATP-Sandbox gegen Zero-Day-Bedrohungen

Die Advanced Threat Protection (ATP) von Barracuda verarbeitet die Anhänge und Payloads, die Signaturen nicht erkennen. Verdächtige Dateien werden in eine Sandbox-Umgebung umgeleitet, wo sie ausgeführt und beobachtet werden: Versuche ausgehender Verbindungen, Modifikation von Systemdateien, Verschlüsselungsverhalten, Code-Injektion. Das ist die Antwort auf Zero-Day-Bedrohungen, für die noch keine Signatur existiert.

ATP kombiniert statische Analyse (Inspektion der Dateistruktur, der Makros, der eingebetteten Skripte) und dynamische Analyse (Detonation in der Sandbox). Das Verdikt speist anschließend die Blockierungsentscheidungen. In den höheren Plänen löst es zudem automatisierte Remediation-Aktionen aus.

Der Anti-Spoofing-Schutz durch verhaltensbasierte KI

Der Schutz vor Identitätsmissbrauch ist eines der starken Argumente von Barracuda im KMU-Segment, das mangels interner Erkennungsmittel besonders Business-Email-Compromise-Angriffen (BEC) ausgesetzt ist. Das Modul Impersonation Protection (historisch aus dem Baustein "Sentinel" hervorgegangen) wendet eine verhaltensbasierte Analyse durch maschinelles Lernen an, um Betrug zu erkennen.

Die Engine lernt die normalen Kommunikationsmuster der Organisation: wer wem schreibt, von welchen Adressen, mit welchem Tonfall, zu welchen Zeiten. Sie meldet anschließend die für einen BEC-Angriff typischen Anomalien: eine angeblich von der Geschäftsleitung von einer externen Adresse gesendete E-Mail, eine ungewöhnliche Überweisungsanfrage, ein angezeigter Name, der einen Mitarbeiter imitiert, eine ähnlich aussehende Domain (Typosquatting). Das Problem ist, dass diese Angriffe oft weder Link noch Anhang enthalten. Keine Signatur greift bei ihnen. Die verhaltensbasierte Erkennung bleibt das einzige Mittel, um sie zu fassen.

Die API-Verteidigung und die Remediation nach der Zustellung

Über das Gateway hinaus fügen die höheren Pläne eine Schicht zur Postfach-Verteidigung per API auf Microsoft 365 hinzu. Dieser Ansatz ergänzt die Filterung vor der Zustellung durch eine Analyse bereits angekommener Nachrichten nach der Zustellung, nach Art der ICES-Lösungen. Sie nutzt den Zugriff auf die internen Metadaten des Tenants (Beziehungen zwischen Nutzern, Kommunikationshistorie), um die verhaltensbasierte Erkennung zu verfeinern.

Das Modul Incident Response schließt den Kreis: Wird eine Bedrohung nach der Zustellung identifiziert, kann der Administrator (oder das MSP) die Nachricht automatisch aus den betroffenen Postfächern entfernen, über alle betroffenen Nutzer hinweg. Für ein MSP, das Dutzende Tenants verwaltet, ist die Massen-Remediation ein entscheidender operativer Gewinn: eine Kampagne über den gesamten Bestand mit wenigen Klicks neutralisieren, statt Tenant für Tenant.

Regionale Rechenzentren und Multi-Tenant-Architektur für MSP

Barracuda betreibt EGD von mehreren geografischen Regionen aus, jede mit eigener Konsole und eigenem SPF-Include. Zwei Aspekte rechtfertigen diese Aufteilung: die Latenz (E-Mail möglichst nah an der Organisation verarbeiten) und der Datenstandort (ein europäischer Kunde will seine Daten in Europa verarbeitet wissen, DSGVO-Konformität verpflichtet). Die heute verfügbaren Regionen umfassen die USA, Deutschland (für Europa), Großbritannien, Kanada, Australien und Indien.

Die Architektur ist nativ multi-tenant, zugeschnitten auf das MSP-Modell. Ein Dienstleister verfügt über eine zentrale Konsole, von der aus er die E-Mail-Sicherheit aller seiner Kunden bereitstellt, konfiguriert und überwacht. Die Richtlinien werden von einem gemeinsamen Modell vererbt und dann pro Tenant verfeinert, und die Abrechnung folgt der Nutzung. Das ist einer der Gründe für die starke Präsenz von Barracuda bei MSP, einem Segment, in dem Enterprise-Lösungen im Multi-Kunden-Modus schwerfällig zu betreiben bleiben.

🔧 Die DNS-Konfiguration, Schritt für Schritt

EGD bereitzustellen ändert vier DNS-Einträge: MX, SPF, DKIM und DMARC. Ein Fehler bei einem davon, und Ihre E-Mails verschwinden oder umgehen die Filterung. Hier jeder Schritt mit den realen Werten und den zu vermeidenden Fallstricken.

Der MX-Eintrag im Format ess.barracudanetworks.com

Der MX-Eintrag von Barracuda EGD folgt dem Format <kunden-id>.ess.barracudanetworks.com. Die Kennung ist ein von Barracuda für Ihr Konto generierter eindeutiger Code, sichtbar auf der Domain-Verifizierungsseite der Konsole (Bereich Domains). Ein Konto kann zum Beispiel einen MX vom Typ d9307303a.ess.barracudanetworks.com erhalten.

Das ist ein bemerkenswerter Unterschied zu Mimecast oder Proofpoint, deren MX einer generischen regionalen Nomenklatur folgen (eu-smtp-inbound-1.mimecast.com, mx0a-XXXXXXXX.pphosted.com). Bei Barracuda ist der MX-Hostname kontospezifisch, was zugleich eine praktische Erkennungssignatur darstellt (siehe weiter unten).

Barracuda empfiehlt einen zweistufigen Umschaltansatz über die MX-Priorität. Während der Testphase fügen Sie den Barracuda-MX mit einer hohen Priorität (99) hinzu, also der am wenigsten vorrangigen. Ihre bestehenden MX behalten ihre niedrige Priorität und empfangen weiterhin die legitime Post. Damit können Sie validieren, dass das Barracuda-Konto den Verkehr Ihrer Domain korrekt annimmt, ohne Nachrichten zu riskieren. Sobald die Konfiguration validiert ist, kehren Sie um: Der Barracuda-MX geht auf niedrige Priorität (10) und Sie entfernen die alten MX.

# Aktuelle MX überprüfen
dig MX captaindns.com +short

Erwartetes Ergebnis nach abgeschlossener Umschaltung:

10 d9307303a.ess.barracudanetworks.com.

Klassischer Fallstrick. Lassen Sie keinen Rest-MX bestehen, der auf Ihren alten Server zeigt (Exchange on-premise oder direkt Ihr Tenant *.mail.protection.outlook.com). Ein Rest-MX ist eine Hintertür: Ein Angreifer, der Ihre Microsoft-365-Infrastruktur kennt, kann direkt an Ihre Postfächer zustellen und dabei Barracuda umgehen. Überprüfen Sie nach der Umschaltung mit dig MX, dass nur noch der Barracuda-MX vorhanden ist, und verriegeln Sie Ihren M365-Connector, sodass er nur die Barracuda-IPs annimmt.

Das SPF mit dem regionalen Include

Hier kommt die Geografie ins Spiel. Für die ausgehende über Barracuda relayte Post müssen Sie den SPF-Include hinzufügen, der Ihrer Region entspricht. Den Include einer anderen Region zu verwenden funktioniert nicht, da sich die Versand-IPs unterscheiden.

Region	SPF-Include	Regionale Konsole
USA (US)	include:spf.ess.barracudanetworks.com	us.ess.barracudanetworks.com
Deutschland / Europa (DE)	include:spf.ess.de.barracudanetworks.com	de.ess.barracudanetworks.com
Großbritannien (UK)	include:spf.ess.uk.barracudanetworks.com	uk.ess.barracudanetworks.com
Kanada (CA)	include:spf.ess.ca.barracudanetworks.com	ca.ess.barracudanetworks.com
Australien (AU)	include:spf.ess.au.barracudanetworks.com	au.ess.barracudanetworks.com
Indien (IN)	include:spf.ess.in.barracudanetworks.com	in.ess.barracudanetworks.com

Beispiel für einen SPF-Eintrag für einen US-Kunden, der auch über Google Workspace versendet:

v=spf1 include:spf.ess.barracudanetworks.com include:_spf.google.com -all

Barracuda empfiehlt den Mechanismus -all (Hardfail), strenger als ~all (Softfail). Mit einer DMARC-Richtlinie auf p=reject genügt ~all, da DMARC die Ablehnung diktiert, aber -all fügt einen Schutz auf SPF-Ebene selbst hinzu, was der vom Anbieter empfohlenen Standardkonfiguration entspricht. Überwachen Sie dennoch die Gesamtzahl der DNS-Lookups: Die SPF-Spezifikation (RFC 7208) schreibt ein Limit von 10 rekursiven Lookups vor. Kumulieren Sie Barracuda, Google Workspace und zwei oder drei ESP, und Sie nähern sich schnell der Obergrenze, mit einem PermError als Folge.

Überprüfen Sie Ihren Eintrag mit dem CaptainDNS SPF-Syntax-Checker, der die Lookups zählt und Überschreitungen meldet.

Die DKIM-Signatur

DKIM signiert Ihre ausgehenden E-Mails kryptografisch und erlaubt es dem Empfänger zu überprüfen, dass sie tatsächlich von Ihrer Domain stammen und nicht verändert wurden. Mit Barracuda EGD wird die Konfiguration in der Konsole gesteuert:

1. DKIM-Signatur aktivieren für Ihre Domain in der EGD-Konsole (Bereich Outbound / Sender Authentication), unter Wahl eines Selektors
2. Den öffentlichen Schlüssel abrufen, der von Barracuda generiert wurde, und ihn in Ihrem DNS als TXT-Eintrag am Ort selektor._domainkey.captaindns.com veröffentlichen
3. Die Signatur aktivieren, sobald der DNS-Eintrag propagiert und von der Konsole verifiziert wurde

Überprüfung der Veröffentlichung:

dig TXT barracuda._domainkey.captaindns.com +short

Das Ergebnis muss den öffentlichen Schlüssel im Format v=DKIM1; k=rsa; p=MIGfMA0GCS... enthalten. Denken Sie daran, eine Schlüssellänge von 2048 Bit statt 1024 zu wählen, für eine den aktuellen Best Practices entsprechende Sicherheit, und planen Sie eine Rotation alle sechs bis zwölf Monate ein.

Das DMARC-Alignment

DMARC überprüft, dass die im Feld From sichtbare Domain mit der durch SPF oder DKIM authentifizierten Domain aligniert ist, und legt die im Fehlerfall anzuwendende Richtlinie fest. Es ist das letzte Puzzlestück der Authentifizierung, und Barracuda stützt sich auf Ihre SPF/DKIM-Konfiguration, um das Alignment herzustellen.

Ein im Gateway-Modus oft übersehener Punkt: Das ausgehende Relay über Barracuda schreibt den SMTP-Envelope um, was die ursprüngliche SPF-Information auf Empfängerseite verloren gehen lässt. SPF präsentiert sich dann nicht mehr aligniert mit der Domain des From, und es ist DKIM, das zur Säule des DMARC-Alignments hinter Barracuda wird. Daher die Bedeutung, die DKIM-Signatur in der EGD-Konsole korrekt zu aktivieren, bevor Sie die Richtlinie verschärfen: ohne sie werden eigentlich legitime Nachrichten an DMARC scheitern.

Die empfohlene Progression ist dieselbe wie bei jedem Deployment:

1. p=none (Überwachung): Sie erhalten die aggregierten Berichte, ohne die Zustellung zu beeinträchtigen. Empfohlene Dauer: 2 bis 4 Wochen.
2. p=quarantine: Nicht authentifizierte Nachrichten landen im Spam. Dauer: 2 bis 4 Wochen.
3. p=reject: Nicht authentifizierte Nachrichten werden abgelehnt. Das ist die Zielrichtlinie.

Beispiel für einen DMARC-Starteintrag:

v=DMARC1; p=none; rua=mailto:dmarc@captaindns.com; ruf=mailto:dmarc-forensic@captaindns.com; fo=1;

In den höheren Plänen (Premium Plus) liefert Barracuda ein Modul Domain Fraud Protection, das die DMARC-Berichte aggregiert und visualisiert, die legitimen, noch nicht authentifizierten Versandquellen identifiziert und den Aufstieg zu p=reject begleitet. Wenn Sie bei EGD allein bleiben, steuern Sie DMARC mit einem Drittanbieter-Tool. Validieren Sie jede Änderung Ihres Eintrags mit dem CaptainDNS DMARC-Syntax-Checker.

🔍 Wie erkennt man, dass eine Domain durch Barracuda geschützt ist?

Um zu erfahren, ob eine Domain Barracuda Email Gateway Defense nutzt, untersuchen Sie ihre MX- und SPF-Einträge: Ein MX, der auf .ess.barracudanetworks.com endet, oder ein SPF, das include:spf.ess[.<region>].barracudanetworks.com enthält, ist die eindeutige Signatur des Cloud-Dienstes.

Diese Erkennung ist in mehreren Fällen nützlich: einen Interessenten vor einem Verkaufstermin auditieren, den Stack eines Partners qualifizieren oder einfach verstehen, worüber Ihre eigenen E-Mails laufen. Die Methode beruht auf zwei DNS-Signaturen.

MX-Signatur. Jeder MX-Eintrag, dessen Hostname auf .ess.barracudanetworks.com endet, weist auf eine Domain hinter Barracuda EGD hin. Das Präfix (d9307303a in unseren Beispielen) ist die eindeutige Kennung des Kundenkontos.

# Barracuda über den MX erkennen
dig MX captaindns.com +short
# Eine Antwort vom Typ "10 d9307303a.ess.barracudanetworks.com." = Barracuda EGD

SPF-Signatur. Das Vorhandensein eines include:spf.ess.barracudanetworks.com (oder seiner regionalen Variante spf.ess.de/uk/ca/au/in.barracudanetworks.com) im TXT-Eintrag der Domain bestätigt, dass Barracuda die ausgehende Post relayt.

# Barracuda über das SPF erkennen
dig TXT captaindns.com +short | grep spf
# Vorhandensein von "include:spf.ess.barracudanetworks.com" = Barracuda im Ausgang

Für eine vollständige und lesbare Analyse der Einträge einer Domain ohne dig zu bemühen, verwenden Sie das DNS-Lookup-Tool von CaptainDNS, das die MX, TXT und andere Einträge auf einen Blick anzeigt. MX und SPF zu kreuzen beseitigt jede Mehrdeutigkeit: Ein MX auf .ess.barracudanetworks.com kombiniert mit dem entsprechenden SPF-Include identifiziert fehlerfrei eine Domain, die vollständig durch Barracuda EGD geschützt ist, eingehend und ausgehend.

🔄 Vergleich mit Mimecast, Proofpoint und Microsoft

Barracuda zeichnet sich durch seine KMU- und MSP-Positionierung aus, während Proofpoint und Mimecast Großkunden und Mittelstand anvisieren. Die folgende Tabelle vergleicht die Kriterien, die bei einer Wahl wirklich ins Gewicht fallen.

Kriterium	Barracuda EGD	Mimecast	Proofpoint	Microsoft Defender
Typ	SEG Cloud + Inbox Defense API	SEG + API (2026)	SEG Enterprise + ICES	Nativ M365
Zielgruppe	KMU, Mittelstand, MSP	KMU/Mittelstand mit vielfältigem Bedarf	Fortune 100, große Mittelständler	M365-Umgebungen
KI/ML-Erkennung	Impersonation Protection, verhaltensbasiertes ML	Multi-Vector + CyberGraph	Nexus AI 6 Komponenten	9,1/10 unabhängige Tests
MSP-Multi-Tenant-Modell	Ja (Stärke)	Teilweise	Begrenzt	Über CSP-Partner
DMARC	Domain Fraud (Premium Plus)	DMARC Analyzer integriert	EFD mit Beratern	Nein
Archivierung	Über Cloud Archiving (Add-on)	Ja (1 Tag bis 99 Jahre)	Über Partner	Über M365-Aufbewahrung
MX-Format	<id>.ess.barracudanetworks.com	eu-smtp-inbound-1.mimecast.com	mx0a-XXXX.pphosted.com	*.mail.protection.outlook.com
Gartner 2025	Visionär	Leader	Leader (#1 Execution)	Leader
Ideal für	KMU und MSP mit Bedarf an Einfachheit/Preis	Sicherheit + Archivierung zentralisieren	Erstklassige Threat Intel	Full M365, knappes Budget

Mimecast und Proofpoint: die Mittelstands- und Enterprise-Referenz

Im Mittelstand bietet Mimecast eine breitere Suite bei den nativen Funktionen: integrierte Langzeit-Archivierung, E-Mail-Kontinuität, DMARC Analyzer ohne Zusatzkosten. Wenn Ihr Bedarf darin besteht, Sicherheit, Archivierung und Kontinuität in einer einzigen Konsole zu zentralisieren, bietet Mimecast oft ein besseres funktionales Verhältnis als Barracuda, zum Preis einer komplexeren Konsole. Unser vollständiger Leitfaden zu Mimecast beschreibt detailliert seine Architektur und seine DNS-Konfiguration.

Im Großkundensegment dominiert Proofpoint durch seine Threat Intelligence und seinen People-Centric-Ansatz (VAP-Konzept). Es ist die Referenz für reife SOCs der am stärksten ins Visier genommenen Branchen (Finanzen, Verteidigung, Gesundheit), aber zu einem Preis und einer Komplexität, die die Bedürfnisse eines KMU bei Weitem übersteigen. Siehe unseren vollständigen Leitfaden zu Proofpoint.

Microsoft Defender und Abnormal: das Native und das Verhaltensbasierte

Wenn Ihre Organisation vollständig Microsoft 365 ist, bleibt Defender for Office 365 die naheliegendste Wahl beim Preis-Abdeckungs-Verhältnis: nativer Schutz ohne MX-Änderung, oft weniger als 2 Euro pro Nutzer und Monat, teils sogar in der E5-Lizenz enthalten. Unabhängige Tests bescheinigen ihm einen hohen Erkennungswert. Für ein M365-KMU mit Standardbedarf ist das ein schwer zu schlagender Einstiegspunkt. Barracuda behält den Vorteil bei der Unabhängigkeit gegenüber dem E-Mail-Anbieter (nützlich in hybriden Umgebungen oder bei Google Workspace) und beim MSP-Modell.

Bei der reinen verhaltensbasierten Erkennung funktioniert Abnormal Security ausschließlich per API und glänzt bei BEC und VEC (siehe unseren vollständigen Leitfaden zu Abnormal Security). Viele Organisationen nutzen es als Ergänzung zu einem SEG statt als Ersatz.

Das Fazit: für wen ist Barracuda die richtige Wahl?

Barracuda EGD ist relevant, wenn Sie ein KMU oder ein Mittelständler sind, der einen einfach bereitzustellenden und zu betreibenden Cloud-E-Mail-Schutz sucht, ohne dediziertes SOC-Team, mit einem guten Preis-Abdeckungs-Verhältnis. Es ist auch die bevorzugte Wahl der MSP dank seiner Multi-Tenant-Konsole und seiner Massen-Remediation. Barracuda ist hingegen nicht der naheliegende Kandidat, wenn Sie die erstklassige Threat Intelligence eines Großkonzerns anstreben (Proofpoint), eine All-in-One-Suite für Archivierung/Kontinuität (Mimecast), oder wenn Sie vollständig M365 mit grundlegenden Bedürfnissen sind (Defender genügt).

🖥️ Migration und Deployment Schritt für Schritt

Sobald Barracuda Email Gateway Defense ausgewählt ist, bleibt es bereitzustellen, ohne den Dienst zu unterbrechen. Die folgende Sequenz stützt sich auf die Umschaltung per MX-Priorität.

Deployment-Leitfaden in 5 Schritten, von der DNS-Inventur bis zur MX-Umschaltung

1. Dokumentieren Sie den aktuellen Zustand Ihrer MX-, SPF-, DKIM- und DMARC-Einträge mit den CaptainDNS-Tools. Erfassen Sie vor allem alle legitimen Versandquellen Ihrer Domain: Hauptserver, Marketing (Mailchimp, HubSpot), Transaktional (SendGrid, Mailgun), CRM (Salesforce), Ticketing (Zendesk), interne Produkte. Jede muss in Ihrer neuen SPF-Konfiguration authentifiziert und in der DMARC-Roadmap berücksichtigt werden.

2. Fügen Sie in der EGD-Konsole Ihrer Region (us., de., uk., ca., au. oder in.ess.barracudanetworks.com) Ihre Domain hinzu und verifizieren Sie deren Eigentümerschaft. Rufen Sie Ihre eindeutige Kontokennung für den MX ab (<id>.ess.barracudanetworks.com). Konfigurieren Sie die Verbindung zu Ihrem Zielserver (M365, Google Workspace, Exchange) und synchronisieren Sie das Nutzerverzeichnis. Notieren Sie sich Ihre Region: Sie bestimmt den zu verwendenden SPF-Include.

3. Fügen Sie den Barracuda-MX mit einer Priorität 99 hinzu (der am wenigsten vorrangigen). Ihre bestehenden MX behalten eine niedrige Priorität und empfangen weiterhin die legitime Post. Senden Sie Test-E-Mails, um zu überprüfen, dass das Barracuda-Konto den Verkehr Ihrer Domain korrekt annimmt und dass das Routing zu Ihrem Zielserver funktioniert. Diese Phase validiert die Konfiguration ohne jegliches Risiko eines Nachrichtenverlusts.

4. Sobald die Konfiguration validiert ist, setzen Sie den Barracuda-MX auf niedrige Priorität (10) und entfernen Sie alle alten MX. Führen Sie die Umschaltung außerhalb der Stoßzeiten durch. Überprüfen Sie mit dig MX captaindns.com +short, dass nur noch der Barracuda-MX vorhanden ist. Verriegeln Sie anschließend Ihren Microsoft-365- oder Google-Workspace-Connector, sodass er den eingehenden Verkehr nur von den Barracuda-IPs annimmt, und schließen Sie damit die Hintertür des Rest-MX.

5. Fügen Sie den regionalen Barracuda-SPF-Include hinzu (keine andere Region), unter Einhaltung der 10 Lookups. Aktivieren Sie die DKIM-Signatur mit 2048 Bit in der Konsole und veröffentlichen Sie den öffentlichen Schlüssel im DNS. Setzen Sie DMARC auf p=none, überwachen Sie die Berichte 2 bis 4 Wochen, steigen Sie dann auf p=quarantine und p=reject. Validieren Sie jeden Eintrag mit den CaptainDNS-Checkern.

Der Sonderfall der Migration von der ESG-Appliance

Wenn Sie noch die Email-Security-Gateway-(ESG)-Appliance betreiben, treibt Barracuda die Migration zum Cloud-Dienst EGD über sein Programm "ESG Elevate" voran. Die Logik ist klar: Die Legacy-Appliance erhält nicht mehr dieselben Investitionen, zwingt Sie dazu, Hardware und Patches selbst zu verwalten, und der Vorfall von 2023 hat an die Kosten einer Schwachstelle bei einem Produkt erinnert, das der Kunde selbst patchen muss.

Die Migration von ESG zu EGD läuft darauf hinaus, von einer On-Premise-Filterung zu einer Cloud-Filterung zu wechseln. Konkret: Sie stellen EGD in der Konsole bereit, übertragen Ihre Filterrichtlinien (Barracuda stellt dafür Assistenten bereit), testen mit Priorität 99 wie oben beschrieben, und schalten dann die MX der Appliance auf <id>.ess.barracudanetworks.com um. Um die manuelle Arbeit zu begrenzen, bietet das Programm ein Konvertierungstool, das die Einstellungen, Domains und Nutzer von ESG automatisch über ein Barracuda Cloud Control Konto zu EGD migriert, wobei Barracuda eine Umschaltung "in weniger als einer Stunde" ankündigt. Der Hauptvorteil: Sie haben keine Appliance mehr zu warten und keinen kritischen Patch mehr dringend anzuwenden. Genau das ist das Vorfallszenario, das der folgende Abschnitt detailliert.

⚠️ Grenzen, Nachteile und die Schwachstelle von 2023

Keine Lösung ist perfekt, und Barracuda schleppt den Ruf eines ernsten Vorfalls mit sich. Nur betrifft dieser Vorfall ein bestimmtes Produkt, das man vom Cloud-Dienst unterscheiden muss. Wir gehen zuerst die sachlichen Grenzen von EGD durch, dann die CVE-2023-2868.

Die Grenzen des Cloud-Dienstes

• Threat Intelligence unter den Leadern. Bei der Erkennung der raffiniertesten BEC- und APT-Angriffe bleibt Barracuda laut Analysten hinter Proofpoint und Mimecast zurück. Seine Positionierung als Visionär im Gartner 2025 spiegelt eine anerkannte Produktvision, aber eine als unter den Leadern eingestufte Ausführung wider. Für eine ultragezielte Branche (Finanzen, Verteidigung) ist es nicht die erste Wahl.

• Weniger vollständige native Suite. Die Archivierung (Cloud Archiving), die Sensibilisierung und bestimmte erweiterte Schutzfunktionen sind Module oder höhere Pläne (Premium, Premium Plus). Der Einstiegspreis von EGD ist attraktiv, aber ein vollständiger Schutz erfordert es, die Bausteine zu kumulieren, und die Gesamtkosten steigen. Vergleichen Sie den genauen Umfang jedes Plans, bevor Sie unterschreiben.

• Eingeschränktere regionale Abdeckung. Sechs Regionen (US, DE, UK, CA, AU, IN), das ist feinkörniger bei manchen Wettbewerbern. Überprüfen Sie, dass Ihre Anforderung an den Datenstandort einer verfügbaren Region entspricht, insbesondere bei strikten Souveränitätsvorgaben.

• URL-Rewrite und False Positives. Wie jedes SEG kann Barracuda Links über Link Protection umschreiben: Die URLs zeigen dann auf eine Barracuda-Umleitungsadresse. Gute Nachricht für die üblichen Bedenken bei Magic Links: Die umgeschriebenen URLs laufen nicht ab, und Barracuda schreibt geläufige Domains nicht um (google.com, microsoft.com, teams.microsoft.com), gerade um False Positives zu begrenzen. Das Risiko bei Einmal-Links (Passwort-Zurücksetzung) ist daher gemäßigter, als man befürchtet. Die Wachsamkeit gilt eher der Quarantäne, die in den ersten Wochen zu überwachen ist: Absender, die eigentlich auf der Zulassungsliste stehen, finden sich manchmal dort blockiert wieder, und die Nutzerrückmeldungen (G2) weisen auf eine manuelle Einstellung hin, die zu Beginn einzuplanen ist.

Die CVE-2023-2868 betraf die Appliance, nicht die Cloud

Die CVE-2023-2868 ist der markanteste Sicherheitsvorfall in der Geschichte von Barracuda. Eine Präzisierung gleich vorweg: Diese Schwachstelle betraf die Email-Security-Gateway-(ESG)-Appliance, nicht den Cloud-Dienst Email Gateway Defense (EGD), um den es in diesem Artikel geht. Wenn Sie EGD evaluieren oder nutzen, waren Sie nicht exponiert. Gehen wir die Fakten der Reihe nach durch, ohne zu dramatisieren.

Die Schwachstelle war eine Command Injection über das Parsing-Modul für als Anhang empfangene .tar-Dateien, im Perl-Code der ESG-Appliance. Ihr CVSS-Score betrug 9,8 (kritisch), nahezu das Maximum. Konkret konnte ein Angreifer eine E-Mail mit einem speziell formatierten .tar-Anhang senden, um beliebigen Code auf der Appliance auszuführen.

Die Chronologie ist aufschlussreich. Die In-the-Wild-Ausnutzung begann bereits im Oktober 2022, also mehrere Monate vor jeglicher Entdeckung. Mandiant (Google Cloud Threat Intelligence) ordnete die Kampagne UNC4841 zu, einem mutmaßlich mit China verbundenen Akteur (China-nexus). Barracuda entdeckte am 18. Mai 2023 anomalen Verkehr, stellte am 20. Mai 2023 einen weltweiten Patch bereit und veröffentlichte die Offenlegung am 23. Mai 2023.

Der Punkt, der die Gemüter bewegte, ist die Empfehlung zum physischen Austausch: Barracuda formulierte sie zunächst am 31. Mai 2023, dann am 6. Juni 2023 erneut, und riet zum sofortigen Austausch aller kompromittierten ESG-Appliances, unabhängig vom angewandten Patch-Level. Der Grund: Die Angreifer hatten persistente Hintertüren platziert (unter anderem die Malware SEASPY, SUBMARINE und SALTWATER), die die Patches überlebten. Das FBI hat diese Empfehlung zum Hardware-Austausch weitergegeben. Es ist ein seltener Fall, in dem ein Anbieter rät, die Hardware wegzuwerfen, statt sie zu patchen, was viel über die Tiefe der Kompromittierung aussagt. Barracuda hat zudem nie eine genaue Zahl betroffener Organisationen veröffentlicht und sprach nur von einer "begrenzten Anzahl" unter den Hunderttausenden bereitgestellten Appliances.

Für eine Entscheidung im Jahr 2026 sagt der Vorfall vor allem eines aus: das strukturelle Risiko der Appliances, die der Kunde selbst patchen muss. Eine verwaltete Cloud wie EGD überträgt diese Verantwortung an den Anbieter. Daraus folgt der Kernpunkt: EGD war nicht von dieser CVE betroffen, und das Cloud-Produkt aufgrund des ESG-Vorfalls auszuschließen bleibt ein häufiger Analysefehler. Das ist im Übrigen das Argument, das Barracuda anführt, um die Migration von ESG zu EGD voranzutreiben: die Angriffsfläche der On-Premise-Appliance eliminieren.

📋 Empfohlener Aktionsplan

Vom ersten Audit bis zur strikten DMARC-Richtlinie, hier die vollständige Sequenz, um Barracuda Email Gateway Defense zu evaluieren und dann bereitzustellen.

1. Auditieren Sie Ihre aktuelle E-Mail-Sicherheitslage (MX, SPF, DKIM, DMARC) mit den CaptainDNS-Tools
2. Den Produktbedarf klären: Bestätigen Sie, dass Sie EGD (Cloud) und nicht die ESG-Appliance evaluieren, und wählen Sie den Plan (Advanced, Premium, Premium Plus) je nach Ihrem Bedarf an DMARC, Sensibilisierung und Backup
3. Vergleichen Sie mit Mimecast, Proofpoint und Microsoft Defender je nach Ihrer Größe, Ihrem Budget und Ihrem Modell (intern oder MSP)
4. Ein POC anfragen und Ihre EGD-Region identifizieren (US, DE, UK, CA, AU, IN), die den SPF-Include bestimmt
5. Die regionale Konsole konfigurieren, die Domain hinzufügen, die MX-Kennung abrufen und das Verzeichnis synchronisieren
6. Mit Priorität 99 testen: das Routing ohne Risiko eines Nachrichtenverlusts validieren
7. Die MX umschalten auf niedrige Priorität außerhalb der Stoßzeiten und alle alten MX entfernen
8. Den Connector verriegeln M365/Google Workspace, sodass er nur die Barracuda-IPs annimmt
9. SPF einrichten (regionaler Include, -all), DKIM (2048 Bit) und DMARC (p=none dann Verschärfung)
10. Überwachen Sie die Quarantäne, die DMARC-Berichte und steigen Sie nach 4 bis 8 Wochen sauberer Überwachung auf p=reject

📚 E-Mail-Gateway-Leitfäden

Diese Analyse ist Teil unserer Serie über E-Mail-Sicherheitslösungen:

• Mimecast Secure Email Gateway: Architektur, DNS-Konfiguration, Vergleich und Aktionsplan
• Proofpoint Secure Email Gateway: Nexus AI, TAP, EchoSpoofing 2024 und DNS-Konfiguration
• Abnormal Security: verhaltensbasierte KI, API-Deployment, Attune 1.0

FAQ

Was ist Barracuda Email Gateway Defense?

Barracuda Email Gateway Defense (EGD) ist ein Cloud Secure Email Gateway, das 100 % des eingehenden E-Mail-Verkehrs filtert, bevor er Ihren Mailserver erreicht. Sie leiten Ihre MX-Einträge zur Barracuda-Infrastruktur um (<id>.ess.barracudanetworks.com), die jede Nachricht prüft (Reputation, Anti-Spam, Anti-Malware, Advanced Threat Protection, Anti-Phishing) und dann den sauberen Verkehr an Microsoft 365, Google Workspace oder Exchange weiterleitet. Es ist der frühere Barracuda Email Security Service (BESS), historisch auf KMU und MSP ausgerichtet, mit über 200 000 Kunden weltweit.

Was ist der Unterschied zwischen Email Gateway Defense und Email Security Gateway?

Es sind zwei unterschiedliche Produkte. Email Gateway Defense (EGD) ist der Cloud-SEG-Dienst, vollständig bei Barracuda unter ess.barracudanetworks.com gehostet, ohne Hardware zu verwalten. Email Security Gateway (ESG) ist eine physische oder virtuelle Legacy-Appliance, on-premise oder in der Cloud des Kunden bereitgestellt, die die Organisation selbst administriert und patcht. Es ist die ESG-Appliance, nicht der Cloud-Dienst EGD, die 2023 von der CVE-2023-2868 betroffen war. Barracuda treibt die Migration von ESG-Kunden zu EGD über sein Programm ESG Elevate aktiv voran.

Welche MX-Einträge hat Barracuda?

Die MX von Barracuda Email Gateway Defense folgen dem Format <kunden-id>.ess.barracudanetworks.com, zum Beispiel d9307303a.ess.barracudanetworks.com. Die Kennung ist für Ihr Konto eindeutig und auf der Domain-Verifizierungsseite der EGD-Konsole sichtbar. Beim Deployment empfiehlt Barracuda, diesen MX mit Priorität 99 für die Testphase hinzuzufügen (die legitime Post bleibt auf dem alten Server), ihn dann auf niedrige Priorität (10) zu setzen und die alten MX zu entfernen, sobald die Konfiguration validiert ist.

Welchen SPF-Include mit Barracuda verwenden?

Der SPF-Include hängt von Ihrer Region ab. In den USA: include:spf.ess.barracudanetworks.com. In Deutschland/Europa: include:spf.ess.de.barracudanetworks.com. In Großbritannien: include:spf.ess.uk.barracudanetworks.com. In Kanada: include:spf.ess.ca.barracudanetworks.com. In Australien: include:spf.ess.au.barracudanetworks.com. In Indien: include:spf.ess.in.barracudanetworks.com. Barracuda empfiehlt, den Eintrag mit -all zu beenden. Überwachen Sie die Gesamtzahl der DNS-Lookups, um unter dem von der RFC 7208 vorgeschriebenen Limit von 10 zu bleiben.

Wie erkennt man, dass eine Domain durch Barracuda geschützt ist?

Zwei DNS-Signaturen identifizieren sie. Eingangsseitig: ein MX-Eintrag, der auf .ess.barracudanetworks.com endet (dig MX captaindns.com +short). Ausgangsseitig: das Vorhandensein eines include:spf.ess[.<region>].barracudanetworks.com im TXT-Eintrag der Domain (dig TXT captaindns.com +short). Beide zu kreuzen beseitigt jede Mehrdeutigkeit. Sie können auch das DNS-Lookup-Tool von CaptainDNS verwenden, um diese Einträge lesbar anzuzeigen, ohne dig zu bemühen.

Funktioniert Barracuda mit Microsoft 365 und Google Workspace?

Ja. Barracuda Email Gateway Defense ist unabhängig vom Messaging-Anbieter. Im Gateway-Modus leiten Sie die MX zu Barracuda um, unabhängig von Ihrem Zielserver (Microsoft 365, Google Workspace, Exchange on-premise), und konfigurieren dann die ausgehende Verbindung in der EGD-Konsole. Auf Microsoft-365-Seite beruht die Integration konkret auf drei Connectoren (zwei eingehend, einer ausgehend) plus einer "allow spoofing"-Richtlinie für den von Barracuda kommenden Verkehr; die Anti-Umgehungs-Verriegelung erfolgt über einen eingehenden Partner-Connector, der nur die Barracuda-IPs annimmt. Für Microsoft 365 fügen die höheren Pläne eine Schicht zur Postfach-Verteidigung per API und ein Incident-Response-Modul hinzu, um bereits zugestellte bösartige Nachrichten zu entfernen.

Betrifft die CVE-2023-2868 Email Gateway Defense (Cloud)?

Nein. Die CVE-2023-2868 (Command Injection über Parsing von .tar-Dateien, CVSS 9,8) betraf ausschließlich die Email-Security-Gateway-(ESG)-Appliance, nicht den Cloud-Dienst Email Gateway Defense (EGD). Wenn Sie EGD nutzen, waren Sie dieser Schwachstelle nicht ausgesetzt. Der Vorfall, ab Oktober 2022 vom Akteur UNC4841 ausgenutzt (Zuordnung Mandiant, China-nexus), führte dazu, dass Barracuda am 6. Juni 2023 den physischen Austausch der kompromittierten ESG-Appliances empfahl, aufgrund persistenter Hintertüren, die die Patches überlebten. Das ist eines der angeführten Argumente, um von der ESG-Appliance zur EGD-Cloud zu migrieren.

Ist Barracuda für KMU und MSP geeignet?

Ja, das ist sogar seine bevorzugte Positionierung. Barracuda EGD ist darauf ausgelegt, ohne dediziertes SOC-Team einfach bereitzustellen und zu betreiben zu sein, mit einem attraktiven Preis-Abdeckungs-Verhältnis für KMU und Mittelstand. Für MSP ermöglicht die Multi-Tenant-Architektur, die E-Mail-Sicherheit von Dutzenden Kunden über eine zentrale Konsole bereitzustellen, zu konfigurieren und zu überwachen, mit Massen-Remediation und nutzungsbasierter Abrechnung. Es ist eines der ausgereiftesten MSP-Programme am Markt, während Enterprise-Lösungen im Multi-Kunden-Modus schwerfällig zu betreiben bleiben.

Wie migriert man von der ESG-Appliance zu Email Gateway Defense?

Die Migration besteht darin, von einer On-Premise-Filterung zu einer Cloud-Filterung zu wechseln, über das Barracuda-Programm ESG Elevate. Sie stellen EGD in der regionalen Konsole bereit, übertragen Ihre Filterrichtlinien (Barracuda stellt Assistenten bereit), testen mit Priorität 99 ohne Risiko eines Nachrichtenverlusts, und schalten dann die MX der Appliance auf <id>.ess.barracudanetworks.com mit niedriger Priorität um, unter Entfernung der alten MX. Der Hauptvorteil: keine Appliance mehr zu warten und kein kritischer Patch mehr dringend anzuwenden, was die von der CVE-2023-2868 ausgenutzte Angriffsfläche eliminiert.

Verwaltet Barracuda DMARC und DKIM?

Ja. Die DKIM-Signatur wird in der EGD-Konsole konfiguriert: Sie wählen einen Selektor, Barracuda generiert das Schlüsselpaar, und Sie veröffentlichen den öffentlichen Schlüssel als TXT bei selektor._domainkey.captaindns.com (bevorzugen Sie 2048 Bit). Für DMARC stützt sich EGD auf Ihr SPF/DKIM-Alignment, und Sie steuern die Richtlinie von p=none zu p=reject. Im Plan Premium Plus aggregiert und visualisiert das Modul Domain Fraud Protection die DMARC-Berichte und begleitet den Aufstieg zu einer strikten Richtlinie. Bei EGD allein können Sie DMARC mit einem Drittanbieter-Tool steuern und dabei die Syntax mit dem CaptainDNS DMARC-Checker validieren.

Vergleichstabellen herunterladen

Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.

• Vergleich herunterladen (CSV)
• Vergleich herunterladen (JSON)

Glossar

• SEG (Secure Email Gateway): E-Mail-Sicherheitsgateway, das den eingehenden und ausgehenden Verkehr zwischen Internet und Mailserver filtert und jede Nachricht (Spam, Malware, Phishing) analysiert, bevor sie an den Empfänger übermittelt wird.

• EGD (Email Gateway Defense): das Cloud Secure Email Gateway von Barracuda, gehostet unter ess.barracudanetworks.com. Früher Barracuda Email Security Service (BESS). Thema dieses Artikels.

• ESG (Email Security Gateway): die Legacy-Barracuda-Appliance (physisch oder virtuell), vom Kunden administriert und gepatcht. Nicht mit EGD zu verwechseln. Es ist die von der CVE-2023-2868 betroffene Produktlinie.

• BESS (Barracuda Email Security Service): früherer Name des heute Email Gateway Defense genannten Cloud-Dienstes.

• MX (Mail Exchanger): DNS-Eintrag, der die für den Empfang der E-Mails einer Domain zuständigen Server angibt. Barracuda EGD bereitzustellen bedeutet, die MX zu <id>.ess.barracudanetworks.com umzuleiten.

• SPF (Sender Policy Framework): Authentifizierungsprotokoll, das die zum Versand von E-Mails für eine Domain autorisierten Server auflistet. TXT-Eintrag, begrenzt auf 10 rekursive Lookups (RFC 7208). Barracuda verwendet einen regionalen Include (spf.ess[.<region>].barracudanetworks.com).

• DKIM (DomainKeys Identified Mail): Protokoll, das E-Mails kryptografisch signiert. Der öffentliche Schlüssel wird im DNS veröffentlicht und erlaubt es dem Empfänger, die Integrität und Herkunft der Nachricht zu überprüfen.

• DMARC (Domain-based Message Authentication, Reporting and Conformance): Protokoll, das das Alignment zwischen der From-Domain und den durch SPF oder DKIM authentifizierten Domains überprüft und die im Fehlerfall anzuwendende Richtlinie festlegt (none, quarantine, reject).

• ATP (Advanced Threat Protection): Barracuda-Modul, das unbekannte Anhänge und Payloads in einer Sandbox analysiert, um Zero-Day-Bedrohungen durch Verhaltensbeobachtung zu erkennen.

• Impersonation Protection: Barracuda-Engine zur Erkennung von Identitätsmissbrauchsangriffen (BEC), basierend auf dem Lernen der normalen Kommunikationsmuster der Organisation, um Anomalien aufzuspüren.

• Incident Response: Barracuda-Modul, das es ermöglicht, bereits in den Postfächern zugestellte bösartige E-Mails automatisch zu entfernen, mit Massen-Remediation, besonders nützlich für MSP.

• BEC (Business Email Compromise): E-Mail-Betrug, bei dem sich der Angreifer als Geschäftsführer oder vertrauenswürdiger Partner ausgibt, um eine Überweisung oder sensible Daten zu erlangen. Oft ohne Link oder Anhang, also unsichtbar für signaturbasierte Filter.

• MSP (Managed Service Provider): Dienstleister, der die IT-Infrastruktur mehrerer Kunden verwaltet. Die Multi-Tenant-Architektur von Barracuda ist für dieses Modell gedacht.

• CVE-2023-2868: kritische Schwachstelle (CVSS 9,8) der Command Injection über das Parsing von .tar-Dateien in der ESG-Appliance, von UNC4841 ausgenutzt. Betrifft nicht den Cloud-Dienst EGD.

• UNC4841: mutmaßlich mit China verbundener Bedrohungsakteur (China-nexus), dem Mandiant die Ausnutzung der CVE-2023-2868 auf den ESG-Appliances ab Oktober 2022 zuordnet.

Quellen

• Barracuda Campus: Email Gateway Defense, Domain-Verifizierung und MX
• Barracuda Campus: Sender Policy Framework für ausgehende Post (regionale Includes)
• Barracuda Campus: Understanding Link Protection
• Barracuda Campus: Microsoft-365-Integration (Connectoren)
• Barracuda: 2025 Email Threats Report
• Barracuda Trust Center: ESG Appliance Vulnerability (CVE-2023-2868)
• Gartner Peer Insights: Email Security Platforms, Barracuda-Bewertungen
• Mandiant / Google Cloud: weltweite Ausnutzung der ESG durch UNC4841
• Gartner Magic Quadrant for Email Security 2025