About Archive Tags RSS Feed

 

Want to fight about it?

24 March 2013 21:50

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.

Tags: bookmarks, coding, github | 2 comments

 

Comments on this entry

icon Marco Innocenti at 12:34 on 24 March 2013

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

icon Steven C. at 12:43 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.

 

Created by ephemeris.

© Steve Kemp