New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Wiping disk before leaving? [kimsufi]
CreativeProjects
Member
in Providers
Has any of you tried to read the disk when he got his new kimsufi dedi? Are they wiping the disk for new customers automatically?
I'm about to release one and I'm not sure if I should wipe it or not (apart from all my ssh keys I've already "shred -n 42")
Comments
I've not tried with Kimsufi specifically, but here are a couple of some references:
https://www.lowendtalk.com/discussion/comment/2148573/#Comment_2148573 (read around for a bit of context/discussion).
https://www.lowendtalk.com/discussion/116047
Try that next time you buy a KVM VPS, the results may horrify you.
the right way to do this ( the next time) is setup dm-crypt luks layer before writing any data.
So, even if you miss a due date and lose the host , you can sleep well.
As far as I know, they do wipe disks. But you can always do something like this,
https://linux.die.net/man/1/shred
Will definitely do the next time.
It might not have worked well on the low end Atom processor though, but I'm not going to get another one of these CPU anymore
On a KS, since the network bandwidth is typically (at most) 100Mbps, giving you maximum of ~10MB/s, the disk is usually much faster than that and with there's enough CPU (left over) to do disk encryption (luks+dm_crypt) unless of course you're killing the CPU in which case...well you've picked the wrong KS :-)
For a laugh I tried sfill on default settings on a 4TB disk.
160GB wiped after 48 hours.
The defaults are significantly overkill and very random heavy so they are very slow.
Try a simpler setting (for mere mortals) that one random and one zero round. For most folks, a single pass zero write should be good enough. Of course when you're talking about a precious unique-in-the-world er... anime collection of course you may prefer NSA/CIA/MI5/MI6 defying tactics. YMMV.
be that from InceptionHosting. Is that in your AUP?
That they promise to provide you a thoroughly scrubbed disk? I've never seen that in any TOS or AUP.
Now that I think about it, I've never seen any promise to scrub data after you leave (in anyone's TOS/AUP), unless there's some generic data privacy language.
It's only possible when you rent the disks entirely. As long as it's shared, it's dead. That might explain it?
>
I figured that, but I'd never tried it (I'm not often well-organised to have the luxury of time to piss about before I have a server back) so I though I'd have a go.
Running sfill with the -fz options seems to be much quicker and should be enough, not that I don't trust the provider to clean the disks properly, but I just like to be thorough.
No, 99% of hosts using solusvm+KVM don't wipe/0 logical volumes after use, if someone buys the same package as the last cancellation the chances are you can literally boot the old customer's entire OS with minimal effort.
I rename and then 0 disk images after termination.
SolusVM when they were made aware of the issue simply released an 'improvement' (about a year later) which requires a manual edit of config files on a per node bases, pretty silly and it was not really covered in any detail so literally every host I have spoken to about it since has/had no idea.
This Thread/Discussion should give you some very useful and valuable inputs on the issue. One of the reasons I enjoy LET - one finds there are so many (interesting) ways "skin a cat" and yet all roads lead to Rome.
I misread the subject as "Wiping dick before leaving? [kimsufi]".
Guys, a note about wiping disks obsessively:
There is no known attack that can break a 1-pass wipe. Not even CIA/NSA type attack. The multiple-pass method was against a theorized attack developed in 1996 by a researcher, and he himself said there is no way to read data from the modern hardware after 1 pass. Current harddisk technology is already very densely packed and electron microscope method to read wiped data is not possible.
It doesn't matter if you write all 0's to the disk. It doesn't matter if you write all 1's. It doesn't matter if you write random bytes. All methods on the HDD will permanently wipe the data.
And SSD disks are even safer, they don't leave a magnetic trace and they can't be read by a microscope anyway. One time pass is perfectly secure. SSD drives prefer all 1's when you wipe, that makes the drives faster for the next customer, while still perfectly clean and secure.
I like to leave a copy of my linux ISOs for the next customer.
I asked OVH support about this by email a while back and they said they definitely wipe every drive after cancellation.
Not really. There are some SSDs (e.g. based on the SandForce controllers) which compress data on the fly, and if it's compressible, they can write much less to flash than the amount that is coming from the host computer (improving performance and saving flash wear). So if you write all 0s or all 1s, perhaps 1/1000th of the area of the flash is going to contain the tightly compressed zeroes or ones, and the rest is going to contain guess what, old data.
Some other models don't use actual compression, but just have a special-case detection for a stream of zeroes. Perhaps writing all 1s would work on those.
Fair enough, I didn't know the latest advancements. Although, when the data is compressed, if the next customer wants to read some sectors, the same controller will return zeroes too, I guess, instead of the old data. An entirely different controller may be required to read inaccessible sectors. To prevent that, random/non-compressible data may be a better option.
In either case, I doubt the next customer can read the inactive sectors. The controller returns zeroes for all sectors, when the OS requests data. It does the compression internally, and doesn't let the OS know or do anything about it.
I don't know if there is a software switch to enable/disable this controller compression. From the article you linked to, I didn't get the impression that the controller will allow the OS to decide what to do.
But if we are talking about wiping the data to prevent forensic analysis with a custom controller, then random-data wipe will surely take care of the problem. If we are only considering "the next customer", then all 1's or all 0's should still suffice.
Lots of SSD's and HDD's now have a secure erase command. Basically the data on the drive is all encrypted by a key that's inside the drive. The secure erase command wipes the key and generates a new one, so the old data instantly becomes inaccessible.
Why 1s instead of 0s? Pure curiosity.
DBAN works great if you want to mount an ISO and run it.
https://sourceforge.net/projects/dban/files/dban/dban-2.3.0/dban-2.3.0_i586.iso/download
SSDs have write operations quite different from HDD operations. When you write, they read the block, copy its contents to another block with updated data, and mark the old block for garbage collection. some details here
Writing also requires erasing the new block and writing the new content. SSDs can't just update a block, they need to erase it first and write later. The TRIM feature works by pre-erasing old blocks while the disk is idle, so the next time you will write to a block, it's already erased. This erase is done by setting all the bits to 1, for some reason, not 0. If you write a full disk with 1s, and then erase the file, the OS marks it as erased, but the SSD doesn't know it's full of 1s, so it still requires TRIM. There is no performance advantage here.
But RAID configurations do not enable TRIM for some reason, so the SSD never gets cleaned (unless the raid controller implements its own TRIM), and every new write requires setting all the bits to 1 first.
Assuming that hosting/server solutions implement RAID most of the time, TRIM isn't used, and setting every bit to 1 manually will make the blocks write faster the next time. Also, writing 0s means the disk will write 1s first (to clean the block), then write 0s.
Of course, once the new customer writes some data, the advantage is gone. It usually helps only with the initial OS installation and first few days of writes.
The difference is marginal, you may need to run some benchmarks to see the few percent difference, but if you have the choice of writing 1s or 0s, there is a small advantage to use 1s.
Another problem is the encrypted disks. If the SSD has internal encryption for the secure erase function, it doesn't just use your 1s, it writes an encrypted result. You don't get a performance upgrade at that point. If it has compression, again, it will write a small file and leave the rest intact. But there is a chance the disk doesn't implement either of these features, and writing 1s help. If it does implement either of these, you can't really control what it writes, but choosing 0 instead of 1 has no advantage, so you can use 1s.
But if the disk has compression, as I've recently learned about, writing random data will be the most secure way to overwrite all blocks, instead of sequential 1s or 0s.
RAID being only HW RAID or Fake Raid/Soft Raid included?
So many implementation differences.
https://serverfault.com/questions/763271/raid-in-ssd-issue-with-trim
Did they specify how they wipe the drives at all that you can remember? They are pretty procedural, so I'd expect all to be handled nearly the same with their brands, but that doesn't mean they don't just delete the partitions and called it "wiped".
Hey, are you that guy called "imthatguyhere" at WHT too?
Probably booting a PXE "wipe" image like other providers do when the server is terminated.