Add seperated timeout for the connections that only receive packets in one direction

Add seperated timeout for the connections that only receive packets in one direction

[Changli Gao]

Add seperated timeout for the connections that only receive packets in one direction.

If we use tcp_timeouts[TCP_CONNTRACK_ESTABLISHED] to timeout the connections that only receive packets in one direction, ACK flood attack with fake source address A will exhaust A's connection limit, and A is DoSed. After the attack is stopped, A can't recover quickly due to the large timeout value.

This patch adds a new timeout value: nf_ct_tcp_timeout_loose_unreply for this kind of connections. It can help A to recover quickly after the attack is over.

Signed-off-by: Changli Gao <xiaosuo@gmail.com>
----
 nf_conntrack_proto_tcp.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
index 7eda8b8..471045a 100644
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -70,6 +70,8 @@ static const char *const tcp_conntrack_names[] = {
 static unsigned int nf_ct_tcp_timeout_max_retrans __read_mostly    =   5 MINS;
 static unsigned int nf_ct_tcp_timeout_unacknowledged __read_mostly =   5 MINS;
 
+static unsigned int nf_ct_tcp_timeout_loose_unreply __read_mostly  =   30 SECS;
+
 static unsigned int tcp_timeouts[TCP_CONNTRACK_MAX] __read_mostly = {
 	[TCP_CONNTRACK_SYN_SENT]	= 2 MINS,
 	[TCP_CONNTRACK_SYN_RECV]	= 60 SECS,
@@ -1006,6 +1008,9 @@ static int tcp_packet(struct nf_conn *ct,
 			nf_ct_kill_acct(ct, ctinfo, skb);
 			return NF_ACCEPT;
 		}
+		if (new_state == TCP_CONNTRACK_ESTABLISHED &&
+		    timeout > nf_ct_tcp_timeout_loose_unreply)
+			timeout = nf_ct_tcp_timeout_loose_unreply;
 	} else if (!test_bit(IPS_ASSURED_BIT, &ct->status)
 		   && (old_state == TCP_CONNTRACK_SYN_RECV
 		       || old_state == TCP_CONNTRACK_ESTABLISHED)
@@ -1298,6 +1303,13 @@ static struct ctl_table tcp_sysctl_table[] = {
 		.proc_handler	= proc_dointvec,
 	},
 	{
+		.procname	= "nf_conntrack_tcp_timeout_loose_unreply",
+		.data		= &nf_ct_tcp_timeout_loose_unreply,
+		.maxlen		= sizeof(unsigned int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec_jiffies,
+	},
+	{
 		.procname       = "nf_conntrack_tcp_be_liberal",
 		.data           = &nf_ct_tcp_be_liberal,
 		.maxlen         = sizeof(unsigned int),
@@ -1394,6 +1406,13 @@ static struct ctl_table tcp_compat_sysctl_table[] = {
 		.proc_handler	= proc_dointvec,
 	},
 	{
+		.procname	= "ip_conntrack_tcp_timeout_loose_unreply",
+		.data		= &nf_ct_tcp_timeout_loose_unreply,
+		.maxlen		= sizeof(unsigned int),
+		.mode		= 0644,
+		.proc_handler	= proc_dointvec_jiffies,
+	},
+	{
 		.procname	= "ip_conntrack_tcp_be_liberal",
 		.data		= &nf_ct_tcp_be_liberal,
 		.maxlen		= sizeof(unsigned int),

Re: Add seperated timeout for the connections that only receive packets in one direction

[Jozsef Kadlecsik]

Hi,

On Fri, 27 Nov 2009, Changli Gao wrote:

> Add seperated timeout for the connections that only receive packets in 
> one direction.
> 
> If we use tcp_timeouts[TCP_CONNTRACK_ESTABLISHED] to timeout the 
> connections that only receive packets in one direction, ACK flood attack 
> with fake source address A will exhaust A's connection limit, and A is 
> DoSed. After the attack is stopped, A can't recover quickly due to the 
> large timeout value.
> 
> This patch adds a new timeout value: nf_ct_tcp_timeout_loose_unreply for 
> this kind of connections. It can help A to recover quickly after the 
> attack is over.
> 
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ----
>  nf_conntrack_proto_tcp.c |   19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> diff --git a/net/netfilter/nf_conntrack_proto_tcp.c b/net/netfilter/nf_conntrack_proto_tcp.c
> index 7eda8b8..471045a 100644
> --- a/net/netfilter/nf_conntrack_proto_tcp.c
> +++ b/net/netfilter/nf_conntrack_proto_tcp.c
> @@ -70,6 +70,8 @@ static const char *const tcp_conntrack_names[] = {
>  static unsigned int nf_ct_tcp_timeout_max_retrans __read_mostly    =   5 MINS;
>  static unsigned int nf_ct_tcp_timeout_unacknowledged __read_mostly =   5 MINS;
>  
> +static unsigned int nf_ct_tcp_timeout_loose_unreply __read_mostly  =   30 SECS;
> +
>  static unsigned int tcp_timeouts[TCP_CONNTRACK_MAX] __read_mostly = {
>  	[TCP_CONNTRACK_SYN_SENT]	= 2 MINS,
>  	[TCP_CONNTRACK_SYN_RECV]	= 60 SECS,
> @@ -1006,6 +1008,9 @@ static int tcp_packet(struct nf_conn *ct,
>  			nf_ct_kill_acct(ct, ctinfo, skb);
>  			return NF_ACCEPT;
>  		}
> +		if (new_state == TCP_CONNTRACK_ESTABLISHED &&
> +		    timeout > nf_ct_tcp_timeout_loose_unreply)
> +			timeout = nf_ct_tcp_timeout_loose_unreply;

I don't see how can the condition be true. The first reply 
packet checked here and if that's a pure ACK, then the new_state cannot be 
TCP_CONNTRACK_ESTABLISHED (except for picked up connections).

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Add seperated timeout for the connections that only receive packets in one direction

[Changli Gao]

On Fri, Nov 27, 2009 at 5:25 PM, Jozsef Kadlecsik
<kadlec@blackhole.kfki.hu> wrote:
> Hi,
>
> On Fri, 27 Nov 2009, Changli Gao wrote:
>
>
> I don't see how can the condition be true. The first reply
> packet checked here and if that's a pure ACK, then the new_state cannot be
> TCP_CONNTRACK_ESTABLISHED (except for picked up connections).
>

Yes, as nf_conntrack_tcp_timeout_loose_unreply implied, it is for
picked up connections.


-- 
Regards，
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add seperated timeout for the connections that only receive packets in one direction

[Jozsef Kadlecsik]

On Fri, 27 Nov 2009, Changli Gao wrote:

> On Fri, Nov 27, 2009 at 5:25 PM, Jozsef Kadlecsik
> <kadlec@blackhole.kfki.hu> wrote:
> >
> > On Fri, 27 Nov 2009, Changli Gao wrote:
> >
> >
> > I don't see how can the condition be true. The first reply
> > packet checked here and if that's a pure ACK, then the new_state cannot be
> > TCP_CONNTRACK_ESTABLISHED (except for picked up connections).
> 
> Yes, as nf_conntrack_tcp_timeout_loose_unreply implied, it is for
> picked up connections.

Connection pickup can be disabled by proper rules or by setting 
nf_ct_tcp_loose to zero. So in which environment this third method is 
required? I'm curious what triggered you to write your patch.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Add seperated timeout for the connections that only receive packets in one direction

[Changli Gao]

On Fri, Nov 27, 2009 at 5:42 PM, Jozsef Kadlecsik
<kadlec@blackhole.kfki.hu> wrote:
> On Fri, 27 Nov 2009, Changli Gao wrote:
>
>>
>> Yes, as nf_conntrack_tcp_timeout_loose_unreply implied, it is for
>> picked up connections.
>
> Connection pickup can be disabled by proper rules or by setting
> nf_ct_tcp_loose to zero. So in which environment this third method is
> required? I'm curious what triggered you to write your patch.
>

In some condition, you can't disable it. It's why we export
nf_ct_tcp_loose. As a bridge, if its booting breaks connections, users
won't happy, so we must allow loose mode.

-- 
Regards，
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add seperated timeout for the connections that only receive packets in one direction

[Patrick McHardy]

Changli Gao wrote:
> On Fri, Nov 27, 2009 at 5:42 PM, Jozsef Kadlecsik
> <kadlec@blackhole.kfki.hu> wrote:
>> On Fri, 27 Nov 2009, Changli Gao wrote:
>>
>>> Yes, as nf_conntrack_tcp_timeout_loose_unreply implied, it is for
>>> picked up connections.
>> Connection pickup can be disabled by proper rules or by setting
>> nf_ct_tcp_loose to zero. So in which environment this third method is
>> required? I'm curious what triggered you to write your patch.
>>
> 
> In some condition, you can't disable it. It's why we export
> nf_ct_tcp_loose. As a bridge, if its booting breaks connections, users
> won't happy, so we must allow loose mode.

That won't help much. If you're able to spoof packets, you might
as well spoof packets for both direction so SEEN_REPLY is set.

Re: Add seperated timeout for the connections that only receive packets in one direction

[Patrick McHardy]

Changli Gao wrote:
> It is not easy to spoof in both directions. Routers won't forward it if the destination is at the same side.

Please don't top post.

They don't need to forward anything, conntrack handles the packet before
routing.

> Patrick McHardy <kaber@trash.net>写道：
> 
>> Changli Gao wrote:
>>> On Fri, Nov 27, 2009 at 5:42 PM, Jozsef Kadlecsik
>>> <kadlec@blackhole.kfki.hu> wrote:
>>>> On Fri, 27 Nov 2009, Changli Gao wrote:
>>>>
>>>>> Yes, as nf_conntrack_tcp_timeout_loose_unreply implied, it is for
>>>>> picked up connections.
>>>> Connection pickup can be disabled by proper rules or by setting
>>>> nf_ct_tcp_loose to zero. So in which environment this third method is
>>>> required? I'm curious what triggered you to write your patch.
>>>>
>>> In some condition, you can't disable it. It's why we export
>>> nf_ct_tcp_loose. As a bridge, if its booting breaks connections, users
>>> won't happy, so we must allow loose mode.
>> That won't help much. If you're able to spoof packets, you might
>> as well spoof packets for both direction so SEEN_REPLY is set.

--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add seperated timeout for the connections that only receive packets in one direction

[Changli Gao]

On Fri, Nov 27, 2009 at 7:47 PM, Patrick McHardy <kaber@trash.net> wrote:
> Changli Gao wrote:
>> It is not easy to spoof in both directions. Routers won't forward it if the destination is at the same side.
>
> Please don't top post.

Sorry, I don't notice that G1 top posts.

>
> They don't need to forward anything, conntrack handles the packet before
> routing.
>

Think about this topologic:

Attacker -> router1 -> router2 -> ... -> Linux Router -> Apache.

the packets in the other direction won't be sent to the Linux Router,
as the other routers will routed them to the other place.

Case 2:

Attacker ---+
                +-- Linux Router --> WAN
Victim-------+

If we do sth. like RPF before entering conntrack, the packets in the
other direction won't be in.

-- 
Regards，
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add seperated timeout for the connections that only receive packets in one direction

[Patrick McHardy]

Changli Gao wrote:
> On Fri, Nov 27, 2009 at 7:47 PM, Patrick McHardy <kaber@trash.net> wrote:
>> They don't need to forward anything, conntrack handles the packet before
>> routing.
>>
> 
> Think about this topologic:
> 
> Attacker -> router1 -> router2 -> ... -> Linux Router -> Apache.
> 
> the packets in the other direction won't be sent to the Linux Router,
> as the other routers will routed them to the other place.

Yes, in that case it could help.

> Case 2:
> 
> Attacker ---+
>                 +-- Linux Router --> WAN
> Victim-------+
> 
> If we do sth. like RPF before entering conntrack, the packets in the
> other direction won't be in.

RPF doesn't help since its also done after conntrack.

Re: Add seperated timeout for the connections that only receive packets in one direction

[Changli Gao]

On Mon, Nov 30, 2009 at 7:10 PM, Patrick McHardy <kaber@trash.net> wrote:
> Changli Gao wrote:
>> Case 2:
>>
>> Attacker ---+
>>                 +-- Linux Router --> WAN
>> Victim-------+
>>
>> If we do sth. like RPF before entering conntrack, the packets in the
>> other direction won't be in.
>
> RPF doesn't help since its also done after conntrack.
>

I didn't mean RPF. I meaned some other thing like RPF before conntrack.

-- 
Regards，
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add seperated timeout for the connections that only receive packets in one direction

[Jozsef Kadlecsik]

On Mon, 30 Nov 2009, Changli Gao wrote:

> Think about this topologic:
> 
> Attacker -> router1 -> router2 -> ... -> Linux Router -> Apache.
> 
> the packets in the other direction won't be sent to the Linux Router,
> as the other routers will routed them to the other place.

Sorry, I don't get it. 

If the attacker forges the source IP of the packet so that Apache thinks 
it's a local machine from its own point of view and answers it on the LAN, 
then that's the fault of the Linux Router operator: ingress and egress 
filtering is a must, period.

If the attacker forges the source IP of the packet otherwise so that 
Apache thinks it's a non local machine, then Apache will send the answer 
via the Linux Router regardless of the routing table of any router out 
there.
 
> Case 2:
> 
> Attacker ---+
>                 +-- Linux Router --> WAN
> Victim-------+
> 
> If we do sth. like RPF before entering conntrack, the packets in the
> other direction won't be in.

Here again I don't understand it completely: if there's an attacker on the 
LAN, then the point is not to mitigate the load for the Linux Router but 
first to find the attacker and then to prevent source IP forging.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Add seperated timeout for the connections that only receive packets in one direction

[Changli Gao]

On Tue, Dec 1, 2009 at 5:14 PM, Jozsef Kadlecsik
<kadlec@blackhole.kfki.hu> wrote:
> On Mon, 30 Nov 2009, Changli Gao wrote:
>
>> Think about this topologic:
>>
>> Attacker -> router1 -> router2 -> ... -> Linux Router -> Apache.
>>
>> the packets in the other direction won't be sent to the Linux Router,
>> as the other routers will routed them to the other place.
>
> Sorry, I don't get it.

There is a assumption: the final receiver doesn't reply any packet for
this packet in the invalid state.

-- 
Regards，
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Add seperated timeout for the connections that only receive packets in one direction

[Jozsef Kadlecsik]

On Tue, 1 Dec 2009, Changli Gao wrote:

> On Tue, Dec 1, 2009 at 5:14 PM, Jozsef Kadlecsik
> <kadlec@blackhole.kfki.hu> wrote:
> > On Mon, 30 Nov 2009, Changli Gao wrote:
> >
> >> Think about this topologic:
> >>
> >> Attacker -> router1 -> router2 -> ... -> Linux Router -> Apache.
> >>
> >> the packets in the other direction won't be sent to the Linux Router,
> >> as the other routers will routed them to the other place.
> >
> > Sorry, I don't get it.
> 
> There is a assumption: the final receiver doesn't reply any packet for
> this packet in the invalid state.

Who's assumption? Mine? Yours? For which case did you answer this?

Please describe a complete example, not bits here and there and leaving 
out conditions.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary