Decommissionare un server in hosting


Può capitare di dover decommissionare un server Linux in hosting presso un fornitore a cui non abbiamo l’accesso fisico o di cui non possiamo verificare l’avvenuta cancellazione, se si tratta di una macchina virtuale.

Quanto segue parte dal presupposto che i dati scritti sul disco tali siano e che non sia possibile leggere il dato scritto precedentemente, quindi se in una posizione c’è scritto 99, gli scrivo sopra 00 quello che leggo è sempre e solamente 00, il 99 è andato.

In questo esempio non vengono utilizzati software specifici, ma solamente i tool messi a disposizione dai sistemi base di Linux.

Consideriamo uno scenario un cui c’è un solo disco fisico /dev/sda e un solo file system montato sotto root.

Nel caso di un sistema a cui abbiamo accesso fisico, si possono usare i metodi descritti qui e qui.

HIC SUNT LEONES!

Il testo che segue contiene indicazioni che, se seguite, portano alla cancellazione definitiva dei dati registrati su un computer. Questo tipo di attività va eseguito con coscienza di causa e ogni tipo di responsabilità è a carico di chi esegue queste operazioni.

HIC SUNT LEONES!

L’operazione avviene via ssh con un utente creato ad hoc che ha guadagnato i privilegi di root.

Innanzi tutto bisogna fermare tutti i servizi non essenziali per la vita del server come mail, httpd, ftp, sql, eccetera; fermiamo anche il syslog e disabilitiamo l’uso dello swap con swapoff -a

Cancelliamo tutti gli utenti creati, e relative home, nel corso della vita del server tranne l’utente che usiamo per collegarci via ssh.

Cancelliamo tutti i file di configurazione, le directory della mail, i sorgenti usati per compilare i file, la directory dei log, i file di storia della bash e di altri eventuali programmi e le directory .ssh di root e dell’utente in uso.

Devono rimanere solamente i binari della distribuzione e le poche configurazioni utili per collegarsi via ssh. Potrebbe essere comodo avere un paio di sessioni ssh attive.

Creiamo uno script come questo:

#!/bin/bash

for FILE in {0..300}
do
       dd if=/dev/random of=$FILE bs=1G
done

dove al posto di 300 c’è il numero di gigabyte di spazio libero arrotondato per eccesso. Una volta che lo script viene eseguito, vengono creati tanti file da un giga quanti sono necessari per riempire il disco. Questa operazione di fatto sovrascrive tutto lo spazio libero del disco (e, quindi, tutti i file cancellati) con dei dati casuali.

Dal momento che siamo root, abbiamo dello spazio riservato nel file system, anche se questo è pieno. Possiamo decidere anche di cancellare i file che abbiamo creato, una volta terminata l’operazione.

L’ultimo passo è quello di tornare in orbita e nuclearizzare il sistema con uno script di questo tipo:

#!/bin/bash

dd if=/dev/zero of=/dev/sda bs=1M
echo 1 > /proc/sys/kernel/sysrq
echo o > /proc/sysrq-trigger

che azzera il disco e  spegne il sistema. Viene utilizzato il Magic SysRq key perché, se ha fatto il proprio dovere, il primo comando ha reso ogni comando del sistema inutilizzabile.

Aggiornamento 13/1/2013 – Un’alternativa potrebbe essere l’utilizzo di DBAN in maniera unattendend.

Una volta scaricato l’ISO di DBAN lo si monta attraverso il device loop (mount -o loop -t iso9660 dban-x.x.x.iso /tmp/dbaniso) oppure si estrae il contenuto dell’ISO con altri metodi.

Il file dban.bzi deve essere copiato dall’ISO in /boot/dban

Fatto ciò bisogna aggiungere al boot manager la voce relativa a DBAN e renderla di default. Nel caso di grub la voce da aggiungere a grub.conf sarà simile a questa

title DBAN
root (hd0,0)
kernel /dban/dban.bzi nuke="dwipe --autonuke"
boot

Riavviando il server partirà automaticamente la cancellazione del disco.

Se il fornitore di hosting non prevede un accesso remoto alla console, non sarà possibile verificare se la procedura viene avviata come ci si aspetta, in quanto il server potrebbe bloccarsi al boot per un errore di configurazione del boot manager.

,

11 risposte a “Decommissionare un server in hosting”

  1. Giusto una nota … perchè cancellare lo spazio libero sovrascrivendo dati random e poi non usare la stessa prudenza per cancellare il resto?

    • Ho usato /dev/random e /dev/zero per usare due modi diversi.

      Date le premesse del secondo capoverso del post e data l’unica necessita’ di sovrascrivere i file, che la sovrascrittura avvenga con valori uniformi o con valori casuali, il livello di prudenza per me e’ identico.

  2. “Dal momento che siamo root, abbiamo dello spazio riservato nel file system, anche se questo è pieno.”

    Puoi darmi qualche informazione in più su questo punto?

  3. Va anche detto che se non mi fido che il provider dell’hosting cancelli per davvero la macchina virtuale, non mi posso nemmeno fidare che non si sia copiato tutto il contenuto della macchina virtuale mentre era in esercizio 🙂

    • Non vedo proprio il nesso causale tra le due cose, oltretutto l’articolo non si applica solamente alle VM.

      Se, poi, nello SLA non e’ presente il wipe dei dati (su VM o su HD che siano), non posso nemmeno pretenderlo. Anche se fosse non ho strumenti necessari per verificarlo.

      Bottom line: lanciare uno script di 4 righe in croce su un server in dismissione
      costa molto meno delle pippe di SLA e verifiche e da’ maggiore sicurezza. Costi/benefici nettamente a favore dei benefici.

      • Se il problema e` che non e` previsto che il provider ti cancelli i dati (disco o VM che sia) allora, ovviamente, devi arrangiarti cosi`.

        Se il problema e` che puoi chiedergli di cancellarteli, ma non ti fidi della sua discrezione, allora lo scriptino serve a poco. Hai a monte un problema ben piu` grave.

        • Ho scritto che non posso verificarlo, non che non mi fido.

          Controlli incrociati e verifiche fanno parte del diligente modo di procedere nell’informatica, come in altri settori.

          • L’importante e` che sia chiaro che parliamo di una strategia “cinta e bretelle”…

Lascia un commento

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