Re: Dropping syn+fin replies, but not really?

On Nov 23, 2008, at 18:52, Pieter de Boer wrote:

Eirik Øverby wrote:

I have a FreeBSD based firewall (pfsense) and, behind it, a few dozen FreeBSD servers. Now we're required to run external security scans (nessus++) on some of the hosts, and they constantly come back with a "high" or "medium" severity problem: The host replies to TCP packets with SYN+FIN set.
I'd consider this at most a 'low' severity problem.


Problem: Both the firewall (FreeBSD 6.2-based pfSense 1.2) and the host in question (recent FreeBSD 7.2-PRERELEASE) have net.inet.tcp.drop_synfin=1 - I would therefore expect this to be a non-issue.
Given security tools' (including Nessus') track records of false
positives, I wouldn't be surprised if this was one of them.

They generate a lot of others, too, mostly due to insufficient or downright bogus identification of services. Since when did "pound ssl proxy" equal "aladdin web server"? And since when was it common to run Apache 2.0.23 for Linux on FreeBSD 7.0? Not to mention all the windows- specific vulnerabilities I'm supposedly open to.

Have I missed something important? Apart from this the hosts and services get away without any serious issues, but the security audit company insists this so-called hole to be closed.
It's not a hole, but could possibly aid in bypassing filtering rules
(which is quite unlikely in this day and age). It may be wise to find a
security company that knows how to interpret and verify Nessus output.

If you want to do verification yourself, you could try the following:
- Run tcpdump on one of the servers and on the firewall
- Run nmap from an external host using the '--scanflags SYNFIN' flag
with destination the server.

You can let tcpdump only show specific ports and source/destination
addresses. It's probably useful to use nmap to scan both ports you know
to be open and in use and ports that are filtered. Using the -p option
to nmap, you can specify which ports to scan.

Perform the nmap scan and look at the tcpdump output to see how your
firewall and/or server react.

nmap command:
nmap -PN -sT --scanflags SYNFIN -p<port>
where <port> was either 80 (open) or 8585 (closed).

tcpdump command on firewall (which NATs to internal IPs):
tcpdump -i <interface> -p -vvv host and \(port 80 or port 8585\)
where <interface> was the publicly facing interface on the firewall.

Results for port 80:
IP (tos 0x0, ttl 59, id 12785, offset 0, flags [DF], proto: TCP (6), length: 64) > S, cksum 0xa720 (correct), 3300467486:3300467486(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 2747936488 0>
IP (tos 0x0, ttl 63, id 10914, offset 0, flags [DF], proto: TCP (6), length: 60) > S, cksum 0x8ef5 (correct), 347647336:347647336(0) ack 3300467487 win 65535 <mss 1460,nop,wscale 3,sackOK,timestamp 2946365534 2747936488>
IP (tos 0x0, ttl 59, id 33877, offset 0, flags [DF], proto: TCP (6), length: 52) > ., cksum 0x7dbd (correct), 1:1(0) ack 1 win 16384 <nop,nop,timestamp 2747936488 2946365534>
IP (tos 0x0, ttl 59, id 31905, offset 0, flags [DF], proto: TCP (6), length: 40) > R, cksum 0x7180 (correct), 1:1(0) ack 1 win 0

Results for port 8585:
IP (tos 0x0, ttl 59, id 44156, offset 0, flags [DF], proto: TCP (6), length: 64) > S, cksum 0xf765 (correct), 1324215952:1324215952(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 4070158112 0>
IP (tos 0x0, ttl 63, id 34488, offset 0, flags [DF], proto: TCP (6), length: 40) > R, cksum 0x52ef (correct), 0:0(0) ack 1324215953 win 0

I can't tell what's going on here, except I wouldn't have expected a reply at all to the second one at least, and maybe not even the first. However, I don't have enough experience to tell if nmap is doing the "right thing" here at all.

freebsd-security@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"