Enabling Logging on default rules in Palo Alto

Hey there.

To brief, Palo alto is not a deny all firewall. It has 2 default actions:
Interzone deny and Intrazone allow.

This indicates that all traffic passing between zones will be denied unless explicitly allowed.
The explicit rule has to be on top of these as the rules are evaluated from Top down.

Hence, its a restrictive access device. However, how you will come to know if anyone was allowed or denied using default rule.

By default it is not going to log anything. Yes, no logging at all. I think this should be allowed by default. Before version 6.1 there were no such rules but they were present implicitly. You just couldn't see them. If you need to enabled logs you had to mimic these two rules and enabled logging.

After 7.0 if we need to enable logging, we would have to override and change settings. We can't change their name and nature but it will allow you to make minimal changes. Here are few captures.

What is Pan(w)achrome.

Hi Guys,

I have recently bumped into Pan(w)achrome while surfing Palo Alto forums.  

I have done research on this and found following: 


Pan(w)achrome is an application which is been written by Palo Alto itself. 

It is a chrome extension which will provide you information about counters, CPU, Memory and much more. 

In my opinion, this is a great step taken by Developers because Palo Alto is a GUI friendly firewall still there is a lot of information which is still present on CLI.

This tool was out as early as 2011. It started with Palo Alto version 4.1. It has recently evolved and the way it can represent data in Graphical form is just amazing. You can see following information from using this Extension which is generally never available in GUI; 

Here are few links for your reference: 

Installation, usage of Pan(w)achrome: 

https://live.paloaltonetworks.com/t5/API-Articles/Panachrome-Extension-for-Monitoring-the-Palo-Alto-Networks/ta-p/72145

First release: 

https://live.paloaltonetworks.com/t5/API-Articles/Panachrome-for-PAN-OS-4-1-v0-3/ta-p/60151

0.6: 

https://live.paloaltonetworks.com/t5/API-Articles/Pan-w-achrome-0-6/ta-p/62646

0.7 (latest as of now): 

https://live.paloaltonetworks.com/t5/API-Articles/Pan-w-achrome-0-7/ta-p/53506

Thank you. 

Packet flow in Cisco ASA Demystified Part 1.

(This is my own research. I would request experts to correct me if I am wrong)

I will be writing flow of packets. Understanding packet flow was very necessary for me to compare Cisco Firewall with others I have worked on. Once I started looking I found document number 113396 found on Cisco.com. Link in references. However, I understood less so I decided to walk step by Step so that I can have a clear cut understanding. 

However, I have decided to demystify the packet flow by using appropriate flow charts, and packet captures. 

Lets get ready. First and foremost, I would like to introduce you to a flowchart which I have created (after fighting with Microsoft word for days): 

Here is explanation of the steps I have defined above one by one: 

1. The packet arrives on the Interface (wire). 

2. As the packet hits the Ingress Interface buffer, its counter is going to be incremented by 1

3. ASA tries to find if the connection table, If the packet matches the current connection It will be moed to Step 6. 

However, a different we have a different story for packets which are not matched any connection and they go as follows: 

4.The packet will be checked against the ACL. The packet will be processed by ACL sequence. Top to down. When a packet matches the ACL, hitcount will be incremented. 

5. Oh boy! This one confused me. In step 5 the packet is processed using NAT Control was disabled in 8.3 and yes you can't' turn it on. NAT control is nothing just a necessary presence of NAT. However, as NAT control has been disabled after version 8.3 Now its only used to do a route lookup and find the egress interface. Here is a link for NAT control if you are interested. 

http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/nat_control.html

6. Packet is also checked form Stateful Packet Inspections if there are any present. If there is a CSC Module or CX module. Packets should be inspected by them as well. 

7. The IP address of the header is translated using the NAT policies. In case you have a PAT in place the ports are going to change as well. In case you have AIP-SSM module, it is going to do further checks. 

8. Packet is forwarded to egress Interface. 

9. In normal Scenario: The egress Interface will be determined using NAT and A route lookup will be performed in case they both match,packet will be forwared.

In (not so)normal Scenario 1: The NAT does not have a egress Interface defined, a global route lookup is done and the packet is forwarded. 

In (not so) normal Scenario 2: The NAT does point to a different Interface and the Route point to the different. In this case the packet will be dropped and you will get : No route to messages. 

10. Once a L3 route lookup is done, L2 resolution is identified. 

11. Packet is put on a Wire and Interface counters go up.

Now in next post I am going to setup a GNS LAB and going to take packet captures.