Deploy Data Center Best Practices

If you’re already familiar with Palo Alto Networks’ platform, this checklist streamlines deploying security best practices in your data center to safeguard your most valuable assets.
Implement data center best practices when you create Security profiles, Decryption profiles, Security policy rules, Authentication policy rules, and Decryption policy rules.
For Security, Authentication, and DoS policy rules, configure log forwarding to Panorama or external services to centralize logs for convenient viewing and analysis, with notifications.
  1. If your data center application inventory includes proprietary custom applications, then create custom applications for them so that you can specify them in Security policy.
  2. Configure tight data center best practice Security profiles to prevent threats from disrupting your data center network.
    • Configure the best practice Antivirus profile by cloning the predefined profile and changing the imap, pop3, and smtp decoder values to reset-both in the Action and WildFire Action columns.
    • Configure the best practice Anti-Spyware profile by cloning the predefined strict profile. On the Rules tab, enable single packet capture on low, medium, high, and critical severity threats for traffic you log. (For traffic you don’t log, apply a separate profile without packet capture enabled.)
      On the DNS Signatures tab, change the Action on DNS Queries to sinkhole if the firewall can’t see the originator of the DNS query (typically when the firewall is north of the local DNS server) so that you can identify infected hosts. DNS sinkhole identifies and tracks potentially compromised hosts that attempt to access suspicious domains and prevents them from accessing those domains. Enable extended packet capture on the sinkholed traffic.
    • Configure the best practice Vulnerability Protection profile by cloning the predefined strict profile and changing the Packet Capture setting for every rule except simple-client-informational and simple-server-informational to single-packet. If the firewall identifies a large volume of vulnerability threats and that affects performance, disable packet capture for low-severity events.
    • The predefined strict File Blocking profile is the best practice profile. If supporting critical applications prevents you from blocking all the file types the strict profile blocks (you can identify the file types used in the data center from data filtering logs at MonitorLogsData Filtering), clone the strict profile and modify it as needed. If files don’t need to flow in both directions, use the Direction setting to restrict the file type to only the required direction.
    • The predefined WildFire Analysis profile is the best practice profile. WildFire provides the best defense against unknown threats and advanced persistent threats (ATPs).
  3. Configure tight data center best practice Decryption profiles to prevent unknown traffic from entering your data center.
    • Perform CRL/OCSP checks to ensure that certificates presented during SSL decryption are valid.
    • SSL Protocol Settings: Set the Min Version to TLSv1.2, the Max Version to Max, and uncheck the SHA1 Authentication Algorithm. (The weak 3DES and RC4 Encryption Algorithms are automatically unchecked when you select TLSv1.2.)
    • SSL Forward Proxy: For Server Certificate Verification, block sessions with expired certificates, untrusted issuers, and unknown certificate status, and restrict certificate extensions. For Unsupported Mode Checks, block sessions with unsupported versions, unsupported cipher suites, and client authentication. For Failure Checks, blocking sessions if resources aren’t available is a tradeoff between the user experience (blocking may negatively affect the user experience) and potentially allowing dangerous connections. If you have to consider this tradeoff, also consider increasing the decryption resources available in the deployment.
    • SSL Inbound Inspection: For Unsupported Mode Checks, block sessions with unsupported versions and unsupported ciphers. For Failure Checks, the tradeoffs are similar to SSL Forward Proxy.
    • SSH Proxy: For Unsupported Mode Checks, block sessions with unsupported versions and unsupported algorithms. For Failure Checks, the tradeoffs are similar to SSL Forward Proxy.
    • Apply the No Decryption profile to traffic you choose not to decrypt because of regulations, compliance rules, or business reasons. Block sessions with expired certificates and untrusted issuers.
  4. Configure traffic blocking rules to deny traffic you know is malicious or isn’t needed for business purposes.
    Logging and monitoring block rules may reveal users and applications you didn’t know were on your network and that may be legitimate or may indicate an attack. The rule order in the Security policy rulebase is critical to prevent shadowing (traffic matching an allow or block rule before it can match the rule you intend the traffic to match). Some rules are almost the same but enable separate reporting for standard and non-standard ports or for user applications and applications from other sources. For each rule, configure Log at Session End on the Actions tab and set up Log Forwarding to track and analyze rule violations.
    • Block all applications from user zones on the application-default port. Place this rule after the rules that allow legitimate application traffic from user zones to identify unknown or unexpected user applications on standard ports.
      identify-unexpected-apps-on-default-port.png
    • Block all applications from user zones on any port to catch user traffic attempting to use non-standard ports. Place this rule after the preceding application-default block rule to identify unknown or unexpected user applications on non-standard ports, which may be custom applications or evasive applications.
      unexpected-application-on-any-port.png
    • Blacklist applications you never want in your data center, such as evasive and commonly exploited applications and applications not required for business. Place this rule after the application whitelist rules so that, for example, you allow sanctioned file sharing applications before the Filesharing-Appfilter blocks all other file sharing applications.
      block-bad-apps-user-to-dc.png
    • Block all applications from any zone on the application-default port to identify unexpected applications on standard ports. Rule matches may indicate potential threats or application changes that require modifying a whitelist rule. Place this rule after the application whitelist rules and the preceding block rule.
      identify-unexpected-apps-on-default-port-any-zone.png
    • Block all applications from any zone on any port to identify unexpected applications on non-standard ports. Don’t allow unknown-tcp, unknown-udp, or non-syn-tcp traffic. Place this rule after the application whitelist rules and the preceding block rule.
      unexpected-application-on-any-port-any-zone.png
    • Block unknown users attempting to run applications on any port to discover unknown users (gaps in User-ID coverage or attackers) and identify compromised devices (including embedded devices such as printers, card readers, and cameras). Place this rule after the application whitelist rules and the preceding block rule.
      discover-unknown-users.png
  5. Create application whitelist Security policy rules for user traffic to allow appropriate access.
    Place whitelist rules for user access at the top of the rulebase, before block rules, to prevent accidentally blocking legitimate traffic. For each rule, configure Log at Session End on the Actions tab and set up Log Forwarding to track and analyze rule violations.
    • Enable employee user access to internal corporate DNS servers. This rule allows any user because users access DNS services before they log in. The rule tightly controls the source zone, destination servers, and application, and applies Security profiles to the traffic.
      Block access to external DNS servers at the internet gateway to prevent DNS traffic from going out on the internet to public servers.
      dns-resources-sec-pol-rule-user-dc.png
    • Allow secured, privileged access to data center management interfaces for the necessary IT personnel. Restrict the rule to management interfaces (this example uses an address group to identify the devices and a custom service to identify the management ports) and the necessary applications, in this example, RDP, SSH, and SSL. Use a dedicated VLAN to separate management traffic from other traffic and place management interfaces on the same subnet.
      If the same IT user group also manages switches, routers, and other data center devices, add them to the destination and add their ports to the custom service so the rule secures traffic for connections to their management interfaces. If different IT groups manage different data center resources, create separate Security policy rules and corresponding Decryption and Authentication policy rules for each group.
      it-mgmt-sec-pol-rule-user-dc.png
    • Allow required access for employee user groups. These rules limit each user group’s (or user’s) access to the necessary applications and servers. This example limits an engineering user group’s access to only its development servers and applications.
      eng-resources-sec-pol-rule-user-dc.png
    • Allow targeted, limited access to contractors, partners, customers, and other third-parties. This example limits access for an SAP contractor group so the group can reach only the appropriate SAP database servers, using only the appropriate applications.
      sap-contractors-sec-pol-rule-user-dc.png
  6. Create Authentication policy rules for user traffic to authenticate data center access.
    For each user group or user for whom you create application whitelist rules, create an analogous authentication rule (except the DNS whitelist rule because DNS occurs before users authenticate to log in). For each rule, configure Log at Session End on the Actions tab and set up Log Forwarding to track and analyze rule violations.
    • Authenticate users who need specialized access. This example authenticates the IT personnel who need secure privileged access to manage data center servers from the preceding step’s whitelist rule. Because compromising the credentials of a privileged user hands an attacker the keys to your data center kingdom, require Multi-Factor Authentication (MFA) to protect against stolen credentials.
      If the same IT user group also manages switches, routers, and other data center devices, add them to the destination and add their ports to the custom service so the rule authenticates traffic for connections to their management interfaces. If different IT groups manage different data center resources, create separate Security policy rules and corresponding Decryption and Authentication policy rules for each group.
      it-mgmt-auth-pol-rule-user-dc.png
    • Authenticate employees with legitimate business reasons to access the data center. This example authenticates the engineering development user group from the preceding step’s whitelist rule.
      eng-resources-eng-auth-pol-rule-user-dc.png
    • Authenticate contractors, partners, customers, and other non-employee groups. Require MFA for non-employee groups to protect against credential theft at a third-party company. This example authenticates the SAP developers from the preceding step’s whitelist rule.
      sap-contractors-sap-auth-pol-rule-user-dc.png
  7. Create Decryption policy rules for user traffic to decrypt traffic you allow so the firewall can see, inspect, and apply Security policy to the traffic.
    For each Decryption policy rule, apply the appropriate best practice Decryption profile (SSL Inbound Inspection, SSL Forward Proxy, SSH Proxy, or No Decryption, including best practice SSL Protocol Settings for SSL Inbound Inspection and SSL Forward Proxy rules) to block weak protocols and algorithms and to verify server certificates. For each SSL Inbound Inspection rule, import the certificate of the of the data center server you are protecting with decryption.
    Exclude traffic from decryption only for these two reasons:
    • Traffic breaks decryption for technical reasons, such as a pinned certificate or mutual authentication. Add technical exclusions to the DeviceCertificate ManagementSSL Decryption Exclusion list.
    • Traffic that you choose not to decrypt because of business, regulatory, compliance, or other reasons, such as financial, health, or government traffic. Create policy-based decryption exclusions for traffic you choose not to decrypt.
    • Decrypt traffic from the previously created Security policy rule that allows IT privileged access to management servers. The Decryption policy rule and its associated Decryption profile differ depending on whether the IT group uses SSL (SSL Forward Proxy Decryption profile) or SSH (SSH Proxy Decryption profile) to access management ports.
      If the same IT user group also manages data center switches, routers, and other devices, add them to the destination and add the server certificates so the rule decrypts traffic for connections to their management interfaces. If different IT groups manage different sets of data center resources, create separate, tight Security policy rules and corresponding Decryption and Authentication policy rules for each group.
      For SSL privileged access:
      it-mgmt-decrypt-pol-rule-user-dc.png
      For SSH privileged access:
      it-mgmt-ssh-proxy-decrypt-pol-rule-user-dc.png
    • Configure SSL Inbound Inspection to decrypt allowed traffic from employee user groups. This example decrypts traffic from the analogous engineering development user group whitelist rule.
      engg-to-dev-servers-decrypt-pol-rule-user-dc.png
    • Configure SSL Inbound Inspection to decrypt allowed traffic from contractors, partners, customers, and other third-parties. This example decrypts traffic from the analogous SAP contractor user group whitelist rule.
      sap-contractors-to-servers-decrypt-pol-rule-user-dc.png
    • Apply a No Decryption profile to configure server verification for traffic that you choose not to decrypt because of business, regulatory, compliance, or other reasons, such as financial, health, or government traffic. This example shows how to exclude two groups of finance users from decryption when they access servers in the Fin Servers address group.
      finance-PCI-decrypt-pol-rule-user-dc.png
  8. Create application whitelist Security policy rules for internet-to-data-center traffic to control and secure partner, contractor, and customer access.
    Protect against downloading malware from an infected external client or placing malware on an external server from an infected data center server. Whitelist applications required for business purposes and create an External Dynamic List (EDL) to block bad IP addresses. For each rule, configure Log at Session End on the Actions tab and set up Log Forwarding to track and analyze rule violations.
    This example restricts the applications and destinations for internet-to-data-center traffic, and uses the Negate option to prevent communication with the Bad IPs List EDL.
    web-server-out-to-in-internet-dc-v2.png
    Create similar rules for traffic from the internet to other server groups (if allowed) and other applications. Make each rule specific to limit access to only the required applications and servers.
  9. Create Decryption policy rules for internet-to-data-centertraffic to decrypt allowed traffic.
    Configure SSL Inbound Inspection (and import the destination server certificates into the firewall) to decrypt partner, contractor, and customer traffic that Security policy rules allow for internet-to-data-center traffic. This example shows the Decryption policy for the preceding Security policy rule.
    internet-to-data-center-traffic-decrypt-pol-rule.png
    Create Decryption rules to match traffic that internet-to-data-center Security policy rules allow.
  10. Create internet-to-data-center DoS Protection policy rules to protect sensitive servers from Denial-of-Service (DoS) attacks by limiting the number of connections-per-second (CPS) the firewall allows to the servers to prevent a SYN flood attack.
    Attackers target the web server tier because if they take it down, they prevent most legitimate access to the data center. Apply a classified DoS Protection policy rule with a DoS Protection profile that limits the incoming CPS to prevent traffic spikes that can affect server performance and availability.
    • Create a classified DoS Protection profile to protect the web server tier and prevent SYN flood attacks. The CPS thresholds you set depend on the baseline peak CPS rate.
      internet-to-data-center-traffic-dos-protection-profile.png
    • Create a DoS Protection policy rule to specify the web servers you’re protecting and apply the classified DoS Protection profile to it.
      internet-to-data-center-traffic-dos-pol-rule-v2.png
      To protect against SYN flood attacks from internal sources, create a separate DoS Protection policy rule that specifies your internal zones as the source zone instead of L3-External. Separate rules for external and internal attack sources provides separate reporting that makes investigating attack attempts easier.
    • In addition, configure Packet Buffer Protection for each data center zone to protect the firewall from single-session DoS attacks that can cause legitimate traffic to drop.
  11. Create data-center-to-internet whitelist rules to protect connections to external servers.
    Data center servers may obtain software updates or certificate status from servers on the internet. The greatest risk is connecting to the wrong server. Create strict whitelist rules for updates to limit the reachable external servers and the allowed applications (on default ports only). This prevents infected data center servers from phoning home and prevents data exfiltration using legitimate applications such as FTP, HTTP, or DNS on non-standard ports. In addition, use the File Blocking profile’s Direction control to block outbound update files so you only allow downloading for software update files.
    For each rule, apply best practice Security profiles and configure Log at Session End on the Actions tab.
    Work with engineering and other groups that update software to log and analyze web browsing sessions to define the URLs to which developers connect for updates.
    • These examples allow engineering servers to communicate with CentOS update servers (CentOS-Update-Servers custom URL Category) using the yum application and with Microsoft update servers (Win-Update-Servers custom URL Category) using the ms-update application (you must also allow ssl because ms-update has a dependency on SSL).
      centos-update-server-sec-pol-rule-dc-internet.png
      win-update-server-sec-pol-rule-dc-internet.png
    • Allow access to DNS and NTP updates (NTP DNS Update Servers custom URL Category).
      dns-ntp-update-server-sec-pol-rule-dc-internet.png
    • Allow connecting to an internet Online Certificate Status Protocol (OCSP) Responder to check the revocation status of authentication certificates and ensure they are valid. When you configure a certificate profile on the firewall, set up CRL status verification as a fallback method for OCSP in case the OCSP Responder is unreachable.
      cert-update-server-sec-pol-rule-dc-internet.png
  12. Create data-center-to-internet Decryption policy rules to decrypt the traffic allowed in the preceding Security policy rules.
    A compromised update server could download malware and propagate it through the software update process, so decrypting traffic to gain visibility is critical. Because only service accounts initiate update traffic and update traffic has no personal or sensitive information, there are no privacy issues.
    Don’t decrypt traffic to OCSP certificate revocation servers because the traffic usually uses HTTP, so it’s not encrypted. In addition, SSL Forward Proxy decryption may break the update process because the firewall acts as a proxy and replaces the client certificate with a proxy certificate, which the OCSP responder may not accept as valid.
    • Decrypt traffic between data center and update servers. These two examples decrypt the CentOS and Windows update traffic allowed by the analogous Security policy rules in the preceding step.
      centos-update-server-decrypt-pol-rule-dc-internet.png
      win-update-server-decrypt-pol-rule-dc-internet.png
    • Decrypt traffic between data center servers and NTP and DNS update servers. This example decrypts the update traffic allowed by the analogous Security policy rule in the preceding step.
      dns-ntp-update-server-decrypt-pol-rule-dc-internet.png
  13. Create intra-data-center application whitelist rules to protect data center servers from other data center servers that may be compromised.
    A common application architecture consists of three server tiers: web servers, application servers, and database servers. Apply best practice Security profiles to most traffic between server tiers to prevent threats. Don’t apply Security profiles to low-value, high-volume traffic such as mailbox replication and backup flows—the firewall already inspected the original flows, so spending CPU cycles on them provides no extra value. Do create whitelist access rules for these applications to prevent misuse. For each rule, configure Log at Session End on the Actions tab and set up Log Forwarding to track and analyze rule violations.
    This example configures rules that allow traffic between application server tiers for two proprietary internal finance applications for which we created custom applications: Billing-App and Payment-App.
    • Allow finance application traffic between the web server tier and the application server tier.
      web-to-app-server-sec-pol-rule-intra-dc.png
    • Allow finance application traffic between the application server tier and the database server tier.
      app-to-db-server-sec-pol-rule-intra-dc.png
  14. Arrange the Security policy rules in the correct order so no rule shadows another rule and you allow only the applications you want to allow.
    Order the Data Center Security policy rulebase shows the full rulebase from the previous examples (whitelist and blocking rules) in the correct order and explains each rule’s placement.
  15. Install Traps on all data center endpoints to protect against malware and exploits on the endpoints.
    Traps protects all endpoints the same way, so the recommended Traps deployment process and malware protection policy best practices are the same for the data center as for any other network area.

Related Documentation