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

How I spend my first 5 minutes on a server

plusbryan.com

Post reply on HN
Print view View original

211–220 of 355 posts

Re: How I spend my first 5 minutes on a server

#211

Post by majelix »

lenazegher wrote: post #204
drivebyacct2 wrote: post #162

Earlier quoted context omitted.

I guess my response to all of these is... using key based auth is so much more secure than changing the port that changing the port seems to me, completely, pointless. Especially considering that: - password auth = me having to type my password everytime, likely to have a less secure password - key based auth = me never having to type it in, with a key length so long that it's completely inconceivable it'll be cracke…

> using key based auth is so much more secure than changing the port Is it really? Once you get to a sensible password length (say, >14 characters) haven't you effectively made brute force and dictionary attacks impossible anyway? > password auth = me having to type my password everytime, likely to have a less secure password If you use a password often enough, I find the time difference between an 8 character and a…

> but I find the idea of anyone with access to my local machine being able to access my server with 0 additional credentials really disconcerting.

You could hook whatever locks your screen to also clear your ssh-agent then. This is probably something like alias xlock=$(ssh-agent -k && xlock) in linux.

You do lock your screen, right?

Re: How I spend my first 5 minutes on a server

#212

Post by rdl »

majelix wrote: post #209
packetslave wrote: post #130

Earlier quoted context omitted.

SSH keys also never expire and are easy to copy/steal. Key-based auth is officially discouraged at the day job (for laptop-to-desktop type things) for exactly this reason.

Expiring an ssh-key is easy, just remove the public key from authorized_keys. Dealing with theft is also straightforward: just add a passphrase to the key -- the time it takes to crack your pass phrase should be more than the time it takes for you to run ssh-keygen && ssh-copy-id.

The issue is lack of key management for ssh keys in a lot of environments, especially for accounts not always used. You can wrap protection around it, but you ay be better off just using a different authentication system (Kerberos? Something else?) in large environments.

Re: How I spend my first 5 minutes on a server

#213

Post by [deleted] »

josephkern wrote: post #176
drucken wrote: post #168

Earlier quoted context omitted.

You fail to understand that true security is not about passwords but control . Disabling remote root login, 1. cheaply reduces attack surface 2. necessitates assigning administration rights to specific persons and roles. 3. greatly increases command visibility and value of audit trails. 4. combines extremely well with disabled terminal shell over SSH 5. can reduce (unnecessary) system resource usage. Etc. There are v…

You fail to understand that true security is not about passwords or control; true secrity is about risk mitigation . Control is an ignorant tyrants last redoubt. Security is only about: identifying risks and dealing with those risks. All other messures are worthless as actual security objectives. I am not arguing with you in priciple, only in particular. All of your points are well taken, to reduce risk, but not to c…

[deleted]

Re: How I spend my first 5 minutes on a server

#214

Post by belorn »

drucken wrote: post #168
belorn wrote: post #133

It saddens me each time I see a security best practice guide that suggest turning off ssh access for root. Its a very useful feature, and the security industry should focus on the security problems rather than removing features without thinking about the actually benefits of doing so. Sysadmins with root access should be able to handle a random 8 character or longer password, and that number is large enough for a sec…

You fail to understand that true security is not about passwords but control . Disabling remote root login, 1. cheaply reduces attack surface 2. necessitates assigning administration rights to specific persons and roles. 3. greatly increases command visibility and value of audit trails. 4. combines extremely well with disabled terminal shell over SSH 5. can reduce (unnecessary) system resource usage. Etc. There are v…

As the other comment say, Security is about risk mitigation. Risk in turn is about identifying threats, and attack surface is avenues where that threat might cause damage.

The problem I have with the articles claim is that limiting roots access in ssh is not improved security. It does not acknowledge the threat or attack avenue at all, but rather tries a blind approach. The threat is script kiddies. The attack avenue is bad passwords combined with password authenticated use of ssh by root. One can then either fix A) the password, or B), the access root has in using ssh. I pick option A and thus have have good passwords that secure even against internal users, rather than having bad passwords and limiting roots use of ssh. Having good passwords, and disable ssh for root is redundant and a expensive limitation for no security benefit. Having bad passwords and disabled ssh is bad security practice, as bad passwords should by policy be impossible.

> 2. necessitates assigning administration rights to specific persons and roles.

If you need to have different assigned administration roles for a single installation, and guarantee a correct audit trail, you should look into physical tokens or at least a kerberos+ldap setup. "root" user should then not exist as something that anyone should use. however, if you do not care about guaranteed audit trail (and to be honest here, the common use case does not require kerbros+ldap setup), you can add something like environment variables to indicate which user is logged, and ask administrators to document changes to the system.

> 5. can reduce (unnecessary) system resource usage.

This goal can be mitigated in several way. Thus in a honest discussion, this should be the target of it and not the pretense of increased security.

Re: How I spend my first 5 minutes on a server

#215

Post by rdl »

majelix wrote: post #210
rdl wrote: post #126

Earlier quoted context omitted.

I love ssh keys. However: The big problem with ssh keys is not being able to enforce ssh key passphrases on users. From the server perspective, you have no idea if the user has set up a passphrase. There are security standards which mandate certain kinds of passwords (complexity) and are silent on asymmetric keys, so you couldn't use keys in those environments. The old solution was to do some post-login hack to requi…

> There are security standards which mandate certain kinds of passwords (complexity) and are silent on asymmetric keys, so you couldn't use keys in those environments. Every single auditor I've worked with has given a pass when they saw we were using keys instead of passwords. Do you also fail audits because your RSA token is only 10-12 digits? You could, I suppose, demand users upload their private key ( shudder ) t…

Yes -- FISMA. There are both requirements that the implementations be FIPS 140 (although software is ok) and other requirements. I don't think I've ever seen anyone use a securid without a password, so the password complexity requirement is satisfied there. (It wasn't that an auditor failed it, but it was said we'd need to fix this to avoid any issues, so enh)

I don't have a particularly high opinion of most security audit standards, though.

Re: How I spend my first 5 minutes on a server

#216

Post by [deleted] »

shizcakes wrote: post #83
wvenable wrote: post #78

Earlier quoted context omitted.

Is there a free and recommended configuration management system that does all this?

Chef or Puppet are common choices. There are many others, but those two are modern, have large communities, and decent documentation. There's a decent chance someone has already open sourced a cookbook/module for each of many of these items!

[deleted]

Re: How I spend my first 5 minutes on a server

#217

Post by belorn »

lotsofcows wrote: post #160
belorn wrote: post #133

It saddens me each time I see a security best practice guide that suggest turning off ssh access for root. Its a very useful feature, and the security industry should focus on the security problems rather than removing features without thinking about the actually benefits of doing so. Sysadmins with root access should be able to handle a random 8 character or longer password, and that number is large enough for a sec…

If someone logs in directly as root, how do you track root access? Given that you should be discouraging root use and using sudo or scripts to automate admin tasks, why are you encouraging admins to log on as root?

Discouraging root usage is common in desktop and laptop environments, and for developers on production servers. For admins on servers, root use is basically required for all commands, and sudo would not improve the security at all.

Commonly, I track access through environment variables (configuration on the ssh client), and documentation that each administrator do after finishing a task. As one should not recruit administrators that do rm -rf /, tracking (blame) is of an lesser importance and documentation a much higher one. If more was required, I would go with kerberos+ldap approach without anyone using local root user accounts at all.

Re: How I spend my first 5 minutes on a server

#218

Post by stinos »

crdoconnor wrote: post #152
drivebyacct2 wrote: post #145

Earlier quoted context omitted.

Wouldn't the script-kiddie through those hosts into a queue to run a more advanced port scan on? I mean, I see your point, but it seems highly useless compared to, say, simply disabling the password based authentication.

Imagine how long it would take to scan every port between 1 and 65535 on millions of machines. Versus how long it would take to just try port 22 on millions of machines. It wouldn't stop a determined hacker for more than a few minutes, but it will reduce the number of automated attacks on ssh essentially to zero.

this. Everytime I check my logs there's tons of failed tries to port 22 yet none to the port ssh actually runs on. Which keeps the log with failed logins clean.

Re: How I spend my first 5 minutes on a server

#219

Post by martinced »

I honestly do not understand why you need a deploy account with sudo access.

I much prefer a deploy accound which DOES NOT have sudo access. I add firewall rules transparently redirecting 80/443 to non-privileged ports that the webapp is actually listening to. Hence no need to be root / sudo'ed for the deploy account.

You then could get a bit fancier and set the login shell for the deploy account to /bin/false or something fancy (like a fake honeypot shell) to add a bit of "defense in depth" in case someone exploiting a hole in your web server manages tries to drop down to a shell. You'd then use another account to do the (automated) deploy/start/stop/update/patch whatever.

I'd also say that during the first five minutes you should set the default firewalling rules to REJECT anything and then only whitelist what is actually allowed.

Re: How I spend my first 5 minutes on a server

#220

Post by jackalope »

lenazegher wrote: post #204
drivebyacct2 wrote: post #162

Earlier quoted context omitted.

I guess my response to all of these is... using key based auth is so much more secure than changing the port that changing the port seems to me, completely, pointless. Especially considering that: - password auth = me having to type my password everytime, likely to have a less secure password - key based auth = me never having to type it in, with a key length so long that it's completely inconceivable it'll be cracke…

> using key based auth is so much more secure than changing the port Is it really? Once you get to a sensible password length (say, >14 characters) haven't you effectively made brute force and dictionary attacks impossible anyway? > password auth = me having to type my password everytime, likely to have a less secure password If you use a password often enough, I find the time difference between an 8 character and a…

Your private key should have a strong passphrase. I agree that using a passphrase-less key is bad practice. As for keyloggers, once they obtain your password, they have succeeded. But after obtaining a key's passphrase (which you normally only type in once a local session if using ssh-agent), they still need the key, which may or may not be marginally harder. It's still another step to overcome. So, even if it can be shown to be only a narrow improvement over passwords under certain circumstances, it's a big win in convenience and even security under normal circumstances if done properly. Give it a try, finetune your ~/.ssh/config and you might end up loving it.
Post reply on HN