Hoe wis je vrije schijfruimte in Linux?

Waarschuwing: Moderne schijf-/SSD-hardware en moderne bestandssystemen kunnen gegevens wegsijpelen op plaatsen waar u ze niet kunt verwijderen, dus dit proces kan nog steeds gegevens op de schijf achterlaten. De enige veilige manier om gegevens te wissen is het ATA Secure Erase commando (indien correct geïmplementeerd), of fysieke vernietiging. Zie ook Hoe kan ik op betrouwbare wijze alle informatie op een harde schijf wissen?

U kunt gebruik maken van een reeks tools genaamd secure-delete.

sudo apt-get install secure-delete

Dit heeft vier tools:

srm - veilig verwijderen van een bestaand bestand smem - veilig verwijderen van sporen van een bestand van ram sfill - wissen van alle ruimte die als leeg is gemarkeerd op uw harde schijf sswap - wissen van alle gegevens van u wisselruimte.

Van de man pagina van srm

srm is ontworpen om gegevens op dragers op een veilige manier te verwijderen die niet kunnen worden hersteld door dieven, wetshandhavers of andere bedreigingen. Het wisalgoritme is gebaseerd op het papier “Secure Deletion of Data from Magnetic and Solid-State Memory” dat op het 6e Usenix Security Symposium werd gepresenteerd door Peter Gutmann, een van de leidende civiele cryptografen.

srm gaat als volgt te werk:

• 1 pas met 0xff
• 5 willekeurige passen. /dev/urandom wordt gebruikt voor een beveiligde RNG indien beschikbaar.
• 27 passen met speciale waarden die door Peter Gutmann zijn gedefinieerd.
• 5 willekeurige passen. /dev/urandom wordt gebruikt voor een veilige RNG indien beschikbaar.
• Hernoem het bestand naar een willekeurige waarde
• Truncate het bestand

Als extra veiligheidsmaatregel wordt het bestand geopend in O_SYNC modus en na elke pass wordt een fsync() call gedaan. srm schrijft 32k blokken voor het doel van snelheid, het vullen van buffers van disk caches om ze te dwingen om oude data die bij het bestand hoorde door te spoelen en te overschrijven.

De snelste manier, als je maar een enkele pas nodig hebt en gewoon alles wilt vervangen door nullen, is:

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

(draaien vanuit een directory op het bestandssysteem dat u wilt wissen) (het sync commando is een paranoïde maatregel die ervoor zorgt dat alle gegevens naar de schijf worden geschreven - een intelligente cache manager kan er misschien achter komen dat hij het schrijven van eventuele hangende blokken kan annuleren wanneer het bestand ontkoppeld is)

Er zal een tijd zijn tijdens deze operatie dat er helemaal geen vrije ruimte is op het bestandssysteem, wat tientallen seconden kan zijn als het resulterende bestand groot en gefragmenteerd is, dus een tijdje duurt om te verwijderen. Om de tijd te verminderen wanneer de vrije ruimte volledig nul is:

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

Dit zou genoeg moeten zijn om iemand te stoppen met het lezen van de oude bestandsinhoud zonder een dure forensische operatie. Voor een iets veiligere, maar tragere, variant vervang je /dev/zero door /dev/urandom. Voor meer paranoia’s moet je meerdere stappen uitvoeren met /dev/urandom, maar als je zoveel moeite moet doen is het hulpprogramma shred van het coreutils pakket de oplossing:

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

Merk op dat in het bovenstaande het kleine bestand wordt versnipperd voordat het grotere bestand wordt aangemaakt, zodat het kan worden verwijderd zodra het grotere bestand compleet is, in plaats van te moeten wachten tot het wordt versnipperd, waardoor het bestandssysteem gedurende de tijd die nodig is, geen vrije ruimte meer heeft. Het versnipperingsproces met een lange tijd over een groot bestand duurt en tenzij u iets probeert te verbergen voor het NSA is het niet echt nodig IMO.

Al het bovenstaande zou moeten werken op eender welk bestandssysteem.

Bestandslimieten:

Zoals DanMoulding in een commentaar hieronder aangeeft, kan dit problemen hebben met limieten voor de bestandsgrootte op sommige bestandssystemen.

Voor FAT32 zou het definitief een probleem zijn omwille van de 2GiB bestandslimiet: de meeste volumes zijn tegenwoordig groter dan dit (8TiB is de volumegroottelimiet IIRC). U kunt hier omheen werken door de grote cat /dev/zero uitvoer door split te leiden om meerdere kleinere bestanden te genereren en de shredder- en verwijderingsfasen overeenkomstig aan te passen.

Met ext2/3/4 is het minder zorgwekkend: met het standaard / gemeenschappelijke 4K-blok is de bestandsgrootte limiet 2TiB, dus u zou een huge volume moeten hebben om dit een probleem te laten zijn (de maximale volumegrootte onder deze omstandigheden is 16TiB).

Met de (nog experimentele) btrfs is zowel de maximale bestands- als volumegrootte een massieve 16EiB.

Onder NTFS is de maximale bestandslengte in sommige gevallen zelfs groter dan de maximale volumelengte.

Uitgangspunten voor meer informatie: Zoals onlangs in de opmerkingen is vermeld, zijn er extra overwegingen voor virtuele apparaten:

• Voor spaarzaam toegewezen virtuele schijven zullen andere methoden zoals die van zerofree sneller zijn (hoewel dit in tegenstelling tot cat en dd geen standaardhulpmiddel is waarvan u erop kunt vertrouwen dat het beschikbaar is in vrijwel elk unix-a-achtig besturingssysteem).

• Wees ervan bewust dat het op nul zetten van een blok op een dun virtueel apparaat het blok op het onderliggende fysieke apparaat niet kan wissen, in feite zou ik zo ver willen gaan om te zeggen dat het onwaarschijnlijk is - de virtuele schijfmanager zal het blok gewoon niet meer gebruiken zodat het later aan iets anders kan worden toegewezen.

• Zelfs voor virtuele apparaten met een vaste grootte kan het zijn dat u geen controle heeft over waar het apparaat fysiek woont, zodat het op elk moment rond de huidige locatie of op een nieuwe set fysieke schijven kan worden verplaatst en het meeste dat u kunt wissen is de huidige locatie, niet alle eerdere locaties waar het blok in het verleden heeft gestaan.

• Voor de bovenstaande problemen op virtuele apparaten: tenzij u de host(s) controleert en de niet-toegewezen ruimte daarna veilig kunt wissen door de schijven in de VM te wissen of het virtuele apparaat te verplaatsen, kunt u hier achteraf niets meer aan doen. De enige mogelijkheid is om volledige schijfversleuteling vanaf het begin te gebruiken, zodat er in de eerste plaats niets onversleuteld naar de fysieke media wordt geschreven. Er kan natuurlijk nog steeds een oproep worden gedaan voor een vrije ruimte veeg binnen de VM. Let er ook op dat FDE kan zorgen dat spaarzame virtuele apparaten veel minder bruikbaar zijn, omdat de virtualisatielaag niet echt kan zien welke blokken ongebruikt zijn. Als de bestandsysteemlaag van het OS trimcommando’s naar het virtuele apparaat stuurt (alsof het een SSD is), en de virtuele controller interpreteert deze, dan kan dat dit oplossen, maar ik weet niet onder welke omstandigheden dit daadwerkelijk gebeurt en een bredere discussie daarover is elders aan de orde (we komen al dicht in de buurt van off topic voor de oorspronkelijke vraag, dus als dit uw interesse heeft gewekt kunnen wat experimenten en/of vervolgvragen op hun plaats zijn).

WAARSCHUWING

Ik was geschokt door hoeveel bestanden fotorec van mijn schijf konden halen, zelfs na het wissen.

Of er meer zekerheid is in het vullen van de “vrije ruimte” slechts 1 keer met 0x00 of 38 keer met verschillende cabalistische standaarden is meer een academische discussie. De auteur van de rudimentaire paper uit 1996 over shredding schreef zelf een epiloog waarin staat dat dit achterhaald is en niet meer nodig is voor moderne hardware. Er is geen gedocumenteerd geval van gegevens die fysiek vervangen worden door nullen en daarna hersteld worden.

De ware fragile link in deze procedure is het bestandssysteem. Sommige bestandssystemen reserveren ruimte voor speciaal gebruik, en deze wordt niet beschikbaar gesteld als “vrije ruimte”. Maar uw gegevens kunnen er wel zijn. Dat geldt ook voor foto’s, persoonlijke plain-text e-mails, wat dan ook. Ik heb zojuist gereserveerd+space+ext4 gegoogled en heb geleerd dat 5% van mijn home partitie gereserveerd is. Ik denk dat dit de plek is waar photorec zoveel van mijn spullen heeft gevonden. Conclusie: de versnipperingsmethode is niet de belangrijkste, zelfs de multi-pass methode laat nog steeds gegevens achter.

Je kunt # tune2fs -m 0 /dev/sdn0 proberen voordat je het monteert. (Als dit de root-partitie zal zijn na het herstarten, zorg er dan voor dat u -m 5 of -m 1 uitvoert na het unmounten).

Maar toch, op een of andere manier, kan er nog wat ruimte over zijn.

De enige echt veilige manier is om de hele partitie te wissen, opnieuw een bestandssysteem aan te maken, en dan uw bestanden terug te zetten van een backup.

• *

Snelle manier (aanbevolen)

Run vanuit een directory op het bestandssysteem dat u wilt wissen:

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

_Noten: het doel van het kleine bestand is om de tijd te verminderen wanneer de vrije ruimte volledig nul is; het doel van de synchronisatie is om er zeker van te zijn dat de gegevens daadwerkelijk worden geschreven. _

Dit zou voor de meeste mensen goed genoeg moeten zijn.

Slow way (paranoïde)

Er is geen gedocumenteerd geval van gegevens die worden hersteld na de bovenstaande reiniging. Het zou duur zijn en veel middelen vergen, als het al mogelijk is.

Toch, als je een reden hebt om te denken dat geheime instanties veel middelen zouden spenderen om je bestanden te herstellen, zou dit genoeg moeten zijn:

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

Het duurt veel langer.

Waarschuwing. Als je de paranoïde manier hebt gekozen, zou je daarna nog steeds het snelle wissen willen doen, en dat is geen paranoia. De aanwezigheid van puur willekeurige gegevens is eenvoudig en goedkoop te detecteren, en doet het vermoeden rijzen dat het eigenlijk gecodeerde gegevens zijn. Je kunt sterven onder marteling omdat je de ontcijferingssleutel niet hebt onthuld.

Zeer langzame manier (gekke paranoïde)

Zelfs de auteur van het rudimentaire artikel uit 1996 over versnippering schreef een epiloog die zegt dat dit verouderd is en niet nodig is voor de moderne hardware.

Maar als je toch veel vrije tijd hebt en je het niet erg vindt om je schijf te verspillen met veel overschrijven, daar gaat het om:

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

Note: dit is in wezen gelijk aan het gebruik van de secure-delete tool.

• *

Voor de bewerking was dit bericht een herschrijving van David Spillett’s. Het “cat” commando geeft een foutmelding, maar ik kan geen commentaar schrijven op andermans berichten.

Er is in ieder geval een zerofree utility in Ubuntu: http://manpages.ubuntu.com/manpages/natty/man8/zerofree.8.html

zerofree — zero free blocks from ext2/3 file-systems

   zerofree finds the unallocated, non-zeroed blocks in an ext2 or ext3
   filesystem (e.g. /dev/hda1) and fills them with zeroes. This is useful
   if the device on which this file-system resides is a disk image. In
   this case, depending on the type of disk image, a secondary utility may
   be able to reduce the size of the disk image after zerofree has been
   run.

   The usual way to achieve the same result (zeroing the unallocated
   blocks) is to run dd (1) to create a file full of zeroes that takes up
   the entire free space on the drive, and then delete this file. This has
   many disadvantages, which zerofree alleviates:

      · it is slow;

      · it makes the disk image (temporarily) grow to its maximal extent;

      · it (temporarily) uses all free space on the disk, so other
         concurrent write actions may fail.

   filesystem has to be unmounted or mounted read-only for zerofree to
   work. It will exit with an error message if the filesystem is mounted
   writable. To remount the root file-system readonly, you can first
   switch to single user runlevel (telinit 1) then use mount -o remount,ro
   filesystem.

Controleer ook deze link over zerofree: Houden van bestandssysteemafbeeldingen spaarzaam - het is van de auteur - Ron Yorston (9 augustus 2012)

Veeg een drive op topsnelheid.

Typische instructies voor het coderen van een drive tegenwoordig zal u vertellen om de drive eerst te WIPE.

Het onderstaande commando zal uw drive vullen met AES cijfertekst.

Gebruik een live CD als u uw hoofd-boot drive moet wissen.

Open een terminal en verhoog uw privileges:

sudo bash

Laat ons een lijst maken van alle drives op het systeem om veilig te zijn:

cat /proc/partitions

OPMERKING: Vervang /dev/sd{x} door het apparaat dat u wilt wissen.

WAARSCHUWING: Dit is niet voor amateurs! Je zou je systeem niet meer kunnen opstarten!

sudo openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > /dev/sd{x}

Ik ben verbaasd over hoe snel dit is.

Ik gebruik dd om één of meer grote bestanden toe te wijzen om de vrije ruimte op te vullen, gebruik dan een veilig verwijderingshulpprogramma.

Om bestanden met dd toe te wijzen probeer:

dd if=/dev/zero of=delete_me bs=1024 count=102400

Dit zal een bestand met de naam delete_me genereren dat 100 MB groot is. (Hier is bs de “blokgrootte” ingesteld op 1k, en count is het aantal toe te wijzen blokken.)

Gebruik dan uw favoriete veilige verwijderingshulpprogramma (ik heb shred gebruikt) op de aldus gemaakte bestanden.

*Maar let op: * bufferen betekent dat zelfs als u de hele schijf doet, u misschien niet alles krijgt!

• *

Deze link raadt scrub aan voor het wissen van de vrije ruimte. Heb het niet geprobeerd.

U kunt uw vrije ruimte wissen door gebruik te maken van het beveiligde verwijderingspakket

. In dat pakket vindt u sfill tool, die is ontworpen om gegevens die op de beschikbare schijfruimte op dragers liggen op een veilige manier te verwijderen die niet kan worden hersteld door dieven, wetshandhavers of andere bedreigingen.

Om een veilig verwijderingspakket in Linux (Ubuntu) te installeren, installeert u het met het volgende commando:

$ sudo apt-get install secure-delete

Dan naar erase uw gegevens geen vrije ruimte, probeer het volgende commando:

sfill -f -v -ll /YOUR_MOUNTPOINT/OR_DIRECTORY

Waar /YOUR_MOUNTPOINT/OR_DIRECTORY uw koppelpunt (df -h, mount) of directory is om de vrije ruimte te wissen.

Lees de handleiding op http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1 .html

Waarschijnlijk heeft u het GNU coreutils pakket al op uw systeem geïnstalleerd. Het geeft de opdracht shred .

Gemakkelijker is het om scrub :

scrub -X dump

te gebruiken Dit maakt een dump-map in de huidige locatie en maakt een bestand aan totdat de schijf vol is. U kunt een patroon kiezen met de optie -p (nnsa|dod|bsi|old|fastold|gutmann).

Het is niet eenvoudig om scrub te laten installeren zie de Ubuntu Forums op deze ), maar zodra de installatie is voltooid, hebt u een echt SIMPLE en efficiënt hulpmiddel in de hand.

Hier is het “sdelete.sh” script dat ik gebruik. Zie commentaar voor details.

# Install the secure-delete package (sfill command).

# To see progress type in new terminal:
# watch -n 1 df -hm

# Assuming that there is one partition (/dev/sda1). sfill writes to /.
# The second pass writes in current directory and synchronizes data.
# If you have a swap partition then disable it by editing /etc/fstab
# and use "sswap" or similar to wipe it out.

# Some filesystems such as ext4 reserve 5% of disk space
# for special use, for example for the /home directory.
# In such case sfill won't wipe out that free space. You
# can remove that reserved space with the tune2fs command.
# See http://superuser.com/a/150757
# and https://www.google.com/search?q=reserved+space+ext4+sfill

sudo tune2fs -m 0 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'

sudo sfill -vfllz /

# sfill with the -f (fast) option won't synchronize the data to
# make sure that all was actually written. Without the fast option
# it is way too slow, so doing another pass in some other way with
# synchronization. Unfortunately this does not seem to be perfect,
# as I've watched free space by running the "watch -n 1 df -hm"
# command and I could see that there was still some available space
# left (tested on a SSD drive).

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

sudo tune2fs -m 5 /dev/sda1
sudo tune2fs -l /dev/sda1 | grep 'Reserved block count'

Ik heb een eenvoudige oplossing gevonden die werkt op Linux en op MacOS. Beweeg in de hoofdmap van je schijf en start dit commando:

for i in $(seq 1 //DISKSPACE//); do dd if=/dev/zero of=emptyfile${i} bs=1024 count=1048576; done; rm emptyfile*;

waarbij //DISKSPACE// de grootte is in GB van je harde schijf.

Gebruik dd en nul uit de vrije ruimte. het is een mythe dat gegevens meerdere malen overschreven moeten worden (vraag het maar aan Peter guntmann) en willekeurige gegevens, in tegenstelling tot 1’s dan 0’s impliceert onnatuurlijke activiteit. dan is het eindresultaat een schone schijf met veel minder tijd besteed aan het schrijven. bovendien kunnen veilige verwijderingsprogramma’s niet garanderen dat ze zelfs het echte bestand overschrijven op moderne bestandssystemen (gelogitimeerd). doe jezelf een plezier en haal fotorec, scan je schijf om de rotzooi te zien, wis het met 1’s en optioneel met nullen om het er onaangeroerd uit te laten zien. als fotorec nog steeds dingen vindt, onthoud dan dat het alles aan het scannen is, dus doe dit nog eens voorzichtig met de root gebruiker.

onthoud, de cia/fbi/nsa heeft geen fancy machine die de werkelijke staat van je magnetische media bits kan lezen. dat was allemaal maar een papiertje dat lang geleden geschreven is. een “wat-als”. je hoeft maar 1 keer te vegen.

Dit is geen antwoord! Gewoon een opmerking voor degenen die pv willen gebruiken…dus doe geen moeite met stemmen.

Op Linux Mint 17.3 kunt u pv gebruiken (pipe view) om de voortgang van het schrijven te krijgen. Bijvoorbeeld:

# Install pv (pipe view)
sudo apt-get install pv

# Write huge file of approximate size of /dev/sdb, using urandom data:
pv --timer --average-rate --progress --numeric --eta --interval 5 --size "$(blockdev --getsize64 /dev/sda )" /dev/urandom >rand.file

Het voordeel hiervan is dat je een voortgangsbalk, ETA en continu bijgewerkte datasnelheid krijgt. Het nadeel is dat deze op één regel wordt geschreven en als de schijf vol is (een fout terugbrengen) verdwijnt deze. Dit gebeurt omdat de volledige grootte bij benadering is omdat het OS de schijf waarschijnlijk zal gebruiken terwijl deze zeer lange operatie plaatsvindt, vooral op het OS volume.

Op een zeer oude HD krijg ik een datasnelheid van ongeveer 13 MB/s bij gebruik van /dev/urandom, en ongeveer 70 MB/s , bij gebruik van /dev/zero. Dit zou waarschijnlijk verder verbeteren bij gebruik van een ruwe dd of cat, en niet pv.

Ik gebruik soms deze bash one-liner:

while :; do cat /dev/zero > zero.$RANDOM; done

Wanneer het begint te zeggen dat de schijf vol is, druk dan op Ctrl+C en verwijder de aangemaakte zero.* bestanden.

Het werkt op elk systeem, ongeacht de limieten van de bestandsgrootte. Negeer eventuele cat: write error: File too large fouten.

Als het bestand eenmaal van het record van het bestandssysteem is verdwenen, zijn de gegevens die op de harde schijf zijn achtergebleven betekenisloos in de volgorde van 1 en 0. Als u die betekenisloze reeks wilt vervangen door een andere betekenisloze reeks, kan ik enkele commerciële producten adviseren voor het veilig wissen van schijven, zoals arconis.