<!> Noch nicht Fertig!! Fehler und Anregungen können hier direkt editiert werden

Wie richtet man einen Laptop sicher ein?

Was soll geschützt werden:

  1. Diebstahl des Laptops und der darauf befindenden Daten
    1. Private Daten sollten verschlüsselt sein
    2. Selbst wenn der Laptop eingeschaltet geklaut wird, sollten die Daten hinreichend sicher sein
    3. Neuinstallation/Booten eines anderen Betriebsystemes soll verhindert (oder zumindest erschwert) werden
  2. Zugriffschutz
    1. Nur berechtige Benutzer dürfen den Laptop booten
    2. Wenn der Laptop unbeaufsichtigt stehen gelassen wird dürfen unberechtige Personen keinen Zugriff erlangen
    3. Die Installation/Der Bootvorgang sollte gegen Manipulationen geschützt sein (keylogger/trojaner)
  3. Feindliche Netze
    1. Der Laptop sollte vor Angriffen in fremden Netzen geschützt sein
    2. Es sollten nie unverschlüsselte vertrauliche Daten über fremde Netze geschickt werden

Leider werden wir im folgenden sehen das sich einige dieser Forderungen nur sehr schwierig oder gar nicht implementiernen lassen.

Inhalt

Sicheres Booten

Ich beschreibe hier in der Reihenfolge des Bootvorgangs, welche Vorkehrungen nötig sind um Debian GNU/Linux sicher zu starten. Es sollte äusserst sorgsam umgegangen werden, Schüssel und Passwörter sollten nie auf einer unverschlüsselten Partition landen (swapoff -a) und man muss vorsichtig sein, das man sich nicht selber aussperrt und damit seine Daten verliert oder nur mit grossen Aufwand wieder herstellen kann.

1. Bios

1.1. Passwörter

  1. Es ist ratsam das die Bios Einstellungen vor unberechtigter Änderung geschützt werden, allein damit niemand die folgenden Einstellungen ändern kann.
  2. Das setzen eines 'User'-passwords ist optional, der Nachteil ist, das man bei jedem boot hier schon mal ein Passwort eingeben muss, ohne das man allzuviel Sicherheitsgewinn hat.
  3. Festplatten Passwort, einige Festplatten und Bios'e erlauben es ein Passwort für die Festplatte anzugeben. Diese Passwort wird direkt auf der Festplatte gespeichert und die Firmware der Festplatte verhindert unberechtige Zugriffe. Der Vorteil ist, das man keinerlei Performanceverluste hat, die Festplatte is damit auch dann geschützt wenn jemand sie ausbaut und in einen anderen Rechner einbaut, demgegenüber steht, das man auch hier beim booten schon ein Passwort eingeben muss, ausserdem wird keinerlei Verschlüsselung angewandt, die Daten liegen immer noch auf der Platte und könnten von Datenrettungsunternehmen o.ä. gelesen werden. Aus diesen Gründen ist ein Passwort für die Festplatte optional. Daten sollten besser durch die hier beschriebenen Methoden geschützt werdem. Allerdings könnte ein Angreifer eine Festplatte ohne solch ein passwort unbenutzbar machen indem er ein solches Passwort setzt. Das sollte man gegebenenfalls mit einer entsprechenden hdparm config verhindern.

Bios'e behandeln diese Sachen manchmal verschieden, wenn hier Passwörter gesetzt werden, sollte man ihre Funktion unbedingt ausprobieren. Ausserdem ist es nicht ausgeschlossen das der Bios Hersteller ein Master Passwort fest eingebaut hat oder das man das Bios durch andere Möglichkeiten reseten kann. Ferner schützen die ersten beiden Bios Passwörter nicht dagegen, das jemand die Festplatte entfernt und in einem anderen Rechner analysiert.

1.2. Bootreihenfolge

Wenn alles fertig eingerichtet ist, wird das Bios so eingestellt, das nur von der eingebauten Festplatte gebootet werden kann. Falls man doch einmal von CD oder einem anderen Medium booten will wird diese option besser im grub menu mit passwortschutz hinzu gefügt (siehe unten). Alternativ kann man kurzzeitig das Bios anpassen, nur das rückgängigmachen nicht vergessen. Meist ist es trotzdem möglich das Bios zu resetten deshalb stellt dies keinen sicheren Schutz dar.

2. Grub

3. Festplatte verschlüsseln

Wir verschlüsseln nur das /var Filesystem und machen /home einen bind-mount nach /var/home, theoretisch könnt man auch das gesamte system mit Hilfe einer initrd Installation verschlüsseln oder die vorgestellten Methoden auch auf andere Partitionen anwenden. Da Verschlüsseln allerdings Performance kostet (und damit auch batteriezeit) lassen wir das. Vertrauliche Daten im /etc kann man bei bedarf per symlink in die verschlüsselte partition verlegen, für /etc/passwd stelle ich weiter unten noch eine bessere Möglichkeit vor. Pakete zu verschlüsseln, die im Verzeichnis /usr installiert sind, macht definitv wenig sinn. Wer will kann /usr/src und /usr/local noch auf die verschlüsselte partition binden oder symlinken.

Wichtig ist noch, das die swap-partition unbedingt verschlüsselt wird, andernfalls kann es passiern, das vertrauliche Daten in Klartext auf die swap-partition ausgelagert werden. Angriffe die genau dies auslösen sind relativ einfach durchzuführen. Alternativ bietet es sich bei Laptops mit ausreichend RAM (> 1GB) an gar keine swap partition zu verwenden und stattdessen einen swap-daemon zu konfigurieren der dynamisch swapfiles auf der schon verschlüsselten partition anlegt. Meiner Erfahrung nach ist das sogar wesentlich besser, da seltener auf die Platte zugegriffen wird und man den Plattenplatz besser ausnutzt.

3.1. Partitionen initialisieren

Bevor es jetzt losgeht sollten alle Partitionen die später verschlüsselt werden sollen mit Zufallszahlen überschreiben werden. Dazu reicht es dd bs=16M if=/dev/urandom of=/dev/hdXX zu verwenden. Dies kann bei grossen Partitionen und langsamen Laptops sehr lange dauern (mehrere Stunden, übernacht).

3.2. swap

Mit dem cryptsetup Paket bietet Debian eine einfache Möglichkeit Partitionen zu verschlüsseln. Ein init-script liest beim booten /etc/crypttab und ruft cryptsetup mit den dort vermerkten parametern auf.

Als erstes fügen wir folgendes in die /etc/crypttab ein:

# <target device> <source device> <key file> <options>
cswap /dev/hda6 /dev/urandom swap

(/dev/hda6 natürlich auf die partition die den Auslagerungsspeicher beinhalten soll anpassen)

Damit ist jetzt schon eine zufällig verschlüsselte partition eingerichtet. Jetzt passen wir die /etc/fstab noch an, damit diese partition als swap eingebunden wird:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/cswap       none    swap    sw              0       0

Voila, encrypted swap ist fertig!

3.3. einfach

Die gleiche Methode wie oben lässt sich auch für unsere Datenpartition anwenden. Nur wird hier none in der key-file zeile angegeben. Dadurch wird beim booten interaktiv nach einem Passwort was für die Verschlüsselung verwendet wird gefragt.

in /etc/crypttab:

cvar /dev/hda7 none

in /etc/fstab:

/dev/mapper/cvar      /var    auto defaults   0       0

Damit hat man die /var partition schon einfach verschlüsselt.

Leider hat diese Methode folgende Nachteile:

  1. Es gibt nur eine Passwort für die Partition den alle Benutzer des Laptops wissen müssen.
  2. Das ändern des Schlüssels ist eine aufwendige/experimentelle Angelegenheit, da alle Daten auf der Partition umkodiert werden müssen.

3.4. sicher

(veraltet s. u. 'extra sicher')

Eine Möglichkeit die Nachteile der einfachen Verschlüsselung aufzuheben, ist es, wenn jeder Benutzer einen kleinen USB-Stick benutzt, der den Festplattenschlssel speichert. Sinvollerweise sollte der Schlüssel auf dem USB-Stick dann natürlich mit einem Benutzerpasswort verschlüsselt sein.

Mein USB-Stick hatte im Auslieferungszustand einige ungenutzte kbytes hinter der vorformatierten FAT partition. Also habe ich dort einfach eine winzige Partition hinzugefügt, die den Schlüssel aufnimmt. Ähnliches sollte auch mit anderen USB-Sticks möglich sein.

Damit das funktioniert bräuchte man eigentlich nur folgendes in die /etc/crypttab schreiben:

### <target device> <source device> <key file> <options>
key /dev/sda2 none readonly
cvar /dev/hda7 /dev/mapper/key

Das heisst, als erstes wird der USB-Stick (hier /dev/sda2) mit einer interaktiven passwort-abfrage entschlüsselt und danach werden die entschlüsselten Daten von /dev/mapper/key gleich wieder als Schlüssel für die crypto-var Partition verwendet.

Dies funktioniert leider noch nicht ganz so einfach. Damit der USB-Stick von Debian überhaubt als /dev/sda eingebunden wird, muss das hotplug system laufen, in der standard Debian Installation wird es allerdings erst nach dem cryptdisk und mountall aufgerufen. Um dies zu fixen geben wir mv /etc/rcS.d/S*hotplug /etc/rcS.d/S26hotplug an der console ein. Damit wird hotplug nun vor S28cryptdisk gestartet.

Nun haben wir allerdings das Problem, das hotplug keine firmware die in /usr/lib/hotplug/firmware gespeichert ist, mehr laden kann, da wir hotplug vor dem mounten von /usr starten. Zum Glück schaut hotplug aber auch ins /lib/firmware directory um nach Firmware zu suchen. Bei Debian muss man dies erst anlegen und dann die Firmware dorthin verschieben. Danach sollte alles einwandfrei laufen, nur dran denken das man Firmware updates immer wieder nach /lib/firmware packt und nicht nach /usr/lib/hotplug/firmware  wie viele Installationsanweisungen vorschlagen (vieleicht bietet es sich hier an einen symlink anzulegen).

Einen kleinen Schönheitsfehler hat die ganze Sache nun noch. Nach dem Aufschliessen der Partition will der Benutzer seinen USB-Stick wieder abziehen und ausserdem ist es nicht gerade vorteilhaft den Festplattenschlüssel offen in /dev/mapper/key zu präsentieren. Also machen wir uns ein kleines init-script das das mapping nach dem Gebrauch gleich wieder aufhebt und für den fall, das der key nicht passte den Laptop gleich wieder abschaltet.

Nach /etc/init.d/remove_key.sh schreiben wir folgendes:

#! /bin/sh
#
# remove the mapped key-device

set -e

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
#exit 0
case "$1" in
  start)
        if cryptsetup remove key; then
                echo "Key accepted."
        else
                echo
                echo
                echo "    YOU ARE NOT AUTHORIZED TO USE THIS LAPTOP!!"
                echo
                echo
                poweroff -f
        fi
        ;;
  *)
        exit 1
        ;;
esac

exit 0
remove_key.sh

und binden ln -s /etc/init.d/remove_key.sh /etc/rcS.d/S29remove_key.sh ein.

3.4.1. Einrichten des USB-Sticks

Nun muss nur noch ein Schlüssel auf den USB-Stick

3.5. extra sicher

Die obige Methode hat noch folgende Nachteile:

Die Lösung:

Wir verteilen den Schlüssel auf den laptop und auf den USB-Stick und generieren bei jeder Benutzung einen neuen Key. Der USB-Stick kann nur für die nächste Anmeldung benutzt werden, Kopien davon werden dabei ungültig wenn eine Kopie bei der nächsten Anmeldung benutzt wurde wird das orginal damit ungültig (Was ein cleverer einbrecher allerdings durch manipulation der scripte verschleiern könnte!)

wir modifizieren die crypttab:

### <target device> <source device> <key file> <options>
# usb-flash decrypted with password gives prekey
prekey /dev/sda2 none cipher=aes-plain,size=256,hash=sha256,mode=600

# prekey decrypted with /etc/hdkey gives key
key /dev/mapper/prekey /etc/hdkey cipher=aes-plain,size=256,readonly,mode=400

# now use key to decrypt our secret partition
cvar /dev/hda4 /dev/mapper/key cipher=aes-cbc-essiv:sha256,size=256
### <target device> <source device> <key file> <options>

d.h. der USBstick wird zusammen mit einer passphrase zum prekey entschlüsselt, dieser prekey wird dann mit einem auf dem laptop gespeicherten /etc/hdkey zum key für die festplatte entschlüsselt.

Der Trick liegt nun in regenerate-key.sh welches einen neuen /etc/hdkey aus /dev/random generiert und diesen dann nimmt um /dev/mapper/key neu auf das keydevice zurückzuschreiben bevor es alle key mappings wieder entfernt.

#!/bin/bash

# the crypted filesystem regex and its uuid for detection
CRYPTFS=/dev/mapper/hda1_enc
UUID=$'\x6a\xb5\x2c\x07\x68\xe9\x42\x53\x8a\xff\x22\x0d\x3a\x0b\x0e\x83'

# where to store the key on the hd
HDKEY=/dev/hda4
BAKKEY=/lib/init/rw/key

# check if filesystem was successfully decrypted
if [[ "$(dd if=${CRYPTFS} bs=8 count=2 skip=141 2>/dev/null)" = "$UUID" ]]; then
        # try to make backup of the old key
        if dd if="${HDKEY}" of="${BAKKEY}" bs=512 count=1 >&/dev/null; then
                # backup succeeded

                # generate a new random keyfile in a safe manner
                dd if=/dev/urandom of="${HDKEY}" bs=512 count=1 >&/dev/null

                # mapping for the new key
                cryptsetup create newkey /dev/mapper/prekey -d "${HDKEY}" -c aes-plain -s 256

                # try to reencode the key (on usb-flash in-place)
                if dd if=/dev/mapper/key of=/dev/mapper/newkey bs=512 count=1 >&/dev/null; then
                        # succeeded
                        echo -e "\n\tKEY REGENERATION SUCCESS\n"
                else
                        # couldn't write to usb-flash, restore old key
                        dd if="${BAKKEY}" of="${HDKEY}"
                        echo -e "\n\tKEY REGENERATION FAILED: USB-Flash not writeable\n"
                        sleep 5
                fi

                dd if=/dev/urandom of="${BAKKEY}" bs=512 count=1 >&/dev/null
                dd if=/dev/urandom of="${BAKKEY}" bs=512 count=1 >&/dev/null
                rm "${BAKKEY}"

                # remove mapping and sync
                cryptsetup remove newkey
                sync
        else
                # couldn't make a backup, old key remains 
                echo -e "\n\tKEY REGENERATION FAILED: couldn't backup old key\n"
                sleep 5
        fi

else
        # wrong or missing key? 
        echo -e "\n\n\n\tYOU ARE NOT AUTHORIZED TO USE THIS LAPTOP!!\n\n\n"
        poweroff -hf
fi

# remove the remaining key mappings
cryptsetup remove key
cryptsetup remove prekey
regenerate-key.sh

Nebenbei: Flash speicher wie usb-sticks kann man nicht unbegrenzt überschreiben, irgendwann geht er kaputt. Für dieses Authentikations-System ist das aber nicht von Belang da moderne USB-Sticks sich mindestens einige zehntausend mal überschreiben lassen (wenn nicht sogar hunderttausende mal).

3.6. paranoid

Um die obigen Vorschläge noch weiter zu verbessern kann man anstatt eines einfachen USB-Sticks einen USB-Stick mit Fingerabdrucksensor, der erst durch biometrische Authentifizierung lesbar wird, verwenden.

3.7. Steckt der usbstick?

hier ein kleines script das 30 sec lang bis der usbstick gesteckt wird (ziemlicher hack, muss an den eigenen stick angepasst werden)

#!/bin/sh

case "$1" in
start)
        for ((i=0; i<30; ++i)); do
                grep "sda$" /proc/partitions >&/dev/null && break
                sleep 1
        done
        test $i = 30 && poweroff -hf
        ;;
stop)
        :
        ;;
restart|reload|force-reload)
        $0 stop
        $0 start
        ;;
*)
        echo "Usage: $0 {start|stop|restart|reload|force-reload}"
        ;;
esac

wait-for-sda

4. login

TODO

Sicherer Betrieb

1. laplock.sh

natürlich will man den laptop auch mal eingeschaltet stehen lassen ohne jemand an die Daten kommt. Dazu gibt es möglichkeiten das der X screensaver nach dem Benutzerpasswort fragt, oder terminal lock programme. Mir gefällt dies beides allerdings nicht, da der screensaver erst nach einiger zeit gestartet wird und vorraussetzt das X überhaubt läuft ähnliches gilt für terminal lock programme.

Was ich will ist ein lock programm das:

  1. sicher funktioniert, egal ob X oder console gerade läuft
  2. intutiv zu bedienen ist, und den Laptop sofort dann sichert wenn ich ihn verlasse
  3. keine processorleistung (batterie) mit irgendwelchen Schnickschnack verbraucht

daraus folgt:

  1. es sollte eine eigene console aufmachen und verwalten und das consoleswitching abschalten
  2. der einfachste handgriff bei einem laptop um ihn gegen fremden zugrriff zu schützen ist 'klappe zu', mit dem ACPI system nutzen wir diesen event zum locken
  3. vlock tut genau das was ich will

Ausserdem erledigt es gleich noch ein paar extra Aufgaben:

Wichtig ist noch das man die magic-sysreq-key sequenz vom kernel abstellt, sonst kann jemand mit 'Alt+SysReq+K' vlock abschiessen und Zugang erlangen!

also hier ein kleines script das als /etc/acpi/laplock.sh gespeichert wird:

#!/bin/sh
test -f /tmp/laplocked && exit
touch /tmp/laplocked
renice -20 $$
(
        grep -v '#' /etc/laplock.suspend | while read process; do
                killall -STOP $process 
        done
        logger -t laplock -p auth.info 'locked'
        sysreq=$(cat /proc/sys/kernel/sysrq)
        echo 0 >/proc/sys/kernel/sysrq
        fguser=$(find /dev/tty$(fgconsole) -printf "%u")
        openvt -sw -- su $fguser -c 'cat /etc/issue; vlock -a'
        rm /tmp/laplocked
        echo $sysreq > /proc/sys/kernel/sysrq
        logger -t laplock -p auth.info 'unlocked'
        deallocvt
        amixer set Master unmute &>/dev/null
        grep -v '#' /etc/laplock.suspend | while read process; do
                killall -CONT $process
        done
) &
test ! -f /tmp/lid_nomute && amixer set Master mute &>/dev/null
sync
laplock.sh

da ich laptop-mode benutze kommt das jetzt noch in den action handler vom laptop-mode mit rein /etc/acpi/actions/lm_lid.sh

#!/bin/bash

source /etc/acpi/laplock.sh

test -f /usr/sbin/laptop_mode || exit 0

# lid button pressed/released event handler

/usr/sbin/laptop_mode auto

fertig, testen --- klappe zu, auf .. laptop is gelockt und wartet aufs passwort

Sicheres Netz

TODO

Achtung, WICHTIG!

LaptopSicherEinrichten (last edited 2008-09-09 18:02:20 by ct)