Live data from Hacker News

Linux workstation security checklist

github.com

71–80 of 165 posts

Re: Linux workstation security checklist

#71
post #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.

>I really do not understand the point of encrypting a subsection of your drive.

To prevent people from reading sensitive data on a stolen/lost laptop.

Re: Linux workstation security checklist

#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 run it in tandem with SElinux et al, I find it's better to run GRSEC and just fine tune it. You will thank yourself for learning it.

3. These days, you need a HIDS, full stop. What good do logs do if you never know what happens or only check your logs once a week/month/year/never? After spending time trying all the main ones out, OSSEC is my HIDS of choice.

4. SSH: while fail2ban, denyh0sts, et al are all workable options along with the listed option tweaks, what I find to work the best in addition are two things. A) Obscure port. We all know security through obscurity isn't, but reducing scripties bogging stuff down and keeping your logs cleaner helps imho. (it's also the difference between a metric ton of log alert emails and only a few). B) Two factor all the things. I am using the Google pam module, "libpam-google-authenticator". I stopped trusting tor but some friends of mine swear by ssh over tor hidden service.

5. The bottom line is that the linux kernel is out of control at >10mil loc, and 0-days/1-days are prevalent. If you have an internet facing system, it's probably going to get compromised, what you really need is the ability to find out as soon as possible when it happens. What this boils down to is you don't want to lose your data, so you need encrypted backups and verifiable checksums/hashes, so that once you've brought up a fresh system, you can restore data asap. Another thing that factors into this is configuration scripts and management stuff. I really like ansible since it works over ssh/powershell. Can really save a lot of time.

If you really want security, you also need to start and run minimal. I would say self compiled is the best (use flag changes often prevent sploits that otherwise work) so gentoo/slackware/arch would be the best nix distros for this. Beyond that, BSD is still king of the security world imho, especially OBSD, but please give DragonFlyBSD a look. While it's not touted as a "secure" distro, it has a ton of features that make it sexy as hell and it needs security contribs if you have the time. If I were starting a fresh ISP, I would be using DBSD.

For those of us stuck wanting to game and do more fun stuff though, who live in a debian/fedora/ubuntu world, just keeping an eye on logs is really the best you can do. Also keep in mind impact on perf that FDE may have if you are a linux gamer.

Those are my main tips/tricks, but I'm sure both the article and I are missing things, so take it all with a grain of salt.

Re: Linux workstation security checklist

#73
post #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.

I'm assuming he specifically mentioned encrypting /home because it's on a different partition/disk? I'm guessing /usr is on the root partition which he said he encrypts.

Re: Linux workstation security checklist

#74
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).

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.

Re: Linux workstation security checklist

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

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 day to day user.

Re: Linux workstation security checklist

#77

Earlier quoted context omitted.

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.

For your enjoyment, a screencap of UEFI dumping core on a fancy Dell "server class" machine during bootup:

http://i.imgur.com/YpOQXet.jpg

Work required that I restarted this machine frequently -- it would fault during boot probably 1/20 times.

Re: Linux workstation security checklist

#78
post #43
post #42

Earlier quoted context omitted.

> 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. Without secureboot, how do you know your kernel hasn't been modified to log all your keystrokes (including the passphrase to your encrypted partitions)?

If someone has physical access, they can remove my keyboard and install a hardware keylogger anyway. Updating my kernel image wouldn't be very effective given that it gets updated by Arch more often than it gets booted from.

And yet, the primary use-case for file system encryption is to protect data at rest, from someone with physical access to the disk. It seems odd to draw the line at physical security so arbitrarily -- that you'd be willing to encrypt your entire root file system and then throw your hands in the air when it comes to securing a tiny boot partition.

Re: Linux workstation security checklist

#79
post #74
post #45

Earlier quoted context omitted.

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).

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.

Re: Linux workstation security checklist

#80
post #76

Earlier quoted context omitted.

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…

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" in /etc/sudoers.)

Post reply on HN