From owner-freebsd-security@FreeBSD.ORG Mon Nov 24 21:37:26 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC5A7106564A for ; Mon, 24 Nov 2008 21:37:26 +0000 (UTC) (envelope-from ltning@anduin.net) Received: from mail.anduin.net (mail.anduin.net [213.225.74.249]) by mx1.freebsd.org (Postfix) with ESMTP id 8011E8FC13 for ; Mon, 24 Nov 2008 21:37:26 +0000 (UTC) (envelope-from ltning@anduin.net) Received: from [212.62.248.146] (helo=[192.168.2.183]) by mail.anduin.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L4j7S-000KY4-As; Mon, 24 Nov 2008 22:37:22 +0100 Message-Id: <876D0973-A384-4567-8E61-771E96E8A65A@anduin.net> From: =?ISO-8859-1?Q?Eirik_=D8verby?= To: freebsd-security@freebsd.org In-Reply-To: <49299876.4020702@thelostparadise.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 24 Nov 2008 22:37:23 +0100 References: <49299876.4020702@thelostparadise.com> X-Mailer: Apple Mail (2.929.2) Cc: Pieter de Boer Subject: Re: Dropping syn+fin replies, but not really? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2008 21:37:26 -0000 On Nov 23, 2008, at 18:52, Pieter de Boer wrote: > Eirik =D8verby wrote: > >> I have a FreeBSD based firewall (pfsense) and, behind it, a few =20 >> dozen FreeBSD servers. Now we're required to run external security =20= >> scans (nessus++) on some of the hosts, and they constantly come =20 >> back with a "high" or "medium" severity problem: The host replies =20 >> 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 =20= >> host in question (recent FreeBSD 7.2-PRERELEASE) have =20 >> net.inet.tcp.drop_synfin=3D1 - I would therefore expect this to be a =20= >> 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 =20 downright bogus identification of services. Since when did "pound ssl =20= proxy" equal "aladdin web server"? And since when was it common to run =20= Apache 2.0.23 for Linux on FreeBSD 7.0? Not to mention all the windows-=20= specific vulnerabilities I'm supposedly open to. >> Have I missed something important? Apart from this the hosts and =20 >> services get away without any serious issues, but the security =20 >> 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 =20 > 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 =20 > 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 anduin.net where was either 80 (open) or 8585 (closed). tcpdump command on firewall (which NATs to internal IPs): tcpdump -i -p -vvv host alge.anart.no and \(port 80 or =20 port 8585\) where 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 =20 (6), length: 64) alge.anart.no.40283 > 213.225.74.230.http: S, cksum =20 0xa720 (correct), 3300467486:3300467486(0) win 16384 IP (tos 0x0, ttl 63, id 10914, offset 0, flags [DF], proto: TCP =20 (6), length: 60) 213.225.74.230.http > alge.anart.no.40283: S, cksum =20 0x8ef5 (correct), 347647336:347647336(0) ack 3300467487 win 65535 IP (tos 0x0, ttl 59, id 33877, offset 0, flags [DF], proto: TCP =20 (6), length: 52) alge.anart.no.40283 > 213.225.74.230.http: ., cksum =20 0x7dbd (correct), 1:1(0) ack 1 win 16384 IP (tos 0x0, ttl 59, id 31905, offset 0, flags [DF], proto: TCP =20 (6), length: 40) alge.anart.no.40283 > 213.225.74.230.http: R, cksum =20 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 =20 (6), length: 64) alge.anart.no.1839 > 213.225.74.230.8585: S, cksum =20 0xf765 (correct), 1324215952:1324215952(0) win 16384 IP (tos 0x0, ttl 63, id 34488, offset 0, flags [DF], proto: TCP =20 (6), length: 40) 213.225.74.230.8585 > alge.anart.no.1839: R, cksum =20 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 =20 reply at all to the second one at least, and maybe not even the first. =20= However, I don't have enough experience to tell if nmap is doing the =20 "right thing" here at all. Thanks, /Eirik=