net.inet.tcp.drop_synfin=1 no longer works on FreeBSD 10+ How-To-Repeat: Run this scan on identically configured FreeBSD 9 and FreeBSD 10 servers nmap -v -v --scanflags SYNFIN -P0 <target> FreeBSD 9 servers will report "filtered" which is correct. FreeBSD 10 servers will report "open", which means it is vulnerable to this attack to bypass the firewall. The firewall in use on these machines is pf. It is possible to block SYN/FIN on pf as well, but our standard deployment is the sysctl method.
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
I assume that your pf(4) is enabled during these tests, you have "scrub" statements in the ruleset and removing "scrub" will restore the expected behaviour on 10.x? I am slightly amused that on 9.x with "scrub" you're getting the expected behaviour, because clearing FIN bit for SYN packets was the standard behaviour of pf since approximately at least 10 years, http://svnweb.freebsd.org/base/vendor-sys/pf/dist/sys/contrib/pf/net/pf_norm.c?view=markup&pathrev=126258#l1242 Can you show relevant parts of the pf.conf from both machines and output from 'pfctl -s rules' if you are sure that both machines are configured identically pf-wise? Thanks! -- Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
On Wed, May 28, 2014 at 10:46 PM, Eygene Ryabinkin <rea@freebsd.org> wrote: > I assume that your pf(4) is enabled during these tests, you have > "scrub" statements in the ruleset and removing "scrub" will restore > the expected behaviour on 10.x? I can confirm that I see exactly what you are saying on a stable/10 box. cheers, Hiren
Wed, May 28, 2014 at 11:52:51PM -0700, hiren panchasara wrote: > On Wed, May 28, 2014 at 10:46 PM, Eygene Ryabinkin <rea@freebsd.org> wrote: > > I assume that your pf(4) is enabled during these tests, you have > > "scrub" statements in the ruleset and removing "scrub" will restore > > the expected behaviour on 10.x? > > I can confirm that I see exactly what you are saying on a stable/10 box. I had found 2 flavors of 9.x boxen: 9.1/9.2 that behave like 10.x and some 9.0 that are dropping SYN|FIN even in the presence of "scrub". The trouble is that the latter boxes are in full production, so I need some time to try to reproduce that on the text box. -- Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
The test box in particular is using pf and does not have any scrub statements in pf.conf. The dropping of SYN+FIN worked for us in 9.1 and older just by setting net.inet.tcp.drop_synfin=1. We skipped 9.2 for the most part, so I don't have any experience with its behavior in production.
Closing this. There was an off-list discussion where some sensitive information was exchanged to further evaluate this situation. After some testing mistakes on both ends were resolved we concluded that the behavior is correct and manual attempts to invoke this bug were unsuccessful. It seems the remote scanning service we were using was possibly triggering a bug of its own.