de-DEen-GB
rss

Granikos Technology Blog

NRW-Soforthilfe 2020 und E-Mail-Kommunikation - Die Geschichte eines angekündigten Betruges

IllustrationÜber das Desaster der Antragstellung für die NRW Soforthilfe 2020 wurde schon viel geschrieben und konnte den Eindruck gewinnen, dass Maßnahmen zum Schutz der Kommunikation und gegen weitere Betrugsversuche unternommen werden. Augenscheinlich hatte man nur die Antragstellung über das Online-Formular im Blick. Die dazugehörige E-Mail-Kommunikation der Bezirksregierung Köln war und ist aktuell nicht Bestandteil grundlegender Schutzmaßnahmen.

Das folgende Beispiel einer empfangenen E-Mail der Bezirksregierung Köln mit dem Absender Corona-Soforthilfe@bezreg-koeln.nrw.de habe ich zum Anlass genommen, mir die Konfiguration der Absenderdomäne einmal genauer anzuschauen. Die Ergebnisse sind beängstigend.

Ausgangspunkt der Recherche ist die empfange E-Mail-Nachricht. In dieser sind alle benötigten Informationen enthalten.

 

E-Mail Kopfinformationen

Eine E-Mail-Nachricht besteht, wie ein klassicher Brief, aus zwei Teilen. Zum einen gibt es den Umschlag, der alle Zustellinformationen, enthält, und als Zweites den Inhalt, der die lesbaren Informationen und vielleicht auch Dateianhänge für dem Empfänger bereithält.

Für eine genauere Betrachtung der E-Mail-Zustellung sind die Informationen des Umschlages, die sog. Kopfinformationen, von großem Interesse. Ich habe diese Informationen mit Hilfe des Message Header Analyzers von Microsoft in ein besser lesbares Format gebracht. Der nachfolgende Screen zeigt die wichtigsten Kopfinformationen der E-Mail:

  • Betreff
  • Absender
  • Empfänger
  • Alle an der E-Mail-Zustellung beteiligten Serversysteme
Hinweis
Aus Gründen der Vertraulichkeit sind in diesem Screenshot ausgewählte Informationen unkenntlich gemacht.

 

Screenshot - Message Header bezreg-koeln.nrw.de

Besonders interessant sind die rot umrandeten Zeilen 1 - 10. Diese Zeilen geben uns Aufschluss über alle beteiligten internen Systeme der IT.NRW, die als zentraler IT-Dienstleister für die Bezierksregierung Köln tätig ist. Die unkenntlich gemachten Textstellen beinhalten Informatioen über:

  • Computername des Applikationssystems, das für die Erstellung dieser E-Mail zuständig war
  • Computernamen und -adressen der internen E-Mail-Systeme
  • Produktnamen der intern verwendeten E-Mail-Software
  • Produktnamen der intern verwendeten Antivirus-Lösungen
  • Verbindungskette der internen E-Mail-Computersysteme inklusive lokaler Schleifen

Als eine der einfachsten Schutzfunktionen für E-Mail-Nachrichten, die an externe Empfänger gesendet werden, werden die Informationen interner Systeme aus dem Kopfinformationen der E-Mail entfernt. Hierdurch wird sichergestellt, dass keine Informationen über interne Computeradressen oder -name nach aussen gelangen. Diese Informationen lassen u.U. Rückschlüsse zu, die eine möglichen Hackerangriff begünstigen können. Moderne E-Mail-Systeme entfernen solche Informationen mit Hilfe einer Header-Firewall aus einer E-Mail.

Idealerweise hätten die Kopfinformationen mit dem grünumrandeten Eintrag aus Zeile 11 begonnen. Das dort als Submitting Host eingetragene System ist das für die externe Zustellung verantwortliche System.

Die Informationen der Zeilen 1 -10 gehören nicht in eine externe E-Mail.

Nach einem Blick auf die Kopfinformationen der E-Mail geht es mit einer Prüfung der technischen Einstellungen für die E-Mail-Kommunikation der Absenderdomäne bezreg-koeln.nrw.de weiter. 

 

MX Resource Records

Die einfachste Prüfung einer Absenderdomäne ist die Überprüfung auf E-Mail-Systeme für den Empfang von E-Mail-Nachrichten. In den meisten Fällen sind die diese Systeme auch für den Versand von Nachrichten zuständig. Wenn eine Domäne auch E-Mail-Nachrichten empfängt, muss sie über mindestens einen speziellen DNS-Eintrag verfügen. Mit Hilfe eines DNS-Eintrages vom Typ MX wird festgelegt, welche Systeme E-Mail-Nachrichten von anderen Absendern empfangen. 

Für die Überprüfung dieser Einstellungen nutze ich die Webseite mxtoolbox.com. Sie ist ein unerlässliches Werkzeug für jeden E-Mail-Administrator.

Der folgende Screenshot zeigt das Ergebnis der Überprüfung der MX-Einträge vom 6. Mai 2020.

Screenshot - MX Resource Records bezreg-koeln.nrw.de

Für die Domäne bezreg-koeln.nrw.de werden zwei Systeme mit unterschiedlicher Präferenz (Pref-Spalte) aufgeführt. Das System mit Präferenz 60 hat gegenüber dem zweiten System die höhere Priorität und wird daher bevorzugt von zustellenden Systemen angesprochen. Sollte das System nicht antworten, erfolgt ein Zustellversuch an das zweite System mit Präferenz 80.

Ein besonderes Augenmerk gilt den IP-Adressen der Systeme. In den Kopfinformationen der E-Mail hatte das sendende System die Adresse 93.184.128.152. Diese Adresse gehört zu keinem beiden aufgeführten Systeme. Damit ist klar, dass es noch weitere E-Mail-Systeme gibt, die augenscheinlich nur für den Versand verwendet werden. Aber dazu im nächsten Abschnitt mehr.

Eine weitere wichtige Information wird uns von MXToolbox ebenfalls mitgeteilt. Die Domäne verfügt über keinen DMARC-Eintrag. Was das ist und warum es gut ist, solch einen Eintrag vorzuhalten, erkläre ich weiter unten.

MX-Einträge sind für die E-Mail-Kommunikation existenziell. Neben diesem Eintragstyp gibt es noch weitere, die eine E-Mail-Kommunikation sicherer machen können. Kommen wir daher zur IP-Adresse des sendenden Systems zurück.

 

SPF Resource Records

Ein System, das E-Mail-Nachrichten empfängt, verfügt über keinerlei Informationen, welche Systeme für den Versand einer Domäne berechtigt sind. Als Eigentümer einer Domäne kann ich mit Hilfe eines SPF-Eintrages definieren, welchen Systemen es  explizit erlaubt ist, für meine Domäne E-Mail-Nachrichten zu versenden. 

Der folgende Screenshot zeigt das Ergebnis der SPF-Prüfung für die Domäne bezreg-koeln.nrw.de vom 6. Mai 2020.

Screenshot - SPF

Es ist kein SPF-Eintrag vorhanden. Empfangende E-Mail-Systeme haben keine Möglichkeit zur Überprüfung des sendenden Systems. MIt dem Fehlen dieses Eintrages wird der Versand von betrügerischen E-Mail-Nachrichten begünstigt, wenn nicht sogar wissentlich in Kauf genommen.

Das Vorhandensein eines SPF-Eintrages stellt keinen vollständigen Schutz dar. Dazu bedarf es noch weiterer Maßnahmen. Jedoch ist die Nutzung eines SPF-Eintrages seit Jahren Stand der Technik.

Moderne E-Mail-Systeme und Anti-Spam-/Anti-Mailware-Lösungen bewerten das Nichtvorhandensein eines SPF-Eintrages immerhin mit einer Erhöhung der Spam-Wahrscheinlichkeit. Dies kann u.U. dazu führen dass Nachrichten der Bezirksregierung Köln nicht im Posteingang, sondern im Junk-E-Ordner landen.

Es gibt auch Positives zu berichten.

 

PTR Resource Record

Der Name eines E-Mail-Systems ist nicht das einzige Merkmal, auf das ein empfangendes System achtet. Im Normalfall wird ein Computername zu einer numerischen Conmputeradresse aufgelöst. Es gibt aber auch das genaue Gegenteil, die sog. Rückwärtsauflösung. Das empfangende System versucht hierbei die numerische Computeradresse zu einem Namen aufzulösen. Dies erfolgt mit Hilfe eines sog. PTR-Eintrages, der im DNS des Internet-Leitungsanbieters erfolgt. Ist diese Auflösung erfolgreich und der gefundende Name entspricht dem Computernamen der Verbindung, gilt die Identität des Systems als einfach bestätigt. 

Der folgende Screenshot zeigt die Ergebnis für die IP-Adressen der beiden MX-Einträge.

Screenshot - PTR Resource Record

Beide System verfügen über einen zum Computernamen passenden PTR-Eintrag.

 

SMTP Test

Als Abschluss der aktiven Tests erfolgte eine Prüfung der E-Mail-Verbindung zu einem der beiden Systeme mit MX-Eintrag. HIer gibt es wenig Auffälliges zu berichten.

Die Nutzung von HTML-Tags (<br />) in einem Server-Banner ist unüblich und eher hinderlich. E-Mail-Server erwarten eine klare Kennung des Status und des Computernamens. In diesem Fall wird der Status 220 und der Name relay1v.it.nrw.de gleich zweimal in einer Textzeile zurückgegeben. Es wird sicherlich Systeme geben, die dies als nicht protkollkonformes Format bewerten.

Der folgende Screenshot zeigt das Ergebnis des SMTP-Tests.

Screenshot - SMTP Test

Der E-Mail-Server unterstützt verschlüsselte Verbindungen und lässt, wie die Liste der unterstützten Befehle zeigt, weitere E-Mail-Befehle erst nach dem Aufbau einer verschlüsselten Verbindung zu. Ob die Unterstützung des ETRN Befehls zeitgemäß ist, kann man diskutieren. Es wird sicherlich technische Anforderungen auf Seiten der IT.NRW geben, die dies erfordern.

Es fehlen allerdings zwei wichtige Komponenten, um E-Mail-Nachrichten der Domäne bezreg-koeln.nrw.de sicherer zu machen. DMARC und DKIM.

 

DMARC

Die zu Anfang besproche Prüfung der MX-Einträge hat gezeigt, dass kein DMARC-Eintrag vorhanden ist. Ein DMARC-Eintrag legt für eine Domäne, in diesem Fall wäre es für bezreg-koeln.nrw.de, fest, ob und wenn ja welche Informationen ein empfangender E-Mail-Server über E-Mails dieser Domäne sammeln soll. Hierdurch ist es möglich, Fehlerberichte zu erhalten und so festzustellen, welche unberechigten Systeme im Internet E-Mail-Nachrichten im Namen der Bezirksregierung Köln versenden. Solch ein Eintrag fehlt vollständig.

DMARC ist aber nur im Zusammenspiel mit SPF- und DKIM-Einträgen sinnvoll. Die Funktion und die Wichtigkeit eines SPF-Eintrages habe ich schon besprochen. Kommen wir zu DKIM.

 

DKIM

Die Aufgabe von DKIM ist Sicherstellung einer vertrauensvollen E-Mail-Zustellung. Diese Sicherstellung bezieht sich auf den E-Mail-Umschlag. Das empfangende System erkennt, dass der E-Mail-Umschlag mit Hilfe einer DKIM-Signierung gesichert wurde. Hierzu hat das Absendersystem Umschlagsinformationen mit einem Schlüssel, der nur auf dem Absendersystem exisitert, signiert. Das Empfangssystem findet den öffentlichen Schlüssel wiederum als besonderen DNS-Eintrag. Mit diesem Schlüssel können nun die Signaturinformation aufgelöst und anschließend überprüft werden. Hierdurch wird die Integrität des Absendersystems für die Domäne sichergestellt. 

DKIM selbst ist kein neuer Standard für die Sicherung von E-Mail-Nachrichten. Alle großen E-Mail-Anbieter prüfen eingehenden E-Mail-Nachrichten auf DKIM-Signaturen.

Dies ist kein Ersatz für eine mögliche und auch notwendige Verschlüsselung des E-Mail-Inhaltes. Der im Übrigen ebenfalls nicht stattfindet. 

Kommen wir zum Abschluss noch zur Verbindungsverschlüsselung.

 

SSL/TLS Test

Der folgende Screenshot zeigt das Ergebnis der Verschlüsselungsfunktionen im Hinblick auf gängige Industriestandards. 

Screenshot - SSL/TLS Test

Das Ergegbis ist in amerikanischer Notenstufe (A-F) dargestellt, wobei ein A einer Schulnote 1 entspricht. Mehr muss nicht gesagt werden.

Der Hauptgrund für die schlechte Note liegt darin, dass die E-Mail-Systeme alte und unsichere Verbindungsprotokolle und Verschlüsselungstechnologien unterstützen. Diese unsicheren Protokolle und Verschlüsselungen sollten im Jahr 2020 nicht mehr aktiv sein. 

 

Fazit

Die aktuelle Konfiguration der E-Mail-Umgebung der Bezirksregierung Köln und anderer Behörden, die diese IT-Plattform nutzen, kann durch Betrüger ausgenutzt werden. Einfachste Konfigurationen für sichere E-Mail-Kommunikation, die seit Jahren Stand der Technik sind, finden keine Anwendung. Hier wird, meiner Einschätzung nach, grobfahrlässig gehandelt. Betrügerische E-Mail-Nachrichten können ohne Probleme im Namen der Bezirksregierung Köln versendet werden. 

In der Pflicht ist nicht nur die Bezirksregierung Köln, sondern vielmehr der Landesbetrieb IT.NRW, der als zentraler IT-Dienstleister für zahlreiche Behörden und Dienststellen auftritt. Hier muss etwas passieren, um Bürger für betrügerischen E-Mail-Nachrichten, nicht nur im Zusammenhang der NRW Soforthilfe, zu schützen. Alle Behörden und Dienststellen in NRW, die auf eine sichere E-Mail-Kommunikation mit Bürgern und Unternehmen vertrauen und hierzu die Dienstleistungen der IT.NRW in Anspruch nehmen, sollten die für sie gültigen Einstellungen dringend überprüfen lassen.

E-Mail-Nachrichten der NRW Soforthilfe 2020 werden als Klartext versendet, obwohl sie persönliche Informationen enthalten und somit einem besonderen Schutzbedürfnis unterliegen. Der Einsatz einer sog. Gateway-basierten E-Mail-Verschlüsselung kann hier schnell und einfach Abhilfe schaffen. Ebenso ist die Implementierung von SPF, DKIM und DMARC Pflicht.

Ich wünsche mir, dass IT.NRW die Absicherung der E-Mail-Kommunikation ernster nimmt und ihrer Verantwortung, auch als Vorbildfunktion, nachkommt. In der heutigen Zeit vertrauen Bürger auf die IT-Sicherheit, die propagiert wird. Im Rahmen der NRW-Soforthilfe hat dieses Vertrauen sehr gelitten.

Ohne eine Verbessung der E-Mail-Sicherheit, ist dem Betrug weiterhin Tür und Tor geöffnet.

 

Links

 

 

 

Weiterlesen »
The English version of this post is published at ENow's ESE blog: Modern Authentication in Exchange Online

 

Keyboard LogoAbschaltung der Basic Authentication für Exchange Online

In ihrem Blogartikel Improving Security - Together hat die Exchange Produktgruppe angekündigt, die unsichere Authentifizierungsmethode Basic Authentication zum 13. Oktober 2020 nicht nur für die Exchange Web Services (EWS) abzuschalten, sondern zusätzlich auch für Exchange ActiveSync (EAS), POP, IMAP und Remote Exchange PowerShell.

Bei der Basic Authentication handelt es sich um eine in die Jahre gekommene Authentifizierungsmethode, die im Vergleich zu modernen Authentifizierungsmethoden Schwächen hat. Diese Schwächen führen dazu, dass diese Authentifizierungsmethode immer wieder von Angreifern verwendet wird, um unberechtigten Zugriff auf Ressourcen zu erlangen. Exchange Online und Azure AD sind, als globale Clouddienste, immens vielen Angriffen dieser Art ausgesetzt.

 

Mehr Sicherheit mit moderner Authentifizierung

Die moderne Authentifizierung (Modern Auth), basierend auf OAuth 2.0, bietet im Zusammenspiel mit Multi-Faktor-Authentifizierung (MFA) einen umfassenderen Schutz für den Zugriff auf Exchange Online und andere Cloud-Ressourcen. Diese Art der Authentifizierung ist nicht neu, setzt sich für bestimmte Zugriffsarten aber nur langsam durch. Die Unterstützung für Modern Auth wird bereits seit Office 2013 unterstützt und ist seit Version 2016 nativ in das Produkt integriert.

Für mobile Endgeräte stellt sich die Situation etwas anders dar. In vielen Fällen erfolgt der Zugriff auf Exchange Online Postfächer mit nativen E-Mail-Clients der mobilen Endgeräte statt. Diese verwenden in den meisten Fällen das ActiveSync-Protokoll (EAS). EAS wiederum bedient sich standardmäßig der Basic Authentifizierung und ist daher für die Zukunft nicht mehr das passende Protokoll für den Zugriff auf Exchange Online. Hier ist Outlook Mobile (Android/iOS) die bessere Alternative. Mit Outlook Mobile haben Sie die Möglichkeit, die Authentifizierung der Benutzerkonten zusätzlich mit MFA abzusichern.

Für die Protokolle SMTP, POP und IMAP gibt es eine besondere Herausforderungen. Diese Protokolle unterstützen heute die moderne Authentifizierung (noch) nicht. Für den Zugriff auf Mitarbeiter-Postfächer stellt dies noch keine Problem dar, da dieser Zugriff immer über das Protokoll MAPIoverHTTP erfolgen sollte. Das eigentliche Problem sind all die anderen Applikationen, die Sie gegenwärtig für einen POP/IMAP-Postfachzugriff und SMTP-Mailversand über ein Exchange Online Postfach konfiguriert haben. Hierzu gehören z.B. Ticketsysteme, ERP-Lösungen oder individuell programmierte Line-of-Business-Applikationen (LOB).

Ähnlich sieht es für die Authentifizierung von PowerShell-Skripten aus, die auf einem Ihrer internen Skript-Server ausgeführt werden und Aktionen gegen Exchange Online ausführen. Für die direkte Anmeldung an die Exchange Online PowerShell mit Modern Auth können Sie bereits heute das Exchange Online PowerShell Modul mit MFA oder die Azure Cloud Shell verwenden.

 

Was muss ich tun?

Die Deaktivierung der Basic Authentication für Exchange Online hat direkte Auswirkungen auf die von Ihnen betreute IT-Infrastruktur. Um eine Unterbrechung im Zugriff auf Exchange Online-Ressourcen zu vermeiden, müssen Sie wissen, mit welchen Protokollen Anwender und Applikationen auf Exchange Online-Endpunkte zugreifen. Die Exchange Produktgruppe plant ein Software-Tool zur Auswertung bereitzustellen, dass Sie bei der Analyse der Zugriffsarten unterstützt.

Für den Zugriff auf Exchange Postfächer von Windows Desktops ist die Maßnahme einfach. Wenn Sie noch ältere Windows Desktop Betriebssystem im Unternehmen einsetzen, wechseln Sie auf Windows 10 als Standard-Betriebssystem und migrieren Sie die Office-Installation zu Office 2019 bzw. Office 365 ProPlus.

Nutzen Sie Outlook Mobile für den Zugriff auf Exchange Online Postfächer. Outlook Mobile lässt sich über die gängigen Mobile Device Management (MDM) Lösungen zentral auf mobile Endgeräte verteilen und konfigurieren. Mit Hilfe von Mobile Application Management (MAM) und Conditional Access können Sie die Sicherheit beim mobilen Zugriff auf Exchange Online Postfächer noch weiter erhöhen.

Für automatisierte PowerShell-Skripte wird die Anpassung auf Modern Auth schwieriger. Sie können für die Ausführung der Skripte in der lokalen IT-Infrastruktur das Exchange Online PowerShell Modul mit MFA implementieren. Hierbei müssen Sie allerdings bedenken, dass Skripte mit einer längeren Ausführungszeit in technische Probleme laufen werden. Wenn Ihre Skripte von Timeouts und Skriptverzögerungen, sog. Micro Delays, betroffen sind, müssen Sie die Strategie zur Skriptausführung überdenken und den Skript-Code anpassen. Eventuell ist es vorteilhafter, eine professionelle Softwarelösung zur Ausführung von Skripten einzusetzen, die Modern Auth nativ unterstützt. PowerShell-Skripte, die nur Aktionen gegen Exchange Online oder anderen Office 365 Endpunkten ausführen, können auch in Azure Automation betrieben werden.

Wichtig ist auch noch einmal der Hinweis, dass sich die Deaktivierung der Basic Authentifizierung auf Exchange Online bezieht. Die On-Premises Variante von Exchange Server 2019 ist davon nicht betroffen.

 

Fazit

Die Exchange Produktgruppe ist sich der Herausforderungen für die Kunden bewusst. Der Titel des Original-Artikels Improving Security - Together ist mit Bedacht gewählt. Ein besserer Schutz von Exchange Online Postfächern und Ressourcen ist nur möglich, wenn die Erhöhung der Sicherheit gemeinsam, also von Ihnen als Office 365 Kunde und der Exchange Produktgruppe, umgesetzt wird.

Bereiten Sie sich und Ihre IT-Infrastruktur rechtzeitig auf die Abschaltung der Basic Authentication vor. Erstellen Sie einen realistischen Zeitplan für die notwendigen Konfigurationen und Anpassungen, um spätestens im Juli 2020 die Umstellung abgeschlossen zu haben. Es hat sich schon immer bewährt, einen zeitliche Puffer einzuplanen.

Die Erhöhung der Sicherheit geht immer mit Komfortverlust einher. Dieser Komfortverlust ist jedoch zu verschmerzen, wenn man den Sicherheitsgewinn gegenüberstellt.

 

Links

 

Viel Spaß mit Exchange Online!

Weiterlesen »

Microsoft Teams LogoMicrosoft Teams bietet zahlreiche Möglichkeiten zur Konfiguration und Kontrolle der Sicherheits- und Complianceeinstellungen. Matt Soseman, Security Architekt bei Microsoft, hat zum Thema Security & Compliance in Microsoft Teams eine Youtube Playlist erstellt.

Hier ist eine Übersicht der wichtigsten Videos:

How do I secure access to Microsoft Teams and ensure only authorized individuals can use the tool? Join us as we explore how Azure Active Directory Conditional Access and Identity Protection can provide a new level of security for Microsoft Teams.

How do I enforce policy to ensure my users cannot share sensitive data in a Microsoft Teams private chat or channel conversation? Join us as we explore how Office 365 Data Loss Prevention can block users from sharing sensitive data in Microsoft Teams – and be alerted when a violation occurs!

How do I enforce policy to ensure my users cannot copy/paste or download sensitive data out of Microsoft Teams and into a non-approved application/website? Join us as we explore how Windows Information Protection can help enforce compliance and ensure corporate data stays within Microsoft Teams or approved applications.

How do I enforce policy when a user accesses Microsoft Teams from a personal (non-managed) computer? Join us as we explore how Microsoft Cloud App Security and Azure Active Directory Conditional Access can block downloads of files in Microsoft Teams to a non-managed computer.

How can I protect my end users from malicious files that are uploaded to Microsoft Teams? Join us as we explore how the Office 365 Advanced Threat Protection Safe Attachments feature detonates files uploaded to Microsoft Teams and blocks those files from being executed.

How can I protect the Microsoft Teams app when used on a non-managed personal smartphone? Join us as we explore how Microsoft Intune Mobile Application Management capabilities allow you to control the Microsoft Teams app (and other corporate apps) and enforce compliance – all without managing the device.

How can I enforce compliance when a 3rd party storage is used in Microsoft Teams? Join us as we explore how to monitor/audit and enforce policy using Microsoft Cloud App Security on 3rd party storage in Microsoft Teams.

 

Links

 

 

Weiterlesen »
On Februar 9, 2018
2291 Views
The blog post in English has been published at ENow's Solution Engine (ESE) blog.


Die Nutzung von Office 365 Diensten erfordert eine korrekte Namensauflösung für die verwendeten Dienste. Ohne eine funktionierende Namensauflösung können Anwender aus dem Unternehmensnetzwerk oder direkt aus dem Internet nicht auf Office 365-Dienste zugreifen. Das "Finden" der Office 365-Dienste erfolgt auf Basis des Anmeldenamens des Anwenders. Dieser Anmeldename (UPN) und die Haupt-E-Mail-Adresse sind im Idealfall identisch. Die Hintergründe für diese Anforderung hat Joe Palichario bereits 2015 in seinem Blog veröffentlicht. In meinem Beispiel folgen die Anmeldenamen dem Schema Vorname.Nachname@granikoslabs.de, der ADFS Authentifizierungsserver ist unter dem Namen adfs.granikoslabs.de veröffentlicht.

Unter einer Split-DNS Konfiguration versteht man den Betrieb der DNS-Zone, in einer internen und einer externen Konfiguration. Die interne DNS-Zone wird auf DNS-Servern bereitgestellt, die von Clientsystemen aus dem Unternehmensnetzwerk angefragt werden. Die externe DNS-Zone wird entweder auf eigenen DNS-Servern, die aus dem Internet erreichbar sind, oder auf DNS-Servern eines Internet DNS-Anbieters bereitgestellt. Diese Split-DNS Aufteilung ist wichtig, um Clientsystemen entweder die interne IP-Adresse oder die öffentliche IP-Adresse eines Dienstendpunktes bereitzustellen. In einer Hybrid-Konfiguration mit Office 365 ist solch eine Split-DNS Konfiguration dringend empfohlen. Wenn Sie Office 365 im reinen Cloudbetrieb nutzen, ist diese Konfiguration nicht notwendig.

Das folgende Schaubild verdeutlicht die DNS Konfiguration für die Split-DNS Implementierung inklusive ADFS-Server und ADFS-Proxy.

Übersicht Split-DNS und ADFS mit Office 365

Ein interner Client, der auf Ressourcen von Office 365 zugreifen möchte, muss sich am internen ADFS-System authentifizieren . Hierzu wird der Client zum ADFS-Server umgeleitet.

  1. Das interne Clientsystem fragt den internen DNS-Server nach der IP-Adresse für adfs.granikoslabs.de und erhält die interne IP-Adresse des ADFS-Servers
  2. Das interne Clientsystem verbindet sich zum internen ADFS-Server, wird authentifiziert und kann, falls berechtigt, auf die gewünschte Office 365 Ressource zugreifen

Ein externer Client, der auf Ressourcen von Office 365 zugreifen möchte, muss sich ebenfalls am internen ADFS-System authentifizieren. Jedoch ist dieses System nicht direkt aus dem Internet erreichbar, sondern über einen ADFS-Proxy veröffentlicht.

  1. Das externe Clientsystem fragt den DNS-Server des Internet DNS-Anbieters nach der IP-Adresse für adfs.granikoslabs.de und erhält die öffentliche IP-Adresse des ADFS-Proxy-Servers
  2. Der externe Client verbindet sich über den ADFS-Proxy-Server mit dem internen ADFS-Server, wird authentifiziert und kann, falls berechtigt, auf die gewünschte Office 365 Ressource zugreifen

Es ist wichtig, dass neben den individuellen Adressen für die benutzerdefinierte Domäne des Office 365-Tenant auch alle weiteren, von Microsoft bereitgestellten, öffentlichen Adressen für Office 365 auflösbar sein müssen. Die öffentlichen Office 365 Endpunkte werden über CNAME, SRV und TXT Einträge in der internen und externen DNS-Zone definiert. 

Die nachfolgende Liste gibt einen Überblick der DNS-Namen für den Office 365 Tenant mit der benutzerdefinierten Domäne granikoslabs.de.

Übersicht DNS-Einträge einer benutzerdefinierten Domäne in Office 365

Die vollständige Liste der erforderlichen DNS-Namen finden Sie in der Administrationsoberflache von Office 365. Für jede benutzerdefinierte Domäne sind separate Einträge in der jeweiligen DNS-Zone erforderlich, wenn diese Domäne zur Anmeldung an Office 365 und als E-Mail Domäne verwendet wird.

Grundsätzlich unterstützt Office 365 auch eine Konfiguration, bei der der Anmeldename nicht identisch mit der primäre SMTP-Adresse oder SIP-Adresse ist. Jedoch erhöht eine solche Konfiguration den Supportaufwand im Fehlerfall und führt zu einer verwirrenden Benutzererfahrung. Auf den unterschiedlichen Anmeldeseiten der Office 365 Dienste wird der Anwender mal aufgefordert, die E-Mail-Adresse oder den Anmeldenamen einzugeben. Gleichzeitig bietet eine solch individuelle Konfiguration keinerlei Vorteile hinsichtlich der IT-Sicherheit. Eine bessere Absicherung wird vielmehr durch den Einsatz einer Multi-Faktor-Authentifizierung und Zugriffsfilterung (Conditional Access) erreicht.

Viel Spaß mit Office 365!

 

 

Weiterlesen »

Microsoft bietet unter der Adresse https://aka.ms/O365SecurityDocs einen Schnelleinstieg zu Office 365 Security & Compliance Informationen zur Verfügung. Hier finden Sie auf einen Blick die passenden Inhalte zur Absicherung Ihres Office 365 Abonnements unter Berücksichtung Ihrer Unternehmensrichtlinien und der gesetzlichen Anforderungen.

Overview of security and compliance in Office 365

Sie erhalten eine schnellen Überblick über die wichtigsten Informationen rund um die allgemeinen Security- und Compliance-Aufgaben. In den einzelnen Artikeln finden Sie weiterführende Hyperlinks, die Sie zu Schritt-für-Schritt Anleitungen führen.

Beispiel:

Protect access to data and services

Fügen Sie die Adresse https://aka.ms/O365SecurityDocs zu Ihrer persönlichen Hyperlink-Liste hinzu, um schnell auf diese Einstiegsseite zum Thema Office 365 Security & Compliance zugreifen zu können.

Sie haben weitere Fragen zu Office 365 und Cloud Sicherheit? Wir helfen gerne weiter. Kontaktieren Sie uns unter office365@granikos.eu.

 

 

Weiterlesen »