Autorenarchiv: Jörg Kastning

Meine Daten gehören mir

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

Logging und logrotate mit NGINX

In diesem Artikel wird beschrieben, wie ich das Logging und logrotate meines NGINX-Servers konfiguriert habe. Dabei gehe ich kurz auf die beiden verwendeten Direktiven error_log und ngx_http_log_module ein.

Damit dient dieser Artikel meiner Dokumentation und evtl. euch als Anregung, ein eigenes Logging zu konfigurieren.

Logging

Informationen zum Logging findet man in der offiziellen NGINX-Dokumentation.[1. NGINX-Dokumentation] Im folgenden werden die Direktiven error_log[2. NGINX core module error_log] und ngx_http_log_module[3. NGINX – ngx_http_log_module] verwendet.

Mein Server liefert mehrere Webseiten aus. Ich möchte gern für jede Webanwendung ein separates Error-Log und Access-Log schreiben. Dabei wird folgendes Muster verwendet:

  • Log-Verzeichnis: /var/www//logs
  • Name für error_log: _error.log
  • Name für access_log: _access.log

Konfiguration des Error-Log

Die Error_log-Syntax ist denkbar einfach:

error_log log_file [ log_level ]

log_file gibt den Pfad zur Log-Datei an. Mit log_level wird bestimmt, wie viele Informationen protokolliert werden sollen.

Log-Level[4. How To Configure Logging and Log Rotation in Nginx on an Ubuntu VPS]

  • emerg: Notfall, in dem sich das System in einem nicht nutzbaren Zustand befindet
  • alert: Ernste Störung. Sofortiger Eingriff ist erforderlich
  • crit: Kritische Probleme, um die man sich kümmern sollte
  • error: Ein Fehler ist aufgetreten. Hier funktioniert etwas nicht
  • warn: Ein ungewöhnliches Ereignis ist aufgetreten. Dies ist jedoch kein Grund zur Sorge
  • notice: Normale Vorgänge werden ebenfalls protokolliert
  • info: Unnützes Wissen – Nice to know
  • debug: Debugging-Informationen, welche helfen, ein Problem näher zu analysieren

Die Log-Level sind nach Priorität angeordnet. Wird das Level auf „error“ gesetzt, so werden alle Events der Level error, crit, alert und emerg protokolliert.

Möchte man rein gar nichts protokollieren, muss das Log nach /dev/null umgeleitet werden.

error_log /dev/null crit;

Konfiguration des Access-Log

Das Modul ngx_http_log_module besteht aus den Direktiven access_log, log_format und open_log_file_cache, von denen ich hier nur die ersten beiden verwenden werde.

Mit der Direktive log_format kann das Format der Log-Dateien konfiguriert werden. Die einzelnen Formate werden über einen Bezeichner ausgewählt. Dies kann z.B. wie folgt aussehen:

log_format compression '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $bytes_sent '
                       '"$http_referer" "$http_user_agent" "$gzip_ratio"';

access_log /spool/logs/nginx-access.log compression buffer=32k;

Eine detaillierte Beschreibung aller verfügbaren Parameter kann der offiziellen Dokumentation entnommen werden.[5. NGINX -log_format]

Ich selbst verwende aktuell ausschließlich das Format combined. Dieses ist bereits in der Standardinstallation enthalten. Es sieht wie folgt aus:

log_format combined '$remote_addr - $remote_user [$time_local]  '
		    '"$request" $status $body_bytes_sent '
		    '"$http_referer" "$http_user_agent"';

Für die Protokollierung meiner Webanwendungen wird daher folgendes in die jeweiligen Server-Direktiven eingetragen:

server {
...
access_log /var/www//logs/_access.log combined;
...
}

Falls man das Access-Log deaktivieren möchte, kann man dies durch den folgenden Eintrag erreichen:

access_log off;

Nun werden schon mal alle Log-Dateien nach Webanwendungen getrennt in das Verzeichnis /var/www//logs geschrieben.

Im nächsten Abschnitt gehe ich darauf ein, wie man verhindert, dass die Festplatte mit Log-Dateien vollgeschrieben wird.

Rotation der NGINX Log-Dateien

Zum Rotieren der Logs verwende ich die Anwendung logrotate. Diese ist bei Ubuntu bereits in der Standardinstallation enthalten.

Es wird ein Skript im Verzeichnis /etc/logrotate.d erstellt und folgender Inhalt eingefügt.

/var/www//logs/*.log {
        daily
        missingok
        rotate 31
        compress
        delaycompress
        notifempty
        sharedscripts
        postrotate
                [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
        endscript
}

Mit diesem Skript wird logrotate angewiesen, die Log-Dateien im Verzeichnis /var/www//logs/ täglich zu rotieren und die letzten 31 Log-Dateien zu behalten. Die Log-Datei wird nicht rotiert, falls sie leer ist, also keine Einträge enthält. Die älteren Dateien werden dabei komprimiert, um Speicherplatz zu sparen.

Die generelle Beschreibung von logrotate würde den Rahmen dieses Artikels sprengen. Weitere Informationen sind in der Manpage zu finden.[6. logrotate(8) – Linux man page]

Damit ist der verspätete Frühjahrsputz auf diesem Server beendet.

SSL-Schwachstelle bedroht Web- und Mail-Server

Diverse Seiten im Internet berichten über eine neue SSL-Schwachstelle, die durch eine sogenannte Logjam-Attacke ausgenutzt werden kann.[1. Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet] [2. Tausende Web-Server betroffen: Neue HTTPS-Sicherheitslücke aufgetaucht] [3. Guide to Deploying Diffie-Hellman for TLS]

Dieser Artikel beschreibt, wie sich NGINX, Postfix und Dovecot härten lassen. Damit sind diese Dienste nicht mehr verwundbar für die aktuelle SSL-Schwachstelle.

Ich beschreibe die drei genannten Dienste, da ich diese selbst auf mehreren Ubuntu-Servern betreibe. Für weitere Dienste schaut bitte in der Quelle unter Punkt „3.“ nach.

Zu Beginn wird eine Diffie-Hellman-Group für den Server generiert:

openssl dhparam -out dh_params.pem 2048

Anschließend folgt die Härtung der einzelnen Dienste.

NGINX

Im server Block der jeweiligen Webpräsenz werden die zu verwendenden „Cipher Suites“ und Diffie-Hellman-Parameters angegeben:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;

ssl_dhparam /pfad/zur/dh_params.pem;

Anschließend wird der Dienst zur Übernahme der Einstellungen neu geladen:

sudo service nginx reload

Postfix

Beim MTA Postfix werden beide Parameter in der Datei /etc/postfix/main.conf eingetragen:

smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtpd_tls_dh1024_param_file = /pfad/zur/dh_params.pem

Auch hier werden die Einstellungen anschließend neu eingelesen:

sudo service postfix reload

Dovecot

Die beiden Parameter werden in die Datei /etc/dovecot/conf.d/10-ssl.conf eingetragen:

ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_prefer_server_ciphers = yes

#regenerates every week
ssl_dh_parameters_length = 2048

Und auch hier werden die Änderungen anschließend eingelesen:

sudo doveadm reload

Damit sollte man vor dieser Schwachstelle vorerst geschützt sein.

Thunderbird Adressbuch mit ownCloud Kontakten synchronisieren

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.

Cisco AnyConnect VPN Client unter Ubuntu installieren

Dieser Artikel beschreibt die Installation des Cisco AnyConnect VPN Client unter Ubuntu Trusty Tahr.

Laut einem Dokument[1. AnyConnect – Unterstützte Betriebssysteme und Systemvoraussetzungen], dass ich bei der Universität Bielefeld gefunden habe, werden Ubuntu 9.x und 10.x unterstützt. Ich konnte den Client jedoch auch problemlos unter Ubuntu 14.01.1 LTS installieren.

Dazu habe ich einfach das Installationsskript vpnsetup.sh heruntergeladen, ausführbar gemacht und ausgeführt.

:~$ wget https://github.com/Tronde/Schriftrolle/blob/master/vpnsetup.sh
:~$ sudo chmod u+x vpnsetup.sh
:~$ sudo ./vpnsetup.sh

Ist das Setup durchgelaufen, kann der Client aus dem Anwendungsmenü heraus gestartet werden.

cisco anyconnect secure mobility client

Cisco AnyConnect Secure Mobility Client

In das Feld „Connect to“ müsst ihr nun nur noch eureb Verbindungsserver eintragen und schon kann es losgehen.

Die Installation ist damit abgeschlossen. Das war es schon. :-)

Das lokale Paketarchiv aufräumen

Während ich im Artikel „Automatische Installation von Sicherheitsupdates“ beschrieben habe, wie man Sicherheitsupdates unter Ubuntu automatisch installieren lassen kann, werde ich hier kurz beschreiben, wie das lokale Paketarchiv automatisch bereinigt werden kann.

In der Datei /etc/apt/apt.conf.d/10periodic gibt es unter anderem den folgenden Eintrag:

APT::Periodic::AutocleanInterval "0";

Dieser Wert gibt an, in welchem Intervall (in Tagen) das lokale Archiv der Paketquellen bereinigt werden soll. Dieser Wert steht standardmäßig auf „0“. Damit wird das Paketarchiv gar nicht automatisch bereinigt. Um dies zu ändern trägt man hier einfach einen Wert seiner Wahl ein. So lasse ich das Paketarchiv bspw. alle 28 Tage bereinigen:

APT::Periodic::AutocleanInterval "28";

Viele Grüße
Tronde

Installation von VMware Tools in einer Ubuntu VM

Update 2021-06-09

Um den Netzwerkadapter VMXNET3[1. Choosing a network adapter for your virtual machine (1001805)] in einem virtuellen Ubuntu verwenden zu können, müssen die VMware Tools installiert sein. In den aktuellen Versionen von Ubuntu und weiteren Distributionen wie z.B. RHEL, SLES, etc. sind inzwischen Treiber für die VMXNET3-Netzwerkkarte enthalten. Dennoch ist die Installation der VMware Tools empfohlen.
Dieser Artikel beschreibt zwei Methoden, wie dies getan werden kann. Ich gehe dabei ausschließlich auf die Installation unter Verwendung der Kommandozeile (CLI) ein.

Methode 1 – Open-VM-Tools

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB2073803[2. VMware support of open-vm-tools (2073803)].

Bei den open-vm-tools handelt es sich um die Open Source Implementierung der VMware Tools. Die Vorteile dieser Implementierung sind:

  • Die Open-VM-Tools sind in den offiziellen Paketquellen von Ubuntu enthalten. Dadurch wird das Deployment von virtuellen Ubuntu VMs entschieden vereinfacht. Die Installation kann direkt aus den Quellen durchgeführt werden. Es muss nicht auf separate Quellen zurückgegriffen werden.
  • Keine Downtime für das Update der VMware Tools. Das Paket open-vm-tools wird automatisch über die Paketverwaltung aktualisiert.
  • Keine Kompatibilitätsprüfung erforderlich. Aus den Paketquellen wird automatisch das zum Betriebssystem passende Paket installiert.

Die Installation der Tools ist denkbar einfach und geschieht z.B. mittels:

sudo apt-get install open-vm-tools

VMware empfiehlt ausdrücklich die Verwendung der Open-VM-Tools.[3. VMware Tools in an Ubuntu 14.04 Guest] Wer sich über den aktuellen Entwicklungsstand der Open-VM-Tools informieren möchte, kann dies auch direkt auf GitHub tun. [4. https://github.com/vmware/open-vm-tools]

Methode 2

Diese Methode verbleibt der Vollständigkeit halber im Artikel. Es wird ausdrücklich Methode 1, wegen der dort genannten Vorteile, empfohlen.

Dieser Abschnitt basiert auf dem VMware Knowledge Base Artikel KB1022525[5. Installing VMware Tools in an Ubuntu virtual machine (1022525)] und führt die einzelnen Schritte auf, die benötigt werden, um die VMware-Tools in einer VM mit Ubuntu zu installieren.

Abhängigkeiten der VMware-Tools

Um die VMware Tools installieren zu können, müssen folgende Pakete auf dem System installiert sein:

  • gcc
  • binutils
  • make
  • kernel sources

Installation auf der Kommandozeile

Als Erstes wird ein Rechtsklick auf die VM in der Bestandsliste des vSphere-Clients ausgeführt. Aus dem Kontextmenü wählt man „Gast -> VMware Tools installieren/aktualisieren“.

In der laufenden Ubuntu-VM werden nun die folgenden Kommandos ausgeführt:

sudo mkdir /mnt/cdrom
sudo mount /dev/cdrom /mnt/cdrom
tar xzvf /mnt/cdrom/VMwareTools-.tar.gz -C /tmp/
cd /tmp/vmware-tools/distrib/
sudo ./vmware-install.pl -d

Nach Abschluss der Installation ist ein Neustart auszuführen. Nun kann anstatt des veralteten E1000 auch der aktuelle Netzwerkadapter VMXNET3 zur VM hinzugefügt und verwendet werden.

Testinstanz für einen WordPress Blog erstellen

Um Änderungen an der Konfiguration und den Dateien meines Blogs gefahrlos testen zu können, möchte ich eine Testinstanz meines Blogs einrichten. Die dazu erforderlichen Schritte werde ich in diesem Artikel dokumentieren.

Dieser Artikel ist keine Schritt-für-Schritt-Anleitung und kein Tutorial, welches man blind befolgen kann. So gehe ich hier z.B. nicht auf die allgemeine Webserverkonfiguration ein. Falls ihr hierzu Hilfe benötigt, schaut bitte in der offiziellen Dokumentation zu eurem Webserver nach.

Voraussetzungen

Ich betreibe meinen Blog bei einem deutschen Webhosting-Provider. Bei diesem habe ich über ein Kundencenter via FTP-Zugang Zugriff auf die Konfiguration und die Dateien meines Blogs.

Bei einem anderen deutschen Unternehmen betreibe ich noch einen Linux-Root-Server, welcher sich hervorragend eignet, um darauf eine Testinstanz einzurichten.

Daten sichern

Um die spätere Testinstanz mit den Daten des Live-Blogs füttern zu können, werden die Daten aus dem aktuellen Blog zuerst einmal gesichert.

Die Sicherung umfasst die Datenbank und das DocumentRoot des Blogs.

Zur Sicherung der Datenbank verwende ich das Tool MySQLDumper.[1. http://www.mysqldumper.de/] Mit diesem Werkzeug kann man über eine einfach zu bedienende Weboberfläche ein Backup seiner Datenbank erstellen. Dieses Backup wird anschließend zur weiteren Verwendung auf den lokalen Rechner heruntergeladen.

Im zweiten Schritt wird das DocumentRoot-Verzeichnis des Blogs gesichert. Hierzu nutze ich den FTP-Client FileZilla.[2. http://www.filezilla.de/]

Serverkonfiguration

Auf dem Linux-Root-Server laufen Ubuntu Server 14.04 LTS und der Webserver NGINX.[3. http://nginx.org/]

Für meine Webseiten verwende ich eine einheitliche Verzeichnisstruktur:

example.org/
├── logs
│   ├── access.log
│   └── error.log
└── public
    └── index.html

2 directories, 3 files

So wird für jede Webseite in separate Log-Dateien geschrieben, was eine Fehleranalyse deutlich erleichtern kann. Die Dateien der Webseite liegen im Verzeichnis public. Die Datei index.html stellt dabei aktuell nur einen Platzhalter dar, bis die gesicherten Daten des Live-Blogs eingespielt werden.

Den Platzhalter kann man nutzen, um zu testen, ob der Webserver korrekt konfiguriert ist und die im Verzeichnis public abgelegte Seite auch ausliefert.

Um die spätere Testinstanz über die gleiche URL aufrufen zu können, wie den Live-Blog, wird ein Eintrag in die /etc/hosts eingefügt. So erreicht man, dass die URL des Live-Blogs nun auf die IP-Adresse des Servers mit der Testinstanz zeigt.

Hat man alles richtig konfiguriert, wird man vom Webserver mit einem „Hallo Welt!“ begrüßt.

Zugriff beschränken

Während man eine neue Konfiguration testet, können Fehler passieren. Diese können zu Folge haben, dass der Blog nicht korrekt ausgeliefert wird. Für gewöhnlich ist nicht gewünscht, dass ein Benutzer dies sieht. Evtl. möchte man auch einfach nicht, dass Neuerungen zufällig schon von Besuchern entdeckt werden, bevor sie in den Live-Blog überführt wurden.

Daher scheint es sinnvoll den Zugriff auf die Testinstanz einzuschränken und einen Aufruf der Testinstanz erst nach erfolgreicher Authentifizierung mit Benutzername und Passwort zu erlauben.

Dazu eignet sich für NGINX-Benutzer das Modul ngx_http_auth_basic_module.[4. http://nginx.org/en/docs/http/ngx_http_auth_basic_module.html] Nutzer von Apache können .htaccess-Dateien[5. .htaccess – Wikipedia] verwenden. Da ich selbst einen NGINX betreibe, gehe ich im Folgenden auf das zuerst genannte Modul ein.

Zuerst wird die .htpasswd-Datei erstellt, welche Benutzernamen und Passwort für die Authentifizierung enthält.

sudo touch /etc/nginx/conf.d/.htpasswd

Um das Passwort in verschlüsselter Form speichern zu können wird das Paket apache2-utils benötigt. Dieses enthält das Programm htpasswd, mit welchem Benutzername und Passwort erzeugt werden.

:~$ sudo htpasswd -c /etc/nginx/conf.d/.htpasswd BENUTZERNAME
New password: 
Re-type new password: 
Adding password for user BENUTZERNAME

Der Benutzer, unter dessen Kontext der Webserver (NGINX) läuft, muss Zugriff auf die .htpasswd erhalten.

:~$ sudo chown www-data:www-data /etc/nginx/conf.d/.htpasswd

Nun öffnet man die Konfigurationsdatei für die Testseite, welche für gewöhnlich unterhalb von /etc/nginx/sites-available/ liegt. Hier ist folgende Konfiguration zu integrieren:

location / {
    auth_basic           "Authentifizierung erforderlich!";
    auth_basic_user_file conf.d/.htpasswd;
}

auth_basic aktiviert die Überprüfung von Benutzername und Passwort. auth_basic_user_file gibt den Pfad an, wo die .htpasswd-Datei liegt, gegen die geprüft wird.

Mit einem „configtest“ kann man seine Konfiguration auf syntaktische Fehler überprüfen und bei Bestehen der Prüfung die Konfiguration neu laden.

:~$ sudo service nginx configtest 
 * Testing nginx configuration                    [ OK ] 
jkastning@rs212997:~$ sudo service nginx reload
 * Reloading nginx configuration nginx            [ OK ]

Ab jetzt fragt NGINX nach einem Benutzernamen und Passwort, bevor er die Webseite mit dem „Hallo Welt.“-Slogan ausliefert.

Daten einspielen

Wenn der Webserver prinzipiell mit dem weiter oben erstellten vHost funktioniert und die „Hallo Welt.“-Seite ausliefert, werden als nächstes die Daten aus dem Live-Blog eingespielt.

Dazu werden der Datenbank-Dump und das im ersten Schritt gesicherte Verzeichnis auf den Linux-Root-Server hochgeladen. Ich habe dazu wieder FileZilla und das SFTP-Protokoll genutzt.

DocumentRoot

Die gesicherten Dateien und Verzeichnisse, müssen in das DocumentRoot-Verzeichnis der Testinstanz kopiert werden. In meinem Beispiel ist das das Verzeichnis /var/www/example.org/public/. Mit folgendem Befehl wird sichergestellt, dass der Webserver auch alle Dateien lesen kann.

sudo chgrp -R www-data /var/www/example.org/public

Die Datenbank

Bevor die Datenbanksicherung eingespielt werden kann, muss eine Datenbank und ein Datenbankbenutzer angelegt werden.

Wer hierbei Hilfe zur Syntax benötigt, kann im Artikel „Häufig verwendete MySQL-Befele“ nachlesen.

Ist dies erledigt, kann die Datenbanksicherung mit folgendem Befehl eingespielt werden.

mysql -u root -p db_name < db_sicherung.sql

Ober der angelegte Benutzer auch wirklich Zugriff auf die Datenbank hat, kann man mit dem folgenden Befehl überprüfen. Wenn alles stimmt, kann man sich so an der Datenbank anmelden.

mysql -u db_benutzer -p db_name

Fertig. Mein Testblog läuft und ich kann mich jetzt daran machen, mit der WordPress-Konfiguration zu experimentieren. :-)

Update vom 24.12.2016

Bei der gestrigen Aktualisierung der Testinstanz musste ich feststellen, dass zwar die Startseite des Blogs geladen wird, jedoch alle Artikelaufrufe in einen 404-Fehler laufen.

Die Ursache für diese Fehler liegt darin begründet, dass ich mit Nginx einen anderen Webserver verwendet, als mein Webhoster. Dieser behandelt die Permalinks von WordPress anders, als z.B. ein Apache-Webserver mit dem Modul mod_rewrite.

Eine Lösung für dieses Problem habe ich ziemlich schnell in der Nginx Library[6. Nginx Library - WordPress Permalinks {en}] gefunden. Es wird die try_files-Direktive[7. Nginx try_files directive {en}] verwendet, um aufgerufene URLs zur weiteren Behandlung an die index.php von WordPress weiterzuleiten.

Die Einrichtung ist relativ einfach. Das Vorgehen unterscheidet sich, je nach dem ob WordPress direkt im Wurzelverzeichnis einer Domain oder in einem Unterverzeichnis installiert ist. Im Folgenden werden beide Fälle betrachtet.

WordPress im Wurzelverzeichnis

Liegt die WordPress-Installation im Wurzelverzeichnis der Domain z.B. unter http://www.example.com, sucht man in der Konfigurationsdatei der Seite nach dem Block location /. Diesem Block wird folgende Zeile hinzugefügt:

try_files $uri $uri/ /index.php?$args;

Der vollständige Block sollte anschließend wie folgt aussehen:

location / {
    index index.php index.html index.htm;
    try_files $uri $uri/ /index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

WordPress in einem Unterverzeichnis

Liegt die WordPress-Installation in einem Unterverzeichnis der Domain z.B. unter http://www.example.com/wordpress, muss der Konfigurationsdatei ein Block nach dem Muster location /wordpress/ hinzugefügt werden, welcher wie folgt aussieht:

location /wordpress/ {
  try_files $uri $uri/ /wordpress/index.php?$args;
}

Abschießend muss die Konfiguration von Nginx neu geladen werden. Nun sollten auch die 404-Fehler behoben sein.

Ein Kalender für die Terminverwaltung

Nachdem ich in diesem Jahr bereits die Kontrolle über meine E-Mail-Postfächer zurück erlangt habe[1. Der eigene Mailserver – Start der Artikelreihe], gehe ich in diesem Artikel auf die Einrichtung eines Kalenders für die Terminverwaltung im Web und auf diversen Clients ein.

Zu Beginn des Artikels stehen meine Anforderungen an eine Kalender-Lösung. Anschließend gebe ich einen kleinen Überblick über verschiedene kostenlose Lösungen, bevor ich die Lösung näher beschreibe, für die ich mich letztendlich entschieden habe.

Eines sei vorab schon verraten. Bei allen Lösungen handelt sich sich um Software, die auf einem Linux-Webserver installiert werden kann. Die Verwendung eines Root-Servers stellt die größtmögliche Kontrolle über das eigene System und die eigenen Daten sicher.

Anforderungen

Die gesuchte Lösung soll die folgenden Anforderungen erfüllen:

  1. Der Kalender kann auf einem eigenen Server gehosted werden.
  2. Die Terminverwaltung kann über einen Webbrowser erfolgen.
  3. Der Kalender kann unter den mobilen Betriebssystemen Android und iOS genutzt werden.
  4. Eine Nutzung des Kalenders mit dem Mozilla Thunderbird-Plugin Lightning ist ebenfalls möglich.
  5. Mit Hilfe des Kalenders können Termine zwischen den genannten Betriebssystemen und Anwendungen synchronisiert werden.

Kurz angeschaut

Auf der Suche nach einer Lösung habe ich mir die folgenden Projekte kurz angeschaut. Auch wenn ich mich im Endeffekt für ownCloud entschieden habe, führe ich sie hier auf. Evtl. ist jemandem von euch mit einer dieser Lösungen am besten gedient.

Bei sabre/dav[2. Homepage sabre/dav] handelt es sich um einen CardDAV, CalDAV und WebDAV Server. SabreDAV ist komplett in PHP geschrieben und bietet vielfältige Möglichkeiten zum Teilen und Delegieren.

DAViCal[3. DAViCal Homepage] ist ein Server, welcher Kalendereinträge im iCalendar-Format speichern und bereitstellen kann. DAViCal ist in den Ubuntu-Paketquellen enthalten und im Ubuntuusers.de Wiki existiert ein deutschsprachiger Artikel[4. DAViCal im Ubuntuusers.de Wiki] dazu.

Radicale[5. Radicale – CalDAV and CardDAV Server] ist ein sehr einfach einzurichtender Server. Er ist in Python geschrieben und wurde unter der GPL 3 veröffentlicht.

Der ownCloud-Kalender

Meine Entscheidung ist auf den ownCloud[6. ownCloud Documentation Overview]-Kalender gefallen. Er erfüllt alle oben genannten Anforderungen. Darüber hinaus benutze ich bereits eine ownCloud-Instanz zur Verwaltung meiner Kontakte, Bilder und diverser Dateien.

Die Nutzung des ownCloud-Kalenders im Webbrowser ist selbsterklärend. Daher gehe ich an dieser Stelle nur auf die Einrichtung unter iOS, dem Thunderbird-Plugin Lightning und Android ein.

Für alle drei Clients benötigen wir die CalDAV-Adresse des Kalenders. Diese kann man sich anzeigen lassen, indem man auf das Zahnrad unten Links in der Kalenderansicht klickt.

owncloud_calendar

Ansicht eines ownCloud-Kalenders

Einrichtung unter iOS

Die hier beschriebene Einrichtung gilt für iOS 7.1.2. Für andere Versionen müssen die einzelnen Schritte evtl. an die jeweilige Version angepasst werden.

  1. Gehe zu „Einstellungen“ -> „Mail, Kontakte, Kalender“ -> „Account hinzufügen“.
  2. Wähle den Punkt „Andere“ -> „CalDAV-Account hinzufügen“.
  3. Bei „Server“ wird der Hostname eingetragen. Dies ist typischerweise der Name, den man in die Adresszeile des Webbrowsers einträgt, um sich mit der eigenen ownCloud zu verbinden. Benutzername und Kennwort entsprechen den Informationen, mit denen man sich an seiner ownCloud anmeldet. Anschließend kann man noch eine Beschreibung eingeben, um den Kalender in der Übersicht wiederzuerkennen.
  4. Im weiteren Verlauf aktiviert man SSL, falls der eigene Server dies unterstützt.
  5. Bei „Account-URL“ wird die URL eingetragen, welche im ownCloud-Kalender unter „iOS/OS X CalDAV-Adresse“ angezeigt wird.

Viel Spaß mit dem ownCloud-Kalender auf dem iPhone.

Einrichtung in Lightning

Lightning[7. Lightning – Thunderbird Mail DE] ist ein Kalenderplugin für den Mailclient Thunderbird. Es kann über die Thunderbird-Einstellungen -> Add-ons recht simpel gesucht und installiert werden.

In der Ansicht „Erweiterungen“ können die Lightning-Einstellungen konfiguriert werden. Die Dialogfelder sind übersichtlich und zum Großteil selbsterklärend. Anschließend geht es in der Kalenderansicht weiter.

Mit einem Rechtsklick in die Kalenderspalte kann ein neuer Kalender hinzugefügt werden. Im Dialogfenster ist „Im Netzwerk“ auszuwählen und im darauf folgenden Fenster die CalDAV-Adresse des Servers anzugeben.

calendar-caldav-link

CalDAV-Link des Kalenders

Doch Achtung, hier muss der korrekte CalDAV-Link verwendet werden. Dies ist nicht, wie man vermuten könnte, der primäre CalDAV-Link, welcher unter den Kalendereinstellungen der ownCloud zu sehen ist. Statt dessen ist der CalDAV-Link zu verwenden, der direkt neben dem Kalender eingeblendet werden kann.

Im folgenden Dialogfeld kann noch eine Farbe für den Kalender ausgewählt werden und es empfiehlt sich die Offline-Funktionalität zu aktiveren. So kann man den Kalender auch verwenden, wenn keine Online-Verbindung besteht.

Damit ist die Einrichtung des ownCloud-Kalenders in Lightning abgeschlossen.

Einrichtung unter Android

Ich habe den Kalender unter Android 5.0.2 durchgeführt. Die Einrichtung sollte unter den übrigen Android-Versionen jedoch ähnlich verlaufen.

Um den ownCloud-Kalender unter Android nutzen zu können, muss zuerst eine App installiert werden, welche die CalDAV-Unterstützung nachrüstet. Ich habe mich für die kostenlose App „Cal DAV Sync Free Beta“ entschieden. In diese werden Benutzername und Passwort eingetragen, mit denen man sich an seiner ownCloud anmeldet. Hier wird die primäre CalDAV-Adresse aus den Kalendereinstellungen eingetragen, um den Kalender einzubinden.

Damit sind die wichtigsten Einstellungen vorgenommen und der Einrichtungsdialog kann bis zum Ende durchlaufen werden.

Fazit

Die Einrichtung des ownCloud-Kalenders in den verschiedenen Anwendungen und Betriebssystemen ist nicht schwer, sofern man die korrekte CalDAV-Adresse für die jeweilige Anwendung verwendet.

Damit ist ein weiterer Schritt abgeschlossen, die Kontrolle über die eigenen Daten zurückzugewinnen. Der Google-Kalender kann nun in den Ruhestand geschickt werden. :-)

Die Termine können nun auf den verschiedenen Geräten verwaltet und synchronisiert werden. Für mich eine zufriedenstellende Lösung.

Enigmail unterstützt zukünftig nur noch GnuPG 2

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.