Order the Data Center Security Policy Rulebase
When traffic matches a Security policy rule, the firewall
takes an action and the traffic hits no other rules. Incorrectly
ordering the rulebase can allow traffic you want to deny or deny
traffic you want to allow.
This section summarizes the data center Security policy
rulebase for all four data center traffic flows to provide a snapshot
of the complete rulebase and show the order of the rules. The preceding
sections discuss each Security policy rule in detail (as well as
the Decryption policy rules, and where required, the Authentication
policy and DoS Protection policy rules).
The order of the rules is critical. No rule should shadow another
rule. For example, block rules should not block traffic that you
want to allow, so a whitelist rule must allow traffic that a block
rule blocks
before
the block rule goes into effect. In addition,
a whitelist rule should not allow traffic that you want to block.
By creating very specific whitelist rules, you can tightly control
the allowed applications and who can use them, and then block those
applications from other users who are not sanctioned to use them.The first five rules whitelist DNS access for users and whitelist
specific application and server access for specific user groups.
These are the rules we configured in Create
User-to-Data-Center Application Whitelist Rules.
Only the specified users can use only the specified applications
on their default ports to access only the specified data center
destination servers (addresses). Security profiles protect all of
these allow rules against threats. These rules precede the block
rules that discover unknown users and applications on the network
because these rules are very specific and prevent sanctioned users
and applications from matching more general rules lower in the rulebase.
The next two block rules, which we created in Create
Data Center Traffic Block Rules, discover unexpected applications
from users on standard ports and on non-standard ports.
The preceding whitelist rules allow access for known users,
running only the applications they need to use for business purposes
on standard (application-default) ports. Traffic from known users
running the same applications on non-standard ports doesn’t match
those whitelist rules and filters through to the following known-user
rule, which logs the non-standard port usage and applies threat
protection profiles to the traffic.
Because these rules are based on traffic from the user zones,
traffic from other zones doesn’t match these rules. Place these
rules above the application blocking rules (rules 16 and 17) or
they will shadow these rules. (Traffic that matches these two rules
may also match the more general application blocking rules. If the
application blocking rules come first and match traffic that also
matches these rules, that traffic won’t hit these rules and won’t
be logged separately, so the rules won’t do their intended job of
differentiating blocking that is the result of employee user activity
from blocking that is the result of activity from other zones.)
The next seven rules whitelist traffic for the rules we created
in Create
Internet-to-Data-Center Application Whitelist Rules, Create
Data-Center-to-Internet Application Whitelist Rules, and Create
Intra-Data-Center Application Whitelist Rules.
Security profiles protect all of these allow rules against threats.
The next four rules, which we configured in Create
Data Center Traffic Block Rules, block applications that
you know you don’t want in your data center and unexpected applications,
and discover unknown users on your network.
Rule 15 blacklists applications you never want in your data center.
This rule comes after the whitelist allow rules to allow exceptions.
For example, you may sanction one or two file sharing applications
in application whitelist rules that precede this blacklist rule,
and then the application filter in this rule blocks the rest of
that application type to prevent the use of unsanctioned file sharing
applications. If there are sets of applications or individual applications
that you never want on your network and for which there are no exceptions,
for example, BitTorrent, you can create a specific blacklist rule
to block just those applications and place it at the top of the
rulebase, above the application whitelist rules. However, if you
do this, you must be certain that none of the blacklisted applications have
legitimate business uses because they will be blocked.
Rules 16 and 17 are analogous to rules 6 and 7, which discover
unexpected applications from users (the traffic those rules apply
to comes only from user zones). Rules 16 and 17 discover unexpected
applications from all other zones. Having separate rules enables
you to log blocking rule matches with greater granularity.
Rule 18 discovers unknown users so that you can log those attempted
accesses separately for easier investigation.
As with all Security Policy rulebases, the final two rules are
the standard Palo Alto Networks default rules for intrazone traffic
(allow) and interzone traffic (deny).
