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 for Android: free password hash cracker in your pocket

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

Message-ID: <4ED9E5FA.30204@msgid.tls.msk.ru>
Date:	Sat, 03 Dec 2011 13:03:54 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Denys Fedoryshchenko <denys@...p.net.lb>, netdev@...r.kernel.org
Subject: Re: SYN attack, with FIN flag set

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