Live data from Hacker News

Linux workstation security checklist

github.com

61–70 of 165 posts

Re: Linux workstation security checklist

#61
post #8

Not the soundest security advice I've read recently: > We recommend that you use the same passphrase for your root password as you use for your LUKS encryption (unless you share your laptop with other trusted people who should be able to unlock the drives, but shouldn't be able to become root). If you are the sole user of the laptop, then having your root password be different from your LUKS password has no meaningfu…

Not to mention this gem: > it is fine to write down your passphrases and keep them in a safe place

Good enough for Bruce Schneier:

https://www.schneier.com/blog/archives/2005/06/write_down_yo...

Re: Linux workstation security checklist

#62
post #45
post #25

For my home computer, sshd is always on. It is configured to disable password authentification. On the firewall, I authorize only two things: ssh port and wakeonlan. If I need to access another port, it is generally enough to open temporarily a ssh tunnel. I think that you lose most of the advantages of a unix computer if you can not access it remotely.

I have Linux on all my home machines, and none are configured to be accessed remotely. There are still plenty of advantages. Far less viruses / malware / crapware. Better performance on under powered machines. Better development environment (for the sort of development I do). No phoning home to MS / Apple (as far as I am aware).

> I have Linux on all my home machines, and none are configured to be accessed remotely. There are still plenty of advantages. Far less viruses / malware / crapware.

I don't think the 2 ideas are related. I can't think of a script kiddie that would brute force your SSH to install a virus on it. Join a botnet maybe - but probably not to just install a virus.

Also if you use something like SSH keys or OTP - it's pretty much guaranteed that no one but you can access it.

Re: Linux workstation security checklist

#63
To all those writing the critical comments: I'd love to read a rebuttal to this written by someone who is a Linux and security professional, and explaining not only what is wrong here but why in addition to best security practises. Thanks.

Re: Linux workstation security checklist

#64

Earlier quoted context omitted.

>On proper UEFI implementations ... You're going to have to qualify that.

It's no secret that the full UEFI spec is quite complex. Some parts are mandatory while others are optional. It's also no secret that lots of hardware vendors are terrible at implementing software. The usual rule is that the less software they write, the better. The result is that different vendors and OEMs have a different quality UEFI firmware implementations and different feature-set available in them. Some are cl…

Well, that's really the question, isn't it? Is there more security added by enabling UEFI, or keeping it disabled? I managed to brick four Lenovo Thinkpad T540p mainboards due to a UEFI bug. Fortunately I had the on-site corporate maintenance contract (that time it paid for itself), because neither I nor Lenovo could figure out why the system would end up getting so badly bricked it couldn't be booted at all. Turns out there was a bug in the UEFI implementation where if it was enabled at all (regardless of whether it was enforcing secure boot or not), and you had a Samsung SSD installed, the UEFI implementation would write garbage into its non-volatile flash storage, that would completely brick the mainboard, and nothing would fix it except for a complete mainboard replacement.

Sure, it was a bug, but if you've read the UEFI spec, it's scary how complex the thing is. It reminds me of all of the complexity NSA employees managed to insert into the IPSEC and TLS stnadards. Complexity kills, especially when security is concerned. You really want to keep the Trusted Code Base small and simple. And UEFI is not simple. Combine that with the competence traditionally associated with BIOS programmers, and the results are very sad....

Re: Linux workstation security checklist

#65
post #36

Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all this stuff right. I like to keep things simple (which is why I use syslinux instead of GRUB as a bootloader. GRUB2 is ugly as sin to configure) On the FF extension front I'd like to add: Proxy Selector, Self-Destructing Cookies, and RefControl as recommendations.

It certainly makes sense from a security standpoint, but is there any additional overhead to encrypting swap? This is the first time I've ever seen it mentioned as a security measure.

Re: Linux workstation security checklist

#66
post #11
post #3

It may be silly to ask[1] but is there a similar list for Mac OS X? [1] Silly because, you know, closed source

NSA [1] has pretty good list for major OSs. [1] Yes, pretty ironic, isn't it?

No, it is not at all ironic that NSA provides STIGs for major operating systems. NSA is responsible for SIGINT and Information Assurance.

Re: Linux workstation security checklist

#67
post #8

Not the soundest security advice I've read recently: > We recommend that you use the same passphrase for your root password as you use for your LUKS encryption (unless you share your laptop with other trusted people who should be able to unlock the drives, but shouldn't be able to become root). If you are the sole user of the laptop, then having your root password be different from your LUKS password has no meaningfu…

Not to mention this gem: > it is fine to write down your passphrases and keep them in a safe place

Why not? Write them all on a piece of paper and lock it in a safe. Probably much safer than a password manager.

Re: Linux workstation security checklist

#68
post #36

Meh. I have encrypted /, /home and swap. I've disabled Secure Boot, and the TPM, and use legacy boot. I don't really trust my laptop manufacturer to get all this stuff right. I like to keep things simple (which is why I use syslinux instead of GRUB as a bootloader. GRUB2 is ugly as sin to configure) On the FF extension front I'd like to add: Proxy Selector, Self-Destructing Cookies, and RefControl as recommendations.

You don't encrypt /usr? I really do not understand the point of encrypting a subsection of your drive.

Re: Linux workstation security checklist

#69
post #8

Not the soundest security advice I've read recently: > We recommend that you use the same passphrase for your root password as you use for your LUKS encryption (unless you share your laptop with other trusted people who should be able to unlock the drives, but shouldn't be able to become root). If you are the sole user of the laptop, then having your root password be different from your LUKS password has no meaningfu…

I'm struggling to understand any situation where you should ever be typing either your LUKS password or your root password into a fully operating/running system. If you're using sudo correctly, you do not enter your root password. Frankly, the only time I can remember being prompted for a root password in years is when the system has failed to boot and offers entry to a recovery/maintenance shell. If you're using LUK…

You are entirely correct and it is too bad I did not delete my comment in time. Here I am with an intense dislike of bogus criticism on HN and yet perpetuating some. Sleep before you post...
Post reply on HN