Steve Kemp's Blog Writings relating to Debian & Free Software

Want to fight about it?

Sun, 24 Mar 2013 12:32:38 GMT

So via hackernews I recently learned about fight code, and my efforts have been fun. Currently my little robot is ranked ~400, but it seems to jump around a fair bit.

Otherwise I've done little coding recently:

I'm pondering libpcap a little, for work purposes. There is a plan to write a deamon which will count incoming SYN packets, per-IP, and drop access to clients that make "too many" requests "too quickly".

This plan is a simple anti-DoS tool which might or might not work in the real world. We do have a couple of clients that seem to be DoS magnets and this is better than using grep + sort against apache access logs.

For cases where a small number of source IPs make many-many requests it will help. For the class of attacks where a huge botnet has members making only a couple of requests each it won't do anything useful.

We'll see how it turns out.

| 2 comments.

 

Comments On This Entry

[gravitar] Marco Innocenti

Submitted at 12:34:38 on 24 March 2013

You could simply use the match "hashlimit" in iptables. There is no need to write a daemon.

[gravitar] Steven C.

Submitted at 12:43:56 on 24 March 2013

That can be done simply enough with iptables: -m hashlimit --hashlimit-above 1/sec --hashlimit-burst 64 --hashlimit-mode srcip --hashlimit-name SYN-FLOOD -j DROP

The initial burst threshold ought to be high enough for annoying ISP/corporate webfilters/prefetchers that seem to slam a server with many simultaneous, non-pipelined HTTP requests. Or for people who tweaked their browser's concurrent connection limit based on dubious advice. DROP is good because a genuine connection will retry after 1, then 3 seconds or so and then it may succeed.

ipt_recent can be used instead of DROP, if you want to add IPs into a longer-term banlist (an hour, say). Its proc interface allows to add/remove/query IPs in that list by hand. A separate rule looks up IPs in that list and applies some action.

To help with tuning, consider adding a couple of rules 'either side' with higher/lower thresholds, with action -j LOG instead of DROP (or separate ipt_recent tables with no associated -j DROP rule). Then you can see which IPs would or would not have been filtered if the thresholds were adjusted either way.

 

Comments are closed on posts which are more than ten days old.

Spiral Logo

Search

Recent Posts

Recent Tags

Links

RSS Feed

  • Subscribe to feed