Serveradministration - Cybine Media

Dein Server braucht eine IPv6-Adresse

von Fabio Boelter | 20. Nov 2023 | Serveradministration

Themen

Wenn du Server mietest wirst du vermutlich schon mal auf sei gestoßen sein: Diese unhandlich aussehenden langen IPv6-Adressen. Wenn du diesen Blogeintrag liest ist die Wahrscheinlichkeit nicht gering, dass du dir im gleichen Moment dachtest „Wozu brauch ich das Ding eigentlich, wenn ich doch eine IPv4-Adresse habe?“.

In diesem Beitrag möchte ich dir erklären, wozu es IPv6-Adressen gibt, was man interessantes damit anstellen kann und was die Probleme dabei sind.

Was ist IPv6?

IPv6, oder Internet Protocol Version 6, ist die neueste Version des Internetprotokolls, das die Grundlage für die Adressierung und das Routing von Datenpaketen im Internet bildet. Es wurde entwickelt, um die Limitierungen von IPv4 zu überwinden, insbesondere den begrenzten Adressraum.

Erschöpfung von IPv4-Adressen

Der wichtigste Grund für den Übergang zu IPv6 ist die Erschöpfung der IPv4-Adressen. IPv4 verwendet 32-Bit-Adressen, was zu theoretisch rund 4,3 Milliarden eindeutigen Adressen führt. Angesichts des rasanten Wachstums des Internet und der ständig steigenden Anzahl von vernetzten Geräten reichen diese Adressen jedoch nicht mehr aus. Hier kommt IPv6 ins Spiel, das mit seinen 128-Bit-Adressen einen nahezu unerschöpflichen Adressraum bietet.

Zunehmende Anzahl von Geräten

In der heutigen vernetzten Welt sind nicht nur Computer und Laptops online, sondern auch Smartphones, Tablets, intelligente Haushaltsgeräte, Überwachungskameras und vieles mehr. Jedes dieser Geräte benötigt eine eindeutige IP-Adresse, um im Internet kommunizieren zu können. IPv6 ermöglicht die Zuweisung von Adressen in einem Ausmaß, das den Anforderungen der ständig wachsenden Anzahl von Geräten gerecht wird.

Verbesserte Netzwerkleistung

IPv6 bietet nicht nur eine größere Anzahl von Adressen, sondern bringt auch Verbesserungen in der Netzwerkleistung mit sich. Die Paketvermittlung und das Routing sind effizienter, was zu einer insgesamt schnelleren Datenübertragung führt. Dies ist besonders für Server von großer Bedeutung, da sie oft große Mengen an Daten verarbeiten müssen.

Bessere Sicherheit

IPv6 bietet verbesserte Sicherheitsfunktionen im Vergleich zu IPv4. Eine fortschrittliche Adresskonfiguration und integrierte Sicherheitsfeatures machen IPv6-Netzwerke robuster gegenüber potenziellen Bedrohungen. Dies ist entscheidend, um die Vertraulichkeit und Integrität der übertragenen Daten zu gewährleisten, insbesondere auf Serverebene, wo sensible Informationen verarbeitet werden.

IPsec-Integration

Auch wenn IPsec nicht mehr zwangsläufig vorgeschrieben ist, bleibt es ein integraler Bestandteil von IPv6. Die Integration von IPsec in den IPv6-Standard bietet eine eingebaute Verschlüsselung und Authentifizierung auf Netzwerkebene. Dies erhöht die Sicherheit der Kommunikation zwischen Geräten und schützt vor potenziellen Angriffen wie Man-in-the-Middle-Angriffen.

Router Advertisement (RA) Guard

RA Guard ist eine Sicherheitsfunktion, die in IPv6-Netzwerken verwendet wird, um unerwünschte oder böswillige Router-Ankündigungen zu blockieren. Dies verhindert, dass Angreifer gefälschte Router-Ankündigungen verwenden, um den Datenverkehr umzuleiten oder Angriffe wie Rogue Router-Angriffe durchzuführen.

Neighbor Discovery (ND) Spoofing Protection

ND ist ein zentrales Element von IPv6, das für die Adressauflösung, Routererkennung und -konfiguration verantwortlich ist. Spoofing-Angriffe auf ND können jedoch die Netzwerksicherheit gefährden. IPv6 implementiert Mechanismen zur Erkennung und Verhinderung von Spoofing-Angriffen, um sicherzustellen, dass die Kommunikation zwischen Nachbargeräten authentisch ist.

Zukunftssicherheit

Der Übergang zu IPv6 ist nicht nur eine kurzfristige Lösung für die Adressknappheit, sondern auch eine langfristige Investition in die Zukunft. Da IPv6 als der Standard für die Adressierung im Internet anerkannt ist, wird die Unterstützung und Kompatibilität in den kommenden Jahren weiter zunehmen.

Häufige DNS-Einträge und deren Nutzen

von Fabio Boelter | 12. Nov 2023 | Serveradministration

Themen

Heute tauchen wir tief in die Welt der DNS-Einträge ein und beleuchten, warum sie für die Funktionalität des Internets so entscheidend sind. Wir werden nicht nur die häufigsten DNS-Einträge besprechen, sondern auch ihren praktischen Nutzen verstehen.

Die Grundlagen: Was sind DNS-Einträge?

Das Domain Name System (DNS) ist das Rückgrat des Internets. Es funktioniert wie ein Telefonbuch, das Domainnamen in die zugehörigen IP-Adressen übersetzt. Ohne DNS würden wir uns statt www.example.com mit einer kryptischen IP-Adresse herumschlagen. DNS-Einträge sind die Bausteine dieses Systems und helfen dabei, Webseiten, E-Mails und andere Dienste zu finden.

Häufige DNS-Eintragstypen und ihre Bedeutung:

A-Record (IPv4-Adresse):

Der A-Record ist der grundlegende Baustein des DNS. Er verbindet eine Domain mit einer IPv4-Adresse. Stell dir vor, du gibst „blog.example.com“ ein, und der A-Record sagt dem System, dass die dazugehörige IP-Adresse „192.168.1.1“ ist.

Beispiel:

blog.example.com    IN    A    192.168.1.1

AAAA-Record (IPv6-Adresse):

Ähnlich wie der A-Record, aber für IPv6-Adressen. In einer Zeit, in der IPv6 immer wichtiger wird, gewährleistet der AAAA-Record, dass deine Domain auch mit IPv6-Adressen umgehen kann.

Beispiel:

blog.example.com    IN    AAAA    2001:0db8:85a3::8a2e:0370:7334

CNAME-Record (Alias):

Der CNAME-Record erstellt eine Alias-Verknüpfung zwischen zwei Domains. Das ist besonders praktisch, wenn du mehrere Domains auf denselben Server verweisen möchtest, ohne mehrere A-Records pflegen zu müssen.

Beispiel:

www.example.com    IN    CNAME    blog.example.com

MX-Record (Mail Exchange):

Der MX-Record ist entscheidend für den E-Mail-Verkehr. Er gibt an, welcher Mailserver für die Domain zuständig ist. Ohne ihn würden E-Mails im Nirgendwo landen.

Beispiel:

example.com    IN    MX    10    mail.example.com

Spezielle DNS-Einträge und ihre Anwendungen:

TXT-Record (Text):

Der TXT-Record fügt Textinformationen zu einer Domain hinzu. Das wird oft für SPF und DKIM genutzt, um die Authentizität von E-Mails zu überprüfen. Ein wichtiger Schutzmechanismus gegen Spam und Phishing. Wenn du mehr darüber erfahren möchtest, schau doch mal in unseren Beitrag zum Thema Mail-Sicherheit auf der eigenen Domain.

Beispiel:

example.com    IN    TXT    "v=spf1 include:_spf.example.com ~all"

SRV-Record (Service):

Der SRV-Record gibt Informationen über verfügbare Dienste in einer Domain preis. Wenn du Dienste wie SIP oder XMPP nutzt, hilft dir der SRV-Record, die entsprechenden Server zu finden.

Beispiel:

_sip._tcp.example.com    IN    SRV    10    60    5060    sipserver.example.com

PTR-Record (Pointer):

Der PTR-Record wird für Reverse-DNS-Lookups verwendet. Stell dir vor, du hast eine IP-Adresse und möchtest den dazugehörigen Domainnamen herausfinden. Der PTR-Record macht das möglich.

Beispiel:

1.1.168.192.in-addr.arpa    IN    PTR    server.example.com

Warum sind diese Einträge so wichtig?

Jetzt, da wir die verschiedenen DNS-Einträge kennen, stellt sich die Frage: Warum sind sie so entscheidend? Hier sind einige Gründe:

Effiziente Kommunikation:

DNS-Einträge ermöglichen es, dass wir mit menschenfreundlichen Domainnamen anstelle von komplexen IP-Adressen arbeiten. Das macht die Internetnutzung für uns alle angenehmer.

Flexibilität und Skalierbarkeit:

CNAME- und MX-Records bieten Flexibilität, indem sie Aliase und Mailserverdienste auf verschiedene Server verweisen können. Das ist besonders wichtig in komplexen IT-Infrastrukturen.

Sicherheit und Vertrauen:

TXT-, SPF- und DKIM-Records tragen dazu bei, die Sicherheit von E-Mails zu gewährleisten. Durch die Überprüfung der Absenderidentität wird Spam und Phishing effektiv bekämpft.

Diensteverfügbarkeit:

SRV-Records sind für Dienste wie VoIP und Instant Messaging unerlässlich. Sie stellen sicher, dass Clients die richtigen Server für diese Dienste finden können.

Tipps

Regelmäßige Überprüfung:

Stelle sicher, dass die DNS-Einträge deiner Domains regelmäßig überprüft werden. Änderungen an Servern oder Diensten erfordern oft entsprechende Anpassungen in den DNS-Einstellungen.

Dokumentation:

Halte eine detaillierte Dokumentation über deine DNS-Konfiguration. Das erleichtert nicht nur die Wartung, sondern auch die Fehlerbehebung im Falle von Problemen.

Sicherheit im Auge behalten:

Nutze TXT-Records, SPF und DKIM, um die Sicherheit deines E-Mail-Verkehrs zu stärken. Die Verhinderung von Spoofing und Phishing ist entscheidend.

Absicherung deines SSH-Servers

von Fabio Boelter | 9. Mrz 2023 | Serveradministration

Themen

Ein Fernzugang gehört zu jedem Server dazu. Unter Linux wird hierfür meist ein SSH-Server genutzt. Um einen ersten Zugriff zum Server zu bekommen, werden während der Installation einige Grundeinstellungen vorgenommen, die später für einen sicheren Betrieb verändert werden sollten.

Wir zeigen dir einige dieser Einstellungen, mit denen du Angreifern ihre Arbeit erschweren kannst.

Warum keine Standardeinstellungen?

Um den Bedürfnissen möglichst vieler Nutzer entgegenzukommen, bieten viele Softwarelösungen unter Linux eine Vielzahl an Einstellungen. Diese Einstellungen ermöglichen es z.B. viele Anwendungen, die eine Authentifizierung brauchen, an Drittsysteme anzubinden. Um dem Standardnutzer eines Systems dennoch gerecht werden zu können und um die Abhängigkeiten von Drittsystemen gering zu halten, geben die Entwickler der Softwarelösungen eine Standardkonfiguration vor.

Wir haben also eine allgemein bekannte Konfiguration der Software – das bringt für uns sowohl Vor-, aber auch Nachteile mit sich. Wir gehen einmal einige Punkte anhand des SSH-Servers durch.

Zunächst haben wir natürlich den Vorteil, dass wir uns bei großen Softwarelösungen wenig darum Sorgen müssen, dass wir selbst ständig nach den aktuell sicheren Verschlüsselungsalgorithmen suchen müssen, um eine sichere Verbindung zu gewähleisten, da sich die Entwickler bereits mit dieser Aufgabe beschäftigen. Außerdem können wir sichergehen, dass wir die Software direkt nach der Installation ohne weiteres Schritte bereits nutzen können.

Um diese allgemeine Nutzbarkeit allerdings gewährleisten zu können, werden im SSH-Server zunächst alle regulären Nutzer und der Root-User berechtigt sich mit dem hinterlegten Passwort anzumelden.

Jetzt fragst du dich vielleicht „Warum sollte das ein Problem sein? Solange ich ein sicheres Passwort nutze passt doch alles.“ Grundsätzlich möchte ich dir zunächst Recht geben, wir stellen mit der Standardeinstellung kein offenes Tor, um den Server zu manipulieren. Dennoch haben wir aktuell keine Mechanismen, die es unterbinden mehrere hundert oder noch mehr Passwörter pro Minute auszuprobieren. Dazu geben wir dem potenziellen Angreifer noch eine allgemein bekannte Nutzerkennung – den Root-Account – und schon sieht das Konstrukt gar nicht mehr so sicher aus.

Einstellungsänderungen

Um die Konfigurationsänderungen vornehmen zu können, musst du auf dem System mit den Berechtigungen des Root Accounts agieren. Der einfachste Weg hierfür ist, als Root angemeldet zu sein.

Einige der folgenden Punkte können dazu führen, dass du den Zugang zu deinem Server verlierst. Lese dir die einzelnen Punkte daher bitte bis zum Ende durch, wenn du sie umsetzen willst.

Root Zugang blockieren

Lass uns gleich zu Anfang die Anzahl der zu erratenen Komponenten für einen Login erhöhen und den direkten Zugriff auf den Root Account über eine SSH-Verbindung verbieten.

Stelle für diesen Schritt umbedingt vorher sicher, dass du einen weiteren Account auf dem System hast, über den du dich anstelle des Root Accounts anmelden kannst. Du kannst später mit dem Befehl su root - von deinem auf den Root Account welchseln.

Solltest du noch keinen anderen Account haben, kannst du dir auf Debian ähnlichen Distributionen mit dem Befehl adduser <Nutzername> einen weiteren Account auf dem System erstellen.

In der Konfigurationsdatei /etc/ssh/sshd_config suchst du hier nach einer Zeile, in der PermitRootLogin steht. Vermutlich steht bei dir vor dem Namen der Einstellung noch ein # Zeichen. Dieses sorgt dafür, dass die Zeile nicht beachtet wird. Somit entfernen kannst du das erstmal entfernen. Außerdem kannst du den Wert hier auf no ändern.

Port ändern

SSH-Server hören standardmäßig auf Port 22. Da SSH ein Management-Tool für Server ist, versuchen die meisten Angreifer an eben diesen Port ihre Anfragen zu senden. Um dem entgegenzuwirken, ändern wir in diesem Schritt den Port des SSH-Servers.

Stelle für diesen Schritt umbedingt vorher sicher, dass der Port den du wählst erreichbar ist. Prüfe hierfür die Firewall-Einstellungen deines Servers bzw. deines Anbieters.

In der Konfigurationsdatei /etc/ssh/sshd_config suchst du hier nach einer Zeile, in der Port steht. Vermutlich steht bei dir vor dem Namen der Einstellung noch ein # Zeichen. Dieses sorgt dafür, dass die Zeile nicht beachtet wird. Somit entfernen kannst du das erstmal entfernen. Außerdem kannst du den Wert hier auf eine Zahl zwischen 1024 und 49151 ändern. Die vor dir hier hinterlegte Zahl ist der Port auf dem dein SSH-Server später erreichbar sein wird.

Passwort-Login blockieren

Die überwiegende Anzahl der Angriffe auf einen SSH-Server basieren auf dem Ausprobieren von Kombinationen aus Nutername und Passwort. Was liegt also näher, als den Login mittels dieser Kombinationen generell einfach abzuschalten?

Für diesen Schritt musst du zuvor den Login über eine andere Methode eingerichtet haben. Eine dieser Methoden ist der Login mittels Nutername und SSH-Key.

Um den Login mit deinem Passwort zu deaktiveren, kannst du in der Konfigurationsdatei /etc/ssh/sshd_config nach der Einstellung PasswordAuthentication suchen. Entferne das # vor der Einstellung, falls hier noch eins sein sollte und setze den Wert auf no.

Anwenden der Einstellungen

Vor dem Anwenden der Einstellungen solltest du sie einmal prüfen lassen. Das kannst du mit dem Befehl sshd -t machen. Solltest du hier keine Meldung bekommen, hast du alles richtig gemacht. Andernfalls schaue dir die angegebene Zeile nochmals an. Vermutlich hast du dich dort verschrieben.

Nach der Prüfung kannst du die Einstellungen mit dem Befehl service sshd reload übernehmen. Danach sind alle Änderungen, die du zuvor in der Konfiguration geändert hast aktiv.

Prüfe anschließend noch einmal, ob du dich mit einer weiteren Verbindung jetzt wie erwartet auf deinen Server verbinden kannst. Sollte etwas nicht funktionieren, kannst du die Einstellungen nochmals über die noch aktive Verbindung ändern.

Rate-Limiting

Mittels Rate-Limiting kann die Anzahl an Anmeldeversuchen in einem Zeitraum beschränkt werden. Für die Umsetzung der erforderlichen Sperren gibt es zwei Möglichkeiten – Sperrung auf Nutzerbasis und Sperrung auf IP-Address-Basis.

Vom Grundsatz hört sich Rate-Limiting erstmal gut an und es kann die Sicherheit des Servers auch weiter verbessern, jedoch gibt es hier auch einige Nachteile, die aus meiner Sicht überwiegen.

Bei der Sperrung auf Nutzerbasis wird die Anzahl der versuchten Logins für einen Nutzer des Systems gezählt. Überschreitet diese Anzahl einen Schwellwert, werden weitere Loginversuche für diesen Nutzer für eine vordefinierte Zeit blockiert. Somit kann dieser Ansatz dafür ausgenutzt werden, um dich selbst aus deinem System auszusperren, wenn dein Nutzername auf dem System bekannt ist.

Bei der Sperrung auf IP-Address-Basis wird die Anzahl der versuchten Logins von einer IP-Adresse gezählt. Hier werden Logins von einer IP-Addresse geblockt, wenn die Loginversuche einen Schwellwert überschreiten. Bei diesem Ansatz gibt es gleich zwei Probleme. Einerseits kann es sein, dass du dir mit einer Vielzahl von anderen Personen die gleiche ausgehende IP teilst, was dafür sorgen kann, dass diese Personen dir potenziell den Zugang zu deinem Server an diesem Ort sperren können. Andererseits bietet diese Möglichkeit aber auch einen geringeren Schutz, da Angreifer meist mehrere IP-Addressen nutzen, um Login-Kombinationen auszuprobieren, was diesen Ansatz nutzlos macht.

Solltest du dennoch Rate-Limiting auf deinem Server einrichten wollen, kannst du dir Tools, wie fail2ban anschauen.

Fazit

Meist kommt es nicht darauf an, eine nahezu perfekte Sicherheit auf seinen Servern zu implementieren, sondern einfach nur ein Bisschen besser zu sein als der Rest. Mit nur wenigen Einstellungen kannst du einen der wichtigsten Zugangspunkte zu deinem Server nach deinen Bedürfnissen absichern und dich dadurch vom Standard abheben.

Die Liste der Einstellungen ist keines Falls vollstängig und nur eine Auswahl, die ich auf meinen eigenen Servern anwende.

Weitere Links

Wichtige Einstellungen für deine neue Domain

von Fabio Boelter | 7. Jan 2023 | Serveradministration

Themen

Du hast eine neue Domain registriert oder zu einem Hostingangebot dazubekommen und deinen Server schon hinterlegt. So weit so gut oder? – Nicht so ganz, denn bei einer Domain gibt es mehr zu beachten, als auf den ersten Blick sichtbar ist.

In diesem Beitrag möchte ich dir ein paar Tipps geben, was du bei der Einrichtung von deiner Domain beachten solltest, um später keine ungewollten Überraschungen zu erleben.

Zertifikatsaustellung

Die Erstellung eines SSL-Zertifikats für deine Webseite ist eine Möglichkeiten, die dir deine Domain bietet und aufgrund der starken Verbreitung auch vielen bekannt. Wenn du ein Webhostingangebot beziehst wird dir dein Hoster vermutlich irgendwo in der Verwaltung eine Funktion bieten, um automatisch ein derartiges Zertifikat zu erstellen.

Der Nutzen eines SSL-Zertifikats ist neben der beruhigenden Wirkung auf die Besucher deiner Seite die Bestätigung der Identität einer Webseite und die Verschlüsselung der übertragenen Daten. Bei den meisten Seiten kannst du in deinem Browser links neben der Addresszeile ein Schloss (nicht durchgestrichenes) sehen, das symbolisiert, dass ein gültiges Zertifikat für die Seite hinterlegt wurde.

Um ein Zertifikat zu bekommen gibt es mehrere Möglichkeiten. Zum Einen gibt es einige Dienstleister, bei denen du gegen ein Entgelt von einigen Euros eine manuelle Überprüfung und Ausstellung beantragen kannst – zum Anderen gibt es Plattformen, wie Let’s Encrypt, die dir automatisiert in wenigen Sekunden ein kostenloses Zertifikat bereitstellen.

Die Unterschiede halten sich jedoch in Grenzen, so kostet dich der eine Weg offentlichlich Geld während der andere kostenlos ist. Aus technischer Sicht bekommst du für dein Geld ein wenig Komfort geboten, denn Zertifikate von Let’s Encrypt müssen alle 3 Monate erneuert werden, während andere Anbieter dir die Zertifikate meist für ein oder mehrere Jahre ausstellen. Dann wären da noch die höherpreisigen Zertifikate, die neben dem Schloss auch noch die Anzeige eines Unternehmensnamens in der Addresszeile ermöglichen. Diese kannst du nicht über Let’s Encrypt beziehen, da sie weitere nicht automatisierbare Prüfungen erfordern, doch du wirst vermutlich kein solches Zertifikat brauchen, da es neben der Anzeige keinen anderen Mehrwert bietet.

Solltest du deinen Webserver vollständig selbst verwalten, gibt es bereits zahlreiche Anleitungen für die verschiedenen Softwarelösungen, die die Schritte zum hinterlegen des Zertifikats erklären. Suche dafür einfach nach dem Namen der Software und „SSL-Zertifikat hinterlegen“. Wenn du dein Zertifikat von Let’s Encrypt beziehen möchtest füge der Anfrage noch entweder „Certbot“ oder „acme.sh“ hinzu. Das sind beides Programme, die dir mit sehr geringem Aufwand die Interaktion mit Let’s Encrypt ermöglichen und auch eine Möglichkeit zur automatisierten Erneuerung bieten, sodass du dir nach einmaliger Einrichtung keine Gedanken mehr um das Thema machen musst.

Natürlich überprüft auch Let’s Encrypt, dass du berechtigt bist ein Zertifikat für eine bestimmte Domain zu beziehen. Dafür kann entweder eine auf dem Server hinterlegte Datei genutzt werden oder ein Eintrag im DNS deiner Domain. Darum solltest du aufpassen, dass sowohl auf deinen Webspace, als auch auf die Einstellungen deiner Domain nur vertrauenswürdige Personen Zugriff haben, da sie sonst in begrenztem Maße verifizierte Seiten im Namen deiner Domain erstellen können.

Mailversand einschränken

Da die Einrichtung eines eigenen Mailservers doch verhältnismäßig aufwenig ist, sind die folgenden Maßnahmen eher unbekannt, was sie aber nicht unwichtig macht. Um dir einen kurzen Überblick über die Notwendigkeit zu geben – die folgenden Einstellungen schränken die Möglichkeiten unbekannter Dritter ein Mails im Namen deiner Domain zu verschicken und so die Reputation deiner Domain zu wahren.

Hier gibt es drei wichtige Einstellungen, die du in den DNS-Einträgen deiner Domain standardmäßig hinterlegen solltest. Diese Einstellungen sollen zunächst generell verhindern, dass Mails, die im Namen deiner Domain versandt werden, von Mailservern als legitim angesehen werden. Solltest du Mails von deiner Domain versenden wollten, guck dir doch mal unseren Beitrag zur genaueren Einstellung dieser Werte an.

Um die Einstellungen zu hinterlegen, gehst du in die Domainverwaltung deines Anbieters und hinterlegst folgende Einträge mit dem Typ „TXT“:

Subdomain: [keine] 
Inhalt: v=spf1 -all

Subdomain: *._domainkey
Inhalt: v=DKIM1; p=

Subdomain: _dmarc
Inhalt: v=DMARC1; p=reject; adkim=s; aspf=s;

Fazit

Das Betreiben einer eigenen Domain ist nicht schwer, jedoch sollte man einige wenige Sachen beachten, um später keinem der zuvor erwähnten Probleme zu begegnen.

Diese Liste ist keinesfalls vollständig, sondern nur eine Auswahl von wichtigen Punkten, die mir zum Zeitpunkt der Erstellung des Beitrags eingefallen sind.

Weitere Links

Mail-Sicherheit auf der eigenen Domain

von Fabio Boelter | 25. Nov 2022 | Serveradministration

Themen

Häufig lese ich, dass man lieber einen etablierten Mailprovider nutzen soll, statt sich selbst einen zusammenzubauen. Es gäbe zu viele Fallstricke, die man hier beachten müsse. Doch die ersten Schritte, um den Mailverkehr der eigenen Domain abzusichern beginnen schon viel früher, als beim eigenen Mailserver. Hat dein Anbieter, bei dem du deine Domain beziehst darauf hingewiesen, dass du direkt grundlegende Einstellungen für den Mailversand festlegen kannst? Das ist leider eher selten der Fall und plötzlich werden Mails scheinbar in deinem Namen versendet.

In diesem Beitrag möchte ich dir anschaulich erklären, welche Maßnahmen du bei deiner Domain ergreifen solltest – egal, ob du einen eigenen Mailserver betreibst oder ein externes Hostingangebot in Anspruch nimmst.

Überblick über das Problem

Im Grundsatz können wir einige Konzepte aus dem realen Leben auch auf den Mailtransfer anwenden. Beispielsweise könnte ich mich dir bei unserer ersten Begegnung als Anton Müller aus Berlin vorstellen – du würdest mir das vermutlich abnehmen, schließlich hast du keinen Grund mir in der Hinsicht zu misstrauen.

Jetzt überlege mal, wann du mir misstrauen würdest. – Entweder irgendjemand hat mich dir schon anders vorgestellt, sprich du weißt schon, dass ich jemand anders bin oder ich hab dir z.B. gleichzeitig ein Dokument von mir gegeben, wo etwas anderes draufsteht (irgendwo etwas weit hergeholt, aber es erfüllt seinen Zweck).

Bei Mailservern funktioniert das etwa gleich. Der sendende Mailserver kann sich erstmal als irgendjemand ausgeben, außer man teilt dem empfangenden Mailserver irgendwie mit, dass da etwas nicht stimmen könnte. Und eben diese Information wollen wir bereitstellen. Dazu können wir in den DNS-Einträgen deiner Domain – einer Art Telefonbuch für das Internet – hinterlegen, welche Server mit deiner Domain Mails versenden dürfen.

Auch, wenn du es aktuell vielleicht nicht für sinnvoll halten solltest etwas dagegen zu unternehmen, weil du eh nicht vorhast mit der Domain Mails zu versenden, solltest du es dennoch tun. Einer der Gründe dafür ist, dass moderne Spamfilter mitlernen. Sollte jetzt also jemand deine Domain missbrauchen um Spammails zu verschicken und diese werden immer wieder als solche erkannt, kann es dir später passieren, wenn du dich doch umentscheidest, dass du keine wirkliche Chance mehr hast diesen Status als vermeintlicher Spammer loszuwerden.

Verfügbare Sicherheitsmechanismen

Es gibt im Bereich der Sicherheitsmechanismen für Mails 3 große Vertreter – SPF, DKIM und DMARC. Das wird dir jetzt vermutlich nicht viel sagen, darum erkläre ich sie mal.

SPF (Sender Policy Framework)

Ein SPF-Eintrag ermöglicht dir die Einschränkung des Mailversands auf bestimmte IP-Adressen – sprich hier kannst du festlegen, welche Server Mails im Namen deiner Domain versenden dürfen. Das ist die bekannteste Methode der drei und wird am häufigsten eingerichtet.

Leider hat dieser Eintrag auch ein kleines Problem: Werden die Mails z.B. an einen Server gesendet, der die Mails nur weiterleitet, wird dieser Weiterleitungsserver vom empfangenden Server als Sender angesehen. Dadurch kann es bei Unstimmigkeiten mit dem Eintrag dazu kommen, dass diene Mails als Spam angesehen werden, obwohl sie ursprünglich wirklich von dir stammen.

Ein SPF-Eintrag wird auf der betroffenen Subdomain oder auf der ersten Ebene angelegt und beginnt mit der Einstellung v=spf1. Danach kann er mit Leerzeichen getrennt um Einstellungen beliebig erweitert werden.

folgenden Einstellungen erfordern einen Präfix:

Einstellung	Erklärung	Beispiele
`a`	Betrifft alle IP-Adressen, für die ein A-Eintrag bei der aktuellen bzw. angegebenen Domain existiert	`+a` `+a:example.com`
`mx`	Betrifft alle IP-Adressen, für die ein MX-Eintrag bei der aktuellen bzw. angegebenen Domain existiert	`+mx` `+mx:example.com`
`ip4`	Betrifft eine einzelne IPv4-Adresse bzw. einen Netzbereich	`+ip4:192.168.0.1` `+ip4:192.168.0.0/24`
`ip6`	Betrifft eine einzelne IPv6-Adresse bzw. einen Netzbereich	`+ip6:fd42:42:42::1` `+ip6:fd42:42:42::/64`
`all`	Alle nicht näher definierten Quellen	`?all`

SPF-Record – Einstellungen mit Präfix

Präfix	Erklärung
+	Einstellungen mit diesem Präfix werden als gültig angesehen und immer akzeptiert. (Kein Präfix bedeutet automatisch +)
?	Einstellungen mit diesem Präfix werden neutral behandelt und immer angenommen.
~	Einstellungen mit diesem Präfix werden als fehlerhaft angesehen. Da es sich eigentlich um eine Präfix zum testen handelt werden die Mails in der Regel akzeptiert, aber der Check „softfail“ markiert.
–	Einstellungen mit diesem Präfix werden als fehlerhaft angesehen und Mails je nach weiterer Einstellung verworfen oder als Spam markiert.

SPF-Record – Verfügbare Präfixe

Die folgenden Einstellungen erfordern keinen Präfix:

Einstellung	Erklärung	Beispiel
`redirect`	Kann anstelle von einer `all`-Einstellung verwendet werden, um auf einen anderen Eintrag zu verweisen. Muss als letzte Einstellung definiert werden.	`redirect=_spf.example.com`
`include`	Ermöglicht die Einbindung von SPF-Einträgen anderer Domains	`include:example.com`
`exists`	Ermöglicht die Verwendung komplexer Ausdrücke	`exists:%{ir}.%{l1r+-}._spf.%{d}`

SPF-Record – Einstellungen ohne Präfix

DKIM (DomainKeys Identified Mail)

Ein DKIM-Eintrag ermöglicht dir einen sogenannten öffentlichen Schlüssel für deinen Mailversand zu hinterlegen. Dieser wird vom empfangenden Server genutzt, um eine Art Unterschrift des sendenden Servers kryptographisch zu prüfen und hilft dabei sicherzustellen, dass der Inhalt der Mail nicht modifiziert wurde. Einen solchen Eintrag kannst du mehrfach unter anderen Identifikationen (identifier) anlegen, um z.B. mehrere Mailprovider zu autorisieren.

Es ist zwar schön, dass unsere Mails dadurch nicht nicht verändert werden können, aber an sich verhindert es leider nicht den Versand von nicht autorisierten Servern. Dafür kommt der dritte Mechanismus ins Spiel.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Wie der Name des Mechanismus schon verlauten lässt, können mit einem DMARC-Eintrag Regeln festgelegt werden, die bestimmen, wie ein Mailserver bei Verstößen gegen den SPF- und DKIM-Eintrag vorzugehen hat. An dieser Stelle kannst du letztendlich festlegen, ob eine Mail angenommen oder abgelehnt werden soll. Nur nicht in ganz so schwarz oder weiß wie es jetzt gerade klingt. Aber dazu mehr bei der Einrichtung.

Ein DMARC-Eintrag wird auf der Subdomain _dmarc angelegt und beginnt mit der Einstellung v=DMARC1. Danach kann er mit Semikolon und Leerzeichen getrennt um Einstellungen erweitert werden.

Die folgenden Einstellungen stehen zur Verfügung:

`adkim`	Legt fest, wie genau der DKIM-Eintrag geprüft wird. Standard: `r` r = relaxed \| Subdomains werden akzeptiert s = strict \| Domain muss genau übereinstimmen	`adkim=s`
`aspf`	Legt fest, wie genau der SPF-Eintrag geprüft wird. Standard: `r` r = relaxed \| Subdomains werden akzeptiert s = strict \| Domain muss genau übereinstimmen	`aspf=r`
`fo`	Legt fest wann Infos an ruf-Adresse gesendet werden sollen. Standard: `0` `0` \| Wenn alle Checks fehlschlagen `1` \| Wenn irgendein Check fehlschlägt `d` \| Wenn DKIM Check fehlschlägt `s` \| Wenn SPF Check fehlschlägt	`fo=1`
`p`	Legt fest wie mit fehlschlagenden Checks umgegangen werden soll. Einstellung muss gesetzt werden `none` \| Keine weitere Aktion – Mail annehmen `quarantine` \| Mail als potenziellen Spam markieren `reject` \| Mail ablehen	`p=reject`
`pct`	Legt fest wie viel Prozent der eingehenden Mails überprüft werden sollen. Standard: `100` Ganzzahl zwischen `0` und `100`	`pct=100`
`rua`	Legt fest wohin Zusammenfassungen geschickt werden sollen.	`rua=mailto:` `info@cybine.de`
`ruf`	Legt fest wohin detaillierte Infos geschickt werden sollen. Wird aufgrund von Datenschutzbedenken selten Infos erhalten.	`ruf=mailto:` `info@cybine.de`
`sp`	Legt fest wie auf Subdomains mit fehlschlagenden Check umgegangen werden soll. Standard: Einstellung von `p` `none` \| Keine weitere Aktion – Mail annehmen `quarantine` \| Mail als potenziellen Spam markieren `reject` \| Mail ablehen	`sp=reject`

DMARC-Eintrag – Einstellungen

Schritt für Schritt zur abgesicherten Domain

Ab hier kommt es darauf an, was du mit deiner Domain machen willst. Ich stelle dir grundsätzlich vor, wie du die entsprechenden Einträge anlegen kannst – die einzelnen Einstellungen hängen aber von dir ab. Eine Erklärung der einzelnen Einstellungen findest du bei den Vorstellungen der Sicherheitsmechanismen.

Alle folgenden Einträge sind sogenannte TXT-Einträge. Da es sehr viele Anbieter gibt, kann ich nicht für jedes Interface eine Anleitung bereitstellen. Wie du die Einträge bei deinem Anbieter hinterlegen kannst, solltest du in der Dokumentation des Anbieters finden.

Erstellung SPF-Eintrag

Unser SPF-Eintrag legt hier fest, dass wir Mails von einer unserer in der Domain hinterlegten IP-Adressen akzeptieren wollen. In der Regel reicht es hier die A-Records und MX-Records zu hinterlegen. Solltest du dir unsicher sein, ob dadurch nicht zu viele Server eine Sendeberechtigung bekommen, kannst du auch wie oben beschrieben den +a und +mx Teil gegen einen IP-Eintrag tauschen.

Subdomain: [keine] 
Inhalt: v=spf1 +a +mx ~all

Solltest du bei deinem Anbieter die Möglichkeit haben einen DKIM-Eintrag anzulegen, kannst du auch folgenden Eintrag hinterlegen. Dieser wirft potenziell bei Mailweiterleitungen (wie weiter oben beschrieben) nochmal weniger Probleme auf.

Subdomain: [keine] Inhalt: v=spf1 +a +mx ?all

Erstellung DKIM-Eintrag

An dieser Stelle muss ich dich leider auf die Dokumentation deines Providers weiterleiten, da der Prozess für das Hinterlegen des serverseitigen Bestandteils für diesen Eintrag bei jedem Provider anders ist. Du solltest irgendwo im FAQ deines Anbieters etwas finden, wenn du nach DKIM suchst.

Wichtig an dieser Stelle ist, dass alle deine Quellen, von denen du Mails versendest, diesen Schritt unterstützen müssen. Sollte auch schon nur einer deiner Provider das nicht unterstützen, wird dir die Einstellung mehr schaden als helfen, da die Mails von nicht autorisierten Mailservern mit hoher Wahrscheinlichkeit im Spam landen.

Es gibt leider auch einige Anbieter, die in ihrer Produktbeschreibung mit DKIM-Validierung werben und damit den Anschein machen, dass sie DKIM unterstützen. Die Validierung hat jedoch nichts mit dem Anlegen des Eintrags für dich zu tun. Solltest du einen Anbieter haben, bei dem du für deine Mails keine DKIM-Einstellungen vornehmen kannst, würde ich dir nahelegen dich eventuell nach einem anderen Anbieter umzuschauen der DKIM-Signierung unterstützt.

Solltest du deinen Server selbst vollständig verwalten findest du unten in den Links einen Guide (Eigenen Mailserver einrichten), der den Prozess ganz gut erklärt.

Der Eintrag in deiner Domain müsste etwa so aussehen:

Subdomain: [identifier]._domainkey
Inhalt: v=DKIM1; h=sha256; k=rsa; s=email; p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA0rw59vhi2JGYr4gQXJC7mj8hKHucRB6CQvMd5pYDqTMmT5eyVoPMNJceXU1+waHP0CLg1KZwayjVgv3Nnu0lQf02QHzer83uKoIKA1rRo9pwtXaAcGOf4UtzCgSRz+f3EccWVWFxuFvDXkUyCXMCZzXtu8vqLMdsARczM6SM/Ah/3YUclaOnFWe0RSaBRweBziy2QzxzH7cugNhqlKF4xoeV32RtL8/IURhdDU3U6WcW9w9NbsO6a0ODG8YJfUQdZN5K7tw7y+mZPtahaT+2nKnT4HjYBLdt6aEDNV3qcNOn8xwR4BUJ4dR/gZWfW4UQ9rP7KLVB4joYn3/OGO1UrdZzx64FfsvBd0LepG4jtiI7pQu1suakwYKFhAboAjUm63nATA4giSt27Q3/WLi1J1pjnZAjWQdScEPVz4L/2cV8uOsfckeYbbbEiGPDvY5Q5zC/ZKytTzG1K+0XjeC5e93+rFBXGLwls7ZVLhDcC8NwvjrWai8reX+gIFQHEhxbar81gCX8owtP/dt9cTf2DNrHYITsDvB8JBd8J6RwogoOu+d6VldljTu/X8KeFgVDZxces6k7DW1kLuysjyGWinFzNWdLFyiVA4jzNq/Js8paXz2QKukZZd22N8xK+nWmjdSNqFV7E37EZnYqtePYsXL5Wz+qFozM7gd4f4n4b1kCAwEAAQ==

Erstellung DMARC-Eintrag

Mit dem DMARC-Eintrag legen wir jetzt final fest, wie mit Mails von deiner Domain umgegangen werden soll. Die Erklärungen zu den einzelnen Einstellungen findest du weiter oben im Beitrag.

Subdomain: _dmarc
Inhalt: v=DMARC1; p=quarantine; rua=mailto:postmaster@deine.domain; pct=100; sp=reject; adkim=s; aspf=r

Bei diesem Eintrag musst du nur noch die rua-Adresse auf deine Mailadresse anpassen und entscheiden, welchen Wert du für die p-Einstellung haben willst. Prinzipiell ist es sicherer hier mit reject zu gehen. Sollten sich jedoch Fehler in deiner Konfiguration eingeschlichen haben, werden deine Empfänger deine Mails nicht mal zugestellt bekommen. Daher ist es hier zum testen empfehlenswert vorerst auf quarantine zu bleiben.

Abschließende Tests

Wenn du jetzt alles eingerichtet hast, ist es noch wichtig die ganze Konfiguration zu testen. Sende dir dafür am besten selbst Mails an eine andere Plattform. Solltest du hierfür eine Empfängeradresse wählen, mit der du bereits geschrieben hast, bedenke, dass Mailserver mitlernen und ggf. Mails die eigentlich als Spam markiert würden, durch den zuvor gehenden Mailverkehr im normalen Posteingang landen.