go-linux.info

 Start

1. Überblick
 Was ist Linux?
 Programme
 Security
 Root
 Dienste konfigurieren
 Paketfilter
 Encryption
 kmail+gnupg

2. Arbeiten mit Linux
 Einleitung
 Grundlagen
 Berechtigungskonzept
 Textbearbeitung
 Was ist eine Shell?
 Prozesse / Jobs

3. Anwendungen Shell
 Einleitung
 Die Kommandozeile
 Systemverwaltung
 Netzwerk
 Dateien
 Multimedia

4. Look and Feel
 Einleitung
 Windowmanager
 Desktop Environments


Start arrow Security arrow Encryption
Encryption   PDF  Drucken 
Warum Verschlüsselung?

Oft hört man, "Wozu verschlüsseln? Ich habe nichts zu verbergen." Ungeachtet dessen, daß diese Aussage auch politisch-gesellschaftlich gesehen kurzsichtig und naiv ist, gehen wir im folgenden rein auf die technische Notwendigkeit der Verschlüsselung ein.

Es sollte jedem klar sein, daß es nicht wünschenswert ist, einen telnet- oder ftp-Zugang mit parasitären Nutzern zu teilen, die das im Klartext übermittelte Paßwort mitgehört haben, und nun diesen Zugang für andere Zwecke nutzen können und werden.

Aber wie übermittelt man überhaupt Paßworte? Auf einem Zettel im Schulhof? Murmelnd, aneinander vorbeigehend? Und wie kommuniziert man anschließend? An toten Briefkästen? Durch heimlich ausgetauschte Zeitungen?

Allen Agentenfilmen zum Trotz gibt es dafür ein festes Prozedere: 1. man verschaffe sich einen gesicherten Kommunikationsweg (gpg), 2. man verschaffe sich einen gesicherten Weg des Datentransfers und gegebenenfalls der Fernadministration (sftp/ssh), und 3. man verschaffe sich auch lokal 'a place of utter privacy' (mountloop). Alle diese Maßnahmen greifen letztendlich ineinander. Im folgenden wird beschrieben, wie diese Maßnahmen unter Linux einzurichten sind.

Kommunikation (E-mail)

Benötigte oder empfohlene Pakete:
  • gpg
  • kgpg
  • kmail

Hier kann ich mich kurz fassen, denn Gregor Waluga hat bereits eine ausgezeichnete und vor allem sehr ausführliche (13 Seiten) Anleitung für kmail <1.7 ins Netz gestellt. Man findet sie im Bereich Tutorials/HowTos seiner Seite http://linux.waluga.de. (Anwender von kmail 1.7 schauen unter "Anleitung kmail 1.7 und gnugp".) Zum Verständnis des folgenden ist sie sehr zu empfehlen, da sie auch die Hintergründe der Public Key Kryptography anreißt.

Für Ungeduldige...Für diejenigen, denen 13 Seiten zu lang sind, hier eine Kurzanleitung.
Zum Verständnis des folgenden ist sie sehr zu empfehlen, da sie auch die Hintergründe der Public Key Kryptography anreißt. Anwender von kmail 1.7 schauen bitte unter der oben erwähnten Anleitung nach.

Man installiere gpg, kgpg, und natürlich kmail (und damit schlußendlich kde, wobei die ganze Geschichte natürlich auch unter Gnome oder einem x-beliebigen Windowmanager läuft, sofern man eben die notwendigen kde-Libraries und -Anwendungen installiert hat).

Man starte kgpg und erzeuge als erstes ein Schlüsselpaar. Dem Default (DSA & El Gamal) ist zu trauen, aber man wähle auf jeden Fall die maximale Schlüssellänge (4096 bit). Man sollte ein nichtriviales Paßwort (Mantra) wählen, das man aber trotzdem behalten kann. Der public key kann dann sogleich mittels des "key server dialogs" auf einen Server hochgeladen (exportiert) werden. Im Gegenzug können die public keys von Freunden heruntergeladen (importiert) werden. Diese Schlüssel müssen mit dem eigenen privaten Schlüssel signiert werden, um verwendbar zu sein. Man achte aber zuerst auf die Problematik, ob die Keys der Freunde auch tatsächlich von diesen stammen. Archaische Medien wie das Telefon oder gar persönliche Treffen sind gute Mittel, die Authentizität eines Schlüssels zu bestätigen. Nein, das ist kein Wahnsinn und keine Paranoia: bei den heutig gängigen Schlüssellängen ist die verwundbarste Stelle der Erstaustausch.

Nun muß nur noch kmail konfiguriert werden. Das ist einfach: zunächst einmal macht man in Security/OpenPGP bekannt, daß man mit GnuPg zu arbeiten gedenkt. Hier kann man auch einstellen, ob alle Mails signiert oder gar verschlüsselt werden sollen...ersteres ist sicher zu bejahen, letzteres eher nicht. Dann wählt man unter Identities/Advanced den korrekten Schlüssel aus.

Und schon kann man signierte/verschlüsselte Emails verschicken. Kmail hat dafür übrigens Icons in der Toolbar, also kann man das ganz einfach und nach Belieben ein- und ausschalten.

Datenadministration und -transfer (SSH/SFTP)

Benötigte oder empfohlene Pakete:
  • openssh
  • rssh (incl. mkchroot.sh aus dem Quellcode)

Voller SSH-Zugang (Public Key Authentification)

Secure shell (ssh) ist ein Programm, das es gestattet, sich auf einem ssh-Server einzuloggen und auf diesem Kommandos auszuführen. Um das zu illustrieren, ein Beispiel für einen Einsatz dieses Programms:

Man nehme an, man studiere an einer Universität (arbeite in einer Firma), die über jeglichen Browser vollen Zugriff auf die Datenbank www.datenbank.com hat. Dieser Zugriff ist an die IP der Universität (Firma) gekoppelt, und funktioniert daher daheim natürlich nicht. Loggt man sich aber per shh auf einem ssh-Server der Universität (Firma) ein, und startet dann in einer xterm-kompatiblen Konsole z.~B. Mozilla, hat man ebenfalls vollen Zugriff.

Ferner bietet ssh die Möglichkeit des secure file transfers (scp bzw. sftp).

Eine ähnliche Funktionalität bieten rlogin, telnet, und ftp, die allerdings sicherheitstechnisch mehr als bedenklich sind, da der Datenverkehr (incl. der Passworte) im Klartext abgewickelt wird. Im Gegensatz dazu verschlüsselt ssh den gesamten Datenverkehr und erlaubt überdies die weitaus sicherere, paßwortlose Authentifizierung über Public Keys.

Die Einrichtung eines ssh-Servers und eines ssh-Clients sind unter Linux schnell erledigt. In beiden Fällen sollte man sich das openssh-Paket installieren, eine freie Implementation von ssh. Auf dem Client sollte weiterhin openssh-askpass sowie openssh-clients installiert werden, der Server braucht überdies openssh-server.

Beim Server läuft nun bereits der ssh-Daemon (sshd), der auf Verbindungen von außerhalb wartet. Überprüfen kann man dies mit dem Kommando sshd status, starten und stoppen kann man diesen Dienst mittels ssh start bzw. sshd stop. Vorher sollte man allerdings noch die /etc/ssh/sshd.config bearbeiten, damit die Möglichkeiten von ssh auch wirklich ausgeschöpft werden:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

sind die drei Optionen, die größtmögliche Sicherheit gewährleisten.

Wichtig für den nachstehenden Punkt:

Subsystem  sftp	 /usr/lib/ssh/sftp-server

sollte unkommentiert sein, damit das secure file transfer protocol (sftp) funktioniert.

Wünscht man auch Übertragung von Inhalten, die nur unter X laufen (wie mozilla in unserem obigen Beispiel), kommentiert man folgendes aus:

X11Forwarding yes

Clientseitig muß nun noch etwas getan werden, um Verbindung zu unserem Server aufzunehmen. Zunächst muß durch das Programm ssh-keygen ein Schlüsselpaar erzeugt werden. Ob RSA oder DSA ist bei Sicherheitsphilosophen umstritten, aber man wähle auf jeden Fall die größte verfügbare Schlüssellänge. Ein Paßwort für den Schlüssel ist nicht notwendig, erhöht aber die Sicherheit ungemein, sollte dieser doch einmal in falsche Hände fallen. Man beachte: das ist kein Serverpaßwort, sondern eines für den eigenen privaten Schlüssel.

Danach muß der public key an den Administrator des ssh-Servers geschickt werden, und zwar in einer Weise, die Kompromittierung ausschließt. Praktikabel ist hier eine signierte Mail, wie oben beschrieben. Alternativ kann man sich auch persönlich treffen...

Der Administrator verschiebt diesen public key nun in /home/karl/.ssh (falls des Users Login karl ist), und fügt ihn mit less id.dsa.pub >> authorized_keys der Liste der authorisierten Schlüssel zu.

Damit sollte dem vollen ssh-Genuß nichts mehr im Wege stehen.

Eingeschränkter Zugang: SFTP im Chroot-Jail (Public Key Authentification)

Will man allerdings keinen vollen Zugriff auf den Server per ssh gewähren, und seine Clients sowohl in der Auswahl der ausführbaren Programme als auch im Bewegungsspielraum innerhalb des Verzeichnisbaums des Servers einschränken, bietet sich die "restricted secure shell" (rssh) an.

Zunächst installiere man sich die neuste Version von rssh (momentan 2.2.1). Alle User, die auf den Server zugreifen, bekommen nun in /etc/passwd statt der bash die rssh als Defaultshell zugewiesen.

In /etc/rssh.conf läßt sich dann konfigurieren, welche Dienste erhältlich sein sollen. Zur Auswahl stehen stfp, scp, rsync, cvs, und andere mehr.

Zum Beispiel also:

allowscp
allowsftp

Nun können User nur noch die ihnen zugedachten Programme ausführen. Allerdings gelingt es ihnen z.B. mit sftp immer noch, verzeichnisübergreifend auf Dateien lesend zuzugreifen. Will man das verhindern, muß man diese User in ein "chroot-jail" sperren.

Auch hierfür gibt es eine einfache Lösung: im Quellcode von rssh http://www.pizzashack.org/rssh findet man das Shellscript mkchroot.sh. Man passe in diesem Script die Pfade an (man beachte insbesondere den von rssh.chroot.helper), und führe es anschließend im Pfad des betreffenden Users mit folgenden Angaben als root aus: ./mkchroot.sh /home/karl/ karl 555. /home/karl ist hier das neue Rootdirectory, karl sein Inhaber, und 555 die dort vergebenen Rechte.

Anschließend muß man noch in /etc/rssh.conf die chroot-Umgebung für den betreffenden User einrichten, was anhand der dort angegeben zahlreichen Beispiele leicht fällt. Natürlich muß diese Umgebung (also das neue Rootdirectory sowie der User) mit den Angaben beim Aufruf von mkchroot.sh konsistent sein.

Also z.B.

user=karl:011:00011:"/home/karl"

was sowohl scp als auch sftp erlaubt.

Eine weitere Möglichkeit, einen "Käfig" zu realisieren, bietet Jail. Ist Jail installiert, kann es losgehen. Rootrechte holen, und

mkjailenv /var/chroot

legt die Chrootumgebung in /var/chroot mit /var/chroot/dev und /var/chroot/etc an. Der nächste Schritt beinhaltet das hinzufügen von Anwendungen, die der chrooted-User ausführen/benutzen darf. Mit

addjailsw /var/chroot

fügt man ein ganzes Paket mit Anwendungen (u.a. mv, ls, grep, cat, cp, more, touch) hinzu. Möchte man dies nicht, besteht auch die Möglichkeit, nur einzelne Anwendungen der Chrootumgebung hinzuzufügen.

addjailsw /var/chroot -P nano

würde z.B. nur den Texteditor nano der Umgebung hinzufügen. So ist eine individuelle Zusammenstellung von Software für den User möglich.

Diesen User (im folgenden Beispiel anna genannt) müssen wir als nächstes im Hauptsystem anlegen. Dies kann händisch über das editieren der /etc/passwd und manuellem anlegen von /home/anna geschehen oder mittels

useradd anna -m -G users -s /usr/bin/jail

Als Shell muss hier zwingend jail vergeben werden. Der Pfad kann von Distribution zu Distribution verschieden sein. Eine Anpassung in der /etc/passwd ist allerdings dennoch nötig. Wir ändern in der Zeile

anna:x:1001:100::/home/anna:/usr/bin/jail

das Homeverzeichnis in

anna:x:1001:100::/var/chroot:/usr/bin/jail

und speichern ab. Der User anna muß natürlich auch in der Chrootumgebung vorhanden sein.

addjailuser /var/chroot /home/anna /bin/bash anna

übernimmt das für den User anna und vergibt in diesem Fall die Shell Bash. Es ist darauf zu achten, daß die vergebene Shell auch in der Chrootumgebung installiert sein muß. Über

su - anna

sollten wir uns als User anna nun in der Chrootumgebung befinden. Ist der Test erfolgreich, legen wir in /var/chroot den Ordner .ssh an. Darin wird, wie oben beschrieben, die Datei authorized_keys mit den trusted-PublicKeys der entsprechenden User angelegt. Dem Login mittels ssh über PublicKey-Authentication in einem sicheren Anwender-"Käfig" steht nun nichts mehr im Wege.

Datensicherung (Encrypted Container)

Benötigte oder empfohlene Pakete:
  • mountloop (incl. drakloop)
  • mount
  • losetup

Ein verschlüsselter Container ist eine ausgezeichnete Möglichkeit, sensitive Daten (wie Paßworte) vor neugierigen Augen zu sichern. Zur Einrichtung muß man zunächst in jedem Fall die oben erwähnten Pakete installieren bzw. auf den neusten Stand bringen. Die Erzeugung eines 512~MB großen Containers geschieht dann folgendermaßen (der Name des Users ist karl, der des Containers ist container, die Punkte (dots) weisen darauf hin, daß das Kommando in der nächsten Zeile weitergeht):

modprobe aes
modprobe cryptoloop
dd if=/dev/zero of=/home/karl/...
container/encfile bs=1024 count=524288

losetup -e aes256 /dev/loop1 ...
/home/karl/container/encfile
Password:

chown 0 /dev/loop1
mkfs -t ext2 /dev/loop1
losetup -d /dev/loop1

mount -o loop=/dev/loop1,encrypted,...
encryption=aes256 -p 0 /home/karl...
/container/encfile /home/karl/container

Unter Mandriva (Mandrake) genügt übrigens das Ausführen von drakloop als root, sowie die Eingabe der Parameter in der sich darauf öffnenden Maske, um einen verschlüsselten Container zu erzeugen und zu mounten. Analog zu oben wäre also einzugeben: /home/karl/container, die gewünschte Größe (512~Mb), das Paßwort, und der Verschüsselungsalgorithmus (aes256).

Danach kopiere man den in /etc/mtab gefundenen Befehl in /etc/fstab, und füge users, noauto hinzu, damit nicht nur root den Container mounten kann, sondern auch der gemeine User karl, und damit dies nicht automatisch während des Bootens geschieht, sondern erst auf Anfrage. Schließlich füge man noch in /etc/modprobe.preload die Befehle aes und cryptoloop dazu, und reboote.

Danach sollte ein mount container genügen, um die Paßwortabfrage zu initiieren. Falls es Fehlermeldungen gibt, versuche man ein modprobe aes und modprobe cryptoloop.

Datensicherung 2 (Encrypted Partition)

Für alle Mandrivauser die gern mittels GUI arbeiten hier ein kleines HowTo wie mit Diskdrake eine verschlüsselte Partition angelegt wird.

Vorraussetzung:
  • freier Festplattenplatz
  • gewünschter Verschlüsselungalgorithmus liegt als Modul vor oder ist fest in den Kernel einkompiliert
  • Devices Loop und Cryptoloop liegen als Modul vor oder sind fest in den Kernel einkompiliert

Diskdrake über das MCC (Mandriva Control Center) oder per Kommando "diskdrake" als Root in der Shell starten.

In den "Expertenmodus" wechseln. Eine neue Partition "Erzeugen" mit gewünschter Größe, Dateisystem und Name des "Einhängepunktes" (Mountpoint). Mit "OK" bestätigen.


( Zum Vergrössern Bild anklicken... )


"Optionen" auswählen, "encrypted" markieren, darauf folgend Passphrase festlegen und bestätigen, Verschlüsselungsalgorithmus auswählen. Beides anschließend mit "OK" bestätigen.


( Zum Vergrössern Bild anklicken... )

"Formatieren" auswählen und die Abfrage mit "OK" bestätigen.



( Zum Vergrössern Bild anklicken... )

Anschließend mit "Fertig" das Anlegen der Partition abschliessen. Abfrage nach Änderung der "/etc/fstab" mit "OK" bestätigen.



( Zum Vergrössern Bild anklicken... )

Daraufhin ist in "/etc/fstab" folgender Eintrag zu finden

/dev/hdb9 /Enc ext3 encryption=AES256,encrypted 0 0

Device, Einhängepunkt, Verschlüsselung beziehen sich hier auf das durchgeführte Beispiel.

Nach Reboot wird beim Einhängen aller Partitionen gefragt ob man die gefundenen verschlüsselten Partitionen "jetzt" einhängen möchte, wird dies bejaht kommt die Aufforderung die Passphrase einzugeben. Legt man mehrere verschlüsselte Partitionen an werden diese während des bootens nach Ihrer vorliegenden Reihenfolge in der /etc/fstab abgefragt. Üblich ist diese Reihenfolge nach Bezeichnung des Mountpoints mit Großbuchstabe/Alphabet danach kleiner Buchstabe/Alphabet.

Möchte man die Partition nicht während des bootens starten, ist das spätere mounten im laufenden Betrieb mit

mount /Mountpoint

jederzeit möglich. Passphrase wird natürlich wieder abgefragt.

verwendetes System:
Kernel: 2.6.16.2 (Vanilla)
Distribution: Mandriva_2006

Fazit
  • Gesicherte Kommunikation ist das A und O der Privatsphäre. Mit einer solchen können....
  • ...Paßworte oder Schlüssel, z.B. für die Fernsteuerung per ssh, sicher und bequem übermittelt werden.
  • ...alle als sicher befundenen Paßworte und Schlüssel einen Platz im verschlüsselten Container finden. Damit schließt sich der Kreis.


 


Miro International Pty Ltd. ©2000 - 2003 All rights reserved.
Mambo Open Source is Free Software released under the GNU/GPL License.
Powered by Mambo Open Source