Я успешно добрался полностью через rm -rf --no-preserve-root /
без системы, отказывающей сначала, и ни с чем оставляемым на диске.
Установщик CentOS (анаконда), которая поставлется с изображениями PXE, включает сервер VNC, таким образом, можно изменить конфигурацию личинки для начальной загрузки установщика CentOS, передав ответы на вопросы об установщике перед этапом 2 на строке личинки, перезагрузке и затем VNC к установщику.
Теперь, если моя память служит мне правильно, из того установщика необходимо смочь опуститься до оболочки, от которой можно получить доступ и уничтожить диск.
Скопируйте vmlinuz, и initrd файлы от dir PXE в дистрибутиве CentOS (http://mirror.centos.org/centos/5/os/i386/images/pxeboot/) к / загружают и изменяют Вашу конфигурацию личинки:
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
Кстати, любая достойная хостинговая компания должна быть готова уничтожить Ваши диски для Вас.
Перед уничтожением ОС, Вы могли удалить что-либо чувствительное и заполнить нулями (использующий dd если =/dev/zero of=justabigfile).
И я полагаю, что большинство систем будет переживать dd к рабочей системе достаточно долго для перезаписи всего диска. Нет никакого пути назад, если это не делает, конечно.
Мое решение включает в себя многоэтапный подход, выполняющий некоторые из вышеперечисленных, но также с использованием chroot в оперативной памяти, который должен позволить dd завершить полную очистку диска.
Сначала удалите все ваши конфиденциальные данные. data, оставив необходимые файлы для запуска операционной системы. Затем сделайте это (не в сценарии, выполняйте по одной команде за раз):
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
Это должно решить эту проблему!
Вы можете просто использовать dd
для перезаписи всего раздела / диска на работающем сервере без каких-либо проблем. Мы часто используем его на работе (когда заказчик не хочет платить за безопасное уничтожение физического диска).
Вы фактически стираете данные, не зная об этом смонтированная файловая система, поэтому файловая система начнет нервничать, поскольку ее метаданные будут потеряны , то сама ОС начнет «разваливаться». Однако то, что уже есть в кеше, все еще работает. Таким образом, вы можете следить за прогрессом через удаленную консоль или KVM (не пробовал через ssh). Система продолжает работать даже после завершения dd
, однако ни одна команда не будет работать, и все демоны, вероятно, уже мертвы.
Я использую эти команды:
dd if = / dev / zero of = / dev / sda bs = 1M &
а затем kill -HUP% 1
для отслеживания прогресса (dd распечатает текущую скорость и количество записанных данных). Установка размера блока ( bs
) очень важна для достижения скорости последовательной записи жесткого диска с помощью dd
.
Каждый раз, когда dd
мог стереть диск до конца, и я смог выполнить команду kill
(встроенная оболочка) до конца. Если у вас есть программный рейд, вы можете стереть либо само устройство md
, либо каждое компонентное устройство по отдельности.
В протоколе ATA есть команда "безопасного стирания", которая, как указывает ее название, должна безопасно стереть весь жесткий диск.
Подробности см. В вики-статье о ядре, но не забывайте о предупреждениях. вверху:
Что бы вы ни выбрали, обратитесь к другому провайдеру и проверьте его.
Получите аналогичный экземпляр на AWS (или gcloud, или ...) и попробуйте его там, сохранив диск, а затем подключив его к другому экземпляру в качестве дополнительного хранилища и сканируя его. dd if = sdb | hd
Практически весь ваш конфиденциальный материал должен быть в
/home
/opt
/var
/etc
/usr
. Большинство людей беспокоят файлы конфигурации со встроенными паролями. Если вы знаете, что они собой представляют, выполните поиск по всей файловой системе, чтобы искоренить их.
rm удалит файлы, но шестнадцатеричный редактор все равно будет читать диск. Так что ноль потом. Взгляните на клочок. У вас должен быть журнал ваших файлов конфигурации и где они находятся для целей аварийного восстановления, верно? Не забывайте файлы crontab, если, скажем, в них есть пароли.
Установка CentOS или любое решение ramdisk работает нормально. Ядро будет в памяти, вам понадобится dd и немного содержимого bin. Но если вы перезагрузитесь в режиме восстановления, у вас может не быть сети или SSH, и вы отключитесь.
N.B. У Kedare есть хорошая идея, и если вы работаете с оперативной памятью при следующей перезагрузке (ramdisk), это возможно, очень сложно восстановить после записи / dev / zero для начала, поэтому это не добавляет ценности, если ваша жизнь не зависит на это?