Consegui percorrer todo o caminho até rm -rf --no-preserve-root / sem que o sistema falhasse primeiro e sem que nada fosse deixado na unidade.
Estou prestes a terminar meu relacionamento com meu provedor de hospedagem há muitos anos, mas gostaria de limpar a caixa com segurança antes de fazer isso. Este é um servidor dedicado rodando Debian em uma única unidade EXT3 e apesar de eu ter acesso root, não consigo inicializar mídia alternativa já que ele está sem cabeça em um rack em algum lugar.
Não preciso de vários passes, mas gostaria de limpar o espaço se possível. Basicamente eu gostaria de ir embora e ter certeza de não deixar nenhum dos meus dados pessoais para trás. Estou preocupado que a caixa possa falhar antes de terminar de limpar / sincronizar o sistema de arquivos se eu executar apenas srm -R -s /
O instalador do CentOS (anaconda) que vem com as imagens PXE inclui um servidor VNC, assim você pode alterar sua configuração do grub para inicializar o instalador do CentOS, passando as respostas para as perguntas do pré-estágio 2 instalador na linha de inicialização e depois VNC para o instalador.
Agora, se a minha memória me serve corretamente, de dentro desse instalador você deve ser capaz de acessar um shell, a partir do qual você pode acessar e destruir o disco.
Copie os arquivos vmlinuz e initrd do diretório PXE na distro CentOS ( link ) para / boot e modifique sua configuração do grub:
default 0 timeout 5 title 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
Incidentalmente, qualquer empresa de hospedagem decente deve estar preparada para destruir seus discos para você.
Antes de destruir o sistema operacional, você pode remover qualquer coisa sensível e zerofill (usando dd if = / dev / zero de = justabigfile).
E eu acredito que a maioria dos sistemas irá sobreviver a um dd para um sistema em execução o tempo suficiente para substituir o disco inteiro. Não há caminho de volta se isso não acontecer, claro.
Minha solução envolve uma abordagem em várias etapas, fazendo algumas das opções acima, mas também envolvendo um chroot in ram que deve permitir que o dd termine completamente de limpar o disco.
Primeiro, exclua todos os seus dados confidenciais, deixando os arquivos necessários para executar o sistema operacional. Então faça isso (não em um script, faça um comando de cada 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
Isso deve resolver isso!
O protocolo ATA possui um comando "secure erase", que, como seu nome indica, deve limpar com segurança todo o disco rígido.
Veja o artigo wiki do Kernel para detalhes, mas lembre-se dos avisos no topo:
Você pode usar apenas dd para sobrescrever a partição / disco inteiro em um servidor em execução sem preocupações. Nós o usamos muito no trabalho (quando o cliente não quer pagar pela destruição segura do disco físico).
Na verdade, você limpa os dados sem o sistema de arquivos montado sabendo disso, então o sistema de arquivos começará a pirar à medida que seus metadados forem sendo perdidos, então o sistema operacional começará a "desmoronar". No entanto o que já está no cache ainda funciona. Então você pode monitorar o progresso via console remoto ou KVM (não tente via ssh). O sistema é mantido em execução mesmo após dd ter terminado, no entanto, nenhum comando funcionará e todos os daemons provavelmente já estarão mortos.
Eu uso esses comandos:
%código%
e, em seguida, dd if=/dev/zero of=/dev/sda bs=1M & para monitorar o progresso (dd imprimirá a velocidade atual e a quantidade de dados gravados). A configuração do tamanho do bloco ( kill -HUP %1 ) é muito importante para alcançar a velocidade de gravação do disco rígido com bs .
Cada vez que dd foi capaz de limpar o disco e consegui emitir o comando dd (shell integrado) até o final. Se você tiver invasão de software, poderá limpar o próprio dispositivo kill ou cada dispositivo componente individualmente.
Você pode tentar escrever dados aleatórios em seu disco da seguinte forma:
dd if=/dev/urandom of=/dev/sda
É mais seguro do que usar / dev / zero porque ele grava dados aleatórios, mas também é MUITO mais lento.
Qualquer coisa que você escolher fazer, entrar em outro provedor e testá-lo.
Obtenha uma instância semelhante na AWS (ou gcloud ou ...) e tente lá, mantendo o disco e, em seguida, anexando-o a outra instância como armazenamento adicional e analisando-o. dd se = sdb | hd
Apenas sobre todo o seu material confidencial deve estar em
/home
/opt
/var
/etc
/usr
São os arquivos de configuração com senhas incorporadas que incomodam a maioria das pessoas. Se você sabe o que são, pesquise todo o sistema de arquivos para erradicá-los.
O rm irá apagar arquivos, mas um editor hexadecimal ainda lerá o disco. Então, zero depois. Dê uma olhada no fragmento. Você deve ter um log de seus arquivos de configuração e onde eles estão para fins de DR, certo? Não esqueça os arquivos crontab se você tem senhas nesses, digamos.
A instalação do CentOS ou qualquer solução de ramdisk é boa. O kernel estará na memória, você precisa de dd e algum conteúdo de bin. Mas se você reiniciar no modo de recuperação, você pode não ter rede ou SSH e se desligar.
N.B. Kedare tem uma boa idéia, e se você está rodando a partir de sua próxima reinicialização (ramdisk) isso é possível, é muito difícil se recuperar de / dev / zero para começar, então realmente não agrega valor a menos que sua vida dependa sobre isso?