Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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...)

share|improve this question

migrated from stackoverflow.com Feb 1 '10 at 8:51

This question came from our site for professional and enthusiast programmers.

"Surely you're not serious?" "I am serious, and stop calling me Shirley." –  AJ. Jan 30 '10 at 19:37
@AJ That was one weird movie. –  Kaleb Brasee Jan 30 '10 at 19:40
You mean, this 'serious man' wasn't as serios as I thought (well, in this area). So, there is nothing I should scare of, beyong buffer overload, building web-applications (self-severing applications). Well, what kind of procection Apache sever provides, than (by tons of setup files and so on)? –  MInner Jan 30 '10 at 19:57
You say you're not building a web server. Are you building a web application? The security concerns of an application are going to be quite a bit different than the security concerns of a server. –  Pace Jan 30 '10 at 20:06
@Pace Well, it's closer to sever... Yeah, that's a server. (but without interpretation, any kind of SQL db) ... no more "application" word in question... :) –  MInner Jan 30 '10 at 20:15

1 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.

share|improve this answer
Well, you've made me feel calm. Actually, if here are main problems of sever protection, my server is allready rather well-protected. :) PS Is DDoS protection is a sever (not filter?) proposition? –  MInner Jan 30 '10 at 20:47
You can DDoS anything with sufficient load. Best thing to do is stress test and look for choke points. How you mitigate the risk is up to you (hardware, filters, modifying your server, etc.). –  pestilence669 Jan 30 '10 at 22:48
What do you mean by "choke points"? I've found that : "In military strategy, a choke point (or chokepoint) is a geographical feature on land such as a valley"... That's not what you mean, probobly :) –  MInner Jan 31 '10 at 18:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.