netdev - Re: SYN attack, with FIN flag set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <73da1a18b48dc3097acd6728be208c66@visp.net.lb>
Date:	Sat, 03 Dec 2011 11:07:10 +0200
From:	Denys Fedoryshchenko <denys@...p.net.lb>
To:	Michael Tokarev <mjt@....msk.ru>
Cc:	Eric Dumazet <eric.dumazet@...il.com>, <netdev@...r.kernel.org>
Subject: Re: SYN attack, with FIN flag set

 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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html