Applications and their dependencies

[snormoyle]

I am trying to figure out this APP ID and the dependencies

In order for symantec updates app to work, the FTP app must be allowed.  I discovered that to get to the doc's on palo alto network you need the app clearspace which is dependent on http-proxy.

As I allow the FTP and http-proxy apps how can that be restricted so just not anybody can then get access to those apps.  I know I could restricted by source, but this can lead to a very messy situation over time.

[snormoyle]

This is just an addition into my concerns related to the application dependencies that need to allowed in order to allow applications to work.

the clearspace app is used by the palo alto networks and in order to to use clearspace through the palo alto firewall you need to allow http-proxy app.  If you allow the http-proxy application through the firewall, this now opens up a the possibility that the "http connect tunnel" can now get through.

[mikand]

I agree that this needs to be fixed.

If I allow clearspace then I have nothing against if the PAN will do some magic behind the scenes to make this work but at the same time it should never allow other applications as you described.

In the particular case I can agree to that http-proxy needs to be allowed at first (in order to detect clearspace) but once clearspace is detected (or not detected) then http-proxy should no longer be allowed through the PAN for this particular flow. The question here is perhaps how many packets is needed for the detection to work?

Doing tests for how the appid works (deny unknown, allow any appid (with full idp, antivirus and antispyware inspection incl ssl-termination) showed that the request will be allowed through the PAN (because at this point it doesnt know what app this might be and because I simply allow all applications in this test) but the response from the server is blocked (because now PAN figured out that the application in use was web-browsing BUT the request itself wasnt web-browsing so the endresult was unknown which was denied).

In this particular test I sent a "a b c" as request to a webserver (located behind the PAN) and could verify that the packet with just "a b c" (instead of "GET / HTTP/1.0" or whatever) passed through - but the (I think it was) "HTTP 400 Bad Request" sent as response from the webserver was not allowed and the session was destroyed (as it should).

So is there some manual workaround one can use to fix this problem unless PAN cannot fix this?

At first I thought that something like this could work (before my brain started to function )

1) Allow appid: clearspace, http-proxy

2) Deny appid: http-proxy

but once my brain booted up (a few microseconds later ) I realized that this will never work becuase PAN uses top-down first-match so rule no1 will always be used before rule no2 (a flow identified as http-proxy will never hit rule no2).

[snormoyle]

The application dependencies do not bother me that much, because most applications are heterogeneous.

I know I can restrict rules by source address, source user, etc, but this could lead to a very sticky web over time within the rules.

Hopefully Palo Alto will come back with a detailed explanation and all this is just a mute point.

[SRA]

You can restrict rules by adding other match criteria to the policy. In addition to source address, you could also restrict by the URL category to handle dependencies on web-browsing. Many of the AV updates do go over HTTP, but with symantec-update you will need to allow FTP as the update file is retrieved only after the initial login is allowed. For a centralized av mgmt, source addr could be limited to just a single server too.

For clearspace, the dependency on http-proxy may be in error. You need it only if you have a proxy setup. In that case, you can restrict the rule by the destination addr of the proxy. We'll fix this in a future content update.

We are also working on simplifying application dependencies in the future, where some of the dependencies could be handled implicitly.

[mikand]

Yes but the point here is that this updateserver suddently cannot do just symantec-update, it will also be able to do ftp to all the world (unless you create custom url category to restrict it to a specific domain/host but this wont work for ftp traffic I guess so you are back to square 1).

And this gives that the whole idea of using a NGFW aka applicationfirewall suddently gets broken since this "limit to a specific application" isnt really true...

For me its more logical to only allow "symantec-update" and nothing more. The need for "ftp" as appid should be (in my opinion) handled by the "symantec-update" itself.

Lets say that the ftp session is always right after the updateserver communicate with someurl:someport and some payload (dunno whats the signature for the "symantec-update"). This brings that the "symantec-update" could allow the ftp but only after that initial http stream to the liveupdate servers.

As it is today the updateserver will be able to do more than just symantec updates... because the rules setup with appid are OR-based and not AND-based.

I mean if I setup a security rule that allows symantec-update and ftp, this rule will allow my host to do ftp on its own to any ftp-server (and not limit the ftp sessions to only those related to update against a symantec liveupdate server)?