Remote wipe software

[Oliver Leaver-Smith]

Hello misc@

I wonder if anyone could recommend remote wipe software for OpenBSD, should someone want to start using it in an enterprise setting where such features are a requirement?

Thanks in advance,

ols

[Janne Johansson]

Den tis 27 apr. 2021 kl 11:44 skrev Oliver Leaver-Smith

Post by Oliver Leaver-Smith
I wonder if anyone could recommend remote wipe software for OpenBSD, should someone want to start using it in an enterprise setting where such features are a requirement?
Thanks in advance,

Regardless of OS, the "easiest" setup is where you encrypt the drives
and wipe by "forgetting" the keys. Then you can dd the disks if it
makes someone else happy but having FDE and changing the key to
something random that you don't store, and then doing a normal wipe in
the simplest of terms would cover a lot of the practical attacks.

For the ones concerned with theoretical and imaginary enemies,
PXE-booting into a DBAN.iso or similar wiping solutions is probably
the next step. Also OS-independent.

[Oliver Leaver-Smith]

Post by Janne Johansson
Regardless of OS, the "easiest" setup is where you encrypt the drives
and wipe by "forgetting" the keys. Then you can dd the disks if it
makes someone else happy but having FDE and changing the key to
something random that you don't store, and then doing a normal wipe in
the simplest of terms would cover a lot of the practical attacks.
For the ones concerned with theoretical and imaginary enemies,
PXE-booting into a DBAN.iso or similar wiping solutions is probably
the next step. Also OS-independent.

Thanks Janne. Certainly those are two useful methods for ensuring that
the disk is wipe or the contents are not accessible. The scenario I am
thinking about is say a laptop is left in a suspended state, and
forgotten on a train somewhere. The contents of the drive would be
recoverable in that state unless something remote was to lock it down or
wipe the disk

--
Oliver Leaver-Smith
TZ=Europe/London

[Nick Holland]

Post by Oliver Leaver-Smith
I wonder if anyone could recommend remote wipe software for OpenBSD,
should someone want to start using it in an enterprise setting where
such features are a requirement?
Thanks in advance,

Remote wiping an openbsd system...depends on your company policy, but
there are options. I'm kinda assuming you are looking for an OpenBSD
solution, any wiping system will wipe any supported drives on any
machine.

# dd if=/dev/random of=/dev/rsdXc bs=1m

will clear drive sdX very nicely, and quite quickly compared to other
OSs -- to the point I've often installed OpenBSD remotely, then done
this to clear other OSs from systems. OpenBSD's performance from
its random number generator is fantastic.

IF your policy is a "multi-pass" wiping, I'd suggest doing a few
passes with /dev/random, then following up with /dev/zero, so you can
quickly and easily see if a particular drive has been cleared -- if it
is all zeros, you know you have completed the required number of
passes (it's easy to see zeros, a little harder to determine if data
is "random" or "just not understood".

If a one-pass wipe is sufficient by your company policy, a running
OpenBSD system can wipe itself. Yes, you will get error messages
when the dd is done, but...you don't really care, right?

You can even do the dd thing from a bsd.rd kernel, network booted or
physical media. Many years ago, I found that OpenBSD's full install
had a faster /dev/random (by a large margin) than the bsd.rd
/dev/random. I've got no idea if that's true now.

When tasked with a number of machines to wipe, I've actually made
wipe disks -- built a CD (or other) install media with the startup
scripts set to wipe all drives in the system, unprompted. Boot the
machine off the media, and let it run. Label them carefully and
destroy them when done to prevent very unhappy accidents later!

Nick.

[Oliver Leaver-Smith]

Thanks for your response, a lot to think about sure. I suppose having
some sort of phone home daemon running to know whether or not to dd
itself is probably the best way to at least somewhat destroy itself in a
disaster scenario

Label them carefully and destroy them when done to prevent very
unhappy accidents later!

Like Employee_Financial_Data.xlsx?

--
Oliver Leaver-Smith
TZ=Europe/London

[Karsten Pedersen]

Post by Oliver Leaver-Smith
Thanks for your response, a lot to think about sure. I suppose having
some sort of phone home daemon running to know whether or not to dd
itself is probably the best way to at least somewhat destroy itself in a
disaster scenario

As a note, it seems that dd on an SSD is not so effective due to
the wear balancing algorithm. Instead the "ATA Secure Erase" command
should be used (of course you have to trust that the SSD vendor has
implemented that correctly in the ROM / hardware).

[Steve Litt]

Oliver Leaver-Smith said on Tue, 27 Apr 2021 13:19:21 +0100

Post by Oliver Leaver-Smith
Thanks for your response, a lot to think about sure. I suppose having
some sort of phone home daemon running to know whether or not to dd
itself is probably the best way to at least somewhat destroy itself in
a disaster scenario

If you employ a dead man's switch like you describe above, you really
should back up that machine every single day.

SteveT

Steve Litt
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques

[Daniel Wilkins]

Post by Nick Holland
# dd if=/dev/random of=/dev/rsdXc bs=1m

I don't know Oliver's specific case but it's worth noting
that you probably want to check the output of
mount rather than hardcoding a value; if you need remote
wipes then you probably need full disk encryption and if I
remember correctly your device number isn't always
guaranteed there. Root is on sd3 for now, it might be on
sd2 next boot, etc. I may be misinformed though.