Why do "incomplete" sessions show as "allowed"

L4 Transporter

No big deal man it's an easy mistake to make believe me! When I first started working at the company I'm now with I was new to PAN, and the service column was weird and mysterious to me.

I'm almost of the opinion that there should be some kind of commit warning if the service column is left at 'any' for any rules in the policies tab that are bound to the 'untrust' zone. That's just my own humble opinion though.

L4 Transporter

Thing is, I'm not "new" to PA. I had (have, I suppose) a PA certification in the V3 OS, and this is now the third place I've successfully pushed the installation of the PA firewalls into (yeah, I kinda like them compared to other stuff, how did you guess? :-)) - I just plain bloody *forgot*, and then asked a stupid question.

Of course the firewall was trying to identify the application before dropping on non-standard ports - because I didn't tell it not to!

I'm going to go hide my face in shame now.

L7 Applicator

Yes, if you create a rule that says "permit any app on any port" or "permit specific app on any port" the you could port-scan a machine from one end to the other. That's why you never, never, ever use "any" service on inbound permit rules.

L4 Transporter

OK - how do you deal with application over-rides?

(I know, I know, they're a case of baby did a bad, bad thing, but I need one).

If I set "application default" on those, will they break anything else? In effect, an application override just looks at the port for the specified designation, right? So "application default" should be fine?

L6 Presenter

If I remember correctly the PA will do a precheck on the packet before it start to crunch it through the "singlepass" engine.

This precheck (described in a pdf/picture on this site) will check for the ip-header stuff like srcip, dstip, srcport, dstport. Which gives if you for example only have one rule setup and thats something like "appid:web-browsing, service:TCP80" then if the packet arriving has a dstport of something other than TCP80 then this packet will be dropped (and logged if you have a rule in the end which will log dropped packets, the builtin hidden last rule is just a drop without logging).

Thats why you should avoid to use "service:any" and always use at least "application-default" or even better define exactly which ports you allow.

The next step (when this "singlepass" kicks in) is to try to detect what kind of application this packet actually is, send it through a protocol-decoder and if thats successful it will do other tests aswell on the packet before finally (hopefully) give a final verdict of letting this packet pass through (or drop the session completely).

This gives that if your rule instead was "service:any" the precheck would always fail (given the combo of srcip + dstip is valid aswell) and the PA must let through enough of packets before the particular application can be identified.

Some applications can be identified on the first packet (after the tcp handshake if we talk about tcp applications) while others need a few more packets before the verdict can definately say "this packet is not the allowed appid".

You can see this yourself in action if you setup a rule like "appid:web-browsing, service:any" and put a webserver to listen at lets say TCP81.

Your tcp-handshake will complete (since its obviously part of web-browsing) and you will also be able to send a packet through towards the webserver - lets say a packet such as:

a b c

that is three letters with whitespace in between.

As you can see "a" is not a valid http method - but PA obviously doesnt know this (yet)...

not until the server responds with "HTTP ERROR 400/Bad Request" it seems that PA is 100% sure that this flow has nothing to do with web-browsing and will now drop the flow (and log it if you have such rule in the end).

I have no idea why PA will let through such requests (or if this particular case has been taken care of by an appid update) but a workaround is to create a custom appid which is based on web-browsing but with the addition of "http-method" (or whatever its called when you create custom appids) needs to be GET, HEAD or POST (or whatever http methods you like to let through). Now, with the custom appid, even the request would be dropped.

There are also other corner cases such as if you wish to block skype. In order to block skype you must first allow skype-probe. Which gives that the more you go into "applications" the more leakage will occur.

Personally I recommend to first configure your PA device as you would with an older SPI based device - look at srczone, dstzone, srcip, dstip and service. THEN add which application is supposed to get detected by this flow. And in some cases also add a url-filter (if dealing with browsing). And of course the rest of a proper IPS profile, AV, SSL-termination (to inspect https sessions) etc.

Edit: Here is the document I had in mind:

There is also an "executive summary" edition of the flows described on page 4 (anyone else remembers what that document is called? its like light green boxes describing the same flow but with less technical details).

Edit2: Here is that "executive summary" (well sort of) I had in mind: http://media.paloaltonetworks.com/documents/techbrief-app-id.pdf

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!