postfix: IP-Adresse des Absenders verbergen

Nach langer Zeit gibt es heute mal wieder einen kleinen Post aus der Sysadmin-Ecke.

Die Ausgangslage

Ein Benutzer liefert seine Emails mit Authentifizierung bei einem durch mich betriebenen Mailserver ein, der für die entsprechende Domain zuständig ist.

In den Headern dieser Mail wird nun die IP-Adresse auftauchen, von der aus die Email eingeliefert wurde. Dies kann die IP zu Hause sein, die von einem Bekannten oder die von einer Institution. Postet derjenige häufiger auf Mailinglisten kann man so schon ein Profil erstellen und bekommt auf jeden Fall heraus, dass er z.B. Emails von der Uni aus sendet, etc.

Dies möchte man nun verhindern - und das funktioniert mit postfix Bordmitteln sogar relativ einfach.

Mehr Information ist am Ende doch weniger

Zunächt müssen wir die entsprechenden Header erkennen können. Da bei allen nicht-authentifizierten Emails die IP-Adresse des einliefernden MTA im Header unverändert erhalten bleiben soll, schon um Spammer identifizieren zu können ohne extra in die Logs schauen zu müssen, brauchen wir einen Weg, die passenden Received:-Header zu erkennen. Dies erreichen wir, indem wir dem postfix sagen, dass er den Benutzernamen des Absenders auf dem Mailserver in den Header einfügen soll. Dies geschieht über die Anweisung smtpd_sasl_authenticated_header = yes in der Datei main.cf des postfix.

Unser header sieht nun ungefähr so aus:

Received: from [192.168.101.150] (guest123.guest.example.org [192.0.43.10])
  (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
 (No client certificate requested)
 (Authenticated sender: username)
 by mail.somedomain.tld (Postfix) with ESMTPSA id 32A59B1C032
 for ; Thu, 30 Jun 2011 12:36:07 +0200 (CEST)

Die hervorgehobene Zeile ist neu hinzugekommen und ermöglicht es uns im zweiten Schritt nach genau diesen Headern zu suchen.

pcre ftw!

postfix bietet dafür die Möglichkeit der header_checks. Damit kann man mittels (perl) regular expressions auf den Headern der Email arbeiten und Zeilen einfügen, Zeilen ändern und eigentlich vor allem Aktionen auslösen wie das Aufhalten einer Email, Abweisen, Weiterleiten, etc.

Wir benutzen diese Möglichkeiten, um auf der oben gezeigten Received:-Zeile ein paar Ersetzungen vorzunehmen.

Dazu stellen wir zunächst sicher, dass die main.cf des Postfix auch header checks aktiviert hat:

 smtpd_sasl_authenticated_header = yes
 ...
 header_checks      =  pcre:/etc/postfix/header_checks
 mime_header_checks =  pcre:/etc/postfix/header_checks

Nun koennen wir in der angegebenen Datei header_checks mit folgender Zeile das Umschreiben aktivieren:

/^Received:\ from (.*)\(.*\)(.*)\(Authenticated\ sender:\ .*\)(.*by mail\.somedomain\.tld.*)$/U  REPLACE Received: from $1 (Remote IP hidden) $2(Sender was authenticated on somedomain.tld) $3

Hinweis: Die Zeile ist relativ lang, beim Kopieren aufpassen sie komplett zu erwischen. Wichtig ist die Option U an der Regex, diese schaltet sie auf ungreedy. Siehe man pcre_table.

Der Name des Mailservers taucht hier nochmal auf, damit ich die Original-IP bei extern eingelieferten Emails nicht verwerfe - das kann zum Identifizieren von Spammern helfen, auch wenn die Header oft gefälscht sind.

Im Ergebnis sieht der Header der Email nun aus wie folgt:

Received: from [192.168.101.150]  (Remote IP hidden) 
 (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
 (No client certificate requested)
 (Sender was authenticated at somedomain.tld) 
 by mail.somedomain.tld (Postfix) with ESMTPSA id A36241184685
 for ; Fri, 29 Jul 2011 20:23:31 +0200 (CEST)

Wenn man die private IP auch noch entfernen möchte, kann man sich jetzt natürlich einen weiteren Header-check überlegen, der auf '\[.*\].*Remote IP hidden' triggert und diese ersetzt. Das kann im Einzelfall notwendig werden, wenn kaputte Antispam-Maßnahmen anderer Empfänger solche Emails ablehnen.

Wenn man misstrauisch ist fügt man ausserdem noch eine Zeile hinzu, die jedes Vorkommen von '(Authenticated sender: ...)' mit etwas belanglosem ersetzt, falls man unter allen Umständen die internen Nutzernamen geheim halten will.

Effizienter Desktop mit fluxbox

Nach langer Zeit mal wieder ein kleines Posting von mir. Diesmal zum Thema Organisation des Desktops bzw. Windowmanagers

Vor zwei Tagen bin ich auf der Suche nach einem neuen Windowmanager auf Anregung von Seba auf fluxbox umgestiegen. Flott, schlank, stark konfigurierbar. Auch wenn ich nach wie vor ein paar Gimmicks vermisse, habe ich Features entdeckt, die ich glaube ich nicht mehr missen will.

Dinge die ich vermisse

Der System-Monitor von Gnome war doch ganz praktisch. Man konnte in einem Panel die CPU-Auslastung sehen und den Speicherverbrauch. Aktuell habe ich nur die CPU-Auslastung beider CPUs ohne Unterscheidung in Nice, System und IO-Wait. Die wmaker-Docks sind mir zu groß und außerdem nicht im Panel. Ein 'swallow' wie damals beim fvwm2 wäre toll, um Anwendungen in das Panel einzubinden.

Die Arbeitsflächen lassen sich nicht zweidimensional anordnen, d.h. ich kann immer nur nach links und rechts, nicht nach oben und unten wechseln. Das war aber relativ effizient, um schnell zwischen Anwendungen zu wechseln. Eine Sache der Gewöhnung, hoffe ich.

Das Killer-Feature

Eines der Killer-Features schlechthin ist aber die Möglichkeit, beliebige Aktionen, per MacroCommand auch mehrere, auf Tastaturshortcuts zu legen.

Nicht nur, dass man damit Dinge wie das Maximieren oder Umschalten der Arbeitsflächen anpassen kann, man kann auch neue Funktionalität schaffen, zum Beispiel einer Anwendung eine Tastenkombination zuordnen und sie nur dann starten wenn sie noch nicht läuft.

Aktuell ist mein fluxbox nun so konfiguriert, dass Programme wie Firefox, Thunderbird, etc. eine Tastenkombination haben, die entweder auf die Arbeitsfläche mit der Anwendung umschaltet und sie anzeigt oder aber eine Dialogbox aufpoppt mit der Frage, ob sie gestartet werden soll. Zusätzlich ist den Anwendungen eine Arbeitsfläche und Größe fest zugeordnet, auf der sie starten sollen.

Läuft die Anwendung also noch nicht, startet sie unsichtbar auf ihrer Arbeitsfläche und ich kann dann später dorthin umschalten, sobald sie bereit ist.

Gerade das Umschalten zum Instant-Messenger oder Mediaplayer und wieder zurück zum Browser oder der IDE ist damit sehr schnell möglich.

Hinweis: Eventuell klappt das nur mit der aktuellen git-Version von fluxbox, da NextWindow unter Umständen nicht alle Workspaces durchsucht.

Hier die relevanten Auszüge:

~/.fluxbox/keys:

Mod4 C :Reconfigure
Mod4 F :If {Some Matches (class=Iceweasel)} {NextWindow (class=Iceweasel)}  {Exec ~/.fluxbox/bin/fbexec.sh iceweasel}
Mod4 G :If {Some Matches (class=Gmpc)     } {NextWindow (name=gmpc) (class=Gmpc)} {Exec ~/.fluxbox/bin/fbexec.sh gmpc }
Mod4 M :If {Some Matches (class=Icedove)  } {NextWindow (class=Icedove) } {Exec ~/.fluxbox/bin/fbexec.sh icedove}
Mod4 P :If {Some Matches (class=Pidgin)   } {NextWindow (class=Pidgin)  } {Exec ~/.fluxbox/bin/fbexec.sh pidgin }
Mod4 R :If {Some Matches (class=RSSOwl)   } {NextWindow (class=RSSOwl)  } {Exec ~/.fluxbox/bin/fbexec.sh ~/bin/RSSOwl.sh}

Anm: Mod4 ist die 'Windows'-Taste. Die Werte für class habe ich der apps-Datei entnommen, die fluxbox automatisch erweitert, wenn man mit der rechten Maustaste auf eine Titelleiste klickt und 'Remember' anklickt um Attribute wie den Workspace der Anwendung zu speichern. Alternativ geht auch xprop oder wmctl -l ~/.fluxbox/apps:

...
[app] (name=Navigator) (class=Iceweasel) (role=browser)
  [Workspace]   {5}
  [Dimensions]  {1198 682}
  [Position]    (UPPERLEFT)     {0 80}
[end]
...

~/.fluxbox/bin/fbexec.sh:

#!/bin/sh

#timeout returnes 0 (success) thus we have to use || here:
xmessage -center -buttons 'yes:1,no:0'  -timeout 5 "about to exec $@" || exec "$@"

Mein Dockstar lebt wieder...

So. Es ist wieder einmal passiert. Ich habe mir Hardware zum Spielen gekauft.

Diesmal: Ein FreeAgent DockStar Network Adapter von Seagate.

Das Schätzchen hat 128MB Ram und 256MB Flash on Board, eine nette ARM CPU, Gigabit-Netzwerk und 4 USB-Ports. Details finden sich zu Hauf im Netz.

Was mich besonders interessiert hat, war die in der CPU vorhandene Crypto-Unit, die sha1, md5 und aes in Hardware berechnen kann.

Linuxkernel

Leider ist es mit der Unterstützung dieser Einheit im offiziellen Kernel noch nicht so wahnsinnig weit - bisher wird das ganze nur rudimentär angesprochen (z.B. kein DMA), so dass es nicht wirklich Spaß macht, das ganze zu nutzen. (1-2MB/s Gewinn)

Etwas mehr verspricht hier ein Kernel des Herstellers - und voilá, GPL-sei-dank gibt es da auch was passendes. Oder naja, etwas das man für passend halten kann.

Vorweg: Ja, ich habe den Kernel letztlich übersetzt bekommen, man darf nur nicht so wahnsinnig sein, und an der config großartig Dinge ändern wollen - weil dann knallt es. Und zwar richtig mit Compiler-Fehlern und Syntax-Errors in den Kernelquellen.

Letztlich habe ich jedenfalls 15MB/sec von einer verschlüsselten USB-Platte lesen können statt 6-7 ohne Hardwareunterstützung.

Details zum Kernel folgen, sobald ich einen stabilen build habe und das dokumentieren kann. Ausserdem will ich die LEDs aus dem Kernel heraus ansprechen können, die GPIO-Konfiguration habe ich im Prinzip bereits.

uBoot - der Bootloader

Damit ich dieses System bequemer booten kann, wollte ich dann einen neuen uBoot bauen.

Die Cross-compiler-chain war ja schon von kernel vorhanden - sollte also alles kein Problem sein. Dachte ich.

Die Konfiguration des DockStar unterscheidet sich leider etwas von der des Sheeva-Plugs. So ist nur die Hälfte des Rams vorhanden, ausserdem sind die beiden LEDs an andere GPIO-Pins angeschlossen.

Kaputtgeflasht

Was mir letztlich das Genick brach war aber ein dummer Fehler: Ich habe das uBoot-Binary direkt in den Flash des DockStar gebrannt - statt des kwb-Images, das die Hardwarekonfiguration enthält.

Letztlich habe ich nun 4 verschiedene Jtag-Adapter hier gehabt, davon zwei selbstgebaute. Der letzte, ein wiggler, funktionierte schließlich - wenn auch nur mit 50kHz statt 500. (Kabellänge)

Folgende Fallen begeneten mir dabei:

• 74HC244 falschrum im Sockel. Gute Heizwirkung, der Chip hats überlebt, mein Zeigefinger auch...
• Kabel zu lang und zu wenig abgeschirmt
• Ein funktionierender DockStar hat das JTAG deaktiviert und ist zum Testen ungeeignet!

Vor allem der letzte Punkt mit dem funktionierenden DockStar hat mich etliche Stunden gekostet. Aber wer rechnet schon damit -.-

Ausblick

Die folgenden Posts werden ausführlich das Wiederbeleben des DockStars, die korrekte Konfiguration des Bootloaders für diese Plattform und die Konfiguration des Kernels enthalten.

Der Bootloader kann hier jedenfalls schon die LED's ansprechen, dem Kernel werde ich das wohl auch noch beibringen. TODO's sind aber noch die Konfiguration des Speichers im uBoot.

md-raids aus USB-Platten und automatische Checks...

Falls ihr externe USB-Platten als Raid einsetzt, werdet ihr wissen, dass es mitunter Tage dauern kann, bis ein Rebuild oder Check des Raids komplett ist:

md4 : active raid5 sdc[0] sdf[3] sde[2] sdd[1]
      2930287488 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
      [>....................]  check =  0.9% (8861912/976762496) finish=1374.5min speed=11735K/sec

Falls ihr euch nun wundert, warum das Raid an einem Sonntag Abend auf einem Debian System sehr träge reagiert und 50% der CPU durch einen Thread mit dem Namen md4_raid5 belegt sind, empfehle ich euch mal den Cronjob des mdadm anzusehen.

Dieser läuft am ersten Sonntag jedes Monats und prüft das Raid auf Konsistenz. Einerseits recht nützlich kann es aber auch störend sein - dauert es doch wie gesagt relativ lange. Zudem gibt es unter Debian bei manchen Installationen einen Bug, so dass der Cronjob jeden Sonntag läuft.

Um einen laufenden Check abzubrechen genügt ein:

/usr/share/mdadm/checkarray -x --all

Der Cronjob ist in der /etc/cron.d/mdadm definiert.

Komplett deaktivieren ist aber auch unschön, weil es das Erkennen von Fehlern auf dem Raid verhindert. Bei Mirror-Raids ist das Fatal, beim Ausfall einer Platte in einem Raid5 ebenfalls, weil dann unter Umständen keine reduntenten Informationen zum Wiederherstellen vorhanden sind.