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
beforethe 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).