

Ask HN: server security intro/reference? - nfnaaron

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.<p>Last couple days I've been perusing security related posts here, and following links.<p>And I have to say: gaaa!<p>Admin/security is a firehose.<p>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.<p>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:<p><pre><code>  - 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.
</code></pre>
I guess knowing how people break things down into categories and areas of focus would be helpful too.<p>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.<p>Thanks. I think I'll go breath into a paper bag for awhile.<p>[edit: formatting]
======
Travis
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.

------
hga
"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...](http://www.amazon.com/Practical-Unix-Internet-
Security-3rd/dp/0596003234/)).

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!

~~~
nfnaaron
"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!"

~~~
hga
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.

~~~
nfnaaron
"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."

~~~
hga
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.

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

ocean large, boat small

~~~
hga
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.

