mailing list archives
RE: Appropriate PIX logging level
From: David Lang <dlang () digitalinsight com>
Date: Tue, 2 May 2006 12:34:55 -0700 (PDT)
On Tue, 2 May 2006, Paul Melson wrote:
I was actually just starting to look into this, I'm being blasted by
the messages from the pix when it rejects a broadcast packet (I'm
getting 43,000 log entries per day based on the firewalls rejecting
each server that's in a HA configuration and useing broadcast udp
packets for their heartbeat, that adds up to a LOT of log entries when
there are several dozen such clusters)
If what you need is for the PIX to handle but not log certain policy events,
use 'log disable' in your ACLs:
access-list acl_inside deny udp any 10.0.255.255 eq 694 log disable
But, I think this is a bad idea for a number of reasons. First, this is not
a lot of data. 43K syslog events from a PIX is going to be less than 10MB
of actual data before parsing or compression. Even on a P2 running NT and
Kiwi, this is not a lot of data.
if it was _just_ 43k (10MB) logs per day I wouldn't worry about it, but
43K logs/day * 100 servers * ~2 firewalls/server drives it up to ~9m
(2GB) logs/day, which is much more significant :-)
the worst thing is that at the moment I get two entries from each packet,
first the 70005 message telling me that the packet to broadcast wasn't
accepted, then the ACL log telling me it was rejected (the 43k
figure doesn't include this doubling).
Second, making these events disappear will skew any firewall performance
statistics that you may want to do with these logs.
Third, even if these events aren't individually important, the volume of
them could be, specifically drastic and sudden changes in that volume.
Log data is all contextual. To throw out even mundane events is to
literally miss the whole picture and will probably come back to bite you
later. Just my unsolicited $0.02.
all very good points, I'll have to balance these against the load on the
logging and reporting infrastructure.
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no
deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
RE: Appropriate PIX logging level Paul Melson (May 04)
Re: Appropriate PIX logging level Miha Vitorovic (May 04)
RE: Appropriate PIX logging level Behm, Jeffrey L. (May 05)