Create Internet-to-Data-Center Application Whitelist Rules
Table of Contents
Create Internet-to-Data-Center Application Whitelist Rules
Create whitelist rules that allow only sanctioned application
traffic access to the data center from external partners, customers,
vendors, and other necessary third parties, and only to the servers
they require for business purposes.
The greatest risks from traffic entering the
data center from the internet are inadvertently downloading malware
from an infected external client or inadvertently placing malware
on an external server if a client pulls data from a compromised
server in your data center. Protect traffic from the internet to
the data center so that you don’t inadvertently download malware
that takes advantage of server vulnerabilities or allow a client
to download malware from one of your company’s servers that could
infect partners, customers, or wind up on a website used by your
industry (serving a watering-hole attack).
Ensure that the
source of traffic to the data center doesn’t come from malicious
IP addresses or other potentially risky sources, and only allow
applications required for business purposes. Don’t allow unnecessary
(and especially unknown) applications in the data center. To do
these things:
- Create whitelist rules that control the sanctioned and allowed applications that external devices can use to communicate with your data center.Tag all sanctioned applications with the predefined Sanctioned tag. Panorama and firewalls consider applications without the Sanctioned tag as unsanctioned applications.
- Create an External Dynamic List to identify bad IP addresses and use it to prevent them from accessing your data center.
- Create a custom application for any proprietary application so that you can identify the application and apply security to it.If you have existing Application Override policies that you created solely to define custom session timeouts for a set a of ports, convert the existing Application Override policies to application-based policies by configuring service-based session timeouts to maintain the custom timeout for each application and then migrating the rule the an application-based rule. Application Override policies are port-based. When you use Application Override policies to maintain custom session timeouts for a set of ports, you lose application visibility into those flows, so you neither know nor control which applications use the ports. Service-based session timeouts achieve custom timeouts while also maintaining application visibility.
- Apply the full suite of Security Profiles to allow rules to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats.
- Log all allowed traffic.
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 sanctioned application traffic from vendors,
contractors, and customers, restricted to only the necessary applications.This rule shows how to secure application traffic arriving at the data center from external sources by tightly controlling the allowed application(s), allowing them only on the default port, and blocking sources that you know are bad using an External Dynamic List to identify known bad IP addresses.
![]()
To create this rule:- Prevent known bad sources from attempting to access the data center. Use the Negate option in the Security Policy rule Source Address to block connections from bad IP addresses. This example uses an External Dynamic List (Bad IPs List)) to identify known bad IP addresses and block them. (The strikethrough text in the source address indicates that it is negated rather than allowed.)
- Restrict the application(s) to only the application(s) required for business purposes and allow them to run only on their default ports (application-default) to prevent evasive malware from attempting to run on non-standard ports. In this example, the vendor uses a proprietary application called Acme. We created a custom application to identify the Acme proprietary application so that the firewall can classify the traffic and apply the appropriate Security policy.
- Restrict the destination for Acme application traffic to the Web-Servers dynamic address group in the Web-Server-Tier-DC zone. If the destination address isn’t in the web server tier, the firewall drops the traffic.
Verify that only the applications you explicitly whitelisted
in the security policy rules are running by viewing the predefined
Applications report (). 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.