As far as I know since PixOS 6.2 (latest version is 6.3) the log format has changed drastically. Old message reporting direction of the session and consumed bytes "%PIX-6-30200<1|2|5|6>" has been replaced by respectively "%PIX-6-30201<3|4|5|6>" (the old messages are no more used).

More information available here: http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_system_message_guides_list.html

About the source and destination problem, I did not found precise information within the Cisco web site (even logged-in). I make my own tests to analyse the Pix logs depending on the direction the session was established. What I saw is the following:

As Cisco Pix Firewall is based on the ASA (Adaptive Security Algorithm), and then all interfaces must have a security level (number between 0 and 100). The inside Interface has by default a security level of 100 and outside has 0. DMZs can have security level in between these two numbers. The ASA always look at the session with the security level in mind, that mean a session is inbound or outbound.
Outbound = Interface with higher security level go to lower
Inbound = Interface with lower security level go to higher
Now we can understand the Cisco "to", that always mean "lower security level interface" to "higher security level interface". This order never takes in account the direction of the session. Only the "Built" message has this information with inbound/outbound string.

Case a) session initiate from inside
The "built" message report outbound (destination-low to source-high) session and "outside:62.210.190.23/80 to inside:155.105.58.53/1516" mean inside is the source and outside is the destination.

Case b) session initiate from outside (155.105.6.32)
The "built" message report inbound (source-low to destination-high) session and "outside:64.68.82.50/42810 to public:155.105.6.32/80" mean outside is the source and public is the destination.

Note: In regard of the destination port it makes sense for a web access!

If you want to be absolutely sure on that, we (I) can forward this question to Cisco. I mean open a TAC case to obtain a Cisco clarification on this subject.

Your "keying" option will be certainly the only way to doing valid report (source/destination). You current report will be right only if you have "inbound" traffic (like for hosted services).

I hope I am clear enough, anyway don’t hesitate to contact me by e-mail for clarification.
Thanks, F. Bruchez

I wonder if we can convince Cisco to change their format to make it reasonable? If they can add something on each line to help the parser understand which is the source and which is the destination, that would be fine. Or if they could make it so "X to Y" always means X is source (e.g. change the order of their outbound connections). Could you open a TAC case not just to clarify this (though I'm sure you're right), but more importantly to try to convince them to change the way they've done this? Maybe I can convince them to switch their logging entirely to W3C or something-- they desperately need a consistent format that doesn't require 100 passes over it to get the information.

Lacking cooperation from Cisco, would it work if Sawmill just automatically flipped source and destination IPs and ports whenever it saw that the connection was "outbound" (using keying to determine that)? That could be done with a collection of Log Filters, at the end of parsing each line. Do you think that would solve the problem, or are there cases where the connection is "outbound" and "X to Y" still means that X is the source?

Will this keying option increase the database size and reduce drastically the speed of the log importation process? Because I have 2GB of Pix log a day, and Sawmill generate a large database and take a long time to process each logs.

Thanks
F. Bruchez

Keying will slow the processing slightly but I would not expect it to be dramatic. It should not affect the database size and it may even reduce the db size if there is less being parsed.

Graham
Technical Support

support@thesawmill.co.uk

106023: Deny udp src inside:xx.xx.xx.xx/138 dst outside:206.120.18.3/138 by access-group "acl_in"
106011: Deny inbound (No xlate) icmp src inside:xx.xx.xx.xx dst inside:xx.xx.xx.xx (type 8, code 0)
106023: Deny udp src outside:152.163.159.221/9052 dst inside:xx.xx.xx.xx/6079 by access-group "acl_out"

Anyway hope that helps, I also would love to see some better pix reports too

Zeeke

For example,

in the Single Page Summary, some of the top *SOURCE* IP addresses are external DNS servers. That makes me think that they are in fact being read in reverse, or not tracking the stateful connections somehow. The only way the DNS servers would be among the top source IP's is if it was only counting responses, and not the initial request.

It seems to be the same thing for ports as well. Maybe I am somehow confused?

Thanks,
Mark Lachniet

It's possible that the IPs are listed in reverse in the log data. I've seen that before a few times.

Might need to send in a sample and we can take a look at it.