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

201–210 of 355 posts

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

#201

Post by crucialfelix »

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?

I wasted several days trying to get a good puppet setup. In the end it still needs more work, and the deploy system is complicated. I only have 4 boxes to manage.

Ansible looks great. Much lighter weight but it can still scale up.

Puppet and chef would both benefit by supporting single run light weight modes of usage.

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

#202

Post by daemon13 »

mryan wrote: post #157
lmm wrote: post #132

Earlier quoted context omitted.

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.

Which open source VPN solution would you recommend?

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

#203

Post by daemon13 »

kelnos wrote: post #189
lmm wrote: post #132

Earlier quoted context omitted.

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.

anyone who compromises [the VPN server] is in a pretty good position. Sure. But without a VPN, anyone who compromises even one of your other hosts is in the same position. It's a lot easier to audit a single-purpose VPN server for possible security issues than it is to audit all the application code running on the rest of your production systems. And I'd rate the odds of a 0-day being found at higher for most VPN sof…

Same question - which open source VPN solution would you recommend?

I liked the idea of adding VPN layer to SSH, so would like to get as much advice as possible :-)

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

#204

Post by lenazegher »

drivebyacct2 wrote: post #162
lmm wrote: post #149

Earlier quoted context omitted.

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 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 16 character password immeasurably small. It's all muscle memory anyway.

>key based auth = me never having to type it in

Perhaps I'm clinging to a false sense of security, 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.

Perhaps in the theoretical world if they can access your machine it's game over anyway because they can install a keylogger. In the real world, I think there's a fairly large population of people who might access your server who wouldn't/couldn't install a keylogger to steal your password.

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

#205

Post by [deleted] »

xinternetx wrote: post #135
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…

.. and it saddens me each time I read a comment like this. It's best practice to disable remote root login. A whole industry supports this.

[deleted]

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

#206

Post by jackalope »

Nursie wrote: post #177
vidarh wrote: post #165

Earlier quoted context omitted.

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

But if you give people any access to any system surely this is a concern. As a software dev, maybe I've inserted something into one of the build scripts that quietly re-opens my backdoor to the source control server... I haven't, but if you assume actually malicious users you're probably going to end up with something so locked down it's useless. Aren't you?

Quite the contrary: You're probably going to end up with documented procedures for deploying software that are simplified, follow existing standards/best practices, and don't rely on complex stone soup build/init scripts concocted by inexperienced developers (and I've seen some doozies).

A developer is more likely to create better and more easily maintainable software if the target audience is assumed to be an ordinary user with no special system privileges. In my experience, when a developer has root and assumes everyone else does, deployment becomes a nightmare.

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

#207

Post by majelix »

ck2 wrote: post #104
bcl wrote: post #58

Don't forget: netstat -ntap | less ps aux | less Also check to see what's enabled to run at boot time via whatever your flavor uses. Check for unusual daemons, ssh running on other ports (yes, the provider pre-loaded systems with a back-door ssh without disclosing it to us). This is especially important when you are taking over admin on a server you didn't setup yourself. Other folks have weird ideas on how to admin…

to see what's enabled to run at boot time what's good beyond this: chkconfig cat /etc/rc.local

chkconfig is redhat specific. I believe debian-varients use update-rc.d.

Generically (for Linux), take a look at /etc/init.d , /etc/inittab, or /etc/rc?.d.

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

#208

Post by kelnos »

daemon13 wrote: post #203
kelnos wrote: post #189

Earlier quoted context omitted.

anyone who compromises [the VPN server] is in a pretty good position. Sure. But without a VPN, anyone who compromises even one of your other hosts is in the same position. It's a lot easier to audit a single-purpose VPN server for possible security issues than it is to audit all the application code running on the rest of your production systems. And I'd rate the odds of a 0-day being found at higher for most VPN sof…

Same question - which open source VPN solution would you recommend? I liked the idea of adding VPN layer to SSH, so would like to get as much advice as possible :-)

I've had success with OpenVPN. I don't know that I'd specifically recommend it over other options, as I don't have much experience with anything else.

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

#209

Post by majelix »

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.

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.

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

#210

Post by majelix »

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…

> 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) to the organization so you can check if it's encrypted; this has its own flaws (primarily that you've just taught your users to be giving with their private key), and you still can't enforce passphrase strength well.

Post reply on HN