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