Live data from Hacker News

Linux workstation security checklist

github.com

11–20 of 165 posts

Re: Linux workstation security checklist

#12
post #7

SecureBoot!? Hahahah, Linux Foundation marks this as critical? I am sorry to laugh, but thank God the LF and others fought tooth and nail for some way to have someone other than Microsoft have the key. But seriously, did anyone else laugh?

Why laugh? On proper UEFI implementations you can enroll your own keys. Arch Wiki (as usual) has an article with more details:

https://wiki.archlinux.org/index.php/Unified_Extensible_Firm...

It may not provide 100% security (what does?), but using this still provides much more security than just booting whatever lies on disk without any sort of verification.

So yeah. Laughing at this advice is at best uninformed.

A nice bonus-effect from using secure boot is that most UEFI implementations secure-boot faster. Why? Because when in "insecure" mode it keeps up a splash-screen saying "Booting insecure" for a few seconds before moving on.

Re: Linux workstation security checklist

#15
post #13

I always install fail2ban so to prevent brute force ssh attacks from getting in. It's popular enough that's it's probably available in your distro's package repositories. http://www.fail2ban.org/

Why would you have sshd running on your workstation in the first place?

Re: Linux workstation security checklist

#16
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…

>Trick the user into running a program that does 'alias sudo=evil-sudo' >> ~/.bashrc

That's only going to get you the user's password, not the root password.

Re: Linux workstation security checklist

#17
post #13

I always install fail2ban so to prevent brute force ssh attacks from getting in. It's popular enough that's it's probably available in your distro's package repositories. http://www.fail2ban.org/

Alternatively, use SSHguard if you want/need IPv6 support.

http://www.sshguard.net/

https://github.com/fail2ban/fail2ban/issues/1123

Re: Linux workstation security checklist

#18
post #16
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…

>Trick the user into running a program that does 'alias sudo=evil-sudo' >> ~/.bashrc That's only going to get you the user's password, not the root password.

Good point. I've toned down my comment because that root password would be getting typed in less often.

An attacker might still bring an evil-su in addition to an evil-sudo, though. And even if you're logging into that root user only in an another tty, it seems like an unnecessary risk to share the password with LUKS.

Re: Linux workstation security checklist

#19
post #7

SecureBoot!? Hahahah, Linux Foundation marks this as critical? I am sorry to laugh, but thank God the LF and others fought tooth and nail for some way to have someone other than Microsoft have the key. But seriously, did anyone else laugh?

Why laugh? On proper UEFI implementations you can enroll your own keys. Arch Wiki (as usual) has an article with more details: https://wiki.archlinux.org/index.php/Unified_Extensible_Firm... It may not provide 100% security (what does?), but using this still provides much more security than just booting whatever lies on disk without any sort of verification. So yeah. Laughing at this advice is at best uninformed. A n…

>On proper UEFI implementations ...

You're going to have to qualify that.

Re: Linux workstation security checklist

#20
post #2

Nice list, until... install a closed source product that sends backups offsite (SpiderOak). wtf?

I was using Wuala but they are closing it down later this year, starting from now. They recommend switching to Tresorit, Swiss based with end to end encryption and no keys held on the server (lose your password at your peril). Any recommendations for cloud storage that is secure and has a Linux GUI? Tresorit is not open source either as far as I can tell from the website.
Post reply on HN