Change the default value for drop_synfin to true. There is no reason to accept a packet with both the SYN and FIN flags set. Suggested by: hiren

[rwatson]

While the behaviour in handling SYN|FIN is undefined by the TCP specification, SYN|FIN probing is widely used in host-stack fingerprinting. It's not clear that fingerprintability is a bug -- and, in fact, it's sometimes relied on as a feature. Disabling responses here will break that feature. I'm not sure I would encourage this change.

[gnn]

Yes my proposed change would prevent fingerprinting. When would fingerprinting be considered a feature by those being fingerprinted?

[allanjude]

http://www.juniper.net/techpubs/software/junos-es/junos-es93/junos-es-swconfig-security/tcp-headers-with-syn-and-fin-flags-set.html

http://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=3041&signatureSubId=0

http://www.symantec.com/connect/articles/abnormal-ip-packets
SYN FIN is probably the best known illegal combination. Remember that SYN is used to start a connection, while FIN is used to end an existing connection. It is nonsensical to perform both actions at the same time. Many scanning tools use SYN FIN packets, because many intrusion detection systems did not catch these in the past, although most do so now. You can safely assume that any SYN FIN packets you see are malicious.

It seems pretty common to drop them, and it only affects active fingerprinting, not passive fingerprinting.

[rwatson]

To date, the view we've taken on fingerprinting is that it's nearly impossible actually to prevent fingerprinting as it's effectively a side channel. So, for example, we made a policy decision to continuing reporting not just the SSH protocol version but also FreeBSD version via sshd on port 22, etc, despite a few complaints from users. As such, my casual reading is that flipping this one flag will make little or no actual security difference.

[rwatson]

(which is all to say: I guess I don't really mind the change, but I'm not sure it really accomplishes much.)

[gnn]

For me this isn't so much about security, per se, as dropping packets we know to have no use earlier in the process of handling them. Why waste time on packets that have no discernible purpose or future utility? The SYN will just get stuck in the SYN cache and time out, wasting resources.

[hiren]

In D2267#14, @gnn wrote:

For me this isn't so much about security, per se, as dropping packets we know to have no use earlier in the process of handling them. Why waste time on packets that have no discernible purpose or future utility? The SYN will just get stuck in the SYN cache and time out, wasting resources.

Spec is not clear on this subject and there is really no use of such a packet. *And* it takes up space in syn cache.

I fail to understand why we want to keep it.