NAS verschlüsseltes volume remote entsperren

[lordpeng]

Hallo Leute,

ich möchte folgendes umsetzen: ein verschlüsseltes volume auf einem NAS, welches automatisch per remote entsperrt wird um zu vermeiden, dass das kennwort im NAS abzulegen

bei QNAP NAS boxen sind bei festplattenverschlüssellung 2 konfigurationen möglich:
1. das kennwort jedes mal nach dem booten des NAS eingeben
2. das kennwort direkt im NAS ablegen

es soll/darf keine interaktion durch den anwender notwendig sein um das NAS zu entsperren, daher kommt punkt 1 nicht in frage
auch soll das kennwort nicht im NAS abgelegt werden ...

ich habe mir folgendes konzept überlegt, auf einem remote-rechner der an einem anderen standort steht läuft ein script, das regelmässig checkt ob das NAS im netzwerk erreichbar ist und bereits entsperrt ist, falls es nicht entsperrt sein sollte, soll dies durchs script geschehen ...

die verbindung zwischen NAS und remote-rechner (der vermutlich ein raspbi sein wird) läuft über VPN

hat jemand andere ideen, einwürfe, einwände etc. für diese problemstellung?

[Viennaboy]

auch wenn du sie ned hören willst...
Was spricht dagegen das der Pi die Daten selbständig in ein Verschlüsseltes Archiv packt und dann auf die NAS verschiebt?

[lordpeng]

keine ahnung, was du meinst, es geht darum, in regelmässigen abständen zu prüfen, ob das verschlüsselte volume im NAS entsperrt ist oder nicht und falls es nicht entsperrt ist, soll es per remote automatisiert entsperrt werden, da eine interaktion durch einen anwender vor ort nicht gewünscht ist

d.h. so wie ich mir das vorstelle läuft auf dem kontroll-rechner (dem raspberry) ein script, das alle N minuten checkt ob das NAS lebt und entsperrt ist und wenn nicht, entsprechende massnahmen setzt ... d.h. es werden einfach ein paar befehle ans NAS geschickt und fertig ...

du darfst aber gerne erläutern wie dein vorschlag gemeint ist ...

btw 1. die freischaltung soll ganz bewusst durch ein remote gerät erfolgen um datendiebstahl durch hardwareverlust vorzubeugen ...

btw 2. das ganze ist derzeit ein reines rohkonzept und basiert NICHT auf einem realen projekt (leider), könnte zwar eins werden, aber wie ich den kunden kenne, wird das eh nix ...

[kleinem]

Ich würde das Problem folgendermaßen lösen:

1) User am PI anlegen, RSA keypair generieren
2) User am NAS anlegen, public Key vom PI user hinterlegen (zur ssh keyauth)
3) cronjob script am PI einrichten welcher alle N minuten läuft
4) script (am PI!) ist ein expect script, welches sich per ssh (rsa keyauth) am NAS einloggt und das command (inkl. passwort) zum entsperren des volumes ausführt.

[lordpeng]

>Ich würde das Problem folgendermaßen lösen:
genau das wäre auch meine vorgehensweise, nur dass ich wohl anstelle eines expect scripts perl verwenden würde
wie ich das technisch umsetze ist soweit auch klar (ist ja keine wirkliche herausforderung)

mir gehts in dem thread aber vor allem darum, ob vielleicht jemand noch andere ideen, vorschläge oder einwände hätte, oder vielleicht schwachstellen an diesem konzept erkennt, die ich gerade nicht sehe ...

[kleinem]

Verstehe, den script beginnt dann so?

Code: Alles auswählen

use Expect;

Aber im Ernst, wenn offensichtlich so um security und robustheit der Lösung bemüht bist, würde ich halt verstärktes Augenmerk aufs exception handling quer durch die Bank legen. Folgendes würde mir spontan einfallen:

error report per (sicherer) mail?
ssh host fingerprint fail
ssh auth fail
evtl timer (N min) agressiver setzen wenn der server gerade down ist
exception handling im expect script?
-> zb. CLI command/bzw. output ändert sich nach einem firmware upgrade?
-> race conditions, z.b. server ist up und per ssh erreichbar, aber RAID/LVM/wasauchimmer ist noch nicht vollständig initialisiert und das unlock command failed
usw..

[lordpeng]

also ich denke, das mit dem script würde das geringste problem sein, da hab ich schon ganz andere sachen mittels script gelöst ...

dein argument mit dem firmware update ist aber auf jedenfall berechtigt, das ist ein punkt, den ich auch schon im sinn hatte, ein firmwareupdate muss vorher natürlich auf kompatibilität und auch sinnhaftigkeit getestet werden

[zid]

hallo lord,

>"...um datendiebstahl durch hardwareverlust vorzubeugen ..."
dein ansatz is imho ok- bis auf die pollerei alle N minuten...
zeitgetriebene mechanismen hab ich nicht so gern, lieber sind mir ereignisgetriebene. ich würde also den spieß eher umdrehen:

- du richtest den nas so ein, daß *er* beim hochfahren deinem raspi eine unlock request schickt.
- am raspi setzt du eine acl, sodaß nur unlock requests mit src-ip = firmen-ip durchgelassen werden.

wenn jetzt ein dieb bei nacht und nebel in der firma einbricht, sich den nas schnappt, damit abzischt, um das ding daheim zu starten, dann rennt er kerzengrad in den beton, weil daheim
src-ip != firmen-ip
gilt und dein raspi die requests blockt.
so, und jetzt gibts nur noch ein zartes prob:
manche diebe sind nicht ganz so unterbelichtet, wie man es gerne haben wollte. daheim angekommen überzuckert der knilch deinen mechanismus, schnappt sich einen lapi + den nas und kehrt zur firma zurück- am besten in der mittagspause, da is eh nie was los...
dort startet er den nas, was auch gutgeht, weil in der firma eben src-ip = firmen-ip gilt, dann nur noch das cu-schnürl von nas abziehen, lapi dran, und die party geht schon los...
um dieses szenario abzusichern, müßtest du den nas so herrichten, daß ein shutdown getriggert wird, sobald die nic down geht, so'ne art reverse wol sozusagen.

ausprobiert hab ich das noch nie. sind nur ein paar gedankensplitter, die mir grad so in den sinn gekommen sind.

lg
zid

[lordpeng]

danke zid, du hast nicht ganz unrecht, das mit der pollerei übers vpn ist nicht unbedingt schön, aber ich will das NAS eigentlich möglichst unmodifiziert lassen

>müßtest du den nas so herrichten, daß ein shutdown getriggert wird, sobald die nic
>down geht, so'ne art reverse wol sozusagen.
das wär schon machbar, aber dann müsste ich wieder im NAS herumwerken, was ich ja eher vermeiden will, weil je mehr ich hier umbaue desto problematischer wirds wenn jetzt vielleicht wirklich mal ein firmware update fällig wäre oder ein problem auftritt, für das ich den herstellersupport brauchen würde (ist zwar bei NAS boxen noch nicht vorgekommen, aber was das betrifft halt ich mir lieber alle türen offen

>wenn jetzt ein dieb bei nacht und nebel in der firma einbricht, sich den nas schnappt,
>damit abzischt, um das ding daheim zu starten, dann rennt er kerzengrad in den beton
also wenn dieser fall eintreten sollte, dann gehe ich von einem gezielten angriff aus und gegen sowas hat man idR. nicht so gute handhabe, bzw. wenn sowas zu befürchten wäre dann müsste der kunde ohnehin mit anderen geschützen auffahren (dort gibts keine wirkliche EDV infrastruktur, obwohl ich eigentlich seit 10 jahren rede und rede, weshalb ich auch dran zweifle, dass dieses projekt jemals umgesetzt wird)...

>ausprobiert hab ich das noch nie. sind nur ein paar gedankensplitter, die mir grad so in den sinn gekommen sind.
ich hab mir mal die hardware zum durchspielen des szenarios herbestellt

[Viennaboy]

daführ nimmt man normal SED Drives.

[lordpeng]

>daführ nimmt man normal SED Drives.
weil? ... performance spielt keine wirkliche rolle und ich bezweifle, dass gängige NAS boxen mit selbstverschlüsselnden platten umgehen können, so gesehen sehe ich keinen wirklichen vorteil zu software-basierenden lösungen und gerade auf besagten NAS boxen konnte ich im test* keinen signifikanten performanceunterschied feststellen...

*zum testen habe ich ein NAS volume, das vorher unverschlüsselt war, gestern verschlüsselt - der datendurchsatz hat sich nur minimal verschlechtert

[Viennaboy]

ich bezweifle, dass gängige NAS boxen mit selbstverschlüsselnden platten umgehen können

deswegen sag ich ja auch ständig das man ein "Pc" nimmt wo man den passenden Controller reinstecken kann der es unterstützt.
Weil dann kann man im OS den Controller zurücksetzen und die Daten sind weg.

[lordpeng]

>deswegen sag ich ja auch ständig das man ein "Pc" nimmt wo man den passenden Controller reinstecken kann der es unterstützt.
>Weil dann kann man im OS den Controller zurücksetzen und die Daten sind weg.
mit welcher begründung? ... ich seh da keinen vorteil drinnen ...

[jutta]

]deswegen sag ich ja auch ständig das man ein "Pc" nimmt wo man den passenden Controller reinstecken kann der es unterstützt.

das setzt aber voraus, dass es ein budget für die laufende wartung des pc gibt, bzw, dass man dem kunden ein solches wartungspaket verkaufen kann.

[lordpeng]

>bzw, dass man dem kunden ein solches wartungspaket verkaufen kann.
vielmehr gehts darum, die ganze lösung so einfach wie möglich zu halten und mit standard-hardware zu arbeiten, desweiteren soll die möglichkeit offengehalten werden einem örtlichen EDV dienstleister für eventuellen hardwaretausch im defekt-fall zu konsultieren und da machts jetzt ned unbedingt sinn, eine hochkomplexe lösung zu erarbeiten ...