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
This archive was generated by hypermail 2b30 : Wed Oct 22 2003 - 13:44:59 PDT