From owner-freebsd-security Fri Jun 16 6: 4:24 2000 Delivered-To: freebsd-security@freebsd.org Received: from europe.std.com (europe.std.com [199.172.62.20]) by hub.freebsd.org (Postfix) with ESMTP id 0A20237BE82 for ; Fri, 16 Jun 2000 06:04:11 -0700 (PDT) (envelope-from lowell@world.std.com) Received: from world.std.com (lowell@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id JAA20081; Fri, 16 Jun 2000 09:04:02 -0400 (EDT) Received: (from lowell@localhost) by world.std.com (8.9.3/8.9.3) id JAA26406; Fri, 16 Jun 2000 09:04:02 -0400 (EDT) To: John F Cuzzola , freebsd-security@freebsd.org Subject: Re: ipfw log entry References: From: Lowell Gilbert Date: 16 Jun 2000 09:04:01 -0400 In-Reply-To: John F Cuzzola's message of Tue, 13 Jun 2000 16:25:04 -0700 (PDT) Message-ID: Lines: 41 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Well, no one else has spoken up, so I'm taking a shot at it. John F Cuzzola writes: > Hi everyone, > On one of our firewalls numerous entries looking like this were logged: > > ipfw: -1 Refuse TCP 209.1.224.16 107.13.119.32 in via ep3 Fragment = 147 > > > I haven't seen this one before. Is this a packet that FreeBSD explicitly > blocks regardless of the firewall rules and if so what is its > intent/purpose? (Basically what I'm asking is does this look like hacker > activity). Without looking at the code, it's hard to say what's happening here. ipfw_report() is getting called with no rule associated. The only case the documentation mentions that might be related is the "always discard" situation of a frag with an offset of one. This packet, though, has a fragment of 147 (slightly larger than the required minimum packet size that any IP device has to be able to handle), so nothing being reported sounds illegitimate. If I had to hazard a guess, I'd say this sounds like a bug in how the reporting routine gets called from somewhere. The only place this could get called from without the associated rule is the bogusfrag label in ip_fw.c. Aside from fragment offsets of one, there's a PULLUP_TO() macro that jumps there. I don't really know BSD mbufs that well, but it looks like the situation being detected is a frame shorter than the IP length. If I'm right, this is very unlikely to be hacker activity. In fact, the situation being detected has to originate on your local wire. I may be wrong, though, because I thought that kind of error should get picked up as an input error on the interface. If we're lucky, Luigi will speak up to tell us whether I'm completely insane. Be well. Lowell Gilbert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message