Date: Thu, 14 Jun 2012 12:35:44 +0200 From: Andre Oppermann <andre@freebsd.org> To: Nikolay Denev <ndenev@gmail.com> Cc: freebsd-net <freebsd-net@freebsd.org>, freebsd-gnats-submit@freebsd.org Subject: Re: kern/168842: FreeBSD 8.2-STABLE sending FIN no ACK packets. Message-ID: <4FD9BE80.1030203@freebsd.org> In-Reply-To: <4FD8937C.3020005@freebsd.org> References: <54EF0399-B36E-42CA-9526-DDC7ADA4406A@gmail.com> <CAJ-Vmo=82Y-oD3gpNZQ_Q4UHWrRqk_Vs2QZqshGXv_E=LqY8-w@mail.gmail.com> <CBFAA2DA-D8D2-466E-83EC-D40505250270@gmail.com> <4FD8937C.3020005@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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<ndenev@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD9BE80.1030203>