Date: Fri, 16 Jun 2000 21:36:38 +0200 (CEST) From: Bart van Leeuwen <bart@ixori.demon.nl> To: Lowell Gilbert <lowell@world.std.com> Cc: John F Cuzzola <vdrifter@ocis.ocis.net>, freebsd-security@freebsd.org Subject: Re: ipfw log entry Message-ID: <Pine.BSF.4.21.0006162125430.29749-100000@isengard.ixori.demon.nl> In-Reply-To: <rd68zw5n5fi.fsf@world.std.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 Jun 2000, Lowell Gilbert wrote: > Well, no one else has spoken up, so I'm taking a shot at it. > > John F Cuzzola <vdrifter@ocis.ocis.net> 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. Well, I'm far from an expert on mbufs, but a quick peak at the code suggests that the other way to get such a log entry would be if allocating a mbuf fails in m_pullup. In that case I'd think its a tunning matter. I can imagine that this happens when receiving a lot of fragments before the packet can be reassembled or when the firewall machine gets a huge amount of packets to handle in general. If I remeber correctly man dummynet suggests that you might need more mbufs because of dummynet and using ipfw. > > If we're lucky, Luigi will speak up to tell us whether I'm completely > insane. Heh.. I won't comment on that ;-) tho... maybe Luigi can tell me if I'm insane as well.. have been wondering for years ;-) Bart. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0006162125430.29749-100000>