IHawkMike

joined 2 years ago
[–] IHawkMike@lemmy.world 5 points 1 day ago

This is a good answer.

To add, for Linux kernels, the maintainer use a shim EFI package with the distro's keys (e.g., Canonical's keys for Ubuntu) which loads the maintainer-signed kernel. And Microsoft signs the shim to keep the chain intact.

[–] IHawkMike@lemmy.world 11 points 1 day ago (5 children)

I don't deal with hardware much anymore, but I'd take Aruba over Cisco any day. But for everything else, yeah fuck HP.

[–] IHawkMike@lemmy.world 13 points 4 days ago (4 children)

I'm Ron Burgundy?

[–] IHawkMike@lemmy.world 6 points 4 days ago (1 children)

Nothing you said is wrong, in fact it's all good advice. But none of what you listed implicitly provides protection against ransomware either.

For that you need backups that are immutable. That is, even you as the admin cannot alter, encrypt, or delete them because your threat model should assume full admin account compromise. There are several onprem solutions for it and most of the cloud providers offer immutable storage now too.

And at the very least, remove AD SSO from your backup software admin portals (and hypervisors); make your admins use a password safe.

[–] IHawkMike@lemmy.world 9 points 6 days ago

What you should be worried about more than a keylogger is that most 2.4 GHz wireless keyboards can have the keystrokes sniffed through the air. Bluetooth will be encrypted though.

[–] IHawkMike@lemmy.world 7 points 1 week ago

"To read the purported PDF document, victims are persuaded to click a URL containing a list of steps to register their Windows system. The registration link urges them to launch PowerShell as an administrator and copy/paste the displayed code snippet into the terminal, and execute it."

This is not new, nor is it newsworthy.

[–] IHawkMike@lemmy.world 1 points 1 week ago

Ah good point. Cheers.

[–] IHawkMike@lemmy.world 7 points 1 week ago (2 children)

This is the right answer. OEM keys are tied to the hardware so you technically need a retail key. The HP machines were almost certainly using OEM keys (chalk the first one working up to luck I suppose).

That said, by calling the licensing clearinghouse on the phone I have had them activate stuff that they probably shouldn't have so it's worth a shot. But I haven't had to call them in over 10 years so YMMV. If you call them you'll need the original OEM key from the sticker or by booting up the old PC and pulling it from WMI.

[–] IHawkMike@lemmy.world 9 points 2 weeks ago

Yep that's how I have Syncthing set up. All global and local discovery disabled, no firewall ports open on the clients, no broadcasting, no relay servers. Just syncing through a central server which maintains versioning and where the backups run. Works like a charm.

[–] IHawkMike@lemmy.world 10 points 2 weeks ago (7 children)

The can opener.

[–] IHawkMike@lemmy.world 3 points 3 weeks ago

As another poster mentioned, QubesOS with anti evil maid will work, but that's the defense against state actors too and is overkill for this threat model.

BitLocker or any FDE using SecureBoot and PCR 7 will be sufficient for this (with Linux you also need PCRs 8+9 to protect against grub and initramfs attacks). Even if they can replace something in the boot chain with something trusted, it'll change PCR 7 and you'd be prompted to unlock with a recovery key (don't blindly enter it without verifying the boot chain and knowing why you're being prompted).

With Secure Boot alone, the malicious bootloader would still need to be trusted (something like BlackLotus).

Also make sure you have a strong BIOS password and disable boot from USB, PXE, and anything else that isn't the specific EFI bootloader used by your OS(es).

[–] IHawkMike@lemmy.world 5 points 3 weeks ago

Yeah this article is complete garbage. Who upvotes this stuff?

 

Berlin artist Simon Weckert used 99 phones and a handcart to create a "virtual traffic jam" on Google Maps

35
submitted 1 year ago* (last edited 1 year ago) by IHawkMike@lemmy.world to c/stick@sh.itjust.works
 

A stick!

view more: next ›