On Tue, Mar 20, 2018 at 12:43:33PM +0100, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > The example rule in the iptables-extensions(8) manpage suggests: > > > > iptables -A INPUT -i eth0 -p tcp --dport 80 > > -m state --state UNTRACKED,INVALID -j SYNPROXY > > --sack-perm --timestamp --mss 1460 --wscale 9 > > > > This is allowing invalid PSH,ACK packets to enter the SYNPROXY target > > since they are matching the INVALID state. > > Why INVALID? Shouldn't we already have a valid conntrack entry at this point? > > > This results in the following sequence: > > client synproxy server > > | | | > > | | | > > ... 3-way handshake via synproxy ... > > | | | > > |-------------------->| | > > | psh,ack |------------------>| > > | | syn | uh, why syn? I'm > > | | | already established?! > > | |<------------------| > > |<--------------------| rst | > > | rst | | > > > > Problem is that the psh,ack packet is handled by SYNPROXY as it would be > > the ACK packet (the third step in the handshake), hence SYNPROXY sends > > it as as SYN packet to the server. The server is not happy, since the > > handshake already happened time ago, so it sends the RST packet and > > connection is teared down immediately. > > I don't understand why push,ack is invalid in first place. > If we do not have a valid connection at this point then a pure > ack would have same effect (reset), no? Under normal circunstances yes, but anyone could cycle and forged PSH,ACK packets to the synproxy that are invalid, right? That would open up for a DOS against SYNPROXY itself... As you said, this can be worst, a simple invalid ACK packet would result in a SYN packet to the server for an already established connection. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
