OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: ipfw log entry
From: Bart van Leeuwen (bartixori.demon.nl)
Date: Fri Jun 16 2000 - 14:36:38 CDT

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 <vdrifterocis.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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message