Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Not to belittle or chide anyone but one should note the standard mentioned that doesn't argue for different methods (or which incineration is just one) and n passes to be used because it's "good", it's about uniformity, quality and certainty. And wrt to standards and threads about wiping data one thing that's often overlooked is the verification stage: you can use all sorts of n passes schemes but if you fail to verify the result, the task isn't finished. One could argue it's a rule only people who handle classified or sensitive data work with, but IMHO it is just common sense to make certain the data is gone.
Also note there's a fast alternative to /dev/urandom called frandom (not for crypto purposes):
An empty, wiped disk would raise some suspicions all by itself that a disk with innocuous data would not.
If you seize a disk anywhere out of its factory-sealed packaging, knowing the seizure location and the fact disks leave the factory patterned, then from an investigative point of view that's a very good observation. Next to emptied disks the ones that contain b0rken filesystems or containing patterned locations are the easiest way to spot "interesting" usage.
If you seize a disk anywhere out of its factory-sealed packaging, knowing the seizure location and the fact disks leave the factory patterned, then from an investigative point of view that's a very good observation. Next to emptied disks the ones that contain b0rken filesystems or containing patterned locations are the easiest way to spot "interesting" usage.
It is negative information. You could just be looking at a privacy advocate who takes steps beyond the ordinary...just because.
And I would love to see the prosecutor: "Your Honor, we are sure this suspect was up to no good because his hard drive was wiped and patterned. We know he was doing bad things because there was no evidence..."
Of course, in the current Orwellish environment, that might just happen...
Speaking just for myself, every now and then I fill up my /home and my / directories with a file in /tmp, and one in ~/tmp, that I fill from /dev/null, then delete, then fill from /dev/urandom - and I set it to run dd until the drive is full.
Ain't perfect, but should get rid of anything that I deleted.
When I needed to send my hard disk back to Dell when it failed, I cleaned it with this: http://abaababa.ouvaton.org/wipe/ which is conveniently located in the Ubuntu repositories. The disk was 230 GB and it took all night and into the morning to complete all 8 passes.
You'll obviously want to read through the manual page to see what the options are all about, but I'm pretty sure if you apply the default settings to a full hard disk, and have the time to wait, that your data will be irrecoverable.
I mean, what do you really have on there anyway? If someone is capable of getting your stuff after 8 passes it means they have a lot of money and really really want it. No one (no government/military) is going through all that trouble for your cookies or even for some financial information. If you have data that is that seriously private then you need to disassemble the hard disk, burn it, and bury the parts over a number of hard to find locations. Then station a loyal troll to protect each of said locations.
You could just be looking at a privacy advocate who takes steps beyond the ordinary...just because.
What you've given there is a possible explanation. When you investigate things you have to be careful to deal with facts only and not let personal perception, opinion, influence what you (think you) are seeing. There are settings where regulations and policies mandate wiping. Most of the time those will be formally documented and accompanied by an auditing trail. Cutting things short, if there's no regulations or policies in effect then wiping data requires the user to have knowledge of wiping data as a solution and be technically knowledgable enough to chose a tool and perform the wiping. True, that is not a conclusion or rocket science but simply an observation that could trigger a more in-depth investigation.
Quote:
Originally Posted by jiml8
And I would love to see the prosecutor: "Your Honor, we are sure this suspect was up to no good because his hard drive was wiped and patterned. We know he was doing bad things because there was no evidence..."
You don't have to be a lawyer to see that's cutting things a wee bit too short. Humourous nonetheless.
Cutting things short, if there's no regulations or policies in effect then wiping data requires the user to have knowledge of wiping data as a solution and be technically knowledgable enough to chose a tool and perform the wiping. True, that is not a conclusion or rocket science but simply an observation that could trigger a more in-depth investigation.
Agreed. But presuming that the person being investigated is competent (and wiping data is evidence of competence) then the more in-depth investigation should lead noplace.
Also, the more in-depth investigation might be constrained by either time, funds, or the interest of the relevant authorities, based upon the severity of the suspected problem.
Bottom line is that a private individual (or organization) who has any reason at all to fear that any of his personal data on his computer could be compromising in any fashion should wipe hard drives. If this causes the authorities to become suspicious, so be it.
I once was hauled before Immigration and Naturalization Service because I married a foreigner. "We are going to investigate your marriage to make sure it is not a sham to get her papers". The interviewer started asking me questions. My answers came slower and slower as the questions got more personal. Finally I told the interviewer that I would answer no further questions.
The interviewer became irate: "Why won't you answer my questions? What do you have to hide?"
My response: "This interview is OVER, you f---ing NAZI!!! I WILL NOT PERMIT A GOVERNMENT FUNCTIONARY TO SPEAK TO ME IN THIS FASHION. I WILL SPEAK TO YOUR SUPERVISOR RIGHT NOW!!!". And I did. And I reamed him, and his flunky: "How DARE THIS BITCH SPEAK TO ME THIS WAY??? YOU WILL NOT INVADE MY PRIVACY. YOU WILL NOT SUGGEST THAT MY INSISTENCE THAT YOU KEEP YOUR BUREAUCRATIC NOSE OUT OF MY BUSINESS SUGGESTS THAT I AM DOING ANYTHING AT ALL WRONG. I will remind you of the law of the land: I am innocent until proven guilty. If you can come up with ANY EVIDENCE AT ALL of wrongdoing by me, then you may approach me. Until that time stay the F*** OUT OF MY FACE AND OUT OF MY WAY."
He took it; he had no choice. My wife got her permanent visa, and later her citizenship.
The point is that they can be as suspicious as they want. But in the US anyway (at least, pre-Patriot Acts) suspicion gets them nothing. They need evidence.
But presuming that the person being investigated is competent (and wiping data is evidence of competence) then the more in-depth investigation should lead noplace.
"Should" does not equal "state with onehundred percent certainty" and so, without knowing the strategy and inventory of the theoretically seized items and even if just an exercise, that is an assumption and one I can not support.
Quote:
Originally Posted by jiml8
Also, the more in-depth investigation might be constrained by either time, funds, or the interest of the relevant authorities, based upon the severity of the suspected problem.
...or be sped up by certain persons forgetting to wipe their sticks, long-forgotten slash off-site backups, et cetera ;-p
The only disk that is most likely impossible to recover data is the one that has turned to dust. I use to work for a data recovery company, it was amazing the data they pulled from drives that had been wiped, damaged, burned and so on.. So wipe all you want, there's someone out there that can recover something from it.
Distribution: Mint 20.1 on workstation, Debian 11 on servers
Posts: 1,336
Original Poster
Rep:
Quote:
Originally Posted by jiml8
But in the US anyway (at least, pre-Patriot Acts) suspicion gets them nothing. They need evidence.
...Unless it's the RIAA or other copyright type company. :/ It makes me sick to the stomac the stuff they get away with.
also this is something wacked I thought of, but given /dev/random and /dev/urandom generate random data based on stuff going on in the system, is there a possibility of it writing say, memory? I could see using this method being dangeraus, and using a set of patterns being more secure.
Sure I'm being paranoid, but I just like considering these type of things. I rarely sell/give HDDs away, only time I'll really get rid of one is if it fails, and I usually just physically destroy it because its fun.
Also using dd how do I manage to output a pattern, but make it repeat?
if I do something like
dd if=pattern1.txt of=/dev/hda
it will just copy pattern1 once. I don't want to have to generate a 500GB file, I want to make like a 100 byte one, then have it repeat.
Also using dd how do I manage to output a pattern, but make it repeat?
Of all the dd-related tools 'dcfldd' is the only one which has a builtin "pattern" and "textpattern" option (see the manual), for others (at least with 'dd') you can echo the pattern and pipe it through it.
As I understand it, the only reason that anyone wipes anything twice+ is because of floppies. It was a medium that could leave magnetic traces behind, and made data recoverable in theory.
Hard disk drives that are wiped one time with zero's/random data have never been successfully recovered -- there is no proof anywhere that it has happened. I think its just a relic of the floppy disk/magnetic media days and a continued urban legend propagated by paranoids.
Last edited by szboardstretcher; 04-28-2014 at 02:49 PM.
There is no proof that you can recover anything even wiping with /dev/zero. However, for the extra paranoid the best option is to encrypt the entire HDD. Multiple runs of a PRNG don't add significant extra security, because PRNGs are not cryptographically secure. Mersenne twister is the most common PRNG used and it can be entirely predicted using 624 consecutive outputs. https://blog.spideroak.com/201212051...n-ruby-and-php
So, if you were able to look at the HDD and identify the bits that were there previously and recover them all (supposedly it can be done, but is extremely tedious), then all you would have to do is decypher the data, which is easy for Mersenne twister, but difficult if it is encrypted.
As I understand it, the only reason that anyone wipes anything twice+ is because of floppies. It was a medium that could leave magnetic traces behind, and made data recoverable in theory.
Hard disk drives that are wiped one time with zero's/random data have never been successfully recovered -- there is no proof anywhere that it has happened. I think its just a relic of the floppy disk/magnetic media days and a continued urban legend propagated by paranoids.
No - it used to work in the really old days. The way disks worked (using a linear recording), left large gaps between tracks. Because the mechanics of head movement, two separate seeks almost never got exactly the same location... so different seeks would be offset slightly in different directions.
Disk drives even has sub-track positioning capability (on the CDC 9600 specifically I know had this) with up to 20 offset positions on either side of the center of the track. You could actually have a complete track recorded by using offset 20 and offset -20... but there could be some bleed over. Using the offsets was a way to attempt to recover from a read error. A sector was never identified as bad, unless all 41 reads (using all possible offsets + the center). If one of the passes worked, then the sector was good.
Making a single pass overwrite would not remove the possibility of recovering prior data by looking at the extreme offsets. Prior data could more easily be retrieved using specialty equipment that had higher resolution than that available to the general head positioning mechanics. (besides just the surface reading, the magnetic domain also had a depth dimension where the surface could be removed, then the domains underneath retrieved). So using multiple overwrites would count on the seek imprecision to write to slightly different locations...
Most of this died when disk manufacturing switched from horizontal recording to vertical recording (the depth field vanished), and the higher precision of of head positioning (and incredibly smaller size of the magnetic domain grains) has made multiple overwrites mostly unnecessary.
What remains though are bad sectors - these are never overwritten, and can still carry sensitive information. Thus the process of removing the platters, degaussing, and grinding to powder is the final method.
[snip]
What remains though are bad sectors - these are never overwritten, and can still carry sensitive information. Thus the process of removing the platters, degaussing, and grinding to powder is the final method.
Out of curiosity, why can't bad sectors be written to? Is it something that the OS is currently incapable of, or does the HDD itself prevent you from doing it?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.