Create Data-Center-to-Internet Application Allow Rules
Create allow rules that enable 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
allow 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 allow rule set 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 allow 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 allow 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’sDirectioncontrol to block outbound update files so you only allow downloading for software update files.
Create a strict allow 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 ()
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 allow rule 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.
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 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 theDev-Serversdynamic address group in theEngineering-DC-Infrazone.
- 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,yumfor 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, theCentOS-Update-Serverscustom URL category defines the update server URLs that the data center servers can reach.
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.
The source zone and address are the same as in the preceding CentOS update rule. The differences are:- The custom URL category (Win-Update-Servers) contains the URL for Windows updates so that contact with other URLs is denied.
- The applications pertain to Microsoft updates. In addition to thems-updateapplication, Microsoft updates require thesslapplication because ms-update depends on SSL. As with the CentOS update rule, only standard ports are valid.Some applications depend on other applications. For a given application, you must allow all dependent applications or the application won’t work. The user interface shows application dependencies when you create a Security policy rule. For example, when you specify the ms-update application in the rule, the interface shows that ms-update depends on also allowing SSL:
ClickAdd to Current Ruleto add the selected application(s) to the rule.
You can also use the Search function () to find application dependencies. For example, to find the dependencies for the ms-update application, search forms-update, click thems-updateapplication in the resulting application list, and then check theDepends on:field.
- 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 theDNS-NTP-Serversdynamic address group in theEngineering-DC-Infrazone.
- Restrict the applications that data center servers can use to communicate with these external update servers to only the required applications, in this example,dnsandntp. 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, theNTP-DNS-Update-Serverscustom URL category defines the update server URLs that the data center servers can reach.
- 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 theIT-Server-Managementdynamic address group in theIT-Infrastructurezone.
- 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 isocsp. Allow the application to run only on the default port to prevent evasive malware from attempting to use non-standard ports.
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.
