Question regarding unknown application behaviour

[Anon1]

Lets say you configure a rule with:

Application = Any

Service = Custom Service (TCP port 12345)

Now when the AppID engine cannot match anything I guess it classifies the traffic as "unknown-tcp".

Will the traffic be allowed (because unknown-tcp is part of Any and the firewall will practically act as statefull firewall) or will it be denied?

What is the purpose of Application Overrides? This seems complicated to me since you have to go to a different policy section and configure it in addition to the actual firewall rule.

Thanks in advance.

[mharding]

When you set the application to any and just define a port, it acts like a basic firewall. Not matter what application is being used (DNS/SMTP/Web-Browsing/SSL), it's going to be allowed as long as it's using the defined port/service.

Application Override policies bypass the App-ID engine.

An application override policy is used to change the way the firewall classifies network traffic into applications.  An application override with a custom application will prevent the session from being processed by the App-ID engine, which is a Layer-7 inspection. The firewall is forced to handle the session as a regular stateful inspection firewall at Layer-4.  If an existing application, web-browsing, for example, is used in the application override, the rule will force all matching traffic into Layer-7 inspection for that specific application.

An application override could be used wilth custom internal applications that use non-standard port numbers or internal applications that are classified by the firewall as "unknown" and custom definitions have been created for them.

Application Override and Scanning Engines

[mikand]

No...

What your rule actually means is "allow if tcp port = 12345, dont care which appid is identified" (assuming your action was allow).

Which means that if you set "appid=any" to all your rules then PA will work just like any SPI-firewall (only looking at srcip, dstip, srcport, dstport (if we ignore the other features which PA have like IPS, AV, SSL termination, URL categorization etc)).

Unknown-tcp is a session/flow which doesnt match any known appid. There is also unknown-udp and unknown-p2p.

So in your case unknown-tcp will be allowed aswell.

A recommendation is therefor to put a specific action=deny for appid=unknown-tcp, unknown-udp and unknown-p2p.

Note however that some appid's demands that unknown traffic is being allowed in order to fully identify the appid in question.

Application overrides is to manually force the PA to detect specific traffic as a appid.

Either due to reporting (for example if you for some reasons know that traffic going to x.x.x.x TCP80 is always http, then you could setup an application override to "dstip=x.x.x.x, dstport=80, proto=tcp, override=web-browsing". The override can also be used if PA incorrectly identifies a specific flow as wrong appid type.

Usually override isnt used (except for the case when PA misidentifies a flow).

[Anon1]

OK, so if AppID=Any and Service=Custom (TCP / UDP / Port number / range) then the device works like a traditional stateful firewall (even if AppID classifies the traffic as unknown)?

Would that approach be a viable option for a migration in large enterprise environment with a lot of firewall rules allowing proprietary applications where no signature for AppID exists (inhouse application, niche applications). At least for a transition phase until a custom AppID definition can be created or research can be done what is actually transfered over the connection (may be with help of the log or reporting).

Another question: Web Server in DMZ hosting web sites, which application would you use here to allow connections from public Internet to the web server in the DMZ: web-browsing? That sounds inappropriate but there is no web-hosting application in applipedia?

[mharding]

Would that approach be a viable option for a migration in large enterprise environment with a lot of firewall rules allowing proprietary applications where no signature for AppID exists (inhouse application, niche applications). At least for a transition phase until a custom AppID definition can be created or research can be done what is actually transfered over the connection (may be with help of the log or reporting).

Talk to your SE. They might have a migration tool to help you get from your current firewall to the Palo Alto. But yes, that's the way I did it way back on PAN-OS 2.0. Then you can use the custom reports to see what apps are actually being used (and that you approve of) and you can start setting them in the security policy.

Another question: Web Server in DMZ hosting web sites, which application would you use here to allow connections from public Internet to the web server in the DMZ: web-browsing? That sounds inappropriate but there is no web-hosting application in applipedia?

It would be web-browsing. Web-browsing is the parent app for HTTP requests. (You have to be careful. You may have child apps like hotmail and web-crawlers accessing your website that be blocked if you just allow web-browsing.)

[mikand]

OK, so if AppID=Any and Service=Custom (TCP / UDP / Port number / range) then the device works like a traditional stateful firewall (even if AppID classifies the traffic as unknown)?

Yes and no. Appid is always active in the background - but this particular rule will just ignore whatever appid the session is being identified as.

There is also a sales slide with a brief description on what the PA will do on a packet which arrives on one of its dataplane interfaces. The first thing (according to this slide) which the PA does is to verify the ip header in terms of srcip, dstip, srcport, dstport. If there are no security rules which matches these items then the packet is dropped right away. But if the packet is accepted then all the shebang of appid, decoding, heuristics etc is performed in what the marketing people calls "single pass engine".

So in this case the flow is:

1) Verify ip header (do we have any security rule which might match the ip header?).

2) Detect appid etc.

3) Now go through the security rules and see if the packet should be allowed or not.

Would that approach be a viable option for a migration in large enterprise environment with a lot of firewall rules allowing proprietary applications where no signature for AppID exists (inhouse application, niche applications). At least for a transition phase until a custom AppID definition can be created or research can be done what is actually transfered over the connection (may be with help of the log or reporting).

Except for what umphmharding already said you wont make it worse by just doing a 1:1 replacement. However the point of getting a PA is in most cases to improve the security but at the same time if you do this in small steps then it will most likely be easier to troubleshoot.

Otherwise if you do everything in a single service window and problems arrives (not necessary due to the PA but more likely due to app developers being detected doing things they are not allowed to with their apps like pushing SSH over TCP80 and such) there will most likely be one or another blame on "yeah its that PA's fault".

So if you start with just do a 1:1 transition on srcip, dstip, srcport, dstport and see that being stable for a week or so the next step will be to, along with the reports from PA device itself, start to limit each flow (security rule) by enabling appid.

And the final step will be to enable IPS, AV, blocking of files etc (unless you do this rule by rule in step 2 above).

Another question: Web Server in DMZ hosting web sites, which application would you use here to allow connections from public Internet to the web server in the DMZ: web-browsing? That sounds inappropriate but there is no web-hosting application in applipedia?

You could as a start just use a security rule for your DMZ server where you set "appid=any" and then look in the logs (or create a report) where you see how the PA identifies this traffic and then apply just that appid for this particular security rule. If you use HTTPS I would strongly advice you to read up on the SSL termination features of PA so the PA can inspect the encrypted traffic aswell.

For other cases you can also contact the appid team at PA if you have an application which isnt being identified by PA and this team will either create a custom appid for you (available through regular updates but only your boxes will see it) or make it commonly available for everybody to use. You can also create your own custom appid's (and IPS signatures which are similar) without involving the appid team.

Edit: WTF - the quoting works in edit mode but not when I save the post :S