Jak vymazat volné místo na disku v Linuxu?

Upozornění: Moderní hardwarové disky/SSD a moderní souborové systémy mohou svírat data na místech, kde je nelze smazat, takže tento proces může stále zanechávat data na disku. Jediným bezpečným způsobem vymazání dat je příkaz ATA Secure Erase (pokud je implementován správně), nebo fyzické zničení. Viz také Jak mohu spolehlivě vymazat všechny informace na pevném disku?

Můžete použít sadu nástrojů s názvem secure-delete.

sudo apt-get install secure-delete

Má čtyři nástroje:

srm - bezpečně odstranit existující soubor
smem - bezpečně odstranit stopy souboru z paměti RAM
sfill - vymažte veškeré místo označené jako prázdné na pevném disku
sswap - vymažte všechna data z vašeho swapovacího prostoru.

Z manuálové stránky srm

srm je navržen tak, aby bezpečným způsobem smazal data na médiích, která nemohou být obnovena zloději, orgány činnými v trestním řízení nebo jinými hrozbami. Algoritmus mazání je založen na článku „Bezpečné vymazání dat z magnetické a polovodičové paměti“, který na 6. bezpečnostním sympoziu Usenix představil Peter Gutmann, jeden z předních civilních kryptografů.

Proces bezpečného mazání dat srm probíhá takto:

• 1 průchod s 0xff
• 5 náhodných průchodů. /dev/urandom se používá pro zabezpečený RNG, pokud je k dispozici.
• 27 průchodů se speciálními hodnotami definovanými Peterem Gutmannem.
• 5 náhodných průchodů. /dev/urandom se používá pro zabezpečený RNG, pokud je k dispozici.
• Přejmenujte soubor na náhodnou hodnotu
• Zkrátit soubor

Jako další bezpečnostní opatření je soubor otevřen v režimu O_SYNC a po každém průchodu fsync() hovor je dokončen. srm zapisuje 32k bloků za účelem zrychlení, zaplňuje vyrovnávací paměti diskových mezipamětí, aby je přinutilo vyprázdnit, a přepíše stará data, která k souboru patřila.

Nejrychlejší způsob, pokud potřebujete pouze jeden průchod a chcete vše nahradit nulami, je:

cat /dev/zero > zero.file
sync
rm zero.file

(spusťte z adresáře na souborovém systému, který chcete vymazat)
_{(sync příkaz je paranoia opatření, které zajišťuje zápis všech dat na disk – inteligentní správce mezipaměti by mohl přijít na to, že může zrušit zápisy pro všechny čekající bloky, když je soubor odpojen)}

Během této operace nastane čas, kdy na souborovém systému nebude vůbec žádné volné místo, což může být desítky sekund, pokud je výsledný soubor velký a fragmentovaný, takže odstranění chvíli trvá. Chcete-li zkrátit dobu, kdy je volné místo zcela nulové:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
cat /dev/zero > zero.file
sync
rm zero.small.file
rm zero.file

To by mělo stačit k tomu, aby někdo zabránil čtení obsahu starého souboru bez nákladné forenzní operace. Pro trochu bezpečnější, ale pomalejší variantu nahraďte /dev/zero s /dev/urandom . Pro větší paranoiu spusťte několik kroků pomocí /dev/urandom , ale pokud potřebujete tolik úsilí, shred nástroj z balíku coreutils je cesta:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
shred -z zero.small.file
cat /dev/zero > zero.file
sync
rm zero.small.file
shred -z zero.file
sync
rm zero.file

Všimněte si, že ve výše uvedeném je malý soubor skartován před vytvořením většího, takže jej lze odstranit, jakmile je větší dokončen, místo toho, abyste museli čekat na jeho skartaci, takže souborový systém bude mít nulové volné místo po dobu, kterou to zabere. Proces skartování trvá dlouho čas nad velkým souborem a pokud se nesnažíte něco skrýt před NSA, není to IMO opravdu nutné.

Vše výše uvedené by mělo fungovat na jakémkoli souborovém systému.

Omezení velikosti souboru:

Jak DanMoulding zdůrazňuje v komentáři níže, může to mít problémy s omezením velikosti souborů na některých souborových systémech.

Pro FAT32 by to určitě být znepokojující kvůli limitu 2GiB souboru:většina svazků je v dnešní době větší než tento (8TiB je limit velikosti svazku IIRC). Tento problém můžete obejít propojením velkého cat /dev/zero výstupní výstup přes split generovat několik menších souborů a podle toho upravit fáze skartování a odstraňování.

S ext2/3/4 to není tak důležité:s výchozím/běžným blokem 4K je limit velikosti souboru 2TiB, takže byste museli mít obrovské objem, aby to byl problém (maximální velikost svazku za těchto podmínek je 16TiB).

S (stále experimentálním) btrfs je maximální velikost souboru i svazku obrovských 16EiB.

V systému NTFS je maximální délka souboru v některých případech dokonce větší než maximální délka svazku.

Výchozí body pro více informací:
http://cs.wikipedia.org/wiki/Ext3#Size_limits
http://cs.wikipedia.org/wiki/Btrfs
http://cs.wikipedia.org/wiki/Ntfs#Scalability

Virtuální zařízení

Jak bylo nedávno zmíněno v komentářích, pro virtuální zařízení existují další úvahy:

• Pro řídce alokované virtuální disky jiné metody, jako jsou ty, které používá zerofree bude rychlejší (i když na rozdíl od cat a dd toto není standardní nástroj, na který se můžete spolehnout, že je dostupný v podstatě v jakémkoli operačním systému typu unix).

• Uvědomte si, že vynulování bloku na řídkém virtuálním zařízení nemusí vymazat blok na základním fyzickém zařízení, ve skutečnosti bych řekl, že je to nepravděpodobné - správce virtuálních disků prostě udělá blok jako již nepoužívaný, takže jej lze později přidělit něčemu jinému.

• Dokonce i u virtuálních zařízení s pevnou velikostí nemusíte mít žádnou kontrolu nad tím, kde se zařízení fyzicky nachází, takže by se mohlo kdykoli přesunout kolem jeho aktuálního umístění nebo na novou sadu fyzických disků a maximálně můžete vymazat aktuální umístění, nikoli všechna předchozí místa, kde mohl blok v minulosti sídlit.

• K výše uvedeným problémům na virtuálních zařízeních:pokud neovládáte hostitele a nemůžete provést bezpečné vymazání jejich nepřiděleného prostoru a poté vymazat disky ve virtuálním počítači nebo přesunout virtuální zařízení, nemůžete s tím po skutečnost. Jediným východiskem je použití úplného šifrování disku od začátku takže nic nezašifrovaného není v první řadě zapsáno na fyzické médium. Samozřejmě stále může existovat požadavek na vymazání volného místa ve virtuálním počítači. Všimněte si také, že FDE může způsobit, že řídká virtuální zařízení budou mnohem méně užitečná, protože virtualizační vrstva ve skutečnosti nevidí, které bloky jsou nevyužité. Pokud vrstva souborového systému OS posílá příkazy oříznutí virtuálnímu zařízení (jako by to bylo SSD) a virtuální řadič je interpretuje, pak to může vyřešit, ale nevím o žádných okolnostech, kdy k tomu skutečně dojde a širší diskuse o tom je věcí jinde (už se blížíme k tomu, že jsme mimo téma původní otázky, takže pokud to vzbudilo váš zájem, může být na místě nějaké experimentování a/nebo doplňující otázky).

UPOZORNĚNÍ

Byl jsem šokován tím, kolik souborů mohl photorec načíst z mého disku i po vymazání.

Zda existuje větší bezpečnost při zaplnění "volného prostoru" pouze jednou 0x00 nebo 38krát různými kabalistickými standardy, je spíše akademická diskuse. Autor klíčového článku o skartování z roku 1996 si napsal epilog, v němž řekl, že je to zastaralé a pro moderní hardware nepotřebné. Neexistuje žádný zdokumentovaný případ, kdy by byla data fyzicky nahrazena nulami a následně obnovena.

Skutečný křehký odkaz v tomto postupu je systém souborů . Některé souborové systémy si rezervují prostor pro speciální použití a ten není zpřístupněn jako "volné místo". Vaše data tam ale mohou být . To zahrnuje fotografie, osobní e-maily ve formátu prostého textu, cokoliv. Právě jsem googlil Reserve+space+ext4 a zjistil jsem, že 5 % z mých home oddíl byl rezervován. Myslím, že tady je photorec našel tolik mých věcí. Závěr:Metoda skartování není nejdůležitější, dokonce i metoda více průchodů stále ponechává data na místě .

Můžete zkusit # tune2fs -m 0 /dev/sdn0 před jeho montáží. (Pokud to bude kořenový oddíl po restartu, ujistěte se, že spusťte -m 5 nebo -m 1 po jeho odpojení).

Ale přesto, tak či onak, může zůstat nějaké místo.

Jediný skutečně bezpečný způsob je vymazat celý oddíl, znovu vytvořit souborový systém a poté obnovit soubory ze zálohy.

Rychlý způsob (doporučeno)

Spusťte z adresáře na souborovém systému, který chcete vymazat:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
rm zero.file

Poznámky:účelem malého souboru je zkrátit dobu, kdy je volné místo úplně nulové; účelem synchronizace je zajistit, aby byla data skutečně zapsána.

To by mělo většině lidí stačit.

Pomalá cesta (paranoidní)

Neexistuje žádný zdokumentovaný případ obnovení dat po výše uvedeném čištění. Bylo by to drahé a náročné na zdroje, pokud je to vůbec možné.

Přesto, pokud máte důvod si myslet, že tajné agentury by vynaložily spoustu prostředků na obnovu vašich souborů, mělo by to stačit:

dd if=/dev/urandom of=random.small.file bs=1024 count=102400
dd if=/dev/urandom of=random.file bs=1024
sync ; sleep 60 ; sync
rm random.small.file
rm random.file

Trvá to mnohem déle.

Varování. Pokud jste zvolili paranoidní způsob, po tomto byste stále chtěli provést rychlé vymazání, a to není paranoia. Přítomnost čistě náhodných dat je snadno a levně zjistitelná a vzbuzuje podezření, že se skutečně jedná o zašifrovaná data. Můžete zemřít mučením za to, že jste neprozradili dešifrovací klíč.

Velmi pomalý způsob (šílený paranoidní)

Dokonce i autor klíčového článku o skartaci z roku 1996 napsal epilog, v němž uvedl, že je to zastaralé a pro moderní hardware nepotřebné.

Ale pokud máte ještě spoustu volného času a nevadí vám plýtvat diskem spoustou přepisování, tak to jde:

dd if=/dev/zero of=zero.small.file bs=1024 count=102400
sync ; sleep 60 ; sync
shred -z zero.small.file
dd if=/dev/zero of=zero.file bs=1024
sync ; sleep 60 ; sync
rm zero.small.file
shred -z zero.file
sync ; sleep 60 ; sync
rm zero.file

Poznámka:Toto je v podstatě ekvivalentní použití nástroje bezpečného mazání.

Před úpravou byl tento příspěvek přepsáním příspěvku Davida Spilletta. Příkaz "cat" vytváří chybovou zprávu, ale nemohu psát komentáře k příspěvkům jiných lidí.