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

291–300 of 355 posts

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

#291

Post by samstave »

belorn wrote: post #258

> No secure server is complete without a firewall. Comments like those are why I normally point people to actual security expects (like, say, Schneier), and why I recommend that new admins should ignore as much as possible the practices chanted by the industry. A secure server does not need a firewall. A firewall can be used to secure a server against a specific threat, but that's it. The days of ping of death are be…

In general, people should keep a broader idea of security to include resiliancy.

Robust, redundant deployments should be a part of an overall security policy, securing yourself from outages and downtime.

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

#292

Post by marcosdumay »

alan_cx wrote: post #259

Imagine you are a fairly normal windows user or even sysadmin. Imagine you are considering Linux to replace some task that a windows server performs. Now imagine the conclusion after reading this thread. As some one who can just about get something useful done in Linux, this thread makes me want to never use it again, it just looks too scary. Loads of disagreements which seems to have lots of dire consequences. OK, g…

There is just one action on the post that will have dire consequences if ignored: disabling the ssh password authentication.

The rest are decisions that you don't need to rush into, and things you should learn when they make sense. Be advised that "the proper way to configure a server" is an elusive beast, you'll be always improving it, it's never done.

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

#293

Post by marcosdumay »

npsimons wrote: post #264

passwd Change the root password to something long and complex. And bam! Not even a full paragraph in and security fail. root login should be disabled completely, and all use of privileges should be through sudo. Debian sets this up for you automatically upon install if you supply an empty root password. Of course, disabling root is just the beginning (and the first user created needs to be locked down, as they are no…

> root login should be disabled completely

Would you care to explain why?

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

#294

Post by ajdecon »

belorn wrote: post #258

> No secure server is complete without a firewall. Comments like those are why I normally point people to actual security expects (like, say, Schneier), and why I recommend that new admins should ignore as much as possible the practices chanted by the industry. A secure server does not need a firewall. A firewall can be used to secure a server against a specific threat, but that's it. The days of ping of death are be…

> The only thing I can think of is either a Zero day TCP/IP stack vulnerability (not a realistic threat), or that the admin doesn't trust the other admins when they install new services. Yes, if an admin installs a new email server and enables relaying to the whole world against the explicit recommendation in bold font by the install wizard and the configuration file, a firewall can block that admins' actions. Then again, that same admin could just as well have disabled the firewall to "get the mail to work", so I'm not sure it's a viable defense against bad admins.

I think it's less about defense against "bad admins" than it is about protecting against accidental bone-headedness. :-) I typically set up a restrictive firewall policy even when I have a clear list of the services I'm running and/or I am the only admin. This comes in handy every once in a while, in cases where...

* A service is expecting more ports to be open than are documented. (Happens not-infrequently with license servers.)

* I'm re-using an old image and there are undocumented services enabled by default.

* A user decides to run a network service in their own account without informing the admins.

In all those cases, am I likely to change the firewall to "make it work"? Sure. But having to actually make that change helps keep an audit trail, and helps keep the admins explicitly aware of the attack surface. It's similar to why it's a good idea to periodically run nmap against your own servers.

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

#295

Post by marcosdumay »

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.

And, yet, the best practice seems to require an user account with full sudo priviledges.

If you know the difference between that and root, please explain it, because I can't see any.

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

#296

Post by marcosdumay »

RobAley wrote: post #178
fsniper wrote: post #163

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?

Bear in mind that in small company, developer == dev op == sys op == network manager = testers == toilet cleaner. i.e. they do everything, dev or production. As regards to unattended upgrades, again in small companies the choice is usually between them or no upgrades (no time for the test/deploy cycle across all platforms in use etc., less frequently used systems get forgotten and so on). As the article points out, i…

If you don't have time to test, you have yet another reason to not automate updates. It's better to run them only when you are around and have some time to fix whatever goes wrong.

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

#297

Post by packetslave »

majelix wrote: post #209
packetslave wrote: post #130

Earlier quoted context omitted.

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.

Expiring an ssh-key on YOUR machine is "easy". Ensuring it's really gone on every, single UNIX-like box anywhere in your company is less easy. Oh, and what happens when you restore a home directory or entire machine from tape? Are you absolutely sure you remembered to delete every SSH key you wanted to "expire" at some point?

SSH keys do not satisfy a "fail closed" security model: they're there unless you explicitly remove them (and keep them removed). Certificates, tickets, and other expiring credentials eventually go away and lock users out unless they're explicitly renewed.

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

#298

Post by ajacksified »

Wilya wrote: post #194
kelnos wrote: post #187

Earlier quoted context omitted.

The problem is that most of the recommendations are bad. Having an up-to-date system and only accepting security updates is a good policy. Fail2ban is a good tool (but it's a starting point; you should be doing other things to detect suspicious behavior). The rest is just bad advice. Having everyone log in using a single user account is a terrible idea. You can't audit who did what, ever. You have to remember to remo…

I agree on a lot of things, except LDAP. Of course, it sounds like the ideal way, but in practice, there's a matter of scale to take into account. Frankly, you need a lot of developers and servers before investing the time to setup a ldap deployment, integrating it with logins, and spending the inevitable hours debugging why nobody can access anything anymore, becomes more worth it than "just rsync/pssh into all serv…

My friend and I are rebuilding an old, text-based browser RPG, occasionally with another friend helps out with art and game content.

We're on LDAP, which we use to SSH into our ec2 servers, and which we use for authentication when we deploy using `git push production master` to a GlusterFS cluster. We're running our LDAP, application, and file servers on Gentoo. We can easily add new accounts, and we have it set up with group permissions (so the friend can deploy game content to test but not prod, for example).

I refuse to believe that LDAP is "too complicated" or "has to scale before it's useful", when a couple of guys can, in their free time, set it up for themselves. It's saved us a load of time in managing servers that would otherwise take away from the limited time we have to actually write code.

It's also a whole lot cleaner than a bunch of Chef scripts running a script across a quantity of servers; using Chef can too often be a crutch to fixing the actual issue.

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

#299

Post by packetslave »

linker3000 wrote: post #222
packetslave wrote: post #130

Earlier quoted context omitted.

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/

You require both key-based AND password auth with OTP? Or is the OTP at a higher layer, e.g. VPN.
Post reply on HN