Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux workstation security checklist

github.com

Post reply on HN
Print view View original

31–40 of 165 posts

Re: Linux workstation security checklist

#31

Post by vacri »

m4r71n wrote: post #15
oofabz wrote: 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?

I've ssh'd into colleagues' machines to help them with system problems, and they've ssh'd into mine to retrieve their VPN keys. Not all of my colleagues have ssh access to a common server somewhere.

I've also remoted into my workstation from home to do emergency work.

Re: Linux workstation security checklist

#32

Post by 616c »

josteink wrote: post #30
616c wrote: post #26

Earlier quoted context omitted.

I laugh, and get downvoted, because SecureBoot was a noble concept, and rightfully open source enthusiasts made it clear that trusting select corporate bodies and vested interests to be the sole distributor of keying material for the OS was problematic. I deal with computer deployment for a living. I realize there is far more nuance, but I trust centralized system verification like I do centralized SSL PKI: I have to…

rightfully open source enthusiasts made it clear that trusting select corporate bodies and vested interests to be the sole distributor of keying material for the OS was problematic. And that was a good thing. It put pressure on getting the capability to add your own keys. I realize there is far more nuance, but I trust centralized system verification like I do centralized SSL PKI: I have to, and no one is trusting my…

I thought there was a significant gap between our views, but I think you and I are of very similar viewpoints. Thanks for teasing something more detailed out of me, so I do not feel like so much of a troll.

Re: Linux workstation security checklist

#33

Post by gozo »

SturgeonsLaw wrote: post #29
ivank wrote: 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

I don't see any problem with that. Physical security is much easier to manage than digital security.

Re: Linux workstation security checklist

#34

Post by mtgx »

brador wrote: post #22

Why can't someone simply make a security wizard for Linux. Like I run the program and it gives me options and changes the settings based on my selections. Why must everything be so manual everytime on Linux...

This was a nice presentation comparing security in general to how cars were built in the 1960's, when engineers made the car work great - but with little consideration for "user error" or the user experience in general. 50 years later cars are highly protected against dumb things the user might do, and he suggests that's how the security community should look at building stuff, too(while hopefully not taking another 50 years to achieve great security with great user experience as well).

http://kernsec.org/files/lss2015/giant-bags-of-mostly-water....

Re: Linux workstation security checklist

#35

Post by amalcon »

ivank wrote: 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…

Frankly, I find it suspect that they even suggest having a root password. The only situation where this is useful is when sudo is somehow broken (e.g. a typo in /etc/sudoers). This happens rarely enough that I'm OK with a more heavyweight process (like booting Knoppix) to fix it.

Re: Linux workstation security checklist

#36

Post by nly »

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.

Re: Linux workstation security checklist

#37

Post by vog »

oofabz wrote: 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/

Also, don't use SSH passwords. Authenticate only with SSH keys.

An SSH private key is almost impossible to brute force, compared to passwords. (unless your SSH key generator has been patched by a clueless Debian maintainer)

Re: Linux workstation security checklist

#40

Post by Hello71 »

Animats wrote: post #4

FireWire is a vulnerability for Linux only because the kernel maintainers want it to be. There's a register in FireWire controllers which controls the address range for which remote memory accesses are valid. It can be set to 0, which locks out that function. The last time I looked, years ago, it was set to allow access to the first 4GB of memory, because the code pre-dated 64 bit systems. I once proposed setting it…

Linux has, in fact, supported a configuration option CONFIG_FIREWIRE_OHCI_REMOTE_DMA (default n) since 2.6.26 released 13 July 2008. [0][1] In kernel 3.14, this was changed into a module parameter (default n). [2] I did not further investigate the status of firewire modules before then.

I was unable to locate any relevant mailing list posts referencing "firewire" or "DMA" by the author "John Nagle". [3][4]

[0] http://cateee.net/lkddb/web-lkddb/FIREWIRE_OHCI_REMOTE_DMA.h...

[1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

[2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

[3] http://search.gmane.org/?query=firewire&author=John+Nagle

[3] http://search.gmane.org/?query=dma&author=John+Nagle

Post reply on HN