From owner-freebsd-net@FreeBSD.ORG Thu Jun 14 10:35:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BED2106566B for ; Thu, 14 Jun 2012 10:35:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CCB698FC0C for ; Thu, 14 Jun 2012 10:35:50 +0000 (UTC) Received: (qmail 76817 invoked from network); 14 Jun 2012 12:32:53 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Jun 2012 12:32:53 -0000 Message-ID: <4FD9BE80.1030203@freebsd.org> Date: Thu, 14 Jun 2012 12:35:44 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nikolay Denev References: <54EF0399-B36E-42CA-9526-DDC7ADA4406A@gmail.com> <4FD8937C.3020005@freebsd.org> In-Reply-To: <4FD8937C.3020005@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , freebsd-gnats-submit@freebsd.org Subject: Re: kern/168842: FreeBSD 8.2-STABLE sending FIN no ACK packets. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 10:35:51 -0000 On 13.06.2012 15:19, Andre Oppermann wrote: > On 08.06.2012 14:43, Nikolay Denev wrote: >> >> On Jun 8, 2012, at 4:30 AM, Adrian Chadd wrote: >> >>> On 7 June 2012 05:41, Nikolay Denev wrote: >>>> Hello, >>>> >>>> I've been pointed out by our partner that we are sending TCP packets with FIN flag and no ACK >>>> set, which is triggering >>>> alerts on their firewalls. >>>> I've investigated, and it appears that some of our FreeBSD hosts are really sending such >>>> packets. (they are running some java applications) >>>> I did "tcpdump -s0 -vni em1 '(tcp[tcpflags]& tcp-ack == 0)&& (tcp[tcpflags]& tcp-fin != 0)'" to >>>> catch them. >>>> >>>> Is this considered normal? >>>> It seems at least Juniper considers this malicious traffic : >>>> http://www.juniper.net/techpubs/software/junos-security/junos-security10.0/junos-security-swconfig-security/id-72577.html >>>> >>> >>> Would you please file a PR with this, so it doesn't get lost? >>> >>> Thanks, >>> >>> >>> Adrian >> >> Filed as kern/168842, and mistakenly duplicated as kern/168843 (the latter can be closed). >> >> As I wrote in the PR, I have a PCAP that I can privately share if someone is interested. > > Hi Nikolay > > please make the pcap available to me. From the tcpdump in the PR I can't > analyze how this stray packet may come about. OK, thanks for the pcap file which I've analyzed now. > While certainly a bug it is not a security issue as any compliant tcp stack > would drop such a packet on receipt. The stray FIN happens on timeout of unsuccessful connection attempts (SYN_SENT). There are a number of bugs for that case I've identified so far: 1. there is bug in the SYN_SENT inpcb teardown case that causes the wrong FIN to be sent. It may be a residual of T/TCP. 2. the SYN retransmit is broken by sending the first after 3s, and then four in succession at 3.2s, the fifth comes at 6.2s, at 8s the application times out. 3. after the third SYN retransmit we turn off the tcp options, except that SACK_PERM stays on. I'm working on fixes for each of these bugs. -- Andre