nachdem der letzte Eintrag jetzt ja doch wieder ein Weilchen her ist (keine Sorge, ich habe auch die Artikelserie zum Thema Sicherheit nicht vergessen, ich bin nur aktuell 1. beschäftigt und 2. nicht sonderlich motiviert) habe ich hier mal wieder ein Goodie für euch:

Ein Script, das dafür sorgt, dass man seinen tinc-VPN-Server als Exitnode für einen Tunnel nehmen kann ohne sich dabei die Finger zu brechen.

Warnung: YMMV, ich habe alles auf der Konsole gemacht, ich habe keine Ahnung, ob sich das Script mit GUI-Foo wie z.B. dem network-manager verträgt.

Vorbereitung:

tinc installieren:

# apt-get install tinc

tinc.conf erstellen:

# echo "# Kurzname des Routers/Computers Name = $NAME_DES_NODES # Mit folgenden Computern versuchen zu verbinden ConnectTo = $DEIN_SERVER # Arbeitsweise des VPN Mode = Router # alternativen Port zu 655 verwenden Port = 8656" > /etc/tinc/$DEIN_NETZWERK/tinc.conf

tinc-up erstellen:

# echo "#!/bin/sh ip addr add dev $INTERFACE 1.2.3.4/24 broadcast 1.2.255.255 ip link set dev $INTERFACE up" > /etc/tinc/$DEIN_NETZWERK/tinc-up

tinc-down erstellen:

# echo "#!/bin/sh ip route del default ip route add default via $ORIGINAL_GATEWAY dev $INTERFACE" > /etc/tinc/$DEIN_NETZWERK/tinc-down

Dateien ausführbar machen:

# chmod +x /etc/tinc/$DEIN_NETZWERK/tinc-*

Keys erstellen:
# mkdir /etc/tinc/$DEIN_NETZWERK/hosts
# tincd -n $DEIN_NETZWERK -K

Dieser Befehl erstellt einen private- und einen public-key. Bitte beim private-key einfach mit Enter bestätigen und beim public-key
den Speicherort /etc/tinc/$DEIN_NETZWERK/hosts/$NAME_DES_NODES wählen.

Jetzt passt Du die host-Datei an
# vi /etc/tinc/$DEIN_NETZWERK/hosts/$NAME_DES_NODES

Folgende Eintragungen sind vor dem Key zu machen:

Address = $IP_DES_NODES Address = $FQDN_DES_NODES_1 Address = $FQDN_DES_NODES_2 Port = 8656

Geh jetzt die gleichen Schritte auf Deinem Server nochmals durch. Du solltest jetzt auf Client und Server jeweils ein Exemplar der host-Datei haben, diese sollten natürlich unterschiedliche IPs haben und unterschiedliche Namen. Mein Laptop z.B. heißt loki, der Server heißt bifroest.

Jetzt kopierst Du die host-Datei von Deinem Client auf den Server und umgekehrt:

# scp /etc/tinc/$DEIN_NETZWERK/hosts/$NAME_DES_NODES root@server.

Wenn beide Dateien ausgetauscht sind sollten die beiden Rechner miteinander reden können:

# tincd -d 3 -n $DEIN_NETZWERK
startet den tinc-daemon mit log-level 3.

# tail -f /var/log/syslog
zeigt euch den Output. Wenn keine Fehlermeldungen aufblinken sollte es so weit tun.

Bis hierher ist das alles noch nichts besonderes, ihr habt jetzt also den ersten Schritt gemacht und könnt euren Server über ein VPN erreichen. So lange jetzt aber nicht alle Verbindungen über diesen Server geroutet werden, bringt euch das nicht wirklich weit.

Um sicherzustellen, dass das ganze Ding jetzt tut, was es soll, müsst ihr zunächst dem Server beibringen, das Richtige ™ zu tun.

Einsatz als Exitnode:

Dazu verbindet ihr euch mit dem Server:
$ ssh root@server.tld

und führt dort folgende Befehle durch:

# iptables -t nat --append POSTROUTING -i $DEIN_NETZWERK -j MASQUERADE iptables -t nat --append POSTROUTING -j MASQUERADE iptables -t nat --append PREROUTING -i $DEIN_NETZWERK -j ACCEPT cat /proc/sys/net/ipv4/ip_forward

Das sorgt dafür, dass euer Server Verbindungen einfach durchschleift und sie nicht zwischendrin blockiert.

Wenn der Server so weit vorbereitet ist, könnt ihr das folgende Script auf dem Client ausführen:

#!/bin/sh #I don't think that this is necessary but I'll do it anyway: #License: CC #define variables GW="$(ip r get 8.8.8.8 | gawk '{print $3}')" TUN="$IP_DES_SERVERS_IM_VPN" INTERFACE="$(ip r get 8.8.8.8 | gawk '{print $5}')" EXIT="$IP_DEINES_SERVERS/32" # change routes ip route del default ip route add $EXIT via ${GW%0x*} dev ${INTERFACE%0x*} ip route add $TUN dev $DEIN_NETZWERK ip route add default via $TUN dev $DEIN_NETZWERK echo 'nameserver 8.8.8.8' > /etc/resolv.conf echo "routes established" ip r show
Ja, das sind mindestens 2 dirty hacks: awk den Hex-Wert abgewöhnen und die resolv.conf überschreiben aber es funktioniert. Ich habe
das Script unter /etc/tinc/$DEIN_NETZWERK/tinc-route gespeichert. Außerdem habe ich ein weiteres Script angelegt:

# echo "#!/bin/sh tincd -n $DEIN_NETZWERK" > /etc/tinc/$DEIN_NETZWERK/tinc-auto

Dieses dient dazu, beim Start der Netzwerkverbindung den tinc-daemon automatisch anlaufen zu lassen.

Meine /etc/network/interfaces habe ich angepasst wie folgt:

# dhcp-basiertes Kabelnetz iface auto inet dhcp pre-up "/etc/tinc/bifroest/tinc-auto" post-up "/etc/tinc/bifroest/tinc-route"

Damit startet zunächst der tinc-daemon, dann bezieht das interface eine IP und dann werden die Routen angepasst.

Wenn ihr jetzt # mtr eingebt, sollte eure Route über euren Server verlaufen.

Fragen oder Anmerkungen wie immer jederzeit gern in den Kommentaren.

Zunächst einmal sollte man wohl beim Thema E-Mails ansetzen. Eine E-Mail ist, wie der Name schon sagt, eine elektronisch versendete Nachricht. Die Einzelheiten dazu findet ihr hier und hier.

Die Besonderheit dabei ist, dass E-Mails mitnichten mit Briefen gleichzusetzen sind, wie allenthalben angenommen wird. Vielmehr sind E-Mails das digitale Äquivalent zur Postkarte: Billig, schnell und lesbar von jedem, der sie auf dem Weg vom Sender zum Empfänger in die Hände bekommt. Mit ein wenig Geschick sind sie sogar manipulierbar und bergen damit ein großes Potenzial für Misslichkeiten aller Arten.

Dagegen hilft nicht viel, die einzige Möglichkeit um aus einer Postkarte eine sichere (siehe dazu auch einen älteren Eintrag) Möglichkeit zur Kommunikation zu machen ist, sie in einen Umschlag zu stecken und den Umschlag zu versiegeln. Wird das Siegel gebrochen weiß der Empfänger, dass die Nachricht nicht mehr in dem Zustand ist, in dem sie den Sender verlassen hat.

Das gleiche kann man problemlos auch bei E-Mails tun: Umschläge und Siegel benutzen.

Dazu installiert man sich das FOSS-Programm GPG, mit dessen Hilfe man sich die Umschläge und das Siegel selbst bauen kann. In den meisten Linux-Distributionen zählt GPG als Bordmittel und ist dementsprechend vorinstalliert. Der Grund dafür ist, dass GPG weit mehr kann, als nur E-Mails verschlüsseln. Was das ist kann man bei Interesse auf der Projektwebsite nachlesen.

Im Interesse der Benutzerfreundlichkeit empfehle ich außerdem, das Programm “Mozilla Thunderbird” sowie dessen Extension “Enigmail” zu installieren. Beides ist in den Debian-Repositories hinterlegt.

Wenn alles installiert ist könnt ihr loslegen. Eine bebilderte Schritt-für-Schritt-Anleitung, die selbst der letzte n00b verstehen sollte findet ihr hier.

Ich möchte gar nicht viel zum eigentlichen Einrichten sagen, da ich finde, dass das die Jungs vom CryptoCD-Team verdammt gut gelöst haben.

Zur Benutzung möchte ich euch allerdings einige Hinweise an die Hand geben.

Stellt euch die Technik vor, als würdet ihr jedem, der euch eine Nachricht schicken möchte, einen Stapel Stahlkisten zuschicken. Jede dieser Stahlkisten hat ein Schloss, das nur mit einem bestimmten Schlüssel zu öffnen ist. Diesen Schlüssel habt ihr allein. Wenn ein Freund euch jetzt eine Nachricht schicken will, nimmt er eine dieser Stahlkisten von seinem Stapel und steckt die Nachricht hinein. Dann schlägt er die Tür zu. Ab jetzt kann die Kiste nur noch mit dem richtigen Schlüssel geöffnet werden. Jetzt setzt sich der Bote ans Steuer seines LKW und fährt die Kiste zu euch. Ihr macht die Kiste auf und  siehe da – die Nachricht hat euch erreicht, ohne, dass jemand anderes sie lesen oder verändern konnte. Und damit ihr sicher sein könnt, dass die Nachricht auch von eurem Freund kommt, hat der sie unterschrieben und sein Siegel auf der Nachricht hinterlassen. Für die Antwort nehmt ihr eine Stahlkiste vom Stapel, den er euch geschickt hat und los gehts.

Prinzip klar? Wunderbar.

Dann noch einige Sicherheitshinweise:

1. Erstellt ein Backup eures geheimen Schlüssels an einem sicheren Ort. Wenn der Schlüssel verloren geht könnt ihr alle damit verschlüsselten E-Mails abschreiben.

2. Gebt den Schlüssel nicht aus der Hand. Jeder, der Zugriff auf den Schlüssel hat, kann in eurem Namen E-Mails verschicken. Und eure E-Mails lesen.

3. Unterstützt das Web of Trust der GPG-Nutzer und geht zu Keysigning-Partys oder veranstaltet selbst welche. Wenn ihr Hilfe braucht meldet euch bei mir.

4. Verschlüsselt so viele Nachrichten wie möglich und helft so, den Umschlag als Standard zu etablieren und die Postkarte zur Ausnahme zu machen.

Falls noch Fragen offen sind meldet euch in den Kommentaren.

Anmerkung: Das Bild zeigt eine graphische Darstellung meines GPG-Web-of-Trust. Erstellt wurde die Darstellung mit sig2dot und springgraph, vielen Dank an Darxus für diese epischen Tools!

Mit dem Einverständnis von Aaron Spettl kopiere ich das HowTo nach hier. Redundanz schadet nie.

Die einzige Anpassung, die ich vornehme, ist das Dateisystem von ext2 auf ext4 zu aktualisieren.

Ziel:

Ein verschlüsselter Container, den man bei Bedarf in das Dateisystem einbindet. Dies soll ohne Neukompilieren des Kernels funktionieren und keine besonderen Pakete benötigen – sowie in meinem Fall auch unter Debian Testing lauffähig sein.

Pakete:

Wir installieren cryptsetup und loop-aes-utils.

1. Erstellen der Containerdatei

An einem beliebigen Ort legen wir die Datei an, die unsere Daten speichern soll – hier 10 GB groß (mit Zufallsdaten gefüllt):

dd if=/dev/urandom of=/home/user/daten.safe bs=1M count=10240

2. Loop-Device

Als root legen wir ein Device an, das einfach auf diese Datei verweist:

losetup /dev/loop0 /home/user/daten.safe

3. Verschlüsselung einrichten

Wir richten nun die Verschlüsselung (Standard: AES mit 256 Bit) auf diesem Device ein – dabei muss das Kennwort angegeben werden:

cryptsetup -y create datensafe /dev/loop0

4. Formatierung

Der Container ist nun im System unverschlüsselt unter /dev/mapper/datensafe vorhanden. Nun richten wir das Dateisystem ein (hier ext4):

mkfs.ext4 /dev/mapper/datensafe

5. Mount

Nach der Formatierung können wir das Device unter einem beliebigen Verzeichnis einhängen (das existieren muss):

mount -t ext4 /dev/mapper/datensafe /mnt/datensafe

Nun kann man auf /mnt/datensafe ganz normal arbeiten, also speziell auch Zugriffsberechtigungen (restriktiv) setzen.

6. Aushängen

umount funktioniert ganz normal, danach noch den Container schließen und das Loopdevice freigeben:

umount /mnt/datensafe/
cryptsetup remove datensafe
losetup -d /dev/loop0

Tipp: Automatisierung mit sudo

Der mount/umount-Prozess inklusive Öffnen/Schließen des Loopdevices und des Containers kann man in ein Skript packen (und auf einem Ubuntu-System dem User mit sudo die Rechte dafür geben).

1
2
3
4
5
6
7
8
9
10
11
12

#!/bin/sh
# datensafe_mount.sh
 
LOOPDEV=/dev/loop0
SAFE=/home/user/datensafe
CRYPTNAME=datensafe
MNT=/mnt/datensafe
FS=ext4
 
/sbin/losetup $LOOPDEV $SAFE
/sbin/cryptsetup create $CRYPTNAME $LOOPDEV
/bin/mount -t $FS /dev/mapper/$CRYPTNAME $MNT

und

1
2
3
4
5
6
7
8
9
10
11

#!/bin/sh
# datensafe_umount.sh
 
LOOPDEV=/dev/loop0
SAFE=/home/user/datensafe
CRYPTNAME=datensafe
MNT=/mnt/datensafe
 
/bin/umount $MNT
/sbin/cryptsetup remove $CRYPTNAME
/sbin/losetup -d $LOOPDEV

Man startet die Installation, hangelt sich durch bis zum Partitionsmenü und stellt dann auf “Geführt, verwende vollständige Festplatte mit verschlüsseltem LVM” um. Danach folgt man den Anweisungen weiter, installiert das Grundsystem und fertig ist der Lack.

Zu einfach?

Richtig.

Für den Standardfall “eine Festplatte im Rechner verbaut und der Rechner ist ein Linux-Only-Gerät” reicht diese Vorgehensweise aus, man muss sich also dank der grandiosen Vorarbeit der Debian-Developers nicht mal mehr groß Gedanken darum machen.

Wenn man jetzt allerdings mehr als eine Platte hat und diese auch alle nutzen möchte, sieht das Ganze schon etwas schwieriger aus.

Dazu folgt man ebenfalls dem Standard-Installations-Menü bis zur Partitionierung und wählt dann “Manuell” aus.

Je nach Einsatzzweck ist zunächst das Software-RAID zu konfigurieren. Wenn man die Festplatten nicht redundant genutzt werden sollen sondern sämtlicher Speicherplatz ausgenutzt wird kann man sich das RAID sparen.

Dann konfiguriert man den LVM. Dabei steht LVM für Logical Volume Manager, der Link geht dabei zum sehr gut recherchierten und aufbereiteten Wikieintrag bei den Ubuntuusers. Das dort hinterlegte Wissen ist von hier ab als gegeben angenommen. Ich empfehle, alle nicht benutzten Partitionen zu einer LVG (Logical Volume Group), im Folgenden als lvg bezeichnet, zusammenzufassen und dort dann die Volumes anzulegen. Die wichtigen Volumes sind:

- lvg-boot, ca. 200MB bis 1GB, abhängig davon, wie viel Platz man zur Verfügung hat. Ich lasse bei meinen Systemen immer gern Luft nach oben, um für eventuelle Erweiterungen des Codes gerüstet zu sein.
- lvg-swap, sollte ca. doppelt so groß sein wie der Arbeitsspeicher.
- lvg-main, kann der verbleibende Rest des Speicherplatzes sein, falls keine separate /home-Partition angelegt werden soll. Hier finden wir später die /-Partition wieder.
- ggf. lvg-home, falls eine eigene /home-Partition angelegt wird.

Wenn die Volumes angelegt sind wird im Partitionsmenü der Punkt “Verschlüsselte Datenträger konfigurieren” aufgerufen. Hierbei werden alle Volumes außer lvg-boot ausgewählt. Die boot-Partition darf natürlich nicht verschlüsselt werden, sonst bekommt man eine hässliche Fehlermeldung und kann von vorn anfangen.

Die Installationsroutine geht jetzt ein Volume nach dem anderen durch und lässt die Einstellungen abnicken, mit denen die Verschlüsselung eingeleitet wird.

Achtung: Ubuntu setzt hier mehr auf Geschwindigkeit als auf Sicherheit und schlägt vor, die Daten auf den Platten nicht zu löschen. DAVON RATE ICH STRIKT AB! Wenn man größtmögliche Sicherheit haben will, lässt man die Daten überschreiben. Mehrfach. Dazu muss allerdings bei Ubuntu in besagtem Einstellungsmenü ausgewählt werden, dass man die Daten löschen möchte. Das passiert dann automatisch, kann allerdings abhängig von der Partitionsgröße und der Rechenpower eine Weile dauern.

Wenn man die Verschlüsselungs-Einstellungen hinter sich hat landet man wieder im Partitionsmenü. Hier werden jetzt die angelegten Volumes ausgewählt und mit Dateisystemen und Mountpoints versehen. lvg-boot bekommt ein ext3-Dateisystem und wird auf /boot eingehängt, lvg-swap_crypt wird als Auslagerungsspeicher verwendet, dadurch fällt der Mountpoint weg und lvg-main_crypt bekommt ein ext4-Dateisystem und wird auf / eingehängt.

Jetzt werden die Änderungen gespeichert und die Installation fortgesetzt. Ab hier läuft wieder alles nach Standard-Vorgehensweise und die Installationsroutine tut ihre Arbeit.

Wem das jetzt immer noch zu einfach war, dem lege ich diese Anleitung zur Installation eines verschlüsselten Linux Mint Debian Edition (LMDE) ans Herz.

Auch die exzellenten Artikel des Linux-Magazins bzw. des Linux-Users kann ich dazu sehr empfehlen, die Heftnummern reiche ich auf Wunsch gern nach.

Die Verzögerung begründet sich in einer längeren Geschichte, in der unter anderem ein widerspenstiger Eee-PC, ein Campingurlaub und ein kaputter USB-Stick eine Rolle spielen. Dazu vielleicht in einem anderen Blogeintrag mehr.

Zunächst ist es wichtig, zwischen der Vollverschlüsselung (Full Disk Encryption, FDE) und einem so genannten Container zu unterscheiden.

Bei der Vollverschlüsselung wird, wie schon der Name sagt, die komplette Festplatte (bis auf die boot-Partition) verschlüsselt. Bei einem Container wird ein einzelner Ordner (oder auch eine ganze Partition, z.B. /home) verschlüsselt.

Die Container-Lösung ist immer dann sinnvoll, wenn man Daten möglichst sicher über ein unsicheres Medium transferieren will. Man erstellt einen Container, legt seine Daten dort ab und kopiert den Container in seinen Webspace, von wo aus zwar jeder die Daten herunterladen kann, aber nur diejenigen auch etwas damit anfangen können, die das Passwort dazu haben. Wichtig dabei ist: Wenn man Dateien in einen Container legt, kann es immer noch sein, dass Teile davon im Swap-Bereich verbleiben, wo sie dann von einem Angreifer gefunden werden könnten. Das heißt, dass Container per se weniger sicher sind als die FDE. Dennoch haben sie, wie oben bereits angeführt, ihre Berechtigung.

Auf der sicheren Seite, wenn es darum geht, seine eigenen Daten vor Unbefugten zu schützen ist man, wenn man sein System vollverschlüsselt.

ACHTUNG: Auch hier gilt, wie bei allen anderen Sicherheitssystemen auch: Sobald ein physischer Zugriff auf das System möglich ist, kann die Sicherheit nicht mehr gewährleistet werden. Wie man an diesem Beispiel sieht, muss man davon ausgehen, dass jeder Fremdzugriff das System kompromittiert. Mit einer FDE wäre der Geschäftsmann vermutlich besser gefahren, hätte sich aber im Zweifel nicht schützen können. Dennoch, so lange man es nicht mit Sicherheitsbehörden zu tun hat, die überdurchschnittlich viel Zeit und Geld haben, ist eine Vollverschlüsselung sinnvoll.

Der guten Ordnung halber trenne ich den Artikel hier in die Anleitung für FDE und die Anleitung für Container.