NAS verschluesselung

kskler199

Lt. Junior Grade
Registriert
Juni 2008
Beiträge
390
Guten abend community!

Ich baue diese woche meine NAS bassierend auf fedora.
Die relevante hardware:
- 500gb festplatte mit fedora
2x3tb im raid 1 für owncloud daten.

Ich möchte die NAS wegen den daten komplet verschluesseln, allerdings soll sie morgens selbst booten und später runterfahren.

Wie würdet ihr das problem loesen?

System platte standardmäßig mit fedora verschlüsseln und as raid nachträglich mit truecrypt?

Oder liese sich system und raid zusamme mit der fedora verschluesselung regeln?

Danke u grüsse
 
Je nach Hardware würde ich Hardwareverschlüsselung nehmen.

Beantworte dir selbst die Frage, warum du verschlüsselst. Besteht Gefahr, dass der Server geklaut wird? Wenn ja, der Dieb kann ihn ja einfach bei sich booten.
 
exakt...

bei nem laptop machts ja noch sinn.
aber nen stationären server und dann auch noch dein privater ?

das is wie nen schloß in deine brieftasche einzubauen und die dann auf der parkbank zu lagern...
 
Zuletzt bearbeitet:
Ob das alles bei RAID funktioniert weiß ich nicht, daher mit Vorsicht genießen:

Ich würde es nicht mit Truecrypt machen wenn Linux mit LUKS / dm-crypt schon die passenden Werkzeuge mitbringt.
Entschlüsseln kannst du beispielsweise mit einem USB-Stick. Wenn dieser allerdings immer eingesteckt ist, bringt dir die Verschlüsslung absolut keine weitere Sicherheit.
Alle Information wie du die Verschlüsslung durchführen kannst findest in einer Kombination dieser Anleitungen:
http://wiki.ubuntuusers.de/LUKS#Erstellen
http://wiki.ubuntuusers.de/System_v...einem_USB-Schlüssel#Vorbereiten-des-Schlosses
https://systemausfall.org/wikis/howto/CryptoPartitionHowTo
https://wiki.archlinux.de/title/Festplatte_verschlüsseln#Vorbereitungen
 
Zudem ist ein Raid-1 für dich sinnlos, es ersetzt kein regelmäßiges Backup und potenziert die Fehlermöglichkeiten.
 
Guten Morgen
Danke für die vielen Antworten!
@john.veil: Da meinst du sicherlich raid 0 ;) raid 0 fügt 2 Festplatten zusammen, Raid 1 spiegelt. Daher wäre deine Aussage falsch
@wilhelm14 Ja der Server bassiert auf Hardware verschluesselung. Falls dann wirklich jemand den Server in die Finger bekommen sollte, so wären die Daten darauf verschlüsselt, und er könnte nichts damit anfangen.
@ Cliff1 Danke für die Links!

Wenn die System Platte verschlüsselt wurde, muss der Rechner ja standartmäßig kurz anch dem booten das Passwort erhalten, um dann die restliche Software zu starten.
Lässt sich dieses entschlüssen auch remote machen, sprich das zum Beispiel Ultra VNC in diesem frühen zustand des bootensmit startet?
 
kskler199 schrieb:
Lässt sich dieses entschlüssen auch remote machen, sprich das zum Beispiel Ultra VNC in diesem frühen zustand des bootensmit startet?

Viel zu umständlich. Ich würde eine udev-Regel erstellen, die bei Einstecken eines bestimmten USB-Sticks, der ein paar Schlüssel enthält, den relevanten Schlüssel ausliest und erst dann die entsprechenden Partitionen einbindet und weitere Dienste startet.

Alternativ kann man sich den Schlüssel auch von einem anderen Server holen, per smb, ssh, wget, was-auch-immer.

Oder aber man leitet die console auf eine RS232-Schnittstelle um. Würde ich für headless-Server sowieso machen, für den Fall, daß der Rechner nicht mehr über's Netzwerk ansprechbar sein sollte. Aber eine Passphrase beim Bootvorgang eingeben? Nein, viel zu umständlich.;)
 
Das hört sich vernünftig an. Somit könnte ich auf einen USB stick am Router die Schlüssel drauflegen.
Habe zwar mit einem solchen entschlüsselungs verfahren noch keine Erfahrung, aber hört sich doch sehr gut an!
Danke :)

Bin normal auch eher Win User. Aber Linux wird mir mehr und mehr sympatisch :)
 
Musst Dir überlegen, wie Du die Schlüssel speichern willst. Eine Möglichkeit wäre, sie in eine separate Partition zu packen, die Du (mit Label versehen) einhängst und die Schlüssel dann als Datei ausliest. Eine andere Variante wäre, daß Du sie als Rohdatenfolge an eine bestimmte Stelle schreibst und sie z.B. per dd auch wieder ausliest. So wären sie schwerer zu lokalisieren, insbesondere, wenn der USB-Stick mit Zufallsdaten aufgefüllt wäre. Für den einfachen Fall reicht aber sicherlich auch Variante 1.

Dann identifizierst Du den USB-Stick, am Einfachsten per Vendor-ID, und schreibst einen passenden Eintrag in /etc/udev/rules.d/, der in etwa so aussehen kann:
Code:
99-unlock-luks.rules:
## identify usb-key and run script
#BUS=="usb", 
SUBSYSTEMS=="usb"
KERNEL=="sd[b-z]2", 
ACTION=="add"
#ENV{DEVNAME}=="/dev/disk/by-label/lock",
ATTRS{vendor}=="SMI",
ATTRS{rev}=="1100",
#[...]
#SYMLINK+="usbkey%n", 
RUN+="/scripts/unlock-luks"

unlock-luks:
#! /bin/bash

## script to unlock and mount encrypted device on key insert
f_error(){    ## default error message
    echo "" >>/dev/ttyS0
    echo "Es ist ein Fehler aufgetreten bei Befehl $1." >>/dev/ttyS0
    echo "" >>/dev/ttyS0
    exit 1
}


if ! ( mount | grep -icq "/dev/mapper/storage" ); then
    if [ -e /dev/disk/by-label/lock ]; then
        mount -t ext4 /dev/disk/by-label/lock /lock
        if [ $? -ne 0 ]; then
            exit 1
        fi
        cryptsetup luksOpen --key-file=/lock/key.256 UUID=b4f34d1f-c647-410c-80df-7163e6713256 storage
        sleep 1
        mount /services/storage
        if [ $? -ne 0 ]; then
            f_error "mount /dev/mapper/storage"
        fi
        umount /lock
        echo "storage wurde erfolgreich eingehangen..." >>/dev/ttyS0
        if [ -e /run/lock/menu ]; then
            if ( mount | grep -icq '/dev/mapper/storage' ); then
                for SERVICE in $(cat /config/services.list); do 
                    if ( $( service ${SERVICE} status | egrep -icq "not running | stopped" ) ); then
                        echo "" >>/dev/ttyS0
                        echo "starte ${SERVICE}" >>/dev/ttyS0
                        echo "" >> /dev/ttyS0
                        service ${SERVICE} start
                        if [ $? -ne 0 ]; then
                            f_error ${SERVICE}
                            break
                        else
                            echo "" >>/dev/ttyS0
                            echo "service ${SERVICE} erfolgreich gestartet." >>/dev/ttyS0
                        fi
                    fi
                done
            fi
        fi
    fi
fi
exit 0

Hier habe ich bereits zwei Möglichkeiten, von denen eine ausgeklammert ist: Identifikation über die vendor-ID, oder über den "Gerätenamen".
Die Datei "unlock-luks" mußt Du Dir natürlich selbst ein wenig zurechtbiegen, es war nur als Gedankenansatz gedacht. Ich würde auch nicht mehr direkt an ttyS0 schreiben, sondern an syslog, so kann man Fehler auch später noch nachvollziehen. War nur jetzt zu faul, dies umzuschreiben.
Mehr infos über udev gibt's z.B. hier oder hier.
 
Danke Twostone für das skript!
vom ansatz verstehe ich das skript, ist aber von meinem standpunkt aus etwas zu hoch :D
Wenn die Hardware jetzt aber am Do ankommt werde ich mal testen ob ich dein skript umsetzen kann. falls ich da noch Fragen hätte, würde ich mich bei dir per pn melden wenn das ok ist :)
 
john.veil schrieb:
Zudem ist ein Raid-1 für dich sinnlos, es ersetzt kein regelmäßiges Backup und potenziert die Fehlermöglichkeiten.

kskler199 schrieb:
@john.veil: Da meinst du sicherlich raid 0 ;) raid 0 fügt 2 Festplatten zusammen, Raid 1 spiegelt. Daher wäre deine Aussage falsch
Er meint RAID 1 und er sagt richtig, dass ein RAID 1 kein Backup ersetzt. Du hast recht, dass ein RAID 1 spiegelt. Du liegst aber falsch, wenn du diese Spiegelung als Backup siehst. Warum ein RAID 1/Spiegel/Mirror kein Backup ersetzt steht hier: https://www.computerbase.de/forum/threads/alles-zum-thema-raid-und-die-funktionen.738685/

john.veil schrieb:
@wilhelm14 Ja der Server bassiert auf Hardware verschluesselung. Falls dann wirklich jemand den Server in die Finger bekommen sollte, so wären die Daten darauf verschlüsselt, und er könnte nichts damit anfangen.
Wenn der Server automatisch booten kann, kann er auch automatisch entschlüsseln. Dann kann ein Dieb damit etwas anfangen. Auch wenn du den Schlüssel auf einen USB-Stick ablegst und ihn im Server stecken hast. Du erwähnst schon die Möglichkeit, den Schlüssel bei jedem Boot eingeben zu müssen. Das wäre zwar sicher, aber eben auch unkomfortabel.
 
Natürlich ist Raid 1 kein Backup ^^ Dafür habe ich noch meine externe :)
Von der Verschluesselung scheint das mir aber alles nicht als gut genug.
OwnCloud unterstützt doch die Verschluesselung von Ordnern über die Web Oberfläsche. Somit wären die Daten ja auch lokal verschlüsselt?
Habe dazu leider nichts im Netz gefunden.
Falls das nämlich eintreffen würde, würde mir dies schon ausreichen.


Grüße
Ergänzung ()

Ok, doch noch was dazu gefunden:
http://www.tecchannel.de/storage/ba...s_owncloud_ein_security_vergleich/index5.html
Das dürfte für meine Verhältnisse ausreichen, da die daten lokal verschlüsselt werden.
 
ownCloud verwendet AES-256 auf die Daten im Data-Verzeichnis. Allerdings sind die Dateinamen weiterhin sichtbar, das mag je nach Use Case ein Problem sein. Letztlich halte ich ganz persönlich das für ausreichend - wenn denn alles im ownCloud-Verzeichnis liegt.

Sicher, dass du da nichts gefunden hast?
https://owncloud.com/wp-content/uploads/2014/10/Overview_of_ownCloud_Encryption_Model_1.1.pdf
https://github.com/owncloud/core/tree/master/apps/files_encryption
http://doc.owncloud.org/server/7.0/user_manual/files/encryption.html
 
Zuletzt bearbeitet:
Hier wird beschrieben, wie du einen Rechner, der mit dm-crypt+LUKS verschlüsselt ist dazu überedet kriegst, beim boot die key datei von einem usb-stick einzulesen.
Ich weiß nicht ob das patchen von mkinitrd noch immer nötig ist. Ein Vorteil bei LUKS ist, dass du mehrere Schlüssel haben kannst, also einen für den USB-Stick und einen den du dir merkst, falls der Stick verloren geht.
 
Zurück
Oben