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.

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_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: LISTENING, ESTABLISHED, CLOSE_WAIT TCP Ports & UDP Ports?
    ... properties of a process and it will show you what tcp/ip ports and services ... Beyond that I suggest you read the Windows 2003 Server Security Guide to see ...
    (microsoft.public.windows.server.security)
  • Re: DNSReport w/ Hosting Your Own DNS
    ... Thing is, I'm aware of the risks, monitor the server daily, patch as soon as ... I wouldn't dream of attempting to run public DNS. ... While it is permissible on an SBS server to host a website directly ... I've seen that point of ports being open a risk a lot with hardly a reason ...
    (microsoft.public.windows.server.sbs)
  • Re: Source Code to Filter out WindowsMessenger POP-UPS
    ... > time to get the details I did get about the ports and none ... It does not act as a relay server - at least ... To that I will just add that REAL security - ... > port 80 inbound ...
    (microsoft.public.inetserver.iis.security)
  • Re: escalating IUSR to admin rights via unicode and iis4
    ... 6- Try a command line net scan that can be uploaded to the web server ... any TCP/IP connections from your host through a middle host to ... This list is provided by the SecurityFocus Security Intelligence Alert ... For more information on SecurityFocus' SIA service which ...
    (Pen-Test)
  • Re: Blocking/responding to port scans
    ... If someone is scanning my ports, it's pretty certain that they're up ... security that other hosts are more attractive targets than your host. ... Might we be better off running Multics? ...
    (comp.os.linux.security)