Dotaz: VPS a ochrana dat

[hujik]

Ahoj vsichni. Chtel bych se zeptat na Vas nazor na ochranu dat, kdyz provozujete server na virtualnim stroji u nektereho z poskytovatelu.

Jakym zpusobem zajistite, ze vas virtual provider nezkopiruje, nespusti nekde bokem, neprihlasi se do systemu a neukrade data? Jde to vubec zajistit. Napr. kdyz se pouziva standardni edice Ubuntu server na KVM.

---

---

Odpovědi

[marbu]

Jakym zpusobem zajistite, ze vas virtual provider nezkopiruje, nespusti nekde bokem, neprihlasi se do systemu a neukrade data?

Nijak.

[hujik]

To jako opravdu? Ani sifrovani by nepomohlo? Nechce se mi verit, ze lidi tohle neresi :-O

[pavlix]

To jako opravdu? Ani sifrovani by nepomohlo? Nechce se mi verit, ze lidi tohle neresi :-O

To je asi jako říct, že se ti nechce věřit, že lidi za polárním kruhem neřeší, aby byl v zimě co čtyřiadvacet hodin bílý den.

Proti některým útokům se dá dejme tomu jakžtakž bránit nebo je aspoň detekovat. Ale v případě, že má někdo v rukou celou tvojí infrastrukturu, je to jako bojovat s vlkem (klasickou) plácačkou na mouchy.

Jediná slušná ochrana je mít infrastrukturu „pod zámkem“, tedy fyzický server, fyzicky chráněný.

[Michal Ludvig]

Já bych to neviděl tak černě. 100% ochránit to nelze, ale je možné to ztížit...

1. Šifrování celého disku

2. Intrusion Detection System, třeba Tripwire

3. Samozřejmě standardní ochrany jako heslo v GRUBu, silná hesla, atd.

Tím lze docílit že se provozovatel nedostane do běžícího serveru. Pokud bude chtít se tam dostat tak ho bude muset restartovat a toho si všimneš. Když ho restartuje tak nebude mít heslo k filesystému, takže bude muset upravit tvůj initrd aby to heslo odchytil. Jenže jakmile zadáš heslo a nabootuješ tak Tripwire zjistí že někdo laboroval s initrd a se to hned dozvíš. Tohle by na "běžné šmírování" ze strany providera mohlo stačit. Sice přímo nezabráníš krádeži dat, ale alespoň se dozvíš že se něco děje.

Pokud ale bude ISP opravdu odhodlán tvá data tajně získat tak si vymyslí nějaký legitimní důvod pro reboot tvé VPS, podstrčí ti rootkit který Tripwire oblafne, atd. V extrémním případě vezme snapshot paměti a v něm si najde co potřebuje, ale to už se dostáváme do oblasti kde na stroji který není plně pod tvojí správou není moc obrany.

Účinnou obranou je na VPS nemít tak důležitá data aby tomu ISP stálo za to strávit moře času jejich získáním.

[Mrkva]

On se ale provozovatel nemusí nikam bourat, pokud je disk šifrovaný tak jednoduše klíč vyčte z paměti (ke které má přistup). Žádný restart není potřeba.

[Michal Ludvig]

Skoro bych se odvážil tvrdit, že vyčíst klíč z fyzické paměti, což je to k čemu má provozovatel přístup, nespadá do kategorie "jednoduše". Ale rád se nechám přesvědčit o opaku ;)

[pavlix]

Mno... já bych nerad, aby to zklouzko k tomu, že si každý zakonzervuje svůj počáteční názor a pak bude hledat každý i kdyby minimální argument ho podpořit.

Podle mě, je relativně složité (a drahé!) systém ochránit tak, aby stále ještě bylo relativně jednoduché z něj data získat.

Nejdřív bych si s tebou rád ujasnil, jak zajistíš zadávání hesla k tomu šifrovanému disku. Při úvahách nezapomeň na to, že se jedná o obyčejný VPS na nějaké běžné technologii a nemůžeš k systému přidávat žádné další HW zařízení.

[Michal Ludvig]

Tak ještě jednou - neříkám že data na VPS je možné 100% zabezpečit. Ale říkám že je možné jejich získání natolik ztížit že námaha potřebná na překonání těch překážek bude nepřiměřeně velká vzhledem k ceně těch dat.

Pokud na tom VPS bude jen pár na koleně spíchnutých PHP skriptů od Franty z Horní Dolní, tak je dostatečnou ochranou přihlašovací heslo, protože ačkoliv si Franta může myslet opak tak ty jeho skripty nikoho nezajímají. Pokud tam je něco z kategorie "to by mě docela zajímalo jak to je udělaný" tak může být dostatečnou ochranou šifrování, protože získat to heslo není nemožné ale je to netriviální a dost pravděpodobně to kolemjdoucího šmíráka odradí. Pokud ale na tom VPS bude databáze nějaké úspěšné firmy tak ta data dost možná budou mít takovou cenu že se konkurenci vyplatí investovat peníze do prolomení všech ochran. No a nakonec i v případě že nejde o untrusted VPS ale o tuze dobře zašifrované plány atomovky někde na notebooku tak pokud o ně někomu skutečně půjde tak se k nim dostane. Je známo že Rubberhose kryptoanalýza je poměrně účinná na prolomení libovolného šifrovacího algoritmu.

Takže řešit jak zadat to heslo je tady poměrně irelevantní. Míra dostačující ochrany dat závisí na jejich ceně. Čím zajímavější data tím těžší je je ochránit. Ale trvám na tom že pro pár php skriptů a soukromých mailů je běžné šifrování VPSky dostatečná ochrana bez ohledu na to že existuje tucet způsobů jak ji prolomit. Jen si člověk musí být vědom limitů tohoto zabezpečení aby nežil v omylu že je 100% chráněn.

[pavlix]

Tak ještě jednou - neříkám že data na VPS je možné 100% zabezpečit. Ale říkám že je možné jejich získání natolik ztížit že námaha potřebná na překonání těch překážek bude nepřiměřeně velká vzhledem k ceně těch dat.

Tak mi nezbývá než ti ještě jednou připomenout, že tvé srovnání je úplně zbytečné, protože v tvých úvahách úplně chybí cena a složitost samotného zabezpečení.

Takže řešit jak zadat to heslo je tady poměrně irelevantní.

To, že něco neumíš, ještě neznamená, že je to irelevantní.

[Filip Jirsák]

Ale trvám na tom že pro pár php skriptů a soukromých mailů je běžné šifrování VPSky dostatečná ochrana bez ohledu na to že existuje tucet způsobů jak ji prolomit.

Myslím, že šifrování je v tom případě zbytečně silná ochrana. Pokud mají správci dotyčné VPSky jako koníčka procházet disky zákazníků a hledat tam zajímavé e-maily, nebudu se bránit šifrováním, ale odchodem k jinému poskytovateli.

[Filip Jirsák]

Stačí udělat snapshot virtuálního počítače a ten si odnést. S tím už si pak dotyčný může dělat co chce, restartovat, číst, zapisovat, a majitel původního virtuálního počítače o ničem neví.

[Jendа]

Třeba qemu má na to v qemu-konzoli příkaz pmemsave, který ti paměť dumpne do souboru. Pak už na to stačí spustit aeskeyfind, nebo třeba rovnou forianu.

[Michal Ludvig]

Zajímavé, aeskeyfind jsem neznal. Předpokládal jsem že v dumpu fyzické paměti bude potřeba hledat key podle znalosti toho kam by si ho kernel měl uložit, ale netušil jsem že AES klíč v tom blobu lze najít hrubou silou. Díky za rozšíření obzorů :) Z readme aeskeyfind:

The program uses the following algorithm:
1. Iterate through each byte of the memory image.  Treat the following block of
   176 or 240 bytes as an AES key schedule.
2. For each word in the potential key schedule, calculate the Hamming
   distance from that word to the key schedule word that should have
   been generated from the surrounding words.
3. If the total number of bits violating the constraints on a correct
   AES key schedule is sufficiently small, output the key.

Jako ochranu před tímto druhem útoku by asi stačilo ten AES key schedule rozstrkat různě po paměti, aby nebylo všechno po hromadě. Zajímalo by mě jestli to tak novější jádra dělají když je tenhle útok známý?

Mimochodem co je 'foriana'? Nic relevantního s tímhle jménem nemůžu najít...

[Jendа]

Jako ochranu před tímto druhem útoku by asi stačilo ten AES key schedule rozstrkat různě po paměti, aby nebylo všechno po hromadě.

K tomu pak právě lze použít ta Foriana, na složení zpátky :).

Mimochodem co je 'foriana'?

Druhý odkaz z Googlu, ale možná mě bublinkují.

[Michal Ludvig]

Druhý odkaz z Googlu, ale možná mě bublinkují.

Já mám tenhle odkaz až na druhé stránce výsledků. Možná v tom hraje roli i regionální cílení - od vás je SK celkem za rohem, ode mě celkem ne, tak mi Google SK odkazy nedává. Kdo ví. Ale dík za link.

[Bilbo]

Google už nějakou dobu "personalizuje" výsledky, takže návody typu "je to druhý odkaz v googlu" přestávají fungovat, pokud je člověk v jiném regionu, má nastavený jiný jazyk, případně je přihlášený jako jiný uživatel (kdo ví co všechno se k tomu používá ...).

[Bilbo]

Jako ochranu před tímto druhem útoku by asi stačilo ten AES key schedule rozstrkat různě po paměti, aby nebylo všechno po hromadě. Zajímalo by mě jestli to tak novější jádra dělají když je tenhle útok známý?

Jsou přístupy kdy dešifrovací klíč v paměti není vůbec - klíč je držen pouze v cache procesoru, odkud je o něco těžší ho získat. Viz. http://frozencache.blogspot.com/.

Ale to může pomoci jen u některých útoků na fyzické počítače (např. u podchlazení a vyndání RAM z běžícího stroje tam pak ten klíč jaksi nikde není) a je to za cenu značné ztráty výkonu (cache obsahuje klíč a nelze ji využít na to k čemu byla původně určena).

Je to omezeně použitelné asi jen v okrajových případech (např. při uspávání notebooku přemístím klíče do cache).

U útoků kdy útočník může i zapisovat do paměti to pak nepomůže vůbec (dát někam do paměti kód který to z cache vykopíruje zpět do paměti na místo kde se rychle spustí je vcelku jednoduché)

U VPS kde udělat snapshot paměti (včetně cache/registrů procesoru) je vcelku triviální (někdy jsou i nástroje na stěhování "živých" virtuálů na jiné fyzické stroje a udělat z toho nástroj na kopírování stroje do sandboxu, kde je následně zapauzován a hacknut je jednoduché)

Mimochodem co je 'foriana'? Nic relevantního s tímhle jménem nemůžu najít...

http://hysteria.sk/~niekt0/foriana/

[Jendа]

a je to za cenu značné ztráty výkonu (cache obsahuje klíč a nelze ji využít na to k čemu byla původně určena)

Šlo to nějak ohackovat přes AES-NI, kde na udržení stavu šifry stačily nějaké debug registry a cache tak nebylo potřeba zamykat.

Na kolikátém místě jsi měl ten odkaz? Pokud níže než na druhém, tak toho o mě Google ví nějak moc.

[Bilbo]

Na kolikátém místě jsi měl ten odkaz? Pokud níže než na druhém, tak toho o mě Google ví nějak moc.

Na třetím ...

[pavlix]

Jsou přístupy kdy dešifrovací klíč v paměti není vůbec - klíč je držen pouze v cache procesoru, odkud je o něco těžší ho získat. Viz. http://frozencache.blogspot.com/.

Zdá se mi to, nebo tím už jsi úplně mimo kontext VPS?

[Jendа]

To si v dalším odstavci IMHO uvědomuje.

RFT: na kolikátém místě v Googlu máš na dotaz "foriana" tu stránku, o které se bavíme?

[d'areback]

Ja mam hysterku na prvnim miste, ale myslim si, ze to je priznak toho, ze o mne vi ho..uby.

[Jendа]

Hmm, já na druhém.

(Why so curious? Zajímalo mě, zda z toho lze vyčíst, že Google ví o mých interakcích s autorem. Nepotvrdilo se, když to i ostatní mají nahoře.)

[d'areback]

Vytvoril jsem na ubuntu na skoro nikym nepouzivane ip adrese noveho uzivatele a pripojil se pres high anonymouse ruskou proxy (takze google videl jen to, ze prostredi je cz - aspon doufam:) a hysterka na prvnim miste.

[Jendа]

Já furt na druhém. Spíš jsem se děsil toho, že to ostatní budou mít někde daleko. OK.

takze google videl jen to, ze prostredi je cz - aspon doufam

Panopticlick znáš? :)

[d'areback]

Ale jo. Prave proto jsem udelal i pokus na tom ubuntu - ten nikdo na brouzdani nepouziva. Ja se zas pred googlem nijak cilene neschovavam (protoze verim, ze nejde po mne, ale po vsech :))

[pavlix]

Druhém. Ale jsem v Česku :). Navíc je to ojedinělý odkaz, takže si jeho stoprocentní vyhledatelností nejsem zdaleka jistý.

[pavlix]

A mám G+, a mám tam přidané kdejaké linuxáky.

[Jendа]

Díky, moje paranoia tím trošičku opadla. (ale jen trošičku!)

[pavlix]

Jsi o krok vepředu. Řešíš situaci, kdy je disk už šifrovaný, takže ti Michal právem řekl, že číst RAM je relativně složité. Důležité je ale oproti čemu.

Takže pro začátek jsem zvědavý na robustní řešení toho šifrování. Konkrétně předání klíče k rozšifrování disku. Viz výše.

[pavlix]

Tím lze docílit že se provozovatel nedostane do běžícího serveru.

Erm... nemá náhodou run-time k dispozici celý obraz RAM? Vzhledem k tomuto faktu mi přijde celý zbytek příspěvku tak nějak prázdný.

[marbu]

Sifrovani by pomohlo jedine v pripade, ze se data na vps nahraji uz zasifrovana aniz by na vps byl klic, coz trochu omezuje vyuziti takovych dat (jde tak resit maximalne zalohy nebo sdileni).

[Filip Jirsák]

Když to budete mít na fyzickém železe, taky tam můžete mít procesor, který při dešifrování uleje klíč někam bokem, můžete tam mít vylepšenou paměť, která svůj obsah včetně dešifrovacího klíče umí na tlačítko vysypat na vloženou flashku, můžete mít místo disku utajený RAID1, ze kterého si může poskytovatel kdykoliv jeden disk odnést. Jediný rozdíl je v tom, že cinknout virtuální stroj bude jednodušší, než cinknout procesor.

[MMMMMMMMM]

Databázi nijak chráněnu nemám, ale třeba PHP skripty mám na produkčním serveru (VPS) zkompilovány pomocí bcompileru a pokud vím, dekompiler (zatím) neexistuje.

[d'areback]

Odkazovat boleveckeho podivina z tebe dela profesionala na zvasty a diletanta na ciny, to si zapamatuj.

[chinook]

A nemyslíš si, že by toto udělali v datacentru pouze jednou a pak skončili v tomto byznyse? Podle mě, už toto je trochu paranoa.

[pavlix]

Nemyslím. Podle mě to stačí korigovat s realitou a zjistíš, že to není pravda.

[Stanislav Petr]

Samozrejme ze to neni zadnej problem. Staci disk toho VPS sifrovat - napr. pouzit LIKS. Nechapu proc tu dvacet lidi resi takovou trivialitu a tvrdi ze to nejde. Nekteri zakaznici to u nas takhle celkem bezne provozujou.

[Jendа]

Nechapu proc tu dvacet lidi resi takovou trivialitu a tvrdi ze to nejde.

Třeba protože před pár měsíci dostali za úkol otestovat, jak složité jer prolomit se do takové zašifrované VPS, a trvalo jim to pár minut? ;)

[JanM]

Pokud to nebylo jen blafování (vějička na oběti), tak by se možná jednalo o ideálního poskytovatele VPS, data budou v bezpečí

[Filip Jirsák]

Když tady dvacet lidí tvrdí, že to nejde, a vy přijdete s opakem, mohl byste napsat aspoň náznak toho, jak to uděláte – kde se vezme dešifrovací klíč, kde bude uložený za běhu virtuálního stroje, jak se s ním bude pracovat.

[pavlix]

Samozrejme ze to neni zadnej problem.

Pán je těžké king :D.

Staci disk toho VPS sifrovat - napr. pouzit LIKS.

Zřejmě LUKS? Jak zákazníci zadávají heslo? Jak se zákazníci brání odposlechu toho zadávaného hesla?

Jenom kecy.