Lura min NAS att kryptera filsystemet?

Inte helt rätt fram, vad är NAS OS? Kan man tanka ner det och leka runt med det på i t.ex. virtualbox??

Bara för att den kör linux kernel betyder det inte att tillverkarna inte varit kreativa med egna lösningar och byggt på funktionalitet. I vanliga linux distributioner är är LUKS vanligt, men det finns flera sätt att kryptera sina diskar på. Och oftast är det inte bara någon flagga, utan snarare en installations setup man får göra.

Sen handlar det också om vad din NAS har för processor. Är du nöjd med t.ex. en max hastighet på 100-300kb/sec när CPUn går i taket för den saknar vissa instruktioner som accelererar kryptering? Det kan vara enorm skillnad, man kan inte ta sånt förgivet att det bara skulle vara lite långsammare.

Har du provat att uppdatera mjukvara till den senaste och se om funktionaliteten har tillkommit (när man uppdaterar en NAS och speciellt stora uppdatering när man hoppar flera steg i uppdatering på en gång, skall man alltid säkra att man har backup på sina data innan på externa USB-diskar) - det kan också vara att du får skrota dina nuvarande volymer (och tappa all data om de inte flyttas/har backupp) och skapa nya innan du kan välja krypteringen då en del av dessa är diskvolymbaserade/partitionsbaserade (dm-crypt) och kan inte läggas på i efterhand på en redan använd partition/filsystem. Däremot om man använder 'encfs' så kan det lägga på befintlig volym och dessutom kan köras med Usermode utan beroende av root-rättigheter (använder FUSE för att skapa virtuella filsystem på user-nivå).

på somliga NAS-fabrikat (som netgears NAS) så kan man hämta tilläggs-programvara via 'apt-get install' systemet - andra som Asustor är helt isolerad och mycket fientlig på cli-nivå och väldigt lite 'standard' fungerar om man vill jobba via SSH-termina...

---

På en ARM-baserad NAS med 32-bitars OS och utan HW-stöd för kryptering så hamnar man runt 10-12 MByte/s på en krypterad filsystem - ganska lika även mellan olika kryptomiljöer. Problemet med de olika ARM-versionerna på Low-end NAS (som din) är att även om använda ARM-propp har HW-AES-stöd så stödde inte libbarna för det i använda OS utan det mjukvaru-tuggades oavsett

En system är att använda encfs som vissa NAS:ar använder (bl.a Asustor idag) men med nackdelen att filnamnen kan bara vara max 148 tecken långa och är en filbaserad kryptering vilket gör att man kan analysera fil-längder och tex kan se att det troligen är mediafiler av sin storlek även om filnamn och innehåll är krypterat

volymbaserad kryptering så är dm-crypt (och hanteras ofta med cryptsetup och med Lukscrypt) mer eller mindre standard men måste planeras i samband när man skapar volymer då det är block-device-kryptering direkt mot partitioner eller diskimage-kontainrar via loopback (losetup...) och filsystemet läggs sedan ovanpå detta - på en raidad system kan det vara 3 lager med först md-adm-RAID, på detta DM-crypt och ovanpå allt själva filsystemet som då oftast också är en volym i NAS:en

Asustor använde det tidigare via loop-AES eller dm-crypt (kommer inte ihåg vilket) på lägsta nivå utan Lukscrypt eller cryptsetup som skal på en fil som var en diskimage som gömdes på den befintliga volymen och var en sk. sparse-fil lika stor som hela volymen men tog nästan ingen plats på disken när den var nyinitierad - problemet med detta arrangemang var att platsen återlämnades inte till volymen när man tog bort filer igen i den krypterade volymen och det fans ingen funktion som 'nollade' sektorer utanför själva krypteringen när man raderade filer.

Detta medförde att man förr eller senare körde 'End of Space' på volymen och man kunde inte göra ett skit trots att den krypterade delen var i stort sett tom.

Detta hände tydligen för tillräckligt många användare och Asustor ändrade det till encfs i senare mjukvaruuppdateringar.

Jo de flesta knappar i GUI slutar i andra ändan i någon form av kommandoradsprogram.

att hantera dm-crypt ensam är bökig på kommandoradssidan då man skall trycka i en väldigt massa parametrar på detajnivå och dessutom är volymen som skapas inte 'säker' - inte i avseende säkerhetsmässighet då den är bra utan att strukturen påminner om en okrypterad filsystem och kan mountas av misstag med fel filsystemhanterare och man får totalhaveri.

Det som är vanligaste med dm-crypt är att man använder ett 'skal' av scriptar ursprungligen, nu program som kallas 'cryptsetup' som tar hand om all krångel med bra defaultvärden till chiphern mm. och gömma undan passorden på bra sätt och där kan man välja Lukscrypt som sätter en egen header på partitionen och därmed inte kan misstas för en valid filsystem längre. LUKS-crypt ger också möjligheten med upp till 8 olika nycklar för att komma in i samma volym

---

dm-crypt går på partitioner så där går det inte så mycket att göra åt om man inte är villig att skrota sina volymer och bygga nytt.

Om man nöjer sig med filkryptering så kanske gocryptfs skulle vara något att kolla om man kan kompilera upp det för ARM-miljö (finns för rpi) och är skriven i go.

Den kör på FUSE och därmed inte behöver rooträttigheter för att köras - den kan också köras reverserat precis som encfs (dvs man refererar mot en filträd i filer ej krypterad form och nya mappen som gocryptfs monteras mot visar då samma filträd som orginalet men då som krypterade filer och mappar som speglas och kan tex. synkas mot molntjänst då alla filer är krypterade som skickas över med tex rsync eller rclone - med andra ord filerna krypteras bara när man läser ut dessa från den krypterande mapparna vilket gör att man fortfarande har kvar snabbheten på den ej krypterade orginalsidan som inte är krypterad.

Hur eller hur så är det en efterföljare på encfs 'in mind' och fixat en del av potentiella vekheterna som encfs har samt att de har löst att man kan ha filnamn ända till 255 tkn