The top-down first-match is a common execution path when it comes to security rules. Cisco use this, iptables (Linux) use this and so on. To me this is easier to maintain and to interpret (and audit) by simply just read the rules from above until you hit a rule where all "columns" match. Compared to ipf in bsd (along with older allied telesyn switches among others) where a later rule can overrule a previous rule. The new thing with PA (compared to legacy SPI firewalls/acls) is the use of applications. The problem here (as I see it) is if you rely to much on application identification. Thats why I recommend people to first setup their PA as a regular SPI firewall (using the "service" column to define ports) and then add appid to each rule (meaning be as specific as you can regarding "service" or at least use "application-default" and DONT user "any" for service). That is because it can take a few packets before your NGFW detects what kind of application this is and these few packets can be bad for the server your try to protect. You can test this yourself... Setup a rule with appid:web-browsing and service:any. Then setup a webserver listening on TCP81 and connect to it using telnet client such as "telnet 1.1.1.1 81" and type: a b c followed with two enters (that is a[space]b[space]c). Now run tcpdump on the webserver and you will see that your PA (or any other NGFW) will let this packet through to hit your webserver. Not until the webserver replies with "400 Bad Request" the app engine will have proofs that this flow is supposed to be web-browsing but the request isnt so the response will be blocked back to the client. Now, if you setup your rule as appid:web-browsing and service:TCP80 the request would never reach the webserver at TCP81.
... View more