Re: [logs] firewall logging and rulesets

From: Terence Runge (terencerunge@private)
Date: Tue Oct 21 2003 - 16:17:30 PDT

  • Next message: Bill Mathews: "Re: [logs] firewall logging and rulesets"

    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) for the correct version of the pix and get a full description of the message.
    Error Message   %PIX-6-305011: Built {dynamic|static} {TCP|UDP|ICMP}
    translation from interface_name [(<acl-name>)]:real_address/real_port to
    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."
    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.
    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
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Wed Oct 22 2003 - 13:44:59 PDT