Re: Appropriate PIX logging level

On Tue, 18 Apr 2006, Tichomir Kotek wrote:

> Ravdal, Stig wrote:
>> Hi guys,
>
> Hi
>
>> 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.
>
>
> tk
>
>
> _______________________________________________
> firewall-wizards mailing list
> firewall-wizards_at_honor.icsalabs.com
> http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
>

-- 
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_at_honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards