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

141–150 of 165 posts

Re: Linux workstation security checklist

#141

Post by yellowapple »

vog wrote: post #37
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)

Better yet: it's a workstation. There's a pretty solid chance you don't actually need sshd to be even running.

(Granted, this guide specifies that it's meant for sysadmins managing groups of workstations, in which case SSH access might be necessary for remote administration, but for most users, SSHing into a workstation is unnecessary.)

Re: Linux workstation security checklist

#142

Post by yellowapple »

vacri wrote: post #31
m4r71n wrote: post #15

Earlier quoted context omitted.

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.

Ideally, those colleagues would keep sshd disabled unless they actually do need your remote assistance, at which point they'd "service sshd start" or "systemctl sshd.service start" (or however it's normally done with systemd) or "/etc/init.d/ssh start" or "/etc/rc.d/rc.ssh start" or what have you. Minimization of attack surface is an important part of a comprehensive security strategy, and a remote login system - even one with a phenomenal track record like OpenSSH - contributes pretty heavily to that attack surface.

Re: Linux workstation security checklist

#143

Post by yellowapple »

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

Try YaST on openSUSE. Offers precisely what you're looking for (among other things; it's basically the Linux equivalent to Windows' Control Panel).

Relevant documentation: http://doc.opensuse.org/documentation/html/openSUSE_121/open...

Re: Linux workstation security checklist

#144

Post by yellowapple »

dfc wrote: post #66
satai wrote: post #11

Earlier quoted context omitted.

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.

If only the NSA knew that :)

Re: Linux workstation security checklist

#145

Post by vonuebelgarten »

yellowapple wrote: post #138
SmellyGeekBoy wrote: post #65

Earlier quoted context omitted.

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.

Ideally, you wouldn't even have a dedicated swap partition. No data is always more secure than even the most perfectly-encrypted data. If you do have swap, though, then the encryption probably won't matter much compared to the fact that your machine is swapping in the first place.

Hibernation is a very nice feature (I use it for laptop and desktop machines) and it requires a swap partition. Also, a encrypted swap is even more important in this scenario.

In the laptop I'm typing this, swap is one of the partions over a LVM2 physical volume over LUKS.

Re: Linux workstation security checklist

#146

Post by pakled_engineer »

wyclif wrote: post #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.

Encrypt the root emails instead of sending them cleartext, can easily write a small script to do this and not give away internal security information.

Re: Linux workstation security checklist

#147

Post by Tiksi »

yellowapple wrote: post #140
nly wrote: post #97

Earlier quoted context omitted.

Everything except /home is on the root filesystem. I've never seen the point in loads of mountpoints.

Historical reasons aside, some operating systems (like OpenBSD) are designed to be able to implement different security policies by filesystem. For example, you could mark a given filesystem as executable or non-executable, adding yet another layer of security (at least policy-wise) to a system. And really, with things like LVM and btrfs, there's little reason why this is a bad idea anymore, since expanding subvolume…

You can do that in linux by bind mounting a folder to itself with the more secure options. I have a couple systems where I do this to have directories noexec, nosuid, etc. Kinda hackish but useful.

Re: Linux workstation security checklist

#148

Post by rsy96 »

Alupis wrote: post #122
ams6110 wrote: post #117

Earlier quoted context omitted.

If you have unrestricted sudo, which is how most single-user systems are set up, your password is effectively the root password.

> If you have unrestricted sudo [...] your password is effectively the root password. Yes, but it keeps an audit trail of who's account was compromised, etc.

With root privilege you can erase all of the audit logs. A malicious attack probably would do so if he/she cares about that.

Re: Linux workstation security checklist

#149

Post by rsy96 »

baghira wrote: post #107
forgottenpass wrote: post #98

Earlier quoted context omitted.

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 That gets to the philosophy of what sudo is used for in the first place. Back when sudo was experiencing a big upswing in popularity, it was a way to avoid having a root shell open at all. Forcing the user to type sudo before every co…

Sure, although I never found that reason to hold much ground given that in reality most distros ship with accounts that can open a shell (instead of having a list of allowed commands) and have the timeout not set to zero, so any security benefit that would come from not using "sudo -s" is pretty much voided. And I'm skeptical that having users type sudo a bunch of time when they add a PPA and install a program someho…

When you have multiple commands to run, chances are that only some of them require root privilege. Prefixing only those with `sudo` instead of executing all of them in a root shell allows you to reduce damage, should the "normal" commands are typed wrong or have bugs.

Re: Linux workstation security checklist

#150

Post by josteink »

tytso wrote: post #64
josteink wrote: post #51

Earlier quoted context omitted.

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 o…

Good questions all together. But if I were to make one technical nitpick...

> Is there more security added by enabling UEFI, or keeping it disabled?

You're not really disabling the UEFI firmware at a technical level. You're just telling the UEFI firmware to load a UEFI BIOS compatibility shim, which then proceeds to load a unverified bootloader instead.

How much security do you expect to gain from that? I don't think there's any evidence this will help make your machine more secure against software based attack Of course there are no absolute answers, or otherwise we wouldn't be having this discussion.

Post reply on HN