How to delete all data from the server without the possibility of recovery?

Question

linux

There is a task to erase all data on a remote server (dedicated).
iLO and something like that is not. There is access via SSH and the likelihood that the server may never start again if it is restarted.
The migration from the server was successful, but the task is to delete all data from it so that there is a minimum chance of recovery. I decided to do it in two stages:
1. I delete the directories where the data that needs to be deleted first is stored:
rm -rf /catalog/path
2. I look at which drive is in the root

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       150G   100G   50G  60% /

3. I run after that, I will most likely be thrown out of `ssh` How reckless is the solution? Are there any more reliable ways? Thanks
dd if=/dev/urandom > /dev/sda3 &

Answer 1

The method is more reliable than a simple dd over ssh:

mkdir /target
mount none -t tmpfs -o size=1G /target/
debootstrap stable /target/ https://deb.debian.org/debian/
echo "Killer_system" > /target/etc/debian_chroot
chroot /target
mount none -t proc /proc/
mount none -t sysfs /sys/
mount none -t devtmpfs /dev/
mount none -t devpts /dev/pts/
apt install openssh-server
echo "Port 11122" >> /etc/ssh/sshd_config
echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
/etc/init.d/ssh start
passwd root

Now connect to ssh running from RAM: Distort
the disk:

echo 1 > /sys/block/sda/device/delete
for i in /sys/class/scsi_host/host?/scan ; do echo "- - -" > $i ; done

Now sda will become sdb
At the end of the job:
This will restart the server, but of course it won't boot.
Unlike the previous method, we can wait 100% for dd to complete

Answer 2

shred nwipe bleachbit

Answer 3

Normal hosting providers back up user data. So there certainly is (should be) a backup that you will not erase in principle.
As a rule, hosting has the ability to reinstall the system from scratch. It makes sense to do so, and install it in a small partition, so that only it fits. Then almost all sectors of this partition will be overwritten.
Then we overwrite the free space of the disk. And just in case - overwrite the partition with the system.
PS: Here's another reason to put the system in one partition, and keep the data in another partition.

Answer 4

1. You can run the shred (for files) and wipe (for folders) commands over important data that you want to bang with a guarantee, but there really is no need to do the rest.
2. You can write dd in crontab so that it runs at a certain time.
3. You can write dd to .bash_logout so that it will be executed when you exit the console (for example, the ssh session ends).
4. You can create a service that deletes all data, make it active in reboot/shutdown mode and send the server to reboot, from which it will not return.

Answer 5

What prevents you from deleting all critical data from the server and clearing free space with any wiper?
What's the point of deleting it completely? Leave a working OS - there will be nothing secret left in the cleaned system - except root password hashes and the like.

Answer 6

The author correctly wrote in the first post.
Random noise recording is better than any movies. And faster.
You can add a semicolon-separated sequence of disk-duplications for all disks in the system.
Throws out or not from ssh no longer matters. 3 commands went into execution.

Answer 7

If your server's disk supports OPAL, just change the password. If not, and it's remote, you don't have a reliable way to destroy the data on it.
In principle, what you are going to do will work. And even from ssh you will most likely not be thrown out. Why would? But as Alexey Dmitriev
correctly noted, there is no point in erasing everything - it is better to erase only the important. The correct decision for Artem is to fill the disk with data to failure, but only after that erase the garbage again and again fill it to failure. Repeat 3-4 times this will give more confidence that the data cannot be restored than just dd. But there is no guarantee that the hoster has no backup copies left :)