Pulisci in modo sicuro un server Linux remoto senza testa

18

Sto per interrompere la mia relazione con il mio fornitore di hosting da molti anni, ma mi piacerebbe pulire la scatola in modo sicuro prima di farlo. Questo è un server dedicato che esegue Debian su una singola unità EXT3 e sebbene io abbia accesso root, non riesco ad avviare supporti alternativi poiché è senza testa in un rack da qualche parte.

Non ho bisogno di più passaggi, ma vorrei liberare spazio libero se possibile. Fondamentalmente mi piacerebbe andarmene e assicurarmi di non lasciare indietro nessuno dei miei dati personali. Sono preoccupato che la scatola potrebbe bloccarsi prima che finisca di cancellare / sincronizzare il filesystem se avessi appena eseguitosrm -R -s /

— notpeter
fonte

imho, usare il dd (in basso)

— Alcuni Linux Nerd

4

Sono riuscito con successo fino in fondo rm -rf --no-preserve-root /senza che il sistema si schiantasse prima e senza che nulla fosse lasciato sul disco.

— Fahad Sadah
fonte

Ho eseguito SRM sulle mie directory dei dati, quindi rm -rf --no-preserve-root /tramite SSH per ripulire il resto. Ha lanciato un paio di errori in / dev e poi completati; Non sapevo bene cosa fare al prompt di bash. Senza un / bin / ls o / sbin / shutdown, non potrei confermare il successo. Era anticlimatica; Ero mentalmente preparato per un crash, non un kernel zombie e una sessione sshd.

— not

7

Questo non è sicuro. I dati non vengono cancellati e l'annullamento è ancora possibile. Meglio ddinvece sul disco.

— Qris,

10

Il programma di installazione CentOS (anaconda) fornito con le immagini PXE include un server VNC, quindi è possibile modificare la configurazione di grub per avviare il programma di installazione CentOS, passando le risposte alle domande del programma di installazione pre-stage 2 sulla linea grub, riavviare e quindi VNC all'installatore.

Ora, se la mia memoria mi serve correttamente, dall'interno di quel programma di installazione dovresti essere in grado di passare a una shell, da cui puoi accedere e distruggere il disco.

Copia i file vmlinuz e initrd dalla directory PXE nella distribuzione CentOS ( http://mirror.centos.org/centos/5/os/i386/images/pxeboot/ ) su / boot e modifica la configurazione di grub:

impostazione predefinita 0
timeout 5
titolo CentOS
root (hd0,0)
kernel /boot/vmlinuz.cent.pxe vnc vncpassword = PASSWORD headless ip = IP netmask = 255.255.255.0 gateway = GATEWAYIP dns = 8.8.8.8 ksdevice = eth0 method = http: //mirror.centos.org/centos/5/os / i386 / lang = en_US keymap = us
initrd /boot/initrd.img.cent.pxe

Per inciso, qualsiasi società di hosting decente dovrebbe essere pronta a distruggere i tuoi dischi per te.

— Stephen Nelson-Smith
fonte

3

Non sono una "società di hosting decente", quindi il mio bisogno di lasciare e cancellare i miei dischi.

— not

Non ho usato questo metodo, ma usare GRUB per avviare un'immagine di ripristino minima preconfigurata per abilitare vnc (o anche solo SSH) è totalmente fattibile. Se sbagli, potenzialmente rimani con un sistema che richiede un intervento manuale per riavviarsi correttamente, quindi probabilmente vale la pena testarlo prima in una VM.

— notpeter

1

Una parola sull'ordine in cui vengono spazzate le cose potrebbe essere utile. Pulendo prima tutte le partizioni tranne quella contenente /boot, si sarebbe in grado di ricominciare da capo nel caso in cui la macchina fosse riavviata nel mezzo del processo. Se si /boottrova sulla /partizione, è possibile eliminare tutti i file al di fuori di /boote cancellare lo spazio libero prima di cancellare definitivamente l'intera partizione. Ciò ridurrebbe al minimo la quantità di dati rimasti sul disco nel caso in cui vengano riavviati una volta cancellati così tanto che non sarà più possibile avviarli.

— Kasperd,

7

Prima di distruggere il sistema operativo è possibile rimuovere qualsiasi cosa sensibile e zerofill (usando dd if = / dev / zero di = justabigfile).

E credo che la maggior parte dei sistemi sopravviverà a un dd su un sistema in esecuzione abbastanza a lungo per sovrascrivere l'intero disco. Ovviamente non c'è modo di tornare indietro.

— Joris
fonte

4

Se elimini tutti i file di cui ti preoccupi prima di farlo, scambia la partizione di swap, cancella la partizione di swap (usando wipe o dd), quindi quanto sopra dovrebbe essere abbastanza sicuro. Dovrai farlo come root per superare il 5% riservato a root e potresti non cancellare tutti i nomi dei file, ma i dati dovrebbero essere spariti.

— Slartibartfast

6

La mia soluzione prevede un approccio in più passaggi facendo parte di quanto sopra, ma coinvolgendo anche un chroot in ram che dovrebbe consentire a dd di completare completamente la cancellazione del disco.

Prima elimina tutti i tuoi dati sensibili, lasciando i file necessari per eseguire il sistema operativo. Quindi fai questo (non in uno script, esegui un comando alla volta):

mkdir /root/tmpfs/
mount -t tmpfs tmpfs /root/tmpfs/
debootstrap --variant=buildd --arch amd64 precise /root/tmpfs/
mkdir /root/tmpfs/mainroot
mount --bind / /root/tmpfs/mainroot
mount --bind /dev /root/tmpfs/dev
chroot /root/tmpfs/

# fill mainroot partition to wipe previously deleted data files
dd if=/dev/zero of=/mainroot/root/bigfile; rm /mainroot/root/bigfile
# now clobber the entire partition, probably won't be able to stay connected to ssh after starting this
# obviously change '/dev/md1' to the device that needs cleared
nohup dd if=/dev/zero of=/dev/md1 >/dev/null 2>&1

Dovrebbe occuparsene!

— moparisthebest
fonte

1

Puoi semplicemente usare ddper sovrascrivere l'intera partizione / disco su un server in esecuzione senza preoccupazioni. Lo usiamo molto al lavoro (quando il cliente non vuole pagare per la distruzione sicura del disco fisico).

In realtà cancelli i dati senza che il filesystem montato lo sappia, quindi il filesystem inizierà a impazzire man mano che i suoi metadati vengono persi, quindi il sistema operativo stesso inizierà a "collassare". Tuttavia, ciò che è già nella cache funziona ancora. Quindi puoi monitorare l'avanzamento tramite console remota o KVM (non l'ho provato tramite ssh). Il sistema continua a funzionare anche dopo aver ddterminato, tuttavia nessun comando funzionerà e probabilmente tutti i demoni sono già morti.

Uso questi comandi: dd if=/dev/zero of=/dev/sda bs=1M & e poi kill -HUP %1per monitorare l'avanzamento (dd stamperà la velocità attuale e la quantità di dati scritti). L'impostazione della dimensione del blocco ( bs) è molto importante per raggiungere la velocità di scrittura seq dell'HDD con dd.

Ogni volta è ddstato in grado di cancellare il disco fino alla fine e sono stato in grado di emettere il killcomando (shell integrata) fino alla fine. Se hai un raid software, puoi cancellare il mddispositivo stesso o ciascun dispositivo componente singolarmente.

— Marki555
fonte

Il mio collega ha fatto questo e xwindows non è riuscito a bloccarsi, dovrebbe essere esattamente ciò di cui il richiedente ha bisogno.

— Alcuni nerd Linux

1

Il protocollo ATA ha un comando "cancellazione sicura" che, come indica il nome, dovrebbe cancellare in modo sicuro l'intero HDD.

Vedi l'articolo della wiki del kernel per i dettagli, ma attenzione agli avvertimenti in alto:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

— Vladimir Panteleev
fonte

Aggiornamento 2018: l'ho usato con successo in diverse occasioni per cancellare i server in remoto, anche se stanno eseguendo il filesystem in fase di cancellazione. Poiché il programma emette solo un comando ATA e attende una risposta, non è necessario eseguire alcun codice sulla CPU durante il processo di cancellazione.

— Vladimir Panteleev, il

0

Puoi provare a scrivere dati casuali sul tuo disco in questo modo:

dd if=/dev/urandom of=/dev/sda

È più sicuro dell'uso di / dev / zero perché scrive dati casuali, ma è MOLTO più lento ..

— Kedare
fonte

Come qualcuno che non conosce meglio, perché le persone votano in questo modo? Non è una buona pratica?

— Canadian Luke REINSTATE MONICA

@CanadianLuke La domanda riguarda la cancellazione sicura di un server già in esecuzione. Non è possibile scrivere su un'unità montata come questa, quindi non funzionerà.

— collo lungo il

@longneck Grazie. Per qualche ragione, ho pensato che root potesse farlo ... Anche se non ci ho mai provato, quindi prenderò la tua parola per questo. Grazie per avermi spiegato

— canadese Luke REINSTATE MONICA il

@longneck ya you can, ha aggiunto il commento sopra ma ho avuto un collega davvero paranoico. In realtà è possibile scollegare completamente il disco rigido e Linux continuerà comunque a eseguire tutto in memoria senza altro che un mucchio di messaggi di errore dell'applicazione.

— Alcuni nerd Linux

0

Qualunque cosa tu scelga di fare, vai su un altro fornitore e testalo.

Ottieni un'istanza simile su AWS (o gcloud o ...) e provalo lì, mantenendo il disco e quindi collegandolo a un'altra istanza come memoria aggiuntiva e scansionandolo. dd if = sdb | HD

Quasi tutto il materiale sensibile dovrebbe essere presente

/home
/opt
/var
/etc
/usr

Sono i file di configurazione con password incorporate che infastidiscono la maggior parte delle persone. Se sai cosa sono, cerca in tutto il filesystem per sradicarli.

rm cancellerà i file, ma un editor esadecimale leggerà comunque il disco. Quindi zero dopo. Dai un'occhiata a shred. Dovresti avere un registro dei tuoi file di configurazione e dove sono per scopi di DR, giusto? Non dimenticare i file crontab se hai password, ad esempio.

L'installazione di CentOS o qualsiasi soluzione ramdisk è valida. Il kernel sarà in memoria, hai bisogno di dd e un po 'di contenuto bin. Ma se riavvii in modalità di ripristino potresti non avere rete o SSH e tagliarti.

NB Kedare ha una buona idea, e se stai eseguendo da ram al tuo prossimo riavvio (ramdisk) questo è possibile, è molto difficile recuperare da / dev / zero per iniziare, quindi non aggiunge davvero valore a meno che la tua vita dipende da questo?

— mckenzm
fonte