Limpie de forma segura un servidor Linux remoto sin cabeza

18

Estoy a punto de terminar mi relación con mi proveedor de alojamiento durante muchos años, pero me gustaría borrar la caja de forma segura antes de hacerlo. Este es un servidor dedicado que ejecuta Debian en una sola unidad EXT3 y, aunque tengo acceso de root, no puedo arrancar medios alternativos ya que no tiene cabeza en un rack en alguna parte.

No necesito múltiples pases, pero me gustaría borrar el espacio libre si es posible. Básicamente, me gustaría alejarme y asegurarme de no dejar ninguno de mis datos personales. Me preocupa que la caja se bloquee antes de que termine de borrar / sincronizar el sistema de archivos si solo ejecutosrm -R -s /

— notpeter
fuente

En mi humilde opinión, use el dd (en la parte inferior)

— Algunos Linux Nerd

4

He logrado completar todo el proceso rm -rf --no-preserve-root /sin que el sistema se bloquee primero, y sin que quede nada en el disco.

— Fahad Sadah
fuente

Ejecuté srm en mis directorios de datos, luego a rm -rf --no-preserve-root /través de SSH para limpiar el resto. Lanzó un par de errores en / dev y luego se completó; No sabía qué hacer en el indicador de bash. Sin un / bin / ls o / sbin / shutdown, no pude confirmar el éxito. Era anticlimático; Estaba mentalmente preparado para que se bloqueara, no un kernel zombie y una sesión sshd.

— notpeter

77

Esto no es seguro. Los datos no se borran y la eliminación aún es posible. Mejor que ddsobre el disco en su lugar.

— qris

10

El instalador CentOS (anaconda) que se envía con las imágenes PXE incluye un servidor VNC, por lo que puede modificar su configuración de grub para iniciar el instalador de CentOS, pasando las respuestas a las preguntas del instalador previo a la etapa 2 en la línea de grub, reiniciar y luego VNC al instalador

Ahora, si mi memoria me sirve correctamente, desde ese instalador debería poder caer a un shell, desde el cual puede acceder y destruir el disco.

Copie los archivos vmlinuz e initrd del directorio PXE en la distribución CentOS ( http://mirror.centos.org/centos/5/os/i386/images/pxeboot/ ) a / boot y modifique su configuración de grub:

por defecto 0
tiempo de espera 5
título CentOS
root (hd0,0)
kernel /boot/vmlinuz.cent.pxe vnc vncpassword = CONTRASEÑA sin cabeza 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

Por cierto, cualquier empresa de alojamiento decente debe estar preparada para destruir sus discos por usted.

— Stephen Nelson-Smith
fuente

3

No son una "empresa de alojamiento decente", de ahí mi necesidad de irme y limpiar mis discos.

— notpeter

No utilicé este método, pero usar GRUB para arrancar una imagen de rescate mínima preconfigurada para habilitar vnc (o incluso solo SSH) es totalmente factible. Si comete un error, es posible que se quede con un sistema que requiere intervención manual para reiniciar correctamente, por lo que probablemente valga la pena probarlo primero en una VM.

— notpeter

1

Una palabra sobre el orden en que se borran las cosas podría ser útil. Al limpiar primero todas las particiones, excepto la que contiene /boot, podrá comenzar de nuevo en caso de que la máquina se reinicie en el medio del proceso. Si /bootsucede que está en la /partición, uno puede eliminar todos los archivos fuera /booty borrar el espacio libre antes de finalmente borrar toda la partición. Esto minimizaría la cantidad de datos que quedan en el disco en caso de que se reinicie una vez que haya borrado tanto, que ya no podrá iniciarlo.

— Kasperd

7

Antes de destruir el sistema operativo, puede eliminar cualquier cosa sensible y zerofill (usando dd if = / dev / zero of = justabigfile).

Y creo que la mayoría de los sistemas sobrevivirán dd a un sistema en ejecución el tiempo suficiente para sobrescribir todo el disco. No hay vuelta atrás si no es así, por supuesto.

— Joris
fuente

44

Si elimina todos los archivos que le preocupan antes de hacer esto, cambie su partición de intercambio, limpie la partición de intercambio (usando wipe o dd), entonces lo anterior debería ser bastante seguro. Deberá hacerlo como root para superar el 5% reservado para root, y es posible que no borre todos los nombres de archivo, pero los datos deberían desaparecer.

— Slartibartfast

6

Mi solución implica un enfoque de varios pasos que hace algo de lo anterior, pero también involucra un chroot en ram que debería permitir que dd termine de borrar completamente el disco.

Primero elimine todos sus datos confidenciales, dejando los archivos necesarios para ejecutar el sistema operativo. Luego haga esto (no en un script, hágalo un comando a la vez):

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

¡Eso debería cuidar de él!

— moparisthebest
fuente

1

Puede usar ddpara sobrescribir toda la partición / disco en un servidor en ejecución sin ninguna preocupación. Lo usamos mucho en el trabajo (cuando el cliente no quiere pagar por la destrucción segura del disco físico).

Realmente borras los datos sin que el sistema de archivos montado lo sepa, por lo que el sistema de archivos comenzará a enloquecer a medida que se pierden sus metadatos, luego el sistema operativo comenzará a "colapsarse". Sin embargo, lo que ya está en caché todavía funciona. Entonces puede monitorear el progreso a través de la consola remota o KVM (no lo probé a través de ssh). El sistema se mantiene en funcionamiento incluso después de ddfinalizar, sin embargo, ningún comando funcionará y todos los demonios probablemente ya estén muertos.

Uso estos comandos: dd if=/dev/zero of=/dev/sda bs=1M & y luego kill -HUP %1para monitorear el progreso (dd imprimirá la velocidad actual y la cantidad de datos escritos). Establecer block-size ( bs) es muy importante para lograr la velocidad de escritura secuencial del HDD con dd.

Cada vez ddpude borrar el disco hasta el final y pude emitir el killcomando (shell incorporado) hasta el final. Si tiene una incursión de software, puede borrar el mddispositivo en sí o cada dispositivo componente individualmente.

— Marki555
fuente

Mi compañero de trabajo hizo esto y xwindows no se pudo bloquear, debería ser exactamente lo que necesita el solicitante.

— Algunos Linux Nerd

1

El protocolo ATA tiene un comando de "borrado seguro" que, como su nombre indica, debe borrar de forma segura todo el disco duro.

Vea el artículo de Kernel wiki para más detalles, pero tenga en cuenta las advertencias en la parte superior:

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

— Vladimir Panteleev
fuente

Actualización de 2018: lo he utilizado con éxito en varias ocasiones para borrar servidores de forma remota, incluso cuando se están ejecutando fuera del sistema de archivos que se está limpiando. Como el programa solo emite un comando ATA y espera una respuesta, no es necesario ejecutar ningún código en la CPU durante el proceso de borrado.

— Vladimir Panteleev

0

Podría intentar escribir datos aleatorios en su disco de esta manera:

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

Es más seguro que usar / dev / zero porque escribe datos aleatorios, pero también es MUCHO más lento.

— Kedare
fuente

Como alguien que no conoce mejor, ¿por qué la gente está votando por esto? ¿No es esta una buena práctica?

— Canadian Luke REINSTATE MONICA

@CanadianLuke La pregunta es sobre borrar de forma segura un servidor que ya se está ejecutando. No puede escribir en una unidad montada como esta, por lo que no funcionará.

— Longneck

@ Longongck Gracias. Por alguna razón, pensé que root podría hacer eso ... Aunque nunca lo intenté, así que aceptaré tu palabra. Sin embargo, gracias por explicarlo

— canadiense Luke REINSTATE MONICA el

@Longneck ya puedes, agregó el comentario anterior, pero tuve un compañero de trabajo realmente paranoico que hizo eso. En realidad, puede desconectar completamente su disco duro y Linux seguirá ejecutando todo en la memoria sin más que un montón de mensajes de error de la aplicación.

— Algunos Linux Nerd

0

Independientemente de lo que elija hacer, busque otro proveedor y pruébelo.

Obtenga una instancia similar en AWS (o gcloud o ...) e inténtelo allí, manteniendo el disco y luego adjuntándolo a otra instancia como almacenamiento adicional y escaneándolo. dd if = sdb | hd

Casi todo su material sensible debe estar en

/home
/opt
/var
/etc
/usr

Son los archivos de configuración con contraseñas incrustadas los que molestan a la mayoría de las personas. Si sabe cuáles son, busque en todo el sistema de archivos para eliminarlos.

rm eliminará archivos, pero un editor hexadecimal seguirá leyendo el disco. Entonces cero después. Echa un vistazo a triturar. Debe tener un registro de sus archivos de configuración y dónde están para fines de recuperación de desastres, ¿verdad? No olvide los archivos crontab si tiene contraseñas, digamos.

La instalación de CentOS o cualquier solución de ramdisk es sólida. El kernel estará en la memoria, necesita dd y algo de contenido bin. Pero si reinicia en modo de recuperación, es posible que no tenga redes o SSH y se desconecte.

Nota: Kedare tiene una buena idea, y si está ejecutando desde ram en su próximo reinicio (ramdisk), esto es posible, es muy difícil recuperarse de las escrituras / dev / zero para empezar, por lo que realmente no agrega valor a menos que su vida depende de ello?

— mckenzm
fuente