Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Mirek Prýmek

Stran: 1 ... 204 205 [206] 207 208 ... 618
3076
Software / Re:Ověření funkčnosti velkých záloh
« kdy: 26. 04. 2016, 08:44:48 »
Ja nic otvarat nechcem, ja sa budem tvarit ako ostatne data :-) a cakat ... (A na pozadi testovat CRC)

A testovat navnadami budem to, co ma zaujima aby sa odzalohovalo
To jsme si asi nerozuměli. Představ si, že ransomware funguje tak, že každý soubor po uzavření zašifruje. Návnady se nedotkne, protože tu uživatel neotevře, ty nic nezdetekuješ a data máš v čudu. Proto říkám, že stejně jediná věc, na kterou se dá slušně spolehnout, je dobře nastavené zálohování. Různé ad hoc fígly jsou sice fajn, ale fungují jenom na nějakou množinu případů a můžou ti dát falešný pocit bezpečí. Mně přijde, že to nemá cenu a lepší je prostředky věnovat na lepší zálohování.

3077
Software / Re:Jak podepsat e-mail pomocí OpenSSL?
« kdy: 26. 04. 2016, 06:32:04 »
Chybí udělat ještě nějaký krok?

Tak zaprve samotny RSA klic nestaci. Musis k nemu mit certifikat a cele to zabalit do formatu  PKCS12, treba podle tohoto navodu: https://www.palantir.com/2008/06/pkcs12/

3078
Server / Re:TrueCrypt: bezpečnost používání přes SSH
« kdy: 25. 04. 2016, 19:11:36 »
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 :)

3079
Server / Re:TrueCrypt: bezpečnost používání přes SSH
« kdy: 25. 04. 2016, 17:57:30 »
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í.

3080
O serveru Root.cz / Re:Podpořte root, platební metody
« kdy: 25. 04. 2016, 16:13:08 »
Pro zajímavost – zatím ho využili přesně tři čtenáři.
To se dalo čekat :)

3081
Software / Re:Ověření funkčnosti velkých záloh
« kdy: 25. 04. 2016, 14:49:17 »
O nich samozrejme viem, ake maju CRC ...

Subor mozem testovat pri backupe (napr. na obed), alebo napr. planovanou ulohou cyklicky
To je sice fajn napad, ale porad tam mas hodne silny predpoklad (ransomware sifruje vsechno co najde a ne napr. otevirane soubory).

Podle me to proste nema smysl resit jinak nez transparentni zalohovaci politikou - proste se vyhlasi, ze garantujes zalohy treba rok zpetne s takovou a takovou granularitou a nic vic. Pokud nekdo rok na nejaky soubor nesahl, tak proste neni garantovano, ze ho dokazes obnovit. A pokud nejaka data potrebuji specialni zachazeni, je potreba to nahlasit a nasadit misto zalohovani archivaci.

3082
Software / Re:Ověření funkčnosti velkých záloh
« kdy: 25. 04. 2016, 14:42:15 »
Myslim ze ak clovek nasadi delta zalohy tak ta historia nebude vobec velka. Ako napriklad rdiff-backup. Nove data sa vytvaraju len urcitym tempom takze mnozstvo by malo byt proste X GB/tyzden.
Velikost je specificka pro dany pripad. X GB/tyden to muze byt pro normalni uzivatelska data krat neco kolem stovky uzivatelu. Pokud to jsou grafici nebo strihaji filmy, udela ti stejny objem klidne jeden clovek. A u zalohovani serveru to muze byt uplne jakkoli.

A pokud ty zalohy nemas prolinkovane, muze znamenat obnoveni rok stare zalohy obnovu padesati zaloh, coz neni nic prijemnyho... A pokud mas nejakou databazi zazalohovanych souboru (jako to ma napr. ten Bareos), poroste ti i ta.

A to je teda rec o tydenni granularite, takze v nejhorsim pripade muzes prijit o ctyri dny prace, coz taky neni uplne malo...

Ak bude clovek sledovat velkost takychto zaloh tak to bude aj detekcia ransomware pretoze ak v normalnej prevadzke mu to zalohuje 5GB za den a to zrazu vyskoci na 100GB tak je nieco zle. Samozrejme pruser bude ak sa ransomware nauci sifrovat len nove subory.
To je dobra poznamka, ale bohuzel u normalnich uzivatelu objem zaloh taky docela kolisa, takze pokud jich mas sto a jeden az deset z nich chytne ransomware, tak to nepoznas (kolisani do 10% je normalni).

3083
Software / Re:Ověření funkčnosti velkých záloh
« kdy: 25. 04. 2016, 14:28:02 »
Ten příkaz file zkoumá vždy obsah souboru, zda odpovídá příslušné struktuře, nebo se jen spokojí s koncovkou názvu a tím, že při nějaké koncovce uvnitř nenašel několik málo známých struktur?
Princip je popsaný na té odkazované man stránce.

Napadly mě ještě další dva způsoby, kromě specifických utilit na metadata.
- Zkusit soubor zkomprimovat, jak se zmenšil. Pokud je šifrovaný, nezmenší se. Jenže to nelze aplikovat na formáty které jsou vnitřně už komprimované.
- Zkusit soubor dekomprimovat. Specificky se to týká msoffice a openoffice formátů, což je přejmenovaný zip archiv.
Způsobů si můžeš vymyslet kolik chceš. Ale vždycky ti to bude fungovat jenom pro pár typů souborů. Nevidím moc smysl v tom, implementovat něco, co už existuje (detektor formátu) - je to vyhozená práce a uděláš to hůř než co už existuje.

3084
Software / Re:Ověření funkčnosti velkých záloh
« kdy: 25. 04. 2016, 14:14:53 »
P.S. téma máš nazvaný zavádějícím způsobem - pod "funkčností zálohy" se obvykle myslí to, že záloha jde obnovit (medium není poškozený, formát není zastaralý) případně že obsahuje to, co skutečně bylo na disku. Takže to není tvůj případ, ty nechceš obnovit to, co bylo někdy na disku, ty chceš obnovit soubor přesně před nějakou událostí (zašifrování) - o které dopředu nevíš, kdy se stane.

3085
Software / Re:Ověření funkčnosti velkých záloh
« kdy: 25. 04. 2016, 14:11:34 »
Tyjo, fakt hezký a praktický téma, dík za něj!

Bohužel myslím, že když si jasně rozmyslíš, co vlastně přesně chceš řešit, dojdeš na to, že se stoprocentní jistotou to řešit nejde.

Když si to tak vezmeš:

1. ransomware ti může jakýkoliv soubor zašifrovat kdykoliv
2. "korektnost" všech možných typů souborů nejsi schopný zkontrolovat

...tak z toho máš závěr, že buď musíš přijmout omezení na maximální stáří souboru nebo na velikost záloh nebo omezit množství formátů, pro které tu garanci chceš, nebo omezit jistotu, s jakou víš, že formát je v pořádku.

Pokud nechceš omezit stáří, musíš mít historii všech souborů až zpátky k jejich vzniku (=> potenciálně obrovské nároky na úložiště záloh, imho ve většině případů prakticky těžko realizovatelné).

Tu jistotu o korektosti formátu můžeš snížit třeba tak, že na všechny soubory spustíš normální file (http://man.he.net/?topic=file&section=all), který ti pro velkou část z nich správně určí typ obsahu a zároveň asi není úplně pravděpodobný, že by soubor by ransomware soubor zašifroval a zároveň zachoval hlavičku.

Jinak taky bys měl snižovat objem záloh pomocí nějaké usecase-specific deduplikace: skoro každý rozumnější zálohovací nástroj umí několik úrovní záloh - např. Bareos má Full, Differential, Incremental, tar má --level. Soubory, které se nezměnily od poslední zálohy stejného nebo vyššího levelu se znovu nezálohují. Pak taky existují různé nástroje, které pro nezměněné soubory používají hardlinky. Když tohle správně použiješ, můžeš historii slušně natáhnou za nízkého zvýšení nákladů. Pořád ale bude nějak omezená - kapacita nabývá nekonečná.

...no a pokud bys do toho chtěl jít fakt hardcore, tak můžeš mít nekončnou kapacitu pomocí nějakého "doufejme, že to nikdy nebudu potřebovat číst" řešení typu Amazon Glacier.

Prostě žádný silver bullet mě na tenhle problém nenapadá...

3086
Server / Re:Truecrypt pouzivani v terminau ssh bezpecne ?
« kdy: 19. 04. 2016, 19:22:31 »
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áš?

3087
Server / Re:Truecrypt pouzivani v terminau ssh bezpecne ?
« kdy: 19. 04. 2016, 19:00:12 »
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
Kód: [Vybrat]
ln -fs /dev/null /home/USER/.local/share/recently-used.xbel
Třeba to zafunguje a nebudeš to muset mazat :)

3088
Server / Re:Truecrypt pouzivani v terminau ssh bezpecne ?
« kdy: 19. 04. 2016, 18:43:13 »
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.

3089
Server / Re:Truecrypt pouzivani v terminau ssh bezpecne ?
« kdy: 19. 04. 2016, 18:26:20 »
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...

3090
Server / Re:Sendmail a Dovecot jako náhrada za Qpopper
« kdy: 19. 04. 2016, 13:47:31 »
Samozrejme mas pravdu, kdyz zvolis system, ktery je na toto nastaveny. Mozna jsi svoji poznamkou tazateli ukazall, na co by mel hned na startu myslet. Ja pouzivam distra, kde sice upgrady jdou udelat, ale nemam s nimi dobre zkusenosti, tak se jim vyhybam, coz zase prinasi prirozene zestarnuti systemu.
Chtel jsem tim rict, ze samotny ten mailovy soft zadnou vetsi udrzbu nepotrebuje. Samozrejme pokud si nekdo nainstaluje distro, ktere to cele znasilni - a v kazde verzi snasilnuje jinak, tak to pak je opruz. Ale s mailserverem jako takovym to moc nesouvisi.

Stran: 1 ... 204 205 [206] 207 208 ... 618