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.
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").
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:
|
Tabelle 1: |
|
|---|---|
| BLOB |
Binary Large Object |
| GPG |
GNU Privacy Guard |
| Guile |
GNU's Ubiquitous Intelligent Language for Extensions |
| Mime |
Multipurpose Internet Mail Extensions |
| MTA |
Mail Transfer Agent (Mailserver) |
| MUA |
Mail User Agent (Mailclient) |
| NLS |
Native Language System |
| PAM |
Pluggable Authentication Modules |
| PGP |
Pretty Good Privacy |
| SASL |
Simple Authentication and Security Layer |
| S/Mime |
Secure Mime |
| SMTP |
Simple Mail Transfer Protocol |
| SSL |
Secure Sockets Layer |
| TLS |
Transport Layer Security (SSL-Nachfolger) |
Weitere Komponenten sind optional und nur für bestimmte Szenarien sinnvoll:
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«.
| SMTP unterschieben |
|---|
| Manche Mailprogramme, zum Beispiel Mutt, rufen die Sendmail-Binärdatei direkt auf, wenn sie eine E-Mail verschicken. Dann ist es aber unmöglich, Host und Port des SMTP-Dienstes per Mailclient-Konfiguration zu ändern, da nur der Admin das Sendmail-Verhalten konfiguriert. Außerdem erlauben einige Mailer keine Authentifizierung über den SMTP-AUTH-Mechanismus. Abhilfe schaffen Programme wie MSMTP [13] oder ESMTP [14], die das Verschicken der Mail stellvertretend übernehmen. Sie arbeiten als gewöhnliche Kommandozeilenprogramme. Jeder Nutzer darf die Tools individuell konfigurieren, bei ESMTP mit Hilfe der Datei »~/.esmtprc«: hostname = anubis.abyssworld.de:24 username = "haischt" password = "access4anubis" starttls = disabled Der Dienst schickt die Mail an den Anubis-Server (»anubis.abyssworld.de«, Port 24) und authentifiziert sich mit Username und Passwort. Die Starttls-Verschlüsselung bleibt abgeschaltet. Mutt muss noch wissen, dass es ESMTP statt des Sendmail-Binary verwenden soll: set sendmail="/usr/local/bin/esmtp" Diese Zeile in seiner Mutt-Konfigurationsdatei stellt den E-Mail-Client darauf ein. |
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
