Jak wytrzeć wolne miejsce na dysku w Linuksie?

Ostrzeżenie: Nowoczesny sprzęt dyskowy i nowoczesne systemy plików mogą wiercić dane w miejscach, w których nie można ich usunąć, więc proces ten może nadal pozostawiać dane na dysku. Jedynym bezpiecznym sposobem wymazania danych jest polecenie ATA Secure Erase (jeśli zostało poprawnie wdrożone) lub fizyczne zniszczenie. Zobacz również Jak mogę niezawodnie wymazać wszystkie informacje z dysku twardego?

Możesz użyć zestawu narzędzi zwanego secure-delete.

sudo apt-get install secure-delete

Posiada on cztery narzędzia:

srm - bezpiecznie usuń istniejący plik smem - bezpiecznie usuń ślady pliku z ram sfill - wytrzyj całe miejsce oznaczone jako puste na dysku twardym sswap - wytrzyj wszystkie dane z zamienionego miejsca.

Na stronie man z srm

srm jest przeznaczony do bezpiecznego usuwania danych na nośnikach, które nie mogą być odzyskane przez złodziei, organy ścigania lub inne zagrożenia. Algorytm wycierania opiera się na pracy “Secure Deletion of Data from Magnetic and Solid-State Memory” zaprezentowanej na 6 Usenix Security Symposium przez Petera Gutmanna, jednego z czołowych kryptografów cywilnych.

Proces bezpiecznego usuwania danych srm przebiega w następujący sposób:

• 1 przejazd z 0xff
• 5 losowych przebiegów. /dev/urandom jest używany do bezpiecznego RNG, jeśli jest dostępny.
• 27 przebiegów ze specjalnymi wartościami określonymi przez Petera Gutmanna.
• 5 losowych przebiegów. /dev/urandom jest używany do bezpiecznego RNG, jeśli jest dostępny.
• Zmień nazwę pliku na wartość losową
• Obetnij plik

Jako dodatkowy środek bezpieczeństwa, plik jest otwierany w trybie O_SYNC i po każdym przebiegu następuje wywołanie fsync(). srm zapisuje 32k bloków w celu uzyskania prędkości, wypełniając bufory pamięci podręcznej dysku, aby zmusić je do przepłukania i nadpisania starych danych, które należały do pliku.

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).

WARNING

I was shocked by how many files photorec could retrieve from my disk, even after wiping.

Whether there is more security in filling the “free space” only 1 time with 0x00 or 38 times with different cabalistic standards is more of an academic discussion. Autor referatu o rozdrabnianiu z 1996 roku napisał sam siebie epilog mówiąc, że jest to przestarzałe i niepotrzebne dla nowoczesnego sprzętu. Nie ma udokumentowanego przypadku fizycznego zastąpienia danych zerami i ich późniejszego odzyskania.

Prawdziwym fragile link w tej procedurze jest system plików. Niektóre systemy plików rezerwują miejsce na specjalny użytek i nie są one udostępniane jako “wolne miejsce”. Ale twoje dane mogą tam być. To obejmuje zdjęcia, osobiste e-maile tekstowe, cokolwiek. Właśnie googlowałem reserved+space+ext4 i dowiedziałem się, że 5% mojej partycji home zostało zarezerwowane. Zgaduję, że to tutaj photorec znalazło tak wiele moich rzeczy. Wniosek: metoda rozdrabniania nie jest najważniejsza, nawet metoda wieloprzebiegowa nadal pozostawia dane na miejscu.

Możesz spróbować # tune2fs -m 0 /dev/sdn0 przed jej zamontowaniem. (Jeśli będzie to partycja główna po restarcie, upewnij się, że uruchomiłeś -m 5 lub -m 1 po jej odmontowaniu).

Ale nadal, w ten czy inny sposób, może pozostać trochę miejsca.

Jedynym naprawdę bezpiecznym sposobem jest wytarcie całej partycji, utworzenie systemu plików ponownie, a następnie przywrócenie plików z kopii zapasowej.

Szybki sposób (zalecany)

Uruchom z katalogu na systemie plików, który chcesz wytrzeć:

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

_Uwaga: celem małego pliku jest skrócenie czasu, w którym wolne miejsce jest całkowicie zerowe; celem synchronizacji jest upewnienie się, że dane są rzeczywiście zapisane. _

To powinno być wystarczająco dobre dla większości ludzi.

Powolny sposób (paranoik)

Nie ma udokumentowanego przypadku odzyskania danych po powyższym czyszczeniu. Byłoby to kosztowne i wymagałoby dużych zasobów, jeśli w ogóle byłoby to możliwe.

Jeśli jednak masz powody sądzić, że tajne agencje wydadzą dużo zasobów na odzyskanie Twoich plików, to powinno wystarczyć:

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

Zajmuje to znacznie więcej czasu.

Ostrzeżenie. Jeśli wybrałeś sposób paranoiczny, po tym czasie nadal chciałbyś zrobić szybkie wycieranie, a to nie jest paranoja. Obecność czysto przypadkowych danych jest łatwa i tania do wykrycia oraz budzi podejrzenia, że są to dane zaszyfrowane. Możesz zginąć pod wpływem tortur za nieujawnienie klucza deszyfrującego.

Bardzo powolny sposób (szalona paranoja)

Nawet autor seminarium z 1996 roku na temat rozdrabniania napisał epilog mówiący, że jest to przestarzałe i niepotrzebne dla nowoczesnego sprzętu.

Ale jeśli masz jeszcze dużo wolnego czasu i nie masz nic przeciwko marnowaniu dysku na nadpisywanie, to idzie:

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

Uwaga: jest to w zasadzie równoznaczne z użyciem bezpiecznego narzędzia do usuwania.

• *

Przed edycją ten post był przepisem Davida Spillett'a. Komenda “cat” tworzy komunikat o błędzie, ale nie mogę pisać komentarzy do postów innych osób.

Przynajmniej w Ubuntu jest zerofree utility: 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.

Sprawdź również ten link o zerofree: Keeping filesystem images sparse - jest od jego autora - Rona Yorstona (9 sierpnia 2012)

Wytrzyj dysk z najwyższą prędkością.

Typowe instrukcje szyfrowania dysku w dzisiejszych czasach powiedzą Ci, aby najpierw WIPE dysk.

Poniższe polecenie wypełni Twój dysk szyfrowanym tekstem AES.

Użyj live CD, jeśli chcesz wytrzeć główny dysk rozruchowy.

Otwórz terminal i podnieś swoje uprawnienia:

sudo bash

Wymieńmy wszystkie napędy w systemie, aby być bezpiecznym:

cat /proc/partitions

UWAGA: Wymień /dev/sd{x} na urządzenie, które chcesz wytrzeć.

OSTRZEŻENIE: To nie jest dla amatorów! Możesz sprawić, że twój system będzie nie do uruchomienia!!!

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}

Jestem oszołomiony jak szybko to jest.

Używam dd do alokacji jednego lub więcej dużych plików, aby wypełnić wolne miejsce, a następnie używam bezpiecznego narzędzia do usuwania.

Aby zaalokować pliki z dd spróbuj:

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

To wygeneruje plik o nazwie delete_me o wielkości 100 MB. (Tutaj bs to “rozmiar bloku” ustawiony na 1k, a count to liczba bloków do przydzielenia)

Następnie użyj swojego ulubionego narzędzia do bezpiecznego usuwania (używałem shred ) na tak utworzonych plikach.

But NOTE THIS: buffering means even if you do the whole disk, you may not get absolute everything!

• *

This link recommends scrub for free space wiping. Nie próbowałem tego.

Możesz wytrzeć wolne miejsce za pomocą bezpiecznego pakietu do usuwania danych.

W tym pakiecie znajdziesz narzędzie sfill, które jest przeznaczone do usuwania danych, które znajdują się na dostępnej przestrzeni dyskowej na nośnikach w bezpieczny sposób, który nie może być odzyskany przez złodziei, organy ścigania lub inne zagrożenia.

Aby zainstalować bezpieczny pakiet do usuwania danych w systemie Linux (Ubuntu), zainstaluj go za pomocą następującej komendy:

$ sudo apt-get install secure-delete

Następnie do erase your data no free space, spróbuj następującej komendy:

sfill -f -v -ll /YOUR_MOUNTPOINT/OR_DIRECTORY

Where /YOUR_MOUNTPOINT/OR_DIRECTORY is your mount point (df -h, mount) or directory to wipe the free space.

Read the manual at http://manpages.ubuntu.com/manpages/hardy/man1/sfill.1 .html

Prawdopodobnie masz już zainstalowany w swoim systemie pakiet GNU coreutils . Dostarcza on komendę shred .

Łatwiej jest używać scrub :

scrub -X dump

To spowoduje utworzenie folderu dump w bieżącej lokalizacji i utworzenie pliku do momentu zapełnienia dysku. Możesz wybrać wzór z opcją -p (nnsa|dod|bsi|old|fastold|gutmann).

Nie jest łatwo zainstalować scrub'a zobacz Forum Ubuntu na tej stronie ), ale po zakończeniu instalacji masz w ręku naprawdę proste i skuteczne narzędzie.

Oto skrypt “sdelete.sh”, którego używam. Zobacz komentarze, aby dowiedzieć się więcej.

# 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'

Znalazłem proste rozwiązanie, które działa na Linuksie i MacOSie. Przenieś się do folderu głównego dysku i uruchom tę komendę:

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

gdzie //DISKSPACE// jest wielkością w GB Twojego dysku twardego.

Jest to mit, że dane muszą być zapisywane wielokrotnie (wystarczy zapytać Peter'a guntmann'a), a losowe dane, w przeciwieństwie do danych 1, a następnie 0, implikują nienaturalną aktywność. wtedy końcowym rezultatem jest czysty dysk z dużo krótszym czasem zapisu. poza tym, programy do bezpiecznego usuwania danych nie mogą nawet nadpisać prawdziwego pliku na nowoczesnych systemach plików (journaled). Zrób sobie przysługę i zdobądź photorec, zeskanuj swój dysk, aby zobaczyć bałagan, wytrzyj go 1’s i opcjonalnie zerami, aby wyglądał nietknięty. jeśli photorec nadal znajduje rzeczy, pamiętaj, że skanuje wszystko, co jest dostępne, więc zrób to ostrożnie ponownie z głównym użytkownikiem.

Pamiętaj, cia/fbi/nsa nie ma fantazyjnej maszyny, która może odczytać rzeczywisty stan bitów nośnika magnetycznego. to wszystko było tylko papier napisany dawno temu. “co-jeśli”. wystarczy przetrzeć 1 raz.

To nie jest odpowiedź! _To tylko komentarz dla tych, którzy chcą użyć pv…więc nie przeszkadzaj w głosowaniu.

Na Linux Mint 17.3 możesz użyć pv (pipe view) aby uzyskać postęp w pisaniu. Na przykład:

# 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

Zaletą jest to, że otrzymujesz pasek postępu, ETA i stale aktualizowane dane. Wadą jest to, że jest on zapisywany na jednej linii i gdy dysk jest pełny (zwracając błąd) znika. Dzieje się tak dlatego, że pełny rozmiar jest przybliżony, ponieważ system operacyjny będzie prawdopodobnie używał dysku podczas tej bardzo długiej operacji, szczególnie na woluminie systemu operacyjnego.

Na bardzo starym HD otrzymuję prędkość transmisji danych około 13 MB/s przy użyciu /dev/urandom, oraz około 70 MB/s , przy użyciu /dev/zero. Prawdopodobnie poprawiłoby się to jeszcze bardziej, gdy używam surowego dd lub cat, a nie pv.

Czasami używam tego bash one-liner:

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

Kiedy zacznie mówić, że dysk jest pełny, wystarczy wcisnąć Ctrl+C i usunąć utworzone pliki zero.*.

Działa na każdym systemie, niezależnie od ograniczeń rozmiaru plików. Ignoruj wszelkie błędy cat: write error: File too large.

Po usunięciu pliku z rekordu systemu plików, dane pozostawione na dysku twardym są bezsensowną sekwencją 1’s i 0’s. Jeśli chcesz zastąpić tę bezsensowną sekwencję inną bezsensowną sekwencją, mogę doradzić kilka komercyjnych produktów do bezpiecznego usuwania dysków, takich jak arconis.