Re: [logs] firewall logging and rulesets

terencerunge@private

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