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

Schlagwort: InfoSec (Seite 13 von 16)

DMARC-Prüfung in Postfix: OpenDMARC und rspamd im Vergleich

Eine DMARC-Policy zu veröffentlichen ist die eine Seite. Die andere ist, eingehende Mails gegen die DMARC-Policy des Absenders zu prüfen. Postfix kann das nicht selbst. Dafür gibt es zwei Wege: OpenDMARC als eigenständigen Milter oder rspamd, der DMARC als eines von vielen Modulen mitbringt.

Variante 1: OpenDMARC

OpenDMARC ist ein dedizierter DMARC-Milter. Er liest die Ergebnisse von SPF und DKIM aus den Mailheadern und prüft ob die DMARC-Policy des Absenders erfüllt ist.

# Debian/Ubuntu
apt install opendmarc

# FreeBSD
pkg install opendmarc

Die Konfiguration in /etc/opendmarc.conf:

AuthservID mail.example.de
Socket inet:8893@localhost
UserID opendmarc
SoftwareHeader true
Syslog true
RejectFailures false
HistoryFile /var/run/opendmarc/opendmarc.dat

RejectFailures false ist ein guter Startwert. Damit werden Mails die den DMARC-Check nicht bestehen nicht sofort abgelehnt, sondern nur markiert. So kann man erst beobachten bevor man scharf schaltet. AuthservID muss zum Hostnamen des Mailservers passen.

Wichtig: OpenDMARC verlässt sich darauf, dass SPF und DKIM bereits geprüft wurden und die Ergebnisse in den Authentication-Results-Headern stehen. Die Reihenfolge der Milter in Postfix ist daher entscheidend: SPF und DKIM müssen vor OpenDMARC laufen.

Postfix-Integration

In der main.cf den Milter registrieren. OpenDMARC muss nach dem DKIM-Milter stehen:

# main.cf
smtpd_milters = inet:localhost:8891, inet:localhost:8893
non_smtpd_milters = inet:localhost:8891, inet:localhost:8893

Port 8891 ist hier OpenDKIM, Port 8893 OpenDMARC. Nach einem postfix reload prüft OpenDMARC jede eingehende Mail und schreibt einen Authentication-Results-Header mit dem DMARC-Ergebnis.

Variante 2: rspamd

Wer rspamd als Spamfilter einsetzt, braucht keinen separaten DMARC-Milter. rspamd prüft SPF, DKIM und DMARC in einem Durchgang und verrechnet das Ergebnis mit dem Gesamtscore. Das DMARC-Modul ist standardmäßig aktiv und unterstützt auch DMARC-Reporting (rua/ruf).

Der Vorteil von rspamd: Statt einer harten Ablehnung bei DMARC-Fail fließt das Ergebnis in die Gesamtbewertung ein. Eine Mail die DMARC nicht besteht aber sonst sauber aussieht, wird nicht sofort abgelehnt. Umgekehrt kann eine Mail die DMARC besteht trotzdem als Spam markiert werden wenn andere Indikatoren dagegen sprechen.

Was passt besser?

OpenDMARCrspamd
AufwandEigener Dienst, eigene ConfigBereits als Milter integriert
VerhaltenHarte Entscheidung (reject/accept)Score-basiert, flexibel
ReportingEigenes Reporting-Tool nötigrua-Reports eingebaut
AbhängigkeitenBraucht SPF/DKIM in den HeadernPrüft SPF/DKIM selbst

Für neue Setups ist rspamd meist die bessere Wahl, weil es SPF, DKIM, DMARC, ARC und Spam-Filterung in einem Paket liefert. OpenDMARC ist sinnvoll wenn man einen minimalen Stack ohne Content-Filter will oder bereits einen anderen Spamfilter einsetzt.

Übrigens: DMARC und Mailinglisten vertragen sich nicht ohne Weiteres. ARC löst das Problem. Fragen? Einfach melden.

Heartbleed Bug: Was du darüber wissen musst und wie du dich schützt

Heartbleed OpenSSL vulnerability logo

Au man… Das ist ja der Hammer! Wie konnte denn bitte dieser Scheiß passieren? Zum Glück war mein System noch auf der Version 0.9… Aber keine Sorge, ich muss an genug anderen Systemen neue Schlüssel erstellen und die Anwender zu neuen Kennwörter „überreden“.

Das ist einer der größten Löcher die ich bisher gesehen habe und wer hat es gefunden? Google…. Ö_ö

Disbelief reaction meme about Heartbleed bug

Hier muss nun unbedingt ein Plan her für besseren Code Audit, richtig? Ich habe sogar bereits von Exploids gelesen, welche noch vor dem Bekanntwerden im Umlauf gewesen sein sollen. Alle Systeme mit den bösen Versionsständen müssen also als kompromittiert angesehen werden. Ich habe nun schon mit einigen Leuten darüber gesprochen und in diesem Punkt stimmen mir die Meisten zu, bis zu dem Punkt an welchem die damit verbundenen Konsequenzen klar werden. Also neue Schlüssel bauen, von der CA signieren lassen, einbinden, allen Anwendern neue Kennwörter zuschieben usw. usw. usw… Denn mit dem einspielen der Patches ist zwar das Loch gestopft, die möglicherweise abgeschnorchelten und vielleicht bereits missbrauchten Daten sind damit noch nicht zurückgeholt. Denn noch tun sich hier einige Entscheider schwer..

Richtig unangenehm wird es, wenn man daran denkt das in der Vergangenheit aufgezeichnete -verschlüsselte- Daten mit dem vielleicht eingesammelten privaten Schlüssel nun entschlüsselt werden können. Es sei denn Perfect Forward Secrecy war aktiviert. Das ist wohl das Gute an der ganzen Nummer. Man hat nun nicht nur einen theoretischen Grund um PFS einzuführen.

Also weiter machen!

Siehe auch: Von RSA zu ECDSA

Fragen? Einfach melden.

Sichere SSL/TLS Konfiguration für ejabberd

Unsichere Protokolle und Chiper aus Postfix, Dovecot und Apache2 sind schonmal weg!

Jetzt ist mein xmpp Jabber Server ejabberd dran… Auch hier müssen die Protokolle SSLv2 sowie SSLv3 weichen. Nur alles größer TLSv1 ist erlaubt…. Bei den Chipern fliegt alles raus das „böse“ ist… Zum Beispiel MD5, RC4 usw. usw… Natürlich werden auch die ECDHE Cipher suite aktiviert um Forward secrecy zu unterstützen.

Test lässt sich alles am besten über die folgenden Links. Einmal aus der Sicht eines Client und einemal aus der Serversicht!
Client: https://xmpp.net/result.php?id=19649
Server: https://xmpp.net/result.php?id=19650

Next…

Siehe auch: Openfire: Unsichere TLS-Cipher deaktivieren

Fragen? Einfach melden.

Die Akte „IGNORANT“

Ein Lehrstück über Mail, Macht, und die merkwürdige Waffe namens DNS

Es begann nicht mit Explosionen. Es begann mit einem Bounce.

Ein einziger, stiller Bounce – so leise, dass er in der täglichen Flut aus Logzeilen untergehen wollte. Ein 550, trocken wie Kreide:

550 5.1.1 <abuse@domain.tld>: Recipient address rejected: User unknown

Der Absender war ein kleiner Provider, irgendein abgegriffenes Abuse-Postfach, das seit Tagen versucht hatte, jemanden zu erreichen. Die Mail selbst war banal: „Ihre Domain wird für Spam missbraucht, bitte prüfen Sie Ihre Systeme.“ Keine Drohung, kein Drama. Nur ein Handgriff im Maschinenraum: „Schraube locker – bitte nachziehen.“

Noir-style cyber investigation scene with a shadowy analyst at a desk, green terminal showing ‘RFC-Ignorant.org blacklist – no abuse@ / no postmaster@’, and a case board labeled ‘Missing Contacts’ in the background.

Nur war da niemand, der die Schraube nachzog.

Und genau da, in diesem winzigen, fast lächerlichen 550, begann die Operation.

1) Der Mann im Schatten der RFCs

In den frühen 2000ern war das Netz gleichzeitig größer und kleiner. Größer, weil plötzlich jeder einen Mailserver betreiben konnte. Kleiner, weil die Leute, die es wirklich taten, sich kannten – über Mailinglisten, Konferenzen, und die ewigen Schlachten um Anti-Spam-Policy.

Unser Protagonist – nennen wir ihn M. – war keiner von den Lauten. Kein Held, kein Prediger. Er war ein Admin mit dem seltenen Talent, die Welt nicht moralisch zu deuten, sondern operativ.

Seine Welt bestand aus:

  • maillog bei 3 Uhr morgens
  • MRTG-Graphen, die wie EKGs von sterbenden Routern aussahen
  • dig, tcpdump, grep
  • und den RFCs – nicht als Religion, sondern als Werkzeugkiste

M. hatte diese eine fixe Idee: Wenn das Netz schon aus freiwilligen Regeln besteht, dann sind Kontaktadressen die Nieten im Stahl. Ohne Nieten fällt der Kran auseinander. Und „Kontaktadresse“ hieß in diesem Bereich: postmaster@ und abuse@.

  • postmaster@ – der Notausgang für SMTP-Probleme, traditionell Pflicht in der Mailwelt
  • abuse@ – die Stelle, an die man Missbrauch meldet, wenn’s brennt

Und jetzt kam der Haken: Du konntest die beste Abuse-Meldung der Welt schreiben – wenn die Gegenseite „User unknown“ sagt, bleibt der Brand ein Waldbrand.

M. nannte das nicht „Ignoranz“ aus Spaß. Er meinte es wörtlich: Wer nicht erreichbar ist, ist für den Betrieb nicht existent.

2) Die erste Liste – wie man Druck baut, ohne eine Waffe anzufassen

Eines Abends – der Kaffee war kalt, der Pager lauter als nötig – schrieb M. eine kleine Zone-Datei. Kein Kunstwerk. Ein schlichtes Stück Text, ein paar A-Records, eine Reihe von Domains, die auf eine IP zeigten.

So funktionieren DNSBLs: Du drehst die Frage um.

Statt „Ist diese Domain gut?“ fragst du:

„Wenn ich reversed-stuff.blacklist.example nachschlage – bekomme ich eine Antwort?“

Bekommst du eine Antwort, ist es ein Treffer. Kein Treffer, keine Antwort.

DNS als binärer Schalter. Brutal. Elegant. Gefährlich.

M. wusste, was er da baute: eine Art Signalfeuer für Mailadmins. Keine Zensurbehörde – eher ein „da stimmt was nicht“-Indicator, der automatisch verwertbar war.

Das Ziel war simpel formuliert:

  • Domain betreibt MX (oder nutzt Mail)
  • aber postmaster@domain und/oder abuse@domain sind nicht erreichbar
  • also: Eintrag in „IGNORANT“
  • wer die Liste nutzt, kann Mails von dort markieren oder härter behandeln

Nicht blocken war die „sanfte“ Variante. Viele taten’s trotzdem, weil Admins Admins sind: Wenn es eine Kante gibt, wird sie genutzt.

M. sagte dazu nur: „Ich liefere Daten. Policy ist euer Problem.“
Und damit hatte er recht – und auch wieder nicht. Daten sind nie nur Daten, wenn sie in SMTP-Pipelines landen.

3) Der erste Feldtest – RCPT TO als Lügendetektor

Die Methode war bestechend, weil sie so alt war wie SMTP selbst: Frag den Server direkt.

Ein Testlauf sah im Kern so aus:

  • MX der Domain ermitteln
  • SMTP-Session öffnen
  • RCPT TO:<postmaster@domain>
  • RCPT TO:<abuse@domain>
  • Ergebnis klassifizieren

Einige Server antworteten sauber:

  • 250 2.1.5 Ok – Empfänger akzeptiert
  • Andere waren ehrlich brutal:
  • 550 5.1.1 User unknown – Empfänger existiert nicht

Manche waren schlüpfrig:

  • 451 4.7.1 Try again later – temporär, könnte Rate-Limit sein
  • 550 5.7.1 Access denied – Policy-Block, manchmal blind
  • oder sie akzeptierten alles und bouncten später (Backscatter-Paradise)

M. baute Regeln. Nicht perfekt, aber besser als Bauchgefühl.

Die ersten Einträge in der Liste waren nicht „die Bösen“. Es waren oft schlicht:

  • kleine Firmen, die Mail „irgendwie“ hatten
  • Domains mit kaputten Weiterleitungen
  • „wir nutzen einen Provider“-Setups ohne Rollenpostfächer
  • oder verlassene Domains, die noch MX hatten, aber niemand mehr betreute

Und dann: große Namen. Weil große Namen nicht automatisch gute Hygiene bedeuten.
Das machte die Liste berühmt. Und brachte die ersten Feinde.

4) Die Gegenwehr – Agenten mögen keine Aufmerksamkeit, DNSBLs bekommen sie gratis

Sobald die Liste sichtbar war, passierten drei Dinge gleichzeitig:

  • Admins waren dankbar, weil es endlich ein automatisierbares Signal gab.
  • Betroffene waren wütend, weil sie plötzlich Konsequenzen spürten.
  • Spammer wurden neugierig, weil jede Liste auch ein Kartendienst ist.

M. bekam Mails – ironischerweise auf die eigenen Kontaktadressen, die natürlich existierten. Viele waren sachlich: „Wie komme ich runter?“ Andere waren… weniger sachlich.

In der Welt der DNSBLs ist „Runterkommen“ kein Yoga. Es ist Ops:

  • Alias abuse@ anlegen
  • Alias postmaster@ anlegen
  • Monitoring drauf
  • dann Retest / Delist

Aber hier lag der eigentliche Konflikt: Viele wollten nicht „fixen“, sie wollten „weg“. Und zwar sofort. Ohne Aufwand. Ohne Veränderung. Ohne Verantwortung.

In Agentensprache: Sie wollten den Wachmann bestechen, statt die Tür zu reparieren.

M. war nicht käuflich – schon weil das Projekt nicht so funktionierte. Du konntest nicht „zahlen“, damit SMTP plötzlich 250 sagt.

Das machte ihn gefährlich. Nicht durch Macht – durch Unbestechlichkeit. Eine seltene Sorte.

5) Der schmutzige Teil – wenn „Kontakt“ plötzlich selbst ein Angriffsziel ist

Je größer die Liste wurde, desto absurder wurden die Nebeneffekte.

Abuse-Postfächer sind Müllhalden, wenn du sie nicht verteidigst. Sobald klar war: „abuse@ existiert“, wurde es von manchen als Spamziel missbraucht.

Einige Betreiber reagierten vorhersehbar falsch:
Sie löschten abuse@ wieder. „Problem gelöst.“
Und landeten damit wieder in IGNORANT. Kreislauf geschlossen.

Andere machten’s richtig:

  • abuse@ als Ticket-Queue
  • harte Inbound-Filter (aber kein „User unknown“)
  • Rate-Limits
  • klare Auto-Responder mit Case-ID
  • und vor allem: menschliche Bearbeitung, wenn’s ernst wird

Und dann war da die technische Front: Last.

DNSBLs werden nicht „ab und zu“ befragt. Sie werden in Mailpipelines eingebaut – und dann feuert jede eingehende Verbindung Queries ab. Das kann klein anfangen und schnell grotesk werden.

M. musste plötzlich Dinge tun, die in keinem idealistischen Konzeptpapier stehen:

  • Anycast? Schön wär’s.
  • mehrere NS? Klar, aber kostet Zeit und Geld
  • Query-Rate begrenzen, ohne legitime Nutzer zu töten
  • Monitoring, sonst bist du blind
  • DoS-Abwehr, weil irgendwer’s „witzig“ findet

Agenten leben von Logistik. Und Logistik kostet.

Das Projekt, das als mahnender Zeigefinger begann, wurde zu Infrastruktur. Und Infrastruktur frisst Menschen.

6) Die philosophische Krise – wenn ein binärer Schalter moralische Debatten auslöst

Irgendwann war IGNORANT nicht mehr nur „eine Liste“. Es war ein Argument.

Die Debatten drehten sich nicht mehr um SMTP-Codes, sondern um Macht:

  • Darf man Domains „bestrafen“, weil sie nicht erreichbar sind?
  • Ist abuse@ wirklich Pflicht oder nur Tradition?
  • Wer kontrolliert die Liste?
  • Was ist mit False Positives?
  • Was ist mit Domains, die absichtlich keine Mail annehmen?

Die Wahrheit: Alle hatten ein bisschen recht, und genau das ist der Fluch der Netzpolitik.

Technisch ist es simpel: Ein Server akzeptiert oder akzeptiert nicht.

Operativ ist es komplex:
Manche Domains wollen gar kein SMTP, haben aber trotzdem MX wegen Legacy.
Manche Provider verstecken Rollenpostfächer hinter Formularen oder Portalen.
Manche blocken „fremde“ Tests, weil sie Abuse-Scanning für Angriff halten.
Und manche sind schlicht kaputt.

Die Liste war ein Hammer. Viele Probleme sind Nägel. Aber einige sind Glas.

M. wusste: Eine DNSBL ist immer zu grob für die Realität. Sie ist trotzdem nützlich, solange man sie als Signal nutzt – nicht als absolutistische Wahrheit.

Nur: Menschen lieben Absolutismus. Der ist bequem. Und bequem ist gefährlich.

7) Der Zeitenwandel – wenn Mega-Provider die Spielregeln ändern

Dann kam die nächste Welle: Zentralisierung.

Die Mailwelt kippte von „tausend kleine Server“ zu „ein paar riesige“.

Große Provider hatten ihre eigenen Systeme:

  • interne Reputation
  • Feedback-Loops
  • Abuse-Teams
  • automatisierte Takedowns
  • und vor allem: genug Personal, um nicht von einem DNSBL-Projekt abhängig zu sein

Gleichzeitig verschwanden viele kleine Betreiber – oder wurden zu Resellern, die keinen Zugriff mehr auf die eigentlichen Systeme hatten. Du konntest ihnen noch so oft sagen „macht abuse@“ – sie konnten oft nicht.

IGNORANT traf zunehmend die, die am wenigsten Hebel hatten.
Und verfehlte zunehmend die, die wirklich Einfluss hatten.

Das ist der Moment, in dem Agentenfilme normalerweise einen Twist haben: Der Held merkt, dass seine Waffe nicht mehr trifft, was sie treffen soll.

8) Der letzte Einsatz – Hardware stirbt, Menschen auch (nur anders)

Am Ende war es nicht der große Gegner, der IGNORANT beendete. Es war die klassische, schäbige Realität:

  • alte Hardware
  • Wartungsaufwand
  • sinkende Zeit
  • steigender Ärger
  • und das Gefühl, dass man gegen Windmühlen schraubt

Ein DNSBL-Projekt kann man nicht „halb“ betreiben. Wenn du’s tust, wirst du selbst zur Fehlerquelle. Stale Data ist Gift. Und wenn du eine Liste fütterst, die andere in Mailannahme-Policy einbauen, ist „ungepflegt“ ein Sicherheitsrisiko.

M. machte das einzig Verantwortliche: Er zog den Stecker.

Keine dramatische Abschiedsrede. Eher eine Notiz am Schaltschrank:
„Diese Maschine wird nicht mehr gewartet. Benutzung auf eigenes Risiko.“

Die Seite blieb als Geschichte. Als Warnung. Als Artefakt.

Wie ein altes Agentenhandbuch in einem Safe, das keiner mehr benutzt, aber jeder mal lesen sollte.

Field Notes – Was man aus der Akte mitnimmt (ohne Mythos)

A) Rollenpostfächer sind keine Folklore – sie sind Incident-Response-Mechanik

Wenn du Mail betreibst (direkt oder indirekt), brauchst du:

  • postmaster@domain – für SMTP-/Delivery-Probleme, Fehlkonfig, Policy
  • abuse@domain – für Missbrauch, Compromise, Spam, Phishing, Beschwerden

Nicht weil’s „nett“ ist – weil es operativ ist. Ohne erreichbaren Kanal wird jedes Problem langsamer, teurer, größer.

B) DNSBLs sind Werkzeuge – keine Orakel

  • Gut als Signal (Score, Tag, zusätzliche Prüfung) — mehr dazu in RBL und Postfix
  • gefährlich als harte Wahrheit (Reject ohne Kontext)

Wenn du so eine Liste nutzt: Logging, Exceptions, Monitoring. Keine Religion.

C) Tests müssen sauber sein

Ein einfacher, reproduzierbarer Ansatz (mehr dazu unter E-Mail-Spoofing mit Telnet demonstrieren):

domain=example.org
dig +short MX "$domain" | sort -n
mx=$(dig +short MX "$domain" | sort -n | head -1 | awk '{print $2}' | sed 's/\.$//')

# SMTP-Handshake – minimal
openssl s_client -starttls smtp -crlf -connect "$mx:25" <<EOF
EHLO test.invalid
MAIL FROM:<probe@test.invalid>
RCPT TO:<postmaster@$domain>
RCPT TO:<abuse@$domain>
QUIT
EOF

Interpretation:

  • 250 bei RCPT = existiert/akzeptiert
  • 550 5.1.1 = typischer „existiert nicht“
  • 451/421 = temporär – retesten, Rate-Limits beachten
  • „accept-all then bounce“ = Sonderfall – Backscatter-Risiko

D) Der richtige Fix ist banal – und genau deshalb wird er oft nicht gemacht

  • Aliases anlegen
  • auf ein Ticket-/Queue-System routen
  • Filtern/Rate-Limiting, aber kein „User unknown“
  • Monitoring + Eskalation

Das ist kein Hexenwerk. Es ist Hygiene. Genau das macht’s so unbequem.

Epilog – Warum diese Geschichte heute noch zählt

Die Mailwelt hat sich geändert. Die Grundprobleme nicht.

Wenn du heute eine Domain betreibst und irgendwo Mail berührst (warum abuse@ und postmaster@ Pflicht sind) – direkt, über SaaS, über Provider – dann gilt immer noch:

Wenn man dich nicht erreichen kann, existierst du für Incident Response nicht.
Und das Netz ist voll von Leuten, die dir gerne helfen würden, bevor es eskaliert – aber nur, wenn ein Postfach am anderen Ende nicht „User unknown“ sagt.

RFC-Ignorant war keine perfekte Maschine. Aber es war ein klares Signal aus einer Zeit, in der das Netz noch stärker auf freiwillige Betriebskultur angewiesen war.

Eine Agentengeschichte, nur ohne Pistolen.
Stattdessen: DNS, SMTP, und ein 550, der die Welt erklärt.

Fragen? Einfach melden.

Spam aus Schweden

Mir rennt hier gerade eine Kiste aus ?Schweden? ganz schön die Bude ein und versucht seinen SPAM bei mir abzuladen..

Alles von post.lidingo.se[194.22.4.7]… Ein wc -l sagt mir nach einem grep mit | der letzten Stunde: 7606

Die Kiste steht bereits ganz fett in allen möglichen RBL Listen, was ist denn da los? Na ja, für Spaß habe ich noch mal etwas in deren Abuse Mailbox gekippt, vielleicht reagiert ja jemand.

Sind die Schweden jetzt die neuen „Chinesen“? Solche Aktionen bin ich sonst eher von dort gewohnt. Da kann man sich die abuse mail aber auch meist sparen!

So long…

 

 

Fragen? Einfach melden.

Postfix SSL / TLS Cipher Suite Auswertung

Nachdem ich nun am Postfix hinsichtlich der SSL / TLS Sicherheit einige Einstellungen vorgenommen habe und sogar die nutzbare Cipher Suite eingeschränkt habe, da interessiert mich natürlich welche von den Clients genutzt werden. Daher fische ich für meinen Testzeitraum einfach mal per Regex (Regular expression) und egrep ein paar Infos aus dem Logfile und lege es hier zur Begutachtung hin.

So lässt sich nun gut verfolgen, welche Cipher, wie oft genutzt wird.

 

 

Siehe auch: TLS-Infos im E-Mail-Header

Fragen? Einfach melden.

Apache: Sichere SSL/TLS-Verschlüsselung einrichten

Ich habe vor kurzem etwas über sichere SSL / TLS Einstellungen beim Mozilla Firefox geschrieben. Dabei habe ich etwas die Serveradmins in die Pflicht genommen, dafür zu sorgen dass ihre Seite so konfiguriert wird, dass erst überhaupt keine unsicheren Verfahren angeboten werden. Inzwischen sind ein paar Fragen bei mir angekommen wie ich es umgesetzt habe.

Begonnen habe ich mit dem Strict-Transport-Security Header. Sind diese gesetzt, und ein Client verbindet sich verschlüsselt (SSL / TLS) mit dem Webserver sagt ihm der Server: „Schön das du da bist. Ach ja, verbinde dich bitte die nächsten X Tage nur noch verschlüsselt mit mir, ok?“.

Normalerweise richten sich Webbrowser an diese „Bitte“ des Servers. Damit wird verhindert das ein Angreifer den Client überredet sich unverschlüsselt mit einem anderen Server zu unterhalten oder von der verschlüsselten Übertragung zur unverschlüsselten zu wechseln. Denn würde ein solcher Wechsel klappen, könnte der Angreifer ja ab dem Moment mitlesen!

Damit ich nun also die Strict-Transport-Security nutzen kann muss zuerst das Apache Modul headers aktiviert werden. Dieses erledige ich mit:

$ a2enmod headers

 Fehlt nur noch eine weitere Zeile in der vhost Konfiguration:

Header always set Strict-Transport-Security "max-age=15552000"

max-age gibt einen Zeitwert in Sekunden vor. Dieser darf/sollte nicht kleiner als 180 Tage sein. 15552000 entspricht dabei genau 180 Tagen.

Damit wird also schon mal jeder Client für die kommenden 180 Tag versuchen verschlüsselt mit mir zu sprechen. Natürlich ist an dieser Stelle zu bedenken, wenn ich mich plötzlich dazu entscheiden sollte SSL/TLS nicht mehr anzubieten, werden es die Clients denn noch weiter so probieren. Also aufpassen….

Auf zu ssl crime attack… Dieser Angriff ist möglich wenn die SSLCompression aktiviert ist. Ich erweitere also meine Konfiguration des vhosts im Apache um folgende Zeile:

SSLCompression off

Um direkt die unsicheren und veralteten Protokolle zu deaktivieren folgt auf dem Fuße:

SSLProtocol +ALL -SSLv3 -SSLv2

Damit sich gleich alle an die Reihenfolge meiner zugelassenen Cipher Suite halten, gebe ich dieses noch einmal expliziet vor:

SSLHonorCipherOrder On

Fehlen nur noch die zu verwendenden Cipher Suites…. Dabei beginne ich mit den gewünschten Favoriten und gehe Stück für Stück weiter runter. Am Ende verbiete ich noch diese, welche ich auf keinen Fall nutzen will (alles vor dem ein Ausrufezeichen „!“ steht).

SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4

 Nur noch den Apache neu starten und den aktuellen Zustand testen: https://www.ssllabs.com/ssltest/analyze.html?d=kernel-error.de

Noch Fragen? Na dann fragen!

Fragen? Einfach melden.

Unsichere SSL/TLS-Verschlüsselungen im Firefox deaktivieren

Veraltet: Die hier beschriebenen about:config-Einstellungen existieren in aktuellen Firefox-Versionen nicht mehr in dieser Form. Moderne Browser deaktivieren unsichere Protokolle und Cipher automatisch. Dieser Beitrag ist veraltet.

Nach der NSA „Geschichte“ sollte klar sein dass man mehr denn je darauf achten sollte eine möglichst sichere Verschlüsselung zu nutzen. Als Benutzer kann man leider nicht immer Einfluss auf die Gegenseite, den Server nehmen. Um denn noch etwas mehr steuern zu können, dass eine „sichere“ Verschlüsselung benutzt wird kann jeder etwas an seinem Client schrauben.

Warum? Nun ja….. Nehmen wir als Beispiel den Firefox Web Browser. Dieser unterstützt viele verschiedene Protokolle, diese noch in vielen verschiedenen Version und noch mehr Chiffrensammlungen. Die Gegenseite sollte ebenso mehrere Verfahren unterstützten. Der Hintergedanke dabei ist dass sich beide Seiten so auf ein Verfahren einigen können welches beide unterstützen. Wenn man also nun seinen Client nur Verfahren anbieten lässt, welche man als sicher erachtet… Tja, dann können sich beide nur auf ein sicheres Verfahren einigen. OK, wenn der Server nun nichts „sicheres“ anbietet, werden sie sich nicht einig werden. An dem Punkt muss man sich dann fragen ob man wirklich „unsicher“ mit der Gegenseite sprechen möchte oder nicht!

Es ist doch hin und wieder erschreckend, welche Seite nur ~schlechte~ Chipher anbieten. Hier ist wohl, wie so oft per IPv6, ein Weg zur Lösung… Nachfragen. Also den Betreibern einer solchen Seite die Frage stellen, warum geht das nicht?!?! Manche Antworten sind echt lustig.

Ich denke es gibt drei große Punkte an denen man ansetzten kann:

1. Als kleinstes Protokoll TLS1
2. RC4-Stromchiffren komplett deaktivieren
3. Perfect Forwad Secrecy (PFS) vorschreiben

1. Sorgt dafür das der Browser nur noch als sicher bekannte Protokolle nutzt.
2. Wirft die als unsicher geltende RC4 Cipher Suite raus.
3. Sorgt dafür das selbst aufgezeichnete SSL/TLS Verbindungen in der Zukunft nicht so schnell gebrochen werden können, selbst wenn die Rechenleistung deutlich zunimmt.

Im Firefox lässt sich alles schnell und sehr einfach über die Seite: about:config einrichten.

B.t.w.: TLS (Transport Layer Security) ist der Nachfolger, die Weiterentwicklung von SSL (Secure Sockets Layer). Wir sprechen also besser nur von TLS, oder? Zurück zum Text…

1. TLS Version 1.0 als kleinstes unterstütztes Protokoll.
Unter der about:config Seite in der Suche nach security.tls.version suchen. Hier den Wert security.tls.version.max auf 3 und den Wert security.tls.version.min auf 1 setzten.

2. RC4 Cipher Suite deaktivieren.
Wieder über die Suche der about:config Seite nach rc4 suchen. Nun bei allen angezeigten Zeilen den Wert auf false setzten.

3. Perfect Forwad Secrecy (PFS) vorschreiben
Erraten, about:config und die Suche benutzen. Gesucht wird security.ssl3…. Bei den Suchergebnissen nun alle Werte auf false setzten bei denen nicht ECDHE, DHE oder RC4 (wobei die RC4 „Jungs“ sollten ja bereits aus sein) in der Bezeichnung steht.

Seine Einstellungen kann man nun am besten prüfen auf: https://www.ssllabs.com/ssltest/viewMyClient.html

Ach ja…. Die Seite https://www.ausweisapp.bund.de/ kann spannenderweise nicht mehr aufgerufen werden, wenn man diese sicheren Einstellungen in seinem Browser vorschreibt. Lustig, hm?


U-P-D-A-T-E

Wem das alles etwas zu hart ist, der kann bei security.ssl3 den Wert: security.ssl3.rsa_aes_256_sha auf true lassen/setzten. Dieses würde sich zwar vielleicht mit steigender Rechenleistung entschlüsseln lassen. Ist aber aktuell noch recht sicher und wird von mehr Webseiten angeboten als nur auf Diffie Hellman zu setzten.

Oh ja, was man Serverseitig tun könnte findet sich hier…

 

Postfix mit DANE und DNSSEC absichern

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.

SSH Brute Force

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 🙁

netname: CHINANET-JS
descr: CHINANET jiangsu province network
descr: China Telecom
descr: A12,Xin-Jie-Kou-Wai Street
descr: Beijing 100088
country: CN
admin-c: CH93-AP
tech-c: CJ186-AP
mnt-by: MAINT-CHINANET
mnt-lower: MAINT-CHINANET-JS
mnt-routes: maint-chinanet-js
changed: hostmaster@ns.chinanet.cn.net 20020209
changed: hostmaster@ns.chinanet.cn.net 20030306
status: ALLOCATED non-PORTABLE
source: APNIC

role: CHINANET JIANGSU
address: 260 Zhongyang Road,Nanjing 210037
country: CN
phone: +86-25-86588231
phone: +86-25-86588745
fax-no: +86-25-86588104
e-mail: ip@jsinfo.net
remarks: send anti-spam reports to spam@jsinfo.net
remarks: send abuse reports to abuse@jsinfo.net
remarks: times in GMT+8
admin-c: CH360-AP
tech-c: CS306-AP
tech-c: CN142-AP
nic-hdl: CJ186-AP
remarks: www.jsinfo.net
notify: ip@jsinfo.net
mnt-by: MAINT-CHINANET-JS
changed: dns@jsinfo.net 20090831
changed: ip@jsinfo.net 20090831
changed: hm-changed@apnic.net 20090901
source: APNIC
changed: hm-changed@apnic.net 20111114

person: Chinanet Hostmaster
nic-hdl: CH93-AP
e-mail: anti-spam@ns.chinanet.cn.net
address: No.31 ,jingrong street,beijing
address: 100032
phone: +86-10-58501724
fax-no: +86-10-58501724
country: CN
changed: dingsy@cndata.com 20070416
mnt-by: MAINT-CHINANET
source: APNIC

 

 



Siehe auch: SSH-Server absichern mit MFA, Mal wieder auffällig viele Brute-Force SSH Angriffe…., Raspberry Pi als Angriffsziel: SSH-Brute-Force auf den User pi

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑