Focus

Data Center Best Practice Security Policy

Create Data-Center-to-Internet Application Whitelist Rules

Table of Contents

Create Data-Center-to-Internet Application Whitelist Rules

Create whitelist rules that allow the appropriate data center servers to connect to update servers, certificate revocation servers, and other necessary servers on the internet, while preventing connections to illegitimate servers.

The main use case for data center servers initiating connections to external servers on the internet is to update software or to obtain certificate status. The greatest risk is connecting to the wrong server, especially for Linux updates because there are many third-party URLs to which you may inadvertently connect. Ensure that your data center servers receive updates from legitimate update servers, using only the required applications on their default ports.

To do this, create strict application whitelist rules that limit the external servers to which data center servers connect and the applications that data center servers use when connecting to external servers. Tag all sanctioned applications with the predefined Sanctioned tag. (Panorama and firewalls consider applications without the Sanctioned tag as unsanctioned applications.) A strict application whitelist disrupts potential attacks by:

Preventing malware that is already on a data center server from connecting to a compromised external server (phoning home) and downloading additional data because the whitelist rules don’t allow connections to those servers.
Preventing attackers from using legitimate applications such as FTP, HTTP, or DNS tunneling to exfiltrate data or using legitimate applications such as web-browsing on non-standard ports for command-and-control (C2) operations because the whitelist rules don’t allow data center servers to communicate with the internet using those applications. An additional way to help prevent exfiltration is to use the File Blocking profile’s Direction control to block outbound update files so you only allow downloading for software update files.

Create a strict whitelist rule for each application that requires software updates from a different set of external servers. In many cases, App-ID alone isn’t enough to protect data center servers. For example, for Linux server updates, it’s not enough to limit traffic to an update application such as yum or apt-get because that doesn’t prevent connecting to illegitimate servers. The best practice is to find the URLs that data center servers need to connect to, create custom URL categories (ObjectsCustom ObjectsURL Category) that specify the websites to use, and combine them with App-ID in Security policy rules. The combination of App-ID and custom URL categories locks down the external servers with which the data center servers can connect by preventing the use of illegitimate applications and preventing connections to update servers that aren’t in the custom URL category. For example, in a Security policy rule that allows data center servers to connect to CentOS update servers, you could create a custom URL category called CentOS-Update-Servers and add the CentOS update sites your servers use to the custom category.

To find out the URLs of legitimate Linux update servers and other update servers, work with software engineering, development operations, and other groups that update software to understand where they go to get updates. You can also log web browsing sessions, collect the URLs to which developers connect, and then take the URLs to engineering to filter out the right URLs for the Security policy.

Don’t use the URL Filtering Profile (PAN-DB URL Filtering) in Security policy rules for data center servers that communicate with the internet because you don’t want to allow all update servers. Restrict communication so that data center servers only reach out to the particular servers from which they retrieve updates.

In addition, all allowed communication should occur on the standard ports for each application. No applications should run on non-standard ports. As with all data center traffic, monitor whitelist violations because violations indicate either that you need to update the security policy to allow legitimate traffic or that an adversary is in or is attempting to enter the network.

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 data center servers to access software update servers.
This rule shows how to restrict access to software update servers on the internet so that data center servers communicate only with legitimate, known servers and don’t communication with other external update servers. This example allows engineering data center servers to access CentOS update servers and restricts communication to using only the necessary applications to establish connections to only the right set of update servers.
To create this rule:
- Restrict the source of CentOS update requests to only the data center servers that need to retrieve updates, in this example the Dev-Servers dynamic address group in the Engineering-DC-Infra zone.
- Restrict the application(s) that data center servers can use to communicate with external update servers to only the required application(s), in this example, yum for CentOS updates. Only allow the application(s) to run on the default port to prevent evasive malware from attempting to use non-standard ports.
- Create a custom URL category to define the URLs of the update servers to which the data center servers can connect. In this example, the CentOS-Update-Servers custom URL category defines the update server URLs that the data center servers can reach.
- Apply the full suite of Security Profiles to the rule to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats.
- Log update activity so that you can track and analyze violations of the rule, which may indicate an attempted attack.
This combination of restrictions also prevents attackers who have already compromised a data center server from reaching other destinations and using other applications to exfiltrate data or download additional malware.
Similarly, a rule allowing the same servers to communicate with Microsoft Windows update servers uses the same construction.
In addition to applying the best practice security profiles and logging traffic that this rule allows, the source zone and address are the same as in the preceding CentOS update rule. The differences are:
- The applications pertain to Microsoft updates. In addition to the ms-update application, Microsoft updates require the ssl application because ms-update depends on SSL. As with the CentOS update rule, only standard ports are valid.
  
  Some applications have dependencies on other applications. For a given application, you must allow all dependent applications or the application won’t work. You can filter applications (ObjectsApplications) to find application dependencies. For example, to find the SSL dependency for the ms-update application, filter on ms-update, click ms-update, and check the Depends on: field.
- The custom URL category (Win-Update-Servers) contains the URL for Windows updates so that contact with other URLs is denied.
Allow data center servers to access DNS and NTP update servers.
This rule shows how to restrict access to DNS and NTP update servers on the internet so that data center servers communicate only with legitimate, known servers. This example allows IT data center servers to access DNS and NTP update servers and restricts communication to using only the necessary applications to establish connections to only the right set of update servers.
To create this rule:
- Restrict the source of DNS and NTP update requests to only the data center servers that need to retrieve updates, in this example the DNS-NTP-Servers dynamic address group in the Engineering-DC-Infra zone.
- Restrict the applications that data center servers can use to communicate with these external update servers to only the required applications, in this example, dns and ntp. Allow the applications to run only on the default port to prevent evasive malware from attempting to use non-standard ports.
- Create a custom URL category to define the URLs of the update servers to which the data center servers can connect. In this example, the NTP-DNS-Update-Servers custom URL category defines the update server URLs that the data center servers can reach.
- Apply the full suite of Security Profiles to the rule to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats.
- Log update activity so that you can track and analyze violations of the rule, which may indicate an attempted attack.
Allow data center servers to access certificate authority servers to obtain the revocation status of digital certificates and ensure that they are valid.
This rule enables data center servers to connect to an Online Certificate Status Protocol (OCSP) Responder (server) on the internet to check the revocation status of authentication certificates. An OCSP Responder provides the most recent certificate status compared to browser Certificate Revocation List (CRL) updates, which depend on the frequency of CRL browser updates to keep up with certificate revocations, so the CRL is more likely to be out-of-date than an OCSP Responder. When you configure a certificate profile on the firewall, you can set up CRL status verification as a fallback method for OCSP in case the OCSP Responder is unreachable.
To create this rule:
- Restrict the source of certificate revocation check requests to only the data center servers that need to check certificate validation, in this example the IT-Server-Management dynamic address group in the IT-Infrastructure zone.
- Restrict the applications that data center servers can use to communicate with external certificate revocation servers to only the required applications. This example secures the connection between data center servers and OCSP Responders, so the only application to specify is ocsp. Allow the application to run only on the default port to prevent evasive malware from attempting to use non-standard ports.
- Apply the full suite of Security Profiles to the rule to protect against malware, vulnerabilities, C2 traffic, and known and unknown threats.
- Log activity so that you can track and analyze violations of the rule, which may indicate an attempted attack.

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.