Re: SYN attack, with FIN flag set

[Eric Dumazet <eric.dumazet@gmail.com>]

Le samedi 03 décembre 2011 à 11:07 +0200, Denys Fedoryshchenko a écrit :
>  No,no, as i understand it is just threating SYN+FIN as plain SYN.
>  I think if it incurr additional expenses (verification), no need maybe 
>  to fix it, it is job of iptables.
>  But is FIN to listening socket - legitimate? Shouldn't it be dropped?
> 


Host network stack is optimized for the fast path (legitimate traffic)

Firewalls are optimized to the opposite, to let protected machines doing
their jobs without slow checks.

If we add all possible counter measures in tcp stack, it would be maybe
2 times slower than it is...

Remember than SYN|FIN messages are maybe 0.000001% of total Internet
trafic, since they are not legitimate.

In the case of SYN packet, flow is :

1) IP stack : ip_rcv(), ip_route_input_noref(), ip_rcv_finish()

2) TCP stack : 
	tcp_v4_rcv(),
	__inet_lookup_skb() [ find the listener socket ]
	bh_lock_sock_nested(sk) [ lock the socket ]
	tcp_v4_do_rcv()
	tcp_v4_hnd_req()
	inet_csk_search_req() [ try to find a previous SYN_RECV sock]
	tcp_rcv_state_process()
		tcp_v4_conn_request(sk, skb)

So it appears we go too far, we should drop FIN messages at this point.

What about following patch then ?

The added test is hit only for SYN messages, this seems not a very
expensive test.


[PATCH] tcp: drop SYN+FIN messages

Denys Fedoryshchenko reported that SYN+FIN attacks were bringing his
linux machines to their limits.

Dont call conn_request() if the TCP flags includes SYN flag

Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
 net/ipv4/tcp_input.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 52b5c2d..d54c942 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5809,6 +5809,8 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
 			goto discard;
 
 		if (th->syn) {
+			if (th->fin)
+				goto discard;
 			if (icsk->icsk_af_ops->conn_request(sk, skb) < 0)
 				return 1;