new posts
This commit is contained in:
parent
924200ca57
commit
7e3f51fc47
29
content/tech/HDD_wipe_101.md
Normal file
29
content/tech/HDD_wipe_101.md
Normal file
@ -0,0 +1,29 @@
|
||||
+++
|
||||
title = 'HDD wipe 101'
|
||||
date = 2024-12-12
|
||||
image = 'https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fwww.easeus.com%2Fimages%2Fen%2Fscreenshot%2Fpartition-manager%2Fphysical-damage.png&f=1&nofb=1&ipt=52e03fc20edc108b7cee49cacbc26b1810547f9641f1b29f0de79ebcc2ada00a&ipo=images'
|
||||
+++
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Secure wipe individual file
|
||||
|
||||
```sh
|
||||
shred -v -n 3 ./file
|
||||
```
|
||||
> Thou might not be secure if your filesystem use COW (copy-on-write) (like btrfs,zfs)
|
||||
|
||||
## Secure wipe entire drive
|
||||
|
||||
```sh
|
||||
shred -v -n 3 /dev/HDD
|
||||
# Or if you are paranoid - slower
|
||||
shred -v -n 7 /dev/HDD
|
||||
```
|
||||
> Long. Expect waiting a day or two.
|
||||
|
||||
Or...
|
||||
|
||||
![](https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fwww.easeus.com%2Fimages%2Fen%2Fscreenshot%2Fpartition-manager%2Fphysical-damage.png&f=1&nofb=1&ipt=52e03fc20edc108b7cee49cacbc26b1810547f9641f1b29f0de79ebcc2ada00a&ipo=images)
|
195
content/tech/HowTo_wipe_SSD.md
Normal file
195
content/tech/HowTo_wipe_SSD.md
Normal file
@ -0,0 +1,195 @@
|
||||
+++
|
||||
title = 'HowTo wipe SSD'
|
||||
date = 2024-12-11
|
||||
image = 'https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fi.imgflip.com%2F5fold8.jpg&f=1&nofb=1&ipt=57d5a7bd95d2cf08d7a126d00926f244038b58c47a130479233bd079c024a6f9&ipo=images'
|
||||
+++
|
||||
|
||||
![](https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fi.imgflip.com%2F5fold8.jpg&f=1&nofb=1&ipt=57d5a7bd95d2cf08d7a126d00926f244038b58c47a130479233bd079c024a6f9&ipo=images)
|
||||
|
||||
If you are using SSD and want to securely wipe it (so no one can recover data), then you are in a trouble since it isn't as easy as with [HDD](/tech/hdd_wipe_101) thou faster. <!--more-->
|
||||
|
||||
> Warning: Be *really* sure that you are wiping correct drive. If you are doing it in script, then find your drive in `/dev/disk/by-id` since linux can change `/dev/sdX` after reboot
|
||||
|
||||
> By the way. You can't just wipe individual file on SSD, it won't be removed securely.
|
||||
|
||||
## Level 1 - blkdiscard
|
||||
|
||||
```sh
|
||||
blkdiscard -v /dev/SSD
|
||||
```
|
||||
|
||||
### Verify
|
||||
|
||||
```sh
|
||||
echo 3 > /proc/sys/vm/drop_caches
|
||||
cmp /dev/zero /dev/SSD
|
||||
# expected result: EOF on /dev/SSD
|
||||
```
|
||||
|
||||
pros:
|
||||
- Just works on any SSD
|
||||
- Done in a blink of an eye
|
||||
- Scriptable (just add `-f`)
|
||||
|
||||
cons:
|
||||
- Not secure, data still can be recovered.
|
||||
`blkdiscard` will tell SSD to wipe blocks, SSD should put them to TRIM queue and wipe them *later*. It can't be secure and we don't trust SSDs manufacturer with that.
|
||||
|
||||
## Level 2 - SATA Secure Erase / NVMe SES
|
||||
|
||||
### SATA
|
||||
|
||||
```sh
|
||||
hdparm -I /dev/SSD
|
||||
```
|
||||
In a buttom part, 'Security' section
|
||||
![](https://grok.lsu.edu/image/32974.png)
|
||||
```sh
|
||||
# IF ' frozen' - we need to unfreeze it by putting PC in sleep for a few seconds
|
||||
echo -n mem > /sys/power/state
|
||||
# or - systemctl sleep
|
||||
# check if it frozen
|
||||
hdparm -I /dev/SSD
|
||||
# if it still frozen - repeate sleeping/waking until it's not. #TODO is there any other better way???
|
||||
```
|
||||
![](https://grok.lsu.edu/image/32979.png)
|
||||
```sh
|
||||
# IF 'not frozen' - we will set up temporary password 'p' (don't change) for a drive to issue secure erase command
|
||||
hdparm --user-master u --security-set-pass p /dev/SSD
|
||||
# Check to see if the password is set correctly and that security is now enabled
|
||||
hdparm -I /dev/SSD
|
||||
# In 'Security' section now should be ' enabled' and 'Security level high'
|
||||
```
|
||||
![](https://grok.lsu.edu/image/32986.png)
|
||||
```sh
|
||||
# Finaly erase drive
|
||||
# If the drive DOES support Enhanced Security Erase:
|
||||
hdparm --user-master u --security-erase-enhanced p /dev/SSD
|
||||
# If NOT:
|
||||
hdparm --user-master u --security-erase p /dev/SSD
|
||||
# After reset password should be disabled automatically
|
||||
hdparm -I /dev/SSD
|
||||
```
|
||||
|
||||
In case if you get error when tried to wipe and want to disable password:
|
||||
```sh
|
||||
sudo hdparm --user-master m --security-erase NULL /dev/SSD
|
||||
# if didn't worked try --security-disable
|
||||
# also try with --user-master u
|
||||
```
|
||||
|
||||
|
||||
pros:
|
||||
- Should work on most SATA SSDs
|
||||
|
||||
cons:
|
||||
- You can't be sure that it is secure wipe if you paranoid enough or against NSA.
|
||||
When you issue Secure Erase, SSD controller should instantly wipe all memory banks by just giving power on them. If you don't trust your SSD's manufacturer, then it isn't sufficient.
|
||||
If your drive is SED (self-encrypting drive), then it should remove cryptographic key instead of wiping memory banks making proccess faster
|
||||
- Complicated. Hard to add in a script
|
||||
- Drive must be directly attached to SATA (no USB, RAID controller or NVME SSD...)
|
||||
- Long, expect it to take up to a hour
|
||||
|
||||
### NVMe
|
||||
|
||||
```sh
|
||||
sudo nvme format /dev/nvmeSSD --ses=1
|
||||
# Or if you have SED (self-encrypting drive)
|
||||
sudo nvme format /dev/nvmeSSD --ses=2
|
||||
```
|
||||
|
||||
pros:
|
||||
- Should work on most recent NVMe SSDs
|
||||
- Scriptable
|
||||
|
||||
cons:
|
||||
- Same as in SATA - You can't be sure that it is secure wipe if you paranoid enough or against NSA.
|
||||
Drive's firmware decide how exactly it should be erased (e.g., zeroing, random data overwrite)
|
||||
In case of `--ses=2` and SED drive - it will remove crypto keys what is going to be fast
|
||||
- Long, expect it to take up to a hour
|
||||
|
||||
## Level 3 - dd/shred + blkdiscard
|
||||
|
||||
```sh
|
||||
dd bs=1M status=progress if=/dev/urandom of=/dev/SSD
|
||||
# or - shred -v -n 1 /dev/SSD
|
||||
|
||||
blkdiscard -v /dev/SSD
|
||||
```
|
||||
|
||||
### Verify
|
||||
|
||||
```sh
|
||||
echo 3 > /proc/sys/vm/drop_caches
|
||||
cmp /dev/zero /dev/SSD
|
||||
# expected result: EOF on /dev/SSD
|
||||
```
|
||||
|
||||
pros:
|
||||
- Just works on any SSD
|
||||
- Scriptable
|
||||
|
||||
cons:
|
||||
- Long, expect it to take up to a hour
|
||||
- Security - complicated. `dd/shred` aren't a guaranteed to securely wipe entire SSD. The issue is a complexity of a SSDs:
|
||||
wear leveling, garbage collection, logical/physical data mapping, TRIM during proccess... They all make `dd/shred` arent reliable to securely wipe entire SSD, some parts of a drive still can be recovered.
|
||||
If you trust enough your drive manufacturer and drive didn't containe any important information, then just use SATA Secure Erase / NVMe SES.
|
||||
|
||||
## Level 4 - paranoia
|
||||
|
||||
Well, if you paranoid enough to wipe device for sure, then we are combining stuff above in extreme maner (your disk should be like 3 times overwritten)
|
||||
|
||||
```sh
|
||||
shred -v -n 1 /dev/SSD
|
||||
echo 3 > /proc/sys/vm/drop_caches
|
||||
blkdiscard -v /dev/SSD
|
||||
echo 3 > /proc/sys/vm/drop_caches
|
||||
|
||||
# !!!ISSUE SATA Secure Erase / NVMe SES!!!
|
||||
|
||||
echo 3 > /proc/sys/vm/drop_caches
|
||||
|
||||
# We will do random data wipe once again by encrypting 0s and verifying encrypted 0s later
|
||||
cryptsetup open --type plain --cipher aes-xts-plain64 /dev/SSD cryptyourssd
|
||||
# Pass:Three unicorns went into a bar and got stuck in the door frame
|
||||
badblocks -b 4096 -t 0 -s -w -v /dev/mapper/cryptyourssd
|
||||
|
||||
# Power off your PC and boot it again
|
||||
# Open drive again
|
||||
cryptsetup open --type plain --cipher aes-xts-plain64 /dev/SSD cryptyourssd
|
||||
# Pass:Three unicorns went into a bar and got stuck in the door frame
|
||||
|
||||
# verify that you did good
|
||||
cmp /dev/zero /dev/mapper/cryptyourssd
|
||||
# expected result: EOF on /dev/mapper/cryptyourssd
|
||||
```
|
||||
|
||||
pros:
|
||||
- tranquility knowing that drive is wiped
|
||||
- you still have a working drive!
|
||||
|
||||
cons:
|
||||
- The longest, expect it to take a few hours
|
||||
- You need to understand what you are doing
|
||||
|
||||
## Level 5
|
||||
|
||||
<!-- ![](https://i.imgur.com/q2ZIwQ7.mp4) -->
|
||||
{{< rawhtml >}}
|
||||
<video width=100% controls autoplay loop>
|
||||
<source src="https://i.imgur.com/q2ZIwQ7.mp4" type="video/mp4">
|
||||
Your browser does not support the video tag.
|
||||
</video>
|
||||
{{< /rawhtml >}}
|
||||
(If you cant see a video, then the answer is - physical destruction)
|
||||
|
||||
{{< source >}}
|
||||
https://superuser.com/questions/1284450/quickest-way-to-wipe-an-ssd-clean-of-all-its-partitions-for-repartitioning-in-li
|
||||
https://unix.stackexchange.com/questions/681521/securely-erase-ssds-the-whole-ssd
|
||||
https://grok.lsu.edu/Article.aspx?articleid=16716
|
||||
https://superuser.com/questions/1671399/remove-unknown-ata-password-with-hdparm
|
||||
https://unix.stackexchange.com/questions/659931/how-secure-is-blkdiscard
|
||||
https://superuser.com/questions/1530363/how-to-securely-erase-an-nvme-ssd
|
||||
https://serverfault.com/questions/147759/dd-vs-secure-erase-for-reconditiong-ssds
|
||||
{{< /source >}}
|
||||
|
Loading…
Reference in New Issue
Block a user