Raes Blog

Wenn Seahorse sich weigert, den privaten SSH-Key zu laden, obwohl er unter ~/.ssh/id_dsa oder id_rsa liegt und laut Dokumentation automatisch geladen werden sollte, und auch ein Import fehlschlägt mit der Meldung, der Schlüssel läge im falschen Format vor, dann liegt das vielleicht daran, dass der öffentliche Schlüssel nicht auch dort liegt oder falsch benannt ist.

Gemeine Sache, die einen viele Nerven kosten kann...

Wie mittlerweile auch heise festgestellt hat, rollt seit März eine anhaltende Backscatter-Welle durchs Netz und macht Mailserver-Betreibern das Leben schwer. Darum geht es mir hier und jetzt aber eigentlich nicht, daher an dieser Stelle lediglich der Hinweis, dass es hier ein hilfreiches HowTo für Postfix gibt, mit dem man sich recht effektiv des Zeuges entledigen kann. Falls ich Zeit und Lust dazu finde, werde ich hier im Blog auch mal ein kleines HowTo posten, wie ich des Problems auf meinem Server Herr geworden bin.

Ganz Themenfremd ist das aber nicht, denn es geht auch jetzt um SPAM und dessen Bekämpfung auf einem Postfix-Server. Diesmal stehen gar lustige Gesellen im Vordergrund, deren Mailserver behaupten, aus nicht erlaubten bzw. möglichen Netzen zu stammen, die zumindest alles andere tun sollten, als von dieser Adresse aus Mails an öffentlcihe Server abzuliefern.

Netterweise stellt IANA.org unter anderem eine Liste bereit zum derzeitigen Verwendungsstatus der IPv4-Adressen. Noch netter ist, dass diese Liste in einem gut maschinenles- und parsebaren Format daherkommt - man muss sich manuell nur um die historisch gewachsenen Sonderfälle wie die Kapriolen im 192.0.0.0/8-Netz kümmern, die aber auch keinen Änderungen unterworfen sind.

Was man damit machen soll und warum überhaupt kümmern? Wenn z.B. auf dem externen Interface ein Server eine Mail einliefern will, der meint, eine IP-Adresse wie 10.0.8.15, 192.168.42.23 oder 169.254.47.11 als Absende-Adresse kommunizieren zu können, dann will jemand entweder was böses tun, oder aber der Server ist bestenfalls hoffnungslos falsch konfiguriert. Der Unterschied ist unerheblich, da man in beiden Fällen von diesem Server keine Mails haben möchte. Genauso verhält es sich mit Netzen, die nicht vergeben sind oder als Multicast-Netze dienen. Diese Stati kann man alle hervorragend aus der o.g. Liste von IANA herausfinden, in eine Datei packen, die von Postfix (mutmasslich auch von anderen Mailserver-Programmen) verwertet werden kann, um die entsprechenden Server mit solchen komischen Angaben gleich auf SMTP-Ebene abzuweisen.

Da es lästig ist, immer wieder die Liste aufzurufen und auf Änderungen gegenüber der im Mailserver verwendeten Liste zu prüfen, ist es dank der weiter oben erwähnten, leichten Maschinenlesbarkeit der Liste eine prädestinierte Aufgabe für ein kleines Shell-Script, was regelmäßig die Aufzählung der "verbotenen" Netze auf den aktuellen Stand bringt. Das habe ich umgesetzt und nun liegt hier eine Datei im CIDR-Format mit allen für den direkten Mailversand unzulässigen Netzen bereit, die täglich gegen 1:30 Uhr nachts per Cronjob aus den aktuellen Daten der IANA.org erstellt wird.

Der Aufbau der Datei ist folgendermaßen:
In der ersten Spalte steht das betreffende Netz, also z.B. 192.168.0.0/16, dann folgt die Anweisung, wie Postfix damit zu verfahren hat, wenn der fremde Mailserver vorgibt, aus diesem Netz zu kommen (in dieser Konfiguration ganz RFC-konform ein REJECT = Ablehnen), danach weiterführende Informationen zu der Ablehnung, die im eigenen, sowie - falls dort aktiviert - auch im fremden Mailserverlog auftaucht (für dieses Netz lautet die Meldung "mail server in RFC 1918 private network").

Man unterstellt ja zunächst das Positive: Dem Admin des fremden Mailservers ist ein Fehler in der Konfiguration unterlaufen - und so bekommt er über die Logs die Chance zu erkennen, was nicht stimmt und kann mit der Information das Problem besser lokalisieren.

In Postfix ist diese Datei auch ganz leicht zu integrieren:
Man öffnet die /etc/postfix/main.cf und fügt in die smtpd_*_restrictions (am Besten eignen sich die smtpd_recipient_restrictions) folgende Zeile hinzu:

check_sender_mx_access cidr:/etc/postfix/mx_access.cidr,

(das Komma am ende nicht vergessen, wenn es nicht der letzte Eintrag bei den Restrictions ist)

Die CIDR-Datei muss dann natürlich dort auch vorhanden sein, wenn Postfix sie verwenden soll, also cd /etc/postfix/ && wget http://datenhalde.tuxhilfe.de/mx_access.cidr. Damit Postfix die Konfigurationsänderung auch berücksichtigt, sollte ein reload genügen, sicher geht man aber mit einem beherzten /etc/init.d/postfix restart.

Da der jeweilige Status der Netze kein auf ewig festgeschriebenes Dogma ist, kommt man nicht umhin, wie oben erwähnt, diese Liste immer mal wieder zu aktualisieren. Das kann man bequem per Cron machen. Also crontab -e aufrufen und folgende Zeile hinzufügen:

0 4 * * 0 cd /etc/postfix/ && wget http://datenhalde.tuxhilfe.de/mx_access.cidr && /etc/init.d/postfix reload

Jetzt wird jeden Sonntag morgens um 4:00 Uhr die aktuelle Version der Datei geholt und Postfix veranlasst, seine Konfiguration neu einzulesen. Ich bin mir nicht sicher, ob Letzteres wirklich nötig ist, aber schaden kann es nicht.

Nun ist ja wirklich lange nichts mehr passiert hier. Als Ausrede bringe ich an, dass dafür in meinem Leben umso mehr passiert ist

Seit nunmehr einem knappen Monat befinde ich mich in einem neuen Arbeitsverhältnis, wie der ein oder andere Leser vielleicht schon über andere Kanäle mitbekommen hat. Der neue Job macht eine Menge Spaß. bietet ein angemessenes Gehalt, ist aber auch recht fordernd, sodass ich abends seltener die Lust habe, meinen Senf hier im Blog oder anderswo abzusondern, solange die Abende noch immer recht kurz sind und ich mich in die neue Situation eingewöhne.

Allerdings darf ich mich bei meinem neuen Arbeitgeber durchaus mit interessanten Projekten beschaeftigen, deren Erfahrungen ich hier sicherlich demnächst zum Besten geben werde - wie z.B. ein meiner Meinung nach spannendes Mailserver-Setup mit einigen gar wunderlichen Fußangeln, oder die anstehende Migration von CVS (zu vermutlich SVN), wo unter Garantie auch noch die ein oder andere Überraschung auf mich wartet.

Außerdem stehen demnaechst auch voraussichtlich ein paar Neuerungen an, die TuxHilfe betreffen - da stehen auch ein paar nette Dinge in der Warteschlange. Die müssen sich aber leider auch dem Zeitdiktat beugen und abwarten, bis sie an der Reihe sind.

So, das soll erstmal genug Lebenszeichen gewesen sein, in naher Zukunft wird sich wieder ein bisschen was bewegen, hier.

Wie soeben bekannt wurde, hat AMD die 2D-Spezifikationen der ATI-Grafikchips offengelegt.

Nun machen sie also Ernst. Die über 900 Seiten starke Dokumentation liegt unter http://www.x.org/docs/AMD/ bereit. Weitere Dokumentation (inklusive der 3D-Spezifikationen) soll folgen.

Danke! Ein Grund, den nächsten Grafikkarten-Kauf noch etwas hinauszuzögern..

Nachtrag: Laut Slashdot soll sogar der neue OpenSource-Treiber für die R500/R600-Serie noch vor Ablauf nächster Woche erscheinen. Na da müssen sich die Jungs aber zügeln, wenn sie ihre bisherige Roadmap einhalten und den 3D-Treiber erst irgenswann in 2008 fertigstellen wollen. Der freie 2D-Treiber sollte ja auch erst "bis Ende 2007" erscheinen...