Die alten Pharaonen scheuten keinen Aufwand, um ihre Pyramiden aufzutürmen. Ähnlich mühsam wäre es heute, wollten Admins jedes Mailprogramm PGP-fähig ausstatten. Die neuen IT-Götter manipulieren mit Anubis: Der Daemon nimmt Nachrichten vom Client entgegen und ergänzt, was der nicht schafft.

Persönliche Daten, vertrauliche Verträge oder die geheimen Pläne des neuen Ein-Liter-Autos unverschlüsselt durchs Netz schicken ist ebenso gefährlich wie üblich. PGP, GnuPG [2] und S/Mime sind den meisten Anwendern fremd, es fehlt an Verständnis, Akzeptanz und einfacher Bedienbarkeit. Der IT-Leiter kann das bejammern oder kurzerhand selbst für Abhilfe sorgen: So genannte PGP-Server verwalten die Schlüssel der Benutzer zentral und sorgen für das Ver- und Entschlüsseln auf dem Server. Folglich entfällt die lästige Installation und Konfiguration eines PGP-Programms auf den Arbeitsstationen aller Nutzer.

Linux-Admins haben freie Programme wie GPG-Relay [3] oder Kuvert [4] zur Wahl, der Markt bietet weitere Applikationen (etwa [5] bis [9], teils auch für Windows). Soll’s keine Spezialsoftware sein, steht auch das universelle Mail-Manipulationsprogramm GNU Anubis ([1], ägyptischer Schutzgott) zur Verfügung. Anubis klinkt sich in den SMTP-Verkehr ein und verarbeitet E-Mail auf vielfältige Weise. Unter anderem verschlüsselt es Mails mit GnuPG. Die ausgereifte Open-Source-Lösung ermöglicht den Aufbau einer zentralen PGP-Infrastruktur.

Eintreffende E-Mails automatisch zu entschlüsseln oder den PGP/Mime-Standard fürs Verarbeiten von Datei-Anhängen einzusetzen erfordert zwar ein Programm wie GPG-Relay oder Kuvert, mit Anubis gelingt es aber bestens, die ausgehende Mail zu verschlüsseln und zu signieren.

Arbeitet als SMTP-Relay

Eine herkömmliche E-Mail-Infrastruktur ist in Abbildung 1 dargestellt. Zwei Mailprogramme (Mutt und Mozilla Thunderbird) versenden Nachrichten über je einen Internetmail-Provider. Um die Nachrichten zu verschlüsseln oder zu signieren, ist ein PGP-Plugin wie Enigmail [12] notwendig. Abbildung 2 zeigt den geänderten Aufbau mit GNU Anubis, beschränkt sich aber auf einen Client.

Der Benutzer (1) sendet seine Mails nicht mehr direkt über seinen Mail-Provider (3), sondern indirekt über die Anubis-Software (2). Sie fungiert als Mittler, formt den Inhalt der Nachricht um, signiert oder verschlüsselt sie und verschickt sie schließlich wie gehabt über den Provider. Dabei kann Anubis auf einem getrennten Server laufen oder demselben Rechner wie Client oder MTA. Der Benutzer muss in seinem E-Mail-Client den Anubis-Rechner als Mailserver eintragen (siehe Kasten “SMTP unterschieben”).

Installation

Konfiguration und Installation von Anubis verlaufen dank Autoconf reibungslos. Wichtig ist es jedoch, vorab festzulegen, in welcher Datenbank die Benutzerdaten liegen sollen. Im so genannten Pixie-Modus ist es auch möglich, die User über einen Ident-Daemon auf ihrer Arbeitsstation zu authentifizieren. Diese Variante kommt ohne relationales Datenbanksystem aus. Es ist auch möglich, alle Module zu kompilieren und sich später für einen Aufbau zu entscheiden:

• Regex (Unterstützung für reguläre
  Ausdrücke)
• GSASL (Benutzerauthentifizierung)
• Das Modul zur Authentifizierung per Ident-Daemon ist immer
  enthalten
• Guile (Scripting)
• OpenSSL oder GnuTLS (SSL-Unterstützung)
• GPG (GNU Privacy Guard) und GPGme
• MySQL (Datenbank)
• PostgreSQL (Datenbank)
• GDBM und Textdatei (diese Datenbankvarianten sind immer
  enthalten)

Weitere Komponenten sind optional und nur für bestimmte Szenarien sinnvoll:

• PAM (Authentifizierung)
• Libwrap (TCP-Wrapper)
• SOCKS (SOCKS-Unterstützung)
• NLS (Internationalisierung)
• PCRE (Regex mit Perl-Syntax)

Leider unterstützt Anubis keinen LDAP-Verzeichnisdienst. Das wäre vorteilhaft, da sowohl Benutzerdaten als auch PGP-Schlüssel oft schon in einem OpenLDAP- oder Active-Directory-Server vorliegen. Anubis nutzte lange Zeit ausschließlich Text- oder GDBM-basierte Datenbanken, die Unterstützung relationaler Systeme ist noch sehr neu. Bleibt zu hoffen, dass LDAP-Unterstützung bald folgt.

Ob jedes Modul richtig konfiguriert ist, steht nach dem »./configure«-Lauf am Ende der Datei »config.log«. Nach erfolgter Installation zeigt der Aufruf »anubis –show-config-options«, ob die gewünschten Module auch tatsächlich verfügbar sind. Seine Konfiguration erwartet Anubis in »/etc/anubisrc«. Der Pfad ist fest in »src/header.h« eingetragen, lässt sich zur Laufzeit aber mit »–altrc Datei« ändern. Der »make install«-Lauf erzeugt noch keine Konfigurationsdatei, eine Vorlage befindet sich aber im Quellpaket unter »examples/2anubisrc«.

hostname = anubis.abyssworld.de:24
username = "haischt"
password = "access4anubis"
starttls = disabled

set sendmail="/usr/local/bin/esmtp"

Persönliche Konfiguration

Zudem darf jeder Nutzer, der über den Anubis-Daemon Mails verschicken möchte, eine »~/.anubisrc«-Datei in seinem Homeverzeichnis erzeugen. Ein Beispiel hierfür gibt »examples/1anubisrc«. Für erste Tests bietet der Anubis-Daemon eine Debugging-Betriebsart:

anubis --altrc /usr/local/etc/anubis/U
anubisrc --mode=transparent -v -D -f

Anubis arbeitet bei diesem Aufruf im transparenten Modus ohne eigene Authentifizierung, gibt sich gesprächig mit »-v«, erzeugt Debugging-Ausgaben mit »-D« und bleibt im Vordergrund (»-f«), statt sich als Daemon von Standardein- und Ausgabekanälen loszulösen.

Abbildung 1: Bei einer herkömmlichen E-Mail-Infrastruktur übergibt jeder Client (MUA, Mail User Agent) seine Nachrichten an einen SMTP-Server (MTA, Mail Transfer Agent), der sich um die Zustellung kümmert.

Abbildung 2: GNU Anubis schaltet sich zwischen MUA und MTA in den SMTP-Verkehr ein. Aus Sicht des Clients ist Anubis der Mailserver. In dieser Lage kann er Nachrichten beliebig umformen, sie zum Beispiel verschlüsseln.

Pixie-Authentifizierung

Die Identität eines Benutzers stellt Anubis auf verschiedene Weisen fest. Eine einfache Authentifizierungsvariante ist der Pixie-Modus, aktiviert durch den Eintrag »mode transparent« im Control-Block der globalen Konfigurationsdatei. Auf der Arbeitsstation des Nutzers läuft dazu ein Ident-Daemon (»AUTH«-Protokoll). Erst nach erfolgreicher Authentifizierung nimmt Anubis die Mail entgegen (siehe Abbildung 3).

Diese Technik ist allerdings nur unter sehr engen Voraussetzungen sinnvoll: Der Server muss den Angaben des Ident-Daemon vertrauen. Diese Form der Client-seitigen Sicherheitsprüfung funktioniert aber nur, wenn Workstation und Server von vertrauenswürdigen Admins betreut werden, dieselben Benutzer kennen und sich niemand am Netzwerk zu schaffen macht. In der Praxis ist von dieser Variante abzuraten.

Abbildung 3: Im Pixie-Modus fragt Anubis zunächst den Ident-Daemon auf der Workstation des Absenders, welcher User die Verbindung geöffnet hat, bevor er die Mail annimmt und verarbeitet.

Abbildung 4: Der Anubis-Server verwendet im Dixie-Modus das SMTP-AUTH-Verfahren, um den Benutzer sicher zu authentifizieren. Der Server hält dazu Benutzername und Passwort des Users in einer Datenbank vor.

Praktisch, aber unsicher

Anders als der Protokollname AUTH vermuten lässt, führt Identd keine Authentifizierung durch [15]. Der Daemon ist dafür gedacht, Angriffe zurückzuverfolgen: Der Admin des attackierten Systems fragt per Ident nach, welcher Benutzer auf dem Quellrechner eine TCP-Verbindung gestartet hat. Mit diesen Daten wendet er sich an den Admin-Kollegen, der die Quelle betreut. Viele Ident-Implementierungen antworten schlicht mit einer Default-Kennung ([10], [11]).

Listing 1 stellt eine Anubis-Session im Pixie-Modus dar. Interessant sind Zeile 6 (Ident-Athentifizierungsversuch) und Zeile 8, in welcher der Mail-Nutzer auf den lokalen Unix-Account »haischt« abgebildet wird. Nach dieser Authentifizierungsphase reicht der GNU-Anubis-Daemon die Nachricht an den Mailserver weiter (Zeilen 11 bis 14).

Auf Windows XP als Clientsystem stört oft die eingebaute Firewall während der Testphase. Sie unterdrückt – aus durchaus nachvollziehbaren Gründen – in der Standardkonfiguration alle Ident-Requests auf Port 113. Das gilt es zu ändern (Port 113 freigeben oder Firewall abschalten). Außerdem darf im Pixie-Modus das Mailprogramm keinen SMTP-AUTH-Benutzernamen verwenden.

01 > Reading system configuration file /usr/local/etc/anubis/anubisrc...
02 > UID:0 (root), GID:0, EUID:0, EGID:0
03 > GNU Anubis bound to 192.168.1.6:24
04 > [68239] GNU Anubis is running...
05 > [68239] Connection from 192.168.120.239:1310
06 > [68244] IDENT: connected to 192.168.120.239:113
07 SERVER >>> 1310, 24 : USERID : UNIX : haischt(36)
08 > [68244] IDENT: resolved remote user to  haischt.
09 > [68244] UID:65534 (nobody), GID:65534, EUID:65534, EGID:65534
10 > [68244] Getting remote host information...
11 > [68244] Connected to 192.168.1.6:25
12 > [68244] Transferring message(s)...
13 SERVER >>> 220 smtp.abyssworld.de ESMTP Postfix (2.2.3)(46)
14 CLIENT <<< 220 smtp.abyssworld.de (GNU Anubis v4.0) ESMTP Postfix (2.2.3)(64)

Dixie, die bessere Alternative

Neuer und besser als Pixie ist der Dixie-Modus (Abbildung 4). Er basiert auf dem SMTP-AUTH-Standard. Benutzername, Passwort und andere Userdaten liest Anubis aus einer Datenbank (einfache Textdatei oder relationales Datenbanksystem). Die Textvariante enthält die Benutzerkennung (SMTP-AUTH-ID), das Passwort sowie optional den Unix-Account und den Pfad zur benutzerbezogenen Konfiguration (Tabelle 2).

Jeder User steht in einer eigenen Zeile der Textdatei, die Felder sind durch ein Leerzeichen getrennt. Laut offizieller Dokumentation sollte zwar ein Doppelpunkt als Feldtrenner dienen, aber selbst in Anubis 4.0 funktioniert diese Syntax nicht. Die Textvariante ist für erste Tests und für kleinere Umgebungen ideal. Wer viele User verwaltet, verwendet lieber eine Datenbank. Abbildung 5a zeigt ein passendes Tabellenschema.

Das Feld »authid« ist als Primärschlüssel definiert; alle Felder sind vom Typ Text. Abbildung 5b lässt erkennen, dass der Inhalt der Tabelle ein genaues Abbild der Textdatei ist. Folgender Befehl importiert das Textfile in die MySQL-Datenbank:

anubisadm --create 'mysql://mail:access4anubis@mysql.abyssworld.de/mail;table=anubis_test' < /usr/local/etc/anubis/anubisdb.txt

Das Kommando gibt die Zieltabelle explizit als URL-Parameter an – leider eine etwas irreführende Nomenklatur, da die Parameter nicht wie bei einer HTTP-Adresse durch ein Et-Zeichen (&), sondern durch ein Semikolon getrennt sind. Die URL und ihre einzelnen Parameter stehen in Anführungszeichen, da sich sonst schon die Shell für den Strichpunkt zuständig fühlt.

Datenbank einbinden

Damit Anubis die neue Tabelle verwendet, wechselt der Admin den Authentifizierungsmodus im Control-Abschnitt der globalen »anubisrc«-Konfiguration von »mode transparent« auf »mode auth« (Listing 2, Zeilen 1 bis 5) und ergänzt in der »AUTH«-Sektion (Zeilen 7 bis 15) den Ort, an dem die Benutzerdaten liegen. Listing 2 zeigt dies für eine MySQL-Datenbank. Zudem muss jeder User sein Mailprogramm dazu bringen, sich beim Verschicken einer Nachricht via SMTP-AUTH zu authentifizieren.

Eine erfolgreiche Dixie-Session ist in Listing 3 dargestellt. Ab Zeile 7 nimmt ein Mailprogramm mit dem Anubis-Daemon Verbindung auf. Es ist in der Lage, sich über die SASL-Mechanismen DIGEST-MD5 und CRAM-MD5 zu authentifizieren. Beide Verfahren übertragen nur einen Passwort-Hash statt des Klartextpassworts über das Netzwerk.

Zeile 9 lässt erkennen, dass das Mailprogramm über den »STARTTLS«-Befehl eine sichere SSL-Verbindung zum Anubis-Daemon aufbauen will. Das scheitert, weil Anubis dafür noch nicht konfiguriert ist. In Zeile 16 einigen sich Mailprogramm und Anubis auf den SASL-Mechanismus CRAM-MD5. Der Daemon sucht dann in MySQL nach einem Datensatz, der auf den Benutzer »haischt« mit zugehörigem Passwort passt, und findet diesen auch (Zeilen 18 bis 20).

01 ---BEGIN CONTROL---
02 # ...
03 mode auth
04 # ...
05 ---END---
06 
07 ---BEGIN AUTH---
08 smtp-greeting-message ESMTP Anubis (4.0.0)
09 smtp-help-message help message
10 ## Einfache Textdatenbank:
11 # sasl-password-db file:/usr/local/etc/anubisdb.txt
12 ## Relationale MySQL-Datenbank
13 sasl-password-db mysql://mail:access4anubis@mysql.abyssworld.de/mail;table=anubis_user
14 sasl-allowed-mech NTLM GSSAPI DIGEST-MD5 CRAM-MD5
15 ---END---
16 
17 ---BEGIN TRANSLATION---
18 #translate [USER@]ADDRESS into USERNAME
19 translate me@daniel.stefan.haischt.name into haischt
20 ---END---

01 > Reading system configuration file /usr/local/etc/anubis/anubisrc...
02 > UID:0 (root), GID:0, EUID:0, EGID:0
03 > GNU Anubis bound to 192.168.1.6:24
04 > [68643] GNU Anubis is running...
05 > [68643] Connection from 192.168.120.10:40501
06 CLIENT <<< 220 abyssone.abyssworld.de GNU Anubis ESMTP; Identify yourself(64)
07 CLIENT >>> EHLO [192.168.121.2](22)
08 CLIENT <<< 250-Anubis is pleased to meet you.(36)
09 CLIENT <<< 250-STARTTLS(14)
10 CLIENT <<< 250-AUTH DIGEST-MD5 CRAM-MD5 (31)
11 CLIENT <<< 250 HELP(10)
12 CLIENT >>> STARTTLS(10)
13 [68647] anubis.pem: No such file or directory
14 CLIENT <<< 454 TLS not available due to temporary reason(47)
15 CLIENT >>> AUTH CRAM-MD5(15)
16 SASL mech=CRAM-MD5, inp=NULL
17 CLIENT <<< 334 PDE0MTU0NTMyOTUzMDA2MzI0MTIzLjBAbG9jYWxob3N0Pg==(54)
18 CLIENT >>> aGFpc2NodCA5ZmQ1MDhkYTYzYzQ3ODRiOGUwMzMzZTNhMmUyM2VjZQ==(58)
19 > [68647] Found record for `haischt'.
20 > [68647] Authentication passed. User name haischt, Local user haischt. Welcome!
21 CLIENT <<< 235 Authentication successful.(32)
22 > [68647] UID:1001 (haischt), GID:20, EUID:1001, EGID:20
23 > [68647] Reading user configuration file /home/haischt/.anubisrc...
24 > [68647] Getting remote host information...
25 > [68647] Connected to 192.168.1.6:25
26 > [68647] Starting SMTP session...
27 SERVER >>> 220 smtp.abyssworld.de ESMTP Postfix (2.2.3)(46)

Ein interessantes Detail verbirgt sich in Zeile 20. Anubis bildet den Nutzer mit der Mailadresse »me@daniel.stefan.haischt.name« auf den lokalen User »haischt« ab. Für das Mapping von Mailadressen auf lokale Namen ist die Sektion »TRANSLATION« zuständig (zu sehen in den letzten vier Zeilen von Listing 2). Sie kann auch alle Adressen, die zu einer Domäne gehören, auf einen gemeinsamen Namen abbilden (»translate Domain into User«).

Der Dixie-Modus ist gut gelungen, baut er doch auf aktuellen Standards wie SMTP-AUTH auf. Zudem ist es mit ihm möglich, dass auch Mail-Nutzer ohne Unix-Account den Service verwenden. Der Dixie-Modus hat jedoch in der aktuellen Implementierung noch einige störende Schwächen:

• Passwörter stehen in der Datenbank als Klartext.
• Das Datenbankfeld für die Anubis-Konfigurationsdatei des
  Anwenders verweist auf eine real existierende Datei. Oft wäre
  es praktischer, alle Parameter in einem BLOB-Feld oder in einer
  eigenen Tabelle abzulegen.

Mit Kenntnis des Benutzernamens kann Anubis den Inhalt einer Nachricht gezielt verarbeiten, etwa die E-Mail signieren oder verschlüsseln. Dazu ergänzt der Benutzer die »RULE«-Sektion seiner »~/.anubisrc«-Datei. Recht einfach ist es, Attribute mit »add header[Name] Wert« an den E-Mail-Header zu hängen:

add header[X-Processed-By] "GNU Anubis"

Anubis kennt auch bedingte Kommandos. Enthält die E-Mail einen Header, der »Mit-Signatur« heißt und einen beliebigen Wert enthält (regulärer Ausdruck ».*«, siehe Kasten “Reguläre Ausdrücke”), dann entfernen folgende Zeilen den Header und fügen am Ende der Mail eine Textsignatur ein:

if header [Mit-Signatur] :re ".*"
    remove [Mit-Signatur]
    signature-file-append yes
fi

Während »signature-file-append yes« den Trenner »– « gefolgt vom Inhalt der Datei »~/.signature« anhängt, fügt »body-append« den Inhalt einer beliebigen Datei an das Ende einer Nachricht ein, »body-clear-append« löscht vorher den alten Nachrichtentext.

Kommandos im Betreff

Zusätzliche Header sind mit vielen Mailclients schwer einzutragen, Anubis will dem Benutzer die Arbeit erleichtern. Es bietet sich an, den Inhalt der Betreffzeile auszuwerten:

if header [Subject] "^ *\[sig\](.*)"
    remove [Subject]
    add [Subject] "1"
    signature-file-append yes
fi

Die If-Anweisung untersucht, ob der Betreff mit »[sig]« beginnt (Posix-Extended-Syntax, da nicht näher spezifiziert). Danach entfernt ein Kommando die komplette Subject-Zeile und fügt eine neue ein, die nur den Teil hinter »[sig]« enthält. Dazu referenziert »1« den in runde Klammern gesetzten String aus dem regulären Ausdruck.

Betreffzeilen eignen sich so gut für Kommandos, dass Anubis hierfür eine eigene Syntax nutzt: Trigger. Der Benutzer löst sie über den Betreff seiner Mail aus; er hängt das Kommando ans Ende der Subject-Zeile, eingeleitet mit zwei At-Zeichen, etwa »Beliebiger Text@@signiere«. Dazu passt folgender Trigger:

trigger "signiere"
 gpg-sign me@daniel.stefan.haischt.name
done

Das Kommando »gpg-sign« signiert den Body der E-Mail mit der angegebenen Schlüssel-ID. Dazu muss der GPG-Schlüsselring des Nutzers im Verzeichnis »~/.gnupg« liegen und seine Anubis-Datei »~/.anubisrc« das GPG-Passwort enthalten (»gpg-passphrase “Meinpasswort”«). Beim Verschlüsseln braucht GPG die Schlüssel-ID des Empfängers. Für diese Aufgabe eignet sich ein erweiterter Trigger, der zusätzliche Daten aus dem Subject auswertet:

trigger :extended "^chiffriere:(.*)"
   gpg-encrypt "1"
   add [X-GPG-Comment] "Encrypted for 1"
done

Die Betreffzeile enthält den Trigger »chiffriere« und dahinter die Schlüssel-ID des Empfängers: »Hallo John Doe!@@chiffriere:Empfänger-Key«.

Abbildung 5a: PHP-MyAdmin zeigt die Struktur der MySQL-Tabelle, die als Dixie-Datenspeicher für Anubis dient. Alle vier Felder enthalten Text: Userkennung, Passwort, Unix-Name und Pfad zur Konfigurationsdatei.

Abbildung 5b: Die MySQL-Tabelle enthält die Daten des Benutzers »haischt«, der sich per Dixie authentifiziert. Sein Unix-Account trägt den gleichen Namen und die Konfigurationsdatei liegt in »/home/haischt/.anubisrc«.

Manipulativer Schakal

Komplexere Aufgaben erfordern ausgewachsene Programmiersprachen, was Anubis mit der integrierten Skriptsprache Guile (einem Scheme-Dialekt) auch anbietet. Zudem ist es möglich, Mails mit externen Programmen zu bearbeiten. Zusammen mit den integrierten Kommandos liefert GNU Anubis sehr flexible Techniken, um E-Mail-Header und -Inhalte zu verarbeiten. Beliebige Manipulationen sind die Stärke dieser Software. Zudem spart die integrierte Unterstützung für PGP/GnuPG viel Konfigurationsarbeit.

Schlechter sieht es bei der Authentifizierung der Benutzer aus (Pixie mit unsicherem Ident oder Dixie, das Klartext-Passwörter in der Datenbank verlangt), zudem liegen PGP-Keyrings und benutzerbezogene Konfigurationen nur im Dateisystem statt optional in der Datenbank. Dass LDAP-Unterstützung fehlt und PGP/Mime sowie das Entschlüsseln eingehender Nachrichten nicht möglich sind, kommt hinzu.

Bleibt zu hoffen, dass sich der schicke Schakal (typische Darstellung des ägyptischen Anubis-Gottes) entsprechend weiterentwickelt. (fjl)