Re: [logs] firewall logging and rulesets

brford@private

Terence ,

We are trying hard to make sure that alarm-IDs remain unique.

To go a step further (and tell you things you may already know) the PIX 
allows the Firewall Admin to do two interesting things.

One thing we (big Cisco we) did is to change the level of any log 
message.  So with this you can push all the messages that you really care 
about down to log level 0 (which historically we at Cisco do not use).  Do 
you view this as valuable?  The reason I ask is that I sometimes get push 
back about putting too much capability into the Firewall device.  I just 
look at that as local aggregation which is a generally good thing most of 
the time (unless you are doing forensics and need to see it all).

The other thing we did is to allow the suppression of messages based on the 
ID.  So if you don't like the "Built Dynamic Translation" message you can 
make it so your PIX never emits that message again.  And when I say never I 
mean until you take that line out of the configuration.  But it does 
suppress that message ID.  It doesn't care about any of the data in the 
message (some have said it would have been interesting to try and make it 
smart enough to tell the difference between inbound and outbound).  Again, 
that's at the PIX in an individual devices configuration.

In reading your message am I hearing that you would like to see (and use) a 
Syslog viewer that can interpret what it is reading?  What if I could 
interpret the message for you (if you tell me the PIX OS version) when you 
click on it.

Interesting (at least to me) that nobodies Syslog draft picked up on any of 
this.

Liberty for All,

Brian

At 04:17 PM 10/21/2003 -0700, Terence Runge wrote:
>My 2 cents about pix firewalls, syslog messages, and the overall model.
>With a pix, the messages are limited but contain all the elements for
>greater interpretation, although getting the descriptive info requires
>an additional step. Take the following example, which gives us the most
>basic description of an event "Built dynamic TCP  translation".
>
>Oct 15 00:01:23 [x.x.x.x] %PIX-6-305011: Built dynamic TCP  translation
>from inside:x.x.x.x/3174 to outside:x.x.x.x/35312
>
>In the same example above, we can take the alert and plug it into
>cisco's pix syslog message page (the extra step)
>http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_system_message_guides_list.html 
>for the correct version of the pix and get a full description of the message.
>
>"305011
>Error Message   %PIX-6-305011: Built {dynamic|static} {TCP|UDP|ICMP}
>translation from interface_name [(<acl-name>)]:real_address/real_port to
>interface_name:mapped_address/mapped_port
>
>Explanation   A TCP, UDP, or ICMP address translation slot was created.
>The slot is used to translate the source socket from the local side to
>the global side. In reverse, the slot is used to translate the
>destination socket from the global side to the local side.
>
>Recommended Action   None required."
>
>Point:
>Alarm-id's should remain static and not be recycled, which makes the
>parsing / describing job a bit less cumbersome.The cisco model is good
>in that it provides static alarm-ids which map to version controlled
>static descriptions. This model can be be automated to allow for "higher
>level" reporting with a variety of firewalls.
>
>Hope you found this of use.
>
>Terence
>
>On Tue, 2003-10-21 at 17:10, Tina Bird wrote:
> > in my somewhat limited experience with firewall network connection logs,
> > it seems that firewalls log the result of a particular connection request
> > (usually ALLOW or DENY) pretty faithfully.  they may or may not log the
> > rule which caused them to take the recorded action -- that's the default
> > config on some firewalls, and can be forced on some others.
> >
> > but that's really not terribly helpful, because they usually report on the
> > specific rule using its position in the ruleset, or maybe using a name if
> > such a thing exists in its management.  if you don't have some kind of
> > independent record of what the ruleset >was< at the time that network
> > connection was logged, you have no way of making sense out of the action.
> >
> > i can imagine doing something kind of ugly like pushing a new copy of the
> > ruleset into the system logs every time it changes, but i figured i should
> > ask -- has anyone found a more elegant way of dealing with this problem?
> > in the long run, does it matter much?  that is, if i decide i need to make
> > sense of a set of connections in six months or a year, do i really need to
> > know what rule caused the action?
> >
> > thanks for any info -- tbird
> >
> > _______________________________________________
> > LogAnalysis mailing list
> > LogAnalysis@private
> > http://lists.shmoo.com/mailman/listinfo/loganalysis
>_______________________________________________
>LogAnalysis mailing list
>LogAnalysis@private
>http://lists.shmoo.com/mailman/listinfo/loganalysis

Brian Ford
Consulting Engineer
Corporate Consulting Engineering, Office of the Chief Technology Officer
Cisco Systems, Inc.
http://www.cisco.com
e-mail: brford@private

_______________________________________________
LogAnalysis mailing list
LogAnalysis@private
http://lists.shmoo.com/mailman/listinfo/loganalysis