Schutz vor Phishing - SPF, DKIM, DMARC

Schutz vor Phishing

SPF, DKIM, DMARC

Rocco Gagliardi
von Rocco Gagliardi
Lesezeit: 11 Minuten

Keypoints

So schützt man sich vor Phishing

  • Nahezu 90 % der Email-Angriffe basieren auf falschen Absenderidentitäten
  • Es gibt bekannte Methoden zum Schutz vor Identitätsdiebstahl
  • Die Implementierung von SPF, DKIM und DMARC kann für die meisten IT-Abteilungen schwierig sein
  • Nur ein Viertel der geprüften Domänen implementiert bisher mindestens einen der genannten Sicherheitsmechanismen

Laut neueren Untersuchungen basieren fast 90% der Email-Angriffe auf falschen Absendern, sowohl von Marken (83%) als auch von Einzelpersonen (6%). Eine Art des Identitätsdiebstahls, der so genannte exakte Domain-Identitätsdiebstahl (Exact Domain Identity Theft), tritt auf, wenn Betrüger eine Domain im From-Feld der Nachricht verwenden, um sich als Teil einer anderen Organisation auszugeben.

Es gibt Möglichkeiten, Spammer und Phisher daran zu hindern, Ihre Domain zu fälschen. Die Email-Authentifizierung – Überprüfung, ob eine Email wirklich von der Domäne stammt – basiert auf wohlbekannten Standards, die wir in unserem Beitrag diskutiert haben. Diese Sicherheitsmechanismen sind relativ einfach einzurichten und bieten ein gutes Schutzniveau.

Wenn diese Methoden Spam fast vollständig blockieren, warum hören wir dann immer noch häufig davon? In der Praxis setzen sie nicht alle Unternehmen ein.

SPF, DKIM, DMARC

Die Umsetzung von SPF ist nur der Anfang, denn für einen wirksamen Schutz ist es auch notwendig, DMARC und folglich DKIM umzusetzen.

DMARC bietet drei Hauptelemente zu den bisher existierenden Email-Authentifizierungsstandards:

Probleme

Wie jeder Schutz sind auch diese ein zusätzliches Problem, das es für das reibungslose Funktionieren des Systems zu lösen gilt: Im Grossen und Ganzen entscheidet der Inhaber der Domain, was der Empfänger mit den in seinem Namen erhaltenen Emails macht.

Es gibt keinen schnellen und sicheren Weg, um zu testen, ob eine Konfiguration funktioniert oder nicht, ohne mehrere Parteien gleichzeitig einzubeziehen. Dadurch wird alles akademischer: Man muss sich vor ein Papier setzen und die Policy so gestalten, dass sie theoretisch funktionieren kann; einmal implementiert, muss man ihre tatsächliche Funktionsweise überwachen und auf jedes Problem reagieren.

Die erwähnten Schutzsysteme sind für eine gemeinsame IT-Abteilung schwer zu verstehen und zu implementieren, weil:

Ausserdem gibt es einige spezifische technische Kritikpunkte:

Dies erklärt zum Teil, warum viele Administratoren es vorziehen, eine Einführung zu vermeiden oder “pro forma” umzusetzen.

Analyse

Um herauszufinden, wie der Stand der Implementierung in den verschiedenen Unternehmen ist, die täglich mit Millionen von Benutzern kommunizieren, haben wir eine Beispielanalyse von interessanten Bereichen durchgeführt. Die Liste der Domains wird von OpenPage Rank zur Verfügung gestellt. Wir haben die Domänen ausgewählt (basierend auf TLDs, Schlüsselwörtern usw.), die öffentlichen DNS-Einträge untersucht und den verschiedenen gefundenen Richtlinien eine Sicherheitsbewertung zugewiesen.

Verfahren

Die Analyse der Aufzeichnungen umfasst sowohl die Identifizierung der vorhandenen Mechanismen (SPF, DKIM, DMARC) als auch die definierten Richtlinien.

In der Policyanalyse:

Die gesammelten Informationen werden zur Analyse in einer MongoDB gespeichert:

Beispiel eines analysierten Datensatzes

Datensatz

Wir analysierten 414783 Domänen, ausgewählt nach bestimmten Top-Level-Domains:

TDL Anzahl Domains
.org 185695
.edu 99557
.eu 50526
.ch 46089
.gov 29839
.mil 2911
.bank 166

Resultate

Einsatz von Sicherheitsmassnahmen

Die nachfolgende Abbildung zeigt, wie viele Domains insgesamt und gruppiert nach ausgewählten TLDs Schutzmechanismen implementieren.

Verwendung von Sicherheitsmechanismen

Die nächste Abbildung zeigt im Detail für jede TDL den prozentualen Anteil der Domänen, die Schutzmechanismen verwenden.

Verwendung von Sicherheitsmechanismen durch TDLs

Beobachtungen:

Sicherheitniveau der Domains

Die folgende Abbildung zeigt die Anzahl der Domänen für jedes Niveau der Sicherheit.

Dieses wird auf der Grundlage des Vorhandenseins der Schutzmechanismen und der Qualität der Konfiguration berechnet.

Bereich Beschreibung
.-100 bis -50 Die Security Policy benutzt keine Schutzmechanismen oder setzt diese falsch ein
.-49 bis 0 Die Security Policy greifen auf unsichere Optionen zurück
.1 bis 50 Die Security Policy könnte restriktiver gesetzt werden
.51 bis 100 Die Security Policy ist gut konfiguriert

Verteilung des Sicherheitsniveaus

Beobachtungen:

SPF Konfigurationsqualität

Wir werfen nun einen genaueren Blick auf zwei spezifische SPF-Mechanismen (all und ip4_prefix), um die Kreativität einiger Administratoren mit den SPF-Policies zu zeigen.

Der All-Mechanismus

Die nächste zeigt, wie der wichtigste Mechanismus von SPF, die sogenannte all, in den analysierten Bereichen konfiguriert ist. Dieser obligatorische Mechanismus gibt an, was mit den nicht konformen E-Mails zu tun ist (abweisen, markieren oder ignorieren).

Dies ist ein gutes Beispiel dafür, was schief gehen kann: "v=spf1 +all" ist laut SPF-Organisation eine gültige Anweisung, aber laut Dokumentation: Der Domänenbesitzer denkt, dass SPF nutzlos ist und/oder sich nicht darum kümmert

Verteilung von all innerhalb von SPF

Beobachtungen:

Der ip4_prefix-Mechanismus

Die gezeigte Abbildung illustriert die Konfiguration eines weiteren SPF-Mechanismus, des ip4. Dieser Mechanismus wird verwendet, um eine bestimmte Anzahl von Servern als gültige Mailserver für die Domäne zu markieren. Wir haben die Maske extrahiert, um zu berechnen, wie viele Server mit diesem Mechanismus auf der Whitelist stehen. Die Anzahl dieser Server sollte nur auf die Mailserver beschränkt werden. Beachten Sie, dass dieser Mechanismus optional ist.

Nutzung von SPF ip4_prefix

Beobachtungen:

Andere Mechanismen

Es wurden acht Mechanismen für SPF analysiert. Wir haben nur zwei im Detail gezeigt, um zu betonen, dass selbst das Vorhandensein der SPF-Policy keine Sicherheitsgarantie ist. Darüber hinaus sind die Absichten derjenigen, die ein ip4-Präfix auf 0 konfigurieren, immer fragwürdig.

Zusammenfassung

Mechanismen zum Schutz vor Identitätsdiebstahl, gerade im Mailbereich, gibt es seit vielen Jahren. Aber aus verschiedenen Gründen werden sie noch nicht in grossem Umfang eingesetzt und oft nur im Informationsmodus zwecks Reporting verwendet.

Unsere Untersuchung zeigt, dass die Implementierung solcher Systeme, selbst für sensible Bereiche, noch lange nicht abgeschlossen ist.

Über den Autor

Rocco Gagliardi

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

Links

Sie wollen die Awareness Ihrer Benutzer prüfen?

Lassen Sie durch uns einen Social Engineering Test durchführen!

×
Übergang zu OpenSearch

Übergang zu OpenSearch

Rocco Gagliardi

Graylog v5

Graylog v5

Rocco Gagliardi

auditd

auditd

Rocco Gagliardi

Security Frameworks

Security Frameworks

Rocco Gagliardi

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv