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

81–90 of 165 posts

Re: Linux workstation security checklist

#81

Post by Tenhundfeld »

SmellyGeekBoy wrote: post #67
SturgeonsLaw wrote: post #29

Earlier quoted context omitted.

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.

Absolutely. I use a password manager for everything except a handful of ultra-critical sites, mostly things involving money or attack vectors to get access to my email. For those sites I don't trust to store in LastPass, I write the passwords down on paper. But I also do something I haven't seen others recommend:

Have a (logical) salt for all of the passwords. Don't write down that salt.

So, if you found my piece of paper with passwords, you might see something like this:

Etrade - I1999IbmfsaaymIwIbmoi

Gmail - D9cjeawfocsIdkwhtfts4r

But my actual passwords are something like this:

Etrade - I1999ibmfsaaymIwibmoi804WMainStreet

Gmail - D9cjeawfocsIdkwhtfts4r804WMainStreet

804WMainStreet is tacked on to the end of all of them, but you wouldn't know that from looking at the sheet of paper. Only my spouse knows the salt, and it's easy for us to remember, e.g., maybe 804WMainStreet is the address of the first place we lived together. In theory, this is reducing randomness, which might make it easier to crack one knowing the others, but I'm not super concerned about that.

The two most important elements of security for regular consumers are: 1) Use different passwords for everything. 2) Use multi-factor auth when available.

Whatever you have to do to achieve that is better than not doing it.

*And I actually use initialism for these passwords so I don't have to pull out the piece of paper often, only when I forget. In this example, the Etrade password might be derived from "In 1999 I bought my first stock as a young man. I wish I bought more of it."

Re: Linux workstation security checklist

#82

Post by throwaway2048 »

arca_vorago wrote: post #72

This is an interesting list, and I don't see anything glaringly wrong ( a few personal preference subjects, but..), so here are my handful of extra tips on top: 1. You can encrypt grub in order to prevent single user mode et al boot attacks. It can also make FDE systems recovery a pita though. 2. They already said it, but GRSEC is where it's at. It's really the future of linux security enhancement, and while you can…

you cant encrypt all of grub, some bit of it has to load the rest.

Re: Linux workstation security checklist

#83

Post by Skunkleton »

SmellyGeekBoy wrote: post #65
nly wrote: 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.

In theory anything could be in ram could also end up in swap. So yes, it is important. And yes, there is overhead, but it isn't too bad if your system isn't RAM constrained, and your CPU supports AES-NI or similar.

Re: Linux workstation security checklist

#84

Post by exceptione »

zdw wrote: post #55
Hello71 wrote: post #40

Earlier quoted context omitted.

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:/…

Are these protections active before the kernel has booted? Does DMA default to be off until enabled? If firewire (and thunderbolt, expresscard) aren't DMA-free by default, then there's a time window before/during boot in which an attack could happen. Full disk encryption/TPM/Secure Boot could help mitigate this though.

I am wondering myselves too.

  The new module parameter "remote_dma" (default = N, enable
  unfiltered remote DMA = Y) replaces the former build-time 
  option CONFIG_FIREWIRE_OHCI_REMOTE_DMA. (This kernel 
  configuration option was located in the "Kernel hacking" 
  menu, item "Remote debugging over FireWire with firewire-
  ohci".) It is therefore now possible to switch on RDMA at 
  runtime on all kernels with firewire-ohci loaded or built-in, 
  for example for remote debugging, without the need for a 
  custom build option.
from: https://ieee1394.wiki.kernel.org/index.php/Release_Notes#Lin...

I am not an expert in these matters, but could it be that OP is wrong with regarding to firewire? From what I am reading here is that dma is off by default, and can only be activated at runtime.

If the OP is right about the need to disable firewire, I hope someone could explain why so…

Re: Linux workstation security checklist

#85

Post by Skunkleton »

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?

So that you can ssh to it?

Re: Linux workstation security checklist

#86

Post by Skunkleton »

kagamine wrote: post #20
noja wrote: 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.

The Deja-Dup front end for duplicity is built in to Ubuntu. It does encryption, and knows how to store in all sorts of places, including locally and on multiple cloud providers.

Re: Linux workstation security checklist

#87

Post by Skunkleton »

worklogin wrote: post #79
reacweb wrote: post #74

Earlier quoted context omitted.

Today, my wife (at home) has called me (at work) because she could not launch chrome anymore. The disk was full. The files /var/log/kern.log and syslog were eating gigabytes. I was able to solve her problem remotely. I have also installed ubuntu on the computer of my old father who lives far. Regularly, I upload pictures (he is my backup for pictuers) and put a shortcut on his desktop.

I suppose SSH is easier to use on machines you don't own, but the best practice would be to set up a VPN tunnel. 6 - 1/2 dozen.

VPN and SSH are only partially overlapping in their features. Are you suggesting that SSH only allows local connections, and your VPN is what allows you local network access?

Re: Linux workstation security checklist

#88

Post by baghira »

ivank wrote: post #80
baghira wrote: post #76

Earlier quoted context omitted.

What I found problematic (unless I'm missing something) was the suggestion that your day-to-day user should be in the wheel group: if that's the case, once your user is compromised the attacker can edit .bashrc to change $PATH and use a patched sudo to take over the machine. IMHO "sudo" (or "doas") should be used from a different user, by switching to a different VT. Or at least only allowing certain commands for you…

sudo'ing as your day-to-day user is dangerous for another reason, too: the default 15 minute password timeout lets subprocesses in your shell use your sudo credentials, even if you didn't intend them to. e.g. sudo command, then later ./some-installer.sh - you didn't want to give some-installer.sh root, but it opportunistically uses 'sudo' and succeeds. (I disable credential caching with "Defaults timestamp_timeout=0"…

Sure, it always bothered me that guides show whole lists of commands prefixed by sudo, instead of teaching people to disable the timeout and use "sudo -i" or "sudo -s" to get their stuff done. See also the fact that OSX ships with tty_tickets disabled.

Still, unless one is sure that the sudo being invoked really is sudo, disabling the timeout won't be enough.

Re: Linux workstation security checklist

#90

Post by pbhjpbhj »

worklogin wrote: post #79
reacweb wrote: post #74

Earlier quoted context omitted.

Today, my wife (at home) has called me (at work) because she could not launch chrome anymore. The disk was full. The files /var/log/kern.log and syslog were eating gigabytes. I was able to solve her problem remotely. I have also installed ubuntu on the computer of my old father who lives far. Regularly, I upload pictures (he is my backup for pictuers) and put a shortcut on his desktop.

I suppose SSH is easier to use on machines you don't own, but the best practice would be to set up a VPN tunnel. 6 - 1/2 dozen.

Why is a VPN better practice?

Only I've been using sshuttle to make ad-hoc tunnels and it's exceedingly easy - there's details at http://alicious.com/digitalocean-free-credit/ (if you'll forgive the rather mercenary promotional slant in that post).

In short "$ sshuttle --dns -r root@X.X.X.X 0/0 --exclude 192.168.0.0/9 # start sshuttle" tunnels everything but my local network over a server with SSH on it [I've not checked for myself with Wireshark yet, do your due diligence].

When setting up I found [Open]VPN a bit protracted in comparison.

Post reply on HN