Posts Tagged ‘DNS’

Donnerstag, 19. Juli 2018

SPF für ein Cyon-Hosting aktivieren

Da ich mich auf der Arbeit gerade mit dem Thema E-Mail-Sicherheit und -Authentizität befasse, war es nun an der höchsten Zeit, auch meinen privaten Mailverkehr sicherer zu machen.

Begonnen habe ich mit der Konfiguration des sogenannten Sender Policy Frameworks SPF. Der Besitzer einer Domain gibt mit einem TXT-Eintrag in einem bestimmten Format auf dem Nameserver der Domain bekannt, von welchen IPs aus überall legitime E-Mails versendet werden können.

Mailserver, welche von einer mit SPF ausgerüsteten Domain E-Mails erhalten, können — müssen aber nicht — diese Information abfragen und mit den Informationen im Header des E-Mails vergleichen. Basierend auf dem Resultat dieser Auswertung kann der Mail-Server oder der Mail-Client des Empfänger Aktionen ergreifen. Beispielsweise E-Mails markieren oder in einen Unterordner verschieben, welche von keiner der freigegebenen IP versendet wurden. Oder E-Mails von einer offiziellen Mail-Server-IP eine höhere Authentizitätspunktzahl geben und so von der Spam-Score abziehen.

Mein Hoster der Wahl, Cyon, hat im Support-Artikel Was ist ein SPF-Record? festgehalten, wie ein solcher SPF-Record aussehen könnte und wie man diesen über das Controlpanel my.cyon einrichtet. Obwohl der Autor des Support-Artikels festhält, dass alle Kundendomains bereits einen Eintrag besitzen …

Der Standardeintrag bei cyon sieht folgendermassen aus: […] Sie können diesen im my.cyon unter «Webhosting» > «DNS-Editor» mit dem DNS-Editor anpassen. Wichtig ist, dass man den bestehenden Eintrag ergänzt, da nur jeweils ein SPF-Eintrag gültig ist.

… hatten meine Domains keinen solchen Eintrag. Wahrscheinlich, weil ich bereits langjähriger Kunde bin und nur neue Hostingkunden diesen Eintrag automatisch erhalten.

Cyon schlägt folgenden Eintrag vor:

v=spf1 +a +mx +ip4:194.126.200.0/24 +ip4:149.126.0.0/21 -all

Ich empfand diese zwei Ranges viel zu weitläufig und habe mich entschieden, stattdessen folgende Konfiguration einzuspeisen:

v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all

Die IPs fand ich folgendermassen heraus:

$ host mail.cyon.ch
mail.cyon.ch has address 194.126.200.18
mail.cyon.ch has address 194.126.200.22
mail.cyon.ch has address 194.126.200.20
mail.cyon.ch has address 194.126.200.19
$ host s056.cyon.net
s056.cyon.net has address 149.126.4.65

Dahinter verstecken sich einerseits alle vier Server, auf welche mail.cyon.ch auflöst, andererseits der physische Server, auf welchem meine Web-Site gehostet wird: s056.cyon.net.

Die TTL habe ich auf 15 Minuten gesetzt, damit ich in Notfällen Anpassungen vornehmen kann und diese sich dann rasch propagieren.

Existenz des Eintrags verifizieren

$ dig @ns1.cyon.ch emeidi.com txt
...
;; ANSWER SECTION:
emeidi.com.		900	IN	TXT	"v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all"
...

Via: Using dig to search for SPF records
und Force dig to resolve without using cache

Warnung

Auf der Arbeit musste ich realisieren, dass man als Besitzer einer Domain den SPF-Record stets aktuell halten muss. Bisher sah ich folgende Probleme:

  • E-Mails werden im Namen des Dienstleister über den Services eines Dritten versendet (bspw. SaaS), der Dienstleister vergisst aber, die IP(s) resp. die Domain mit den SPF-Einträgen des Mail-Servers in die Konfiguration aufzunehmen.
  • Man macht einen Flüchtigkeitsfehler und schreibt bspw. Anstelle +ip4:1.2.3.4 folgende syntaktisch falsche Konfiguration: +ipv4:1.2.3.4

Validität prüfen

Es empfiehlt sich deshalb, zumindest die Validität eines SPF-Records zu testen. Hierfür hat sich bei mir das Tool MxToolbox Supertool bewährt:

image-7972

Wird der SPF-Record grün hinterlegt, ist alles bestens. Erscheint er rot, ist etwas an der Syntax nicht korrekt. Übrigens: Bei mit +include: verschachtelten Einträgen empfiehlt es sich, die Domains im Include-Statement auch noch gleich abzufragen, indem man in der Resultate-Tabelle darauf klickt. In einem Fall fand sich die Fehlkonfiguration dort.

Zusätzlich gibt es noch eine andere Variante — lasst uns doch einfach ein Mail senden! Und zwar an diese Mail-Adresse: check-auth@verifier.port25.com. Man erhält automatisch eine Antwort zurück, die sich etwa so liest:

==========================================================
Summary of Results
==========================================================
SPF check:          pass
"iprev" check:      pass
DKIM check:         permerror
SpamAssassin check: ham

==========================================================
Details:
==========================================================

HELO hostname:  s056.cyon.net
Source IP:      149.126.4.65
mail-from:      xyz@eMeidi.com

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         pass
ID(s) verified: smtp.mailfrom=xyz@eMeidi.com

DNS record(s):
   eMeidi.com. 60 IN TXT "v=spf1 +a +mx +ip4:194.126.200.18 +ip4:194.126.200.19 +ip4:194.126.200.20 +ip4:194.126.200.22 +ip4:149.126.4.65 -all"
   eMeidi.com. 60 IN A 149.126.4.65


----------------------------------------------------------
"iprev" check details:
----------------------------------------------------------
Result:         pass (matches s056.cyon.net)
ID(s) verified: policy.iprev=149.126.4.65

DNS record(s):
   65.4.126.149.in-addr.arpa. 60 IN PTR s056.cyon.net.
   s056.cyon.net. 60 IN A 149.126.4.65

Produktiver Test

Um das funktionieren des SPF-Records vollends zu testen, sendete ich mir ein Mail an eine Gmail-Adresse und guckte mir dann den Mail-Header an, wie er bei Google ankommt:

...
Received-SPF: pass (google.com: domain of xyz@emeidi.com designates 149.126.4.65 as permitted sender) client-ip=149.126.4.65;
Authentication-Results: mx.google.com;
       dkim=temperror (no key for signature) header.i=@emeidi.com header.s=default header.b=LchLhMBS;
       spf=pass (google.com: domain of xyz@emeidi.com designates 149.126.4.65 as permitted sender) smtp.mailfrom=xyz@emeidi.com
...

Ist SPF gar nicht konfiguriert, sieht der E-Mail-Header stattdessen folgendermassen aus:

...
Received-SPF: neutral (google.com: 149.126.4.65 is neither permitted nor denied by best guess record for domain of xyz@emeidi.com) client-ip=149.126.4.65;
Authentication-Results: mx.google.com;
       dkim=temperror (no key for signature) header.i=@emeidi.com header.s=default header.b=cbFM4Bn7;
       spf=neutral (google.com: 149.126.4.65 is neither permitted nor denied by best guess record for domain of xyz@emeidi.com) smtp.mailfrom=xyz@emeidi.com
...

Tags: , , , ,
Labels: Web

Keine Kommentare | neuen Kommentar verfassen

Samstag, 25. November 2017

Session Replay-Sites auf DNS-Ebene blocken

Vor ein paar Tagen publizierten Sicherheits-Forscher eine Untersuchung (deutsch) über eine Vielzahl von Web-Analyse-Services, welche jede Benutzereingabe auf einer Web-Site abfangen und an den Analyse-Server senden. Sozusagen ein web-site-spezifisches Keylogging.

Gefällt mir ganz und gar nicht.

Die Forscher stellten auch eine Datenbank ins Netz, welche auflistet, welche grössere Web-Site konkret welche Lösung im Einsatz haben.

Da ich seit einer Weile im internen Netzwerk bereits Ad-Sites auf DNS-Ebene blocke (mit der Folge, dass ich im Browser keine SPIEGEL-Artikel mehr lesen kann — Instapaper als funktionierender Workaround), habe ich die von den Forschern entdeckten Services zur offiziellen Block-Liste hinzugefügt.

Hier meine Konfiguration:

// Session Replay Prevention
// https://webtransparency.cs.princeton.edu/no_boundaries/session_replay_sites.html

// Already blocked by http://pgl.yoyo.org/adservers/:
// mouseflow.com
// hotjar.com
// userreplay.net

// Specific subdomains used by some sites investigated
//zone "cdnssl.clicktale.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.clicktale.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.decibelinsight.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.inspectlet.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "wu-app.quantummetric.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "ws.sessioncam.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "cdn.userreplay.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
//zone "mc.yandex.ru" { type master; notify no; file "/etc/bind/zones/null.dns"; };

zone "clicktale.net" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "fullstory.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "decibelinsight.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "inspectlet.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "quantummetric.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "sessioncam.com" { type master; notify no; file "/etc/bind/zones/null.dns"; };
zone "yandex.ru" { type master; notify no; file "/etc/bind/zones/null.dns"; };

Die gröbsten Missetäter sollten somit nicht mehr ins Haus kommen …

Tags: , , , , , , , , ,
Labels: IT, Linux, Web

Keine Kommentare | neuen Kommentar verfassen

Freitag, 28. April 2017

Unterstützt mein Hoster DNSSEC?

Verisign liefert ein Tool, mit welchem man unter Eingabe eines Domain-Namens testen kann, ob der Betreiber des Nameservers der Domain DNSSEC unterstützt:

DNSSEC Analyzer

Antwort in meinem Fall für Cyon (April 2017): Leider nein.

image-7272

image-7273

Tags: , , ,
Labels: Web

1 Kommentar | neuen Kommentar verfassen

Sonntag, 19. Februar 2017

ELK: Race Condition mit resolv.conf und WiFi

Seit einer Woche läuft auf einem Laptop bei mir zu Hause der ELK-Stack und sammelt per Syslog die Logs aller meiner Devices an drei Standorten. In unregelmässigen Abständen werde ich hier über Erkenntnisse berichten, die ich dank der zentralisierten Analyse der Logs gemacht habe.

Dank ELK fand ich auf Grund von postfix Log-Meldungen bald einmal heraus, dass mein Raspberry Pi 3, welcher ein Dashboard in unserer Wohnung antreibt, keine E-Mails versenden kann. postfix konnte den Hostnamen meines Mail-Providers nicht auflösen:

DASHBOARD postfix/error[1234]: ABCDEF: to=<log@domain.tld>, orig_to=<root@dashboard>, relay=none, delay=40662, delays=40584/78/0/0.27, dsn=4.4.3, status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=server41.cyon.ch type=A: Host not found, try again)

Nach einer längeren Debugging-Session dann die Erkenntnis:

The problem is that Postfix checks /etc/resolv.conf before the WiFi is connected. Therefore, /var/spool/etc/postfix/resolv.conf stays empty after the boot and mails cannot be sent.

Quelle: Postfix error: Host or domain name not found

Genau das war das Problem. Während der Kommentator auf Superuser empfiehlt, postfix erst nach der erfolgreichen WiFi-Verbindung zu starten, löste ich das Problem anderweitig, indem ich einen Cron-Job einrichtete:

...
*/1 * * * *	root	cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf
...

Sicherlich nicht sexy, aber es löst das Problem (und schafft eventuell einige andere).

Tags: , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 20. Mai 2014

Unter DD-WRT DNS-Server per DHCP an die Clients weitergeben

Dies erledigt man folgendermassen:

  1. Services
  2. Services
  3. DNSMasq
  4. Additional DNSMasq options
dhcp-option=6, 10.0.1.10, 195.186.4.111

DD-WRT - Services - Services - DNSMasq
image-5823

Quelle: ISP DNS-Servers

10.0.1.10 ist mein lokaler DNS-Server, welche bestimmte Adressen intern anders auflöst als aus dem Internet. Bei 195.186.4.111 handelt es sich um einen DNS-Server von Swisscom (ex-Bluewin) und ist als Fallback gedacht, wenn 10.0.1.10 nicht reagieren sollte (10.0.1.10 leitet DNS-Anfragen, für welche er keine Authorität hat, transparent an denselben DNS-Server weiter).

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen