NetFilter
[Top] [All Lists]

Re: syn DDoS attack solution

To: Ric Messier <kilroy@WasHere.COM>, netfilter@lists.netfilter.org
Subject: Re: syn DDoS attack solution
From: "Tony.Ho" <support@idccenter.cn>
Date: Fri, 01 Jun 2007 09:20:26 +0800
Cc:
Delivered-to: sp-com-lists@consult.net
Delivered-to: netfilter-list1@securepoint.com
In-reply-to: <015e01c7a3bf$64fbe7e0$2ef3b7a0$@COM>
List-archive: </pipermail/netfilter>
List-help: <mailto:netfilter-request@lists.netfilter.org?subject=help>
List-id: General discussion and user questions <netfilter.lists.netfilter.org>
List-post: <mailto:netfilter@lists.netfilter.org>
List-subscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=subscribe>
List-unsubscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=unsubscribe>
References: <465EF582.4070904@bgs.hu> <015e01c7a3bf$64fbe7e0$2ef3b7a0$@COM>
Sender: netfilter-bounces@lists.netfilter.org
User-agent: Thunderbird 2.0.0.0 (Windows/20070326)
I have a thought about this.
I can use ipset and iptables on a bridge firewall.

ipt_recent module compares the SYN package and ACK package's TTL. If not match then drop. ipt_hashlimit module stores the concurrent connections. When the connections exceed the threshold iptables would store the IP in ipset. ipset's iptree modules can store the IP in a fixed time. When a IP which is in the iptree's list comes the firewall iptables would TARPIT its tcp connection.

Is this setting effective?


Ric Messier wrote:
Bgs writes:
  We recently got under a low traffic botnet DDoS attack. All attacker
nodes opened a single tcp session (just SYN part) and then did nothing.
This rules out rate limiting solutions and syncookie doesn't help
either. (Thousands of attacking nodes).


This is simply a SYN flood attack. It may or may not be a botnet (though
saying botnet makes it sound sexier :-) ). A decent SYN flood attack tool
would randomize the source address anyway.
You should try reading the following as a starting point:

http://www.securityfocus.com/infocus/1729

Your second suggestion has been implemented in the TCP/IP stack forever. The
article above gives guidance on how to tune it in a Linux implementation.

Ric






<Prev in Thread] Current Thread [Next in Thread>