: Create Intra-Data-Center Application Allow Rules
Focus
Focus

Create Intra-Data-Center Application Allow Rules

Table of Contents

Create Intra-Data-Center Application Allow Rules

Create Security policy rules that allow servers in different data center server tiers to communicate and 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 Security policy allow 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 allow 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 allow 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.
Each of the following allow rules:
  • Has the best practice Security profile group attached, which consists of the best practice Security profiles. Using a Security profile group enables you to apply all of the best practice profiles to a rule at one time instead of specifying each profile individually. Security profile groups make configuring protection against malware, vulnerabilities, C2 traffic, and known and unknown threats faster and easier.
  • Logs traffic (at session end) so that you can track and analyze rule violations and includes log forwarding. Forward logs to log servers and when applicable, forward log emails to appropriate administrators.
  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 Allow 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.
    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.
    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.
    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.
    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 allowed in the security policy rules are running by viewing the predefined Applications report (MonitorReportsApplication ReportsApplications). If you see unexpected applications in the report, review the application allow rules and refine them so that they don’t allow the unexpected applications.