Die OnDMARC-API eignet sich hervorragend für die Durchführung von umfangreichen oder sich wiederholenden Aufgaben, die schnell, häufig und fehlerfrei ausgeführt werden müssen – und Sie müssen kein Entwickler sein oder sogar wissen, wie man programmiert, um sie zu nutzen. Im Folgenden werde ich Ihnen zeigen, wie Sie die gängige Aufgabe der Aktualisierung der Subdomain-Richtlinie von Domains, die bereits abgelehnt wurden, mit Dynamic DMARC von Red Sift, der OnDMARC-API und Make (früher bekannt als Integromat) durchführen können. In diesem Beispiel verwenden wir Make, aber Sie können problemlos ein beliebiges Automatisierungswerkzeug ohne Code wie Zapier oder Retool verwenden.
Was tun wir, und warum
Wenn OnDMARC zum ersten Mal einen DMARC-Eintrag für eine Domäne einrichtet, die zuvor keinen Eintrag hatte, wird immer eine Richtlinie mit p=„none“ (nur DMARC-Berichterstattung) und sp=none erstellt. Das bedeutet, dass die Richtlinie für die Subdomäne ebenfalls auf „Reporting only“ gesetzt wird. Das bedeutet, dass der Empfänger keine (blockierenden) Maßnahmen ergreifen sollte, wenn E-Mails, die von der Domäne oder einer ihrer Subdomänen kommen und keine spezifische Richtlinie haben, DMARC nicht bestehen. Die E-Mail wird ganz normal zugestellt, und ein DMARC-Bericht wird zur Analyse an uns zurückgeschickt. Es sei denn, die Subdomain verfügt über eine eigene DMARC-Richtlinie – mehr dazu in unserem hilfreichen DMARC-Leitfaden hier.
Diese passive Richtlinie ist gut, solange eine Domain und ihre Sendequellen konfiguriert werden, aber sobald das geschehen ist oder wenn die Domain und ihre Subdomains nicht senden, sollte die Richtlinie schnell auf p=reject geändert werden. In diesem Fall werden E-Mails, die DMARC nicht bestehen, vom Empfänger zurückgewiesen, wodurch Spoofing-Versuche blockiert werden.
In unserem Beispiel haben wir 4 Domänen in einem OnDMARC-Konto. Wir haben 3 Domänen sorgfältig auf p=reject umgestellt, aber vergessen, die Subdomänen-Richtlinie zu aktualisieren, die auf sp=none bleibt. Eine verbleibende Domäne steht noch auf p=none, weil wir noch daran arbeiten. Wir müssen also zurückgehen und die Subdomänen-Richtlinie für 3 der 4 Domänen auf sp=reject aktualisieren. Mit der OnDMARC-Schnittstelle und Dynamic DMARC ist dies eigentlich recht einfach und würde etwa 12 Klicks erfordern. Aber was wäre, wenn wir statt 3 von 4 Domänen 36 von 73 hätten? Das würde viel weniger Spaß machen. Hier kommt die OnDMARC-API ins Spiel.
Schritt 1: Besorgen Sie sich einen OnDMARC-API-Schlüssel
Zuerst müssen wir einen API-Schlüssel für OnDMARC erhalten. Gehen Sie zur Verwaltung im Benutzer- und Kontobereich, indem Sie auf das Profilsymbol oben rechts auf dem Bildschirm klicken.
Klicken Sie dann auf die Registerkarte OnDMARC und stellen Sie sicher, dass Sie die richtige Instanz aus der Instanzauswahl auswählen. Wenn Sie nur Zugriff auf eine OnDMARC-Instanz haben, müssen Sie sich nicht um die Auswahl der richtigen Instanz kümmern.
Blättern Sie zur API-Schlüsseltabelle am unteren Rand des Bildschirms und klicken Sie auf Hinzufügen. Vergewissern Sie sich, dass Sie diesem Schlüssel während des Vorgangs die Rolle Super Admin zugewiesen haben. Kopieren Sie den API-Schlüssel an einen sicheren Ort. Ihr API-Schlüssel-Bildschirm sollte jetzt so aussehen:
Schritt 2: Laden wir unsere Domainliste von OnDMARC herunter
Klicken Sie auf dem Bildschirm „Meine Domains“ auf die unten hervorgehobene Schaltfläche „Exportieren“ und laden Sie Ihre Domainliste als CSV-Datei herunter.
Gehen Sie dann zu Google Sheets (oder Microsoft Office 365) und laden Sie es in ein neues Blatt hoch. Entfernen Sie alle Spalten außer der Domänenspalte, damit wir uns auf diese konzentrieren können. Das Blatt sollte nun in etwa so aussehen:
Wir hätten die Domänenliste auch von der API abrufen können, indem wir den API-Endpunkt GET /domains anstelle der CSV-Methode verwendet hätten.
Schritt 3: Make einrichten
Nachdem wir nun unser Kontrollblatt eingerichtet haben, gehen wir zu Make, um unser Automatisierungsszenario einzurichten. Wenn Sie noch kein Konto haben, können Sie hier eines einrichten.
Gehen Sie nun zu Scenarios und klicken Sie auf „Create a new scenario“. Fügen Sie das erste Modul hinzu und wählen Sie das Google Sheets-Modul „Get Range Values“. Wenn Sie dies zum ersten Mal tun, wird Make Sie bitten, sich bei Google Sheets zu authentifizieren, bevor Sie fortfahren.
Danach richten wir das Modul so ein, dass es den richtigen Zeilenbereich aus unserer spezifischen Google Sheets-Datei und Registerkarte abruft. Das sollte so aussehen:
Wir können dies testen, indem wir mit der rechten Maustaste auf das Modul klicken und „Nur dieses Modul ausführen“ wählen, um die Ausgabe zu überprüfen.
Wie erwartet, erhalten wir ein Bündel pro Zeile, das jeden Bereich enthält. So können wir in den folgenden Schritten jede Domäne in der Liste durchgehen.
Als Nächstes werden wir die OnDMARC-API anpingen, um zunächst die aktuellen dynamischen DMARC-Einstellungen zu prüfen und sie dann gegebenenfalls zu aktualisieren. Wir überprüfen die aktuellen Einstellungen, bevor wir sie aktualisieren, da wir die Subdomain-Richtlinie nur für Domänen aktualisieren wollen, bei denen die Top-Level-Richtlinie auf Ablehnung steht.
Um die vorhandenen Einstellungen der dynamischen DMARC-Richtlinie abzurufen, verwenden wir den Endpunkt GET domainDMARC. Dieser ruft die aktuellen dynamischen DMARC-Einstellungen einer bestimmten Domäne in der OnDMARC-Instanz ab.
Schritt 4: Durchführung des ersten OnDMARC-API-Aufrufs
Erstellen Sie ein neues Modul und verknüpfen Sie es mit dem ersten Modul von Google Sheets. Wählen Sie die HTTP-App und die Aktion „Make a Basic Auth request“ wie unten dargestellt:
Geben Sie in das Feld URL die Basis-URL der API für Ihr Gebietsschema ein, gefolgt von der Erweiterung „/domain/{domain}/dmarc“. Die korrekte Basis-URL finden Sie oben in der API-Dokumentation. Sie variiert je nach Standort Ihrer Instanz (EU, UK oder US). Für die britische Instanz würde sie wie folgt aussehen: https: //api.ondmarc.com/domain/{domain}/dmarc
Ersetzen Sie nun {domain} durch einen Verweis auf die Domänenspalte im Google Sheet aus dem vorherigen Modul wie folgt:
Stellen Sie sicher, dass die Methode auf GET eingestellt ist, und dann können wir zum nächsten Schritt der Einrichtung dieses API-Aufrufs übergehen: Autorisierung. Damit der API-Aufruf funktionieren kann, muss er mit Ihrem API-Schlüssel autorisiert werden. Dazu müssen wir einen Autorisierungs-Header hinzufügen.
Geben Sie Punkt 1 im Abschnitt Kopfzeilen den Namen „Autorisierung“ und in das Feld Wert geben Sie Api-Key ein, gefolgt von einem Leerzeichen, gefolgt von dem API-Schlüssel, den Sie in Schritt 1 gespeichert haben. Achten Sie darauf, dass Sie diese Schritte genau wie angegeben ausführen, da Groß- und Kleinschreibung beachtet werden müssen. Das Endergebnis sollte wie im obigen Screenshot aussehen.
Als letzten Schritt setzen Sie den Body-Typ auf Raw, den Content-Typ auf JSON (application/json) und „Parse response“ auf yes, dann klicken Sie zum Speichern auf OK.
Führen Sie nun das gesamte Szenario aus, um es zu testen.
Großer Erfolg. Bei der Analyse der Ausgabe gibt die API ein Datenobjekt zurück, das ein Array mit der Bezeichnung „entries“ enthält. Das erste Element (Element 1) enthält die Richtlinie der obersten Ebene und das dritte Element (Element 3) enthält die Richtlinie der Unterdomäne. Um uns die Manipulation des Arrays zu ersparen, gehen wir davon aus, dass die Einträge immer in dieser Reihenfolge zurückgegeben werden, und erstellen einfache Zuordnungen für unsere Filter.
Zurück zu unserem Google-Blatt, geben Sie in der Kopfzeile von Spalte B „p=“ und in Spalte C „previous sp=“ ein, in D fügen wir „Update status code“ und in E „new sp=“ ein. Das Ergebnis sollte wie folgt aussehen:
Lassen Sie uns nun unsere erste Rückmeldung an Google Sheets erstellen, um die aktuellen Einstellungen zu Bestätigungszwecken in unser Blatt zurückzuschreiben. Fügen Sie ein Google Sheets-Modul „Zeile aktualisieren“ hinzu und richten Sie es wie folgt ein:
Beachten Sie den Verweis auf die Zeilennummer des ersten Moduls, um sicherzustellen, dass die Ergebnisse an die richtige Zeile angehängt werden. Und in den Spalten B und C beziehen wir uns auf die Werte der Elemente 1 und 3 des Arrays „Entries“, das von der OnDMARC-API zurückgegeben wurde. Wenn wir nun das Szenario ausführen, sollten die Ergebnisse wie folgt aussehen:
Wir können jetzt deutlich sehen, dass die Domänen in den Zeilen 2, 4 und 5 ihre Subdomänen-Richtlinie so anpassen müssen, dass sie abgelehnt werden, aber nicht die in Zeile 3. Lassen Sie uns mit dem nächsten Schritt fortfahren.
Schritt 5: Filterung und Aufruf der Aktualisierungs-API
Lassen Sie uns nun ein Router-Modul erstellen, um zwei mögliche Pfade für unser Szenario zu erstellen. Klicken Sie auf das + Zeichen neben dem letzten Modul im Szenario und suchen Sie nach „Router“. Im ersten Weg werden wir nur die Zeilen durchlassen, in denen die p=-Policy den Wert „reject“ hat, und im zweiten alle anderen Ergebnisse.
Richten wir den ersten Filter ein, indem wir auf den ersten Pfad nach dem Router klicken. Benennen Sie den Filter und richten Sie ihn wie folgt ein:
Das bedeutet, dass nur Elemente, für die die Richtlinie p=reject gilt, diesen Durchgang passieren dürfen. Auf dem zweiten Pfad richten wir den umgekehrten Filter ein:
Beachten Sie den Operator „Nicht identisch mit“.
Lassen Sie uns zuerst den zweiten Pfad einrichten, da er am einfachsten ist. Hier brauchen wir die Richtlinie nicht zu aktualisieren, wir schreiben einfach zurück in die Zeile, dass keine Aktualisierung erforderlich war. Klonen Sie das Modul Zeile aktualisieren und ziehen Sie es auf den zweiten Pfad, bearbeiten Sie es so, dass es wie folgt eingerichtet wird:
Denken Sie daran, dass Spalte D unser Feld „Aktualisierungsstatuscode“ ist.
Wenden wir uns nun dem ersten Pfad zu, in dem wir einen Aktualisierungsaufruf an die OnDMARC-API machen werden. Anstatt ein neues HTTP-Modul von Grund auf neu zu erstellen, klonen Sie das erste Modul, benennen es um und ziehen es dann in den Pfad. Die Pfade sollten wie folgt aussehen:
Jetzt müssen wir den API-Aufruf ändern, weil wir nicht mehr die aktuellen Einstellungen abrufen, sondern neue Einstellungen übertragen wollen. Wir werden denselben API-Endpunkt verwenden, aber statt eines GET-Aufrufs werden wir einen PATCH-Aufruf mit einigen zusätzlichen Informationen im Textkörper verwenden, um die gewünschten geänderten Einstellungen anzugeben. Richten Sie ihn wie folgt ein:
Denken Sie daran, die Methode in PATCH zu ändern, die gleichen Autorisierungs-Header beizubehalten und Folgendes in den Inhalt oder den Body der Anfrage aufzunehmen:
[{
"key": "sp",
"value": "reject"
}]
Dadurch wird die Subdomain-Richtlinie der fraglichen Domain aktualisiert, während alles andere unverändert bleibt.
Fügen wir nun eine letzte Rückmeldung in Google Sheets ein. Klonen Sie das Google Sheets-Modul „Zeile aktualisieren“, benennen Sie es um und ziehen Sie es aus dem unten angegebenen Pfad, und richten Sie es wie folgt ein:
Dadurch wird der Statuscode der Antwort in Spalte D zurückgeschrieben, und wenn der Status erfolgreich ist (Code 200), dann wird der aktualisierte Wert („reject“) in Spalte E geschrieben, andernfalls wird sie leer gelassen.
Das vollständige Szenario sollte wie folgt aussehen:
Lassen Sie es ablaufen!
Wenn alles richtig eingestellt ist, sollten die Domains, die abgelehnt werden, über Route 1 gehen, und die, die nicht abgelehnt werden, über Route 2 geleitet werden. Und hier ist das Ergebnis in Google Sheets, perfekt:
Schlussfolgerung
Dies ist ein großartiges Beispiel für einen realen Anwendungsfall der OnDMARC-API. Wir haben gesehen, wie jeder sie mit einer Tabellenkalkulationssoftware wie Google Sheets oder Microsoft Office 365 als Kontrollblatt und Make oder Zapier als Automatisierungstool für die API-Aufrufe nutzen kann. In diesem Beispiel haben wir die API verwendet, um die dynamischen DMARC-Einstellungen für eine Reihe von Domänen bedingt zu aktualisieren, aber jede andere Aktion ist ebenfalls möglich. Um einige Ideen zu bekommen, können Sie sich die OnDMARC-API-Dokumentation ansehen oder einfach daran denken, dass Sie für alles, was Sie manuell in der Benutzeroberfläche tun können, wahrscheinlich auch einen passenden API-Endpunkt finden können, an dem Sie es automatisch orchestrieren können.
Source: Red Sift-Blog
Sie haben Fragen? Ihr Ansprechpartner für D/A/CH
Do you have any questions? Your contact person for D/A/CH
Julian Wulff, Director Cyber Security Central Europe at Red Sift