Fórum Root.cz
Hlavní témata => Server => Téma založeno: CryptoGuru 19. 04. 2016, 18:07:09
-
Zdravim
Je tady jedna otazka, a to dalkove vyuziti truecryptu - zdali je to bezpecne. V pripade lokalniho pouzivanije Truecrypt relativne bezpecny. V pripade windows je tu hlavne nebezpeci softwarovych a hardwarovych keyloggeru coz plati i pro Linux. V Linuxu se otevrene TC kontejnery navic objevuji jako nedavno pouzite soubory, stejne tak i keyfiles - dira jako brno.
Jak je to ale s textovym rezimem. Na Linuxovem stroji je vice uzivatelu a ja chci namontovat prez terminal TC disk, a to i s pouzitim ssh od vzdaleneho mista. To samozrejme vyzaduje zadani hesla do terminalu, keyfiles pouzity nejsou a pokud se odchyti, jaky partition je zasifrovan, nevadi. JE TO BEZPECNE NEBO MUZE NA VZDALENEM STROJI CI NEKDE PO CESTE NEKDO ODCHYTIT HESLO ? Root prava ma vic uzivatelu.
Rizika: Prolomeni hrubou silou zapomenme, softwariove hardwarove keylogery na me strane take. ssh tunel je sifrovany a tedy by nemeli jit data odchytit. Hesla do Linuxu se uladaji v hash, take jdou zmenit, ne uhadnout. Jedinou moznsti je odchyceni hesla pri psani ci prenaseni na konzoli (jak pri vstupnim tak na cilovem stroji) - jde nejak nekym od nekud odchytit co pisi na konzoli ? Jak vychozi tak cilovy stroj i cesta mezi stroji (MIM).
Z auditu vime, ze pokud jeden uzivatel namontuje disk, muze k nemu nekdo jiny. Ale o to nejde - spis mechanizmus tvorby hesla je unikatni.
-
Je tady jedna otazka
Tady? Tady žádná otázka není. Myslíš tam?
V Linuxu se otevrene TC kontejnery navic objevuji jako nedavno pouzite soubory, stejne tak i keyfiles - dira jako brno.
Ne "v Linuxu", ale maximálně tak možná v nějakém konkrétním DE nebo programu.
Jedinou moznsti je odchyceni hesla pri psani ci prenaseni na konzoli (jak pri vstupnim tak na cilovem stroji) - jde nejak nekym od nekud odchytit co pisi na konzoli ?
Coby CryptGuru bys měl vědět, že pokud má někdo roota na stroji ze kterého nebo na který se přihlašuješ, může dělat cokoli. Včetně pozměnění binárky ssh.
JE TO BEZPECNE NEBO MUZE NA VZDALENEM STROJI CI NEKDE PO CESTE NEKDO ODCHYTIT HESLO ?
1. máš zaseklý caps lock, zkus to spravit nožem
2. Nic jako "bezpečné" nebo "nebezpečné" neexistuje. Existuje jenom "zranitelné" nebo "nezranitelné" konkrétním typem útoku.
Z auditu vime, ze pokud jeden uzivatel namontuje disk, muze k nemu nekdo jiny.
Audit se asi nezmínil o tom, že pro mount existují volby uid a umask...
-
V Linuxu se otevrene TC kontejnery navic objevuji jako nedavno pouzite soubory, stejne tak i keyfiles - dira jako brno.
Ne "v Linuxu", ale maximálně tak možná v nějakém konkrétním DE nebo programu.
V Ubuntu to takto je - ale vim kde promazat.
Jedinou moznsti je odchyceni hesla pri psani ci prenaseni na konzoli (jak pri vstupnim tak na cilovem stroji) - jde nejak nekym od nekud odchytit co pisi na konzoli ?
Coby CryptGuru bys měl vědět, že pokud má někdo roota na stroji ze kterého nebo na který se přihlašuješ, může dělat cokoli. Včetně pozměnění binárky ssh.
[/quote]
[/quote]
Nejde ze by nekdo umyslne menil binarky primo v systemu, jde mi spis o diry obecne na cele ceste.
-
V Ubuntu to takto je - ale vim kde promazat.
V nějakém konkrétním DE nebo programu to tak možná je.
Nejde ze by nekdo umyslne menil binarky primo v systemu, jde mi spis o diry obecne na cele ceste.
Prostě pokud má někdo roota na zdroji nebo cíli, nemusíš už nic jiného řešit. V takovém případě prostě žádnou bezpečnost ničeho nezajistíš. Takže jestli chceš řešit odolnost něčeho proti nějakému útoku, napiš přesně čeho a proti jakému útoku.
-
Nepredpokladam schvalnosti od roota, ptal jsem se na bezpecnost na ceste (z meho PC internetem do jineho PC, navic i prez VPN). Nikdy jsem to na dalku nedelal. Root si samozrejme teoreticky muze delat co chce, to je jasne.
To je jako u vetsiny mail serveru - admin je muze cist. U tech special. mail serveru nikdo nevi nebot nemame zdrojaky (admin cist muze ci nemuze, tot otazka).
A co se tyce zaznamu pouziti souboru - pouzivas kontejner nebo disk partition, pouzivas keyfiles, pouzivas graficky nastroj TC ?
Prohlidni si soubor /home/USER/.local/share/recently-used.xbel
-
Nepredpokladam schvalnosti od roota, ptal jsem se na bezpecnost na ceste
MUZE NA VZDALENEM STROJI [...] NEKDO ODCHYTIT HESLO ? Root prava ma vic uzivatelu.
Nikdy jsem to na dalku nedelal.
Taky jsem to nikdy nedělal na dálku.
A co se tyce zaznamu pouziti souboru - pouzivas kontejner nebo disk partition, pouzivas keyfiles, pouzivas graficky nastroj TC ?
Používám to, co je vhodné pro daný účel.
Prohlidni si soubor /home/USER/.local/share/recently-used.xbel
Fascinující! :)
Zkus
ln -fs /dev/null /home/USER/.local/share/recently-used.xbel
Třeba to zafunguje a nebudeš to muset mazat :)
-
Mirek
Diky ale nevim co a jak myslis vazne.
Jinak o tom recently-used.xbel moc lidi sutecne nevi a podobnych srand je tam vic.
Jinak asi bych mel konkretizovat, kde cekam diru:
1. Prebootovani nebo nainstalovani jineho operacniho systemu ci jine verze Linuxu. Ve skole se to obcas totiz necekane stane.
2. Ulozeni paneho textu (tedy i hesla) do souboru typu bash_histrory.
3. Man in the middle attack.
4. Deravost putty
-
Diky ale nevim co a jak myslis vazne.
Všechno myslím vážně. Čestný skautský, že na dálku jsem to nikdy nedělal!
Jinak o tom recently-used.xbel moc lidi sutecne nevi a podobnych srand je tam vic.
To bude asi tím, že to nikomu nevadí. Pokud chci zatajit nějaká data, šifruji celý disk a neřeším střípky sem a tam. Způsobů, jak můžou informace leakovat, je příliš moc než abych je řešil takhle jednu po druhé.
Jinak asi bych mel konkretizovat, kde cekam diru:
1. Prebootovani nebo nainstalovani jineho operacniho systemu ci jine verze Linuxu. Ve skole se to obcas totiz necekane stane.
2. Ulozeni paneho textu (tedy i hesla) do souboru typu bash_histrory.
3. Man in the middle attack.
4. Deravost putty
To jsme rádi, že to víme. A otázku nějakou máš?
-
Hm, jak se dela MiTM attack na ssh, zejmena, kdyz mam na druhe strane svuj klic?
-
Blbě. ;D
-
No prave.
-
Všechno myslím vážně. Čestný skautský, že na dálku jsem to nikdy nedělal!
No prave z Tvych odpovedi to vyzniva ruzne.
To bude asi tím, že to nikomu nevadí. Pokud chci zatajit nějaká data, šifruji celý disk a neřeším střípky sem a tam. Způsobů, jak můžou informace leakovat, je příliš moc než abych je řešil takhle jednu po druhé.
Vetsene lidem to skutecne nevadi, nebot vyblejou o sobe na FB i co maji k veceri a pod. Nad ukladani historie prohlizecu i praci se soubory nepremisli. Sifrovat cely disk je zase nekdy komplikovane.
Hm, jak se dela MiTM attack na ssh, zejmena, kdyz mam na druhe strane svuj klic?
Asi dost tezko, ale nejsem si jisty, prave proto jsem se ptal.
-
Hm, jak se dela MiTM attack na ssh, zejmena, kdyz mam na druhe strane svuj klic?
Asi dost tezko, ale nejsem si jisty, prave proto jsem se ptal.
Tak dovedl bych asi vypotit scenar MiTM utoklu na server, kdyz nepouzivam klice a kdyz jsem se na ten server jeste nikdy nepripojil. Pokud ale mam klice na vzdalenem serveru, tak mi fantazie selhava. A pokud jsem se na ten server jiz nekdy pripojil, tak na me ssh zarve, ze se zmenil fingerprint nebo tak nejak a jestli jako jo nebo radsi ne. A tusim jde i nastavit, ze pri zmene fingerprintu se spojeni natvrdo ukonci.
-
Vetsene lidem to skutecne nevadi, nebot vyblejou o sobe na FB i co maji k veceri a pod. Nad ukladani historie prohlizecu i praci se soubory nepremisli.
Ne. Právě lidi, kteří chtějí data chránit a něco o tom vědí, nevymýšlejí krávoviny a přijímají účinná opatření.
Sifrovat cely disk je zase nekdy komplikovane.
Šifrovat celý disk je triviální a je to jediné rozumné opatření.
-
Šifrovat celý disk je triviální a je to jediné rozumné opatření.
Uz dlouho jsem neinstaloval zadne distro Linuxu, tak nevim, jak se k tomu stavi typicky instalator. Uz se da naklikat, ze to chci instalovat s sifrovanim celeho disku, vcetne swapu? Kdysi nic takoveho instalatory nenabizely a rozchodit to byval dost opruz. Krome toho je tu porad problem s tim, ze sifrovani zere vykon, takze je otazka, jestli ten vykon mas a nepotrebujes ho na jine veci. Nekdy je asi lepsi mit dva stroje, na jednom delat na vykon narocne neprilis tajne zalezitosti a na druhem mit detske porno, plany na vyhozeni Bileho domu do luftu a tajny recept na babovku po babicce. Nebo mit na stroji dve distra, jedno pro privatni veci se sifrovanim, TORem a tak, druhe nesifrovane a nikdy nemontovat oddily druheho distra z toho, ktere zrovna bezi.
-
...
Při instalaci nevím, instaluju debootstrapem a tam problém nikdy nebyl.
Scrub na šifrovaném disku, tedy nejen dešifrování, ale i parsování souborového systému a počítání checksumů, mi na i3-2350M (tedy dnes už spíš low-end) jede 260 MB/s.
-
tak nevim, jak se k tomu stavi typicky instalator.
Takhle: https://www.eff.org/files/images_insert/ubuntu_crypto1.png a už drahně let.
Krome toho je tu porad problem s tim, ze sifrovani zere vykon
Zaprvé, s AES-NI to nepoznáš a za druhé si prostě musíš vybrat - buď chceš být paranoidní a něco tě to stojí, nebo nechceš.
Nekdy je asi lepsi mit dva stroje, na jednom delat na vykon narocne neprilis tajne zalezitosti a na druhem mit detske porno, plany na vyhozeni Bileho domu do luftu a tajny recept na babovku po babicce. Nebo mit na stroji dve distra, jedno pro privatni veci se sifrovanim, TORem a tak, druhe nesifrovane a nikdy nemontovat oddily druheho distra z toho, ktere zrovna bezi.
Vzhledem k tomu, že tazatel řeší i naposledy otevřené soubory, tak nejspíš s ničím jiným než plány na vyhození Bílého domu do povětří nepracuje :)
-
Vzhledem k tomu, že tazatel řeší i naposledy otevřené soubory, tak nejspíš s ničím jiným než plány na vyhození Bílého domu do povětří nepracuje :)
Tak pokud jde o to, aby se manzelka nemohla podivat, jestli prez ssh necumnel na porno, tak napriklad v LXDE by tohle nebyl problem. Pokud vim, tak posledni otevrene soubory jsou ulozeny na kazde FS extra, takze kdyz napriklad odmontuju EcryptFS, tak soubory, ktere jsem z nej otevrel, ze seznamu poslednich souboru zmizi a znovu se objevi, kdyz EcryptFS zase namontuju. Predpokladam, ze v pripade TrueCryptu by se to chovalo stejne. Je mozne, ze jine DE to resi nejak blbe a soubory v seznamu stale visi, i kdyz dany FS neni k dispozici. A v ciste textovem prostredi snad ani nic jako posledni otevrene soubory neexistuje.
-
Krome toho je tu porad problem s tim, ze sifrovani zere vykon
Zaprvé, s AES-NI to nepoznáš a za druhé si prostě musíš vybrat - buď chceš být paranoidní a něco tě to stojí, nebo nechceš.
Pri bezny praci to nepoznas ani bez AES-NI. Ani pri kopirovani velkych souboru se nedostanes pres nejakych 40% na hodne starym CPU (C2).
-
Nebo mit na stroji dve distra, jedno pro privatni veci se sifrovanim, TORem a tak, druhe nesifrovane a nikdy nemontovat oddily druheho distra z toho, ktere zrovna bezi.
Dve distra nepomozu ovela viac ako 2 uzivatelske ucty + ACL. Predpokladam, ze by data niekoho zaujimali.
Ked niekto v jednom distre ziska roota, moze lahko zabackdoorovat dotaz na heslo a dostane sa aj do druheho distra. Tuto separaciu poskytne aj ACL.
-
Ked niekto v jednom distre ziska roota, ...
Tak jiste, holt se musite snazit, aby Roota neziskal. Slo mi o to, aby v distru s tajnym obsahem nemohl nekdo vycucnout obsah disku a hledat kousky dat ze swapu nebo docasnych souboru. Pokud se chcete pripravovat na tu nejhorsi eventualitu, tak ziskani roota neni jedina moznost. Oni to z vas take muzou vymlatit kusem vodovodni trubky.
-
Ked niekto v jednom distre ziska roota, ...
Tak jiste, holt se musite snazit, aby Roota neziskal. Slo mi o to, aby v distru s tajnym obsahem nemohl nekdo vycucnout obsah disku a hledat kousky dat ze swapu nebo docasnych souboru. Pokud se chcete pripravovat na tu nejhorsi eventualitu, tak ziskani roota neni jedina moznost. Oni to z vas take muzou vymlatit kusem vodovodni trubky.
Tak to je nejvhodnější asi Whonix v KVM nebo Virtualboxu a pro jistotu ještě zašifrovaný v kontejneru... :-).