Rules, group, filters etc.

[BobW]

I realize this sort of question is difficult to answer but here goes.

I am working on setting up our PA500 and am curious how others are setting their rules.  As an example:  there are three groups of users as defined in active directory:  A, B, and C.  All of which require different levels of URL filtering, times and App filtering.  Of course there are some servers which need to be published as well.  What I am doing is:

Setup an app group for each user type.  Setup a couple "all users" app groups and nested these inside of the user specific  "users App groups".  This way I can add an application to the "all users" app group and it filters up to each of the "user app groups".

Setup a URL filter list for each user type.

My rules go as follows in the order as shown:

Publish server/services.

Allow utils/dns/smtp from specific servers

Deny bad apps/urls for all users--proxy, bittorent, etc.

Allow "app group A" for "User group "A"

Deny all apps for "User group A"

Alow "app group B" for "User group B"

Deny all apps for "User group B"

Alow "app group C" for "User group C"

Deny all apps for "User group C"

The reason I have deny groups is so I can track which apps I need to add to the different "app groups" or the "all users app group".  In the end I would expect to get rid of the "deny all apps" rules.

I guess the question I have is are others using the "nested groups" approach or am I missing something?  I feel like the "groups" method seems a bit weird.

I am not using the "App filters", are people using these much?  Example being if I try to filter P2P level 5 it inlcudes Google apps.

In the end I will have almost exclusively "allow" rules and very few deny (except URLs).  Correct?

Of course my real world stuff is more complex.  It sure woudl be nice to have "real world example" document....

Any other thoughts on the above?

Thanks

Bob

[mikand · Accepted solution]

Thats not uncommon to take more time to decide than it really should and it often ends up in a matter of taste anyway 🙂

First of all... PAN uses top-down first-match which gives that for performance reasons if you have two or more rules with similar content (as in your case with different usergroups), put the rule which you expect to have more hits before the other rules of similar content.

But since PAN uses FPGA/ASICs to handle the traffic (aka dataplane) this will in reality have a minimal impact on the performance. I think however you might get an impact when it comes to user verification (because the dataplane must speak to the mgmtplane or something like that).

Then you can use various "design guidelines" in order to how to construct your rules (and in which order to place them).

If we start with security purposes (which after all is why you have a firewall in the first place) you can use a design something like:

*) blacklists (denies)
*) whitelists (allows)
*) default deny (with logging, at least on session start but you might need on session end for debugging aswell)

Example for above is if you wish to deny access to url-category malware but allow access to url-category newssite. Now... if you only use whitelist and a site is categorized as both newssite and malware at the same time this would be bad wouldnt it? So to fix this you place the stuff you wish to blacklist before the stuff you wish to whitelist.

Then we have readiness. If you just have 3 security rules it doesnt really matter in which order they are placed... but if you have hundreds of these security rules you must start to "group" them somehow, or at least place them in such order to its easier to locate a specific rule (this will at the same time break the performance "optimization" which again doesnt matter that much since the performance "optimization" is limited anyway).

PAN currently doesnt support security groups (grouping the security rules in the GUI) but this doesnt really matter if you decide to order your rules according to which dstzone they have.

In this case it can be handy to be more strict and not combine different dstzone's in the same security rule. You will end up with more rules but at the same time easier to audit your own rules (start to combine your rules only if you hit the roof of how many security rules your device can handle).

For example for each dstzone setup:

*) blacklists (denies), dstzone=x
*) whitelists (allows), dstzone=x
*) default deny (with logging, see above), dstzone=x

*) blacklists (denies), dstzone=y
*) whitelists (allows), dstzone=y
*) default deny (with logging, see above), dstzone=y

This way you will construct (and place) the security rules per zone and also try to block any misconfigurations later on (in case you in the y-grouping suddently tries to enable traffic into x-grouping - of course this wont be foolproof if you do the other way around but still take care of 50% of the misconfigurations when it comes to allow traffic into zones you shouldnt).

Regarding misconfigurations - avoiding combining rules can save you later on.

Not uncommon that some people construct rules such as (to keep number of rules down or I dont know):

src: 1.1.1.1, 2.2.2.2
dst: 1.1.1.1, 2.2.2.2
service: TCP1111, TCP2222

instead of:

src: 1.1.1.1
dst: 2.2.2.2
service: TCP2222

src: 2.2.2.2
dst: 1.1.1.1
service: TCP1111

which of course ends up with to much open between the two hosts (or even worse networks) in case the combined version above is used.

Also try to keep your security rules as detailed as possible (specially allows). If you for example wish to allow web-browsing but only for TCP80 then setup the service column to only allow TCP80 instead of "any", or at least use "default-application".

So in your case I would set this up something like (given that you use one blacklist per group unless you use a global blacklist for all groups):

Allow "app ping" dstzone any

Allow "app dns" with service "TCP53_UDP53" dstzone "DNS"
Deny any dstzone "DNS" (log on session start)

Allow "app smtp" with service "TCP25" dstzone "SMTP"
Deny any dstzone "SMTP" (log on session start)

Deny "app group blacklist A" for "User group A" dstzone "Internet" (log on session end)
Deny "app group blacklist B" for "User group B" dstzone "Internet" (log on session end)
Deny "app group blacklist C" for "User group C" dstzone "Internet" (log on session end)
Allow "app group A" with service "default-application" for "User group A" dstzone "Internet"
Allow "app group B" with service "default-application" for "User group B" dstzone "Internet"
Allow "app group C" with service "default-application" for "User group C" dstzone "Internet"
Deny any dstzone "Internet" (log on session start)

Deny any any (log on session start)

but make each rule as detailed as possible (like that allow dns rule above I would also define which srczones etc should be allowed).

One could argue that allows should be as narrow/detailed as possible while denies should be as broad as possible. Which is true but if you sort your security rules by dstzone (so you protect whats allowed into each zone) I still think you can use the blacklist for user A, B and C with dstzone "Internet" instead of just dstzone "Any".

The ping rule above is just an example on where to place "any" rules in case you wish to allow pings into all zones.

The last "Deny any any (log on session start)" should never be reached since each zone should already have blocked unwanted traffic. You could create a daily report regarding this and trigger some alarm in case that last deny any any log rule would get triggered anyway.

So the design would be:

ALLOW GLOBAL (dstzone=any)

DENY (dstzone=x) specific log on session end

ALLOW (dstzone=x) specific

DENY (dstzone=x) any log on session start

...

DENY GLOBAL (dstzone=any) any log on session start

[BobW]

Thank you for the detailed reply.  It is always helpful to hear real world examples/opinions.  I have never worked in an academic environment and ity is quite a bit more challenging, especially when you throw internation boarding students into the mix!

I am also finding the "logic" and rules in the PA are handled differently than I am used to.  It actually requires a different method of thinking.  Having said that, I can't imagine trying to do this stuff on a Watchguard!

I am a BIG fan of the Pal Alto!

Bob

[mikand]

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.

[BobW]

Excellent suggestion!

Thanks again,

Bob