Re: [fw-wiz] Appropriate PIX logging level

On Tue, 18 Apr 2006, Tichomir Kotek wrote:

Ravdal, Stig wrote:
Hi guys,


I'm having a discussion with some of our network engineers about the
appropriate level of logging on a Cisco PIX firewall. The major
complaint I get for increasing the logging level is because of lack of
storage. Are there standard or best practice references that I can
bring to the table?

main disk space killers are connection built(302013,302015)
and connection teardown (302014,302016) events
(built events record connection "orientation", teardown sometimes not,
but provide bytecount and length infos for tcp connection teardown flags)
these informations are sometimes not needed, BUT do read your security
policy ;)

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)

my concern in figuring out how to not log the broadcast traffic, but still log the other blocked traffic.

David Lang

I'm expecting to get some variation in responses from this post. What
may be helpful to me is to understand what information is being lost by
going to the next lower level.

if you are not interesting in logging some of events,
you can turn them off (no logging message <num>) or
change severity (logging message <num> severity <level>)

At a minimum I think we should be logging and analyzing: date/time,
interface(s), src/dst IP, src/dst port, proto, allow/deny, rule applied
(, other?). Does that seem right? What about SYN/ACK and so on?

there is log messages guide for pix with every event description in it

Based on the information I believe we should be logging what does the
logging level on a PIX have to be set to?

Personaly, I will log everything.


firewall-wizards mailing list

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