Vulnerability Development mailing list archives
Re: Firewall-1 Logging *Issue*
From: BlueBoar () THIEVCO COM (Blue Boar)
Date: Thu, 13 Jan 2000 21:23:13 -0800
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
Current thread:
- Administrivia #4883 Blue Boar (Jan 13)
- Re: Administrivia #4883 Marc (Jan 13)
- Re: Administrivia #4883 Travis Siegel (Jan 13)
- [Fwd: Administrivia #4883] Blue Boar (Jan 13)
- Firewall-1 Logging *Issue* Mike Frantzen (Jan 13)
- Re: Firewall-1 Logging *Issue* Blue Boar (Jan 13)
- Re: Administrivia #4883 nascheme () ENME UCALGARY CA (Jan 14)
- Secure coding in C (was Re: Administrivia #4883) Bennett Todd (Jan 14)
- Re: Secure coding in C (was Re: Administrivia #4883) Marco Walther (Jan 14)
- Re: Secure coding in C (was Re: Administrivia #4883) Bennett Todd (Jan 14)
- Re: Secure coding in C (was Re: Administrivia #4883) Liviu Daia (Jan 14)
- Re: Secure coding in C (was Re: Administrivia #4883) spin0ff (Jan 16)
- ICQ >= 99* + CC Data (Was: Re: Administrivia #4883) Ken Williams (Jan 16)
- Re: ICQ >= 99* + CC Data Vanja Hrustic (Jan 16)
- Re: Secure coding in C (was Re: Administrivia #4883) Liviu Daia (Jan 16)
- Re: Secure coding in C (was Re: Administrivia #4883) Valery Dachev (Jan 17)
- Secure coding in C (was Re: Administrivia #4883) Bennett Todd (Jan 14)
- Re: Administrivia #4883 Marc (Jan 13)