-=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: DNS (Seite 2 von 5)

RFC 7858 – DNS over Transport Layer Security

30. Oktober 2017 / / Keine Kommentare

Ich habe in den letzten Tagen etwas mit dem RFC 7858 (https://tools.ietf.org/html/rfc7858) herumgespielt. Meine Zonen und auch Dienste sind per DNSsec, HSTS, Pinning usw. usw. abgesichert. Warum also noch DNS per TLS? Nun ja… Sinn macht es sicher keinen, bei mir ist nichts spannendes zu finden und kaum ein Besucher wird mit Problemen rechnen müssen wenn er hier ist. Für mich sollte Kryptographie nicht die Ausnahme sondern der Normalzustand sein. RFC 7858 ist da nur ein weiteres Detail. In einer DNS Abfrage finden sich selten geheime Daten. Klar wäre es schlecht wenn diese verändert würden um diese zu verhindern reicht eine Signatur. Das mitlesen der DNS Abfragen würde einer dritten Person so aber offenlegen wo man surft und welche Dienste man nutzt. Sind diese Abfragen per TLS verschlüsselt bleibt dieses geheim. Daher macht es wohl am meisten Sinn es für seinen lokalen DNS Resolver zu nutzen oder es auf großen DNS Servern zu aktivieren. DNS Servern welche sich um viele Zonen kümmern….

Um irgendwo zu starten und selbst einen Eindruck davon zu bekommen habe ich es auf meinen DNS Servern für meine Zonen aktiviert. Bis auf ns2.kernel-error.org haben die Server gültige Zertifikate. Bei ns2.kernel-error.org muss ich mal schauen wie es sich entwickelt.

Als Test:

$ getdns_query -s www.kernel-error.de a @176.9.109.53 -l L

Viel Spaß

Siehe auch: DoT und DoH mit BIND 9.20, DNS over TLS mit Stunnel und BIND9: Eigenen DoT-Server einrichten, DNS over TLS (DoT) mit BIND, Stunnel und Android 9 einrichten, DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server

Fragen? Einfach melden.

Eigene DNS-Blocklisten in Postfix: DNSRBL und RHSBL einrichten

30. Januar 2017 / / Keine Kommentare

Postfix kann eingehende Mails anhand von DNS-basierten Blocklisten ablehnen. Zwei Typen sind relevant: DNSRBL (IP-basiert) prüft ob die sendende IP-Adresse auf einer Blockliste steht. RHSBL (Domain-basiert) prüft ob die Absenderdomain gelistet ist. Beides passiert in Echtzeit während der SMTP-Sitzung, noch bevor die Mail angenommen wird.

Öffentliche Listen

Es gibt dutzende öffentliche Blocklisten. Nicht alle sind gleich zuverlässig. Diese hier laufen bei mir seit Jahren ohne nennenswerte False Positives:

# /etc/postfix/main.cf (Auszug)
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   reject_rbl_client zen.spamhaus.org,
   reject_rbl_client bl.spamcop.net,
   reject_rbl_client b.barracudacentral.org,
   reject_rbl_client ix.dnsbl.manitu.net,
   permit

zen.spamhaus.org ist die Kombiliste von Spamhaus (SBL + XBL + PBL). ix.dnsbl.manitu.net wird in Deutschland gepflegt und erwischt deutschsprachigen Spam den internationale Listen übersehen.

Eigene Listen

Zusätzlich betreibe ich eigene Blocklisten unter kernel-error.de. Die werden teils von Hand gepflegt, teils automatisch aus einem Honeypot-Postfach befüllt. Einträge bleiben mindestens sechs Monate drin:

# Eigene Listen (RHSBL + RBL)
reject_rhsbl_sender abuse.rhsbl.kernel-error.de,
reject_rhsbl_sender postmaster.rhsbl.kernel-error.de,
reject_rhsbl_sender spam.rhsbl.kernel-error.de,
reject_rbl_client spam.rbl.kernel-error.de,

Die RHSBL-Listen prüfen die Absenderdomain: abuse listet Domains ohne funktionierende abuse-Adresse, postmaster solche ohne postmaster-Adresse, spam bekannte Spam-Domains. Die RBL-Liste prüft die IP-Adresse des sendenden Servers.

Warnung

Das sind meine privaten Listen. Ich pflege sie nach meiner persönlichen Einschätzung. Wer sie produktiv einsetzt, macht das auf eigene Verantwortung. Es wird zu False Positives kommen, weil meine Kriterien nicht mit den eigenen übereinstimmen müssen. Für den eigenen Mailserver sind sie ein nützlicher Baustein neben den öffentlichen Listen. Für fremde Mailserver würde ich sie nicht empfehlen.

Wer seinen Postfix weiter absichern will: Die HELO-Prüfung fängt einen erstaunlichen Anteil an Spam ab, bevor die RBL-Abfrage überhaupt nötig wird. Fragen? Einfach melden.

DNSSEC, IPv6 und DENIC: Wenn der DNS-Server in Japan steht

30. Januar 2017 / / Keine Kommentare

Zum Spaß hatte ich mir einen VPS in Japan geklickt. Was damit anfangen? Einen weiteren DNS-Server aufsetzen natürlich. Gute Idee? Nicht wirklich. Der Server steht am anderen Ende der Welt, hat höhere Antwortzeiten und der Resolver wählt zufällig, welchen DNS er fragt. Sporadisch deutlich langsamere Antworten also. Aber für den Spieltrieb war das OK.

FreeBSD 10, BIND 9.11, als Slave für drei Zonen (kernel-error.org, .com, .de). System gepatcht, BIND installiert, DNSSEC-Validierung getestet (TCP, UDP, größer 512 Bytes), alles sauber. Als Slave eingebunden, nochmal getestet, dann bei den übergeordneten Zonen eintragen lassen.

Das Problem

Die Zonen .org und .com haben den neuen Nameserver anstandslos aufgenommen. Die .de-Zone (DENIC) meckerte: DNS-Timeout bei IPv6. Nur bei IPv6. Per dig und drill lief alles einwandfrei:

dig @2001:310:6000:f::1fc7:1 +edns +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.

dig @2001:310:6000:f::1fc7:1 +tcp +edns +norec +bufsize=4096 kernel-error.com IN MX +short
10 smtp.kernel-error.de.

BIND macht keinen Unterschied zwischen IPv4 und IPv6. Alles beantwortet, alles sauber. Auch tcpdump zeigte nichts Auffälliges. PF deaktiviert, kein Unterschied. Provider filtert nicht (nur Switch, iptables und ebtables auf der Infrastruktur, klingt spartanisch). DNSViz meldete ebenfalls einen Fehler, genau wie DENIC.

Die Fehlermeldung der DENIC-API:

ERROR: 223 Timeout after switching from UDP to TCP -
switch to TCP due to timeout (target)
(ns3.kernel-error.com./2001:310:6000:f:0:0:1fc7:1:53)

Der Query-Log

Query-Log aktiviert. Man sieht die Anfragen der DENIC (2a02:568:201:214::1:15) ankommen und beantwortet werden. UDP, TCP, EDNS, DNSSEC-Queries, alles da:

30-Jan-2017 18:30:04.669 client 2a02:568:201:214::1:15#38145: query: ns3.kernel-error.com IN A -E(0)DC
30-Jan-2017 18:30:04.670 client 2a02:568:201:214::1:15#41589: query: ns3.kernel-error.com IN AAAA -E(0)DC
30-Jan-2017 18:30:04.938 client 2a02:568:201:214::1:15#20703: query: kernel-error.de IN SOA -
30-Jan-2017 18:30:05.510 client 2a02:568:201:214::1:15#58465: query: kernel-error.de IN NS -T
30-Jan-2017 18:30:05.889 client 2a02:568:201:214::1:15#47548: query: kernel-error.de IN SOA -E(0)D
30-Jan-2017 18:30:05.896 client 2a02:568:201:214::1:15#55493: query: kernel-error.de IN DNSKEY -E(0)D
30-Jan-2017 18:30:06.416 client 2a02:568:201:214::1:15#37170: query: kernel-error.de IN DNSKEY -E(0)TD

Die Auflösung

Während ich einem Kollegen das Problem demonstrieren wollte, lief das DENIC-Update plötzlich einfach durch. Keine Änderung meinerseits. Die Antwort von DENIC kam dann auch:

Unsere Kollegen können derzeit nicht genau sagen woran es hängt.
Jedoch sind unsere Verbindungen nach Korea zeitweise leicht
beeinträchtigt, evtl. wurde die Nast-Prüfung genau in dem
Moment durchgeführt.

Vermutlich lag es an der Antwortzeit von 200–300 ms, die zusammen mit einem Routing-Problem auf der DENIC-Seite gerade so in einen Timeout lief. Offiziell geklärt wurde es nie. Ein leicht ungutes Gefühl bleibt.

Die tcpdump-Mitschnitte von damals liegen hier: dns.tar.gz. Wer sich für DNSSEC-Grundlagen interessiert: DNSSEC einrichten mit BIND. Fragen? Einfach melden.

Neues Zertifikat für die Homepage von Let’s Encrypt

24. Januar 2017 / / Keine Kommentare

Tach zusammen,

StartSSL ist ja aktuell einfach tot 🙁 Eine für mich sinnvolle Alternative konnte ich aber nicht finden. Eine Wildcard Zertifikat für meine Domains und dann einfach überall das gleiche *grusel* aber 10000 € ausgeben um sonst meine Wünsche zu erfüllen macht auch keinen Sinn. Tja bleibt Let’s Encrypt…. Gott, ich will nicht alle drei Monate neue Zertifikate bauen. Das ist Käse, vor allem mit TLSA/DANE, HPKP usw. *brech*

Für jetzt bin ich dennoch dazu gezwungen auf Let’s Encrypt zu wechseln. Es wird also ein solches Zertifikat hier geben. Ich hoffe nun einfach darauf, dass StartSSL wieder in die Browser kommt. 01.06.2017 soll es da wohl weiter gehen, hm?

https://bugzilla.mozilla.org/show_bug.cgi?id=1311832

https://startssl.com/NewsDetails?date=20160919

Klar ist jetzt dieser China CA zu vertrauen? Nö… Nur bis zu einem gewissen Punkt und ab dann halt HPKP, TLSA/DANE, DNS CAA. Was mir so gut gefällt ist die Möglichkeit für einen vertretbaren Preis so viele unterschiedliche Zertifikate raus zu hauen, wie ich es für richtig halte.

Also kommt nun Let’s Encrypt als „hoffentlich Übergang“ und dann wieder StartSSL oder jemand von euch hat eine gute Idee für mich?

So long…

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

TLSA verkackt: Wenn man nach dem Zertifikatstausch den DNS-Record vergisst

26. September 2016 / / Keine Kommentare

Da kommt folgende Mail rein:

Hi,
mein Firefox Plugin und hash-slinger sagen beide, dass dein TLSA Record für
munin.kernel-error.com
kaputt ist.

Gruß
Andreas

Recht hat der Mann. Ich hatte das Zertifikat getauscht (auf Elliptic Curve umgestellt) und vergessen, den TLSA-Record im DNS zu aktualisieren. Klassiker. Der TLSA-Record enthält einen Hash des Zertifikats. Tauscht man das Zertifikat, stimmt der Hash nicht mehr, und jeder Client der DANE prüft sieht einen Fehler.

Passiert schneller als man denkt, besonders wenn man mehrere Dienste auf verschiedenen Subdomains hat. Jeder braucht seinen eigenen TLSA-Record. Zertifikat erneuern, TLSA vergessen, niemand merkt es (weil kaum jemand DANE validiert). Bis jemand wie Andreas mit dem Firefox-Plugin vorbeikommt.

Die Lektion: Nach jedem Zertifikatstausch die TLSA-Records prüfen. Am besten automatisiert, zum Beispiel per Skript das nach dem ACME-Renewal den Hash berechnet und den DNS aktualisiert. Wer TLSA-Records von Hand prüfen will, findet die Anleitung unter TLSA/DANE manuell prüfen. Die Grundlagen zu DANE stehen im Beitrag DNSSEC und DANE. Fragen? Einfach melden.

OPENPGPKEY: GPG-Schlüssel direkt im DNS veröffentlichen

1. April 2015 / / Keine Kommentare

Schon länger kann man GPG-Schlüssel per CERT-Record im DNS hinterlegen — allerdings nur als Verweis auf einen Ort, an dem der Schlüssel liegt. Mit dem OPENPGPKEY Resource Record (RFC 7929) geht es einen Schritt weiter: Der komplette öffentliche Schlüssel steckt direkt im DNS-Record. Ist die Zone per DNSSEC gesichert, kann der Schlüssel nicht gefälscht werden — unabhängig von Keyservern und den dort möglicherweise kursierenden Fake-Keys.

Aufbau des Records

Der Hostname des OPENPGPKEY-Records wird aus der E-Mail-Adresse abgeleitet. Aus dem Localpart (alles vor dem @) wird ein SHA-256-Hash gebildet und die ersten 56 Zeichen davon als Subdomain unter _openpgpkey.domain verwendet. Für user@example.de:

echo -n "user" | sha256sum
# Ergebnis: 04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b9df8fb
# Die ersten 56 Zeichen des Hashes werden zum Hostnamen:
04f8996da763b7a969b1028ee3007569eaf3a635486ddab211d512c85b._openpgpkey.example.de. IN OPENPGPKEY <base64-encoded-key>

Der Wert des Records ist der GPG Public Key im Binärformat, Base64-kodiert.

Record erzeugen

Den Hash des Localparts berechnen:

echo -n "kernel-error" | sha256sum | cut -c1-56
# 4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4

Den Public Key exportieren und Base64-kodieren:

gpg --export --export-options export-minimal kernel-error@kernel-error.com \
  | base64 -w 0

Beides zusammen ergibt den Zoneneintrag:

4e1543e4c2a42754aa23025a940a30d0d3d106025c9e03be8e525ac4._openpgpkey.kernel-error.com. IN OPENPGPKEY mQINBF...==

Zugegeben — der Record sprengt etwas die Zonenlesbarkeit. Ein GPG-Schlüssel hat schnell mehrere Kilobyte, das wird im Zonefile eine lange Zeile. BIND kommt damit problemlos klar.

Schlüssel automatisch aus dem DNS holen

GnuPG ab Version 2.1 kann OPENPGPKEY-Records direkt abfragen. Will man eine E-Mail verschlüsseln und hat den Schlüssel des Empfängers noch nicht, reicht:

gpg --auto-key-locate dane --locate-keys kernel-error@kernel-error.com

GnuPG sucht den OPENPGPKEY-Record im DNS, prüft die DNSSEC-Signatur und importiert den Schlüssel automatisch. Kein Keyserver nötig, kein manueller Import.

Testen

Ob der Record korrekt im DNS steht, lässt sich online prüfen: openpgpkey.info — E-Mail-Adresse eingeben, der Dienst fragt den OPENPGPKEY-Record ab und zeigt den gefundenen Schlüssel an.

OPENPGPKEY vs. CERT-Record

Der ältere CERT-Record enthält nur eine URL zum Schlüssel — der Client muss den Schlüssel dann von dort herunterladen. OPENPGPKEY packt den kompletten Schlüssel ins DNS. Vorteil: Ein einziger DNS-Lookup genügt, kein zusätzlicher HTTP-Request nötig. Nachteil: Große DNS-Antworten, die bei UDP-Transport fragmentiert werden können — aber mit passender EDNS-Konfiguration kein Problem.

Siehe auch: GPG-Schlüssel per PKA im DNS, GPG: E-Mails signieren und verschlüsseln mit GnuPG, Der sichere GPG-Schlüssel

Fragen? Einfach melden.

Openfire: 404 Remote Server Not Found bei S2S-Verbindungen mit TLS

19. November 2014 / / Keine Kommentare

Seit ich für die Server-zu-Server-Verbindungen (S2S) auf meinem Openfire TLS erzwinge, melden sich andere Openfire-Admins: Ihre User bekommen ein „404 remote server not found“. Nachrichten gehen nur in eine Richtung durch. Wenn die Unterhaltung einmal läuft, klappt es für eine Weile. Ein seltsamer Effekt der nicht direkt auf die Ursache schließen lässt.

Das Problem

Das Problem liegt nicht am eigenen Server und nicht am DNS. Es liegt am Java-Keystore auf der Gegenseite. Java 6 und einige Versionen von Java 7 können die Zertifikatskette nicht korrekt aufbauen, wenn das Intermediate-Zertifikat der CA fehlt. Mein Server sendet es zwar mit, aber Java ignoriert es und versucht die Kette allein aus dem lokalen Truststore zu bauen.

Im warn.log des betroffenen Openfire findet man dann:

org.jivesoftware.openfire.server.ServerDialback - Error verifying key of remote server: jabber.kernel-error.de
org.jivesoftware.openfire.server.ServerDialback - ServerDialback: OS - Ignoring unexpected answer in validation

Die Lösung: Intermediate-Zertifikat importieren

Der Admin des betroffenen Openfire muss das Intermediate-Zertifikat der CA in den Java-Truststore importieren. Auf einem Debian-System:

cd /etc/openfire/security/
/etc/init.d/openfire stop

# Intermediate-Zertifikat der CA herunterladen
wget "https://example-ca.com/intermediate.crt"

# In den Truststore importieren
keytool -import -keystore truststore -alias ca-intermediate -file intermediate.crt
# Passwort: changeit (Java-Default)

/etc/init.d/openfire start

Das Prinzip gilt für jede CA. Das Intermediate-Zertifikat von der Webseite der CA herunterladen und mit keytool in den Truststore importieren. Falls das Zertifikat bereits vorhanden ist, meldet keytool das und man kann den Import überspringen.

Prüfen ob die Kette stimmt

Mit openssl lässt sich prüfen ob der Server das Intermediate-Zertifikat korrekt ausliefert:

openssl s_client -showcerts -connect jabber.example.com:5222 -starttls xmpp

Entscheidend ist die letzte Zeile der Ausgabe:

Verify return code: 0 (ok)

Steht dort etwas anderes, fehlt ein Zertifikat in der Kette oder das Intermediate-Zertifikat wird nicht mitgesendet. In dem Fall muss der Serverbetreiber seine Zertifikatskonfiguration in Openfire prüfen.

Wer schon dabei ist die TLS-Konfiguration anzufassen: Im Beitrag zu unsicheren Ciphern und Protokollen in Openfire steht wie man die veralteten Algorithmen loswird.

Fragen? Einfach melden.

Alternative SPF-RECORDS im DNS

2. November 2014 / / Keine Kommentare

Veraltet: Der dedizierte SPF-DNS-Record-Typ (Typ 99) wurde mit RFC 7208 als deprecated eingestuft. SPF wird ausschließlich über TXT-Records veröffentlicht. Siehe den aktuellen SPF-Beitrag.

Da ich es gerade mal wieder auf dem Tisch habe…. Ja, „früher“ konnte man verschiedene RECORDS im DNS setzten um SPF-RECORDS zu veröffentlichen. So auch einen Record Type mit dem direkten Namen SPF. Seit 2014 ist dem aber nicht mehr so! Denn ab jetzt soll man seine SPF-Records nur noch als TXT-Record (RFC1035 Typ 16) veröffentlichen. Dieses steht im fertigen RFC7208 Abschnitt 3.1.

Damit also bitte die ganzen anderen RECORDS zu SPF aus dem DNS entfernen und nur noch TXT-RECORDS einsetzten. Ich freue mich darüber, denn bisher musste man sonst eine Vielzahl verschiedener Records pflegen, da man sich nicht sicher sein konnte, welchen jetzt bitte die Implementierung des Empfängers nutzt. Zugegeben, die Basis TXT war die am meisten verbreitete Version. Denn noch gab es da hin und wieder ein Problem. Nun steht das RFC bereits einige Zeit fest, und ich habe alle anderen „SPF-RECORDS“ aus dem DNS entfernt. Nun also nur noch TXT bei mir.

So long

IP Reverse Map Delegation: Einrichtung und Fehlerbehebung

17. Oktober 2014 / / Keine Kommentare

Reverse Map Delegation nach RFC 2317 klingt komplizierter als es ist. Es löst ein konkretes Problem: Wer ein kleines IP-Netz hat (kleiner als /24), kann normalerweise keine eigene PTR-Zone betreiben. Mit Reverse Map Delegation geht es doch.

Warum man es braucht

In der guten alten Zeit bekam man ein /24 (256 Adressen). Da legt man einfach eine Zone 3.2.1.in-addr.arpa. an und fertig. Heute bekommt man, wenn überhaupt, ein /29 (8 Adressen). Und da liegt das Problem: DNS-Zonen werden am Punkt getrennt. Bei einem /24 passt das, bei einem /29 gibt es keinen Punkt an dem man die Zone aufteilen kann.

Der Provider behält also die /24-Zone und richtet für das kleine Subnetz CNAMEs ein, die auf eine „Sub-Zone“ des Kunden zeigen. Der Kunde kann dann seine PTR-Records selbst verwalten.

Die Provider-Seite

In der /24-Zone des Providers wird für das Subnetz 1.2.3.0/29 eine Delegation eingerichtet. Jede IP-Adresse bekommt einen CNAME in die Sub-Zone des Kunden:

$ORIGIN 3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.kernel-error.de. hostmaster.kernel-error.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.kernel-error.de.
         IN NS  ns2.kernel-error.org.

; Delegation für 1.2.3.0/29 an den Kunden
0/29     IN NS    ns1.vandemeer.de.
0/29     IN NS    ns2.vandemeer.de.
0        IN CNAME 0.0/29.3.2.1.in-addr.arpa.
1        IN CNAME 1.0/29.3.2.1.in-addr.arpa.
2        IN CNAME 2.0/29.3.2.1.in-addr.arpa.
3        IN CNAME 3.0/29.3.2.1.in-addr.arpa.
4        IN CNAME 4.0/29.3.2.1.in-addr.arpa.
5        IN CNAME 5.0/29.3.2.1.in-addr.arpa.
6        IN CNAME 6.0/29.3.2.1.in-addr.arpa.
7        IN CNAME 7.0/29.3.2.1.in-addr.arpa.

Die Kunden-Seite

Der Kunde richtet auf seinem DNS-Server die Sub-Zone ein und kann dort seine PTR-Records setzen wie gewohnt:

$ORIGIN 0/29.3.2.1.in-addr.arpa.
$TTL 1D
@   1D IN SOA ns1.vandemeer.de. hostmaster.vandemeer.de. (
              2014101701 ; serial
              6H         ; refresh
              30M        ; retry
              2W         ; expiry
              1D )       ; minimum

         IN NS  ns1.vandemeer.de.
         IN NS  ns2.vandemeer.de.

0        IN PTR netzadresse.vandemeer.de.
1        IN PTR router.vandemeer.de.
2        IN PTR mailin.vandemeer.de.
3        IN PTR imap.vandemeer.de.
4        IN PTR webserver.vandemeer.de.
5        IN PTR frei.vandemeer.de.
6        IN PTR frei.vandemeer.de.
7        IN PTR broadcastadresse.vandemeer.de.

Ergebnis

Eine Reverse-Lookup-Abfrage für 1.2.3.4 läuft jetzt über den CNAME zum DNS des Kunden und liefert den gewünschten PTR-Record:

dig -x 1.2.3.4 +short
4.0/29.3.2.1.in-addr.arpa.
webserver.vandemeer.de.

Probleme

Wäre ja zu schön, wenn es keine gäbe.

Laut RFC darf ein PTR-Record eigentlich kein CNAME sein, außer in genau diesem Fall. Das RFC ist von 1998, aber es hat sich nicht überall herumgesprochen. Man muss seinem Gegenüber gelegentlich RFC 2317 erklären, bevor die Diskussion weitergeht.

Außerdem macht Postfix Ärger, wenn man reject_unknown_client in den smtpd_restrictions hat. Diese Prüfung erwartet, dass PTR und A/AAAA-Record zueinander passen. Bei Reverse Map Delegation tun sie das nicht, weil der CNAME dazwischen steht:

450 4.7.1 Client host rejected: cannot find your hostname, [4.5.6.7]

Wer einen größeren Mailserver betreibt, sollte auf der Mail-IP kein Reverse Map Delegation einsetzen, sondern den PTR direkt beim Provider setzen lassen. Spart Arbeit und Ärger.

Fragen? Einfach melden.

E-Mail-Benachrichtigung bei Root-Login einrichten

3. August 2014 / / Keine Kommentare

Kein Server lässt sich zu 100 Prozent absichern. Wenn sich jemand eine Root-Shell öffnet, will ich das zeitnah wissen. Nicht erst wenn Kunden sich melden oder Abuse-Mails eintrudeln. Eine kurze E-Mail mit IP-Adresse und Zeitstempel bei jedem Root-Login gibt zumindest einen Anhaltspunkt.

Vorweg: Das ist kein Security-Feature. Ein Angreifer mit Root-Rechten kann die Benachrichtigung deaktivieren, die Mail abfangen oder die .bashrc löschen. Es ist Schlangenöl, wenn man es als Schutzmaßnahme verkauft. Aber als ergänzender Hinweis funktioniert es gut, weil die Mail meist schon raus ist bevor der Angreifer sie verhindern kann. Vorausgesetzt, die Mail geht an einen anderen Server.

Variante 1: .bashrc

Die einfachste Methode. Eine Zeile in /root/.bashrc schickt bei jedem Öffnen einer interaktiven Shell eine Mail:

echo 'ALERT - Root Shell Access (ServerName) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" root-logins@example.com

Das Ergebnis sieht dann so aus:

Subject: Alert: Root Access from 203.0.113.42
ALERT - Root Shell Access (bsd01) on: Mi 12. Mär 14:22:03 CET 2026 root pts/0 2026-03-12 14:22 (203.0.113.42)

Damit die IP-Adresse statt eines Hostnamens in der Mail steht, sollte der SSH-Server keine DNS-Abfragen machen:

# /etc/ssh/sshd_config
UseDNS no

Variante 2: PAM

Robuster als die .bashrc-Methode, weil PAM vor der Shell greift und nicht so leicht umgangen werden kann. In /etc/pam.d/sshd am Ende:

session optional pam_exec.so /usr/local/bin/login-notify.sh

Das Script /usr/local/bin/login-notify.sh:

#!/bin/sh
[ "$PAM_TYPE" = "open_session" ] || exit 0
echo "SSH Login: $PAM_USER von $PAM_RHOST auf $(hostname) um $(date)" | \
  mail -s "SSH Login: $PAM_USER@$(hostname) von $PAM_RHOST" root-logins@example.com

PAM setzt die Umgebungsvariablen PAM_USER, PAM_RHOST und PAM_TYPE automatisch. Das Script prüft auf open_session, damit es nur beim Login feuert und nicht beim Logout.

FreeBSD

Unter FreeBSD heißt die PAM-Konfiguration /etc/pam.d/sshd (gleicher Pfad). Statt mail steht dort mailx zur Verfügung, oder man nutzt direkt sendmail. Die .bashrc-Variante funktioniert genauso, die Datei liegt unter /root/.profile wenn csh/tcsh die Standard-Shell ist.

Einordnung

Login-Benachrichtigungen ersetzen kein Monitoring und kein Intrusion Detection System. Sie sind ein einfacher Stolperdraht, der in der Praxis überraschend oft hilft. Nicht weil er einen Angriff verhindert, sondern weil er die Reaktionszeit verkürzt. Wenn um drei Uhr nachts eine Login-Mail von einer unbekannten IP kommt, weiß man dass etwas nicht stimmt.

Wer den SSH-Zugang selbst härten will: Multi-Faktor-Authentifizierung mit Google Authenticator macht einen erfolgreichen Login ohne den zweiten Faktor deutlich unwahrscheinlicher. Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑