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.
  1. 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.
    web-server-out-to-in-internet-dc-v2.png
    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 (
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