Security Policy

[dworakj]

I recently created a new security policy to see how many hits are from a specific application.

The rule is "IN-OUT-APP-BLOCK1".  It is Sourcing from my INSIDE ZONE from ANY IP address.  The Destination is the OUTSIDE ZONE to ANY IP address.  It has 'irc' set as the application, no service, and ALLOWED action.  Pretty simple rule. The rule has a LOT of hits. 

I then went to the Monitor tab and added a filter to show "( rule eq 'IN-OUT-APP-BLOCK1' )".  The results are very interesting.

"IRC" is a Application with 4 sub categories.  IRC is TCP6665-6669 and some dynamic ports.  

My 'interesting' Monitor filtered results show some of my INSIDE hosts are attempting to establish a connection to external devices.  However, in the "TO PORT" it shows port 443 matching my new rule.  I'm very confused how 443 would match this rule.  I've attached an image showing these screenshots of the results from my filter.  

Can anybody explain why a rule with IRC as the application would match a hit from 443?

[BPry]

@dworakj,

I would assume that this is the first application based rule that is in your rulebase. The firewall needs to allow enough traffic to pass to actually identify the application, which is why all of the logs that you have displayed pass so little data. Once enough traffic has passed for the firewall to identify the application, it is re-analyzed to determine whether or not the traffic should be allowed. 

[dworakj]

I do not think this is my case.  I have well over 100,000 hits on this rule.  All sourcing from multiple hosts going to multiple destination.  IRC is identified as a very specific range of TCP ports, but my MONITOR hits for this rule all show 443.  443 is SSL and should not hit this rule at all!

[dworakj]

[dworakj · Accepted solution]

 I think i figured this out.   First, i'm a legacy firewall guy using various other product.  Typically in a firewall you build rules based on "SOURCE - DEST - PORT".  The "PORT" part of this generic policy is what was throwing me off.  The APPLICATION (when you select this) is a list of built applications in the firewall object store.  When you open these and review what is a 'traditional' port it shows the port of that application.  Such as Telnet would be TCP/23.  So to block outbound Telnet, build a policy to block port 23 when going outbound.  

In my case (and noob usage of a Palo) i assumed the 'application' was the same as a Port, but found that the "Service" shoudl actually be the port to be blocked.  

So my rule now looks like this:

Where the "IRC" service was manually built by me to include ports 6665-6669.

[BPry]

@dworakj,

Best practice would be that you aren't building just any 'any' application rule for a service when you're working with a NGFW that can do application identification. You are either manually specifying a service (if absolutely required) or setting application-default so that potential future default ports are actively allowed without you adjusting policy through dynamic updates. At times you'll need to for operational reasons, but it should be the exception. What you have built will allow anything running on 6665-6669, which means if I've breached one of your DMZ hosts I can now build an SSH tunnel for exfiltration once I've done a simple port scan.

Note that your rule appears to be denoting that you are looking to permit this traffic, but in both your example and the description of your intent you are specifying an action of allow. I would verify that you actually want to allow this traffic and not deny it, because it would appear you have your action set incorrectly.

What you experienced earlier is 100% expected behavior with how you had the rule built. The firewall needed to allow enough traffic to pass to identify the application so that it could see if it should be allowing the traffic. Many people are initially surprised to see this behavior when a small amount of traffic is caught under the rule where they aren't expecting to see it, but it's normal and well documented as to why.