Eliminare permanentemente tutti i dati di un disco

 

 

 

Negli ultimi periodi capita di avere chiavette usb o hard disk in abbondanza, e quindi di non riuscire più ad utilizzarli. Può capitare di regalare o vendere queste unità disco, e per una questione di sicurezza, sarebbe meglio fare in modo che nessuno si diverta a recuperare qualche dato personale. E' stato dimostrato che più del 30% dei pc connessi ad internet quotidianamente, naviga su siti porno, salvando foto e video zozzi, come fa Picchiopc. Quindi l'obiettivo è quello di rendere la vita difficile a chi vuole sbirciare nelle abitudini altrui 🙂 Una volta identificato il disco da formattare, il comando è semplice:

 

$ sudo dd if=/dev/zero of=/dev/sdX

 

 

enjoy 😉

Autore: Franco Conidi aka edmond

Senior System Integrator, Network Administrator, Sys Admin Linux, Linux User, Consulente Informatico.

18 pensieri riguardo “Eliminare permanentemente tutti i dati di un disco”

  1. “Negli ultimi periodi capita di avere chiavette usb o hard disk in abbondanza”

    Dammi retta se sei uno che scarica foto puppesche lo spazio NON è mai in abbondanza, quindi non si regala via nulla, anzi si va alla ricerca dello zio o del cugino che butta il suo vecchio pc per prendersi il vecchio disco fisso da 20Gb xD

    “E’ stato dimostrato che più del 30% dei pc connessi ad internet quotidianamente, naviga su siti porno..”

    Veramente la percentuale è molto più alta xD

  2. Sarebbe interessante sapere anche cosa quel comando fa 🙂
    Questo dovrebbe essere lo spirito, insegnare a pescare, non dare il pesce 🙂

  3. @Mattia: il comando “dd” (sta per disk-dump) nel nostro caso preleva zeri dal dispositivo virtuale “/dev/zero” e li scrive sul tuo disco “/dev/sd[x]”. Il comando termina quando lo spazio sul disco bersaglio è esaurito, quando, cioè ha scritto zeri dappertutto. Al posto della [x] va sostituita una lettera dell’ alfabeto: a,b,c,d rispettivamente per il primo, secondo, terzo, quarto disco ecc. Se vuoi vedere “quanti dischi hai” usa il comando “sudo cat /proc/partitions” in una finestra di terminale.

  4. @Mattia
    hai ragione, avrei dovuto mettere la spiegazione, comunque
    chi mi ha preceduto lo ha fatto egregiamente. Praticamente immagina
    tutti i settori del disco sovrascritti da 00000000000000000000000000
    0000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000
    0000000000000000000000000000000000000000000000000000000
    nel caso si trattasse di formattare un disco in uso, basta avviare da cd live.
    @kahhhtt (colpo di tosse)
    grazie per l’intervento

  5. Ehm, i ritirano fuori, eccome se si ritirano fuori, fidati…
    Facciamo che usiamo *almeno* shred o wipe…

  6. @paride
    mi pare che con i fs moderni shred ha qualche problemino,
    wipe lo tengo sempre installato 😉
    @tutti
    wipe è nei repository

  7. @Paride

    a meno che tu non abbia dati percui anche una frazione di file di testo possa rappresentare un grave rischio per la tua privacy dd è più che sufficiente.

    Ho fatto delle prove così:

    dd if=/dev/sdx | strings e non uscito niente di intelleggibile.
    Ho provato anche con software specifico ( encase ) e non è uscito nulla.

    Per evitare facili prove come quella che ho citato:

    dd if=/dev/urandom of=/dev/sdX ( o hdX per un vecchio disco non sata).

    Se il pc è destinato alla discarica…una bella martellata all’ HD sortirà lo stesso effetto.

    Per chi invece si sente preda di servizi segreti di qualche stato ostile la martellata potrebbe non essere sufficiente: recuperando i frammenti dei piatti è possibile, attraverso sofisticate tecniche di deposizione, e l’impiego di un Magnetic Force Microscopy il recupero almeno in parte dei dati presenti.

    Per chi volesse approfondire:

    https://www.vidarholen.net/~vidar/overwriting_hard_drive_data.pdf

  8. @edmond

    Quali tipo di problemi?
    Anche shred e’ nei repository.

  9. @edmond

    Quali tipo di problemi?
    Anche shred e’ nei repository.
    Comunque uno vale l’altro…

  10. @paride
    mi riferivo al fatto che non è garantito sui fs journaled:

    CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place.
    This is the traditional way to do things, but many modern file system designs do not satisfy this assumption.
    The following are examples of file systems on which shred is not effective,
    or is not guaranteed to be effective in all file sys‐ tem modes:

    log-structured or journaled file systems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)

    file systems that write redundant data and carry on even if some writes fail, such as RAID-based file systems

    file systems that make snapshots, such as Network Appliance’s NFS server

    file systems that cache in temporary locations, such as NFS version 3 clients

    compressed file systems

    In the case of ext3 file systems, the above disclaimer applies (and shred is thus of limited effectiveness)
    only in data=journal mode, which journals file data in addition to just metadata. In both the data=ordered (default)
    and data=writeback modes, shred works as usual. Ext3 journaling modes can be changed by adding the
    data=something option to the mount options for a particular file system in the /etc/fstab file, as documented
    in the mount man page (man mount).

  11. Ah, ok, si questo lo sapevo. Se non mi sbaglio anche wipe soffre della stessa cosa. In realta, e’ un “problema” dei file system journaled. Alla fine la cosa migliore sarebbe un bel filesystem crittografato, ed alla fine un wipe o shred sull’intero filesystem…

  12. Non ho mai avuto bisogno di usare shred su un volume intero, quindi non posso essere sicurissimo che funzioni, anche se nel man la possibilità di scrivere su un device è espressamente menzionata, e quindi dovrebbe andare.
    Tutto il discorso sul journaling invece è ininfluente perché, oltre a valere identico anche per dd, si applica quando l’oggetto della sovrascrittura è un file residente in un file system di tipo journaled, mentre l’esempio iniziale si riferisce espressamente a un intero device. Anche se molto più lento, meglio usare shred.

  13. Miu viene una curiosita’.
    E se si lascia il disco esposto ad una elettrocalamita bella piotente per un paio di orette, i dati si possono sempre ritirare
    fuori?

  14. @DPY
    il tuo ragionamento effettivamente non fa una grinza.

    @paride
    dell’elettrocalamita ne ho sentito parlare, ma in più non so altro.
    Invece faccio un’altra domanda, ipotizzando di NON volere piallare
    il disco, secondo voi un fs criptato o una singola cartella criptata,
    per esempio con encfs o mcrypt oppure truecrypt con chiave a 256bit
    o altro, quanto possibilità ci sono che vengano recuperati i dati?

  15. Ma secondo me, le possibilita’ ci sono sempre, ma vale lo stesso ragionamento del costo/beneficio, su tutto il ragionamento…
    Certo che con l’attuale potenza dei pc odierni le possibilita’ ci sarebbero, ed anche concrete…
    Se si pensa che in Debian hanno sostituito le quasi tutte le chiavi di cifratura di gpg da 1024 a 2048 bit…

  16. Il calamitone è in grado di danneggiare il disco, ma non credo sia sufficiente se l’obiettivo è quello di non lasciare neanche un byte leggibile. Il problema è che non c’è modo di esserne sicuri: anche gli hd hanno delle aree critiche che, danneggiate quelle, rendono il resto del disco illeggibile. In tale caso il disco sembrerebbe irrimediabilmente bloccato, ma ricostruendo quelle aree si sblocherebbe tutto e il disco sarebbe in gran parte leggibile. A questo punto meglio fare una sovrascrittura completa, se rimane qualcosa di leggibile devono sforzarsi di ricavarlo da tracce che ora contengono tutt altro: sono comunque dati parziali e zeppi di errori. Poi, una volta sovrascritto tutto, il calamitone non fa male, ma è un di più.

    IMHO la possibilità di decodificare dei dati cifrati con una crittografia forte non può essere esclusa, ma richiede tempi e capacità di calcolo molto elevate che non sono alla portata di un privato, né di un’azienda specializzata in recupero dati. Insomma, ci vogliono i ‘mitici’ computer dell’NSA. A quel punto è più semplice e veloce andare a vedere la parte non crittografata del disco, in particolare la /tmp, il rischio di trovare dati importanti sui file temporanei varia comunque da alto ad altissimo.

  17. In conclusione, il metodo più accettabile è quello della sovrascrittura del disco.
    Per quanto riguarda i dati da tenere “segreti” una crittografia forte dovrebbe reggere
    l’urto di CSI MIami 🙂

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *