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

161–170 of 355 posts

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

#161

Post by vidarh »

raverbashing wrote: post #155
shizcakes wrote: post #48

The premise of this thing is not good advice. 1) Your first couple minutes on a server should be used to install a configuration management client, if your bootstrap policies somehow don't already install one. 2) Everything else listed in this document should be configured by a configuration management system. 3) "User account sync tools" should have no place in a modern infrastructure, you should use your configurat…

You are right, this is a better path But sometimes, and especially for servers that will be delivered to the customer afterwards, it's not practical to use a configuration management tool. Also, millions of servers were deployed before Chef/Puppet appeared. You can't tell they did wrong. Also, Chef/Puppet type solutions may be overkill for some tasks, fabric takes care of the easier cases for example.

It's always practical to use a configuration management tool. It's not always practical to use specific tools like Chef/Puppet.

Even a shell script that automates your standard install scripts is better than doing it by hand, because they can ensure you don't forget any steps and verify the state afterwards and ensure you don't forget any of the verification steps either.

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

#162

Post by drivebyacct2 »

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

Why would they bother? Script-kiddie is just playing the numbers, any machine with a slightly non-default configuration is not worth the effort. Disabling password authentication is better for "real" security, but doesn't stop those dictionary attacks spamming your logfile. (I still feel there should be better solutions to that problem than changing the port though)

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 cracked or collided or brute forced

and then when you change the port, the only "advantage" I get is that I now have to remember the port because they're already not getting in by virtue of key-based auth.

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

#163

Post by fsniper »

I do not recommend unattended upgrades. Every upgrade without any exceptions have the possibility to destroy any working system or your applications. Test and deploy would be wiser.

By the way, what the heck developers do on production systems?

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

#164

Post by raverbashing »

vidarh wrote: post #161
raverbashing wrote: post #155

Earlier quoted context omitted.

You are right, this is a better path But sometimes, and especially for servers that will be delivered to the customer afterwards, it's not practical to use a configuration management tool. Also, millions of servers were deployed before Chef/Puppet appeared. You can't tell they did wrong. Also, Chef/Puppet type solutions may be overkill for some tasks, fabric takes care of the easier cases for example.

It's always practical to use a configuration management tool. It's not always practical to use specific tools like Chef/Puppet. Even a shell script that automates your standard install scripts is better than doing it by hand, because they can ensure you don't forget any steps and verify the state afterwards and ensure you don't forget any of the verification steps either.

Ok, great, that's the spirit

You can put all his recommendations in a shell script (as the easiest solution) then run it (and if you ever did this more than ONE time you see the value in it)

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

#165

Post by vidarh »

mef wrote: post #71
shizcakes wrote: post #48

The premise of this thing is not good advice. 1) Your first couple minutes on a server should be used to install a configuration management client, if your bootstrap policies somehow don't already install one. 2) Everything else listed in this document should be configured by a configuration management system. 3) "User account sync tools" should have no place in a modern infrastructure, you should use your configurat…

For #4, wouldn't the only change when someone leaves the organization be to remove their key from authorized_keys for the shared account? Why would anyone else have to be updated?

If they have had access to a shared account, how much work are you willing to put in to verify that there's nothing in that shared account that will get executed by another user later that will quietly reinstate a key?

A reason to have separate accounts is that not only do you terminate access, you also have an easier time ensuring that less of what that person had access to could have been compromised. (This of course goes right out the window if said person has sudo/su access, in which case you have a much harder time, but even then giving them individual accounts means your opportunity to audit becomes so much greater)

After all, it's not the honest guy who'll never try to log in again you're primarily trying to protect against (in fact: for the honest people, a good security policy protects them by making them less likely to become potential suspects if/when something happens - it's in your own interest when you leave an organisation to ensure you get locked out), but the guy who might decide to try to do something later, or who might even be thinking about doing something before they leave.

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

#166

Post by vidarh »

lmm wrote: post #132
mryan wrote: post #129

Earlier quoted context omitted.

I, also, trust SSH more than any other software. But it is still worth adding an additional layer of security in front of SSH to help protect from exploits. Let's say that, hypothetically, a 0-day exploit was discovered in SSH which allowed remote code execution. A script kiddie begins trawling the internet for publicly accessible SSH servers to attack. Your servers allow SSH from anywhere on the internet, and are ev…

Your outermost server is the one where you should be most worried about having vulnerabilities - if you have a VPN as the outer layer that means the VPN server must be exposed to the public internet, and anyone who compromises it is in a pretty good position. And I'd rate the odds of a 0-day being found at higher for most VPN software than for SSH.

> and anyone who compromises it is in a pretty good position.

You are assuming the VPN host is trusted any more than most people trusts random servers on the internet.

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

#167

Post by mich41 »

KevinMS wrote: post #119

I was wondering about this the other day, is PasswordAuthentication no really that necessary if a strong password is used? Honestly, being a private key screw-up away from never being able to log in again scares me a little.

Encrypt the key (ssh-keygen offers you to do so) and backup it to bazillion clouds.

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

#168

Post by drucken »

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 very good reasons why this practice is standard. Unless you are specifically creating a test or honeypot box of some kind, you would be foolhardy to ignore it.

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

#169

Post by chookrl »

wvenable wrote: post #78
shizcakes wrote: post #48

The premise of this thing is not good advice. 1) Your first couple minutes on a server should be used to install a configuration management client, if your bootstrap policies somehow don't already install one. 2) Everything else listed in this document should be configured by a configuration management system. 3) "User account sync tools" should have no place in a modern infrastructure, you should use your configurat…

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

I recommend Chef - http://www.opscode.com/chef/

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

#170

Post by justincormack »

dave1010uk wrote: post #136

Couple of related questions: 1) Many people seem to be recommending Puppet / Chef. How many servers or installs do you need before this is a good ROI? (Over using odd bash scripts or cPanel/WHM) 2) Am I right in thinking kernel updates don't get applied until the server is rebooted? If so, how / when do you manage this?

Re 2 yes that is true. You need to build this in to your maintenance.
Post reply on HN