Dropping syn+fin replies, but not really?

[Eirik Øverby]

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.

Agreed.


>> 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> anduin.net
where <port> was either 80 (open) or 8585 (closed).

tcpdump command on firewall (which NATs to internal IPs):
tcpdump -i <interface> -p -vvv host alge.anart.no 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) alge.anart.no.40283 > 213.225.74.230.http: 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) 213.225.74.230.http > alge.anart.no.40283: 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) alge.anart.no.40283 > 213.225.74.230.http: ., 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) alge.anart.no.40283 > 213.225.74.230.http: 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) alge.anart.no.1839 > 213.225.74.230.8585: 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) 213.225.74.230.8585 > alge.anart.no.1839: 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.

Thanks,
/Eirik