Mennyire lassít a titkosítás

Ubuntu Linux

Mennyire lassítja egy szervernél a fájlolvasási/írási sebességet a full-disk titkosítás? Különösen akkor ha SSD-ről megy a rendszer.

B kérdés: az áramszünetre érzékeny a titkosított partíció?

  • 3665 megtekintés

( Takaya | 2015. 01. 24., szo – 17:48 )

Ha eleg eros a CPU, lenyegeben nem befolyasolja.

Laptopom procija Hardware Accelerated AES-el tudna 2.3GB/s-et kodolni, de az SSD csak 1140MB/s-es tempot bir :D

Nehany %-os lassulas elofordulhat.

x<10%

--

"You can hide a semi truck in 300 lines of code"

Az érintett telephelyen gyakorlatilag chatnak nézik a levelezést, illetve univerzális fájlküldő rendszernek. :-) Filmeket természetesen nem küldözgetnem emailen, de méreted dokumentumokat rendszeresen. Szóval előreláthatólag keményebb használhat hárul az SSD-re mint egy fileservernél.

A kedvencem: az illető lefotózta a telefonjával a Google találatok közt lévő terméket jépegbe, majd azt a képet bitmapként belerakta egy docx-be, utána bezippelte, és el e-mailozta. Ja, és hót homály volt az egész kép, így pont azok a részletek nem látszottak a fényképen, amiknek kellettek volna. :)
Még jó, hogy pár betűt sikerült a fotóból kisilabizálnom, és így rátaláltam az eredeti képre...

Amikor megnyitottam eme levelet, sikeresen lekapcsolt mentálisan kb negyedórára. (szerintem még a nyálam is kifolyt)

Ez semmi... A bürokrácia mégnagyobb csodákra képes. Rendszeresen kapok képújsághirdetésbe(!) hívatalos rendeleteket, a következő módon:
1. Megírják, kinyomtatják
2. Aláírják, lepecsételik
3. Szar minőségben bescannelik, tömörítetlen képnek
4. bepakolják pdf-nek
5. elküldik csatolmányként.

Több oldalas A4-es doksik is jönnek így néha, amikor meg visszaírok, hogy küldjék már el szöveges formába, vagy már nincs meg, vagy nem küldik, mert úgy nincs rajta pecsét :D

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

( Ritter | 2015. 01. 24., szo – 18:36 )

Új kérdés, hogy áramszünetre érzékenyebb-e a titkosított partíció mint a titkosítás nélküli?

" Plain format is just that: It has no metadata on disk, reads all parameters from the commandline (or the defaults), derives a master-key from the passphrase and then uses that to de-/encrypt the sectors of the device, with a direct 1:1 mapping between encrypted and decrypted sectors.

Primary advantage is high resilience to damage, as one damaged encrypted sector results in exactly one damaged decrypted sector. Also, it is not readily apparent that there even is encrypted data on the device, as an overwrite with crypto-grade randomness (e.g. from /dev/urandom) looks exactly the same on disk."

https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions

------------------------------------------------------------------------------
www.woodmann.com/searchlores/welcome.htm

( osod88 v | 2015. 01. 24., szo – 18:41 )

Szerver, ráadásul ssd-vel. Ne legyen már áramszünet. Kell egy normális ups, bekonfigurálva az os-en.
SSD-k nem díjazzák a hirtelen áramszüneteket, pontosabban az összes adat el tud veszni róluk ilyen esetben.

Aztán annak hogy koros és minőségi a szerver, mi köze van az áramellátás folyamatosságához?
Koránt sem kell 100 ezerért ups-t venni, normális APC-k vannak már 40 ezer környékén.
Ez a link, hogy felrobbant az abit nf-8-as alaplap a vargáné táp mögött meg egy vicc kb.

A négyszög-áram (feszültség, pontosabban) kb. mindegy egy kapcsolóüzemű tápnak. Kicsit nagyobb lesz az elektromágneses sugárzás, kicsit nagyobb lesz a diódák terhelése, oszt ennyi. Ha a táp rendesen túl van méretezve (ugye az 500W-os tápot nem 500W-on használjuk), akkor ez nem lehet gond.

A szerverek tápja kapcsoló üzemű, 100-240V között bármit megeszik, akár egyenáramot is.
Ami nem bírta a négyszögjelet, az a trafó (modem, stb. tápja).

A "vargánya" táp magától is felrobbant, mert az alkatrészek és a hűtőbordák (alumínium!!) jelentős részét kispórolták.

Minden (,minden) szerverünk, router-ünk, stb. UPS mögött van legalább 20 éve és a munkaállomások jó része is.
A rack-es APC-től a nagyon gázos kínaiig, minden előfordul, de még egyik ügyfelünknél sem cseszte szét az UPS a gépet (maximum saját magát :)

Az áramkimaradásból rengeteg adatvesztéssel kellett megküzdeni, néha kézzel kellett visszaállítani a RAID-et vagy a file-rendszert.

Szóval UPS mindenképpen kell, lehetőleg olyan, amivel tud a gép kommunkálni.

Az eredeti kérdésre visszatérve, egy régi dual Xeon-os szerveren (3GHz, ECC DDR1 RAM, no HW AES) szinte alig volt észrevehető, moderált office használat közben.
---
http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

( elod v | 2015. 01. 24., szo – 18:47 )

Továbbra sem értem miért ide titkosítás? És hogy indul ez a szerver? Belépsz távolról és adatpartíció felcsatolása előtt megadod a jelszavát?

Volt példa már erre is. Persze gyakoribb, hogy egy volt bosszúszomjas alkalmazott az illető.

Az nyílt internet felé bármilyen szolgáltatást nyújtó szerverek biztonsága egy teljesen más problémakör. Ha betörnek és megszerzik a root jogot, vagy legalább hozzáférést a fájlokhoz, akkor azon nyilván nem segít az, hogy egyébként titkosított adathordozón vannak az adatok. A partíciók titkosítása a "szerver megszerzése" esetén viszont hatékony védelem, a rajta tárolt adatokra.

A titkosításnak több oka lehet. Én akkor alkalmazom, ha nem ítélem megfelelőnek a szerver fizikai védelmét.

Egyébként egy HP microserverben levő N54L processzor is 85 MB/mp adatolvasást tesz lehetővé titkosított partícióról. Egy E3-xxxx procinál kb. 500 MB/másodperc vihet el egy procimagot a sok közül.

Én úgy oldottam meg több helyen is, hogy egy kiemelt ("admin") felhasználó kap egy speciális pendrive-ot, amit be kell dugni, amikor (újra)indul a szerver. Ennek segítségével nyíl[i|na]k a titkosított partíció(k).
A cégnél van még egy ilyen pendrive biztonságos helyen, ha az első megsérülne. Enélkül nem indul el a rendszer.
Távolról pedig újra tudom indítani egy script segítségével, ami ideiglenesen preparálja a megfelelő fájlokat, majd újraindulás után takarít.

Ezt lehet kiegészíteni azzal, hogy a pendrive nem közvetlenül van a gép seggébe dugva (mert esetleg a támadó észrevehetné), hanem a sok belőle kijövő vezeték közül az egyik egy USB hosszabbító, ami valami fixen lecsavarozott/jól eldugott/nehezen elmozdítható dobozba vezet, és abban van a pendrive. Én pl. ha egyszer lesz a házam alagsorában egy szerver, tuti be lesz falazva az indításhoz szükséges pendrive :) Aztán ha valaki úgy gondolja, hogy majd talál valami terhelőt rám nézve a gépen, az meg fog lepődni :D

A pendrive végére (pl. 

gparted

-del) csináltam egy minimális partíciót. Ezen van a kulcsfájl (el is lehet rejteni), adhatsz neki egzotikus fájlrendszert, ...
Az 

/etc/fstab

-ban bemountolom valahová (pl. 

/mnt

). Itt megint lehet trükközni id, vagy uuid, vagy sdXY hivatkozással.

Az 

/etc/crypttab

-ban a következőképpen adom meg a kulcsfájl helyét: 

logikainev   /dev/fizikai_particio  /mnt/kulcsfajlhelye/kulcsfajlneve luks

A következő rész Linux disztribúciótól függően értelemszerűen eltérhet: 

/etc/init.d/after.local

tartalma az umount-ért és a 3 csipogásért (be kell kötni speakert, ha nincs a gépben!): 

umount /mnt
echo -e "\a" >/dev/tty3
/usr/bin/sleep 1
echo -e "\a" >/dev/tty3
/usr/bin/sleep 1
echo -e "\a" >/dev/tty3
/usr/bin/sleep 1

A script titkosítatlan partícióra másolja a kulcsfájlt, elmenti az eredeti 

/etc/fstab

és az 

/etc/crypttab

tartalmát (pl. .orig kiterjesztéssel), majd a helyükre másolja az előre elkészített 

fstab.ssh

-t és 

crypttab.ssh

-t.
Az 

fstab.ssh

-ból ki kell törölni a kulcs pendrive mountolását, a 

crypttab.ssh

-ban pedig át kell írni a kulcsfájl útvonalát a titkosítatlan helyen lévő kulcsfájléra.
A 

/etc/init.d/after.local

-ban, vagy a 

/var/spool/cron/tabs/root

"@reboot" bejegyzésében töröljük induláskor a kulcsfájlt a titkosítatlan partíciórol.

Ha kihagytam valamit, kérdezz, segítek szívesen.

( zolpet | 2015. 01. 26., h – 22:27 )

http://browser.primatelabs.com/geekbench3/search?q=Xeon+E5420
Elég változóak az eredmények konfigurációtól függően, de úgy látom, ez a processzor nem tartalmaz még hardveres AES gyorsítást, így SSD esetén valúszínáleg erős a lassulás.

Az első találat, egy HP workstation:
AES
Single-core
106.8 MB/sec

AES
Multi-core
701.8 MB/sec