Date: Sat, 17 Jun 2000 05:14:07 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> 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.3.96.1000617040953.11108C-100000@gaia.nimnet.asn.au> 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. As I mentioned to John, this host is res6.geocities.com. We see these here usually in big batches, perhaps about once a month on average, eg: May 22 18:14:39 gaia /kernel: ipfw: 65000 Count TCP 209.1.224.16 203.41.52.xxx in via tun0 Fragment = 147 Rule 65000 is 'count log tcp from any to any in', one of some counts by protocol before being silently denied by 65535, deny ip from any to any. 65000 usually only logs non-established, non-setup TCP packets. I'm not sure whether all traffic from that site suffers this fate or just chunks of it. Note, no TCP port numbers were specified, or logged at any rate. [.. speculation on likely causes in the ipfw code blissfully ignored ..] > 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. Don't think it's any 'activity' either, more likely something broken at res6.geocities.com. Noticed another site occasionally w/fragment = 184. Haven't asked these (dialup) folks what wasn't working for them, as they seem also skilled at finding perhaps related sites, hoping to establish http connections with URLs from nets 10/8, 172.16/12 and 192.168/16 :-) > If we're lucky, Luigi will speak up to tell us whether I'm completely > insane. That would be comforting I'm sure :-) Cheers, Ian 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.3.96.1000617040953.11108C-100000>