Dotaz: boot: / s dmcrypt (volba klice pres sit)

[j3nda]

zdravim, stojim nyni pred problemem, ze chci na novy server udelat sifrovani pres dm-crypt s tim, ze bude sifrovat root (/) svazek. A zaroven heslo pro sifrovani se bude tahat z inetu. procital jsem si ruzne navody a howto (napr...) http://www.root.cz/clanky/zaostreno-na-dm-crypt/ http://www.root.cz/clanky/cryptoroot-pro-nejvyssi-bezpecnost-1/ http://www.root.cz/clanky/jak-funguje-initramdisk/ vsechno vypada schudne.

Rad bych se zeptal zkusenejsich hard-core uzivatelu na toto: je mozne pri bootovani natahnout heslo ze site? Mam na mysli sifrovani jiz korenoveho svazku s tim, ze asi nekde v initramfs bude neco, co to heslo bude tahat a zpristupnovat. [mozna se myslim, do boot procesu zas tak moc nevidim] zaver a shrnuti problemu:
% bootovat linux s sifrovanym korenovym svazkem (mimo /boot
% heslo pro desifrovani tahat ze site (nejaky php skript v inetu) - lze toto vubec realizovat?
- pokud ano, za jakych podminek a kam bych mel umistit skript pro ziskani hesla?
- pokud ano, kdy a jak se inicializuje sit? [
mam zato, ze sit se inicializuje, az v okamziku pripojeni root svazku a v poradi, v jakem je urcenov rc.* takze mnou definovany model nemusi byt funkcni
] prosim poradte...
dekuji. j3nda.

Odpovědi

[zd]

no sit se da zprovoznit i v initrd. pouzival jsem to por startovani bezdiskove stanice ale dm-crypt bohuzel neznam ...

[pht]

imho to pujde a nemusi to byt zas takovy problem, jen si sestavte ten initrd. ale osobne nevidim duvod sifrovat veci jako /bin/bash, protoze kazdy stejne vi co v nem je.

[Jendа]

Ano, je potřeba dát do initrd moduly k síťovce a programy jako ip a nastavit init v initrd, aby nahodil síť. Jen mi uniká smysl - když se to heslo bude tahat po síti, tak stejně půjde odposlechnout, ne?

[j3nda]

puvodni myslenka byla, ze se to bude tahat z https zdroje pres .php s tim, ze se to nejakym jednoduchym (vlastnim) crypt/mcrypt algoritmem zasifruje/rozsifruje podle klice (ip adresy, odkud se to taha)

[prozatim jsem cely tento napad nerealizoval a stale jej odkladam :-/]

[pht]

vlastni crypt to je jako dat si neprustrelny dvere a vedle nechat otevreny okno.

jestli to chcete tahat pres sit tak pouzijte gpg a klice generujte pro kazdyho hosta zvlast. [pak nebude potreba https, staci (t)ftp.]

ale pak budete muset mit privatni klic (bez hesla) v tom initrd a to uz tam muzete mit rovnou to heslo k hard disku. a nebo nesifrovat vubec proste pokud chcete aby to nabootovalo bez vnejsiho zasahu (napr. zadani hesla operatorem) tak to nema cenu sifrovat a klicem na siti to neochcijete.

[Jendа]

Tak to si útočník potom může modifikovat ten initrd a přidat tam "echo $HESLO"

[j3nda]

to moc nemuze, je v planu to dat na server, kde bude omezen pristup. spis se jednalo o to, ze pokud by nekdo pocitac prenesl, tak z jine ip anebo umisteni geoIP to nebude fungovat a bude to mit centralni spravu ve stylu: povoleno/zakazano (narazim ted na archiv citlivych dat, ktere by nemel videt nikdo mimo provozovatele serveru).

[Bilbo]

To mi neprijde moc ucinne, je tam par dalsich moznosti jak to napadnout (napr. ukrast pocitac "vcetne IP" - napr. hacknout nejaky router po ceste, odposlechnout komunikaci, ukrast navic pocitac na kterem je to heslo, nebo ten pocitac upravit primo na miste (echo $HESLO), zapojit ho zpet, precist heslo a pak to cele odnest pryc ... muze byt tezke osetri uplne vse)

Mozna lepsi reseni je mit nezasifrovany /, na nem jen nezbytny zaklad (sshd + dmcrypt + nezbytne knihovny - to by se do 100 mb partition mohlo vejit ) - po restartu se admin prihlasi a heslo ke zbytku rucne naklofe. Pak je dobre asi mit detekci toho, jestli je server stale na svem miste a jestli se v nem nekdo mezitim nehrabal (pripojit usb kameru streamujici na druhy server (vyhoda je, ze od pripadneho zlodeje pak mame obrazek :) nebo nejaky watchdog, ktery pri pohnuti se skrini nebo jejim otevreni napr. premazne nejaky soubor, jehoz obsah admin pred psanim hesla zkouma)

Jinak archiv citlivych dat lze resit lepe, pokud je to archiv, ktery se moc casto necte, tak zasifrovat veci do nej pribyvajici GPG klicem - na serveru je jen verejny klic prosifrovani a privatni je fyzicky uplne jinde (napr. v adminove trezoru, admin si stahuje sifrovana data k sobe a tam si je desifruje dle potreby). I kdyz nevim k cemu se to bude pouzivat., takze mozna ze tahle metoda nepujde :)