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

121–130 of 355 posts

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

#121

Post by laumars »

josephkern wrote: post #87

Firstly, a nice checklist. Easy actionable steps, repeatable, and pretty much most of what you need. Secondly, you are about 4-5 hours away from learning puppet (or Chef) and making this checklist into actual code. Thirdly, you now have a checklist of items that you can use in a job interview if you get the oppertunity to gain a new-hire or an intern. Lastly, good on you for submitting this to a peer-review on HN. We…

We can be picky, but with good reason as security is an exact science and a costly one to get wrong. There's so much conflicting and out right bad advice posted online these days that sometimes it takes a picky community to help clarify the best practices.

For what it's worth, some of the advice given in that article was worth mentioning (eg fail2ban, it's a great tool). But the shared account suggestion was the complete opposite of how you should be managing user accounts as you lose audit trails. And for that comment alone, I'd recommend people read that article with a degree of scepticism before rushing onto any boxes they might administrate.

That article has generated a lot of good discussion though. So even if just indirectly, it's been a valuable contribution to HN.

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

#122

Post by ziziyO »

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.

That's never the case. Any decent colo facility has some way for you to reboot in single user mode and remote in to that, IP KVM is one such tool.

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

#123

Post by gingerlime »

zargon wrote: post #109
gingerlime wrote: post #101

Earlier quoted context omitted.

I'm using fabric quite frequently, and am trying to understand what makes a configuration management tools a much better choice. I'm currently using fabric for anything from bootstrap a new environment from scratch, via restoring a snapshot from backups, to pushing code updates stored on git. Perhaps I'm being really daft, but it always evades me why something as simple as sudo("apt-get install -y ") needs to be repl…

Deployment tools like fabric are imperative, and configuration management tools are declarative. With configuration management, you define the final state you want the server to be in, and it will do whatever is needed to get it into that state. Some or all of the parts might already be done, and it won't change the parts that are already correct (the declarative configuration is idempotent). Deployment tools just ex…

Thanks for the clarification. I think I get the theory a bit better now.

I'm still struggling with seeing some practical examples of those differences.

for example, `apt-get` is pretty much idempotent already, no? if I run `apt-get install -y ` x 1000 times in a loop it won't install it 1000 times...

Fabric does give you the building blocks for those kind of checks elsewhere, such as `exists`, `contains`, `append` (which is supposed to also be idempotent) etc... I've designed my deployment / bootstrap scripts with fabric to take this into account. It does add a little overhead, but nothing that makes me feel I need a better tool... Maybe my deployment base is still relatively small and homogeneous.

So it's true that I have to put in those checks myself, and that I don't have a very easy way to discover what state a server is at.

I'll try to take another stab at one of those tools. Maybe things will sink in when I actually use them. Thanks again for explaining.

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

#124

Post by thomasknowles »

joelesalas wrote: post #85
mef wrote: post #71

Earlier quoted context omitted.

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?

It's a basic principle of security. Each account represents one person so that you have a full audit of who did what by watching the activity of a given user account. If everything is run as "devops" user for example, you have no idea who actually performed a given task. Was it Bill, or was it an automated job? PCI-DSS requirements also affect your model for user accounts (hint: shared users are often not compliant).…

Agreed, anyone who has touched PCI DSS would agree you need to associate access with a human user. This would not work. If you look at the security logs it won't differentiate between which keys were used for that generic account.

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

#125

Post by rdl »

luser001 wrote: post #90
joelesalas wrote: post #85

Earlier quoted context omitted.

It's a basic principle of security. Each account represents one person so that you have a full audit of who did what by watching the activity of a given user account. If everything is run as "devops" user for example, you have no idea who actually performed a given task. Was it Bill, or was it an automated job? PCI-DSS requirements also affect your model for user accounts (hint: shared users are often not compliant).…

Why do you say a VPN server is more secure? Which one? I, for one, trust ssh more than any other software wrt security, especially with password login disabled. Disclaimer: I am not a security expert.

When someone advocates using a VPN, that doesn't mean not using SSH too. VPN + firewall just restricts who has the potential to try to SSH to you, and provides additional protection and central access control/management.

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

#126

Post by rdl »

thaumaturgy wrote: post #65

A few gentle suggestions: > The days of passwords are over. You’ll enhance security and ease of use in one fell swoop by ditching those passwords and employing public key authentication for your user accounts. ssh keys are better than passwords only because they contain (and require) more information. On the other hand, if your dev's machine is lost or stolen or compromised, so is your ssh key. This is especially a p…

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 require a password as well (e.g. to su), or do a VPN (which could have multiple forms of auth) and then ssh with keys after that, but the newest ssh (and I believe commercial ssh for a long time) now supports requiring multiple authentications per login, so you can do ssh key plus passphrase.

There are also DLP/etc. reasons why ssh can be problematic in some environments (i.e. where you're required to log/analyze actions taken by users, particularly admin users). The solution there is to use a bastion host and ssh in and then ssh out, with the user account locked down to log. SSH Communications (the commercial ssh people) have an interesting ssh MITM box which essentially does what all the SSL x509 MITM CA things do.

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

#127

Post by nlew »

gingerlime wrote: post #123
zargon wrote: post #109

Earlier quoted context omitted.

Deployment tools like fabric are imperative, and configuration management tools are declarative. With configuration management, you define the final state you want the server to be in, and it will do whatever is needed to get it into that state. Some or all of the parts might already be done, and it won't change the parts that are already correct (the declarative configuration is idempotent). Deployment tools just ex…

Thanks for the clarification. I think I get the theory a bit better now. I'm still struggling with seeing some practical examples of those differences. for example, `apt-get` is pretty much idempotent already, no? if I run `apt-get install -y ` x 1000 times in a loop it won't install it 1000 times... Fabric does give you the building blocks for those kind of checks elsewhere, such as `exists`, `contains`, `append` (w…

If you're only doing one or two things, the value is a bit more vague. But consider even the simplest interaction: the config file for a service should look like X, and if it has to be changed, the service needs to be restarted afterward. Oh and there are 10 config files, but you only want to restart the service once if any of them changes, after they've all been changed. That's not hard, but it's already starting to look non-trivial.

And what if you want to have the same logic for several services? I guess you abstract it out to a function. But then it turns out one of those services doesn't have a restart command, and you have to do stop+start. And another service won't start if you use restart while it's not running, so you have to check if it's stopped and use start, otherwise use restart.

It's much more than just whether the code is declarative or imperative, or whether it's idempotent or not. An imperative tool can change your system from known initial state A to desired state B. A declarative system can change it from whatever initial state it's in to desired state B, even if you never considered it might be in that state.

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

#129

Post by mryan »

luser001 wrote: post #90
joelesalas wrote: post #85

Earlier quoted context omitted.

It's a basic principle of security. Each account represents one person so that you have a full audit of who did what by watching the activity of a given user account. If everything is run as "devops" user for example, you have no idea who actually performed a given task. Was it Bill, or was it an automated job? PCI-DSS requirements also affect your model for user accounts (hint: shared users are often not compliant).…

Why do you say a VPN server is more secure? Which one? I, for one, trust ssh more than any other software wrt security, especially with password login disabled. Disclaimer: I am not a security expert.

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 eventually discovered and exploited. Mine, which will only allow SSH connections from my VPN bastion host, are effectively invisible to the attacker and will not get exploited (by this particular script kiddie, at least).

Adding a VPN server in front of SSH won't protect you from an APT, but it will protect you from 99% of the random, automated attacks that take place.

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

#130

Post by packetslave »

rdl wrote: post #126
thaumaturgy wrote: post #65

A few gentle suggestions: > The days of passwords are over. You’ll enhance security and ease of use in one fell swoop by ditching those passwords and employing public key authentication for your user accounts. ssh keys are better than passwords only because they contain (and require) more information. On the other hand, if your dev's machine is lost or stolen or compromised, so is your ssh key. This is especially a p…

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…

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.
Post reply on HN