tinc-VPN als sicheren Exit-Node

Guten Morgen,

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.

OK, ran an den Speck

Vorgestern habe ich es einfach mal wieder angepackt, und mich an die Debian-Installation auf meinem Desktop gewagt. Hier hatte ich noch den Gnome3-Desktop aktiv, und daran musste was geändert werden.

Debian-LogoVorgestern habe ich es einfach mal wieder angepackt, und mich an die Debian-Installation auf meinem Desktop gewagt. Hier hatte ich noch den Gnome3-Desktop aktiv, und daran musste was geändert werden.

Zunächst mal hatte ich da nen Haufen Updates einzuspielen, da ich Wheezy seit Mitte November nicht mehr gebootet habe. Und dabei bekam ich nen Haufen Fehlermeldungen, die sich auf den Grafiktreiber bezogen. Das war auch die Hauptaufgabe, die ich in den letzten Tagen hatte. Der Nvidia-Treiber wollte nicht, am Ende lief nur ein Universaltreiber ohne 3D-Unterstützung.

Heute habe ich es denn endlich hinbekommen, den Treiber von der Nvidia-Webseite zu installieren. ich musste dafür letztlich noch den GCC-Compiler aktualisieren, und das ging nur händisch, sowie die Kernel-Sourcen neu installieren. Bei der Gelegenheit spielte ich gleich den Kernel in Version 3.1 ein. Nach einem Reboot mit dem neuen Kernel ließ sich der Nvidia-Treiber sauber installieren, und jetzt funktioniert er auch. Erstmalig unter einem 64-Bit-Linux, zumindest bei mir.

Zudem ersetzte ich Gnome3 durch KDE 4.6.5, welches aber scheinbar noch nicht komplett lokalisiert ist. Zumindest habe ich den Microblogging-Client Choqok komplett in englisch.

Mumble ist eingerichtet, und gleich wird mal getestet, ob das auch funzt: Um 20:00 Uhr ist Online-Stammtisch der AG Bauen und Verkehr in der Piratenpartei.

Multimiedia spielt schon mal meine MP3-Sammlung ab, und lässt mich die TV-Karte nutzen. Das ist doch schon mal was.

Aber jetzt habe ich erst mal keine Lust mehr, und mache wohl erst am Donnerstag weiter. Denn ab morgen habe ich Mittagschicht, da läuft zeitlich nicht allzu viel.

So viel also erst mal zum aktuellen Stand der Dinge…

So langsam muss es weiter gehen

Nach den letzten Querelen mit Debian und den Versuchen, auf KDE umzusteigen, habe ich auf meinem Netbook das damals mitgelieferte Windows XP laufen. Das ist sogar einigermaßen flott, aber ein Zustand, der mich nicht befriedigt.

Nach den letzten Querelen mit Debian und den Versuchen, auf KDE umzusteigen, habe ich auf meinem Netbook das damals mitgelieferte Windows XP laufen. Das ist sogar einigermaßen flott, aber ein Zustand, der mich nicht befriedigt. Und seit dem habe ich hier am Desktop die Debian-Installation gar nicht mehr gestartet, sondern nur noch unter dem parallel installierten Windows 7 gearbeitet. Läuft zwar einigermaßen problemlos, stellt mich aber auch nicht zufrieden. Insbesondere Firefox und Thunderbird frieren immer wieder für mehrere Minuten ein.

Wer mag mich mal in den Hintern treten, damit ich mein Debian endlich wieder in Gang setze? :blush:

Ich könnte kotzen…

Vorgestern Abend habe ich hier am PC Debian Testing installiert, und gestern nach Feierabend daran rumkonfiguriert und diverse Software nachinstalliert. Und heute läufts nicht mehr…

Debian-LogoVorgestern Abend habe ich hier am PC Debian Testing installiert, und gestern nach Feierabend daran rumkonfiguriert und diverse Software nachinstalliert. Und heute läufts nicht mehr…

Gestern Abend, bzw. in der Nacht wollte ich zum Abschluss noch ein wenig fernsehen, und dazu ist in meinem PC eine TV-Karte verbaut. Ich habe dann noch einiges an DVB-Software installiert, und habe dann einen Suchlauf gestartet. Die Abfragen kenne ich ja: Land = Deutschland, Region = Nordrhein-Westfalen, und los geht der Scan. Resultat: Keine Programme gefunden. Die TV-Karte wird aber schon korrekt erkannt… :denk:

Ich versuchte es 3 oder 4 mal, dann habe ich wegen Müdigkeit abgebrochen, und die Kiste neu gestartet. In der parallel installierten WinDOSe funktioniert die TV-Karte nämlich. (Unter Linux hatte ich sie auch bereits laufen!)

Als ich dann heute früh wieder Debian booten wollte, kam mir die Konsole schon merkwürdig vor: Während sonst nach den ersten paar Zeilen Text auf die zum 24-Zöller passende Auflösung gewechselt wird, blieb es jetzt bei 640 x 480 px. Und zum Ende des Bootvorgangs kam dann die Fehlermeldung, dass der X-Server nicht gestartet werden konnte, no screen found…

Wat soll dat dann schon widda! :motz: Noch nich richtig wach, und dann sone Scheiße. Sorry, ich will nicht mehr. Ich sehe mich schon wieder die nächsten Wochen hier an der WinDOSe hocken, weil mir im Moment schon wieder die Lust auf Linux im Allgemeinen und Debian im Besonderen vergeht… :surrender:

Aktuell bin ich dermaßen blockiert, dass mir noch nicht mal mehr Lösungsansätze einfallen wollen. Und neu installieren will ich nicht, ist doch schließlich keine WinDOSe… :denk:

Brauch ich den Schrott hier noch?

Heute habe ich für euch einen (oder genauer 2) Tipps, wie man sich einen Teil seiner Festplattenkapazität zurückholt.
Vielleicht kennt der eine oder andere die Situation, dass man zufälligerweise mal mit

$ls -a

den Inhalt seines home-Ordner anschaut und sich dabei denkt „Woher zum Teufel kommt dieser ganze Mist eigentlich?“

Nun, die Dateien mit einem Punkt vornedran (z.B. .nautilus) sind Konfigurationsdateien, die eure persönlichen Einstellungen speichern. Wenn ihr ein Programm deinstalliert, bleiben diese Konfigurationsdateien in der Regel erhalten. Das soll euch den Wiedereinstieg erleichtern, falls ihr das Programm doch wieder nutzen wollt.

Prinzipiell keine schlechte Idee – aber wenn man sich sicher ist, dass man ein bestimmtes Programm nicht mehr nutzen will, dann nervt das gewaltig. Erstens verbraucht es Speicherplatz und zweitens, viel wichtiger, sorgt es dafür, dass die Inhaltsanzeige des home-Ordners unübersichtlich wird und man nichts mehr findet.

Wenn man nun diese Konfigurationsdateien löschen will, kann man permanent von Hand

$ls -a
$rm -rf $Dateiname

eintippen. Oder man nutzt die Möglichkeiten, die einem die Linux-Bordmittel bieten. Zuerst erstellt man sich eine Liste, der gesammelten Konfigurationsdateien:

$ls -a > filelist

eine Liste aller im Ordner home enthaltenen Dateien. Achtung: Hierbei werden wirklich

    alle

Dateien angezeigt.

Diese Liste editiert ihr jetzt mit Hilfe von vi, gedit, nano, joe oder welchem Editor auch immer und löscht alle Verzeichnisse und Dateien, die ihr behalten möchtet.

Die neue Liste speichert ihr wieder ab.

Jetzt ruft ihr das Programm rm auf und übergebt ihm die Liste filelist als Input.

$cat filelist | xargs rm

Und schon hat euer home-Verzeichnis wieder ein paar Bytes mehr frei.

Ein ähnliches Vorgehen kann man auch beim Thema installierte Programme wählen. Hierbei lauten die Codes

#dpkg -l > proglist

und

#cat proglist2 | xargs apt-get remove --purge

Das

>

steht dabei für >

Achtung: Das file proglist ist absichtlich in einem von apt nicht lesbaren Format belassen worden. Dies habe ich mir selbst als Sicherheitsmaßnahme auferlegt um zu vermeiden, dass ich im Eifer des Gefechts versehentlich eine unbearbeitete Liste von Paketen zum Löschen vormerke.

Wenn jemand einen Tipp hat, wie man automatisiert aus proglist eine direkt nutzbare Paketliste generiert (sed, awk, whatever) und dabei eine Sicherungsmaßnahme einbaut dann postet den Tipp bitte in den Kommentaren. Danke.

Das file proglist2 ist die von Hand erstellte Liste der nicht mehr benutzten Pakete.

Debian Testing (Wheezy)

Nachdem ich letztens Aptosid installiert habe, konnte mich das nicht überzeugen. Der Nachfolger des von mir gerne genutzen, aber leider nicht mehr verfügbarem Sidux kann da einfach nicht mithalten…

Debian-LogoNachdem ich letztens Aptosid installiert habe, konnte mich das nicht überzeugen. Der Nachfolger des von mir gerne genutzen, aber leider nicht mehr verfügbarem Sidux kann da einfach nicht mithalten…

Auf die Gründe mag ich jetzt nicht weiter eingehen, aber meine Entscheidung für die auf Debian Unstable (Sid) basierende Distribution entsprang dem Wunsch nach aktueller, aber stabil laufender Software. Bei Sidux hat das auch noch ganz gut geklappt, bei Aptosid leider nicht mehr. Wobei auch Sidux mit KDE4 unbenutzbar wurde… O.o

Der stabile Zweig von Debian, aktuell in Version 6 mit dem Namen Squeeze, setzt der Distributions-Politik folgend auf nicht mehr ganz so aktuelle, dafür aber stabile Software. Als Updates gibts da eigentlich nur Sicherheits-Patches, neue Versionen mit neuen Features kommen erst mit der nächsten Version der Distribution.

Immer die aktuellste Software gibts in der Unstable-Version, die immer auf den Codenamen Sid hört. Hier können auch gerne Beta-Versionen der einzelnen Pakete vorkommen, Stabilität ist nicht garantiert, und somit scheidet die Sid für Produktiv-Systeme aus.

Sidux und Aptosid bringen Erweiterungen für diese Version mit, die eine gewisse Stabilität mitbringen. Was bei Sidux auch recht gut gelungen ist, klappte bei Aptosid wie gesagt nicht mehr überzeugend. Zudem gab es beinahe täglich mehrere 100 MB an Updates zu laden.

Einen Kompromiss zwischen Stable und Unstable ist dann eben Testing. Wenn die aktuelle Testing-Version in den Stable-Status wechselt, wird in Sid ein Freeze gemacht, und die neue Testing-Version ist da. Das heißt: Aktuelle Versionen der Software, wenn auch nicht die neuesten, und immer weiter wachsende Stabilität. Später wird das mal die Version 7 von Stable, und hört aktuell auf den Namen Wheezy. Auch hier gibt es nur noch Updates, die eben dieser Stabilität, oder aber der Sicherheit dienen. Gnome 3 z.B. ist für Testing nicht zu haben, dafür müsste man Unstable-Quellen einbinden

Und genau diesen Kompromiss habe ich nun zumindest am Netbook installiert. Trotz des per default verwendeten Gnome-Desktop (den mag ich eigentlich nicht) gefällt mir das bisher recht gut. Immerhin kommt hier mein Lieblings-Twitterclient TweetDeck zum Laufen, unter Aptosid hat der immer über ein fehlerhaft installiertes Adobe Air gemeckert. O.o

Auch hardwaremäßig klappt es hier deutlich besser: WLAN lief auch bei Aptosid, der UMTS-Stick mochte aber nicht. Vielleicht hab ich auch an den falschen Schrauben gedreht, jedenfalls konnte ich mit dem Stick keine Internet-Verbindung aufbauen. Jetzt, bei Wheezy, habe ich keine Probleme damit. Stick anstöpseln, im Netzwerk-Manager eine neue Verbindung vom Typ „Mobiles Breitband” einrichten, Provider auswählen und ggf. Zugangsdaten eingeben, fertig.

Ich werde jetzt wohl noch ein paar Tage brauchen, bis das System komplett und nach meinen Wünschen eingerichtet ist. Zudem weiß ich noch nicht, ob ich mich an Gnome gewöhnen kann, oder ob ich KDE noch nachinstalliere. Zudem habe ich die Hoffnung, dass Gnome 3 noch zur Verfügung gestellt wird. Das soll ja nochmal ganz anders sein, aber die Bilder von Schrottie gefallen mir.

Zudem hab ich die 64Bit-Version zur Installation am Desktop bereits heruntergeladen, und einen USB-Stick damit bootfähig ausgestattet. Da wartet dann also die nächste Baustelle auf mich…

Kommunikationsverschlüsselung: GPG

Heute schreibe ich über E-Mails, deren latente Unsicherheit und wie man daraus noch etwas ordentliches macht.

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!

Aptosid installiert

Ich habe eben sowohl am PC, als auch am Netbook die Kubuntu-Installation durch Aptosid ersetzt. Aptosid ist der Nachfolger von Sidux, und baut ebenso auf Debian Sid auf. Also habe ich hier immer die aktuellste Software.

Aptosid-LogoIch habe eben sowohl am PC, als auch am Netbook die Kubuntu-Installation durch Aptosid ersetzt. Aptosid ist der Nachfolger von Sidux, und baut ebenso auf Debian Sid auf. Also habe ich hier immer die aktuellste Software.

Wenn ich das vernünftig zum Laufen bekomme, wird auf beiden Maschinen die parallel installierte Windows 7 Version verschwinden, und zumindest am Netbook gibts dann auch ne Neuinstallation mit verschlüsselten Laufwerken. So wie Dave es hier im Blog beschreibt.

Anyway, ich werde meine Erfahrungen hier posten. WLAN am Eee-PC läuft schon mal problemlos, auch wenn ich die Einrichtung erst suchen musste…

Verschlüsselte Container

Da ich ein wunderbares HowTo gefunden habe muss ich zum Vorgehen keine weiteren Ausführungen machen, denke ich. Falls jemand Fragen hat sollten sie hier in den Kommentaren gepostet werden.

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

Full-Disk-Encryption

Zu einer FDE kommt man heute mit jedem handelsüblichen Debian oder *buntu-System auf denkbar einfache Weise. Ich gehe davon aus, dass das auch bei den meisten anderen Standard-Distros so ist, kann das aber weder verifizieren noch falsifizieren.

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.