SYN attack, with FIN flag set

SYN attack, with FIN flag set

[Denys Fedoryshchenko]

 Hi

 Recently i started to get SYN attacks, and managed them.
 syncookies didn't helped, here is "perf report" info:
 -     26.89%        swapper  [kernel.kallsyms]     [k] _raw_spin_lock
    - _raw_spin_lock
       - 94.97% tcp_v4_rcv
            ip_local_deliver_finish
            ip_local_deliver
            ip_rcv_finish
            ip_rcv
            __netif_receive_skb
            process_backlog
            net_rx_action
            __do_softirq
            call_softirq
            do_softirq
          + irq_exit

 But then i got attack that made server to choke and bypassed "--syn" 
 rule, and i was surprised, that stack are handling invalid combination 
 of flags, SYN+FIN.
 Is it valid behaviour?

 in tcp_input.c, tcp_rcv_state_process(), it just does check for rst (to 
 discard), but maybe packet with fin set should be discarded too?

 From http://www.whitehats.ca/main/members/Seeker/seeker_tcp_header/

 SYN FIN is probably the best known illegal combination. Remember that 
 SYN is used to start a connection, while FIN is used to end an existing 
 connection. It is nonsensical to perform both actions at the same time. 
 Many scanning tools use SYN FIN packets, because many intrusion 
 detection systems did not catch these in the past, although most do so 
 now. You can safely assume that any SYN FIN packets you see are 
 malicious.

 ---
 System administrator
 Denys Fedoryshchenko
 Virtual ISP S.A.L.

Re: SYN attack, with FIN flag set

[Eric Dumazet]

Le samedi 03 décembre 2011 à 00:29 +0200, Denys Fedoryshchenko a écrit :
> Hi
> 
>  Recently i started to get SYN attacks, and managed them.
>  syncookies didn't helped, here is "perf report" info:
>  -     26.89%        swapper  [kernel.kallsyms]     [k] _raw_spin_lock
>     - _raw_spin_lock
>        - 94.97% tcp_v4_rcv
>             ip_local_deliver_finish
>             ip_local_deliver
>             ip_rcv_finish
>             ip_rcv
>             __netif_receive_skb
>             process_backlog
>             net_rx_action
>             __do_softirq
>             call_softirq
>             do_softirq
>           + irq_exit
> 
>  But then i got attack that made server to choke and bypassed "--syn" 
>  rule, and i was surprised, that stack are handling invalid combination 
>  of flags, SYN+FIN.
>  Is it valid behaviour?
> 
>  in tcp_input.c, tcp_rcv_state_process(), it just does check for rst (to 
>  discard), but maybe packet with fin set should be discarded too?

I believe netfilter tcp conntrack considers SYN|FIN as INVALID

Yes, we could drop SYN|FIN messages, but what prevents attacker to just
use SYN messages to attack your machine ?

Re: SYN attack, with FIN flag set

[Eric Dumazet]

Le samedi 03 décembre 2011 à 08:27 +0100, Eric Dumazet a écrit :

> I believe netfilter tcp conntrack considers SYN|FIN as INVALID
> 

Or if you cannot afford conntracking, just do

iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

Re: SYN attack, with FIN flag set

[Denys Fedoryshchenko]

 On Sat, 03 Dec 2011 08:55:02 +0100, Eric Dumazet wrote:
> Le samedi 03 décembre 2011 à 08:27 +0100, Eric Dumazet a écrit :
>
>> I believe netfilter tcp conntrack considers SYN|FIN as INVALID
>>
>
> Or if you cannot afford conntracking, just do
>
> iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

 Sure i did,thanks, but i just was curious, why connection with such 
 flags are threated as SYN.

 ---
 System administrator
 Denys Fedoryshchenko
 Virtual ISP S.A.L.

Re: SYN attack, with FIN flag set

[Eric Dumazet]

Le samedi 03 décembre 2011 à 10:18 +0200, Denys Fedoryshchenko a écrit :
> On Sat, 03 Dec 2011 08:55:02 +0100, Eric Dumazet wrote:
> > Le samedi 03 décembre 2011 à 08:27 +0100, Eric Dumazet a écrit :
> >
> >> I believe netfilter tcp conntrack considers SYN|FIN as INVALID
> >>
> >
> > Or if you cannot afford conntracking, just do
> >
> > iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
> 
>  Sure i did,thanks, but i just was curious, why connection with such 
>  flags are threated as SYN.
> 

TCP stack first tries to lookup a socket, given the tuple found in
incoming packet.

This is where your machine is hit : we find the listener socket and lock
it.

Then, once socket was found and locked, state machine handle various
possible states.

In your case, you want to bypass the lookup, and eventually bypass the
IP route lookup as well (to keep IP route cache small)

iptables -t raw -I PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

Re: SYN attack, with FIN flag set

[Michael Tokarev]

On 03.12.2011 12:53, Eric Dumazet wrote:
[]
> TCP stack first tries to lookup a socket, given the tuple found in
> incoming packet.
> 
> This is where your machine is hit : we find the listener socket and lock
> it.
> 
> Then, once socket was found and locked, state machine handle various
> possible states.
> 
> In your case, you want to bypass the lookup, and eventually bypass the
> IP route lookup as well (to keep IP route cache small)
> 
> iptables -t raw -I PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

Maybe it makes some sence to add a basic "sanity" check rule
before the socket lookup?

The question here is why SYN+FIN results in worse behavour than
SYN alone - in the default setup, without iptables rules?  As
far as I understand, "regular" SYN attack is handled just fine,
but SYN+FIN attack makes the machine to "choke", and it is not
obvious how to fix it -- naive --syn iptables rule does not help.

The price for the sanity check appears to be small since there's
already a check for RST.

Just asking, not suggesting anything... ;)

Thanks,

/mjt

Re: SYN attack, with FIN flag set

[Denys Fedoryshchenko]

 On Sat, 03 Dec 2011 13:03:54 +0400, Michael Tokarev wrote:
> On 03.12.2011 12:53, Eric Dumazet wrote:
> []
>> TCP stack first tries to lookup a socket, given the tuple found in
>> incoming packet.
>>
>> This is where your machine is hit : we find the listener socket and 
>> lock
>> it.
>>
>> Then, once socket was found and locked, state machine handle various
>> possible states.
>>
>> In your case, you want to bypass the lookup, and eventually bypass 
>> the
>> IP route lookup as well (to keep IP route cache small)
>>
>> iptables -t raw -I PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j 
>> DROP
>
> Maybe it makes some sence to add a basic "sanity" check rule
> before the socket lookup?
>
> The question here is why SYN+FIN results in worse behavour than
> SYN alone - in the default setup, without iptables rules?  As
> far as I understand, "regular" SYN attack is handled just fine,
> but SYN+FIN attack makes the machine to "choke", and it is not
> obvious how to fix it -- naive --syn iptables rule does not help.
>
> The price for the sanity check appears to be small since there's
> already a check for RST.
>
> Just asking, not suggesting anything... ;)
>
> Thanks,
>
> /mjt
 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?

 ---
 System administrator
 Denys Fedoryshchenko
 Virtual ISP S.A.L.

Re: SYN attack, with FIN flag set

[Eric Dumazet]

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;
 

Re: SYN attack, with FIN flag set

[Eric Dumazet]

Le samedi 03 décembre 2011 à 10:41 +0100, Eric Dumazet a écrit :
> [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
> 

Oh well this should be :

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

Re: SYN attack, with FIN flag set

[Denys Fedoryshchenko]

 On Sat, 03 Dec 2011 11:02:02 +0100, Eric Dumazet wrote:
> Le samedi 03 décembre 2011 à 10:41 +0100, Eric Dumazet a écrit :
>> [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
>>
>
> Oh well this should be :
>
> Dont call conn_request() if the TCP flags includes FIN flag

 Thats what i meant, maybe this will not slow down things (there is 
 other conditions already available, such as rst, just one more), but 
 will be somehow helpful for network administrators, since such attack 
 are bypassing --syn iptables flag. I hope it doesn't break anything.


 ---
 System administrator
 Denys Fedoryshchenko
 Virtual ISP S.A.L.

Re: SYN attack, with FIN flag set

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 03 Dec 2011 10:41:42 +0100

> [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>

Ok, I've applied this to net-next.