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 11 von 15)

DNSSEC-fähiger Registrar

In der letzten Zeit häufen sich bei mir die Anfragen, mit welchem Registrar ich zusammenarbeite. Vor allem im Hinblick auf DNSSEC und die DS-Records, die man beim Registrar hinterlegen muss.

Hier kann und möchte ich gerne die SpeedPartner GmbH aus Neuss empfehlen. Damals habe ich dort gerne mit Herrn Metz zusammengearbeitet. Es war immer jemand erreichbar, und auch etwas ungewöhnliche Dinge ließen sich schnell umsetzen. Das Webinterface konnte 2014 noch keine DS-Records entgegennehmen, der Weg per E-Mail funktionierte aber binnen Minuten.

Es kommt selten vor, dass ich hier Werbung für ein Unternehmen mache — dieses hatte es damals verdient.

Mehr zu DNSSEC und BIND gibt es im DNSSEC-HowTo. Fragen? Einfach melden.

TLSA DANE Record für E-Mail in Postfix prüfen: Schritt-für-Schritt-Anleitung

Habe ich ganz aktuell gesehen dass sich über die Webseite ssl-tools.net nun ebenfalls die DANE RECORDS testen lassen. Also einmal ob sie vorhanden sind und natürlich auch die Gültigkeit des RECORDS. Zu dem Thema bin ich ja bereits ein paar mal gefragt worden, da „einfache“ Test Tools noch rar waren. Was sich ja inzwischen endlich zu ändern scheint.

KLICK: https://de.ssl-tools.net/mailservers/kernel-error.de

Siehe auch: TLSA und DANE manuell prüfen

Fragen? Einfach melden.

Gestohlene FTP-Zugangsdaten BSI

WOOOOHOOOOO… Ich habe auch mal so eine E-Mail bekommen.


CERT-Bund Reports <noreply@reports.certbund.net> schrieb am 27.05.2014 11:31:10:

Von: CERT-Bund Reports <noreply@reports.certbund.net>
An: registry@domain.tld
Datum: 27.05.2014 11:31
Betreff: [CERT-Bund#2014052612345678] Gestohlene FTP-Zugangsdaten

Sehr geehrte Damen und Herren,

CERT-Bund hat von einer vertrauenswürdigen externen Quelle eine Liste
gestohlener FTP-Zugangsdaten für in Deutschland gehostete Server erhalten.
Die Zugangsdaten wurden im Rahmen der Analyse eines Botnetzes gefunden
und werden offenbar dazu verwendet, um in mit dem FTP-Account
verbundene Webseiten schädlichen Code einzuschleusen, welcher auf
Drive-by-Exploits verweist. Es liegen leider keine Informationen vor,
wann und wie die Zugangsdaten ausgespäht wurden.

Nachfolgend senden wir Ihnen eine Liste der Zugangsdaten für Server in
Ihrem Netzbereich. Die Passwörter wurden sanitarisiert.

Format: ASN | IP-Adresse | FTP-Login

Wir möchten Sie bitten, den Sachverhalt zu prüfen und Ihre Kunden
entsprechend zu informieren.

Bitte bestätigen Sie den Eingang dieser Benachrichtigung und
informieren Sie uns über die von Ihnen getroffenen Maßnahmen.

Liste der Zugangsdaten für Server in Ihrem Netzbereich:

 12345 | 123.123.123.123  | benutzername:IG******@ftp21.domain.tld

Mit freundlichen Grüßen
Team CERT-Bund

Bundesamt für Sicherheit in der Informationstechnik (BSI) Referat C21 –
CERT-Bund Godesberger Allee 185-189
D-53175 Bonn

————————————————————————
Dies ist eine automatisch generierte Nachricht.
Bitte beachten Sie beim Antworten die Reply-To Adresse.

Siehe auch: E-Mail-Benachrichtigung bei Root-Login

Fragen? Einfach melden.

TLSA- und DANE-Records manuell prüfen: Schritt für Schritt mit OpenSSL

Es gibt inzwischen viele Webtools die TLSA-Records prüfen. Aber wer es einmal von Hand gemacht hat, versteht was dabei passiert. Der Ablauf ist immer gleich: Zertifikat vom Server holen, Hash berechnen, mit dem DNS-Record vergleichen.

Zertifikat holen

Verbindung zum Mailserver aufbauen und das Zertifikat per STARTTLS abholen:

openssl s_client -starttls smtp -connect smtp.kernel-error.de:25 \
  -servername smtp.kernel-error.de 2>/dev/null | \
  openssl x509 -outform PEM > /tmp/server.crt

Das Zertifikat liegt jetzt in /tmp/server.crt.

Hash berechnen

Welchen Hash man berechnen muss, hängt vom TLSA-Record ab. Die drei Felder im Record bestimmen das:

Usage0 = CA, 1 = End-Entity (Kette muss gültig sein), 2 = Trust Anchor, 3 = End-Entity (keine Kettenprüfung)
Selector0 = ganzes Zertifikat, 1 = nur Public Key (SPKI)
Matching Type0 = exakter Vergleich, 1 = SHA-256, 2 = SHA-512

Am häufigsten sieht man 3 1 1 (End-Entity, nur Public Key, SHA-256) oder 3 0 1 (End-Entity, ganzes Zertifikat, SHA-256). Zuerst den TLSA-Record aus dem DNS holen um zu sehen was erwartet wird:

dig _25._tcp.smtp.kernel-error.de TLSA +short

Dann den passenden Hash berechnen. Bei Selector 0 (ganzes Zertifikat) und Matching Type 1 (SHA-256):

# Selector 0 (Full Certificate), SHA-256
openssl x509 -in /tmp/server.crt -outform DER | openssl sha256
# Ausgabe: SHA2-256(stdin)= 94c8e1bd...

Bei Selector 1 (nur SPKI, Public Key) und SHA-256:

# Selector 1 (SPKI), SHA-256
openssl x509 -in /tmp/server.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | openssl sha256

Den berechneten Hash mit dem Wert aus dem TLSA-Record vergleichen. Stimmen sie überein, ist der Record korrekt.

Schnelltest mit posttls-finger

Wer nicht alles von Hand machen will: posttls-finger (Teil von Postfix) prüft den kompletten DANE-Ablauf in einem Schritt:

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

In der Ausgabe steht am Ende entweder Verified TLS connection established (DANE-Prüfung bestanden) oder eine Fehlermeldung mit dem konkreten Problem. Das Tool löst die MX-Records auf, holt den TLSA-Record, baut die TLS-Verbindung auf und vergleicht alles automatisch.

Wer DANE für den eigenen Mailserver einrichten will, findet die Anleitung unter Postfix mit DANE und DNSSEC absichern. Die Grundlagen zu DANE und TLSA-Records erklärt der Beitrag DNSSEC und DANE: TLS-Zertifikate mit TLSA-Records absichern. Fragen? Einfach melden.

Google schaut in die E-Mails seiner gmail Nutzer!

Google schaut in die E-Mails seiner gmail Nutzer, wertet den Inhalt aus und zeigt dem Nutzer dann maßgeschneiderte Werbung…. OK, ist jetzt nichts Neues! Nun hat Google aber bekanntgegeben dass sie zumindest keine Schüler mehr in dieser Form abschnorcheln will.

Slow clap reaction GIF about Gmail privacy

Zu lesen ist es hier: http://googleenterprise.blogspot.de/2014/04/protecting-students-with-google-apps.html

Toll, oder? Super… Alle freuen sich…. ALLE FREUEN SICH! Leute, schlaft ihr alle? Google durchsucht, nach eigenen Angaben, keine E-Mail Accounts von Schülern mehr und SCHÜTZT sie somit vor Werbung welche zu E-Mail Inhalten passt!!!!!

Das ist so als wenn der Postbote die Briefe liest und immer direkt das passende Werbeprospekt beilegt. Warum freuen sich alle? Ich verstehe es nicht, tut mir leid!

Fragen? Einfach melden.

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.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑