|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: Firewall-1 Logging *Issue*
Subject: Re: Firewall-1 Logging *Issue*
From: Blue Boar (BlueBoar
THIEVCO.COM)
Date: Thu Jan 13 2000 - 23:23:13 CST
- Next message: jason storm: "Re: Administrivia #4883 (fwd)"
- Previous message: Blue Boar: "[Fwd: Administrivia #4883]"
- In reply to: Mike Frantzen: "Firewall-1 Logging *Issue*"
- Reply: Blue Boar: "Re: Firewall-1 Logging *Issue*"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Mike Frantzen wrote:
> While dinking with an eval version of Firewall-1 4.0 last summer,
> I ran across an 'oddity' in the logging.
<snip>
> Now while watching the logs grow (really really fast), I saw that the
> source IP was being diddled on. For a few seconds of traffic, the source
> IP was losing the high bit. Ie, a 132.3.2.1 would become a 4.3.2.1.
> The next few thousand packets would also have the wrong source IP. After
> a few seconds and a few thousand packets, the source IP would be reported
> correctly in the log viewer. Waiting awhile longer and it would drop the
> MSB again. Rinse, lather, and repeat.
I had something really similar happen on a production FW-1 4.0 SP4 running
on a Nokia 650. I was getting packets with a source of 223.255.255.223,
destination of 222.255.255.222 (or vice-versa, can't recall.) They were
just shy of the IP multicast range (class D.)
These were UDP packets, source and destination ports of 135. Obviously,
these were screwed-up NetBIOS broadcast packets that found their way
to my firewall because of the apparent destination address. In my case,
I don't think it was a logging problem, at least not entirely. (Spotted
them in the log originally.)
I could see them coming in fairly regularly via tcpdump, which
negates somewhat the screwed logging theory in my case. I also
caught a few via debug ip packet on the inside Cisco router,
but much fewer than I should have (compared to the number that
hit tcpdump.)
Had they gotten their bits twiddled on the wire somewhere, the
checksum should have killed them at any router. So, I assumed
they got mangled in memory on the original sending host, and
got a proper checksum for the mangling.
So, one question I'd have for your case is: Are you sure they got onto
the wire intact? Did you have another mechanism to compare them
on the wire vs. in the log?
BB
- Next message: jason storm: "Re: Administrivia #4883 (fwd)"
- Previous message: Blue Boar: "[Fwd: Administrivia #4883]"
- In reply to: Mike Frantzen: "Firewall-1 Logging *Issue*"
- Reply: Blue Boar: "Re: Firewall-1 Logging *Issue*"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This archive was generated by hypermail 2b27 : Thu Jan 13 2000 - 23:35:44 CST