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