Ask HN: server security intro/reference? | Hacker News Reader

Ask HN: server security intro/reference?

3 pointsnfnaaron8 comments

I'm just starting out in server land. Prior to this, everything I've built has been on top of an infrastructure that someone else secured and maintained.

Last couple days I've been perusing security related posts here, and following links.

And I have to say: gaaa!

Admin/security is a firehose.

My problem is that waiting until I know that I know enough would mean that I'll never get anything done, I'll always be waiting to be better. In development the idea of waiting to learn something until you need it makes sense. In admin/security that approach can be fatal.

What I'd like to see, if you're aware of any, is a resource or resources that allow you to approach things with a strategy of layered importance. An overview of where you're going, where the details are then arranged as:

  - If nothing else, do these few N things first and absolutely.
  - Next, certainly do these things as soon as you can.
  - Finally, for uber control and confidence, consider these.

I guess knowing how people break things down into categories and areas of focus would be helpful too.

The question is mainly about server security, but if you want to throw something in about app security/integrity, and recovery from a server or app breach, that would be appreciated too.

Thanks. I think I'll go breath into a paper bag for awhile.

[edit: formatting]

Yes, it is a very complex field of study. I am able to sleep at night by following as many of the best practices that are out there, even those I don't think apply to me.

For checklists, look at the NSA's guide to hardening computers. You should also know exactly what services are running on your server, and dig hard through their manuals to learn more about how to secure them. Mysql, for instance, has 4-5 good tips on how to secure it which are in the security section of their manual.

Finally, don't run services that aren't updated or aren't used. Reduce your potential attack vector to as few known points as possible, so that you can harden those points. Have a web server up? Turn off apache mods that you don't use. THat kind of thing.

Turn on logging. Log everything. Check that you know how to analyze your logs. Make sure to rotate them as well -- opening 2GB files b/c you didn't rotate them daily sucks.

Disaster recovery is a huge part of this. Think of it this way -- you're not a big target (I can tell b/c a big target would already have experts in this field). Chances are good that you have an exploitable part of your web app / site / server. You probably won't know of its existence until after an attack. At that point, you need to be ready to roll EVERYthing back to a known clean point. This is not an easy thing to do, so make sure you practice it.

Those are just a few off my head.

"gaaa!" is an entirely legitimate response to this and the same one I had when I looked at it in the middle of last year (and I've been playing the game since 1980 (sic), but not since 2000 ... the threat environment has exponentially increased since then).

I'm afraid my only recommendation is not immediately useful, which is to start reading/skimming a 1,000 page book, Practical Unix & Internet Security, 3rd Edition by Simson Garfinkel et. al. (http://www.amazon.com/Practical-Unix-Internet-Security-3rd/d...).

But's that reference is only "a mile wide and an inch deep* (from the Amazon.com reviews).

How much time do you have? How much flexibility in choosing your OS (e.g. is OpenBSD or a Linux that really implements SELinux an option)?

And there are so many details today, like how do you get adequate entropy for your RNG on a VPS?

Gaaa!

"But's that reference is only 'a mile wide and an inch deep'"

So maybe that's an overview/jumping off point?

I've run FreeBSD at home years ago. I'm on slicehost for now, the and linode offer mainstream-ish linux.

My concern with *BSD, or a less mainstream Linux, is the difficulty it may introduce in developing and running apps based on the many ready-made tools and frameworks available. Good security vs easy development. "Gaaa!"

If I was starting fresh, that would be my jumping off point. It will orient you, it develops a good philosophy and it will allow you to build your own priority ordered lists (which you probably won't be able to find as such, since things are so unstandardized (and therefore exciting!) right now), and then you'll know what to drill down to with Google et. al.

And, yep, you've outlined one fundamental tradeoff, but in server space this should be less of a problem. But I wouldn't be personally adverse to starting out with a distribution with a serious SELinux implementation (e.g. Fedora, but that has an upgrade problem). Of course SELinux just by itself is somewhat complicated, but it's the only defense in depth solution I know of. And I want one of those in addition to making the "crusts" as hardened as possible.

One thing I'd think strongly about is getting one foundation in place ASAP: disaster and intrusion recovery.

Just like the second thing I do after "Hello, world!" in a new programming project is to set up a good logging system, being able to recover from "man caused" and other disasters will help you a lot until you're a Uber Security Guru.

Ask me if you're responsible for keeping customer information secure ... that's its own can of worms and one that's I've worked on myself.

"Ask me if you're responsible for keeping customer information secure ... that's its own can of worms and one that's I've worked on myself."

I'm one guy, building a web app up from nothing. So yeah, I'm responsible. :-/

My initial approach is to never have a CC number touch my server, and to absolutely limit the amount of information I need from users. Nevertheless, I do want my users' data to be as private as they make it, and I don't want to find myself hosting inappropriate stuff from breakins or "users of convenience."

You've got the right ideas. (And I've been there WRT to the "users of convenience", not fun but one of the less harmful attacks ... unless they use you to spam.)

There's the usual set of things to do with your less sensitive user information: salt and hash passwords appropriately, make your password reset system sane (non-obvious security questions if you go that route), and then as a first step I'd just harden the data on-line. Perhaps encrypt the disk copies so that simply grabbing files won't be sufficient, raise the bar sorts of things.

Simson's book very quickly goes into policies: risk assessments, trade-offs, all that. Get minimally organized there and you can then do something like this:

  What's the threat level?

  What's the cost of compromise?

  How much effort should I put into this?

Then what you should do will be more obvious.

Oh yeah, one thing I forgot to add, in relation to Travis and my suggestions about recovery: have some minimal automated intrusion/modification checks, so you'll have a chance of knowing your system has been compromised.

Thanks lots. Encouraging to know, based on responses, that I'm thinking in some of the right directions.

ocean large, boat small

You're very welcome.

A lot of this is just common sense and thinking things through ... you've already made the only step that really matters, which is taking the issue seriously and proactively.

Good luck, and if you have any specific questions in the future I'm always game; my email is in my HN profile.

Reply on news.ycombinator.com