Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt. Der Nachfolger ist Nextcloud. Mozilla Sync wurde ebenfalls eingestellt — Firefox synchronisiert über Firefox Accounts.
Wem kann man schon trauen? Richtig, niemandem! Man kann also nur das geringste Übel wählen… Im Moment vertraue ich dem Mozilla Browser mehr als dem Google-Browser. Die Browser über verschiedene Geräte und Platformen zu synchronisieren ist eine wunderbare Erleichterung. Nur damit diese Daten immer auf allen Geräte gleichermaßen zur Verfügung stehen müssen sie an einem zentralen Ort vorgehalten werden. Nun habe ich verständlicherweise ein Problem damit diese Daten einfach auf irgendeinen Server, irgendwo in der Welt zu packen. Ich meine… Das sind meine Browserdaten und damit ebenfalls die gespeicherten Kennwörter, meine Leserzeichen, wo ich herumsurfe usw. usw…. OK, die Daten werden dort verschlüsselt abgelegt. Es hinterlässt denn noch ein unangenehmes Gefühl.
Zum Glück gibt es eine Möglichkeit die Daten einfach mit in die ownCloud zu werfen. Einfach als Admin die App „Mozilla Sync“ aktivieren. Schon lässt sich im Firefox die Verbindung zu einem eigenen Server einstellen. Weitere Geräte werden dann so verbunden als wenn man den Mozilla Server nutzen würde.
Lange habe ich nach einem ordentlichen Anbieter für einen neuen vServer gesucht. Dabei galt es folgende Kriterien zu erfüllen:
– Min. 2 IPv4 Adressen – Ein kleines IPv6 Netz – Unbegrenzter Traffic – Min. 100Mbit/s Anbindung – Min. 2 CPUs – Min. 4 GB RAM – Min. 200 GB HDD – Linux als OS
Natürlich habe ich zuerst die Großen abgeklappert.
– 1und1 kein IPv6 (warum nicht? Ich meine 2014 HALLO!?!?) – Strato nur EINE IPv6 Adresse (Ö_ö eine IPv6 Adresse…. eine?) – Host Europe kein IPv6 bei den vServer nur bei den Root Server EINE (tz..) – 1blue kein IPv6 – Server4you kein IPv6 beim vServer, sonst soll es wohl gehen… – Serverloft… Joar, die Kosten sind mir zu hoch. Sind aber auch keine vServer. – usw. usw. usw…
IPv6 scheint noch immer ein größeres Problem zu sein, ist nicht voll integriert oder ist (wie auch meherer IPv4 Adressen) hochpreisigen Produkten vorbehalten.
Dann bin ich auf Contabo gestoßen. Ich war Opfer der Werbung im Linux Magazin 🙁 Preis/Leistung sah dabei einfach zu gut aus. Daher habe ich angerufen. Ohne lange Hoteline sprach ich mit einem Menschen. Diesem stellte ich direkt meine Fragen und er konnte sie überraschenderweise direkt und sicher beantworten. Mit sicher meine ich, dass man nicht das Gefühl hatte er würde es irgendwo nachlesen oder wäre nach einer kurzen Schulung auf die Hotline losgelassen worden. Nein, es war wirklich gut!
Natürlich habe ich abschließend die Frage gestellt wie es klappt dass die angegebene Leistung so gut ist, der Support so schön zu funktionieren scheint und die Ausstattung und Randbedingungen ebenfalls so gut erscheinen. Nach hörbarem Schmunzeln bekam ich die Antwort: Das würde oft gefragt…. Ich müsse es so sehen. Contabo selbst stellt wirklich nur die Hardware und die Infrastruktur. Für das System selbst ist man selbst verantwortlich. Wenn es da mal Probleme gibt, könnte der Support zwar helfen diese wäre dann aber Kostenpflichtig (er meinte damit wenn man seine Kiste mal zerfriemelt hat). Man müsse schon wissen was man tut, dieses würden Contabo bei seinen Produkten einfach voraussetzten.
Schien also genau das zu sein was ich gesucht habe! Daher habe ich bestellt… Wobei ich genau eine solche Antwort von jedem Root-Server erwarten würde.
Alles ging schnell und für mich verständlich online. Ich bekam eine E-Mail mit der Bitte Geld zu überweisen (wer konnte damit nur rechnen. ). Kurz nach meiner Überweisung flatterten bereits die Zugangsdaten in mein Postfach.
Wie bei der Bestellung angeklickt hatte ich schon eine zweite IPv4 Adresse und konnte die PTR-Records flott im Webmenü eintragen. Um die PTR-Records der IPv6 Adressen zu ändern musste ich kurz den Support per E-Mail bemühen. Freitags um 23:36 Uhr habe ich ihn angemailt als ich morgens aufgewacht bin hatte ich schon die Bestätigung in meinem Postfach. Das System selbst ist genau wie bestellt und hat mehr Leistungsreserven als erwartet. Ich habe 8GB Arbeitsspeicher, 400Gb Festplattenplatz und zwei CPUs mit 3,4GHz. Auf der Webseite war nur etwas von 3,2GHz zu lesen. Ok ok… die paar MHz machen den Braten jetzt nicht fett, das es Core I7 CPUs sind hat mich denn noch überrascht!
Ich habe natürlich Speicher und CPU mal mit Arbeit beworfen um zu testen ob es nicht nur Schein ist. Alles prima…. Die Storage Anbindung ist ja gerne mal etwas zu genau auf den Punkt dimensioniert. Bei meinem System kann ich nicht klagen. Performance und I/Os sind wunderbar und mehr als ausreichend.
100Mbit/s sind auch 100Mbit/s… Wobei man hier auf das „Kleingedruckte“ achten muss: Keine zusätzlichen Kosten durch Traffic (bei einem Durchschnittsverbrauch über 40 Mbit/s in einem zusammenhängenden Zeitraum von mindestens 5 Tagen erfolgt eine Umstellung der Anbindung auf 10 Mbit/s).
Zu dem Thema muss ich dann wohl mal eine kleine Auswertung vom Support anfordern. Sollte doch machbar sein, oder?
Ob mich dieses noch ärgert, werde ich herausfinden. Ob mich noch mehr ärgert wird sich zeigen!
Es ist ja nicht zu glauben… Da scheint eine ganze Chinabude nichts weiter zutun zu haben als SSH Burte Force Attacken durchlaufen zu lassen. Dieser Netzowner geht mir gerade tierisch auf die Nerven. Ich bekommen durchgehen Angriffe aus Netzen bei dem er der Eigentümer ist. Das ist im Moment auch echt massiv 🙁
Warum zum Eimer werde ich neuerdings auf Port 445/tcp angepümmelt?
Ist wieder irgendein Rotz unterwegs der da etwas Neues ausnutzt? Ich meine, wer macht schon smb/samba ins Internet? Etwas Traffic ist ja immer klopfend auf dem Port… Kaum ist es 2014 schon brennt hier der Baum?!? Ich habe alleine heute 9k Versuche geloggt. Können wir nicht langsam mal dieses hässliche IPv4 Protokoll abschalten, damit diese Bots aufhören Ranges abzuklopfen?
TCP SYN/Normal scan from host: 1.2.3.4/1.2.3.4 to TCP port: 445
Da habe ich doch gerade noch einen Tipp bekommen (danke Felix). Möchte man „mal eben“ seine DNS Konfiguration inkl. Mailserver testen wird einem ein solcher Test über die Webseite www.dnsinspect.com angeboten.
Der Test geht natürlich jetzt nichts ins absolute Detail aber die ganz groben Fehler findet er dann schon. Auch so Dinge wie PRT – HELO/EHLO – Hostname oder postmaster und abuse Adresse. Zu gesprächige Nameserver usw. usw. usw…
Einfach zum Spaß mal eure Domain reinwerfen und schauen was passiert .-)
Am besten gefällt mir dabei der SPF Test, denn dieser sammelt auch gleich alle nötigen DNS Lookups zusammen und visualisiert sie einem recht ansprechend.
Bunte Bilder *wwwööööööööööhhhhhhhhhyyyyyyyyy*
Ja, wenn es hilft schick mir eine E-Mail und ich sage dir ob deine Konfiguration sauber ist.
Früher also man noch ifconfig nutzte, da gab es vconfig um VLANs auf einem Linux Rechner zu konfigurieren. Wenn ich mich richtig erinnere ist die Verwendung von ifconfig inzwischen unter Strafe gestellt.
Also BITTE nutzt ip. Es kann mehr, es zeigt auch alles an und es ist viel einfacher. Vertraut mir…
Hier einmal kurz VLAN mit command ip!
Anlegen des VLAN Interfaces:
$ ip link add link eth0 name eth0.10 type vlan id 10
Vergeben eine IPv4 Adresse auf dieses neue VLAN Interface:
$ ip -4 addr add 192.168.10.1/24 dev eth0.10
Aktivieren des neuen VLAN Interfaces:
$ ip -4 addr add 192.168.10.1/24 dev eth0.10
Damit haben wir nun ein VLAN Interface mit der VLAN ID 10 und der IPv4 Adresse 192.168.10.1 und der Netzmaske 255.255.255.0. Die .10 im Interfacenamen hat nichts mit der VLAN ID zutun. Ich nenne es nur gerne so um es für mich einfacher zu machen.
Ein Tool, sinnvoll aufgebaut, für fast alles nutzbar, funktioniert, geil. Benutzt es.
SPF (Sender Policy Framework, RFC 7208) legt per DNS fest, welche Server für eine Domain E-Mails versenden dürfen. Empfangende Mailserver prüfen bei jeder eingehenden Mail, ob die IP-Adresse des sendenden Servers im SPF-Record der Absenderdomain steht. Steht sie nicht drin, wird die Mail je nach Policy abgewiesen oder markiert.
Aufbau eines SPF-Records
Ein SPF-Record ist ein TXT-Record im DNS der Domain. Ein typisches Beispiel:
kernel-error.de. IN TXT "v=spf1 ip4:148.251.30.205 ip6:2a01:4f8:262:4716::25 mx -all"
Wichtig: Der alte DNS-Record-Typ IN SPF ist seit RFC 7208 (2014) abgeschafft. Nur IN TXT verwenden.
Mechanismen
Jeder Mechanismus definiert eine Regel, gegen die die IP des sendenden Servers geprüft wird:
ip4:148.251.30.205
Diese IPv4-Adresse darf senden. Auch Netze möglich: ip4:148.251.30.0/24
ip6:2a01:4f8:...
Diese IPv6-Adresse darf senden
mx
Alle IP-Adressen der MX-Records der Domain dürfen senden
a
Die IP-Adresse des A/AAAA-Records der Domain darf senden
a:smtp.example.de
Die IP-Adresse eines bestimmten Hosts darf senden
include:example.de
Die SPF-Policy einer anderen Domain mit einbeziehen (z.B. für externe Dienstleister)
redirect=example.de
Gesamte SPF-Policy von einer anderen Domain übernehmen
Nicht mehr verwenden: Der ptr-Mechanismus ist seit RFC 7208 explizit nicht empfohlen. Er erzeugt unnötige Reverse-DNS-Abfragen und ist fehleranfällig.
Qualifier: Was passiert bei einem Treffer?
Vor jedem Mechanismus kann ein Qualifier stehen, der bestimmt, was mit der Mail passiert:
+ (Pass)
Erlaubt (Standard, wenn kein Qualifier angegeben)
- (Fail)
Nicht erlaubt — Mail soll abgewiesen werden
~ (SoftFail)
Nicht erlaubt, aber nicht hart ablehnen — Mail markieren
? (Neutral)
Keine Aussage — wie kein SPF
Hardfail oder Softfail?
Am Ende des SPF-Records steht der Catch-All-Mechanismus all mit einem Qualifier:
-all (Hardfail) — alle Server die nicht explizit gelistet sind, dürfen nicht senden. Empfänger soll ablehnen.
~all (Softfail) — alle nicht gelisteten Server sind verdächtig, aber nicht definitiv verboten. Mail wird zugestellt, aber markiert.
In der Praxis: -all ist die klare Empfehlung, wenn man weiß, welche Server für die Domain senden. ~all war lange der konservative Ansatz, weil manche Empfänger SPF-Fails zu aggressiv behandelten. Seit DMARC den Umgang mit SPF-Ergebnissen standardisiert hat, ist das kein Argument mehr. Wer DMARC einsetzt, sollte -all verwenden.
Das 10-Lookup-Limit
RFC 7208 erlaubt maximal 10 DNS-Abfragen pro SPF-Prüfung. Jeder include, mx, a und redirect zählt als Lookup. ip4 und ip6 verursachen keine Abfrage, die stehen direkt im Record.
Das wird schnell zum Problem, wenn man externe Dienstleister einbindet. Ein include:_spf.google.com zieht allein schon 3-4 weitere Lookups nach sich. Wer Office 365, Google Workspace und einen Newsletter-Dienst kombiniert, sprengt das Limit leicht. Die Fehlermeldung:
PermError SPF Permanent Error: Too many DNS lookups
Lösung: Den SPF-Record so schlank wie möglich halten. Wo möglich ip4/ip6 statt include verwenden, das verbraucht keine Lookups. Externe Dienstleister nach IP-Ranges fragen statt blind deren Include-Ketten zu übernehmen.
SPF-Record testen
# SPF-Record abfragen
dig TXT kernel-error.de +short
# Ergebnis prüfen — sollte den v=spf1 Record zeigen
# Mehrere TXT-Records sind normal (SPF, DMARC, DKIM Policy etc.)
Für einen vollständigen Check mit Lookup-Zählung eignen sich Online-Tools wie kitterman.com/spf oder mxtoolbox.com. Die zeigen auch verschachtelte Includes auf und warnen bei Überschreitung des 10-Lookup-Limits.
SPF allein reicht nicht
SPF prüft die IP-Adresse gegen den Envelope-From (die Adresse aus dem SMTP-MAIL FROM-Kommando), nicht gegen den From:-Header, den der Empfänger sieht. Ein Angreifer kann also eine Mail mit gefälschtem From:-Header senden, solange der Envelope-From eine Domain ist, die er kontrolliert. Der Empfänger sieht den gefälschten Absender, SPF sagt trotzdem „Pass“.
Genau dieses Problem löst DMARC: Es prüft, ob die Domain im From:-Header mit der SPF-Domain (Alignment) oder der DKIM-Signatur übereinstimmt. Erst SPF + DKIM + DMARC zusammen ergeben eine vollständige E-Mail-Authentifizierung. Fragen? Einfach melden.
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) baut auf SPF und DKIM auf. Es löst zwei Probleme, die SPF und DKIM allein offen lassen: Erstens kann der Absender festlegen, was mit Mails passieren soll, die weder SPF noch DKIM bestehen. Zweitens bekommt der Absender Berichte darüber, wie seine Mails bei den Empfängern ankommen.
DMARC-Record aufbauen
DMARC wird als TXT-Record unter _dmarc.domain.de im DNS veröffentlicht. Ein Beispiel:
_dmarc.kernel-error.de. IN TXT "v=DMARC1; p=quarantine; adkim=s; aspf=s; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de"
Die einzelnen Parameter:
v=DMARC1
Protokollversion (immer DMARC1)
p=quarantine
Policy für die Hauptdomain (siehe unten)
sp=quarantine
Policy für Subdomains (optional, erbt sonst von p)
adkim=s
DKIM-Alignment: s = strict, r = relaxed
aspf=s
SPF-Alignment: s = strict, r = relaxed
pct=100
Prozent der Mails, auf die die Policy angewendet wird
rua=mailto:...
Adresse für aggregierte Berichte (täglich, XML)
ruf=mailto:...
Adresse für forensische Berichte (pro Vorfall)
Alignment: Wofür DMARC wirklich da ist
SPF prüft den Envelope-From, DKIM prüft die signierende Domain. Beides sagt nichts über den From:-Header aus, den der Empfänger tatsächlich sieht. DMARC schließt diese Lücke mit dem sogenannten Alignment: Es verlangt, dass mindestens eine der beiden Prüfungen (SPF oder DKIM) zur Domain im From:-Header passt.
Strict (s) bedeutet: Die Domains müssen exakt übereinstimmen. Relaxed (r) erlaubt auch Subdomains (z.B. mail.kernel-error.de passt zu kernel-error.de). Für die meisten Setups ist strict die richtige Wahl, solange alle ausgehenden Mails über die Hauptdomain signiert werden.
Policy-Stufen
Der p-Parameter legt fest, was der Empfänger mit Mails machen soll, die weder SPF noch DKIM bestehen:
p=none
Nur beobachten, nichts tun. Gut zum Einstieg, um über die Reports erstmal zu sehen was passiert.
p=quarantine
Als Spam markieren. Die Mail wird zugestellt, landet aber im Spam-Ordner.
p=reject
Ablehnen. Die Mail wird gar nicht erst angenommen.
Der empfohlene Weg: Mit p=none anfangen und die Reports auswerten. Wenn alles sauber aussieht, auf quarantine hochdrehen. Wenn auch das stabil läuft, auf reject gehen. Mit pct kann man die Policy schrittweise ausrollen, z.B. erst auf 10% der Mails anwenden und dann langsam erhöhen.
Reporting
Die aggregierten Reports (rua) kommen einmal am Tag als komprimierte XML-Dateien per Mail. Darin steht, welche IPs Mails mit deiner Domain versendet haben und ob SPF/DKIM bestanden oder durchgefallen sind. Das ist Gold wert: Man sieht sofort, ob jemand die Domain missbraucht oder ob ein legitimer Dienst falsch konfiguriert ist.
Die XML-Dateien sind nicht besonders lesefreundlich. Zum Auswerten eignet sich dmarcian.com (XML hochladen, menschenlesbare Übersicht bekommen) oder man baut sich eine eigene Auswertung. Für größere Setups gibt es Open-Source-Tools wie parsedmarc, die Reports automatisch verarbeiten und in Elasticsearch oder eine Datenbank schieben.
Die forensischen Reports (ruf) liefern Details zu einzelnen fehlgeschlagenen Mails. In der Praxis schicken die meisten großen Provider (Google, Microsoft) allerdings keine forensischen Reports mehr, aus Datenschutzgründen. Die aggregierten Reports reichen für die meisten Fälle aus.
Cross-Domain-Reporting
Wer mehrere Domains betreibt und die Reports zentral an eine Adresse schicken will, muss aufpassen. Soll der Report für kernel-error.com an postmaster@kernel-error.de gehen, muss die Empfänger-Domain das erlauben. Dafür braucht es einen zusätzlichen TXT-Record in der Zone von kernel-error.de:
kernel-error.com._report._dmarc.kernel-error.de. IN TXT "v=DMARC1"
Dieser Record sagt: „kernel-error.de akzeptiert DMARC-Reports für kernel-error.com.“ Ohne diesen Eintrag ignorieren Empfänger die Report-Adresse, weil sie in einer fremden Domain liegt.
Einen vollständigen Check inklusive SPF und DKIM bekommt man über mxtoolbox.com oder ähnliche Online-Tools. Einfach eine Testmail an die Prüfadresse schicken und den Report abwarten.
Das Zusammenspiel
DMARC funktioniert nur zusammen mit SPF und DKIM. Alle drei zusammen ergeben eine vollständige E-Mail-Authentifizierung: SPF legt fest welche Server senden dürfen, DKIM signiert die Mail kryptografisch und DMARC verknüpft beides mit einer Policy und liefert Feedback. Wer das Ganze mit rspamd betreibt, hat Auswertung und Enforcement gleich mit dabei. Fragen? Einfach melden.
