LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   Looking for Hard Drive Utility To Provide Proof Of Wipe (https://www.linuxquestions.org/questions/linux-software-2/looking-for-hard-drive-utility-to-provide-proof-of-wipe-4175668637/)

finalturismo 01-29-2020 02:07 PM

Looking for Hard Drive Utility To Provide Proof Of Wipe
 
I have a current opportunity in my hands based on a automated hard drive wiper i made with basic bash and udev commands. One of the requirements i must fulfill is to provide proof that the hard drives have been wiped.

Are there any open source utilities that can get this job done? I need to be able to add the data in a 1 line item.




Here is an example of my automated hard drive log. The columns did not like my copy and past -.-
Drive# Date/Time DriveLetter Temp Health TMP Model Serial MB
1 2018/07/10-18:08:31 /dev/sdf 18 ? 45317 ST31500341AS 9VS0GWB6 1430799
2 2018/07/10-18:36:16 /dev/sdam 20 ? 13277 WDC_WD3200AAJS-08L7A0 WD-WCAV2V120105 305245
3 2018/07/10-19:55:58 /dev/sdk 20 100 26131 SEAGATE_ST600MP0005 S7M0T0JY 572325
4 2018/07/10-19:55:59 /dev/sdh 20 100 26129 SEAGATE_ST600MM0088 S420NL4F 572325
5 2018/07/10-19:55:59 /dev/sdj 20 100 26131 SEAGATE_ST600MP0005 S7M0SV5L 572325
6 2018/07/10-19:55:59 /dev/sdp 21 100 27733 SEAGATE_ST600MM0088 S42017MJ 572325
7 2018/07/10-19:55:59 /dev/sdx 20 100 26129 SEAGATE_ST600MM0088 S420NKH1 572325
8 2018/07/10-19:56:14 /dev/sdac 19 100 24927 SEAGATE_ST600MM0088 S420MF1Y 572325
9 2018/07/10-19:56:14 /dev/sdy 19 100 26103 SEAGATE_ST600MM0088 S420NP2T 572325
10 2018/07/10-19:56:19 /dev/sdaf 20 100 26706 SEAGATE_ST600MM0088 S4202HV2 572325
11 2018/07/10-19:56:22 /dev/sdae ? ? 4920872 SanDisk_LT0200MO 423466960000ags/T43P 190782
12 2018/07/10-19:56:57 /dev/sdai 19 100 24879 SEAGATE_ST600MP0005 S7M0RNTJ 572325
13 2018/07/10-19:56:57 /dev/sdt 20 100 26131 SEAGATE_ST600MP0005 S7M0T09M 572325
14 2018/07/10-19:57:02 /dev/sdal 20 100 26131 SEAGATE_ST600MP0005 S7M0T0AH 572325
15 2018/07/10-19:57:22 /dev/sdam 20 100 26103 SEAGATE_ST600MM0088 S420NNRQ 572325
16 2018/07/10-19:57:31 /dev/sdan 19 100 26131 SEAGATE_ST600MP0005 S7M0SXEM 572325
17 2018/07/10-19:58:04 /dev/sdap 20 100 26131 SEAGATE_ST600MP0005 S7M0SV6L 572325
18 2018/07/10-20:02:59 /dev/sdw 21 100 24948 SEAGATE_ST600MM0088 S420MEP0 572325
19 2018/07/10-20:03:15 /dev/sdaq 21 100 27733 SEAGATE_ST600MM0088 S4108C4N 572325
20 2018/07/10-20:20:58 /dev/sdat 20 100 47429 WDC_WD2500AAKX-753CA1 WD-WMAYW2921274 238475
21 2018/07/17-19:25:19 /dev/sdd 23 100 20481 WDC_WD3200AZKX-00D6NA0 WD-WMC1S0595773 305245
22 2018/07/17-19:28:08 /dev/sdg 24 100 27988 ST3160815AS 6RX2DKVY 152628
23 2018/07/17-19:29:40 /dev/sdh 23 100 54406 WDC_WD2500AAJS-75M0A0 WD-WMAV2EA74134 238419
24 2018/07/17-19:32:45 /dev/sdi 22 100 55228 ST3250312AS 5VY64PWR 238475
25 2018/07/17-19:37:11 /dev/sdj 22 100 45709 ST250DM000-1BD141 9VYLX0E2 238475
26 2018/07/17-19:37:37 /dev/sdk 22 100 9887 ST250DM000-1BD141 Z6E8KXEE 238475
27 2018/07/17-19:39:29 /dev/sdl 24 100 25166 ST500DM002-1BD142 Z6E43PS0 476940
28 2018/07/17-19:41:21 /dev/sdm 23 100 7085 WDC_WD10EACS-00ZJB0 WD-WCASJ0367212 953870
29 2018/07/17-19:56:32 /dev/sdo 24 6 65279 ST31500341AS 9VS0PX9M 1430799
30 2018/07/17-19:56:32 /dev/sdp 23 13 62757 ST31500341AS 9VS4PHSH 1430799
31 2018/07/17-20:00:03 /dev/sdp 22 100 42142 ST3160318AS 6VMFHMEW 152588
32 2018/07/17-20:00:05 /dev/sdo 24 ? 31288 ST31000525SV 6VP4GW9S 953870

sevendogsbsd 01-29-2020 02:16 PM

Well, would proof be that you cannot pull any data from the drive? In the future, please post long code segments like that using the forum's "[CODE]" tags to make it easier for everyone to read.

273 01-29-2020 03:01 PM

Quote:

Originally Posted by sevendogsbsd (Post 6084209)
Well, would proof be that you cannot pull any data from the drive? In the future, please post long code segments like that using the forum's "[CODE]" tags to make it easier for everyone to read.

This.
The only way to prove the data was erased is to list the entire drive contents afterwards and they just be 0s (because random overwrites are meaningless). Oh, and SSDs don't count -- you need to either overwrite with 0s and trust that nobody can access any cells not set to 0 or use the built-in wipe and trust that.

sevendogsbsd 01-29-2020 03:17 PM

I think I read somewhere the only sure way to wipe an SSD was with a hammer...

OP could use something like photorec/testdisk to scan the entire driver after the fact to see if any files can be pulled. Still not as powerful as professional forensics data retrieval software but not sure OP's goal.

michaelk 01-29-2020 03:30 PM

One could state the only sure way to securely wipe any drive is with a hammer... I would assume that most SSDs these days have the built in capability of secure erase. This resets the drive back to its "out of the box condition" including the extra memory for wear leveling. I believe that normally since flash reset state is a 1 that after a secure erase the SSD drive will be all 1s.

It depends what procedure you are using to wipe hard drives drives and their final wiped state. A random value would be difficult to test. If zero, you could compare via the cmp command with /dev/zero. With a secure erase you typically need to set a password and upon completion of the secure erase the password is reset. Not sure if that is enough proof to state the drive was wiped.

jefro 01-29-2020 04:06 PM

We used to use a VHS eraser.

Maybe set all to zero and do a dd to file and use it as proof. The dd file will be very small on gzip if zeroed out.



A secure way is (edit "was") something like 9 times.

michaelk 01-29-2020 06:09 PM

In the old days we used a 9 track tape degausser which had a much bigger magnet then a VHS eraser...

It ultimately depends on what security standard if any your trying to to fulfill. In the US overwriting is no longer acceptable, the DoD standard is either destruction or degaussing but that does not work for SSDs. I don't know if the DoD security manual has been updated recently.

273 01-30-2020 01:17 PM

michaelk mentions a good point -- to erase an SSD it, perhaps, should be set to all ones. I say this because any controller is going to see "set to 0" as "pretend has no data". Hence the mention of "secure erase" in the post also.
If you're not a state-level business or a paedophile then any "secure erase" is likely enough to be negligible risk. By the way, that's not a "no guilt nothing to fear" that's an opinion based upon financial considerations (the ones which rule most of our lives) -- nobody will spend tens of thousands of dollars for one social security number unless it's guaranteed to net more.

Timothy Miller 01-30-2020 01:28 PM

At my company, I use a script using shred that mounts network shares and the last line is the log that outputs:

Code:

shred -vfz -n 3 /dev/${drivename} 2> >(tee /tmp/temp.txt) && grep "0%" /tmp/temp.txt >> /mnt/${serial}-${user}.txt

echo "Shred finished at $(date)" >> /mnt/${serial}-${user}.txt

This does a 3 pass shred outputing the pc's serial number and who ran the shred (it requires you to log in with your network credentials to run) with a every 10% log in the file followed by full date of when it finished.

273 01-30-2020 01:38 PM

Quote:

Originally Posted by Timothy Miller (Post 6084561)
At my company, I use a script using shred that mounts network shares and the last line is the log that outputs:

Code:

shred -vfz -n 3 /dev/${drivename} 2> >(tee /tmp/temp.txt) && grep "0%" /tmp/temp.txt >> /mnt/${serial}-${user}.txt

echo "Shred finished at $(date)" >> /mnt/${serial}-${user}.txt


This does a 3 pass shred outputing the pc's serial number and who ran the shred (it requires you to log in with your network credentials to run) with a every 10% log in the file followed by full date of when it finished.

Only issue I see with that is you're unnecessarily writing to the drive, wearing sectors, with no gain.
Is there evidence of how well shred works on SSDs? I'd also wonder about some wear-levelling stuff end up only overwriting empty space, or something (this, I have no citations for).

Timothy Miller 01-30-2020 01:41 PM

Quote:

Originally Posted by 273 (Post 6084566)
Only issue I see with that is you're unnecessarily writing to the drive, wearing sectors, with no gain.
Is there evidence of how well shred works on SSDs? I'd also wonder about some wear-levelling stuff end up only overwriting empty space, or something (this, I have no citations for).

There is no evidence that I'm aware of. We're doing this strictly so that we have proof of drives being wiped securely, which as I read the OP's is what they're looking for as well.

273 01-30-2020 01:45 PM

Quote:

Originally Posted by Timothy Miller (Post 6084569)
There is no evidence that I'm aware of. We're doing this strictly so that we have proof of drives being wiped securely, which as I read the OP's is what they're looking for as well.

Fair enough but without citations how do you know it is actually working? Saying "the script says it erased all data" is not proof.
You are probably correct in that your script will likely satisfy managers but, and I mean no offense, it's not proven to do anything. Well done with the manager thing though. ;)

Timothy Miller 01-30-2020 02:02 PM

Quote:

Originally Posted by 273 (Post 6084570)
Fair enough but without citations how do you know it is actually working? Saying "the script says it erased all data" is not proof.
You are probably correct in that your script will likely satisfy managers but, and I mean no offense, it's not proven to do anything. Well done with the manager thing though. ;)

By the same token there's no true PROOF when using any of the proprietary software, just the software's word that it did what it said. But the DOD is satisfied with it...and we have no need of DOD level wiping. We're just doing it to be proactive.

Red Squirrel 01-30-2020 10:31 PM

It's kinda dirty, but you could use hexdump. By default it will stop outputting when there's all 00's and then just do a summary. I've never tried to hexdump an entire hard drive before though and I'm not in a position to test that now (with a wiped one) but worth a shot.

You could then write a script that just looks at the output to make sure there's no non zero values within the dump part.

This won't prove that the data can't be recovered with a special electromagnetic microscope or something, but it will prove from a logical point of view that it's wiped.

for HDDs I like to use the shred command with lot of random data followed by zeros. For SSDs, I'm honestly not sure what is better and I think the tech is too new for anyone to really have a good idea, but my train of thought is to take a "good enough" approach and do maybe 2-3 passes max. This should hopefully ensure that you get all the redundant flash (SSDs often overprovision flash so it lasts longer) while not wearing it out TOO bad.

Personally for SSDs, I would just keep them until they are fully worn out. You can always find a use for a SSD in a build. Saves you from worrying about doing a secure erase.

273 01-31-2020 12:49 PM

Quote:

Originally Posted by Timothy Miller (Post 6084578)
By the same token there's no true PROOF when using any of the proprietary software, just the software's word that it did what it said. But the DOD is satisfied with it...and we have no need of DOD level wiping. We're just doing it to be proactive.

So you agree with me?
The DoD wipe is a fallacy but one known to work on spinning rust as well as just writing zeros once. It's actually been proven and acknowledged by the guy who came up with it himself.
SSDs, is there DoD standard? My guess is it's destruction my force and/or fire?


All times are GMT -5. The time now is 02:23 PM.