as we are working to get our solution ICSA certified, they found a behavior that the linux kernel has what they claim to not fullfill their requirements.
They found that we accept PSH packets without first receiving a TCP handshake. Actually we see this not as a faulty behavior, but a feature called 'TCP connection state pickup'. This feature is needed in case of an reboot or an High Availability Firewall Take-Over, to not to loose the existing established connection and therefore prevent a reestablishment of all connections.
We don’t see this as a security hole, because the TCP packet still goes throught the complete packetfilter, and only if that packets gets allowed by the packetfilter ruleset (which implies that the client can also establish a new connection with the current ruleset in the same direction) it gets passed onto the other side. We also monitor the TCP state of those packets inside the kernel, which means: If a packet is send through the firewall in the meanor described above and this packet has no matching connection state entry inside the connection tracking table. We assign this connection temporarily the state 'new connection'. If the receipient of the packet anwseres with a valid response (which means he was expecting this packet) we see this as the wanted behavior and pick up the TCP state by setting it to 'established', if not we drop that connection.
As this is not enough for the ICSA, we added the 'Strict TCP session handling', with this enabled you can only establish connections with a SYN packet and a valid TCP 3-way handshake.
i hope this helps to understand what this feature does.
as we are working to get our solution ICSA certified, they found a behavior that the linux kernel has what they claim to not fullfill their requirements.
They found that we accept PSH packets without first receiving a TCP handshake. Actually we see this not as a faulty behavior, but a feature called 'TCP connection state pickup'. This feature is needed in case of an reboot or an High Availability Firewall Take-Over, to not to loose the existing established connection and therefore prevent a reestablishment of all connections.
We don’t see this as a security hole, because the TCP packet still goes throught the complete packetfilter, and only if that packets gets allowed by the packetfilter ruleset (which implies that the client can also establish a new connection with the current ruleset in the same direction) it gets passed onto the other side. We also monitor the TCP state of those packets inside the kernel, which means: If a packet is send through the firewall in the meanor described above and this packet has no matching connection state entry inside the connection tracking table. We assign this connection temporarily the state 'new connection'. If the receipient of the packet anwseres with a valid response (which means he was expecting this packet) we see this as the wanted behavior and pick up the TCP state by setting it to 'established', if not we drop that connection.
As this is not enough for the ICSA, we added the 'Strict TCP session handling', with this enabled you can only establish connections with a SYN packet and a valid TCP 3-way handshake.
i hope this helps to understand what this feature does.
if you use HA with the V5 as it is now, yes, as all connections need to reconnect on order to work, once our new connection trackin synchronizateion is included (soon), it will work perfectly.
