Jak se zbavujete starých disků? (diskuse)

[R]

Tiez som nasiel niekolko vyhodenych PC aj s datami. Pripadne obcas dostanem vyradene firemne PC. Disk prepisem nulami (dd if=/dev/zero of=/dev/sdX bs=1M), urobim novu instalaciu OS a PC predam.

[Bherzet]

Pro větší jistotu bych raději volil několikanásobný přepis náhodnými daty. Po jedné iteraci přepisu nulami z toho v domácích podmínkách obnovit nepůjde nejspíš nic, ale kdyby na tom někomu hodně záleželo, prolomit to za určitých podmínek lze (alespoň u magnetického disku, u SSD nevím). Samozřejmě ale záleží na citlivosti těch uložených dat, v praxi ten tvůj postup bude většinou zcela dostatečný. Citlivá data by navíc měla být šifrovaná a pak by na té likvidaci tolik záležet nemělo (byť je to samozřejmě lepší).

[aaa]

Vícenásobný přepis netřeba. Je to urban legend. Viz https://www.howtogeek.com/115573/htg-explains-why-you-only-have-to-wipe-a-disk-once-to-erase-it/

[Bherzet]

Bral jsem to hlavně tak, že opětovným přepisem se sníží pravděpodobnost, že disk ta data nepropíše vůbec aniž by zahlásil chybu. Náhodná data bych volil proto, že pokud by přecejen někdo uměl (draze, složitě a se speciální technologií) obnovit i přepsaná data, tak s celým diskem přepsaným stejnou hodnotou bych čekal, že to bude mít snažší. Ale nevím, možná se pletu.

[Gilhad]

No, nebral bych to az tak doslova - ten clanek citovany citovanym clankem tvrdi, ze 35x prepisovat u modernich disku netreba, ze vetsinou docela staci 1x-2x jako ochrana proti teoretickemu utoku ctenim zbytkoveho magnetizmu, z cehoz citovany clanek vyvodi, ze vicenasobne prepsani jen vzbuzuje falesny pocit bezpeci, zvlaste kdyz je takrka nemozne najit 10KB citlivych dat v 200GB bordelu. S timto vyvodem bych nesouhlasil:

- najiti tech 10K pomoci nejakeho programu zase neni tak neresitelne - pomerne snadno se da odfiltrovat "znamy" bordel (treba standardni soucasti windows a obecne pouzivanych programu), stejne tak se daji naopak z toho zbytku vyfiltrovat "podezrela data" a pak se prednostne zabyvat jimi

- IMHO to, ze "vetsinou staci 1x-2x"implikuje, ze v te dobe by to v ojedinelych pripadech stacit nemuselo - i kdyz cas pokrocil, stejne bych rekl, ze 2x ruznymi daty da o nepatrny zlomek vetsi sanci i dnes (cili neni to zcela zbytecne, jen je to vetsinou zbytecne nakladne, protoze vetsinou tam ta data stejne nikdo fakticky nehleda tak drahymi metodami)

- za "pocit falesneho bezpeci" bych povazoval metodu, ktera ackoli slibuje nejaky bezpecnostni efekt, tak ho neposkytuje (napriklad prelepeni disku nalepkou "Neopravnene nakladani daty se tresce dle zakona"), nikoli metodu, ktera poskytne slibovany efekt za nikoli nejnizsi moznou cenu (zbytecne 2. ci 3. prepsani disku zajisti ze prepsana data nepujdou cist, stejne jako asi nesla cist ani po 1. prepsani.)

- "pocit falesneho bezpeci" naopak muze byt prepsani disku daty jednou a vira, ze uz zadna citliva data nehohou uniknout - vzhledem k tomu, ze moderni disky premapovavaji poskozene sektory a nahrazuji je rezervnimi, tak nekde v poolu poskozenych a odmapovanych sektoru ta data porad jeste mohou byt a opakovanym ctenim se dat vytezit (ana, sance, ze tam budou je mala, sance, ze to nekdo bude delat je jeste mensi a to jeste muze ten sektor byt poskozeny k necitelnosti, ale porad to neni jistota, ze se to nemuze povest) - takze pokud jde o opravdu citliva data, tak je potreba zlikvidovat i tyto oblasti (tedy idealne mechanicky).

Osobne stejne disky po 4 nasobnem prepsani (standardni badblocks) rozebiram na soucastky a plotny mechanicky poskodim ackoli tam asi zadna prilis citliva data nemam (ktera by nemel uz nekdo jiny - banka, ISP, statni urady - a tamni lidsky faktor neovlivnim a iluze o nem si nedelam ...), ale to je jina pohadka.

[marbu]

Jo, tohle není případ falešného pocitu bezpečí, ale overkill řešení. Jedno přepsání by mělo bohatě stačit. Viz: Is Data Remanence a Myth? odkazované z wikistránky k tématu bezpečného mazání dat na archlinux wiki.

Pokud ale chci řešit i případy realokace sektorů, jak je interně provádí disk sám, tak jediné řešení je ten disk od začátku šifrovat. Pak i kdyby ve firmware toho disku byla speciální feature co v datech hledá zajímavé patterny a odkládá je na uživatelsky nepřístupnou oblast, třeba i relativně velkou zhledem k celkové kapacitě disku, můžu být v klidu, protože disk pracuje pouze ze šifrovanými daty. Na druhou stranu rešit takový případ vícenásobným přepisem nejde. Ale tohle je extrémní případ :) Viz. manpage wipe(1)

[Josef Kufner]

Ten článek zmiňuje 35 přepisů v kontextu kódování dat na disku, kdy se to přepisuje tak, aby to mělo co nejničivější vliv na kódování, kterým jsou data na disku uložena – viz paper odkazovaný v článku.

Před pár lety jsem četl o tom, jak někdo zkoušel přečíst několikrát přepsaná data a dařilo se jim rekonstruovat několik přepisů přes sebe díky tomu, že hlavičky nelítají nad stopama úplně přesně a na okrajích stop zůstávají stará data. Na takové čtení vsak museli přeprogramovat či nahradit elektroniku disku – hlavičky a mechanika zůstala stejná, takže v domácích podmínkách to realizovatelné bylo, i když značně náročné, co se znalostí a schopností týče.

[pc2005]

Jinak u šindelovejch disků ty okraje zápsaných dat řeší poměrně efektivně. Spíš bych se u moderních disků bál o obsah různých cache (ať už NAND pro šindele nebo rovnou SSHD tak i třeba cache na samotném disku, kde se data zapisují do oblasti na začátku disku, která má rychlejší přístup).

[Ovoce]

Ten problém s remapovanými bloky asi vyvstane když přepisujete z OS, ale diagnostické utility od výrobců disků mají vlastní přepisovací funkci, ta by mohla asi pokrývat i tyhle bloky (ale jistě to nevím, můžete jim poslat dotaz...).

Jinak pokud člověk tohle tak moc řeší, tak by mohly být řešením disky s krypto mazáním - tj. jsou pořád interně zašifrované s nějakým uvnitř uloženým heslem, a při povelu ke smazání se akorát zahodí ten klíč. Není to kompletní zničení, ale pokud neukrýváte souřadnice tajné základny Hitlera...

[R]

Inak nefunkcne a neopravitelne disky rozoberiem, platne dam na nastenku, elektroniku odlozim (na pripadnu opravu ineho disku alebo na suciastky) a zvysok vyhodim.

[_]

"Hrabal jsem v něčím odpadu a ten nezodpovědný člověk v něm měl citlivé informace"

[Sandokan]

V práci likvidujeme staré disky fyzicky, jelikož máme několik elektrických tavících pecí na tvárnou a šedou litinu. Je to jednoduché a spolehlivé, ale není to zrovna obvyklý způsob.

[regine]

Rozšoubuji (asi do 5 minut), vyndaný disk buď rozkřápnu (skleněné) nebo kovové na betonu pomlátím kladivem. Zkrátka nevlastníme v Česku jaderné zbraně. Top Secret - Cosmic Top Secret.

[pc2005]

Nijak, i IDE disky se dají použít jako dočasný disk. I kdyby byl odpálený tak se hodí na aspoň součástky.

[Max]

Disky po životnosti (SCSI, IDE apod.) jdou pod kladivo/šroubovák(=poškrábání ploten), rychlé a no problemo. Ze SCSI disků jsme ještě vymontovávali magnety, protože ve SCSI byly fakt silný.
SATA disky, když jdou na reklamaci, tak se přepíšou nulama (teorie o hledání nějakých mezí v magnetickém poli buněk platila možná kdysi, když měly malou kapacitu, dnes už je to nemožné z toho něco kloudného dostat).
Disky z pole jdou na reklamaci rovnou, protože tam se opravdu nebojím, že by to někdo složil (a né, opravdu RAID1 nepoužíváme).
Pokud jde o SATA disky z desktopů, tak když je tam sebemenší závan ve SMARTu, tak jdou pod kladivo, i když se třeba tváří sebe líp. Je to prevence a uživateli jde rovnou SSD. Aktuálně máme tak polovinu kancelářských PC na SSD (námi dodaný Crucial, nebo HP či Lenovem dodaný SSD), disků vyměníme takto preventivně asi 30ks ročně.
Zdar Max
PS: jinak všechen elektroodpad jde na svoz + potvrzení o likvidaci, servery jdou taktéž, ale přes jinou firmu, která nám za to i něco málo zaplatí (ta pro změnu nechce ledničky, zářivky apod.)

[trekker.dk]

Disky z pole jdou na reklamaci rovnou, protože tam se opravdu nebojím, že by to někdo složil (a né, opravdu RAID1 nepoužíváme).

Složil asi ne, ale krátké soubory, ve kterých jsou klíče/hesla by tam mohly být celé.

[Max]

To jako že máš RAID10 nad 12 diskama, celé to máš naformátěný nějakým FS a když vyndáš jeden disk z pole, tak z toho disku jsi schopen něco přečíst? Tomu moc nevěřím.
Zdar Max

[Vantomas]

Myslím, že RAID a jeho stripe size bude ten problém. Na každém daném disku je vždy třeba 128kB souvislých dat. Pokud by měl někdo heslo uložené v plaintextu, tak to lze opravdu přečíst i z jednoho disku.

Ale ty pravděpodobnosti a to, zda tím chce někdo ztrácet čas... 🤷

[xkucf03]

Pokud víš, kam firma XY vyhazuje disky a automatizuješ si to, tak se ti dříve či později „poštěstí“, aniž by tě to stálo nějak moc práce.

Mně tohle prostě přijde paradoxní – v souvislosti s tím, na jak často i hodně nepravděpodobná rizika se firmy připravují a stresují kvůli nim – a pak si nepohlídají takhle primitivní únik.

[xkucf03]

BTW: jinak se tomu taky říká trashing – prohrabávání se v cizích odpadcích. Dá se toho tak získat a pak poskládat dohromady opravdu hodně. Ne, že bych se zkoušel hrabat v cizí popelnici, ale zkoušel jsem víc přemýšlet o tom, co vyhazuji a jakou informaci to nese… a pak jsem si pořídil skartovačku.

[trekker.dk]

Myslím, že RAID a jeho stripe size bude ten problém. Na každém daném disku je vždy třeba 128kB souvislých dat.

Přesně tak. Do toho stačí započítat, že FS data ukládá od začátku "sektoru" a třeba takové klíče uložené v PEM formátu mají jasně a snadno identifikovatelnou hlavičku.

Vzhledem k tomu, jak snadné je disk aspoň jednou přepsat, což odfiltruje snahy 99.9% šmoulů, co se hrabou v elektroodpadu, nevidím jediný důvod to neudělat.

[Max]

Disk, co jde na reklamaci, těžko přepíšu nulama. A ty, co jdou do šrotu, jsem psal, že jdou nejdříve pod kladivo.
Nejlepším řešením je samozřejmě šifrovat, ale ten overhead se nemusí vůbec vyplatit. Každopádně my to máme tak, že nemáme soubory přímo na poli, ale pole slouží k provozu VM, je tam tedy několik dalších mezivrstev. Nějak si ani nedokážu představit, že tam člověk našel něco kloudnýho.
Nicméně zkusím si to někde nasimulovat.
Zdar Max

[Luboš Doležel (Doli)]

Nejlepším řešením je samozřejmě šifrovat, ale ten overhead se nemusí vůbec vyplatit.

S ohledem na podporu AES-NI v dnešních procesorech ten overhead nepředstavuje větší problém. Rozhodně ne u klasických disků.

[Bherzet]

Do toho overheadu spadá i nastavení šifrování a potíže s tím spojené, např. zapomenuté heslo, jak se mi podařilo nedávno (off-site záložní disk, na který jsem dlouho nesáhl; o data jsem nepřišel). Přesto se ale přikláním k šifrování taky, protože i když si vzdor všem bezpečnostním poučkám napíšeš hesla na lístečky okolo monitoru a jinde, likvidaci či reklamaci disku to stále řeší.

[Josef Kufner]

Nějak si ani nedokážu představit, že tam člověk našel něco kloudnýho.

Zkoušel jsi někdy na takový disk poslat photorec nebo podobný nástroj? Ty mezivrstvy typicky zachovávají bloky a snaží se eliminovat jakékoliv transformace dat. Je velmi pravděpodobné, že souvislý blok dat ve VM bude souvislým blokem dat i na fyzickém disku. Nejspíš budou jen zpřeházené větší kusy, jak si VM alokovalo další a další místo pro virtuální disk, ale to je docela malá komplikace, pokud obnovovací nástroj jde rovnou po datech, hledá hlavičky souborů a neřeší filesystém.

[Jendа]

photorec obnoví soubory co se vešly do jednoho stripe automaticky (pokud mají hlavičku, což většina formátů má). logins.json z mého Firefoxu má 43 kB a najdou ho i hloupé strings.

[gsnak]

The thing that goes on the floor down there...

[Bedňa]

Rozoberiem ich, vymontujem si neodýmové magnety a ostatné ide do šrotu.

Najzaujímavejšie dáta čo sa mi dostali do rúk, tak to boli dáta určitej obce (česky: vesnice) :)

[Agent]

Mám jich málo, takže si je nechávám na památku

[Vinicius]

U funkčních disků pro svou osobní potřebu přepíšu nejprve nulami a pak jedničkami utilitou dd. Vytvořím jeden velký NTFS oddíl a prodám za pár šupů na Aukru jako použité zboží.

[marbu]

Na svém stroji používám šifrování celého disku přes LUKS, a když ten disk měním za nový, přepíšu na něm několikát LUKS hlavičku. Pokud bych ho chtěl udat jinde, ještě bych na něm nechal projet badblocks, abych věděl jestli to má smysl, a zároveň tím celý disk ještě několikrát přepsal.

[Luboš Doležel (Doli)]

Takhle to dělám já, i když ten přepis hlavičky LUKS dělám jen jednou.

[xkucf03]

Tohle jsem řešil už před lety v souvislosti s reklamacemi disků. Obchodníci nejsou schopní ti zaručit, že vadný disk zničí, aby z něj nikdo nic nepřečetl. Je to jeden z mnoha důvodů, proč šifrovat. Když šifrovaný disk odejde, není velký problém ho reklamovat, rozebrat na součástky nebo darovat… Fyzickou likvidaci bych zvažoval jen v případě, že by disk obsahoval něco opravdu hodně citlivého, co by mělo dopad, i za X let, kdy ta šifra bude třeba prolomená.

[Bystroushaak]

+1, šifrování je jediný spolehlivý způsob jak tohle řešit, všechno ostatní jsou zbytečné blbosti, které neřeší například krádež, ztrátu a tak podobně.

[cezz]

Na dnesnom HW uz nie je nad cim premyslat, vykonovo je to zanedbatelny rozdiel a linuxove distribucie uz to dnes pri instalacii vedia v pohode nastavit aj pre BFU.

[cezz]

Este by som dodal, ze v datacentre sme disky mali jednak sifrovane, potom sme ich magneticky vymazali (su na to take zariadenia) a nasledne este fyzicky znicili. (opat v zariadeni ktore ho zlomilo na polovicu) A potom raz za par tyzdnov prisla firma ktora tie disky nasypala do takeho skartovaca (mlynceka) na disky, ktory to doslova pomlel na drobne.

Samozrejme vsetko bolo urobene tak, ze sa pre kazdy disk v datacentre dal podla serioveho cisla dohladat jeho aktualny stav.

Prakticky vzate ktorakolvek z tych operacii by mala zabranit uniku dat, ale je ich tam viac preto aby bolo iste ze ked jedna zlyha, tak tym nie je ohrozena bezpecnost dat. (typicky priklad je ten degauser, kde nevidis vizualne ci su tie data naozaj znicene a ked to testujes raz mesacne, je tam sanca ze medzitym nefunguje) Tiez su tie operacie vykonavane roznymi ludmi, takze je mensia sanca ze (umyselne alebo vedome) zlyha ludsky faktor.

Samozrejme to robila firma pre ktoru su tieto operacie a potrebne zariadenia zanedbatelne naklady. Pre mensiu spolocnost to uz nemusi byt tak lahke. (obzvlast ked potrebuje znicit disk raz za par mesiacov)

Cim som chcel povedat, ze "všechno ostatní jsou zbytečné blbosti" nie je tak celkom pravda, vsetko ma svoje opodstatnenie a spoliehat len na jednu formu ochrany ked na tych datach skutocne zalezi sa nemusi oplatit.

[ham]

vyrábím z nich brusky http://files.hamik5.webnode.cz/200000269-be6d4bf67f/hamikuvkoutek96.pdf

[tomvec]

Než bych řešil nějaký přepis v případě vyhození, není jednodušší jedna rána kladivem?

[manasekp]

Kdyz uz se vyjimecne zbavuju disku tak napred dostane parkrat kladivem.

[Zulu]

Kyknosovi onehda někdo do SUSE donesl starý Mac (ještě Motorola 68k) a na disku byla církevní (nějaká malá církev) databáze oveček s osobnímu daty, včetně "kdy uvěřil", záznamů ze zpovědí apod.

[fraja]

mame vesnickou "skladku" pres jeden les od domu. uz od mych mladych let jsem tam obcas zasel co je tam pekneho. posledni dobou jsou zne... ctyrjadrove intely q6600 uz se vyhazuji. ale zpet k tematu. disku jsem tam nasel vzdy nekolik. celkem mi disku ze skladky proslo rukama cca 4 stovky.

celkem casto byl disk duvodem proc se cely computer vyhodil. ty jsem jen na skladku vratil. ale na tom zbytku byla polovina disku z domacnosti, fotky, certifikaty do bankovnictvi, ulozena hesla v prohlizecich, na par discich byly velmi detailni fotky par slecen z malomesta. jeden disk jsem zbavil svych otisku a poslal anonymne na policii kvuli detskemu pornu.

druha cast byla z firemnich vyrazenych pc, ta byla zajimavejsi, protoze duvodem vyrazeni pravdepodobne bylo, ze se moralne zastaraly pocitac jako vyrazeny jiz valel nekde par let a pri jeho vyhazovani nikdo data neznicil. no co si budeme povidat, parkrat jsem tam zajimava data nasel a velmi zhodnotil, je dobre vedet presne vyrobni naklady, podane cenove nabidky a vsechny kontakty svych konkurentu.

je to dost velka cast meho uspechu v radech desistkach milionu a stale se rapidne navysuje. ale kdyz jsem u rodicu, stejne si na tu skladku s krizovym sroubovakem zajdu.

[Bystroushaak]

Pěkné, pěkné. Nechceš to vydat knižně? Něco jako "Jak jsem vesnickou skládkou k desítkám milionů přišel a půl princezny k tomu dostal?"

[xkucf03]

Těmi „desítkami milionů“ to docela shazuje, ale jinak to může sloužit jako dobré varování všem, kdo ledabyle nakládají s vlastními (nebo ještě hůř, s cizími) daty.

[trekker.dk]

Řekl bych ale, že minimálně ty životopisy by mohly být žalovatelné, protože zákon o ochraně osobních údajů.

Jo, ÚOOÚ by k tomu pravděpodobně měl co říct...

A co vy? Jak se zbavujete starých disků, abyste předešli úniku dat?

V práci je přepisujeme nulami nebo urandom, když jdou na reklamaci kvůli vadným sektorům nebo jinému problému, kde ten disk ještě nějak funguje. Ostatní disky jdou do velké krabice a pak pod vrtačku. Jako ochrana před popeláři to stačí a state-level špiony neřešíme.

[Jendа]

A co vy? Jak se zbavujete starých disků, abyste předešli úniku dat?

Občas nějaké rozebírám na magnety a úmyslně při tom pomatlám a poškrábu plotny.

[Jana J.]

Co se týče přepisů, doporučuji pozornosti utilitu scrub, v běžných distribucích (vím že minimálně v CentOS, Debian, Gentoo) bývá jako balíček.

[drnest]

Ještě nebyla zmíněná utilitka shred. Taky umí přepisovat náhodnými daty.

[Odin1918]

Drive jsem do toho vyvrtal nekolik der vrtakem na zelezo, znicil konektory i elektroniku. Dnes jen prepisu ddckem z /dev/zero ci pripadne /dev/urandom . Obsah stejne sifruji, tak je to jedno.

Jinak konkretne toto by asi zalovat neslo. Spise by mohoi zalovat tebe, ze se hrabes v kontejneru a hackujes cizi disky, coz imho odpovida znakum jisteho paragrafu...

[Blaazen]

V nějaký americký detektivce to bylo tak, že hrabat se někomu v popelnici před domem bylo bráno jako narušení soukromí, ale když ty odpadky prohledávali už v popelářským autě, tak to bylo legální.

[pushkin]

dd if=/dev/urandom of=/dev/sdX

A pak tam přes gParted udělám prázdnou FAT32 a ven s ním. Většinou tam by předtím jiný fs i rozdělení disku, takže pravděpodobnost obnovy dat se blíží nule.

[Jendа]

dd dělá defaultně read a write s nějakou směšně malou velikostí bloku a obzvláště teď po opravách Meltdown a Spectre jsou syscally pomalé. Proč ne prostě cat /dev/urandom > /dev/sdX?

[pc2005]

/dev/urandom mi dává na c2d jenom 105MiB/s (asi je ten pseudorandom generátor v kernelu dost pomalej). To je dost málo (i když na moje disky to ještě pro zápis asi stačí), já používám prostě /dev/zero.

[trekker.dk]

Lehce OT - s tímhle jsem nedávno narazil na to, že i když dd dostane parametr na velikost bloku a z toho disku čte, tak se stejně ta velikost bloku nedodrží. Respektive z pohledu dd možná jo, ale jádro si z disku četlo v tak malých blocích, jak se mu zachtělo

[Gilhad]

Což mi zase nepřijde jako tak zlá varianta. IMHO je jádro tak nějak asi ví co dělá a je podstatné to jádro neobtěžovat zbytečně malými (a tedy početnými) požadavky, když můžu použít i velké. A pokud ty velké jsou vhodně zaokrouhlené, tak by to jádru vadit nemělo (na rozdíl od malých a nezaokrouhlených). IMHO.

[trekker.dk]

IMHO je jádro tak nějak asi ví co dělá a je podstatné to jádro neobtěžovat zbytečně malými (a tedy početnými) požadavky, když můžu použít i velké.

Já bych byl taky pro, ale tady to bylo obráceně - chtěl jsem bloky 4MB, průměrná velikost I/O požadavku na ten disk byla asi 1kB. Testoval jsem Ceph a RBD, takže čtení bloků o velikosti pod 4MB může vést na nadbytečné I/O operace. To dd jelo sekvenčeně (jak jinak), takže bych tam viděl větší prostor pro slučování jednotlivých I/O requestů, než kolik jádro dělalo.

[Jendа]

Respektive z pohledu dd možná jo

GNU dd dělá read() s velikostí odpovídající zadané blocksize a jádro mu může dát libovolně méně. To se stane když zařízení nestíhá nebo když přijde signál. Pikantní to je když se někdo snaží odměřovat množství dat tímto způsobem a pak mu to zfailí. Řešení? iflag=fullblock (a nebo nepoužívat dd)

ale jádro si z disku četlo v tak malých blocích, jak se mu zachtělo

Mně nešlo o to v jak malých blocích se bude číst ze zařízení (tam se toho stejně zhostí readahead) ale že když děláš read(512), tak pro přepsání terabajtu dat musíš udělat dvě miliardy syscallů.

[trekker.dk]

To se stane když zařízení nestíhá nebo když přijde signál. Pikantní to je když se někdo snaží odměřovat množství dat tímto způsobem a pak mu to zfailí. Řešení? iflag=fullblock

Vida, to bych čekal, že bude zapnuté automaticky...

Mně nešlo o to v jak malých blocích se bude číst ze zařízení (tam se toho stejně zhostí readahead) ale že když děláš read(512), tak...

Což to jo, to mi bylo jasné.