Create Intra-Data-Center Application Whitelist Rules

Create whitelist rules that allow servers in different data center server tiers to communicate so that they can provide application services, while preventing unnecessary communication among servers.
Data center traffic often consists of multi-tier application traffic that flows between different server tiers to provide services for applications such as SharePoint, WordPress, internal proprietary applications, etc. The most common multi-tier application architecture consists of web servers (presentation tier), application servers (application tier), and database servers (data tier). Create a Data Center Segmentation Strategy provides guidelines on how to place firewalls between application tiers and how to segment a data center.
The way you treat traffic between data center servers depends on the traffic. For most application traffic, add threat prevention profiles to the whitelist Security policy rules to inspect the traffic. For example, always apply the best practice Security Profiles to protect traffic between the web, application, and server tiers of finance applications, engineering development applications, and so on. The exception to applying threat prevention profiles is traffic for high-volume, low-value applications such as mailbox replication and backup flows. You still whitelist access to these applications, but because a firewall has already inspected the traffic before replication, applying threat prevention profiles consumes firewall CPU cycles without providing extra value.
The WildFire security profile identifies unknown malware attempting to spread among data center servers to prevents the exfiltration of data by discovering malware before it can do damage. If you can’t use the WildFire global cloud, you can deploy a WildFire private cloud or a WildFire hybrid cloud.
The example Security policy rules in this section show how to whitelist traffic for multi-tier data center finance applications that require using the web server, application server, and database server tiers to serve the applications. The example includes two proprietary internal applications for which we created custom applications:
Billing-App
and
Payment-App
. Creating custom App-IDs for these applications enables the firewall to identify them, control them, and apply Security policy to them. Don’t allow unknown applications in the data center because you can’t identify and apply security to them, and they may indicate an adversary in your data center. Every data center application should have an App-ID.
Allow applications only on their standard (
application-default
) ports. In some cases, business needs may require you to make an exception and allow applications to use non-standard ports between particular clients and servers. In these cases, be aware of the application traffic running on non-standard ports, and ensure that you know every instance of an application running on a non-standard port. Applications that run on non-standard ports for which you have not made an explicit (known) exception may indicate the presence of evasive malware.
Tag all sanctioned applications with the predefined
Sanctioned
tag. Panorama and firewalls consider applications without the Sanctioned tag as unsanctioned applications.
Order the Data Center Security Policy Rulebase shows you how to order these rules with all of the other rules we create for the other three data center traffic flows and the block rules so that no rule shadows another rule.
To apply consistent security policy across multiple data centers, you can reuse templates and template stacks so that the same policies apply to every data center. The templates use variables to apply device-specific values such as IP addresses, FQDNs, etc., while maintaining a global security policy and reducing the number of templates and template stacks you need to manage.
  1. Allow finance application traffic between the web server tier and the application server tier.
    This rule restricts the traffic that can flow between the web server tier and the application server tier for the Finance department’s billing servers so that only traffic using legitimate applications can access the billing servers. (We also create a rule to restrict Finance user access to the data center when we Create User-to-Data-Center Application Whitelist Rules so that only the right Finance users can access the data center.) The rule uses dynamic address groups to specify the servers in each application tier—
    Web-Servers
    specifies the addresses of the servers in the web server tier and
    Billing-App-Servers
    specifies the addresses of the servers in Finance’s billing application server tier.
    web-to-app-server-sec-pol-rule-intra-dc.png
    To create this rule:
    • Restrict the source of finance application traffic to the web servers (
      Web-Servers
      ) in the
      Web-Server-Tier-DC
      zone.
    • Restrict the destination for finance application traffic to the billing servers (
      Billing-App-Servers
      ) in the
      App-Server-Tier-DC
      zone.
    • Restrict the applications the web servers can use to access the billing application servers and only allow applications on their default ports. In this example, the applications include two custom applications,
      Billing-App
      and
      Payment-App
      , for which you specify default ports when you create the applications. The Finance Department uses these proprietary applications for billing and payment services.
    • Apply the full suite of best practice security profiles to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats.
    • Log activity so that you can track and analyze rule violations, which may indicate an attempted attack.
    Create similar rules to control applications and traffic between the web server tier and other application server tiers.
  2. Allow finance application traffic between the applications server tier and the database server tier.
    This rule restricts the traffic that can flow between the application server tier and the database server tier for the Finance department’s billing servers so that only traffic using legitimate applications can flow between the billing application servers and the billing database servers. The rule uses dynamic address groups to specify the servers in each application tier—
    Billing-App-Servers
    specifies the addresses of the servers in the application server tier and
    DB2-Servers
    specifies the addresses of the servers in Finance’s database server tier.
    app-to-db-server-sec-pol-rule-intra-dc.png
    To create this rule:
    • Restrict the source of finance application traffic to the billing application servers (
      Billing-App-Servers
      ) in the
      App-Server-Tier-DC
      zone.
    • Restrict the destination for finance application traffic to the database servers (
      DB2-Servers
      ) in the
      DB-Server-Tier-DC
      zone.
    • Restrict the applications the billing application servers can use to access the database servers and only allow applications on their default ports or their known non-default ports.
    • Apply the full suite of best practice security profiles to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats.
    • Log activity so that you can track and analyze rule violations, which may indicate an attempted attack.
    Create similar rules to control applications and traffic between the application server tier and database server tier for other applications.
Verify that only the applications you explicitly whitelisted in the security policy rules are running by viewing the predefined Applications report (
Monitor
Reports
Application Reports
Applications
). If you see unexpected applications in the report, review the application whitelist rules and refine them so that they don’t allow the unexpected applications.

Related Documentation