web server protection

Question

I've been writing a kind of a web-server (without any SQL db, interpreted languages). So, one rather serious man had looked at it, he said like: "there's no problem to crash it... simply by DDoSing...". I agreed with him, but...

That's what I want to ask: which part of protection should be written directly inside code of server. I mean, I do not try to write a net filter (there are some special programs for that, written by professional secure-specialists, as netfilter/iptables ect.), I just try to write well-protected web-server.

So, which kind of web-attack protection should and which shouldn't be inside web-server?

(first thing, I should do - buffer overload protection... That's all I can imagine now...)

Answer 1

Well, there are buffer overflows. If you're using a compiled language and low-level data types, this is always problematic. You need to assume the worst from your clients. If someone sends you a 1MB URL and you only allocated 2k (and fail to check length), that's an overflow. A crafty guy can overwrite your stack with executable code and "own" your server.

There are DDoS attacks. Connection rate limiting will keep the box alive, but it'll still appear to go down. If you don't clean up stale connections fast enough, that's a sure way to run out of connections. If you aren't actively checking the available number of sockets, and assuming that "infinity" is what's available, that'll be a problem. At least need to check for the error and handle it appropriately.

Basic resource awareness... do I have enough RAM, socket handles, etc. to open this connection? Lots and lots of things, but if you code defensively, then you won't have too many problems. Also, watch out if you're spawning a new thread for every new connection. They are not limitless either.