Create Intra-Data-Center Application Whitelist Rules
Table of Contents
Expand all | Collapse all
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.
- 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.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. - 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.
- 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 (MonitorReportsApplication ReportsApplications). 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.