Sep 25

Im Zuge der DSGVO ist das Thema eMail-Verschlüsselung aktueller denn je. Aus diesem Grunde wird in den nächsten Artikeln ausführlich auf die Einrichtung der eMail-Verschlüsselung mit OpenPGP unter Ubuntu, Windows und Android eingegangen.

Zunächst jedoch ein paar allgemeine Gedanken zur Erstellung, Übertragung und Verschlüsselung von eMails, da es bereits hier einige Unterschiede gibt. Sowie dem Grund, weshalb die Entscheidung für OpenPGP gefallen ist.

Möglichkeiten der Erstellung

Für die Erstellung von eMails gibt es generell zwei Möglichkeiten. Entweder werden eMails mittels eines lokal auf dem Gerät installiertem Mail-Programm wie Outlook (Windows/Mac), Thunderbird (Windows/Mac/Linux), Clawsmail (Windows/Linux), KMail (Linux) oder K-9 Mail (Android) erstellt und versendet oder über das Webinterface des eMail-Anbieters, beispielsweise bei GMX, 1&1, Web.de oder Yahoo.
Es sollte dabei berücksichtigt werden, das beide Möglichkeiten parallel genutzt werden können.

Möglichkeiten der Übertragung

Versender -> Mail-Server des Versenders / Mail-Server des Empfängers -> Empfänger
Bei Nutzung des Webinterfaces sollte dies immer über eine HTTPS-Verbindung, sprich verschlüsselt erfolgen. Bei Nutzung eines Mail-Programmes immer per TLS-Verschlüsselung.

Mail-Server des Versenders <-> Mail-Server des Empfängers
Im Idealfall unterstützen sowohl eMail-Anbieter des Versenders, wie auch der eMail-Anbieter des Empfängers die DANE-Technik und übertragen zwischen Ihren Mail-Servern die eMails per TLS-Verschlüsselung.
Selbst wenn die DANE-Technik nicht unterstützt wird, ist die TLS-Verschlüsselung für die eMail-Übertragung zwischen den eMail-Anbietern bereits eine Verbesserung der Sicherheit gegenüber der zuvor gängigen Praxis der unverschlüsselten Übertragung, welche nicht mehr eingesetzt werden sollte.

Möglichkeiten der Verschlüsselung

Für die Verschlüsselung der eMails gibt es aktuell zwei etablierte aber leider bisher zu wenig genutzte Verfahren S/MIME und OpenPGP.

Beiden gemein ist, das Sie digitale Signaturen unterstützen und die Inhalte der eMails verschlüsseln, jedoch nicht die Meta-Daten. Weshalb zusätzlich die verschlüsselte Übertragung der eMails für einen sinnvollen Schutz notwendig ist.

Ohne dieser Ende-zu-Ende Verschlüsselung würden die eMails ansonsten auf den zur Übertragung genutzten Mail-Servern im Klartext vorliegen.

Alternative Möglichkeiten

Es gibt alternative Möglichkeiten der sicheren eMail-Übertragung, deren Reichweite jedoch eingeschränkt und teilweise kostenpflichtig sind.

DE-Mail
Das Hauptziel ist es, Nachrichten und Dokumente über das Internet vertraulich, sicher und nachweisbar zu versenden und zu empfangen und damit ein elektronisches Pendant zur heutigen Briefpost zu etablieren.(Quelle: Wikipedia)
Nachteil ist, das sowohl Versender, wie auch Empfänger eine spezielle DE-Mail-eMail-Adresse benötigen. Sprich die Kommunikation nur innerhalb des DE-Mail Systems möglich ist!
Weiterhin ist DE-Mail nicht kostenfrei, sondern wir pro eMail abgerechnet, weshalb es gerade bei großen Unternehmen bzw. Unternehmen mit hohem eMail-Aufkommen zu einem Kostenfaktor werden kann.

eMail-Made-In-Germany
Im Gegensatz zur DE-Mail ist dieses System kostenfrei, hat aber den gleichen Nachteil wie DE-Mail, weil die gesicherte Kommunikation nur innerhalb des eMail-Made-In-Germany Systems sichergestellt werden kann. Die Teilnehmer sind seit Beginn der Initiative begrenzt und die Aufnahme neuer Teilnehmer scheint unmöglich. (Quelle: „E-Mail made in Germany“ verhindert systematisch Teilnahme anderer Provider)

Entscheidungsgründe für OpenPGP

Wir möchten hier eine Möglichkeit der verschlüsselten eMail-Kommunikation aufzeigen, bei welcher keine Beschränkung auf ein proprietäres System, einen eingeschränkten Nutzerkreis oder welche mit zusätzlichen Kosten verbunden ist.

Hier bieten sich die beiden Verfahren S/MIME und OpenPGP an, welche seit vielen Jahren ein offener Standard sind, jedoch deren Verbreitung sich bisher nicht flächendeckend durchsetzen konnte.

Auf Grund der im Mai 2018 veröffentlichen EFAIL Sicherheitslücken und dem Umstand das das S/MIME-Verfahren grundsätzlich keine Möglichkeiten bietet sich dagegen zu schützen, haben wir uns für das OpenPGP-Verfahren entschieden. Denn beim OpenPGP-Verfahren gibt es Möglichkeiten des Schutzes, welche teilweise durch die Programme selbst umgesetzt werden können bzw. umgesetzt sind und teilweise durch Sicherheitseinstellungen des Nutzers vorgenommen werden können.

Tagged with:
Apr 13

Heute hatten wir ein kurioses Problem mit einem Apache 2.2.22 Server.
Es ging um eine Domain, welche zwei Sub-Domains hat, wovon eine korrekt funktionierte und die andere nicht, sprich diese immer wieder zur Hauptdomain umleitete.

Der Aufbau der Verzeichnisstrucktur ist wie folgt:

/srv/www/webseite <- Hauptdomain www.muster.de
/srv/www/webseite/TEST <- Sub-Domain Nr. 1 test.muster.de
/srv/www/webseite/DEMO <- Sub-Domain Nr. 2 demo.muster.de

Der Nameserver ist korrekt konfiguriert:

muster.de. IN SOA ns1.nameserver.de. dns.ns.de. (
20170413
1800
3600
3600000
1800 )
muster.de. IN NS ns1.ns.de.
muster.de. IN NS ns2.ns.de.

muster.de. IN A 80.80.80.80
www IN A 80.80.80.80
demo IN A 80.80.80.80
test IN A 80.80.80.80
ftp IN CNAME ftp.ns.de.

mail IN CNAME mail.ns.de.
muster.de. IN MX 10 mx1.ns.de.
muster.de. IN MX 20 mx2.ns.de.

Und auch der Apache war korrekt konfiguriert:

<VirtualHost 80.80.80.80:80>

ServerName www.muster.de
ServerAlias muster.de
ServerAdmin webmaster@ns.de

DocumentRoot /srv/www/webseite
ScriptAlias /cgi-bin/ „/srv/www/cgi/“

CustomLog /var/logs/www/www.muster.de_combined_access.log combinedio
ErrorLog /var/logs/www/www.muster.de_error.log

</VirtualHost>

<VirtualHost 80.80.80.80:80>

ServerName demo.muster.de
ServerAdmin webmaster@ns.de

DocumentRoot /srv/www/webseite/DEMO
ScriptAlias /cgi-bin/ „/srv/www/cgi/“

CustomLog /var/logs/www/www.muster.de_combined_access.log combinedio
ErrorLog /var/logs/www/www.muster.de_error.log

</VirtualHost>

<VirtualHost 80.80.80.80:80>

ServerName test.muster.de
ServerAdmin webmaster@ns.de

DocumentRoot /srv/www/webseite/TEST
ScriptAlias /cgi-bin/ „/srv/www/cgi/“

CustomLog /var/logs/www/www.muster.de_combined_access.log combinedio
ErrorLog /var/logs/www/www.muster.de_error.log

</VirtualHost>

Zum Test lag in den beiden Unterverzeichnissen DEMO und TEST jeweils eine Datei test.html!

Der Aufruf test.muster.de/test.html erfolgte korrekt, sprich in der Webbrowser-Adress-Zeile stand dann auch noch test.muster.de/test.html und im Apache Log:
200.200.200.200 - - [13/Apr/2017:14:20:23 +0200] "GET /test.html HTTP/1.1" 200 24 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36" 439 491

Im Gegensatz zum Aufruf demo.muster.de/test.html, denn hier erfolgte eine 301-Weiterleitung nach www.muster.de/DEMO/test.html, was dann auch in der Webbrowser-Adress-Zeile angezeigt wurde und im Apache Log folgendes stand:
200.200.200.200 - - [13/Apr/2017:15:09:07 +0200] "GET /test.html HTTP/1.1" 301 203 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36" 421 658
200.200.200.200 - - [13/Apr/2017:15:09:07 +0200] "GET /DEMO/test.html HTTP/1.1" 200 24 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/53.0.2785.143 Chrome/53.0.2785.143 Safari/537.36" 443 491

Leider konnte mir Google & Co. hier nichts wirklich weiterhelfen, so das ich begann, die beiden Verzeichnisse vom Inhalt her zu vergleichen.

Die Lösung lag in der fehlenden .htaccess Datei im Verzeichniss /srv/www/webseite/DEMO

Vom TEST-Verzeichniss die Datei .htaccess ins DEMO-Verzeichniss kopiert und es lief sofort. Warum ist mir zwar nicht ganz klar und für einen entsprechenden Kommentar wäre ich auch dankbar aber ich hoffe zumindest anderen mit dem gleichen Problem weiterhelfen zu können.

Tagged with:
Sep 09

Vorgabe:
Eine zusätzliche SSD mit kompletter Verschlüsselung als Laufwerk einbinden, wobei bei Booten keine zusätzliche Passwortabfrage erfolgen soll!

Lösung:

Die SDD ist in meinem Fall /dev/sdd und muß entsprechend eurer Konfiguration angepasst werden.

1. Primäre Partition mit voller Größe erstellen am einfachsten mittels
sudo cfdisk /dev/sdd
-> Erstellen -> volle Größe -> Schreiben -> Ende

2. Nach folgender Anleitung einrichten:

2.1. Anfang der zu verschlüsselnden Partition mit Zufallsbytes überschreiben:
sudo dd if=/dev/urandom bs=1M count=8 of=/dev/sdd1

2.2. Jetzt die Partition verschlüsseln:
sudo cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 /dev/sdd1

2.3. Zuweisung der verschlüsselten Partition /dev/sdd1 dem virtuellem Gerät sdd1_crypt welches dann unter /dev/mapper/sdd1_crypt erreichbar ist:
sudo cryptsetup luksOpen /dev/sdd1 sdd1_crypt

2.4. Die Partition unter dem virtuellen Gerät /dev/mapper/sdd1_crypt kann jetzt mit dem gewünschtem Dateisystem beschrieben werden (in meinem Fall ext4):
sudo mkfs.ext4 /dev/mapper/sdd1_crypt

2.5. Nun kann die Partition gemountet werden:
sudo mount /dev/mapper/sdd1_crypt /data2

3. Da die Festplatte beim Systemstart automatisch und ohne Eingabe des Passwortes ins System eingebunden (gemountet) werden soll, ist dies recht elegant mit einem Keyfile möglich, wobei diese Lösung hier nur Sinn macht, wenn das System komplett ebenfalls verschlüsselt ist und somit das Keyfile im /root des verschlüsselten Systems liegt!
Als Vorlage habe ich hier folgenden Beitrag genommen.

3.1. Ein zufälliges Keyfile erzeugen
sudo dd if=/dev/urandom of=/root/keyfile_0x000c58a6 bs=1024 count=4

3.2. Nur root darf Zugriff auf dieses Keyfile haben!
sudo chmod 0400 /root/keyfile_0x000c58a6

3.3. Das Keyfile für die verschlüsselte Partition /dev/sdd1 hinzufügen
sudo cryptsetup luksAddKey /dev/sdd1 /root/keyfile_0x000c58a6

3.4. In der crypttab einen Eintrag hinzufügen um das Keyfile dem virtuellen Gerät /dev/mapper/sdd1_crypt zuzuordnen
sudo nano /etc/crypttab

sdd1_crypt UUID=53baf3bf-dd24-64fa-bbcf-b144870c09d3 /root/keyfile_0x000c58a6 luks,discard

3.5. In der fstab die Partition zum mounten eintragen
sudo nano /etc/fstab

/dev/mapper/sdd1_crypt /data2 ext4 defaults 0 2

4. Rechner neu starten und die neue SSD steht unter /data2 komplett verschlüsselt zur Verfügung! 🙂

Tagged with:
preload preload preload