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

221–230 of 355 posts

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

#221

Post by moe »

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?

If someone logs in directly as root, how do you track root access?

By their SSH-key and IP address (both of which are logged to a remote syslog-server).

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?

That is a false premise. I'd never encourage anyone to use "sudo" because it's a source of errors; people get the escaping and context wrong all the time, doing things that they didn't intend, and wasting precious productivity on getting the incantation just right.

It also doesn't add any meaningful security, it's a red herring.

If you need a dependable audit-trail then sudo is worth zilch. In that case you're looking at SELinux, auditd and friends.

If you don't need that trail (which is most people) then sudo is a ball on a chain and a false sense of security. Local privilege escalation exploits are dime a dozen, any shell-account can be upgraded to root by a dedicated attacker anyway (sometimes via sudo itself, as seen in in the recent sudo exploit...).

Oh, and let's not forget: If you enable a user to do anything meaningful with sudo then that normally includes giving him a way to write arbitrary files as root...

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

#222

Post by linker3000 »

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.

We throw an OTP (One time Password) into the mix using Yubikeys:

http://www.yubico.com/products/yubikey-hardware/yubikey/

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

#223

Post by Nursie »

jackalope wrote: post #206
Nursie wrote: post #177

Earlier quoted context omitted.

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

Not quite sure I understand what you're saying here, I'm not talking about the software being produced, but the systems used to produce it.

What I was trying to say was that there's not really any way for you (server admin guy) to know if I (software dev guy) have inserted something malicious into a script that all the other software folks run constantly (software build system, NOT server build/init script, NOT deployment script).

This is not about the end-user's privileges, or server set up, just how in a team-base software dev environment you're probably going to have to have a measure of trust for your employees.

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

#224

Post by moe »

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…

The answer is really easy: You should do both.

Disable password auth for root, and change the SSH port.

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

#225

Post by bluedino »

jiggy2011 wrote: post #97

The guide recommends blocking SSH access to anything other than your own IP address. The problem is that my IP number sometimes changes at which point I end up locked out totally. So to get around this you either have to allow SSH from anywhere or you have to use some remote KVM system. Most of the remote KVM systems seem to be based on Java applets which is not really something you want to enable on your system. So…

Our provider allows us to modify firewall rules through their control panel. Perfect for when we have a dev working from home or a hotel room for a few days.

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

#226

Post by dhimes »

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…

I would love to see a link to a counter-post of how to do it your way. Not generalities, but a specific guide.

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

#227

Post by stephen_g »

benedikt wrote: post #188
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…

This is just faulty logic. openssh is one of the most secure projects. It's developed by the security obsessed (and I mean it in a kind way) folks at OpenBSD. I, for one, am ready to place for more trust in openssh than in any VPN daemon. The most commonly used ones are propitiatory. What if there is a 0-day vuln (not exploit) for these VPN daemons? That far more likely. "Securing" ssh with a VPN is just one step bey…

Port scanners do generally scan non-standard ports too, you know...

I don't think that exposing SSH to the internet is that bad, but your argument is not sound - requiring a VPN does add security, because if there happened to be a vulnerability in it that allowed access, all it would do is expose SSH on the machines (I'm assuming you have proper firewalls set up), which you are advocating making public in the first place.

Saying it adds no security is false, because you'd require an unpatched vulnerability both in your VPN server and in the SSH server simultaneously. A zero-day in one is possible, but in both at the same time is far, far less likely.

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

#228

Post by jackalope »

Maybe this is considered a preinstallation step, but the very first thing to do is set the system time on the hardware, before you even boot the OS for the first time. Then the first step after booting is to confirm the time and reset it, if necessary. This is essential for accurate and usable logs, file times, version control timestamps, etc.

It's also a good idea to ensure that sshd has fresh keys that are unique to that machine. Hopefully, your images are installed without sshd keys, otherwise you'll have multiple servers with the exact same keys, which is considered bad practice. During initial configuration before deployment, you might want to remove the keys so that sshd will create fresh ones when it starts:

    rm -rf /etc/ssh/ssh_host_*

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

#229

Post by lotsofcows »

belorn wrote: post #217
lotsofcows wrote: post #160

Earlier quoted context omitted.

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

I am the admin. I use the root account as little as possible. I do employ admins that don't rm -rf / by employing admins who don't hack on live as root. Knowing who does what is paramount for resolving problems particularly in admins' work practices.

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

#230

Post by beagle3 »

mercurial wrote: post #158
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.

On the contrary - it is useful exactly to figure out when and what manual changes were made outside of the automated system.
Post reply on HN