Hi all, 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. 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. 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. Anyone? Thanks, /Eirik
Eirik, good day. Sun, Nov 23, 2008 at 05:03:15PM +0100, 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. > > 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.First of all, (if I am correct) your firewall's setting for drop_synfin isn't relevant for the packets that are traversing the firewall: TCP input layer drops these and firewall isn't using this layer. The easy way to identify if there are replies to SYN+FIN is to spawn tcpdump on the firewall and see what's going on. It may be well so that the some sort of scrubbing/modulation is done on the firewall, so when firewall notices that the SYN + FIN is blackholed, it generates RST by itself or just blocks SYN + FIN by itself, but sends RST. I am making guesses here, because I can't test it just now and I have no idea about your setup. If I remember correctly, pf is used on the pfSense, so you can easily block SYN + FIN on the ingress port(s): ----- block in quick on $ingress proto tcp from any to <protected_hosts> \ flags SF/ASF ----- -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20081123/f3e16021/attachment.pgp
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.> 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. G'luck, Pieter
Eirik ?verby <ltning@anduin.net> writes:> 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. > > 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.I added drop_synfin for one reason and one reason only: it prevented nmap from reliably identifying a FreeBSD machine, and at the time, that was sufficient to ward off the kind of script kiddies that would regularly attack EFNet IRC servers. I don't think SYN+FIN packets were ever a security issue, and I'm surprised Nessus thinks they are. Perhaps someone read about drop_synfin and misunderstood its purpose? Back to the issue at hand: you should use tcpdump to double-check nessus's findings. Who knows, perhaps drop_synfin was broken in a network stack reorganization. DES -- Dag-Erling Sm?rgrav - des@des.no
On Nov 23 17:03:15, 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.Aparently, nessus thinks that replying to SYNFIN packets at all is a problem. But it thinks so because you configured it to thinks so, right? Or is this hardwired into nessus? Also, why would nessus sometimes think that it's a "high" severity problem, and at other times, it's a "medium" 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.It you configured your firewall and servers to NOT reply to SYNFIN packets, and the still do, then this is a configuration issue itself. How you also checked with other tools to find whether your servers reply to SYNFIN, or do you trust nessus who says so? Jan