Schlagwort-Archive: E-Mail

Meine Daten gehören mir

Schreibe eine Antwort

Hinweis: Der Artikel „Meine Daten gehören mir!“ erschien erstmals auf der Webseite der Bundeszentrale für politische Bildung.

Vorwort

Überwachung ist kein Problem, für das es eine technische Lösung gibt. Welches Maß an Überwachung eine Gesellschaft zulässt, welche Mittel Bürgerinnen und Bürger haben, um sich zu schützen, muss politisch verhandelt und bestimmt werden. Der Souverän bestimmt, welche finanziellen und juristischen Mittel den Geheimdiensten in die Hand gegeben werden, welcher Kontrolle sie unterworfen werden – oder eben nicht.

Der Souverän, das sind in der Demokratie wir alle. Technische Gegenwehr kann dabei maximal ein Teil der Antwort sein. Um diesen Teil soll es hier gehen. Wie wir aus den Dokumenten erfahren haben, die Edward Snowden den Medien übergeben hat [2], sind die Geheimdienste technisch extrem gut ausgerüstet. Zudem verfügen sie über derart weit reichende Befugnisse oder maßen sie sich an, dass es kaum einem Menschen, der in ihr Visier gerät und direkt ausgespäht werden soll, gelingen wird, seine Kommunikation vollständig vor ihren Augen und Ohren zu verbergen. Das liegt schon daran, dass Kommunikation nun einmal zwischen mindestens zwei Beteiligten stattfindet und sie über dasselbe Maß an Expertise verfügen müssen, um ihre Kommunikation zu schützen. Solange Kommunikationstechnologien nicht „ab Werk“ sicher und verschlüsselt sind, bleibt das eine Herausforderung.

Man kann jedoch noch immer davon ausgehen, dass die meisten Menschen keine Ziele direkter geheimdienstlicher Überwachung sind. Für sie geht es darum, ihre Kommunikation so zu schützen, dass so wenig Inhalte wie möglich im Schleppnetz der NSA, des britischen Geheimdiensts GCHQ oder des deutschen BND landen. Denn all die Milliarden Daten, die die Dienste absaugen, werden entweder nach bestimmten Signalbegriffen oder Mustern durchsucht und dann im Zweifel genauer geprüft. Oder sie werden für Jahrzehnte gespeichert und erst dann analysiert, wenn sie in Zusammenhängen auftauchen, die für die Geheimdienste interessant sind.

Das bedeutet: Jede normale Bürgerin, jeder normale Bürger kann heute zum Ausspäh-Ziel der Geheimdienste werden – und sei es nur durch den Kontakt zu bestimmten anderen Menschen. Um zu verstehen, wie man sich schützen kann, muss man zwei Arten von Daten unterscheiden:

Die eine Art sind die Inhalte der Kommunikation, also etwa der Text einer E-Mail, der Wortlaut eines Telefonats oder der Inhalt einer Datei auf einem USB-Stick. Diese Inhalte können geschützt werden, indem man E-Mails und Datenträger verschlüsselt.

Die andere Art der Daten sind so genannte Meta-Daten, also Daten über Daten: Mit wem hat man wann telefoniert, wer hat wem wann eine Mail geschickt, wer hat wann welche Website aufgerufen? Diese Daten mögen harmloser erscheinen, können aber ebenso weitreichende Schlüsse zulassen wie der Inhalt der Kommunikation. Meta-Daten fallen bei digitaler Kommunikation immer an, aber man kann sie in gewissen Maß verschleiern, etwa durch Werkzeuge für mehr Anonymität.

Keine dieser Techniken und Technologien kann Sicherheit garantieren. Im Gegenteil: zum Teil sind sie komplex und verleiten dazu, Fehler zu machen. Alle müssen ausprobiert, eingeübt und regelmäßig verwendet werden. Doch selbst wenn vor hochaufgerüsteten Geheimdiensten wie der NSA keine umfassende Sicherheit möglich ist, ist es keineswegs umsonst, für mehr Datensicherheit zu sorgen. So bieten gängige Vorkehrungen nicht zuletzt Schutz auch vor gewöhnlichen Kriminellen im Netz. Auch diese sind stets auf der Suche nach Sicherheitslücken und schlecht gesicherter Kommunikation, die sie etwa zum Identitätsdiebstahl nutzen können. Ebenso gilt umgekehrt: Werden Sicherheitslücken geheim gehalten, um sie zur Überwachung nutzen zu können, wirkt sich das negativ auf die Sicherheit aller Bürger aus.

Nützliche Links

  • Das Privacy-Handbuch: Wesentlich ausführlicher, als es hier möglich wäre, beschreibt dieses Handbuch auf mehr als 300 Seiten, was man als Nutzer unternehmen kann, um seine Privatsphäre zu schützen. Es ist ein kollaboratives, von Datenschutz-Aktivisten gepflegtes Handbuch und in verschiedenen Versionen im Netz verfügbar. Eine aktuelle Version findet sich unter privacy-handbuch.de [3].
  • Die US-Bürgerrechtsorganisation Electronic Frontier Foundation [4] betreibt die fortlaufend auf aktuellem Stand gehaltene Ratgeberwebsite „Surveillance Self-Defense“ [5] mit vielen Anleitungen und einfachen Erklärungen zu grundlegenden Konzepten der Datensicherheit. Die Beiträge sind auf Englisch, Spanisch und Arabisch verfügbar.

E-Mail-Verschlüsselung

Wer E-Mails unverschlüsselt verschickt, verschickt das elektronische Äquivalent von Postkarten. Das ist schon oft gesagt und geschrieben worden, dennoch sind viele überrascht, wenn sie erfahren, dass E-Mails praktisch ungeschützt durchs Netz wandern. E-Mails werden auf ihrem Weg vom Absender zum Empfänger mehrfach gespeichert, etwa bei den Internet-Providern bei Absender und Empfänger, aber auch weitere Male dazwischen. Unterwegs können daher diejenigen die E-Mails lesen, die Zugriff aufs Netz haben. Die Snowden-Enthüllungen zeigen, dass massenhaft E-Mails im „Schleppnetz-Verfahren“ überwacht und ausgewertet werden. Sie werden automatisiert auf bestimmte Schlagwörter untersucht, um herauszufinden, ob sie für Geheimdienste interessant sein könnten. Sollte das der Fall sein, werden sie genauer angeschaut. Aber auch, wenn es keinen aktuellen Anlass gibt, ist zu vermuten, dass E-Mails zumindest von der NSA einfach abgespeichert werden, sodass sie auch in Zukunft untersucht werden können.

Wer vermeiden möchte, dass seine E-Mails derart unter die Lupe genommen werden, muss eine so genannte Ende-zu-Ende-Verschlüsselung verwenden. Das bedeutet, dass die E-Mail beim Absender – an einem Ende – verschlüsselt wird, und beim Empfänger – am anderen Ende – wieder entschlüsselt. So wandern die Inhalte niemals unverschlüsselt durch Netze, auf die andere Zugriff haben.

PGP: Geniale Idee, aber zunächst nicht leicht zu verstehen

Eine gängige Lösung, die sich für normale Nutzer – also solche, die keine Unterstützung von Spezialisten haben – zu diesem Zweck eignet, ist PGP [6]. Die Abkürzung steht für „pretty good privacy“, also „ganz gute Privatsphäre“. Der leicht scherzhafte, sprechende Name weist darauf hin, dass PGP-Erfinder Phil Zimmermann nicht davon ausgeht, dass das Verfahren vollständige Sicherheit bieten kann, aber eben doch ziemlich gute. Und obwohl Zimmermann PGP bereits in den 1990er Jahren entwickelt hat, gilt diese Einschätzung bis heute: PGP ist noch immer die sicherste Mailverschlüsselungsmethode.

Um PGP einzusetzen, gibt es unterschiedliche Wege. Üblicherweise benötigt man eine Erweiterung für einen E-Mail-Client – also das Programm, mit dem man E-Mails liest und schreibt. Wenn man E-Mails hingegen nur über den Webbrowser verwendet, gibt es zwar ebenfalls Erweiterungen, aber die meisten Experten halten diese noch nicht für reif. Etwas verwirren kann die Vielzahl unterschiedlicher Abkürzungen: „Open PGP“ ist der Name des zugrunde liegenden Verschlüsselungsstandards, der von verschiedenen Programmen unterstützt wird. Dazu gehören das heute kommerzielle Programm PGP ebenso wie die kostenlose, freie Variante namens „GNU Privacy Guard“ [7], GnuPG oder GPG abgekürzt. Der Einfachheit halber werden all diese Entwicklungen häufig unter dem Begriff PGP zusammengefasst, so auch in diesem Artikel.

Das Verfahren, auf dem PGP beruht, wird „public-key cryptography“ genannt und auf Deutsch mit „asymmetrisches Kryptosystem“ übersetzt – leichter verständlich wäre die Übersetzung „Verschlüsselung mit öffentlichem Schlüssel“. Die Idee dahinter ist genial, aber zunächst nicht leicht zu verstehen. Bei einem symmetrischen Verfahren teilen zwei Menschen sich einen gemeinsamen Schlüssel. Das Problem daran: Wie kann der Schlüssel sicher ausgetauscht werden? Man kann ihn nicht der Nachricht beifügen, weil sie dann auch von einem Angreifer entschlüsselt werden könnte, der die Nachricht abfängt. Man kann den Schlüssel getrennt von der Nachricht übermitteln, aber auch dann könnte er abgefangen werden. Wer ihn hat, kann die Nachrichten dann entschlüsseln. Um sicher zu gehen, müssten sie den Schlüssel daher direkt austauschen, etwa indem sie sich treffen.

Bei der asymmetrischen Verschlüsselung hingegen hat jeder Nutzer einen öffentlichen und einen privaten Schlüssel. Zusammen bilden beide ein Schlüsselpaar. Wie der Name sagt, ist der eine Teil öffentlich und kann sorglos weiter gegeben werden: per E-Mail, über eine Website, auf einem USB-Stick oder in einem Chat. Wenn eine Nachricht mit diesem öffentlichen Schlüssel verschlüsselt wird, kann sie aber nur noch mit dem privaten Schlüssel wieder entschlüsselt werden. Ein Angreifer, der die Nachricht abfängt, kann sie nicht entschlüsseln, da er den privaten Schlüssel nicht kennt. Auch der Sender kann die Nachricht beim Empfänger nicht wieder entschlüsseln, denn auch er kennt nur den öffentlichen Schlüssel, nicht den privaten. Aus dem – jedem bekannten – öffentlichen Schlüssel den privaten Schlüssel zu berechnen, ist so schwierig und aufwändig, dass Experten das System unter bestimmten Voraussetzungen (langer Schlüssel und sicheres Passwort) derzeit für sicher halten.

Geeignetes Programm auswählen, Schlüsselpaar anlegen

Um PGP selbst zu nutzen, braucht man die entsprechende Software. Die Programme sind vielfältig und werden mittlerweile für nahezu alle Betriebssysteme angeboten, auch für Smartphones. Da sie alle etwas unterschiedlich funktionieren und eingerichtet werden, wird unten in den Links auf die entsprechenden Anleitungen verwiesen. Was in jedem Fall zu tun ist: Man muss ein Schlüsselpaar anlegen. Extrem wichtig hierbei ist, dass der private Schlüssel eine Schlüssellänge von mindestens 2.048 Bit hat und mit einem sehr guten Passwort geschützt ist. Die Schlüssellänge kann man festlegen, wenn man den Schlüssel erzeugt. Vereinfacht gesagt, wirkt sie sich darauf aus, wie viele mögliche Schlüssel ein Angreifer durchprobieren müsste, um zufällig den richtigen zu erwischen, wenn er jeden denkbaren Schlüssel ausprobieren würde. 1.024-Bit-Schlüssel gelten inzwischen als unsicher; wer auf der sicheren Seite sein möchte, wählt besser gleich einen 4.096-Bit-Schlüssel. Damit kann das Verschlüsseln großer Mails, zum Beispiel mit angehängten Dateien, auch auf schnellen Rechnern allerdings eher lange dauern.

Der öffentliche Schlüssel sollte auf einen so genannten Key-Server hochgeladen werden. Da er einer E-Mail-Adresse zugeordnet ist, können ihn andere somit auch dann finden, wenn sie noch nie Kontakt mit dem Inhaber der E-Mail-Adresse hatten. Viele Programme bieten an, den Schlüssel direkt auf einen solchen Server hochzuladen.

Nützliche Links

  • Anleitungen, wie man E-Mail-Verschlüsselung einrichtet, hat die Website „Verbraucher sicher online“ für verschiedene Betriebssysteme und Programme zusammengestellt. Dazu gehören die Erweiterung Enigmail und der GNU Privacy Guard [8], die Verschlüsselung mit Mozilla Thunderbird unter Windows, Mac OS sowie Linux & Co. ermöglichen. Für Mac-Systeme gibt es zudem eine Anleitung für das Paket „GPG Suite/GPG Tools“ für Apples Mailprogramm [9]. Bei Windows lässt sich auch GnuPG und Claws Mail einrichten [10], GpgOE für Outlook Express [11] oder GnuPG/WinPT für das Mailprogramm The Bat [12].
  • Eine Anleitung, wie man öffentliche Schlüssel austauscht und auf einen Schlüsselserver lädt, findet sich am Beispiel der GPG Suite ebenfalls bei „Verbraucher sicher online“ [13].
  • Hinweise zu sicheren Passwörtern gibt es beim Bundesamt für Sicherheit in der Informationstechnik bei der Versicherung CosmosDirekt [14]. Wer noch sicherer gehen möchte, beachtet die Tipps von Jürgen Schmidt im Heise-Artikel „Passwort-Schutz für jeden“ [15].

Übung macht den Meister

Oft wird zur E-Mail-Verschlüsselung gesagt, dass es leicht sei, sie zu verwenden. Das stimmt so nicht, denn in der Praxis lauern viele Fallstricke, weshalb die ersten Versuche auch für Erfahrene frustrierend sein können. Wie bei allen komplexen Verfahren gilt: Übung macht den Meister. Am Besten sucht man sich ein Gegenüber, mit dem man die Programme ausprobieren und testen kann.

Einige bekannte Probleme aus der Praxis:

  • Man verschlüsselt die Mails, die man an andere verschickt, empfängt verschlüsselte Mails von anderen, legt die Mails aber unverschlüsselt auf dem eigenen Rechner ab. Wird zum Beispiel der Laptop gestohlen und ein Fremder kann sich Zugang verschaffen, kann er die Mails lesen.
  • Man vergisst sein Passwort und hat kein sogenanntes Sperrzertifikat (revocation certificate) angelegt, mit dem man den Schlüssel für ungültig erklären kann. Dann kann man sich zwar einen neuen Schlüssel mit neuem Passwort anlegen, doch der alte Schlüssel ist weiter erhältlich. Andere schicken dann möglicherweise verschlüsselte Mails, die man nicht entschlüsseln kann, und man muss sie auffordern, einen neuen Schlüssel zu verwenden.
  • Die Festplatte geht kaputt, und es gibt keine Sicherungskopie des privaten Schlüssels. Alle Mails, die verschlüsselt abgelegt wurden, sind unlesbar.
  • Verschlüsselte E-Mails können je nach Programm und gewählter Einstellung nicht mehr einfach durchsucht werden, und sie können auch in der Regel nicht per Webmail-Dienst angesehen werden.

Festplatten und mobile Datenträger verschlüsseln

Auf einem unverschlüsselten Datenträger liegen alle Daten offen zutage. Bei einem tragbaren Gerät wie einer externen Festplatte oder einem USB-Speicherstick ist es auch sofort einleuchtend, warum das ein Problem sein kann: Sie können verloren gehen oder gestohlen werden. Gleiches gilt für Laptops. Aber auch ein Desktop-Rechner kann in falsche Hände geraten, durch einen Einbruch oder weil ein missliebiger Kollege zu neugierig ist.

Passwortschutz ist keine Verschlüsselung: Sind die Computer mit einem Zugangspasswort geschützt, ist das zwar prinzipiell gut, hilft aber nichts, wenn ein Angreifer das Gerät in seinem Besitz hat. Ein solches Passwort hindert ihn zwar daran, das System zu starten und zu nutzen, aber wenn er die Festplatte ausbauen kann, kann er dennoch auf die Daten darauf zugreifen. Bei einem USB-Stick oder einem anderen tragbaren Datenträger ist das ohnehin der Fall.

Verschlüsselung dagegen bedeutet, dass sämtliche Daten, die geschützt werden sollen, in eine Form umgewandelt werden, die für denjenigen, der den Schlüssel nicht kennt, nur Datensalat darstellt, also eine sinnlose Ansammlung von Zeichen. Heißt: Nur wenn die Daten sicher verschlüsselt sind, sind sie vor dem Zugriff eines Angreifers geschützt.

Bordmittel praktisch, aber quelloffene Programme empfehlenswerter

Wie aber geht das? Viele Betriebssysteme bieten Bordmittel an, um Dateien, den Benutzerordner oder ganze Festplatten zu verschlüsseln. Sie haben zwei entscheidende Nachteile: Zum einen liegt durch die Snowden-Enthüllungen der Verdacht nahe, dass sehr viele Unternehmen den Geheimdiensten so genannte Hintertüren offenhalten. Das bedeutet, dass die Verschlüsselungstechnik möglicherweise absichtlich Schwachstellen aufweist, die von NSA und Co. genutzt werden können, um an die Daten heranzukommen.

Zum anderen gibt es das Problem, dass etwa ein USB-Stick, der mit einer Apple-Software verschlüsselt wurde, nicht mit einem Windows-Programm entschlüsselt werden kann. Für mehr Kompatibilität empfiehlt sich ein Programm, das erstens auf möglichst vielen Betriebssystemen eingesetzt werden kann, und dessen Programmcode zweitens transparent ist, sodass zumindest geprüft werden kann, ob Sicherheitslücken und Hintertüren bestehen. Bei den von Microsoft und Apple angebotenen Bordmitteln „Bitlocker“ bzw. „Geräteverschlüsselung“ sowie „File Vault/File Vault 2“ ist das nicht der Fall. Die auf Linux-Systemen häufig eingesetzten Bordwerkzeuge wie LUKS und DM-Crypt können zwar öffentlich überprüft werden, aber auch sie sind nicht ohne weiteres mit anderen Betriebssystemen kompatibel.

Allzweckwerkzeug Truecrypt eingestellt, Alternativen nur teilweise verfügbar

Viele Jahre lang war das Programm Truecrypt hier die erste Wahl, da es beide Anforderungen erfüllte und vielfältig einsetzbar ist: Um verschlüsselte Ordner (Container genannt) anzulegen, die wie ein Laufwerk genutzt werden; aber auch, um komplette Datenträger oder die System-Festplatte zu verschlüsseln. Die verschlüsselten Teile lassen sich zudem so verstecken, dass ihre Existenz unerkannt bleibt. Die anonymen Entwickler haben ihre Arbeit an dem Projekt jedoch im Mai 2014 eingestellt. Da sie zu den Gründen dafür keine wirklich klaren Angaben machten, gibt es unterschiedliche Einschätzungen, ob das Programm weiter eingesetzt werden sollte.

Organisationen wie das amerikanische „Committee to Protect Journalists“ meinen, dass zumindest bestehende Installationen der letzten Vollversion 7.1a weiterhin sicher verwendet werden können [16]. Sie verweisen auf den Umstand, dass Sicherheitsforscher in einer unabhängigen Untersuchung des Programmcodes von Truecrypt [17] bis jetzt keine gravierenden Sicherheitslücken entdeckt haben. Die letzte Vollversion wird an verschiedenen Stellen im Netz weiterhin kostenlos angeboten, etwa auf der Website Security in a box [18], einem Projekt der NGOs „Tactical Tech“ und „Front Line Defenders“. Eine Anleitung für alle verschiedenen Funktionen [19] hat Marco Kratzenberg erstellt.

Andere haben ihre Empfehlungen für Truecrypt mittlerweile zurückgezogen, so etwa auch das Bundesamt für Sicherheit in der Informationstechnik; auch die Entwickler des sicheren Betriebssystems „Tails“ haben das Programm entfernt. Eines der Kernprobleme liegt darin, dass keine Sicherheitsaktualisierungen mehr verfügbar sein werden.

Die Situation ist daher bis auf weiteres unbefriedigend: Während es für Profis einige quelloffene Werkzeuge wie etwa „EncFS“ gibt, sieht es für den Normalanwender schlechter aus. Wer Windows verwendet, kann etwa mit dem „Diskcryptor“ immerhin einzelne Partitionen verschlüsseln. Wer lediglich einzelne Dateien verschlüsseln will, kann das übrigens auch mit den oben erwähnten PGP-Werkzeugen größtenteils tun. Letztlich muss jeder selbst abwägen: Bordmittel und kommerzielle Programme für Windows- und Mac-Systeme sind relativ leicht zu bedienen, aber man muss den Herstellern mehr oder weniger blind vertrauen. Wem das nicht behagt, der muss sich die derzeit angebotenen Alternativen ansehen und entscheiden, welche noch am ehesten die eigenen Ansprüche abdeckt. Eine Übersicht über Werkzeuge bietet die Website prism-break.org [20], kommerzielle ebenso wie quelloffene Programme stellt auch Heise Online [21] vor. Die wohl umfangreichste Vergleichsliste [22] haben die Autoren der englischsprachigen Wikipedia zusammengetragen.

Um Sicherheit zu bieten, müssen auch solche Verschlüsselungsprogramme natürlich richtig eingesetzt werden und ihre Grenzen sollten bekannt sein.

Einige bekannte Probleme aus der Praxis:

  • Ein verschlüsselter, aber geöffneter Ordner ist ungeschützt. Wer in die Kaffeepause geht und ihn offen lässt, unterläuft seine eigenen guten Absichten.
  • Manche Programme legen automatisch Versionen von Dateien an Orten ab, die nicht verschlüsselt sind, etwa in temporären Ordnern. Stürzt zum Beispiel der Rechner ab, bleiben sie unter Umständen erhalten.
  • Ist das Passwort verloren, sind die Daten weg. Alle. Für immer.
  • Sollte ein Angreifer über die Mittel verfügen, das Passwort auszuspähen, kann er an alle Daten heran kommen. Das erlauben etwa Programme, die Tastatureingaben protokollieren (Keylogger). Wenn man gar keine Verschlüsselung verwendet, kommen Angreifer natürlich leichter an Daten, doch es kann auch die Situation entstehen, dass man sich zu sehr in Sicherheit wiegt.

Anonymer Surfen mit Browser-Erweiterungen und Tor

Wer im Web surft, hinterlässt Datenspuren. Websites protokollieren etwa die IP-Adresse des Rechners, von der aus man auf sie zugreift. Wenn man sich mit echter Identität bei einem Web-Dienst anmeldet, sei es Facebook, Google-Drive oder GMX, kann diese IP-Adresse dann einer Person zugeordnet werden; Strafverfolgungsbehörden können ohnehin über eine Anfrage beim Provider feststellen, wer hinter einer bestimmten IP-Adresse steckt. Das ist eigentlich dafür gedacht, dass bestimmte, genau definierte Straftaten verfolgt werden können, doch muss man inzwischen leider davon ausgehen, dass auch in anderen Fällen diese Verknüpfungen angefragt und hergestellt werden.

Mit den Mitteln des Trackings versuchen Anbieter von Websites nachzuspüren, welche Wege im Netz ihre Besucher zurücklegen, um sie mit maßgeschneiderter Werbung zu versorgen. Das kennt man, wenn man zum Beispiel nach „Wetter Mallorca“ sucht und später Flüge und Hotels in der Werbung auftauchen. Ein klassisches Mittel dafür sind Cookies, also kleine Dateien auf der Festplatte, aber die Techniken werden ständig weiterentwickelt. Viele dieser Datenschatten lassen sich dennoch vermeiden. Der alte Grundsatz der Datensparsamkeit dient letztlich auch der Datensicherheit, denn Daten, die gar nicht erst anfallen, können auch nicht missbraucht werden.

Nützliche Links

Mit Browser-Erweiterungen wie HTTPS everywhere, Adblock Edge, Disconnect, Do Not Track Plus oder Noscript lassen sich die Datenspuren bereits verringern. Natürlich registriert ein Website-Betreiber, wenn seine Website aufgerufen wird, aber man kann verhindern, dass einem beim Aufruf dutzende Dritte über die Schulter schauen können, etwa Werbenetzwerke. Eine einfache Anleitung für gängige Browser-Erweiterungen für Firefox [23] hat der Journalist Boris Kartheuser erstellt.

Wer seine Spuren im Netz umfassender verwischen will, sollte sich mit dem Werkzeug Tor beschäftigen. Tor besteht aus einer Software, die man auf dem eigenen Rechner installiert, und einem Netz von Servern, über die die Daten geleitet werden. Der grundlegende Ansatz basiert darauf, den Datenverkehr über mehrere Ecken umzuleiten, sodass der Ausgangspunkt verschleiert wird. Die Abkürzung TOR stand ursprünglich für „The Onion Router“ – gemeint ist damit das Prinzip, den Datenverkehr wie bei einer Zwiebelhülle in mehreren Schichten zu verschlüsseln. Auf jedem Wegpunkt wird gerade soviel davon entfernt, wie nötig ist, um die Daten weiterzureichen, ohne dass die restlichen Informationen bekannt werden. Die Knotenpunkte werden von Freiwilligen – Individuen, Organisationen, Unternehmen – ehrenamtlich betrieben. Forscher, Geheimdienste und Behörden haben bereits versucht, Tor-Nutzer zu de-anonymisieren; dies ist in Einzelfällen auch gelungen. Dennoch sieht es so aus, als hätten die Tor-Entwickler im Katz-und-Maus-Rennen bislang die Nase vorn. Doch gerade bei Tor gilt es, einige Fallstricke zu meiden, die dazu führen können, die eigene Anonymität auszuhebeln, selbst wenn das Tor-Prinzip als solches bislang als sicher gilt. Dazu gehören etwa folgende:

  • Wer über Tor auf einen Webdienst wie Facebook oder Gmail zugreift, für den eine Anmeldung erforderlich ist, unterläuft natürlich die Anonymisierung.
  • Andere Programme, die auf dem Rechner laufen, verwenden nur dann Tor, wenn sie speziell dafür eingerichtet sind. Wer zum Beispiel über Tor surft, aber nebenher ein Chat- oder Mail-Programm verwendet, das nicht auf Tor zurückgreift, ist dabei nicht anonym.
  • Programme im Browser wie Flash oder Java sollten deaktiviert sein. Ebenso können etliche Browser-Erweiterungen Informationen weitergeben, die eine Identifizierung ermöglichen.
  • Tor ersetzt keine verschlüsselten Verbindungen etwa über „HTTPS“. Verlässt der Datenverkehr das Tor-Netzwerk, ist er wieder unverschlüsselt und kann dort mitgeschnitten werden, wenn keine anderen Vorkehrungen getroffen werden.
  • Das bloße Installieren und Aktivieren von Tor bringt nicht mehr Sicherheit. Um tatsächlich Anonymität zu gewinnen, werden die meisten einige typische Verhaltensweisen am Rechner ändern und sich mit der Einrichtung ihres gesamten Systems beschäftigen müssen. Unbedacht verwendet, erhöht man unter Umständen sogar das Sicherheitsrisiko. Berichten zufolge interessieren sich Geheimdienste wie die NSA nicht nur für die Betreiber des Tor-Netzes, sondern für jeden, der das Programm herunterlädt [24], etwa indem sie versuchen, dessen Downloads zu protokollieren.

Nützliche Links

Es ist ratsam, den Tor Browser [25] zu verwenden. In diesem Paket sind bereits alle Programme zusammengefasst, die benötigt werden, inklusive einem Firefox-Browser, in dem häufige problematische Einstellungen bereits korrigiert sind. Dieses Paket kann auch von einem USB-Stick aus gestartet werden, sodass es sich zum Beispiel auch in Internet-Cafés oder bei der Arbeit verwenden lässt.

Eine allgemeine deutschsprachige Installationsanleitung [26] gibt es etwa beim Portal „Verbraucher sicher online“; eventuell ist es zusätzlich notwendig, aktuellere Anleitungen für das eigene Betriebssystem zu konsultieren. Die Tor-Software wird für Windows, Mac OS, Linux & Co. sowie Android angeboten, nicht jedoch für Apples mobile Geräte.

Besonders die Hinweise der Tor-Entwickler selbst [27] zu verbleibenden Risiken und den Grenzen der durch Tor ermöglichten Anonymität und Sicherheit sollte jeder zu Rate ziehen, der auf Anonymität angewiesen ist.

Wie am Anfang des Artikels bereits angemerkt: Datensicherheit ist ein Prozess, der gelernt und geübt sein will. Das kann mit Sicherheit mühsam sein. Doch zum einen hat es noch nie drängendere Gründe gegeben, damit zu beginnen. Und zum anderen ist nun dank Edward Snowden eine Dynamik entstanden, die vielleicht dafür sorgen könnte, das viele Hilfsmittel besser werden oder überhaupt erst entwickelt werden. Jetzt untätig zu bleiben aus dem – durchaus begründeten – Gefühl der Hilflosigkeit darüber, nicht für seinen eigenen, perfekten Schutz sorgen zu können, wäre der größte Gefallen, den man dem Überwachungsstaat tun könnte.

Links
[1] http://www.bpb.de/gesellschaft/medien/datenschutz/203238/meine-daten-gehoeren-mir
[2] http://www.zeit.de/digital/datenschutz/2013-10/hintergrund-nsa-skandal/komplettansicht
[3] https://privacy-handbuch.de/
[4] https://eff.org/
[5] https://ssd.eff.org/en/index
[6] https://de.wikipedia.org/wiki/Pretty_Good_Privacy
[7] https://gnupg.org/
[8] https://www.verbraucher-sicher-online.de/anleitung/e-mails-verschluesseln-in-mozilla-thunderbird-mit-enigmail-und-gnu-privacy-guard
[9] https://www.verbraucher-sicher-online.de/anleitung/e-mails-verschluesseln-in-apple-mail-unter-mac-os-x
[10] http://www.verbraucher-sicher-online.de/anleitung/e-mail-verschluesselung-mit-gnupg-und-claws-mail-unter-windows
[11] http://www.verbraucher-sicher-online.de/anleitung/e-mails-verschluesseln-in-outlook-express-mit-gpgoe
[12] http://www.verbraucher-sicher-online.de/anleitung/windows-vista-e-mail-verschluesselung-mit-the-bat-und-gnupgwinpt
[13] https://www.verbraucher-sicher-online.de/anleitung/e-mails-verschluesseln-in-apple-mail-unter-mac-os-x?page=0,3
[14] https://www.cosmosdirekt.de/sicherheit-im-internet/sicheres-passwort/
[15] http://www.heise.de/security/artikel/Passwort-Schutz-fuer-jeden-1792413.html
[16] https://www.cpj.org/blog/2014/06/journalists-can-safely-use-truecrypt-for-now.php
[17] http://istruecryptauditedyet.com/
[18] https://securityinabox.org/en
[19] http://www.giga.de/software/sicherheit-utilities/die-ultimative-truecrypt-anleitung-alles-was-du-wissen-musst/
[20] https://prism-break.org/en/
[21] http://www.heise.de/download/special-sichere-alternativen-zu-truecrypt-151561.html?hg=1&hgi=16&hgf=false
[22] https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
[23] http://www.investigativerecherche.de/mehr-datenschutz-beim-surfen-im-internet-eine-anleitung/
[24] https://www.tagesschau.de/inland/nsa-xkeyscore-100.html
[25] https://www.torproject.org/projects/torbrowser.html.en
[26] https://www.verbraucher-sicher-online.de/anleitung/den-anonymisierungsdienst-tor-verwenden
[27] https://www.torproject.org/docs/faq.html.en#AmITotallyAnonymous

Autoreninformationen: Matthias Spielkamp und David Pachali (Webseite) arbeiten bei iRights.info. Matthias Spielkamp ist dort Redaktionsleiter und Vorstandsmitglied von Reporter ohne Grenzen Deutschland. David Pachali ist als Journalist und Redakteur tätig.  Dieser Artikel erschien erstmals auf der Webseite der Bundeszentrale für politische Bildung und wurde in „freiesMagazin“ Ausgabe 06/2015 veröffentlicht. Der Artikel wurde an dieser Stelle in der Fassung aus „freiesMagazin“ wiedergegeben.

Dieser Text ist unter der Creative Commons Lizenz veröffentlicht. by/3.0/
Der Name des Autors/Rechteinhabers soll wie folgt genannt werden: by/3.0/ Autor: David Pachali Matthias Spielkamp für bpb.de

Thunderbird Adressbuch mit ownCloud Kontakten synchronisieren

4 Antworten

Dieser Artikel basiert auf der offiziellen ownCloud Dokumentation[1. Thunderbird – Synchronize Addressbook] und beschreibt die Einrichtung eines Thunderbird-Adressbuchs zur Synchronisation mit den ownCloud-Kontakten.

contacts-carddav-link

Menü zum CardDAV-Link

Neben dem Thunderbird-Mailclient wird die Erweiterung Lightning[2. Mozilla Thunderbird Lightning Calendar] benötigt. Wie man diese Erweiterung nutzt, um z.B. den ownCloud-Kalender mit Thunderbird zu synchronisieren, habe ich bereits an dieser Stelle beschrieben.

Um neben dem Kalender auch die Kontakte synchronisieren zu können, wird darüber hinaus der Sogo Connector[3. Sogo Connector] benötigt. Am einfachsten installiert man diese Erweiterung, indem man einen Rechtsklick auf die Erweiterung ausführt und „Ziel speichern unter..“ aus dem Kontextmenü auswählt. In Thunderbird richtet man diese Erweiterung ein, indem man im Add-on Menü die Option „Add-on aus Datei installieren…“ auswählt.

Sind die beiden Erweiterungen erfolgreich installiert, kann das Adressbuch eingerichtet werden. Dazu öffnet man das Thunderbird-Adressbuch aus der Symbolleiste. Im sich öffnenden Fenster wählt man Datei->Neu->Remote-Adressbuch.

Der Verbindungsname kann frei gewählt werden. Bei URL wird der CardDAV-Link eingetragen, den man in den Einstellungen der ownCloud-Kontakte findet. Die Einstellungen verbergen sich hinter dem kleinen Zahnradsymbol.

remote-addressbook-settings

Remote-Adressbuch-Einstellungen

Die weiteren Optionen können nach den persönlichen Vorlieben gewählt werden. Einzig den Haken bei „Nur lesbar“ sollte man nicht setzen, wenn man über Thunderbird auch neue Kontakte in der ownCloud anlegen möchte.

Fertig. Damit sind die ownCloud-Kontakte in den Mailclient integriert und lassen sich z.B. für die Autovervollständigung der E-Mail-Adressen in neuen Nachrichten nutzen.

Enigmail unterstützt zukünftig nur noch GnuPG 2

2 Antworten

Auf meinem Trusty-Notebook läuft Thunderbird mit dem Addon Enigmail in Version 1.8. Heute Morgen informierte mich Enigmail mit folgender Meldung darüber, dass die unter Ubuntu standardmäßig installierte GnuPG-Version 1.4.16 in zukünftigen Versionen von Enigmail nicht mehr unterstützt wird. Es wird ein Update auf GnuPG 2.0 oder neuer empfohlen.

enigmail-message

Enigmail-Meldung

Nichts leichter als das. Schließlich ist GnuPG 2 bereits in den Paketquellen von Ubuntu enthalten und kann aus diesen installiert werden.

sudo apt-get install gnupg2

Fertig. Mehr ist nicht zu tun. Ein Blick in die Enigmail-Einstellungen zeigt, dass das Addon nun automatisch das soeben installierte gpg2 verwendet.

enigmail-settings

Enigmail-Einstellungen

Die vorhandenen GnuPG-Schlüssel stehen automatisch auch in der neuen Version zur Verfügung. Die Bedienung funktioniert im Wesentlichen wie zuvor. Man verwendet nun lediglich das Kommando gpg2, statt des älteren gpg.

SpamAssassins Erkennungsrate mit SA-Learn verbessern

6 Antworten

Unter „Training für SpamAssassin“ wurde bereits erklärt, wie man mit dem Hilfsprogramm sa-learn das Erkennungsverhalten von SpamAssassin trainieren kann.

An dieser Stelle möchte ich noch mal ein konkretes Beispiel dazu dokumentieren.

Auf meinem Server verwende ich die Maildir-Verzeichnisstruktur, zum Speichern meiner E-Mails.

In meinem Fall befinden sich die bereits gelesenen E-Mails im Posteingang im Pfad /var/mail/vmail/example.org/username/mail/cur. Die in diesem Ordner liegenden E-Mails sind kein Spam. Dies kann SpamAssassin mit dem folgenden Befehl mitgeteilt werden:

# sa-learn --ham /var/mail/vmail/example.org/username/mail/cur/ --progress
100% [=========================================================================================================================]  10.43 msgs/sec 00m01s DONE
Learned tokens from 13 message(s) (18 message(s) examined)

Spam landet in meinem Fall im Pfad /var/mail/vmail/example.org/username/mail/Junk/cur. Diese Mails können mit dem folgenden Kommando verarbeitet werden.

sa-learn --spam /var/mail/vmail/example.org/username/mail/Junk/cur

Weitere Informationen findet man auf der offiziellen Homepage von SpamAssassin.

Der eigene Mailserver – Teil 4

2 Antworten

Herzlich willkommen zum vierten und letzten Teil dieser Artikelreihe. An dieser Stelle haben wir bereits einen voll funktionsfähigen und sicher konfigurierten E-Mail Server. E-Mailkonten können im MUA unserer Wahl eingerichtet und genutzt werden. Auf dem Server selbst können mit Leichtigkeit neue Benutzer, Mailboxen und Aliase angelegt werden. Was bleibt also noch zu tun?

Dieser Artikel beschreibt wie man das System noch weiter härten kann. Es wird gezeigt, wie der Webmailer RoundCube eingerichtet wird und wie man den Zugriff auf diesen absichert. Der Artikel endet mit einem kleinen Ausblick, um welche Features der Server noch erweitert werden könnte.

Und los geht’s!

DNS-based Blackhole List (DNSBL)

DNS-based Blackhole Lists oder kurz DNSBL sind Listen, welche von IP-Adressen oder Adressbereiche enthalten, von denen aus Spam versendet wurde.

SpamAssassin, welches in Teil 3 eingerichtet wurde, prüft bereits etliche dieser Listen und markiert eingehende E-Mails entsprechend. Dieser Artikel geht noch einen schritt weiter und beschreibt wie Postfix so konfiguriert werden kann, dass E-Mails auf Basis dieser Listen abgewiesen werden. Dazu wird in Postfix die Funktion Postscreen[1. Postfix Postscreen Howto] aktiviert.

Um Postscreen zu aktivieren, muss die Datei /etc/postfix/master.cf bearbeitet werden. Zu Beginn der Datei sollten folgende Einträge zu finden sein:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp      inet  n       -       -       -       -       smtpd
#smtp      inet  n       -       -       -       1       postscreen
#smtpd     pass  -       -       -       -       -       smtpd
#dnsblog   unix  -       -       -       -       0       dnsblog
#tlsproxy  unix  -       -       -       -       0       tlsproxy
submission inet n       -       -       -       -       smtpd

Hier ist die erste Zeile aus- und die folgenden vier einzukommentieren, so dass die Zeilen anschließend wie folgt aussehen:

# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
#smtp      inet  n       -       -       -       -       smtpd
smtp      inet  n       -       -       -       1       postscreen
smtpd     pass  -       -       -       -       -       smtpd
dnsblog   unix  -       -       -       -       0       dnsblog
tlsproxy  unix  -       -       -       -       0       tlsproxy
submission inet n       -       -       -       -       smtpd

Falls diese Zeilen fehlen sollten, müssen sie am Anfang der master.cf eingefügt werden. Durch diese Zeilen werden die benötigten lokalen Ports und Unix Sockets, für den Postscreen Prozess, geöffnet.

Nach dieser Änderung ist die Datei /etc/postfix/main.cf am Ende um folgende Einträge zu ergänzen. Hier wird Postfix mitgeteilt, dass Postscreen zu nutzen ist und welche DNSBLs verwendet werden sollen.

postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_access_list = permit_mynetworks
postscreen_dnsbl_sites = zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net

Die erste Zeile bewirkt, dass alle Server abgewiesen werden, die versuchen den Verbindungsaufbau in irgendeiner Form abzukürzen (um schneller Spam versenden zukönnen). In Zeile 2 wird die Prüfung anhand von DNSBLs aktiviert. Zeile 3 fügt den Inhalt der Variable „mynetworks“ hinzu, um LAN Clients von der Prüfung auszuschließen. In der vierten Zeile werden schließlich drei DNSBLs angegeben, welche zur Prüfung herangezogen werden.

Es können natürlich auch mehr, als drei DNSBLS angegeben werden. Darüber hinaus bietet Postscreen noch eine Reihe weiterer Konfigurationsparameter. Für weitere Informationen zu diesen Parametern wird auf die Dokumentation verwiesen.[2. Postfix – Postscreen DNSBL Konfigurationsoptionen]

Jetzt kann Postfix mit dem Befehl

sudo service postfix restart

neugestartet werden und schon ist die neue Konfiguration aktiv. Wer sehen möchte wie Postscreen arbeitet, kann sich selbst eine E-Mail senden und das Log /var/log/mail.log studieren.

Webmail mit allem was dazugehört

Wenn es um Webmail geht, ist zuerst die Entscheidung zu fällen wo Webmail gehosted werden soll und welche Anwendung man dafür verwenden möchte. Für große Umgebungen ist man gut beraten Webmail auf einem separaten Server zu installieren. Für die eingene kleine Umgebung kann man Webmail jedoch auch mit auf dem E-Mailserver installieren, wenn der eigene Server über genügend RAM und CPU Leistung verfügt.

Die im Folgenden beschriebene Webmail-Konfiguration setzt sich im wesentlichen aus diesen Anwendungen zusammen:

Jede der genannten Anwendungen ist so umfangreich, dass man ihnen einen eigenen Artikel oder gar eine eigene Artikelreihe widmen kann. Dieser Artikel beschränkt sich daher darauf, eine möglichst sichere Webmail-Konfiguration zu erstellen.

Wo möglich verwende ich die Version einer Anwendung, welche über die Paketquellen zur Vergfügung gestellt wird. Da PHP-FPM nicht in den Paketquellen für Ubuntu 14.04.1 enthalten ist, greife ich hierbei auf ein PPA zurück.

Als erstes werden Nginx und MySQL aus den Paketquellen installiert.

sudo apt-get install nginx-full mysql-server

Zusammen mit den Paketen werden alle benötigten Abhängigkeiten installiert. Nach einigen Minuten wird man aufgefordert ein Passwort für den MySQL-Benutzer „root“ zu vergeben. Für diesen Benutzer sollte ein möglichst langes und komplexes Passwort vergeben werden.

PHP-FPM ist in Trusty noch nicht in den Paketquellen enthalten. Daher wird zuerst ein PPA zur Paketverwaltung hinzugefügt.

add-apt-repository ppa:ondrej/php5
apt-get update
apt-get install php5-fpm php5-mysqlnd php-pear php5-mcrypt php5-intl

Fall man beim Hinzufügen des PPA die folgende Fehlermeldung erhält, fehlt noch ein Paket, welches wie folgt nachinstalliert werden kann. Anschließend kann das PPA wie oben beschrieben hinzugefügt werden.

:~$ sudo add-apt-repository ppa:ondrej/php5
sudo: add-apt-repository: command not found
:~$ sudo apt-get install software-properties-common
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  gir1.2-glib-2.0 libcurl3-gnutls libdbus-glib-1-2 libgirepository-1.0-1
  librtmp0 python3-dbus python3-gi python3-pycurl python3-software-properties
Vorgeschlagene Pakete:
  python-dbus-doc python3-dbus-dbg libcurl4-gnutls-dev python3-pycurl-dbg
Die folgenden NEUEN Pakete werden installiert:
  gir1.2-glib-2.0 libcurl3-gnutls libdbus-glib-1-2 libgirepository-1.0-1
  librtmp0 python3-dbus python3-gi python3-pycurl python3-software-properties
  software-properties-common
0 aktualisiert, 10 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 818 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 3.451 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] J

Im Anschluss an die Installation wird der PHP Interpreter konfiguriert. Dazu gehört, dass PHP-FPM statt über TCP Sockets über UNIX Sockets kommuniziert. Dazu wird in der Datei /etc/php5/fpm/pool.d/www.conf folgende Zeile einkommentiert, bzw. hinzugefügt, falls sie fehlt.

listen = /var/run/php5-fpm.sock

Anschließend werden die Zugriffsrechte für den Socket korrekt gesetzt.

listen.owner = www-data
listen.group = www-data

Hier kann noch eine Menge mehr konfiguriert werden. Zum Beispiel kann PHP-FPM zur Nutzung von memcached konfiguriert werden, welches die Auslieferung von PHP-Anwendungen beschleunigt. Dies würde jedoch den Umfang dieser Artikelreihe sprengen. Steht genügend RAM zur Verfügung, sei auf die Dokumentation zu PHP-FPM verwiesen, um memcached einzurichten.

Wie nach allen Änderungen an Konfigurationsdateien, ist auch hier der betroffene Dienst neu zu starten.

service php5-fpm restart

Nun geht es wieder um Nginx. Als erstes wird die Hauptkonfigurationsdatei /etc/nginx/nginx.conf bearbeitet. Sie sollte anschließend wie folgt aussehen:

user www-data;
worker_processes 2;
pid /run/nginx.pid;

events {
	worker_connections 1024;
	multi_accept on;
}

http {
	sendfile on;
	tcp_nopush on;
	tcp_nodelay on;
	keepalive_timeout 10 10;
	types_hash_max_size 2048;
	server_tokens off;
	port_in_redirect off;
	client_max_body_size 4096k;
	client_body_timeout 10;
	client_header_timeout 10;
	send_timeout 10;

	include /etc/nginx/mime.types;
	default_type application/octet-stream;

	access_log /var/log/nginx/access.log;
	error_log /var/log/nginx/error.log;

	# Gzip Settings
	gzip on;
	gzip_disable "msie6";
	gzip_min_length 1100;
	gzip_vary on;
	gzip_proxied any;
	gzip_buffers 16 8k;
	gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/rss+xml text/javascript image/svg+xml application/x-font-ttf font/opentype application/ vnd.ms-fontobject;

	# Sitewide SSL settings
	ssl_session_cache shared:SSL:10m;
	ssl_buffer_size 4k;

	# Sitewide proxy settings
	set_real_ip_from 127.0.0.1;
	real_ip_header X-Forwarded-For;

	# Virtual Host Configs
	include /etc/nginx/conf.d/*.conf;
	include /etc/nginx/sites-enabled/*;
}

Der Wert von worker_processes ist auf die Anzahl der physikalisch vorhandenen CPU Cores zu setzen.

Als nächstes wird die Datei /etc/nginx/conf.d/php5-fpm.conf mit folgendem Inhalt erstellt.

upstream php5-fpm-sock {
	server unix:/var/run/php5-fpm.sock;
}

Damit wird eine Variable namens „php5-fpm-sock“ erstellt, welche auf den Unix Socket verweist.

Nun wird die Datei /etc/nginx/sites-available/roundcube erstellt und mit folgendem Inhalt befüllt.

server {
	server_name www.domainname.tld;
        listen 80;
	return 301 https://mail.domainname.tld$request_uri;
}

server {
	server_name mail.domainname.tld;
        listen 80;
	return 301 https://$host$request_uri;
}

# HTTPS server
server {
	listen 443 ssl spdy default_server;
	server_name mail.domainname.tld;
	root /usr/share/nginx/roundcube;
	index index.html index.php;
	autoindex off;

	ssl on;
	ssl_certificate /etc/ssl/private/ssl-chain-mail-domainname.pem;
	ssl_certificate_key /etc/ssl/private/domainname-private-ssl.key;
	ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
	ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS;
	ssl_prefer_server_ciphers on;
	ssl_ecdh_curve secp521r1;

	# Client auth via certs
#	ssl_client_certificate /etc/ssl/private/yourdomain.crt;
#	ssl_trusted_certificate /etc/ssl/private/yourdomain.crt;
#	ssl_verify_client on;

	location / {
#		if ($ssl_client_s_dn !~* "you@yourdomain.com") {
#			return 301 http://www.jurassicsystems.com/;
#		}
#		error_page 403 @fallback;
	}

	location ~ ^/(README|INSTALL|LICENSE|CHANGELOG|UPGRADING)$ {
		deny all;
	}

	location ~ ^/(bin|SQL)/ {
		deny all;
	}

	location ~ ^/.*\.php {
		try_files $uri =404;
		include fastcgi_params;
		fastcgi_pass php5-fpm-sock;
		fastcgi_param HTTPS on;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		fastcgi_intercept_errors on;
	}

	location @fallback {
		return 301 http://www.domainname.tld/;
	}
}

Ist die Datei erstellt wird ein symbolischer Link im Verzeichnis /etc/nginx/sites-enabled erstellt und der Link auf die Standardseite gelöscht.

ln -s /etc/nginx/sites-available/roundcube /etc/nginx/sites-enabled/roundcube
rm /etc/nginx/sites-enabled/default

Anschließend benötigt Nginx einen Neustart.

Sind Webserver und Interpreter funktionsfähig, wird es Zeit sich um die MySQL Datenbank zu kümmern.

Erstellung der Datenbank

Zum Glück gibt es hier nicht viel zu tun. Der MySQL Server ist in der Standardkonfiguration bereits recht sicher konfiguriert. Mit dem hier beschriebenen Setup wird der MySQL Server nicht aus dem Internet erreichbar sein und diesen Umstand sollte man nicht ändern.

Als Erstes startet man das SQL Interfaces und verbindet sich mit dem root-Benutzer.

mysql -u root -p

Mit den folgenden Kommandos wird nun eine Datenbank für roundcube angelegt und ein Benutzer mit Zugriffsrechten auf diese Datenbank erstellt.

create database roundcubedb;
grant all on roundcubedb.* to 'roundcubedb'@'localhost' identified by 'enter-a-password-here';
exit

Fertig. Webserver, PHP Interpreter und Datenbankserver inkl. Benutzer sind einsatzbereit. Jetzt fehlt nur noch die eigentliche Webmail Anwendung.

Installation von Roundcube

Die Webmail Anwendung wird direkt von der Roundcube Download Seite heruntergeladen. Auf dem Server können wir den Download direkt auf der Kommandozeile starten.

http://downloads.sourceforge.net/project/roundcubemail/roundcubemail/1.0.4/roundcubemail-1.0.4.tar.gz
tar -xzvf roundcubemail-1.0.4.tar.gz

Anschließend wird das entpackte Verzeichnis an die korrekte Stelle im Dateisystem manövriert und die Zugriffsrechte korrekt gesetzt.

rm -rf /usr/share/nginx/roundcube
mv /usr/share/nginx/roundcubemail-1.0.4 /usr/share/nginx/roundcube
chown -R www-data:www-data /usr/share/nginx/roundcube

Nun wird die URL https://mail.domainname.tld/installer im Webbrowser aufgerufen und der Webinstaller gestartet.

roundcube-webmail-installer

Start des Roundcube Webmail Installationsprogramms

Auf der Startseite des Installationsprogramms wird geprüft, ob alle Voraussetzungen für die Installation erfüllt sind. Hier sollte alles OK sein, außer bei den nicht installierten DBMSs und der Datums- und Zeitkonfiguration ganz am Ende der Seite.

Auf der zweiten Seite sind die Optionsfelder mit den individuellen Werten der eigenen Installation auszufüllen. Das Feld product_name sollte auf einen Wert gesetzt werden, der beschreibt, um wessen Webmailer es sich hierbei handelt. Die Checkbox ip_check sollte aktiviert werden, um Roundcube’s Session-Sicherheit zu steigern. Des Weiteren sollte der Wert des Felds identities_level auf „many identities with possibility to edit all params but not email address“ gesetzt werden. Damit sind Benutzer in der Lage alle Optionen in Roundcube anzupassen, ohne die eigene E-Mail Adresse ändern zu können. Damit ist es ihnen möglich ihr eigenes Passwort zu ändern.

Anschließend werden die Angaben zur eigenen Datenbank gemacht. Das Feld db_prefix kann leer gelassen werden.

Abschließend wird mit einem Klick auf Create Config die Konfigurationsdatei /usr/share/nginx/roundcube/config.inc.php erstellt. Die folgende Seite kann mit einem Klick auf Continue bestätigt werden.

Roundcube_Config_created

Die Roundcube Konfiguration wurde erstellt.

Auf der letzten Seite des Installers wird mit einem Klick die Datenbank initialisiert. Darüber hinaus können hier noch weitere Tests ausgeführt werden. Verlaufen alle Tests erfolgreich, so ist es geschafft. Bevor man den eigenen Roundcube Webmailer nutzt, sollte man noch das Verzeichnis des Webinstallers entfernen.

rm -rf /usr/share/nginx/roundcube/installer

Herzlich willkommen im eigenen Webmail-Interface.

roundcube-webmail-interface

Roundcube Webmail Interface

Damit sind wir am Ende der vierteiligen Artikelreihe angelangt. Nach einem langen Weg ist der eigene E-Mail Server fertig. Er kann E-Mails empfangen und versenden. Und dies von Desktop Mailclients, Smartphones, Tablets oder via Webmail. Der Server ist sicher konfiguriert und es wurde alles getan, damit die eigenen Mails nicht von fremden Spamfiltern herausgefischt werden.

Persönliches Fazit

Zuerst möchte ich Lee Hutchinson danken, dessen hervorragende, englischsprachige Artikelreihe[3. Taking e-mail back, part 4: The finale, with webmail & everything after] mich dazu angeregt hat, mich selbst an einem E-Mail Server Projekt zu versuchen.

Am Ende dieser Artikelreihe habe ich viel über E-Mail im allgemeinen sowie MTAs, MDAs und MUAs im speziellen erfahren. Darüber hinaus konnte ich mich mit etlichen Techniken beschäftigen, die helfen, einen Server zu härten und vor den Gefahren des Internets zu schützen. Allein das war es wert, den ganzen Konfigurationsaufwand auf sich zu nehmen. Und hey, ich habe jetzt meinen eigenen Mailserver. :-)

Ich kann mir vorstellen, zukünftig auf dem bisher erreichten aufzubauen. So ist es denkbar eine zertifikatbasierte Webmail-Anmeldung zu implementieren oder einen Kalenderserver zu integrieren. Mehr dazu in folgenden Artikeln.

Ein paar Worte noch zum Schluss. Haltet euer System stets Up-to-Date!

Ihr könnt euch die Arbeit ein klein wenig erleichtern, in dem ihr die Installation von Sicherheitsupdates auf dem Server automatisiert.

Ihr seid für die Sicherheit eures Servers verantwortlich. Pflegt ihn und haltet ihn aktuell. Nichts ist schlimmer als veraltete Systeme, die im Internet vor sich hin gammeln.

Der eigene Mailserver – Teil 3

6 Antworten

Es ist Zeit für Teil 3 dieser kleinen Artikelreihe. In diesem Teil wird der Server einsatzbereit gemacht. Dazu sind im Wesentlichen die folgenden sechs Aufgaben zu erledigen.

Es gibt wieder viel zu tun. Also legen wir los.

Haben wir nicht was vergessen?

Wie ist es denn um den Update-Status des eigenen Servers bestellt? Evtl. ist jetzt eine gute Gelegenheit das System auf Updates zu prüfen und diese einzuspielen. Doch muss dies nicht manuell passieren.

In „Automatische Installation von Sicherheitsupdates“ erkläre ich, wie man die Update-Installation unter Ubuntu automatisieren kann. Exkurs Ende.

OpenDKIM

OpenDKIM soll Mailservern dabei helfen die Authentizität und die Integrität von eingehenden E-Mails zu überprüfen.

Versendet ein Mailserver eine E-Mail mit OpenDKIM, so bildet der Server einen Hashwert über den Inhalt der E-Mail. Dieser Hashwert wird mit einem privaten Schlüssel verschlüsselt und im Header der E-Mail gespeichert. Der empfangende Mailserver fragt über DNS einen speziellen TXT-Record ab, welcher das öffentliche Gegenstück zum privaten Schlüssel enthält, mit welchem der Hash verschlüsselt wurde. Der empfangende Mailserver nutzt diesen öffentlichen Schlüssel, um den Hashwert der Nachricht zu entschlüsseln. Abschließend bildet der Mailserver selbst den Hashwert der empfangenen E-Mail und vergleicht ihn mit dem soeben entschlüsselten Hashwert aus dem Mailheader. Stimmen beide Hashwerte überein, kann man mit hinreichender Sicherheit davon ausgehen, dass die E-Mail von einem autorisierten Absender stammt und unterwegs nicht verändert wurde.

Für die einzelnen Schritte in diesem Teil werden wieder root-Rechte benötigt. Entweder man öffnet eine root-Shell oder stellt den folgenden Befehlen ein sudo voran.

Als erstes wird das Paket OpenDKIM installiert.

:~$ sudo apt-get install opendkim opendkim-tools

Das OpenDKIM Paket richtet bei der Installation automatisch die benötigten Benutzerkonten und Upstart Jobs ein. Es muss nur noch ein Verzeichnis erstellt werden, in dem die Konfigurationsdateien und der private Schlüssel gespeichert werden. Der Zugriff auf dieses Verzeichnis wird auf den Benutzer und die Gruppe von opendkim beschränkt.

mkdir /etc/opendkim
chown opendkim:opendkim /etc/opendkim

Im nächsten Schritt wird im soeben erstellen Verzeichnis ein DKIM Schlüsselpaar erstellt.

cd /etc/opendkim
opendkim-genkey -r -h sha256 -d domainname.tld -s mail

Mit dem Parameter -r schränkt man das erstellte Schlüsselpaar in der Art ein, dass es nur zur Signatur von E-Mails verwendet werden kann. Die Angabe des Hash-Algorithmus sollte selbsterklärend sein. Der Parameter -d spezifiziert die Domain und -s gibt den Selektor an.[9. opendkim-genkey Manual] Das Kommando gibt die beiden Dateien mail.private und mail.txt aus. Letztere enthält den öffentlichen Schlüssel in Form eines DNS TXT Records. Dies macht es einfach, den benötigten DNS Eintrag auf dem DNS Server hinzuzufügen. Ich komme in Kürze darauf zurück.

Die Datei mail.private wird in mail umbenannt. Anschließend wird festgelegt, welche Dienste den Schlüssel zur Signatur von Mails nutzen dürfen. Aber ein Schritt nach dem Anderen.

Zuerst wird die Datei umbenannt:

mv mail.private mail

Anschließend wird die Datei /etc/opendkim/KeyTable angelegt und mit Inhalt nach folgendem Muster befüllt:

domainname.tld domainname.tld:mail:/etc/opendkim/mail

Hier wird domainname.tld mit dem privaten Schlüssel für diese Domain verknüpft. Hat man mehrere Domains und Schlüssel, werden diese nach dem gleichen Muster hier eingetragen.

Als nächstes wird die Datei /etc/opendkim/SigningTable erstellt und mit folgendem Inhalt gefüllt:

*@domainname.tld domainname.tld

Dieser Eintrag weist OpenDKIM an, alle E-Mails von allen Adressen, die auf @domainname.tld enden, mit der Signatur von mail.domainname.tld zu versehen. Auch hier lassen sich ganz einfach weitere Domains hinzufügen.

Als letzte Datei wird die Datei /etc/opendkim/TrustedHosts erstellt, welche lediglich eine lokale IP-Adresse enthält:

127.0.0.1
::1

Diese Datei gibt an, welche Server Mails signieren dürfen und welche Server signierte Mails versenden dürfen, ohne Benutzeranmeldedaten zu übermitteln.

Damit nur OpenDKIM auf die Dateien unterhalb von /etc/opendkim zugreifen kann, wird der Zugriff noch entsprechend eingeschränkt:

chown -R opendkim:opendkim /etc/opendkim

Jetzt kann es der Konfigurationsdatei /etc/opendkim.conf an den Kragen gehen. An das Ende der Datei wird der folgende Inhalt angehängt:

## Benutzerspezifische OpenDKIM Konfiguration
Canonicalization        relaxed/relaxed
ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable
LogWhy                  Yes
PidFile                 /var/run/opendkim/opendkim.pid
Socket                  local:/var/spool/postfix/opendkim/opendkim.sock
SyslogSuccess           Yes
TemporaryDirectory      /var/tmp
UserID                  opendkim:opendkim

Da das Verzeichnis für den Socket noch nicht existiert, wird es jetzt angelegt und mit den entsprechenden Berechtigungen versehen.

mkdir /var/spool/postfix/opendkim
chown opendkim:root /var/spool/postfix/opendkim

Damit die Konfiguration wirksam wird, muss der Dienst einmal neugestartet werden:

service opendkim restart

Damit Postfix über den Socket mit OpenDKIM kommunizieren kann, fügt man den Benutzer Postfix der OpenDKIM Gruppe hinzu.

usermod -G opendkim postfix

Damit ist die erste Aufgabe für diesen Teil erledigt. Bevor wir OpenDKIM endgültig mit Postfix verbinden, wenden wir uns einem anderen Schlachtfeld zu.

Der ewige Kampf gegen den Spam…

…beginnt an dieser Stelle mit der Installation des milters und der Pakete, die benötigt werden, damit Spamassassin mit den DKIM Headers zusammenarbeitet.

sudo apt-get install spamass-milter pyzor razor libmail-dkim-perl

Es gibt mehrere Wege, SpamAssassin zu konfigurieren und zu nutzen. Der einfachste wäre alle Dienstfunktionalitäten zu ignorieren und Postfix die Mails einfach an SpamAssassin weiterleiten zu lassen, bevor diese an Dovecot geleitet werden. Doch dieser Weg führt zur dunklen Seite der Macht.

Ich möchte, dass Postfix die E-Mails über einen Unix-Socket an spamd zur Überprüfung gibt. spamd läuft im Hintergrund und wartet auf die Mails von Postfix. Dies ist schneller und ressourcenschonender. Denn es muss nicht für jede eintreffende E-Mail ein SpamAssassin Prozess gestartet werden.

In der Standardkonfiguration legt spamass-milter für jedes Postfach eine eigene AntiSpam-Datenbank an. Ob man dies möchte, hängt vom Einsatzzweck des jeweiligen Servers ab. Ich persönlich plane den Server für meine eigenen Domains und meine eigenen Postfächer zu nutzen. Daher werde ich es mit einer globalen Konfiguration versuchen, die für alle Postfächer gilt.

Benutzerkonten und Konfigurationsdateien

Bevor die Betriebsbereitschaft hergestellt werden kann, muss noch ein System-Benutzer für den Dienst spamd erzeugt und der Benutzer spamass-milter der spamd Benutzergruppe hinzugefügt werden.

addgroup --system spamd
adduser --system --home /var/lib/spamassassin --ingroup spamd spamd
usermod -a -G spamd spamass-milter

Fertig, nun werden erstmal ein paar Konfigurationsdateien gehackt.

Zu Beginn ist /etc/default/spamassassin dran. Nach der Bearbeitung sollte die Datei wie folgt aussehen:

SAHOME="/var/lib/spamassassin"
SAGLOBALCFGPATH="/etc/spamassassin"
 
# Change to one to enable spamd
ENABLED=1
 
# Options
# See man spamd for possible options. The -d option is automatically added.
OPTIONS="-x --max-children 5 --helper-home-dir ${SAHOME} -u spamd -g spamd --siteconfigpath ${SAGLOBALCFGPATH} --socketpath=/var/spool/postfix/spamassassin/spamd.sock --socketowner=spamd --socketgroup=spamd --socketmode=0660"
 
# Pid file
# Where should spamd write its PID to file? If you use the -u or
# --username option above, this needs to be writable by that user.
# Otherwise, the init script will not be able to shut spamd down.
PIDFILE="/var/run/spamd.pid"
 
# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1

Die ersten beiden Zeilen enthalten Variablen, die das SpamAssassin Home-Verzeichnis und das Verzeichnis mit der globalen Konfiguration beinhalten. Als nächstes wird der spamd Daemon aktiviert. OPTIONS enthält einen ganzen Blumenstrauß an Parametern. Hier wird festgelegt, dass nur eine Konfigurationsdatei für alle Benutzer verwendet wird. Die UID und GID, unter denen SpamAssassin ausgeführt werden soll, werden festgelegt. Der Pfad zur globalen Konfigurationsdatei wird angegeben, usw. usf. Am Ende wird noch das automatische Policyupdate aktiviert. Für weitere Erläuterungen dieser Datei verweise ich auf die Projektseite[2. Projektseite Apache SpamAssassin], welche unter den Quellen verlinkt ist.

Das Verzeichnis für den Socket wird manuell erstellt und die entsprechenden Benutzerrechte vergeben:

mkdir /var/spool/postfix/spamassassin
chown spamd:root /var/spool/postfix/spamassassin/

Speichern und schließen! Jetzt geht es mit /etc/default/spamass-milter weiter. Diese Datei enthält nur eine einzige Zeile, die nach der Bearbeitung wie folgt aussehen sollte.

OPTIONS="-u spamass-milter -i 127.0.0.1 -m -I -- --socket=/var/spool/postfix/spamassassin/spamd.sock"

Die Option „-u“ definiert, unter welchem Benutzerkontext der Milter ausgeführt wird. „-i“ gibt die Quell-IPs der Systeme an, deren Mails der Milter ignorieren soll. „-I“ ignoriert E-Mails von authentifizierten SMTP-Sendern. „-m“ hält SpamAssassin davon ab, sich zu sehr mit den Mail-Headern zu beschäftigen. Der Rest der Zeile gibt an, wohin der Milter die Mails zum Scannen leiten soll. Hier wird der Socket angegeben, der im letzten Schritt erstellt wurde.

Speichern, schließen, nächster!

An die Datei /etc/spamassassin/init.pre werden die beiden folgenden Zeilen angefügt:

## Add TextCat to assist enable language-based filtering
loadplugin Mail::SpamAssassin::Plugin::TextCat

Die beiden Zeilen bewirken, dass das TextCat-Plugin geladen wird, welches wir in der folgenden Konfigurationsdatei verwenden.

In der Datei /etc/spamassassin/local.cf wird direkt unterhalb des ersten Kommentars der folgende Code eingefügt:

## Force global Bayesian databases instead of per-user
bayes_path /var/lib/spamassassin/.spamassassin/bayes
bayes_file_mode 0777
 
## Ensure non-English and non-German e-mails are treated as spam
ok_languages en de
ok_locales en
 
## Set Pyzor and Razor config file paths
razor_config /etc/razor/razor-agent.conf
pyzor_options --homedir /var/lib/spamassassin/.pyzor

Zu Beginn wird festgelegt, wo die Datenbank für den Bayesian-Filter liegt.

Die nächsten beiden Optionen geben an, in welcher Sprache und welchem Zeichensatz eine E-Mail entsprechen muss, um nicht als Spam aussortiert zu werden. Die aktuelle Einstellung erlaubt E-Mails in englischer so wie deutscher Sprache und westlichem Zeichensatz. Eine vollständige Liste der untestützten Sprachen gibt es in der TextCat Dokumentation[4. Dokumentation TextCat Plugin], die verfügbaren Zeichensätze sind in der SpamAssassin Dokumentation für Konfigurationsdateien[5. SpamAssassin Language Options] zu finden.

Auf die letzten beiden Zeilen werde ich in Kürze noch eingehen.

Wann immer man an den Konfigurationsdateien von SpamAssassin herumgemacht hat, ist es eine gute Idee, die Konfiguration mit folgendem Befehl auf Fehler zu überprüfen.

spamassassin --lint

Liefert das Kommando keine Ausgabe zurück, ist alles in Ordnung.

Zum Start werden einmal die aktuellen SpamAssassin-Regeln mit dem Kommando sa-update abgerufen. In Zukunft passiert dies automatisch.

sa-update
chown -R spamd:spamd /var/lib/spamassassin

Nun werden noch das Verzeichnis für den Socket angelegt, die Benutzerrechte korrigiert und die beiden Dienste neugestartet. Anschließend kann es schon zum nächsten Schritt weitergehen.

chown spamd:spamd /var/lib/spamassassin/.spamassassin
service spamassassin restart
service spamass-milter restart

Razor2 und Pyzor

Razor2 und Pyzor sind zwei Add-Ons für SpamAssassin. Sie erweitern die Fähigkeit Spam auszusortieren, indem auf zwei AntiSpam-Datenbanken zurückgegriffen wird, die ständig erweitert werden. Einmal eingerichtet, muss man sich nicht weiter um die beiden kümmern.

Zuerst werden die benötigten Verzeichnisse angelegt:

mkdir /var/lib/spamassassin/.razor
mkdir /var/lib/spamassassin/.pyzor

Laut der Dokumentation[7. Using Pyzor] braucht es nur ein Kommando, um Pyzor in Gefechtsbereitschaft zu versetzen.

pyzor --homedir /var/lib/spamassassin/.pyzor discover

Um Razor in Gefechtsbereitschaft zu versetzen, bedarf es nur weniger Kommandos mehr:

razor-admin -home=/var/lib/spamassassin/.razor -register
razor-admin -home=/var/lib/spamassassin/.razor -create
razor-admin -home=/var/lib/spamassassin/.razor -discover

Der Datei /var/lib/spamassassin/.razor/razor-agent.conf ist folgende Zeile hinzuzufügen:

razorhome = /var/lib/spamassassin/.razor

Das wars…fast…noch zwei Kommandos und SpamAssassin ist klar zum Gefecht.

chown -R spamd:spamd /var/lib/spamassassin
service spamassassin restart
service spamass-milter restart

Training für SpamAssassin

Die Filter von SpamAssassin lernen selbstständig. Doch kann man den Lernprozess durch aktives Training unterstützen. Dazu lässt man eine gewisse Menge an E-Mails durch das Hilfsprogramm sa-learn analysieren.

Hat man z.B. nur solche E-Mails im Posteingang, bei denen es sich ganz sicher nicht um Spam handelt, kann man SpamAssassin wie folgt darauf trainieren, dass es sich dabei nicht um Spam handelt:

sa-learn --ham /path/to/your/inbox/on/the/server --progress

Genau so gut funktioniert das andersherum. Hat man einen Ordner, der ausschließlich Spam-Mails enthält, kann man den Filter wie folgt trainieren:

sa-learn --spam /path/to/directory/of/spam --progress

Der Trainingsprozess ist am effektivsten, wenn man ca. je 1.000 Nachrichten Spam und echte E-Mail hat. Der Filter wird sogar erst dann aktiv genutzt, wenn sich mindestens 200 Spam-Mails in der Datenbank befinden. Das Training kann man beschleunigen, indem man Mails aus seinem Google-Postfach mit Hilfe von Google exportiert, in ein Verzeichnis auf dem Server entpackt und das Trainingsprogramm auf dieses Verzeichnis anwendet.[8. Download a copy of your Gmail and Google Calendar data] Führt man das Lernprogramm als root aus, muss man anschließend sicherstellen, dass alle Dateien in /var/lib/spamassassin/.spamassassin dem Benutzer spamd gehören.

Falls man SpamAssassin versehentlich mal falsch angelernt hat, kann man dies auch wieder rückgängig machen, in dem man das oben genannte Kommando mit der Option –forget auf die betroffene Menge Nachrichten anwendet.

ClamAV

Mit ClamAV wird ein Virenscanner in Stellung gebracht, der E-Mails und Anhänge auf Schädlingsbefall hin untersucht. Damit ClamAV die die E-Mail-Anhänge auch auf Virusbefall untersuchen kann, werden neben dem Milter auch noch eine ganze Reihe an Dekomprimierungsprogrammen installiert.

apt-get install clamav-milter arj bzip2 cabextract cpio file gzip lha lzop nomarch p7zip pax rar rpm unrar unzip zip zoo

Nach der Installation sind Änderungen an der Konfigurationsdatei /etc/clamav/clamav-milter.conf vorzunehmen. Die folgenden Zeilen sind auszukommentieren und durch die Zeilen im zweiten Codeblock zu ersetzen.

MilterSocket /var/run/clamav/clamav-milter.ctl
...
OnInfected Quarantine 
...
LogFacility LOG_LOCAL6

MilterSocket /var/spool/postfix/clamav/clamav-milter.ctl
...
OnInfected Accept 
...
LogFacility LOG_MAIL

Die erste Option gibt an, wo der Socket erstellt wird, der auf E-Mails von Postfix wartet. Da wie bei allen anderen Miltern auch der Socket innerhalb des Postfix chroot jail liegen muss, legt man das Verzeichnis für den Socket wie folgt an und setzt die Benutzerrechte entsprechend.

mkdir /var/spool/postfix/clamav
chown clamav:root /var/spool/postfix/clamav/

Die nächste Option erlaubt es, Nachrichten mit infiziertem Inhalt weiterzuleiten, statt sie in Postfix Warteschlange zu belassen. Denn um diese soll sich später Sieve kümmern. Zum Schluss wird ClamAV angewiesen, das Log von Postfix zu verwenden, um bei Problemen nur an einer Stelle suchen zu müssen.

Nun wird noch die Zeile

SOCKET_RWGROUP=postfix

in der Datei /etc/default/clamav-milter einkommentiert. Jetzt ist es Zeit für einen Neustart.

service clamav-daemon restart
service clamav-milter restart

ClamAV beinhaltet freshclam, um automatisch die Virusdefinitionen zu aktualisieren. Zum Abschluss sollte man sich vergewissern, dass der Updatemechanismus korrekt funktioniert. In der Logdatei /var/log/clamav/freshclam.log sollte in etwa folgende Ausgabe zu finden sein:

--------------------------------------
freshclam daemon 0.97.8 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
ClamAV update process started at Sun Mar 16 18:32:49 2014
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.97.8 Recommended version: 0.98.1
DON'T PANIC! Read http://www.clamav.net/support/faq
Downloading main.cvd [100%]
main.cvd updated (version: 55, sigs: 2424225, f-level: 60, builder: neo)
Downloading daily.cvd [100%]
daily.cvd updated (version: 18609, sigs: 824724, f-level: 63, builder: neo)
Downloading bytecode.cvd [100%]
bytecode.cvd updated (version: 236, sigs: 43, f-level: 63, builder: dgoddard)
Database updated (3248992 signatures) from db.local.clamav.net (IP: 207.57.106.31)
--------------------------------------

Nach der Konfiguration der ganzen Milter ist es jetzt noch nötig, diese in Postfix zu aktivieren. Dazu sind folgende Zeilen in der Datei /etc/postfix/main.cf einzukommentieren und die Konfiguration neu zu laden.

milter_default_action = accept
milter_connect_macros = j {daemon_name} v {if_name} _
non_smtpd_milters = $smtpd_milters
smtpd_milters = unix:/spamass/spamass.sock unix:/clamav/clamav-milter.ctl unix:/opendkim/opendkim.sock

service postfix reload

DNS Konfiguration

Ohne DNS funktioniert kein E-Mailsystem. Damit der Mailserver erreichbar ist, muss im DNS-Manager des eigenen Domainproviders ein MX-Record angelegt werden, welcher auf die öffentliche IP-Adresse oder einen A-Record des eigenen Mailservers zeigt.

Wie genau man einen DNS-Eintrag für die eigene Domain erstellt, ist von Anbieter zu Anbieter unterschiedlich. Zieht dazu am besten die Anleitung bzw. Hilfe eures Anbieters zu Rate. Ich werde am Ende dieses Abschnitts beispielhaft noch ein Bild meines DNS-Providers einfügen.

Als Nächstes wird noch ein TXT-Eintrag benötigt, welcher den öffentlichen DKIM Schlüssel beinhaltet. Dazu kann der Inhalt der Datei /etc/opendkim/mail.txt verwendet werden. Bitte zieht im Zweifel auch hierbei die Hilfe eures DNS-Anbieters zu Rate. Dort sollte beschrieben werden, wie ihr diesen Eintrag am besten erstellt.

Es folgt noch der Eintrag für die Funktionalität des SPF.

dns configuration

Beispielhafte DNS-Konfiguration im Interface von Goneo.

Im obigen Bild sind insgesamt 5 DNS Einträge zu sehen. Bei den ersten beiden Einträgen handelt es sich um einen A-Record für IPv4 und einen AAAA-Record für IPv6. Mit diesen Einträgen wird den IP-Adressen ein Name zugeordnet. Diese beiden Einträge sind nicht zwingend notwendig, man kann sich einen Namen jedoch leichter merken als eine IP-Adresse. In der dritten Zeile sieht man den MX-Record. Dieser gibt Auskunft darüber, welcher Server für die E-Mails einer Domain zuständig ist. Existiert für die Domain kein A-Record, muss hier eine IP-Adresse angegeben werden. Andernfalls kann man, wie in diesem Beispiel, auch einen Namen verwenden.

In Zeile 4 steht der TXT-Eintrag für das Sender Policy Framework (SPF)[10. Sender Policy Framework (SPF) bei Wikipedia] Hier wird festgelegt, welche Server E-Mails für die genannte Domain versenden dürfen.

Und in der letzten Tabellenzeile steht der Eintrag, welcher den öffentlichen DKIM-Schlüssel enthält. Der Name des Eintrags wird dabei nach dem Muster <selector>._domainkey.<domainname.tld> gebildet. Als Wert wird der öffentliche Schlüssel verwendet. Damit kann ein fremder Mailserver die Signatur der E-Mails überprüfen, die von dem eigenen Mailserver versendet werden.

Ein sehr wichtiger Schritt in der DNS Konfiguration fehlt jedoch noch. Es sollte unbedingt noch ein passender PTR-Record konfiguriert werden, welcher ein Reverse-Lookup der IP-Adresse des Servers erlaubt. Fast alle E-Mail-Server versuchen, mit einem Reverse-Lookup die IP-Adresse eines Servers in einen DNS Namen aufzulösen. Entspricht der aufgelöste Name nicht dem Namen aus dem Forward-Lookup, werden die meisten Mailserver die eingehende E-Mail abweisen. Dies ist eine übliche Vorgehensweise, um den Versand von Spam einzudämmen. Denn Spam wird oft von gekaperten Maschinen versendet, oder von Servern, wo sich der Spammer nicht die Mühe macht, den PTR korrekt zu konfigurieren.

dns-reverse

PTR-Einträge für IPv4 und IPv6

Der Screenshot zeigt einen Ausschnitt aus dem DNS-Konfigurationstool von Strato. Es zeigt zwei PTR-Einträge. Jeweils einen für IPv4 und einen für IPv6.

Konsultiert die Hilfe oder den Support eures Anbieters, wenn sich das Menü mit den entsprechenden Konfigurationsmöglichkeiten nicht auf Anhieb finden lässt.

Angeblich gibt es auch noch Hosting-Provider, die ihren Kunden das Recht vorenthalten, einen PTR-Eintrag zu setzen. In diesem Fall kann man sich entweder damit abfinden, dass es mit dem eigenen E-Mailserver nichts mehr wird, oder man wechselt den Hosting-Provider.

Mit E-Mail Filtern gegen Spam

Wir sind nun im letzten Abschnitt von Teil 3 dieser Artikelreihe angelangt. Zum Abschluss kommt die Konfiguration von Sieve, welcher zwei Dinge erledigen soll:

  1. E-Mails filtern, die von SpamAssassin als Spam markiert wurden.
  2. E-Mails filtern, die von ClamAV als virusinfiziert markiert wurden.

Sieve Filter finden sich an mehreren Stellen. Jeder virtuelle Benutzer kann eigene Filter im virtuellen E-Mail Home-Verzeichnis haben (das ist /var/mail/vmail/domainname/Benutzername/sieve). Global definierte Filter befinden sich in /var/mail/vmail/sieve-before und /var/mail/vmail/sive-after. Die Filterregeln in sieve-before werden vor den benutzerdefinierten Filtern angewendet, die in sieve-after nach diesen.

Ich erstelle einen ersten Filter im Verzeichnis /var/mail/vmail/sieve-before, indem ich die Datei masterfilter.sieve erstelle und mit folgendem Inhalt fülle:

# cat masterfilter.sieve 
require ["envelope", "fileinto", "imap4flags", "regex"];
 
# I don't even want to see spam higher than level 10
if header :contains "X-Spam-Level" "**********" {
    discard;
    stop;
}
 
# Twitter? Die in a fire.
if anyof (envelope "From" "bounce@tweet.twitter.com",
          envelope :contains "From" "@bounce.twitter.com") {
    discard;
    stop;
}
 
# Trash messages with improperly formed message IDs
if not header :regex "message-id" ".*@.*\\." {
    discard;
    stop;
}
 
# File low-level spam in spam bucket, and viruses in Infected folder
if anyof (header :contains "X-Spam-Level" "*****",
          header :contains "X-Virus-Status" "Infected") {
    if header :contains "X-Spam-Level" "*****" {
        fileinto "Junk";
        setflag "\\Seen";
    }
    else {
        fileinto "Infected";
    }
}

Sieve wendet die Filter sequentiell von oben nach unten an. Es spielt daher eine große Rolle, an welcher Stelle eine Filterregel erstellt wird.

Der erste Filter wertet das Spam-Scoring aus, welches von SpamAssassin durchgeführt und in den Header der E-Mails eingefügt wird. Dazu prüft der Filter das Feld „X-Spam-Level“ im Header einer E-Mail. Finden sich hier wenigstens zehn „*“, lässt Sieve die E-Mail verschwinden. Die Aktion wird in /var/log/mail.log protokolliert, doch nirgendwo sonst wird man etwas von dieser E-Mail zu Gesicht bekommen. Die Option stop sorgt dafür, dass die übrigen Mailfilter nicht mehr ausgewertet werden.

Der nächste Filter sortiert Twitter-Werbung aus. E-Mails zum Zurücksetzen des Passworts werden von diesem Filter nicht erfasst, da sie von einer anderen Absenderadresse kommen.

Darunter werden E-Mails abgefangen, die über keine gültige Message-ID verfügen. Dieser Filter nutzt reguläre Ausdrücke. In Sieve können reguläre Ausdrücke verwendet werden, die dem RFC 5228 entsprechen.[11. IETF RFC 5228]

Der letzte Filter funktioniert wie folgt. Er prüft, ob ein E-Mail Header entweder ein X-Spam-Level von 5 oder die Markierung „Infected“ enthält und verschiebt sie in den „Junk“-Ordner. E-Mails, die sowohl als Spam klassifiziert sind, als auch einen Virus enthalten, werden in den „Junk“-Ordner verschoben. Nur Mails, die nur einen Virus enthalten, aber nicht als Spam markiert sind, landen im Ordner „Infected“.

Sieve Filter sind extrem komplex. Es würde den Umfang dieser Artikelreihe sprengen, wenn ich versuche, sie allumfassend zu behandeln. Zum tieferen Verständnis empfehle ich die Quellen 12[12. Pigeonhole Sieve examples], 13[13. Sieve example rules von Tiger technologies] und 14[14. Sieve.info].

Die Datei masterfile.sieve wandeln wir in eine Binärdatei um. Dabei wird auch gleich eine Syntaxüberprüfung durchgeführt.

sievec masterfilter.sieve

Wird dieses Kommando als root ausgeführt, müssen die Besitzrechte wieder korrigiert werden.

chown vmail:vmail *.svbin

In Teil 4 dieser Artikelreihe werde ich noch darauf eingehen, wie man Sieve-Filter über das Webinterface von Roundcube erstellen kann, ohne sich in die Tiefen der RegEx-Syntax einarbeiten zu müssen.

Einrichtung eines E-Mail Clients (MUA)

Mit dem Ende dieses Artikels ist der Webserver bereits voll einsatzbereit und kann mit einem Mail User Agent genutzt werden. Dies ist ein guter Zeitpunkt, um ein Konto z.B. in Mozilla Thunderbird[15. Ubuntuusers Wiki: Thunderbird Einrichtung] einzurichten, um die Konfiguration zu testen. Die folgenden Screenshots zeigen exemplarisch, wie ein Konto in Thunderbird hinzugefügt wird.

Wer an dieser Stelle bereits die Nase voll hat von den doch recht langen Artikeln, kann sich bereits entspannt zurücklehnen. Denn er betreibt einen für das Internet gewappneten MTA, MDA und MUA mit Anti-Spam und Anti-Virus Modulen.

Ich werde in Teil 4 noch weitergehen und Webmail einrichten, um die konfigurierten Postfächer auch über einen Webbrowser nutzen zu können. Teil 4 wird sich außerdem mit der Möglichkeit beschäftigen, eine zertifikatsbasierte Anmeldung zu konfigurieren.

Wenn ihr ebenfalls noch weitermachen möchtet, sehen wir uns in einer Woche. ;-)

Der eigene Mailserver – Teil 2

16 Antworten

Herzlich willkommen zurück bei der Artikelreihe „Der eigene Mailserver“.

Der erste Artikel dieser Reihe handelte von dem zu Grunde liegenden Serverbetriebssystem, dem Remote-Zugriff über SSH und der Installation der ersten Pakete.

In dieser Ausgabe geht es vor allem um die folgenden drei Punkte:

  1. Erwerb und Installation eines SSL/TLS Zertifikats.
  2. Grundlegende Konfiguration von Postfix, so dass E-Mails versendet und empfangen werden und Postfix mit Dovecot zusammenarbeitet.
  3. Grundlegende Konfiguration von Dovecot. Es werden drei virtuelle Benutzer und Mailverzeichnisse angelegt.

Und los geht’s!

Eine Sache noch…

Im ersten Artikel dieser Reihe habe ich geschrieben, dass der Betrieb eines Mailservers im Internet eine verantwortungsvolle Aufgabe ist. Dabei habe ich darauf hingewiesen, dass man stets die Sicherheit des eigenen Systems im Blick haben sollte. Daher ist es, denke ich, ein guter Zeitpunkt, an dieser Stelle zu prüfen, ob es Updates für den eigenen Server gibt und diese zu installieren.

Bei einem Ubuntu Server kann dies ganz einfach mit dem folgenden Befehl durchgeführt werden.

:~$ sudo apt-get update && sudo apt-get upgrade

 

SSL/TLS Zertifikat

Bei der Installation von Postfix und Dovecot im letzten Artikel wurde gefragt, ob man ein selbstsigniertes Zertifikat für Dovecot nutzen möchte. Dies habe ich verneint. Denn für einen Mailserver im Internet benötigt man ein gültiges und vertrauenswürdiges Zertifikat.

Gültig und vertrauenswürdig bedeutet in diesem Fall, dass das Zertifikat von einer anerkannten Zertifizierungsstelle ausgegeben wurde. Dieses Zertifikat wird vom Mailserver genutzt, um sich anderen Mailservern gegenüber zu identifizieren. Selbstsignierte Zertifikate oder jene der gemeinschaftlichen Zertifizierungsstelle CAcert werden von anderen Mailservern in der Regel nicht akzeptiert.

Zum Glück gibt es für Privatpersonen die Möglichkeit, kostenlos ein SSL/TLS Zertifikat z.B. bei der Zertifizierungsstelle StartSSL[1. StartSSL] zu erhalten. Da ich noch kein Zertifikat besitze, werde ich im folgenden die Schritte dokumentieren, um ein Zertifikat von StartSSL zu erhalten. Für die folgenden Schritte muss JavaScript im Webbrowser aktiviert sein.

Wer bereits über ein gültiges und vertrauenswürdiges Zertifikat verfügt, kann dieses natürlich auch verwenden und diesen Abschnitt überspringen.

startssl-express-lane

Startseite von StartSSL.com

Mit der Express Lane geht es weiter zum nächsten Schritt, wo die Daten zur Person abgefragt werden und die CA Policy akzeptiert werden muss. Anschließend erhält man einen Authentifizierungscode per E-Mail.

Die Authentifizierung bei StartSSL erfolgt nicht wie gewohnt mit Benutzername und Passwort, sondern mittels eines Client-Zertifikats, welches mit Hilfe des Webbrowsers generiert und anschließend im Browser installiert wird.

Anschließend ist man direkt in seinem Account angemeldet und durchläuft den Assistenten, um die eigene Domain zu verifizieren. Man folgt der Express Lane, bis man bei folgendem Schritt angelangt ist. Den privaten Schlüssel sollte man tunlichst nicht auf dieser Seite generieren![2. Privaten Schlüssel erstellen]

generate-private-key2

Privater Schlüssel für Domain-Zertifikat

Den privaten Schlüssel sollte man immer auf einem der eigenen Systeme generieren. Dieser gehört niemals in die Hände von Dritten. Auch nicht in die einer Zertifizierungsstelle. Daher erstellen wir den privaten Schlüssel und den Certificate Signing Request (CSR) auf dem eigenen Server.

Da für die folgenden Schritte root-Rechte benötigt werden, wechseln wir mit folgendem Kommando den Benutzer, um uns die Arbeit ein wenig zu erleichtern.

johndoe@server:~$ sudo su
root@server:/home/johndoe#

Nun erstellt man mit dem folgenden Befehl den privaten Schlüssel. Dieser wird als domainname-private-ssl.key gespeichert.

root@server:/home/johndoe# openssl genrsa -out /home/johndoe/domainname-private-ssl.key 4096

Die Angabe 4096 stellt die Stärke bzw. Länge des Schlüssels in Bit dar. Achtung: Schlüssel mit einer Länge von unter 2048 Bit gelten heute nicht mehr als sicher.

Nun kann mit dem nächsten Befehl der CSR erstellt werden. Die Angaben im Code unten stellen dabei Beispiele dar. Beim Common Name ist der Name einzutragen, unter dem der Server später im Internet erreichbar sein wird. Es wird kein „challenge password“ vergeben. Dies müsste später bei jedem Neustart des Webservers eingegeben werden oder im Klartext in einer Textdatei hinterlegt werden. Der erste Fall ist extrem unpraktisch und der zweite extrem unsicher.

root@server:/home/johndoe# openssl req -new -key domainname-private-ssl.key -out /home/johndoe/domainname.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:server.domainname.tld
Email Address []:webmaster@domainname.tld

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
johndoe@server:/home/johndoe#

Den Inhalt des CSR kopiert man nun in das Eingabefeld des Certification Wizard von StartSSL. Man befolgt die weiteren Schritte des Assistenten und am Ende wird das neu erstellte SSL-Zertifikat angezeigt. Dieses kopieren wir nun in die Datei /etc/ssl/private/ssl-cert-mail-yourdomain.pem. Verwendet man dabei einen Editor wie vim, nutzt man :set paste, bevor man den Text des Zertifikats einfügt. Den im vorhergehenden Schritt erstellten privaten Schlüssel und den CSR kopiert man ebenfalls in das Verzeichnis /etc/ssl/private. Jetzt lädt man noch das Intermediate Zertifikat von StartSSL mittels des folgenden Befehls in das gleiche Verzeichnis herunter.

root@server:/home/johndoe# cd /etc/ssl/private/
root@server:/etc/ssl/private# wget https://www.startssl.com/certs/sub.class1.server.ca.pem
--2014-12-20 14:09:08--  https://www.startssl.com/certs/sub.class1.server.ca.pem
Resolving www.startssl.com (www.startssl.com)... 192.116.242.20
Connecting to www.startssl.com (www.startssl.com)|192.116.242.20|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2212 (2,2K) [application/x509-ca-cert]
Saving to: ‘sub.class1.server.ca.pem’

100%[========================================================================================================================================>] 2.212       --.-K/s   in 0s      

2014-12-20 14:09:09 (63,3 MB/s) - ‘sub.class1.server.ca.pem’ saved [2212/2212]

root@server:/etc/ssl/private#

Als nächstes verknüpft man das Zertifikat mit dem Intermediate-Zertifikat der Zertifizierungsstelle zu einem sogenannten „chain-certificate“. Das sind zwei Zertifikate in einer Datei. Dies ermöglicht es einem Client, die komplette Zertifizierungskette zu überprüfen.

:/etc/ssl/private# cat ssl-cert-mail-domainname.pem sub.class1.server.ca.pem > ssl-chain-mail-domainname.pem

Das soeben erstelle Zertifikat wird später sowohl für Postfix, als auch für Dovecot benutzt. Doch bevor wir fortfahren, schützen wir noch unseren privaten Schlüssel vor unbefugtem Zugriff, indem wir einzig dem root-Benutzer Leserechte auf diese Datei einräumen.

chmod 400 my-it-brain-private-ssl.key

Jetzt wo ich alle Zertifikate in der Reihe habe, geht es an die Konfiguration von Postfix.

/etc/postfix/main.cf

Los geht’s mit:

$ sudo vim /etc/postfix/main.cf

Im Folgenden wird die main.cf dargestellt, wie sie nach der Bearbeitung aussieht. Diese Datei ist nicht für Copy & Paste geeignet. Zum einen funktioniert die Datei nicht und zum Anderen möchte man ja auch erst verstehen, was dort passiert ist. Wer in die Tiefen der Postfix Konfiguration eintauchen möchte, dem sei die offizielle Dokumentation ans Herz gelegt.[3. Postfix Documentation] Die wesentlichen Elemente der Konfigurationsdatei werden im Folgenden näher beschrieben.

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
myorigin = /etc/mailname

## Customized smtpd parameters
smtpd_banner = $myhostname ESMTP
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_helo_hostname, reject_invalid_helo_hostname, reject_unknown_helo_hostname, permit
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_client_hostname, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_sender
smtpd_sender_restrictions = reject_unknown_sender_domain, reject_sender_login_mismatch, reject_unknown_sender_domain
smtpd_sender_login_maps = $virtual_mailbox_maps

## Dealing with rejection: use permanent 550 errors to stop retries
unknown_address_reject_code = 550
unknown_hostname_reject_code = 550
unknown_client_reject_code = 550

biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mx.domainname.de
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mx.domainname.de, domainname.de, h2381200.stratoserver.net, localhost.stratoserver.net, localhost, localhost.domainname.de
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_command = /usr/lib/dovecot/deliver -c /etc/dovecot/dovecot.conf -m "${EXTENSION}"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/dovecot-auth
smtpd_sasl_authenticated_header = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
broken_sasl_auth_clients = yes
smtp_use_tls = yes
smtpd_tls_received_header = yes
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_auth_only = yes
tls_random_source = dev:/dev/urandom

## customized TLS parameters
smtpd_tls_ask_ccert = yes
smtpd_tls_cert_file = /etc/ssl/private/ssl-chain-mail-domainname.pem
smtpd_tls_key_file = /etc/ssl/private/domainname-private-ssl.key
smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtpd_tls_ciphers = high
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s

## Customized Dovecot and virtual user-specific settings
canonical_maps = hash:/etc/postfix/canonical
home_mailbox = Maildir/
message_size_limit = 104857600
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_mailbox_domains = hash:/etc/postfix/virtual-mailbox-domains
virtual_mailbox_maps = hash:/etc/postfix/virtual-mailbox-users
virtual_transport = dovecot

## This setting will generate an error if you restart Postfix before
## adding the appropriate service definition in master.cf, so make
## sure to get that taken care of!
dovecot_destination_recipient_limit = 1

## Other customized mail server settings
default_destination_concurrency_limit = 5
disable_vrfy_command = yes
relay_destination_concurrency_limit = 1
smtp_tls_note_starttls_offer = yes

Ziemlich zu Beginn der Konfigurationsdatei steht die Variable myorigin. Diese enthält den Namen des Mailservers. Auf einem debianbasierten System steht dieser Name in der Datei /etc/mailname.

Es gibt einige smtpd_sasl Optionen in der Datei. SASL ist das Protokoll, über welches Dovcot und Postfix miteinander kommunizieren. Dank des unter Ubuntu verfügbaren Metapakets mail-stack-delivery, welches im letzten Artikel installiert wurde, ist der Großteil der Konfiguration bereits erledigt.

myhostname, mydestination und mynetworks definieren, wer der Mailserver ist und wo (in welchem Netz) sich dieser befindet. Die erste Variable sollte als erstes den FQDN enthalten und nachfolgend einige alternative Namen, unter denen der Mailserver erreichbar ist. Die letzte Variable enthält die Netzadresse in CIDR-Notation. Ihr Wert kann meist so belassen werden, wie man ihn vorfindet.

Mit den smtpd Parametern geht es ans Eingemachte. Denn diese Parameter nehmen direkten Einfluss auf die Arbeitsweise des Mailservers.

Die Option smtpd_banner legt fest, wie sich der Server gegenüber anderen Mailservern identifiziert. Bei Ubuntu enthält diese Option meist noch die Variablen $myhostname und $mail_name zusammen mit dem Zusatz Ubuntu. Um möglichen Angreifern so wenig wie möglich über das eigene System zu verraten, kann diese Option auf das absolut notwendige Minimum gekürzt werden.

smtpd_banner = $myhostname ESMTP

smtpd_helo_required = yes sorgt dafür, dass sich andere SMTP-Server erst identifizieren müssen, bevor Postfix SMTP-Kommandos von diesen akzeptiert. Mit Hilfe dieser und der nächsten Option wird festgelegt, wie Postfix entscheidet, ob Mails akzeptiert oder abgewiesen werden. So wird mit smtpd_helo_restrictions festgelegt, welche HELO Nachrichten akzeptiert werden. permit_mynetworks legt fest, dass Clients aus dem eigenen Netz übermitteln dürfen, was sie wollen. Die übrigen Optionen sind weitestgehend selbsterklärend. Sie weisen den Mailserver an, allen Servern, die einen Namen übermitteln, der nicht über einen DNS-Lookup aufgelöst werden kann, das internationale Zeichen der Freundschaft zu zeigen.

SSL/TLS

Jetzt wird das SSL Zertifikat eingebaut. Zuerst wird mit der Option smtpd_tls_ask_ccert = yes festgelegt, dass Postfix andere Server auffordert, sich mit einem Zertifikat zu identifizieren. Die beiden Optionen smtpd_tls_cert_file und smtpd_tls_key_file enthalten den vollständigen Pfad zum SSL-Zertifikat und der Datei mit dem privaten Schlüssel, welcher zum Zertifikat gehört. smtpd_tls_CAfile enthält den vollständigen Pfad /etc/ssl/certs/ca-certificates.crt und hilft Postfix, die Zertifikate anderer Server zu überprüfen.

Die Option smtp_tls_ciphers = high verbietet Postfix, schwache Verschlüsselungs-Chiffren zu verwenden. smtpd_tls_security_level = may weist Postfix an, SSL/TLS zu verwenden, wenn der entfernte Server dies ebenfalls unterstützt. Damit folgt die Konfiguration dem RFC 2487.

master.cf

Es gibt noch eine Konfigurationsdatei, welche bearbeitet werden muss. /etc/postfix/master.cf steuert, wie Postfix mit anderen Diensten, wie z.B. Dovecot, interagiert. Hier wird festgelegt, dass Postfix auch auf Port 587 auf eingehende E-Mails lauscht und wie er sich mit Dovecot verbindet. Dazu sind zwei Änderungen notwendig.

Die folgende Zeile ist durch Entfernen des # einzukommentieren:

#submission inet n       -       -       -       -       smtpd

Am Ende der Datei wird der folgende Code eingefügt. Wichtig dabei ist, den Zeileneinzug der zweiten und dritten Zeile beizubehalten:

dovecot   unix  -       n       n       -       -       pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver
  -f ${sender} -d ${recipient}

Map Files

In den Postfix Konfigurationsdateien finden sich Verweise auf „maps“ und „hashes“. Dies sind Orte, wo Postfix Informationen speichert. Diese werden im Folgenden näher erläutert.

Die Datei /etc/aliases legt fest, welche lokalen Benutzerkonten welchen E-Mail Adressen zugeordnet sind. Damit kann gesteuert werden, an welche E-Mail Adressen Statusmeldungen gesendet werden, die von unterschiedlichen Anwendungen generiert werden. Ich habe meine Datei nach dem folgenden Muster aufgebaut:

postmaster: webmaster@yourdomain.com
root: webmaster@yourdomain.com
www-data: webmaster@yourdomain.com

Damit werden alle lokalen Mails an eine echte E-Mail Adresse gesendet.

Postfix liest seine Informationen jedoch aus einer Binärdatei. Diese wird mit dem folgenden Befehl erstellt.

sudo newaliases

Virtuelle Benutzer

Jetzt geht es darum, wie Postfix entscheidet, wie und wohin er E-Mails zustellt.

Zuerst wird die Datei /etc/postfix/virtual-mailbox-domains erstellt, welche die Domain(s) beinhaltet, für die der Mailserver zuständig ist. Der Inhalt der Datei ist simpel und sieht wie folgt aus.

yourdomain.tld		OK

Aus dieser Map machen wir mit dem folgenden Kommando eine Hash-Datei.

postmap /etc/postfix/virtual-mailbox-domains

Als nächstes wird die Datei /etc/postfix/virtual-mailbox-users erstellt, welche Postfix mitteilt, für welche Benutzer er zuständig ist. Diese Datei besteht aus zwei Spalten. Ganz einfach ausgedrückt wird damit sichergestellt, dass wenn man sich als „name@domainname.tld“ am Dovecot anmeldet, Postfix weiß, dass man E-Mails von der Adresse „name@domainname.tld“ aus versenden darf.

Beispielinhalt der Datei:

you@domainname.tld			you@domainname.tld
postbot@domainname.tld			postbot@domainname.tld
webmaster@domainname.tld		webmaster@domainname.tld

Wenn die Datei angelegt ist, führt man erneut das postmap-Kommando aus.

postmap /etc/postfix/virtual-mailbox-users

Zuletzt wird noch die Map /etc/postfix/virtual erstellt. Mit Hilfe dieser Map können Alias-E-Mail Adressen den echten E-Mail Adressen zugeordnet werden. Die Aliase stehen dabei in der ersten, die ihnen zugeordneten „echten“ E-Mail Adressen in der zweiten Spalte.

Beispiel:

you@domainname.tld		you@domainname.tld
postbot@domainname.tld		postbot@domainname.tld
webmaster@domainname.tld	webmaster@domainname.tld
postmaster@domainname.tld	webmaster@domainname.tld
root@mail.domainname.tld	webmaster@domainname.tld
root@domainname.tld		webmaster@domainname.tld
abuse@domainname.tld		webmaster@domainname.tld
hostmaster@domainname.tld	webmaster@domainname.tld

Benötigt man eine sogenannte Catch-All Adresse, fügt man noch folgende Zeile in die soeben erstellte Datei ein:

@domainname.tld              you@domainname.tld

Ist man mit der Erstellung der Datei fertig, ist es wieder Zeit für postmap:

postmap /etc/postfix/virtual

Ok. Zeit kurz durchzuatmen. Als nächstes legen wir einen Benutzer und ein Verzeichnis an, wo die Mails für unsere virtuellen Benutzer abgelegt werden. Ich halte mich hier an das Tutorial von ars technica und verwende für den benötigten lokalen Benutzer ebenfalls die UID 5000 und die GID 5000.[4. Lee Hutchinsoen: Taking e-mail back, part 2: Arming your server with Postfix and Dovecot:
Our self-hosting e-mail series continues as we get our ducks—and doves—in a row.] Im Dateisystem des Linux Root-Servers existiert bereits das Verzeichnis /var/mail. Hier landen die Mails für die lokalen Benutzer des Systems. Hier wird auch ein Verzeichnis angelegt, wo zukünftig alle Mails der virtuellen Benutzer landen. Dazu werden die beiden folgenden Befehle in einer root shell ausgeführt.

groupadd -g 5000 vmail
useradd -g vmail -u 5000 vmail -d /var/mail/vmail -m

Jetzt geht es Dovecot an den Kragen.

Als erstes öffnet man die Datei /etc/dovecot/conf.d/10-ssl.conf und kommentiert die Zeilen 12 und 13 aus. Dies erspart Ärger mit der SSL-Konfiguration. Schließlich soll das eigens für den Mailserver erstellte SSL-Zertifikat verwendet werden.

Bevor es an die eigentliche Konfiguration geht, werden noch einige Zeilen in ein paar anderen Konfigurationsdateien auskommentiert, damit die Konfiguration später nicht durch diese Optionen überschrieben wird.

  • Zeile mail_location in 10-mail.conf auskommentieren
  • Zeile auth_mechanisms = plain in 10-auth.conf auskommentieren
  • Die Sektion passdb in der Datei auth-system.conf.ext auskommentieren
  • Die Sektion userdb in der Datei auth-systems.conf.ext ebenfalls auskommentieren

Ist das erledigt, geht es nun der Datei 99-mail-stack-delivery.conf an den Kragen. Nach der Bearbeitung sollte diese wie folgt aussehen.
# /etc/dovecot/conf.d/99-mail-stack-delivery.conf
# Some general options
protocols = imap sieve
disable_plaintext_auth = yes
ssl = yes
ssl_cert = </etc/ssl/private/ssl-chain-mail-cert.pem
ssl_key = </etc/ssl/private/private-ssl.key
ssl_client_ca_dir = /etc/ssl/certs
ssl_cipher_list = ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:R
SA+AES:RSA+3DES:!ADH:!AECDH:!MD5:!DSS
mail_home = /var/mail/vmail/%d/%n
mail_location = maildir:/var/mail/vmail/%d/%n/mail:LAYOUT=fs
auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@

# IMAP configuration
protocol imap {
mail_max_userip_connections = 10
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
}

# LDA configuration
protocol lda {
postmaster_address = webmaster@my-it-brain.de
mail_plugins = sieve
quota_full_tempfail = yes
deliver_log_format = msgid=%m: %$
rejection_reason = Your message to <%t> was automatically rejected:%n%r
}

# Managesieve configuration
#protocol managesieve {
#listen = 127.0.0.1:2000
#login_executable = /usr/lib/dovecot/managesieve-login
#mail_executable = /usr/lib/dovecot/managesieve
#managesieve_max_line_length = 65536
#}

# Plugins configuration
plugin {
sieve=~/.dovecot.sieve
sieve_dir=~/sieve
sieve_before = /var/mail/vmail/sieve-before
sieve_after = /var/mail/vmail/sieve-after
}

# Authentication configuration
auth_mechanisms = plain login

passdb {
driver = passwd-file
args = username_format=%u scheme=ssha512 /etc/dovecot/passwd.db
deny = no
master = no
pass = no
skip = never
result_failure = continue
result_internalfail = continue
result_success = return-ok
}

userdb {
driver = static
args = uid=5000 gid=5000 home=/var/mail/vmail/%d/%n
}

# Log all failed authentication attempts
auth_verbose=yes

service auth {
# Postfix smtp-auth
unix_listener /var/spool/postfix/private/dovecot-auth {
mode = 0660
user = postfix
group = postfix
}
}

Was ist hier alles passiert?

Als Erstes wurde das POP3 Protokoll entfernt, da ich nur IMAP und Sieve nutzen werde. Sieve ermöglicht die Erstellung umfangreicher und flexibler Mailfilter-Regeln. Doch mehr dazu in Teil 3.

Als Nächstes wird SSL aktiviert und Dovecot der Ort des SSL-Zertifikats, des privaten Schlüssels und das Verzeichnis mit den Zertifikaten der Root CAs mitgeteilt.

Die mail_home und mail_location Direktiven legen fest, wo Dovecot die E-Mails zustellt. Hier sind zwei Variablen enthalten. „%d“ steht für die genutzte Maildomain. „%n“ steht für den Namen der virtuellen Benutzer. Dies bedeutet, dass eine E-Mail an „webmaster@domainname.tld“ im Verzeichnis /var/mail/vmail/domainname.tld/webmaster zugestellt wird.

Die mail_location Direktive legt fest, dass das „maildir“ Format[5. Wikipedia: Maildir] genutzt wird. Das bedeutet, der Posteingang und weitere Verzeichnisse existieren auf dem Server in Form ganz normaler Verzeichnisse. Maildir ist eines von zwei weit verbreiteten E-Mail Speicherverfahren. Das andere ist MBOX, welches alle Nachrichten in einer einzigen langen Datei speichert. Ich habe mich für die Verwendung von Maildir entschieden, da ich so besser einzelne Nachrichten auf der Kommandozeile behandeln kann. Dies ist von Vorteil bei der Konfiguration und dem Training des Anti-Spam Systems in Teil 3 dieser Artikelreihe.

In der Sektion passdb wird definiert, wie und wo die Passwörter der virtuellen Benutzer gespeichert werden. Die Optionen in dieser Sektion stellen sicher, dass ein Benutzer, der ein falsches Passwort eingibt, keinen Zugriff auf ein Postfach erhält.

Mit den Optionen unter userdb wird festgelegt, dass ein virtueller Benutzer namens „vmail“ verwendet wird.

Bevor die Konfiguration von Dovecot beendet werden kann, sind noch die Passwörter für die virtuellen Benutzer zu vergeben, so dass diese sich mit einem Mailclient mit dem Server verbinden können, um E-Mails zu versenden und zu empfangen. Die Passwörter werden in diesem Fall in der verschlüsselten Datei /etc/dovecot/passwd.db gespeichert. Die Passwörter werden interaktiv in der Konsole generiert, damit sie nicht in der Bash-History gespeichert werden. Dabei hilft das doveadm Tool:

doveadm pw -s SSHA512

Das Tool fordert dazu auf, ein Passwort einzugeben und dieses zu bestätigen. Anschließend gibt es den verschlüsselten und gesalzenen String aus. Anschließend wird die Datei /etc/dovecot/passwd.db erstellt und nach diesem Muster gefüllt:

you@yourdomain.com:{SSHA512}OeR5ulGD3LZ0OHuj9muNqSvKB7hxsxnTquSd8AjK8QXrtOAGqxhxdRs093CzcuaX1PXmOkBGXbQCftYc0tpbo83uZ7Y=
postbot@yourdomain.com:{SSHA512}BPhYH6qtRAtcpCpHxZ919HAve7GGYc4QIIGPIIPCQ2JHhsfVJkzbEsITNL9dvf20YsPNec68LjfLi+TXwS35RrOnElE=
webmaster@yourdomain.com:{SSHA512}o0LG4pTPeHkTZDvqeQufuULcY07YPb2EyA46M5yYtZOAcLI2k4Ee7ADkHSePl/mYdinapCkc7ZEYDvOsi3wg/ungtos=

Jede Zeile startet mit der E-Mail Adresse des dazugehörigen E-Mail Kontos, gefolgt von einem Doppelpunkt und dem kompletten String für das verschlüsselte Passwort.

Der Posteingang und alles Andere

Die wirklich letzte zu bearbeitende Datei ist 15-mailboxes.conf, wo konfiguriert wird, welche Verzeichnisse für jeden virtuellen Benutzer erstellt werden. Hier wird sichergestellt, dass jeder Benutzer seinen eigenen Gesendet-, Entwürfe-, Spam-Ordner und Papierkorb bekommt. Es befinden sich bereits Ordnerdefinitionen in dieser Datei. Diesen fügen wir die Zeile auto = subscribe hinzu. Die Datei sollte ohne Kommentare in etwa wie folgt aussehen:

namespace inbox {
	mailbox Drafts {
		special_use = \Drafts
		auto = subscribe
	}
	mailbox Junk {
		special_use = \Junk
		auto = subscribe
	 }
	mailbox Trash {
		special_use = \Trash
		auto = subscribe
	}
	mailbox Sent {
		special_use = \Sent
		auto = subscribe
	  }
}

Dovecot wird neugestartet und anschließend testet man die Konfiguration mit

dovecot -n

Ähnelt die Ausgabe der folgenden, ist alles korrekt.

$ dovecot -n
# 2.2.9: /etc/dovecot/dovecot.conf
# OS: Linux 3.13.0-042stab092.3 x86_64 Ubuntu 14.04.1 LTS reiserfs
auth_mechanisms = plain login
auth_verbose = yes
mail_home = /var/mail/vmail/%d/%n
mail_location = maildir:/var/mail/vmail/%d/%n/mail:LAYOUT=fs
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
    auto = subscribe
    special_use = \Drafts
  }
  mailbox Junk {
    auto = subscribe
    special_use = \Junk
  }
  mailbox Sent {
    auto = subscribe
    special_use = \Sent
  }
  mailbox Trash {
    auto = subscribe
    special_use = \Trash
  }
  prefix = 
}
passdb {
  args = username_format=%u scheme=ssha512 /etc/dovecot/passwd.db
  driver = passwd-file
}
plugin {
  sieve = ~/.dovecot.sieve
  sieve_after = /var/mail/vmail/sieve-after
  sieve_before = /var/mail/vmail/sieve-before
  sieve_dir = ~/sieve
}
protocols = imap sieve
service auth {
  unix_listener /var/spool/postfix/private/dovecot-auth {
    group = postfix
    mode = 0660
    user = postfix
  }
}
ssl_cert =  was automatically rejected:%n%r
}
protocol imap {
  imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
  mail_max_userip_connections = 10
}

Damit ist das Ende von Teil 2 erreicht. Postfix und Dovecot sind fast vollständig konfiguriert. Was ist noch zu tun?

In Teil 3 dieser Artikelreihe geht es um DNS. Es werden DNS Einträge benötigt, damit Clients den Mailserver finden und auch E-Mails an den richtigen Server geroutet werden können. Außerdem wird es noch um ein paar spezielle DNS-Records gehen, die anderen Servern beweisen sollen, dass wir legitime E-Mails und keinen Spam versenden.

Ebenfalls wird es um eine Anti-Spam Lösung gehen. Spamassassin in Kombination mit einem Virenscanner. Der Mailserver wird nochmal auf Herz und Nieren geprüft und dann im großen weiten Internet bekannt gemacht.

Zum guten Schluss geht es in Teil 4 darum, wie der Webmailer Roundcube installiert und konfiguriert wird. Dieser Teil ist optional, da der Webserver bereist am Ende von Teil 3 fertig für den produktiven Einsatz ist. Aber mal ehrlich, was ist ein Mailsystem schon ohne Webmail?

Bis nächste Woche.

Der eigene Mailserver – Start der Artikelreihe

8 Antworten

Wie man den eigenen Mailserver mit eigener Domain möglichst sicher im Internet betreibt wird Gegenstand einer kleinen Artikelreihe sein.

Die Idee dazu kam mir, nachdem ich eine englischsprachige Artikelreihe zum Thema auf ars technica gelesen habe.[1. Hutchinson, Lee (17.02.2014). How to run your own e-mail server with your own domain, part 1: Gmail? Apple? The cloud? Forget ‚em all—in this series, we take your e-mail back.] Ich werde nach dem Muster von Lee einen Linux Mailserver aufsetzen und zur Nutzung mit einer eigenen Domain konfigurieren. Die dazu erforderlichen Schritte werde ich in den kommenden Artikeln festhalten. Sie sollen mir als Dokumentation und euch als Leitfaden dienen. Fangen wir an.

Ein paar Worte vorweg

Einen Mailserver im Internet zu betreiben ist eine verantwortungsvolle Aufgabe. Arbeitet man hier nicht sorgfältig, schafft man leicht ein sogenanntes Open Relay, welches sehr schnell als Spamschleuder missbraucht werden wird. Um genau dies zu verhindern, muss man bei jedem Arbeitsschritt die Sicherheit des Systems im Hinterkopf behalten und die eigene Konfiguration permanent auf mögliche Schwachstellen hin überprüfen.

Mit der Installation und Konfiguration ist es nicht getan. Der dauerhafte Betrieb eines Mailservers bringt einige wiederkehrende Aufgaben mit sich. Der Server ist regelmäßig zu warten. Sicherheitsupdates müssen installiert werden, die verwendeten Dienste sollten stets auf die aktuellste Version aktualisiert werden und von Zeit zu Zeit sollte man die Logdateien auf ungewöhnliche Vorkommnisse hin überprüfen.

Diese Artikelreihe wird keine Schritt-für-Schritt Anleitung. Grundlegende Kenntnisse in Linux, der Arbeit in einem Terminal, der Nutzung eines Texteditors und der Umgang mit der Paketverwaltung werden vorausgesetzt. Auch solltet ihr in der Lage sein, euch eure eigene Domain zu shoppen. ;-)

Wer auf all dies keine Lust hat, hört am besten hier zu lesen auf. Allen anderen wünsche ich viel Spaß und Erfolg auf dem Weg zum eigenen Mailserver.

Wie ist diese Reihe aufgebaut?

Dieser Artikel gibt eine Einführung in die E-Mail Terminologie. Anschließend gehe ich auf das verwendete Betriebssystem und die Dienste ein, welche zur Realisierung des Mailservers zum Einsatz kommen.

Die Links im Text führen euch auf Seiten, die weiterführende Informationen zum verwendeten Begriff bieten. Die für diese Artikelreihe verwendeten Quellen werden als Fußnoten am Ende des jeweiligen Artikels aufgeführt. Benötigt ihr zur Durchführung einzelner Schritte weitere Informationen, so helfen euch diese Quellen weiter.

Die folgenden Artikel führen durch die Tiefen der Konfiguration, der hier vorgestellten Rollen und Dienste und beschreiben, wie man sein System härtet, um es so gut wie möglich vor Missbrauch zu schützen.

Die Terminologie

Ein Mailserver ist kein einzelner Dienst. Vielmehr setzt sich ein Mailsystem aus unterschiedlichen Komponenten zusammen, die nicht einmal auf demselben Rechner laufen müssen (und es bei größeren Installationen meist auch nicht tun).[2. Mailserver-Einführung]

Diese Artikelreihe orientiert sich an der Terminologie aus der Mailserver-Einführung im Wiki von ubuntuusers.de. Die wichtigsten Begriffe möchte ich hier wiedergeben.

  • MTA (Mail Transfer Agent)/SMTP-Server: zuständig für den Transport der Mail von einem System zum anderen (mehr zu MTA und SMTP)
  • MDA (Mail Delivery Agent): stellt die Post auf dem lokalen System zu (mehr zu MDA)
  • MRA (Mail Retrieval Agent): holt Post von einem entfernten Server ab (mehr zu MRA)
  • IMAP-/POP3-Server: hält die Post für den Endbenutzer bereit, damit er sie mit seinem Mailprogramm (MUA – Mail User Agent) abholen und lesen kann (mehr zu IMAP, POP3 und MUA)

Der Server – Das Betriebssystem

Für einen echten E-Mailserver benötigt man einen Server mit einer öffentlichen IP-Adresse, welche im Internet geroutet wird. Hostingprovider, welche diese Server für eine monatliche Gebühr anbieten, findet man mit der Suchmaschine seiner Wahl reichlich im Netz.

Bei der Auswahl eines Hostingproviders kann man sich das erste Mal Gedanken über die Sicherheit machen. Hier empfiehlt es sich auf einen Anbieter setzen, der sich nach dem internationalen Standard ISO 27001 zertifizieren lässt. Diese Norm spezifiziert Anforderungen für die Implementierung geeigneter Sicherheitsmechanismen. So hosten z.B. auch Großbanken ihre Dienste in Rechenzentren, die sich an den Vorgaben der ISO 27001 orientieren.

Wenn man sich einen Root-Server sucht, sollte man außerdem darauf achten, dass der Provider neben der normalen IPv4 Adresse dem Server auch eine IPv6 Adresse spendiert. So stellt man von Anfang an sicher, dass der eigene Mailserver auch über das neue IP-Protokoll erreichbar ist.

Als Betriebssystem für einen Linux Mailserver kann im Prinzip jede beliebige Linux-Distribution dienen, solange die im nächsten Abschnitt genannten Pakete für die gewählte Distribution verfügbar sind.

Aufgrund persönlicher Vorlieben habe ich mich für Ubuntu Server 14.04.1 LTS entschieden. Diese Version verfügt über Long Term Support und wird bis April 2019 mit Sicherheitsaktualisierungen versorgt.

Darüber hinaus ist Ubuntu eine sehr beliebte Distribution, die bei fast allen Hostingunternehmen zur Verfügung steht. Ubuntu stellt dabei ein Metapaket bereit, welches es uns ermöglicht, zügig und sicher ein vollständiges Mailsystem aufzusetzen. Doch später mehr dazu.

Hat man seinen Root-Server bestellt und das Betriebssystem installiert, erfolgt der Zugriff darauf meist via SSH. Der SSH-Dienst wird über die Datei /etc/ssh/sshd_config konfiguriert. Bei Ubuntu ist die Standardkonfiguration schon ganz akzeptabel und bei Verwendung eines starken Passworts auch ausreichend sicher. Statt der Authentifizierung über Benutzername und Passwort kann man sich alternativ auch via Pulbic-Key[3. Authentifizierung über Public Keys] authentifizieren. Damit ist man selbst vor dem unwahrscheinlichen Fall geschützt, dass jemand das verwendete Passwort errät.

Darüber hinaus werden noch einige Optionen in der /etc/ssh/sshd_config wie folgt gesetzt (Erklärung siehe Kommentar im Code):

# Niemand kann sich direkt als root einloggen.
PermitRootLogin no
# Nur die hier aufgeführten Benutzer dürfen sich einloggen.
AllowUsers JohnDoe JaneDoe
# Hiermit wird die Anmeldung mit Benutzername und Passwort deaktiviert.
PasswordAuthentication no

Anschließend nicht vergessen, die geänderte Konfiguration neu zu laden.

Auf dem Server läuft außer dem OpenSSH-Server noch kein weiterer Dienst. Ob dies so ist, kann man mit dem Kommando netstat überprüfen, welches folgende Ausgabe liefern sollte:

john@server:~$ sudo netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      0          150403263   1527/sshd       
tcp6       0      0 :::22                   :::*                    LISTEN      0          150403265   1527/sshd       
john@server:~$

Ok. Damit ist der Root-Server soweit, dass er nur auf SSH-Verbindungen wartet und diese nur akzeptiert, wenn sich ein autorisierter Benutzer mittels publickey authentifiziert.

Der SSH-Dienst ist ein beliebtes Ziel für Brute-Force-Angriffe. Um auch für diese gerüstet zu sein und den Server im Fall einer Attacke etwas zu entlasten, kann man noch zusätzlich das Paket fail2ban[4. Manual Fail2Ban 0.8] installieren. Mit diesem Paket ist es möglich, Brute-Force-Angriffe zu erkennen und die IP-Adresse des oder der Angreifer für eine gewisse Zeit zu blockieren. Hierzu setzt fail2ban automatisch die benötigten iptables-Regeln.

Was wird sonst noch benötigt?

Neben dem Betriebssystem benötigt man noch eine ganze Reihe weiterer Dinge. Da sind

  • Postfix, der MTA zum Senden und Empfangen von E-Mail
  • Dovecot, der MDA, welcher uns das Protokoll IMAP bereitstellen wird
  • SpamAssassin, um unseren Posteingang frei von Spam zu halten
  • ClamAV, um auch etwas gegen die Viren zu tun
  • Sieve, damit konfigurieren wir Filterregeln
  • Roundcube, da ein guter Webmailer in keinem Mailsystem fehlen darf
  • NGINX und PHP-FPM, um Roundcube auch ausliefern zu können

All diese Dienste gilt es zu härten und abzusichern. Die Kommunikationsverbindungen werden mit SSL/TLS gesichert. Für die eigene Maildomain werden DKIM und SPF konfiguriert.

Und ganz am Ende haben wir nicht nur einiges über Linux und die Absicherung von Diensten im Internet gelernt, sondern sind ebenfalls im Besitz unseres eigenen Mailservers.

Bevor es jetzt weitergehen kann, müssen die beiden folgenden Voraussetzungen erfüllt sein:

  1. Root-Server mit öffentlicher IP-Adresse und installierten Betriebssystem steht bereit.
  2. Man ist im Besitz einer eigenen Domain und hat einen DNS-Record gesetzt, welcher auf den eigenen Root-Server zeigt.

Und ab dafür

Hat man sich bei der Wahl des Betriebssystems für Ubuntu entschieden, hat man es jetzt leicht. Denn hier gibt es ein Metapaket, welches postfix und dovecot in einem Rutsch installiert und beide Anwendungen so konfiguriert, dass sie miteinander spielen mögen. Dazu führt man folgenden Befehl aus.

:~$ sudo apt-get install mail-stack-delivery

Nach einem kleinen Augenblick erscheint ein Bildschirm, der dazu auffordert, zu entscheiden, ob man ein selbstsigniertes SSL-Zertifikat für Dovecot nutzen möchte oder nicht.

Konfiguriere dovecot-core: Wollen Sie ein selbstsigniertes SSL-Zertifikat erstellen?

Konfiguriere dovecot-core: Wollen Sie ein selbstsigniertes SSL-Zertifikat erstellen?

Für eine reine Testumgebung reicht ein selbstsigniertes Zertifikat aus. Möchte man den Server mit eigener Domain im Internet betreiben, wählt man hier lieber „No“. In Teil 2 dieser Artikelreihe werde ich noch darauf eingehen, wie man an ein SSL-Zertifikat kommt, dem die gängigen Browser und Betriebssysteme vertrauen.

Einen Moment später erscheint eine Konfigurationsabfrage zu Postfix. Hier wählt man die Option „Internet Site“ aus, um später im Internet E-Mails senden und empfangen zu können.

Postfix Configuration: Internet Site

Postfix Configuration: Internet Site

Der nächste Konfigurationsdialog fordert dazu auf, den Domain-Namen des E-Mailsystems anzugeben. Hier wird der Name der eigenen Domain eingetragen. Möchte man den Server ausschließlich in einer Testumgebung im lokalen LAN betreiben, kann man hier auch so etwas wie testdom.local eintragen.

Postfix Configuration: System-E-Mail-Name

Postfix Configuration: System-E-Mail-Name

Anschließend lässt man die Installation bis zu Ende durchlaufen.

Weiter geht es in Teil 2 dieser Artikelreihe. Dort werde ich beschreiben, wie man ein SSL/TLS Zertifikat bekommt sowie wo und wie die Namen und Kennwörter von E-Mail Benutzern samt der zugehörigen Postfächer gespeichert werden. Am Ende von Teil 2 ist das Mailsystem schon fast voll funktionsfähig. Doch ich bin noch lang nicht fertig.

Denn es fehlt noch an AntiSpam, AntiVirus, Filter-Regeln, DKIM, SPF und unser Webmailer Roundcube. Also bleibt dran, es gibt noch viel zu entdecken.

Der steinige Weg zu verschlüsselter Kommunikation

2 Antworten

Nach dem in den Medien fast täglich eine neue Schlagzeile rund um die NSA Affäre auftaucht, habe ich beschlossen mich näher mit dem Thema „Vertrauliche Kommunikation“ zu befassen.

Dieser Artikel fasst meine Überlegungen zusammen und grenzt das Thema ein. Dabei gehe ich kurz auf meine Motivation ein, nenne gängige Verfahren zur vertraulichen Kommunikation und kommentiere diese. Dabei führe ich einige Links zu Quellen auf, die weiterführende Informationen zu den einzelnen Verfahren und Programmen bieten. Ich plane in folgenden Artikeln detaillierte Beschreibungen zu einzelnen Lösungen zu geben. Bei diesem Artikel handelt es sich damit sozusagen, um den Grundlagenartikel zum Thema.

Mein Ziel ist es eine Lösung zu finden, mit der eine möglichst sichere (denn 100%-ige Sicherheit gibt es nicht) und vertrauliche Kommunikation über das Internet machbar ist.

Vertrauliche Kommunikation

Vertraulich ist eine Nachricht dann, wenn nur der Absender und der oder die Empfänger von ihrem Inhalt Kenntnis haben. Überbringern bzw. Übermittlern dieser Nachricht ist ihr Inhalt entgegen nicht bekannt.

Dies ist z.B. beim klassischen Brief der Fall. Der Absender schreibt ihn, packt ihn in einen Umschlag, verschließt diesen und übergibt ihn der Post zur Zustellung. Die Post bzw. der Postbote, als Überbringer des Briefs, kann den Brief nicht lesen, ohne den Umschlag zu öffnen. Nur der Empfänger kann die enthaltene Nachricht nach Erhalt lesen. Erhält der Empfänger jedoch einen geöffneten Umschlag, so weiß er, dass die Authentizität und Integrität nicht mehr gewährleistet sind.

Im Gegensatz dazu gleicht eine E-Mail eher eine Postkarte. Jeder, der sie in die Hand bekommt, bzw. jeder Server der die E-Mail weiterreicht, kann den Inhalt im Klartext lesen, kopieren und ggf. verändern.

Möchte ich nun in bestimmten Fällen vermeiden, dass meine Nachricht für unbekannte Dritte lesbar ist, muss ich mir Maßnahmen überlegen, wie ich die Vertraulichkeit sicherstellen kann.

Bekannte Probleme

Vertraulicher Kommunikation im Internet stehen vor allem drei bekannte Probleme entgegen.

  • Die Verfahren sind für den Anwender meist extrem unkomfortabel in der Anwendung.
  • Die Verfahren sind so komplex, dass technisch wenig versierte Anwender sie nicht verstehen bzw. nachvollziehen können.
  • Ob die Verfahren wirklich ein hohes Maß an Sicherheit bieten lässt sich meist nur schwer einschätzen.

Alle drei Punkte sorgen dafür, dass auf eine digitale Signatur bzw. Verschlüsselung meist verzichtet wird.

Ich will es dennoch versuchen und schaue mir dazu die folgenden Lösungen an.

Mögliche Lösungen

Auf den ersten Blick bieten sich fünf Möglichkeiten, um das gesteckte Ziel zu erreichen:

  • DE-Mail,
  • E-Postbrief,
  • E-Mail „Made in Germany“,
  • Einsatz von GnuPG oder
  • S/MIME

Rufen wir uns nochmal kurz das Ziel in Erinnerung. Ich möchte, dass die Kommunikation zwischen dem Sender und dem Empfänger der Nachricht vertraulich bleibt. Dabei möchte ich so nah wie möglich an die Vertraulichkeit des klassischen Briefs herankommen.

Dabei bin ich mir bewusst, dass es Geheimdiensten unter Umständen trotzdem möglich ist an den Inhalt meiner Nachricht zu gelangen. Dieses Problem stellt sich jedoch auch beim klassischen Brief. Wie gesagt, 100%-ige Sicherheit gibt es nicht. Aber ich möchte versuchen es ihnen so schwer wie möglich zu machen. Wenn es mir dabei jedoch gelingt alle anderen Freunde von Big Data auszusperren, ist dies schon als Sieg zu werten.

Kommen wir zu den oben genannten Lösungen im Einzelnen.

DE-Mail und E-Postbrief

Meine Kritik an diesen beiden Produkten habe ich bereits in meinem Artikel „DE-Mail und E-Postbrief – Zwei echte Rohrkrepierer“ geäußert.

Beide Produkte bieten aktuell keine Ende-zu-Ende-Verschlüsselung. Während der Übertragung wird die Nachricht auf den Servern der Anbieter entschlüsselt, verarbeitet, wieder verschlüsselt und weitergeleitet. Nach Angaben der Anbieter wird die Nachricht entschlüsselt, um sie auf enthaltene Schadsoftware zu überprüfen. Der kritische Punkt ist jedoch, dass sie überhaupt entschlüsselt wird. Damit ist der Inhalt der Nachricht nicht mehr vertraulich. Aus diesem Grund kommen beide Produkte für mich nicht in Frage. Weder für den privaten Gebrauch, noch für die Kommunikation mit Ärzten, Versicherungen oder Behörden.

E-Mail „Made in Germany“

Die E-Mail „Made in Germany“ hat das gleiche Problem wie die DE-Mail und der E-Postbrief.

Zitat:

Entgegen zunächst anders lautender Angaben wird bei „E-Mail made in Germany“ genau wie bei De-Mail die Mail auf den Servern der beteiligten Unternehmen mit einem Virenscanner auf Virenfreiheit geprüft. Wer dies nicht wünscht, muss den Inhalt der Mail und etwaige Attachments verschlüsseln.

Die einzige „Neuerung“ im Vergleich zur bisherigen E-Mail Kommunikation besteht darin, dass die E-Mails beim Transport von Server zu Server nun endlich verschlüsselt übertragen werden und nicht an jedem Router, den sie passieren, mitgelesen oder verändert werden können. Dies ist jedoch keine echte Innovation, da die Technik zur Transportverschlüsselung bereits seit Ende der 90’er Jahre vorhanden ist.

Offen bleibt lediglich die Frage, ob man deutschen Providern mehr Vertrauen entgegen bringen kann, als anderen, oder eben nicht. Da ich auch mit Personen außerhalb Deutschlands oder Europas kommuniziere geht der Nutzen dieser Lösung für mich gegen Null.

GnuPG und S/MIME

GnuPG und S/MIME sind zwei verbreitete Möglichkeiten um Daten digital zu signieren und verschlüsseln zu können.

GnuPG wurde in RFC4880 definiert. Die Spezifikationen zu S/MIME finden sich in RFC1847, RFC2633, RFC3851 und RFC5751.

Zuerst die schlechte Nachricht. Beide Verfahren sind nicht kompatibel zueinander. Daher stellt sich als erstes die Frage, auf welches Verfahren man setzen sollte. Im Internet bin ich auf den Artikel „S/MIME vs. OpenPGP: Eine Entscheidungshilfe“ gestoßen. Dieser Artikel war mir bei der Entscheidungsfindung sehr hilfreich. Meine Entscheidung gegen S/MIME fiel unter anderem wegen des folgenden Zitats:

X.509 verwendet ein streng hierarchisches System zur Zertifizierung von öffentlichen Schlüsseln. Eine Certificate Authority (CA) steht an der Spitze der Zertifizierungs-Hierarchie und signiert entweder direkt oder über Sub-CAs die Schlüssel aller Teilnehmer innerhalb der Public Key Infrastruktur (PKI). Die einzelnen Benutzer sind im Besitz ihres eigenen Schlüssels und des öffentlichen CA-Schlüssels und können dadurch die Gültigkeit unbekannter Zertifikate überprüfen.

Dadurch ergibt sich ein Sicherheitsrisiko, welches bei Wikipedia wie folgt beschrieben wird:

Für die Nutzung von S/MIME-Zertifikaten zur Verschlüsselung und Signierung wird aufgrund des Public-Key-Verschlüsselungsverfahrens ein Schlüsselpaar aus öffentlichem und privatem Schlüssel benötigt. Im Gegensatz zum Zertifikat können und sollten diese Schlüssel lokal beim Anwender erzeugt und mit den Zertifikaten verbunden werden. Oft werden die Schlüssel aber gleich von der Zertifizierungsstelle zusammen mit dem Zertifikat generiert und an den Anwender übermittelt. Dadurch ist der Zertifizierungsstelle der private Schlüssel bekannt, was unbedingt im Rahmen der Sicherheit vermieden werden sollte, da der Schlüssel in falsche Hände gelangen kann. Es gibt aber auch Verfahren, bei denen die Schlüssel durch den Webbrowser des Anwenders erzeugt werden. Dabei verlässt der private Schlüssel den PC des Benutzers nicht.

Nach den Enthüllungen rund um die NSA Affäre stehe ich zentralen Zertifizierungsstellen skeptisch gegenüber. Die meisten dieser Zertifizierungsstellen haben ihren Sitz in den USA und es liegt der Verdacht nahe, dass die Geheimdienste durch Hintertüren oder eingebaute Schwachstellen, die mittels dieser Zertifikate geschützte Kommunikation mitlesen können. Auf gut Deutsch: Mein Vertrauen in diese Zertifizierungsstellen wurde schwer in Mitleidenschaft gezogen.

Aus diesem Grund, und aufgrund der Tatsache, dass ich privat vorwiegend auf die Betriebssysteme Linux und Android setze, fiel meine Entscheidung auf GnuPG, welches für alle gängigen Betriebssysteme frei verfügbar ist.

Fazit: Bisher haben wir nur ein paar Überlegungen zu vertraulicher Kommunikation und möglichen Lösungen getroffen. Ihr seht wie lang dieser Artikel geworden ist. Dabei haben wir noch nicht ein Programm installiert, keine Nachricht signiert und auch noch keine Nachricht verschlüsselt.

In einem der nächsten Artikel werde ich mich daran wagen, mit Hilfe von GnuPG ein Schlüsselpaar zu erzeugen und eine erste verschlüsselte Nachricht zu versenden.

Kommentar zum NSA Überwachungsskandal

Schreibe eine Antwort

Der NSA-Überwachungsskandal war ein, wenn nicht das Thema für das diesjährige Sommerloch.

Zwischen den Enthüllungen von Edward Snowden und den Beschwichtigungsversuchen von Innenminister Friedrich, brachte uns die deutsche Wirtschaft auch noch „E-Mail Made in Germany“.

Doch ist die ganze Aufregung überhaupt gerechtfertigt? Surfte man die letzten zwei Jahrzehnte nicht mit Scheuklappen durchs Internet, dürfte einen der NSA-Skandal nicht mehr, als ein müdes Lächeln abringen. Das die Industrienationen dieser Welt untereinander Wirtschaftsspionage betreiben, dürfte nicht verwundern. Das sie dies nicht an die große Glocke hängen ebenfalls nicht.

Auch, dass die Amerikaner sich nicht viel um Datenschutz scheren leuchtet schnell ein. Fällt starke Verschlüsselung in den U.S.A. doch unter das Waffengesetz. Erlaubt sind dort nur schwache (und teils veraltete) Verschlüsselungsalgorithmen, welche einfach zu brechen sind. Starke Verschlüsselung ist genehmigungspflichtig und geht oft mit dem Einbau einer Hintertür für die Geheimdienste und Ermittlungsbehörden einher.

Wer sich angesichts dieser Tatsachen wundert oder gar beschwert, dass die eigenen E-Mails bei GMail, Microsoft oder der Telekom von den Ermittlungsbehörden gescannt, gefiltert und ausgewertet werden, hat das Internet nicht verstanden. So ist eine E-Mail doch nicht mehr, als eine elektronische Postkarte. Auf jedem Server, den sie passiert, kann sie von jedem mit Zugriff auf den Datenstrom gelesen, kopiert und sogar verändert werden. Gegenüber der Postkarte hat die E-Mail sogar noch einen weiteren Nachteil. Während die Postkarte nur noch der Empfänger lesen kann, wenn sie am Kühlschrank hängt, kann die E-Mail auf dem Server des Providers immer noch von jedem gelesen und kopiert werden.

Da hilft auch das neue Wunderprodukt „E-Mail Made in Germany“ nicht viel, welches von der Telekom und United Internet ins Leben gerufen wurde. Die durchgängige Transportverschlüsselung ist eine wirksame Marketingstrategie. Ob sich dadurch auch das Sicherheitsgefühl steigern lässt, hängt vor allem davon ab, wie sehr man den deutschen Behörden vertraut. Dies muss jeder für sich selbst entscheiden.

Zum Glück ist das Sommerloch bald vorbei. Dann hören die Berichte über Verstöße gegen den Datenschutz und ausufernde Überwachung wieder auf. Die Aufregung verklingt und man richtet das Augenmerk wieder auf die wichtigen Themen, wie „Germany’s next Top Model“ oder „Fang dir einen Millionär“.

Und an die Geheimdienste dieser Welt:

Spart euch doch das viele Geld, für teure Überwachungssysteme. Steht doch eh fast alles in öffentlich zugänglichen Facebookprofilen.