• Bewerte uns auf OMR Reviews: Klick

  • 25Reports geht live, schaut es euch an: Klick

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

  • Zertifikate vom Deutschen Forschungsnetz beziehen (Harica CA)? Klick

Wir gehen live - Early Access

JanJäschke

NoSpamProxy

Teammitglied
Registriert
12 September 2019
Beiträge
1,586
Reaktionspunkte
388
Das Produkt ist richtig cool! 👍

Nur die folgenden vier Funktionen fehlen uns zur Perfektion:
- MTA-STS/TLS-RPT Unterstützung
- DNS-Monitor, der bei Änderung an DNS-Einträgen für SPF, DMARC, DKIM, BIMI und MTA-STS/TLS-RPT warnt/informiert
- Anbindung an NoSpamProxy Cloud Portal
- API zur Anbindung an Ticketsysteme wie DocBee oder ServiceNow

(BIMI wird sich vermutlich nicht durchsetzen und ist uns daher aktuell unwichtig.)

Großes Lob! 😎
 
Hallo Marvin,
danke für das tolle Feedback. :-) Das gebe ich sehr gerne ans Team weiter!
Die ersten drei Punkte stehen auf der Roadmap für das kommende Jahr. Auch wenn in diesem Jahr noch das Alerting kommt, wird es noch nicht so umfassend sein, wie Du es beschreibst.
Gruß Stefan
 
Das Produkt ist richtig cool! 👍

Nur die folgenden vier Funktionen fehlen uns zur Perfektion:
- MTA-STS/TLS-RPT Unterstützung
- DNS-Monitor, der bei Änderung an DNS-Einträgen für SPF, DMARC, DKIM, BIMI und MTA-STS/TLS-RPT warnt/informiert
- Anbindung an NoSpamProxy Cloud Portal
- API zur Anbindung an Ticketsysteme wie DocBee oder ServiceNow

(BIMI wird sich vermutlich nicht durchsetzen und ist uns daher aktuell unwichtig.)

Großes Lob! 😎

ich hänge mich da nochmal ran, hier mal die Infos, für die Ihr Alerts basteln könntet:

1759991280265.png
 
@Jordan @Marvin
Vielen Dank für euer Feedback und eure Ideen. :)

Unsere erste Alerting-Version kommt voraussichtlich in ein paar Wochen.
Damit wird es grundsätzlich möglich sein, über E-Mails mit DMARC-Problemen informiert zu werden.
Auch eine Alarmierung bei Änderung der DNS-Einträge (zunächst DMARC und SPF, DKIM kommt später) ist dann möglich. Die anderen Alarme nehme ich gerne in den Backlog und damit in die Roadmap-Diskussion für nächstes Jahr auf.
 
Hallo @Sarah,
ich habe bezüglich der Registrierung eine knifflige Frage. Die Dokumentation hat dazu leider keinen Rat. ;)
  • Registriert man sich am besten mit einem Konto, das im Tenant über weitreichende Rechte verfügt? Hintergrund der Frage: Für die Einrichtung werden ja offenbar verschiedene Komponenten und Verknüpfungen zu 25Reports benötigt. Oder gibt es keinerlei Abhängigkeiten, sodass auch ein „0815“-Konto aus dem Tenant ausreicht?
  • Ich nutze aktuell eine andere Lösung, bei der ich in den DNS-Einträgen zusätzliche E-Mail-Adressen hinterlege. Ist eine parallele Nutzung mit 25Reports organisatorisch überhaupt vorgesehen?
  • Gibt es bereits Überlegungen, wie mit Nutzern umgegangen wird, die bereits eine NFR-Lizenz von NSP besitzen?
  • Möchtet Ihr in der Dokumentation noch ein paar Worte dazu ergänzen, wie, wo und von wem die Daten gehostet werden? In meinem aktuellen DNS-Report taucht nämlich keine einzige deutsche IP-Adresse auf und die Kürzel der Städte in dem MTR bestätigen dies auch. Finde ich persönlich sehr schade.

Auch eine Alarmierung bei Änderung der DNS-Einträge (zunächst DMARC und SPF, DKIM kommt später) ist dann möglich. Die anderen Alarme nehme ich gerne in den Backlog und damit in die Roadmap-Diskussion für nächstes Jahr auf.
Gerne. Meiner Meinung nach sollte man aber nicht versuchen, mit dem Tool (oder Ansatz) ein vollständiges Audit bzw. Monitoring einer DNS-Zone ersetzen oder abbilden zu wollen. Denn eine DNS-Zone kann durchaus 10, 30, 100 oder auch 1000 und mehr Einträge enthalten – das halte ich technisch für unnötigen Overhead im Zusammenhang mit 25Reports.


Gruß,
Daniel
 
Zuletzt bearbeitet:
Ich nutze aktuell eine andere Lösung, bei der ich in den DNS-Einträgen zusätzliche E-Mail-Adressen hinterlege. Ist eine parallele Nutzung mit 25Reports organisatorisch überhaupt vorgesehen?

Bei DMARC- und TLS-RPT-Einträgen kann man mehrere Empfänger eintragen.
Beispiel:
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc_agg@vali.email,mailto:12345@dmarc-mail.de,mailto:dmarc@25reports.com; ruf=mailto:microsoft365@beispiel.de,mailto:beispiel@dmarc-mail.de; fo=1
v=TLSRPTv1; rua=mailto:tls-report@vali.email,mailto:beispiel@firma.de,mailto:beispiel@tls-report.de

Hilft dir das oder meinst du etwas anderes?

Gerne. Meiner Meinung nach sollte man aber nicht versuchen, mit dem Tool (oder Ansatz) ein vollständiges Audit bzw. Monitoring einer DNS-Zone ersetzen oder abbilden zu wollen. Denn eine DNS-Zone kann durchaus 10, 30, 100 oder auch 1000 und mehr Einträge enthalten – das halte ich technisch für unnötigen Overhead im Zusammenhang mit 25Reports.

Eine Domain darf maximal einen einzigen SPF- sowie DMARC-Eintrag enthalten.
25Reports sollte dazu die Syntax prüfen und bei mehr als einem Eintrag einen Fehler ausgeben.
Für SPF wäre eine Warnung bei 10 oder mehr Lookups auch cool.
Das ist meiner Meinung nach technisch gut umsetzbar und erzeugt keinen Overhead.
Die DKIM-Prüfung ist etwas komplexer, da es dort keine feste Obergrenze gibt. Mir bekannte Domains haben einen zweistelligen Bereich aber nie überschritten.
 
Hallo Marvin,
Hilft dir das oder meinst du etwas anderes?
Darum habe ich bewusst organisatorisch geschrieben – die technische Realisierung ist mir bekannt. Es gibt Lösungen am Markt, die ihre Funktionalität teilweise oder ganz einstellen, wenn bei einer Domain mehrere E-Mail-Adressen in den DMARC-Einträgen erkannt werden.

Eine Domain darf maximal einen einzigen SPF- sowie DMARC-Eintrag enthalten.
Der von mir zitierte Abschnitt von Sarah bezieht sich auf deine vorherigen Kommentar. Du hattest beim Punkt DNS Monitoring ein rotes Kreuz gesetzt. Nach meinem Verständnis betrifft das allerdings nicht nur DMARC und SPF, sondern auch andere Einträge sowie die allgemeine Funktionsfähigkeit (z.B. name Server out of sync) des DNS-Servers.


Gruß,
Daniel
 
Hey Daniel,
entschuldige, dann habe ich dich missverstanden. Danke für die Erklärung. 👍
 
Hallo Marvin,
quatsch. Für das musst du dich nicht entschuldigen.


Gruß,
Daniel
 
Hallo Daniel (@869288141),
ich nehme mal Bezug zu deinem ursprünglichen Post:
  • Registriert man sich am besten mit einem Konto, das im Tenant über weitreichende Rechte verfügt? Hintergrund der Frage: Für die Einrichtung werden ja offenbar verschiedene Komponenten und Verknüpfungen zu 25Reports benötigt. Oder gibt es keinerlei Abhängigkeiten, sodass auch ein „0815“-Konto aus dem Tenant ausreicht?
  • Ich nutze aktuell eine andere Lösung, bei der ich in den DNS-Einträgen zusätzliche E-Mail-Adressen hinterlege. Ist eine parallele Nutzung mit 25Reports organisatorisch überhaupt vorgesehen?
  • Gibt es bereits Überlegungen, wie mit Nutzern umgegangen wird, die bereits eine NFR-Lizenz von NSP besitzen?
  • Möchtet Ihr in der Dokumentation noch ein paar Worte dazu ergänzen, wie, wo und von wem die Daten gehostet werden? In meinem aktuellen DNS-Report taucht nämlich keine einzige deutsche IP-Adresse auf und die Kürzel der Städte in dem MTR bestätigen dies auch. Finde ich persönlich sehr schade.
  1. Die 25Reports-Einrichtung benötigt im wesentlichen zwei Dinge: Einen Microsoft Account und Zugriff auf den eigenen DNS. Je nach Einstellung des Azure Active Directories muss eurer Administrator bei der ersten Anmeldung den Zugriff via Single Sign On erlauben.
  2. Ich hatte hier tatsächlich auch das Wort "organisatorisch" überlesen (von daher danke @Marvin). Organisatorisch ist es uns egal, was du sonst noch an E-Mail Adressen eingetragen hast. Hauptsache unsere Adresse steht drin, sonst bekommen wir keine Daten.
  3. Wenn man Partner für 25Reports werden will, so kann man hierfür ebenfalls eine NFR-Lizenz bekommen. Für die Details kann man gerne Kontakt mit unserem Sales Office (sales@nospamproxy.de) aufnehmen.
  4. Ich nehme das gerne als Anregung für die Dokumentation mit. Allerdings kann ich dir auch hier schon direkt eine Antwort geben. :) Die Daten von 25Reports liegen derzeit auf deutschen und irländischen Servern bei einem der großen Hyperscaler. Der DNS-Report ist hier nicht aussagekräftig, weil die Abfragen gegen ein Content Delivery Network (CDN) laufen, welches die Benutzeroberfläche global verteilt. Die eigentlichen Daten werden dort aber nicht verarbeitet oder gespeichert.
Gerne. Meiner Meinung nach sollte man aber nicht versuchen, mit dem Tool (oder Ansatz) ein vollständiges Audit bzw. Monitoring einer DNS-Zone ersetzen oder abbilden zu wollen. Denn eine DNS-Zone kann durchaus 10, 30, 100 oder auch 1000 und mehr Einträge enthalten – das halte ich technisch für unnötigen Overhead im Zusammenhang mit 25Reports.
Unser langfristiges Ziel ist es, alle DNS-Einträge im Zusammenhang mit DMARC oder anderen E-Mail-Sicherheitsthemen (wie z.B. DNSSEC oder MTA-STS) zu monitoren. Folglich werden wir kein vollständiges Audit abbilden, sondern uns mehr darauf fokussieren, die entsprechenden Einträge zu bewerten hinsichtlich syntaktischer Korrektheit, Vollständigkeit und Wirksamkeit (so wie wir es für DMARC und SPF bereits tun).

Liebe Grüße
Sarah
 
Hallo Sarah,
herzlichen Dank für deine ausführliche Rückmeldung.
Die 25Reports-Einrichtung benötigt im wesentlichen zwei Dinge: Einen Microsoft Account und Zugriff auf den eigenen DNS. Je nach Einstellung des Azure Active Directories muss eurer Administrator bei der ersten Anmeldung den Zugriff via Single Sign On erlauben.
Freut mich zu lesen. Damit kann man sich an Prinzipien wie Least Privilege halten.

Die Daten von 25Reports liegen derzeit auf deutschen und irländischen Servern bei einem der großen Hyperscaler.
Ich konnte meinen Fehler inzwischen herausfinden. Beim MTR (My Traceroute) habe ich nicht die FQDNs (z. B. portal.25reports.com) verwendet, sondern die IPv4-Adressen.

Wird die IPv4-Adresse verwendet, gehen die Requests über den Teich. Nachstehend ein Beispiel:
1761168603914.png

Wird der FQDN verwendet, gehen die Requests nach Bielefeld (nein, wir sind nicht bei Wilsberg).
1761226262394.png

So ganz kann ich mir das noch nicht erklären. Wenn ich die Tests mit Adressen von meinem Arbeitgeber durchführe, gehen die Anfragen sowohl bei IPv4 als auch bei FQDN nicht über den Teich. Kann sich das jemand erklären?

Ich muss mich dafür entschuldigen und möchte das korrigieren. Meine vorherige Aussage war in diesem Punkt nicht korrekt. Sorry for that.

Gruß,
Daniel
 

Anhänge

  • 1761168749093.png
    1761168749093.png
    69.8 KB · Aufrufe: 9
  • 1761226184783.png
    1761226184783.png
    112 KB · Aufrufe: 1
Zuletzt bearbeitet:
Das ist eigentlich ganz rund erklärt:
beim CDN kannst du mehr oder weniger jeder Zeit eine andere IP Adresse erhalten, je nach dem von wo du derzeit potentiell den Content schneller ausgeliefert bekommst, selbst die Nutzung eines anderen DNS Servers kann hier schon massive Unterschiede bringen.
Wenn du nun sagst du hast die gleiche IP bei dir wie auch bei deinem Arbeitgeber getestet:
Hier kommen BGP ins Spiel oder einfacher gesagt das rooting im Internet, dieses ist auf Effizienz und Bandbreite ausgelegt. Du hast damit nicht immer von überall die gleiche Route die du zu einer IP gehst 🙃
Etwas kleiner betrachtet (und natürlich auch global genutzt) kannst du das gleiche Verhalten auch im Unternehmen haben wenn OSPF zum Einsatz kommt 😉
 
Hallo Daniel,
wie Jan schon erklärt hat, bestimmt der Netzwerk-Standort, welche IP-Adresse das CDN zurückmeldet.
Für diesen Netzwerk-Standort, spielt der DNS-Server eine entscheidende Rolle.
Wenn du die FQDN zunächst über einen DNS-Server aufgelöst hast, der in den USA ist (z.B. 8.8.8.8), so bekommst du auch eine entsprechend regionale IP-Adresse zurück.
WinMTR wiederum spricht vielleicht einen anderen DNS-Server an (welcher in Deutschland steht), um die IPv4 Adresse zu ermitteln. Dadurch bekommst du dementsprechend eine "deutsche" IP-Adresse vom CDN zurückgemeldet.

So lässt sich vielleicht erklären, warum du bei deinem manuellen Lookup eine andere IPv4-Adresse zurückbekommen hast, als wenn WinMTR diese aus der FQDN ermittelt. :)
 
Zurück
Oben