Skip site navigation (1)Skip section navigation (2)
Date:      16 Jun 2000 09:04:01 -0400
From:      Lowell Gilbert <lowell@world.std.com>
To:        John F Cuzzola <vdrifter@ocis.ocis.net>, freebsd-security@freebsd.org
Subject:   Re: ipfw log entry
Message-ID:  <rd68zw5n5fi.fsf@world.std.com>
In-Reply-To: John F Cuzzola's message of Tue, 13 Jun 2000 16:25:04 -0700 (PDT)
References:  <Pine.LNX.4.21.0006131621210.22570-100000@ocis.ocis.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?rd68zw5n5fi.fsf>