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

151–160 of 355 posts

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

#151

Post by raverbashing »

packetslave wrote: post #130
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…

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.

Thank you

People often consider ssh keys to be a panacea and to think of passwords as outdated

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

#152

Post by crdoconnor »

drivebyacct2 wrote: post #145
tomp wrote: post #143

Earlier quoted context omitted.

Sure. It's only meant to stop automated script-kiddie attacks that target all open SSH servers on the internet. Less logs, less disk usage, ...

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.

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

#153

Post by lmm »

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?

Puppet/chef are certainly worth it for 3 machines. If it's an important machine they're worth it for even 1 machine (so that you have a disaster recovery procedure).

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

#154

Post by crdoconnor »

vacri wrote: post #105
dbarlett wrote: post #51

Earlier quoted context omitted.

I was in the same position - too many distinct environments for bash/Fabric, too little time to learn Chef/Puppet/CFEngine. Ansible [1] seems like a good compromise: you get the simplicity (runs over SSH) and host targeting of Fabric with the declarative nature and idempotency of the more complex tools. You can start with all-in-one "playbooks" [2], then split out tasks, handlers, Jinja2 templates, files, and variabl…

Eh, I didn't like Ansible. Every command is done over SSH, so you don't need an agent/ssh to box and run locally, but... scripts would take much longer to execute than in puppet. We're currently using local runs of puppet, and it's easy to do dry-runs and see what fails before applying when testing. I'm not sure how Ansible gives feedback on that (I assume it must) but I find puppet pretty good about it.

>but... scripts would take much longer to execute than in puppet.

You can bootstrap 0mq and run them over that instead. That's much faster.

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

#155

Post by raverbashing »

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.

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

#156

Post by buster »

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?

Voting for Ansible or Puppet here.

http://ansible.cc/

https://puppetlabs.com/

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

#157

Post by mryan »

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.

Yes, I agree, I was just giving an example of how an additional layer can help protect against automated attacks, even for highly-secure services like SSH.

I also agree that SSH is less likely to have flaws than most VPN software. But on a properly configured bastion host, by-passing the VPN would just put you in a position where you can attack SSH. You would still need to by-pass SSH to access production servers.

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

#158

Post by mercurial »

beagle3 wrote: post #55

1. You should do "apt-get dist-upgrade" to get new kernel packages as well, otherwise you are stuck on an old kernel. (You might want that. I prefer updated kernel for the security, firefoxen, etc.). "apt-get upgrade" will only update existing packages - but the kernel updates require new packages to be installed. 2. If you're on ubuntu, root already has no password, and your initial setup user (whether it is called…

I love etckeeper, but the use of a configuration management system (puppet/chef/salt...) tends to reduce its usefulness.

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

#159

Post by lotsofcows »

drivebyacct2 wrote: post #145
tomp wrote: post #143

Earlier quoted context omitted.

Sure. It's only meant to stop automated script-kiddie attacks that target all open SSH servers on the internet. Less logs, less disk usage, ...

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.

They don't seem to. Plus, if they hit more than 5 ports their ip gets blocked. Plus it keeps crap out of my logs...

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

#160

Post by lotsofcows »

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