Re: TCP Connection tracking and SYN/ACK/PSH

[Tim Burress <tim@variosecure.net>]

Henrik Nordstrom wrote:

> Just a small note to support this: SYN+ACK+PSH is a perfectly valid 
> flags combination, even more so if there actually is data enclosed in 
> the SYN+ACK (which is valid, only a little odd).
>
> There is not really any good reason why conntrack should care in 
> detail about the PSH flag. Most if not all valid flag combinations are 
> good both with and without PSH (even SYN).

We recently had a similar issue, and initially I thought it was overly 
paranoid for Netfilter to mark these segments invalid, but after some 
digging I've changed my mind. The problem is that, even though there is 
no statement in the standards classifying SYN/ACK/PSH itself as invalid, 
the operation that PSH demands -- immediate transmission to the 
application -- is explicitly forbidden during the handshake [RFC 793, 
pg. 30]. In any other protocol, a request to perform a prohibited 
operation would, I think, be considered invalid, so in the end I think 
Netfilter is doing the right thing, inconvenient as it may be for a few 
devices.

In our case the device was a Panasonic WJ-NT104 interface/server for 
network cameras. Apparently there is an embedded TCP/IP stack making the 
rounds in Japan that sets the PSH flag on *every* segment. Panasonic's 
technical support have not yet replied to queries about the issue, but 
we're hoping they will issue a firmware upgrade to fix the problem. In 
the meantime, we modified our rules to allow INVALID traffic to/from the 
device. Obviously it's not ideal, but it gets the job done. If Panasonic 
is unable/unwilling to fix the TCP behavior, we would probably patch 
Netfilter to clear the PSH flag when it occurs in combination with SYN. 
That way we could accept the traffic without allowing invalid segments 
through to hosts on the other side.

Tim