-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: SelfHosted (Seite 6 von 8)

ownCloud News-App

31. Januar 2014 / / Keine Kommentare

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt. Der Nachfolger ist Nextcloud, der 2016 als Fork aus ownCloud hervorgegangen ist.

Ich bin ja SOOOO zufrieden, dass kann sich keiner vorstellen. Ich habe einige RSS News Feed abonniert. Natürlich schaffe ich es nicht alles zu lesen. Daher ist es ganz gut einen Feedreader zu haben welcher sich darum kümmert mir neues zu zeigen, altes gut durchsuchbar aufzubereiten und natürlich kenntlich zu machen welche ich bereits gelesen habe.

Dieses Google oder einem anderen „seriösen“ Anbieter zu überlassen… Hm, da habe ich immer Bauchschmerzen. Was geht es diesen Anbieter denn bitte an, was ich wann lese, für wichtig empfinde? Richtig… Nix.

Wenn ich die Daten nur in einer Anwendung auf dem Notebook vorhalte, kann ich sie nur sinnvoll lesen wenn ich am Notebook bin. Sein wir mal ehrlich umschau wo haben wir alle oft Zeit für so etwas? Genau auf dem Klo… Also auf dem Smartphone? Naja, dann habe ich es wieder nur auf dem Smartphone.

Ich nutze schon lange ownCloud um meine Daten, Kalender, Kontakte, Bilder usw. usw. synchron zu halten. Da sollten doch Nachrichten ebenfalls kein Problem sein, oder? Stimmt.

Es gibt ein >>App Framework<< Dieses bietet die News App. Beides lässt sich nach der „Installation“ einfach als ownCloud Admin aktivieren. Natürlich erst das App Framework und dann die News App…

Schon kann man als Benutzer seine Feeds abonnieren. Damit lässt sich alles über den Browser lesen und es gibt eine feine Android App über welche sich alles auf dem SmartPhone lesen lässt.

Die Installation ist denkbar einfach. Ich habe mir direkt einen git clone gezogen und die Daten dann nur verlinkt. Folgende Schritte waren nötig:

$ mkdir /opt/app-framework
$ cd /opt/app-framework
$ git clone https://github.com/owncloud/appframework.git
$ git clone https://github.com/owncloud/news.git
$ ln -s /opt/app-framework/appframework /pfad/zur/owncloud/apps
$ ln -s /opt/app-framework/news /pfad/zur/owncloud/apps
$ chmod -R www-data:www-data /opt/app-framework

Damit die Nachrichten immer schön aktuell sind, muss jemand anstoßen dass sie eingesammelt werden. Dafür nutze ich cron um alle 5 Minuten ein kleines Script zu starten:

*/5 * * * *  /scripte/cloudnews.sh 1>/dev/null 2>/dev/null

Dieses Script tut nichts weiter als über wget die nötige cron.php zu laden und die Ausgabe direkt in den „Müll“ zu werfen.

#!/bin/bash
/usr/bin/wget --no-check-certificate https://cloud.kernel-error.com/cron.php -O /dev/null

Das war es dann schon.

Siehe auch: ownCloud

ownCloud

30. Januar 2014 / / Keine Kommentare

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt. Der Nachfolger ist Nextcloud.

Zur kurzen Beschreibung von ownCloud greife ich jetzt einfach mal ganz faul auf den ersten Absatz aus dem passenden Wikipediaartikel zurück:

### schnipp ###

ownCloud ist eine Software-Suite, die einen ortsunabhängigen Speicherbereich für Daten zur Verfügung stellt. Das Projekt wurde im Januar 2010 vom KDE-Entwickler Frank Karlitschek ins Leben gerufen, um eine freie Alternative zu kommerziellen Cloud-Anbietern zu schaffen. Im Gegensatz zu kommerziellen Speicherdiensten kann ownCloud auf einem privaten Server ohne Zusatzkosten installiert werden. Somit können gerade bei sensiblen Daten die Bedenken gegenüber einer Datenweitergabe und der damit einhergehenden Abgabe der Kontrolle über die Daten zerstreut werden.

Als Grundlage setzt das Projekt auf PHP und einer angebundenen SQLite-, MySQL- oder PostgreSQL-Datenbank. Die ownCloud kann über eine Weboberfläche bedient werden und ist dadurch nicht an ein bestimmtes Betriebssystem gebunden. Aber auch andere Anwendungen, wie beispielsweise Dateimanager oder Groupwares, können die ownCloud über eine Schnittstelle ansprechen und Dateien und Daten lokal bereitstellen.

### schnapp ###

Im Grunde lässt sich ownCloud also mit recht kleinen Grundvoraussetzungen ownCloud in Betrieb nehmen. Selbst die einfache Installation ist nicht weiter aufwendig. Natürlich hängt es immer etwas davon ab, welche Systeme man noch anbinden möchte und wie groß es am Ende wirklich werden soll.

Inzwischen gibt es für alle möglichen Clients auch Software, welche sie an ownCloud anbindet. Evolution, Thunderbird, Kmail (und Anhang), Sync-Clients für Windows/Linux/… Man kann einfach auf seine Dateien per WebDAV zugreifen usw. usw…

Man hat also seine Daten wirklich unter der eigenen Kontrolle und würfelt sie nicht irgendwo hin. Dabei ist die nötige Basis so gering dass es alles sogar über einen Raspberry Pi läuft.

OK… Es hat natürlich einen Haken. Denn es ist wie immer, wenn man selbst dafür verantwortlich ist, dann ist man auch selbst dafür verantwortlich. Alles ist dann nur so sicher wie man es selbst abgesichert hat, sich um die Patchstände kümmert und die Konfiguration vorgenommen hat.

Denn noch bietet man natürlich selbst in der Regel ein nicht ganz so attraktives Ziel wie ein großer Clouddienstleister (ich mag das Wort cloud nicht…).

Siehe auch: ownCloud und Kalender / Kontakte synchronisieren, ownCloud News-App, ownCloud und Mozilla-Sync, Davdroid ownCloud sync

Fragen? Einfach melden.

ownCloud und Kalender / Kontakte synchronisieren

30. Januar 2014 / / Keine Kommentare

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt. Der Nachfolger ist Nextcloud. CalDAV und CardDAV funktionieren dort identisch.

Meine Frau führt schon immer den „Familienkalender“…. Vor der Smartphonezeit war dieses ein kleines Büchlein in ihrer Tasche und ein größerer Kalender an der Wand. Es gab natürlich immer mal wieder Unterschiede zwischen dem kleinen Büchlein in der Tasche und dem Kalender an der Wand. Am meisten störte mich immer, dass ich sie anrufen musste wenn ich nach einem freien Termin gefragt wurde. Hatte immer so ein bisschen was von: „Bei Mama fragen ob ich mit meinen Freunden spielen gehen kann.“

Mit den Smartphone bot sich nun endlich die Möglichkeit Termine synchron zu halten. Natürlich war es nie eine Option die Daten bei irgendjemandem abzulegen, sondern dann schon unter eigener Kontrolle. Daher in die ownCloud.

Somit sehe ich nun den Kalender meiner Frau, welchen sie für mich freigegeben hat und sie natürlich auch meinen. Dieses nicht nur im Webfrontend der ownCloud und auf dem Android Smartphone sondern zusätzlich noch auf unseren Computer. Egal ob kmail, Evolution oder oder…. Überall ist nun alles gleich!

Dabei setzten wir auf unseren Androiden die Apps CalDAV-Sync und CardDAV-Sync ein. Bisher arbeiten diese Apps sehr gut auf unseren Geräten.

Man braucht Google wirklich nicht um seine Geräte im „Gleichgewicht“ zu halten. Ok, die Konfiguration ist etwas aufwendiger als wenn man das vorgegebene nutzt…. Der Gewinn ist aber aus unserer Sicht riesig.

Siehe auch: ownCloud, Davdroid ownCloud sync

DMARC und Mailinglisten: Warum Signaturen brechen und wie ARC das löst

29. Januar 2014 / / Keine Kommentare

Wer eine strenge DMARC-Policy veröffentlicht und gleichzeitig Mailinglisten nutzt, wird früher oder später feststellen: Die eigenen Mails werden auf der Liste zugestellt, aber beim Empfänger abgelehnt. Das liegt nicht an einem Konfigurationsfehler, sondern an der Art wie Mailinglisten funktionieren.

Das Problem

DKIM signiert nicht nur den Body einer E-Mail, sondern auch bestimmte Header wie den Betreff. Mailinglisten-Manager wie Mailman verändern die Mail aber auf dem Weg zum Empfänger. Sie hängen einen Identifier an den Betreff ([liste-name]), fügen einen Footer mit Abmelde-Link an den Body an und setzen eigene Header. Jede dieser Änderungen bricht die DKIM-Signatur.

SPF schlägt ebenfalls fehl, weil die Mail jetzt vom Listserver kommt und nicht mehr vom Mailserver des ursprünglichen Absenders. Die IP des Listservers steht nicht im SPF-Record der Absender-Domain.

DMARC prüft ob mindestens DKIM oder SPF bestehen und das Alignment stimmt. Beides schlägt fehl. Bei einer Policy von p=reject wird die Mail vom empfangenden Server abgelehnt. Der Absender bekommt einen Bounce, der Empfänger sieht die Mail nie.

Workarounds der Listenbetreiber

Mailinglisten-Manager haben verschiedene Strategien entwickelt um das Problem zu umgehen:

From-RewritingDer Absender wird auf die Listenadresse umgeschrieben. DMARC-Alignment passt dann zur Listendomain. Nachteil: Man sieht nicht mehr wer die Mail geschrieben hat.
Subject-Tag weglassenKein [liste] im Betreff. Schont die DKIM-Signatur, aber der Betreff allein reicht nicht, die Signatur kann trotzdem brechen wenn der Body verändert wird.
Footer weglassenKein Abmelde-Link im Body. Schont DKIM, aber Listenbetreiber brauchen den Footer oft aus rechtlichen Gründen.
DKIM re-signingDie Liste signiert die Mail neu mit ihrer eigenen Domain. Funktioniert, aber die originale Signatur des Absenders geht verloren.

Keiner dieser Workarounds ist sauber. Entweder geht Information verloren oder die Authentizität leidet.

ARC: Die eigentliche Lösung

Authenticated Received Chain (RFC 8617) wurde genau für dieses Problem entwickelt. Die Idee: Jeder Zwischenserver (wie ein Listserver) speichert die Authentifizierungsergebnisse der eingehenden Mail in einem ARC-Header und signiert diesen. Der empfangende Server kann dann die Kette zurückverfolgen und sehen, dass die Mail beim Eintritt in die Liste noch gültig war.

Drei Header bilden die Kette:

ARC-Authentication-Results: i=1; lists.example.org;
  dkim=pass header.d=kernel-error.de;
  spf=pass smtp.mailfrom=kernel-error@kernel-error.com;
  dmarc=pass header.from=kernel-error.de

ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; ...
ARC-Seal: i=1; a=rsa-sha256; d=lists.example.org; cv=none; ...

ARC-Authentication-Results enthält die Ergebnisse zum Zeitpunkt der Annahme. ARC-Message-Signature signiert die Nachricht in ihrem aktuellen Zustand. ARC-Seal signiert die gesamte ARC-Kette und verhindert Manipulation.

Der empfangende Mailserver prüft die ARC-Kette. Wenn er dem Listserver vertraut und die Kette gültig ist, kann er die Mail trotz gebrochener DKIM-Signatur zustellen. Gmail, Microsoft und Yahoo werten ARC bereits aus. rspamd unterstützt ARC-Validierung und ARC-Signing von Haus aus.

In der Praxis

Mailman 3 unterstützt ARC-Signing. Bei Mailman 2 lässt sich ARC über einen vorgeschalteten Milter nachrüsten. Wer rspamd als Milter einsetzt, kann ARC dort aktivieren und braucht keinen separaten Dienst.

Die Empfehlung für Listenbetreiber: ARC-Signing aktivieren und den Betreff nicht verändern (statt [liste] den List-Id-Header nutzen, den alle modernen Mailclients auswerten können). Für Absender mit p=reject: ARC reduziert das Problem erheblich, löst es aber nur wenn die Gegenseite ARC auch prüft. In der Übergangsphase hilft es, bekannte Listserver per DMARC-Whitelist von der Policy auszunehmen.

Fragen? Einfach melden.

Postfix mit DANE und DNSSEC absichern

28. Januar 2014 / / Keine Kommentare
Postfix-Mailserver mit DANE und DNSSEC, TLSA-Record-Prüfung, DNS als Vertrauensanker und verifizierter SMTP-TLS-Verbindung zwischen Mailservern.

Meine Domains sind schon lange per DNSSEC gesichert. Für den Webserver hatte ich auch schnell TLSA-Records veröffentlicht, damit die TLS-Verbindung per DANE abgesichert ist. Seit Postfix 2.11 beherrscht auch der MTA die Prüfung von TLSA-Records, damit lässt sich ausgehende E-Mail-Verschlüsselung kryptographisch verifizieren, ohne sich auf das CA-System verlassen zu müssen.

Postfix konfigurieren

Zwei Zeilen in der main.cf reichen, damit Postfix beim Versand TLSA-Records prüft:

postconf -e "smtp_dns_support_level = dnssec"
postconf -e "smtp_tls_security_level = dane"

smtp_dns_support_level = dnssec weist den SMTP-Client an, DNSSEC-validierte DNS-Antworten zu verlangen. smtp_tls_security_level = dane aktiviert die TLSA-Prüfung, Postfix sucht automatisch nach TLSA-Records für den Zielserver. Gibt es keinen TLSA-Record oder kein DNSSEC, fällt Postfix auf opportunistisches TLS zurück. Die Kommunikation mit Servern ohne DANE leidet also nicht. Details stehen in der Postfix DANE-Dokumentation.

TLSA-Record erstellen

Der TLSA-Record enthält einen Hash des TLS-Zertifikats (oder des Public Keys), den der Empfänger-Mailserver im DNS veröffentlicht. So erzeugt man den SHA-256-Hash des Public Keys aus dem Zertifikat:

openssl x509 -in postfix.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Den Hash trägt man als TLSA-Record in die DNS-Zone ein, für Port 25 (SMTP) und optional Port 465 (Implicit TLS):

_25._tcp.smtp.kernel-error.de.  3600 IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
_465._tcp.smtp.kernel-error.de. 3600 IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Die Felder 3 1 1 bedeuten: DANE-EE (End Entity, kein CA-Vertrauen nötig), SPKI (nur Public Key, nicht das ganze Zertifikat), SHA-256. Der TTL von 3600 Sekunden ist bewusst kurz, bei einem Zertifikatswechsel soll der alte Record schnell ablaufen. Mehr zum Aufbau von TLSA-Records steht in RFC 7672.

Testen

Mit posttls-finger (Teil von Postfix) lässt sich prüfen, ob die DANE-Verifikation funktioniert:

posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de

Die entscheidende Zeile in der Ausgabe:

Verified TLS connection established to smtp.kernel-error.de[...]:25:
  TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Verified statt Untrusted, der TLSA-Record stimmt mit dem Zertifikat überein, die Verbindung ist DANE-verifiziert. Im Postfix-Log sieht man denselben Unterschied:

smtp[3779]: Verified TLS connection established to mx02.example.de[...]:25
smtp[3779]: Untrusted TLS connection established to smtp2.example.de[...]:25

Verified = DANE-geprüft und in Ordnung. Untrusted = TLS aktiv, aber kein gültiger TLSA-Record vorhanden, die Verschlüsselung funktioniert trotzdem, nur ohne kryptographische Verifikation des Zertifikats.

Warum DANE besser ist als das CA-System

DANE verankert das Vertrauen im DNS statt bei Certificate Authorities. Der Domaininhaber veröffentlicht den Hash seines Zertifikats selbst, DNSSEC schützt den Record vor Manipulation. Keine CA kann ein falsches Zertifikat für die Domain ausstellen und damit die Verbindung aufbrechen. Das Ganze kostet nichts außer einem DNS-Record und funktioniert für jeden, der DNSSEC betreibt.

Zum Vergleich: Das damalige „E-Mail made in Germany“ (EmiG) setzte auf eine TÜV-Zertifizierung, die sich nur große Provider leisten konnten. Sicherheit nur für Unternehmen mit Budget, das ist das Gegenteil von dem, was ich unterstütze.

Update August 2014: Ich habe Mailgraph um DANE-Graphen erweitert, um den Anteil verifizierter Verbindungen zu visualisieren.

Siehe auch: TLSA/DANE-Records prüfen, TLSA- und DANE-Records manuell prüfen: Schritt für Schritt mit OpenSSL, Postfix und DANE: „Server certificate not verified“ debuggen, Postfix: Eingehende E-Mails ohne TLS ablehnen

Fragen? Einfach melden.

Zum Dumm, zum Zum: Eine humorvolle Reflexion

27. Januar 2014 / / Keine Kommentare

Na, mal wieder Lust auf etwas aus der: „Mein Gott, van de Meer!“ Ecke? OK…
Ich werfe also gerade einige Domains auf einen neuen DNS Server. Alles prima, nur saugt sich der Slave die Zonen nach einer Änderung nicht vom Master. Ich teste alles durch renne wild umher und gehe schon anderen Leuten auf den Sack. Bis mir jemand sagt… Kommen die Notifys vielleicht noch vom alten Server? Der PTR von der IPv4 Adresse ist….. Gott bin ich doof. Mein Gott bin ich blöde…

Der neue DNS Server hat mehrere IPv4 Adressen. Der Bind hört natürlich auf eine, nur ist es nicht die primäre IPv4 Adresse des Servers. Der Bind schickt folglich die Notifys über eine andere IPv4 Adresse zum Slave. Der denkt sich… Ok tolle Info aber ich soll auf ne andere Adresse hören. Also interessiert er sich nicht und zieht sich die Zone nicht. Ist ja ich richtig so!

Ich Wurst habe nämlich vergessen dem Bind zu sagen dass er bitte einfach alles über eine bestimmte IPv4 Adresse versenden soll. Ich muss den Bind im Grunde an eine ausgehende IP Adresse binden.
Kann Bind natürlich, schon alleine wegen IPv6. Denn da hat man ja schnell mehrere Adressen.
Nun kann man dem Bind viele verschiedene Vorgaben machen, wie er denn bitte den Weg nach draußen zu nehmen hat. Man kann sagen über welche IP Adresse er selbst anfragen rausschicken soll, über welche Adresse er bitte die Zonen durchreichen soll und auch über welche Adresse er das Notify an den Slave schicken soll.

options {
......
transfer-source 1.2.3.4;
notify-source 1.2.3.4;
query-source 1.2.3.4;
......
};

Alles einfach in den Optionsblock und fertig ist:

So einfach kann es sein, WENN MAN DARAN DENKT! Damit bewegt sich Bind fast nur noch über die angegebene Adresse nach draußen. Man bin ich blöde und wieviel Zeit ich damit wieder verbrannt habe *heul*!

Fragen? Einfach melden.

ownCloud und Mozilla-Sync

26. Januar 2014 / / Keine Kommentare

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.

Siehe auch: ownCloud

SPF-Record einrichten: Wie du festlegst, wer für deine Domain Mails versenden darf

1. Dezember 2013 / / Keine Kommentare
SPF-Record-Einrichtung für eine Domain mit TXT-Beispiel, erlaubten Mailservern, SPF-Mechanismen, Qualifiern, 10-DNS-Lookup-Limit und Hinweis auf DKIM und DMARC.

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.205Diese IPv4-Adresse darf senden. Auch Netze möglich: ip4:148.251.30.0/24
ip6:2a01:4f8:...Diese IPv6-Adresse darf senden
mxAlle IP-Adressen der MX-Records der Domain dürfen senden
aDie IP-Adresse des A/AAAA-Records der Domain darf senden
a:smtp.example.deDie IP-Adresse eines bestimmten Hosts darf senden
include:example.deDie SPF-Policy einer anderen Domain mit einbeziehen (z.B. für externe Dienstleister)
redirect=example.deGesamte 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“.

Siehe auch: SPF Records

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 einrichten: Policy, Alignment und Reporting für deine Domain

30. November 2013 / / Keine Kommentare
DMARC-Einrichtung für eine Domain mit SPF, DKIM, Alignment, Policy-Stufen, Reporting und Beispiel-DNS-Record.

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=DMARC1Protokollversion (immer DMARC1)
p=quarantinePolicy für die Hauptdomain (siehe unten)
sp=quarantinePolicy für Subdomains (optional, erbt sonst von p)
adkim=sDKIM-Alignment: s = strict, r = relaxed
aspf=sSPF-Alignment: s = strict, r = relaxed
pct=100Prozent 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=noneNur beobachten, nichts tun. Gut zum Einstieg, um über die Reports erstmal zu sehen was passiert.
p=quarantineAls Spam markieren. Die Mail wird zugestellt, landet aber im Spam-Ordner.
p=rejectAblehnen. 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.

DMARC testen

# DMARC-Record abfragen
dig TXT _dmarc.kernel-error.de +short

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.

Davdroid ownCloud sync

4. November 2013 / / Keine Kommentare

Veraltet: ownCloud wird nicht mehr aktiv weiterentwickelt, der Nachfolger ist Nextcloud. DavDroid heißt inzwischen DAVx⁵ und funktioniert mit Nextcloud identisch.

Über ownCloud selbst muss ich ja keine großen Worte mehr verlieren. Auch dass der Kontakte und Kalender Abgleich / Sync ganz prima über CalDAV sowie CardDAV funktioniert ist bekannt. Bei einem Android Handy kauft man sich einfach für einen super geringen Betrag die Apps CalDAV-Sync sowie CardDAV-Sync und gleicht so seine Kalender- und Kontakteinträge mit den Daten im ownCloud ab. Ich mache dieses seit bestimmt 1,5Jahren und bin absolut zufrieden damit, vor allem da ich über den gleichen Weg die Daten auch mit meinem Mailclient Evolution problemlos abgeglichen bekomme.

Selbst das freigeben, share, teilen (wie man will) klappt so 1A. Ich kann auf den Kalender meiner Frau schauen und sie auf meinen. So kommt man sich bei Planungen eher selten in die Quere.

Vor kurzem ist mir nun https://www.davx5.com/ davdroid als kostenlose Version unter die Füße gekommen. Getestet und funktioniert genauso wie gewünscht. Damit geht es also ebenfalls in kostenlos!!!



Siehe auch: ownCloud, ownCloud und Kalender / Kontakte synchronisieren

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑