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.
- 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.
- Configure tight data center best practice Security profiles to prevent threats from disrupting your data center network.
- On the DNS Signatures tab, change theActionon DNS Queries tosinkholeif 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 exceptsimple-client-informationalandsimple-server-informationaltosingle-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), clone the strict profile and modify it as needed. If files don’t need to flow in both directions, use theMonitorLogsData FilteringDirectionsetting to restrict the file type to only the required direction.
- Configure tight data center best practice Decryption profiles to prevent unknown traffic from entering your data center.
- SSL Protocol Settings: Set theMin VersiontoTLSv1.2, theMax VersiontoMax, and uncheck theSHA1Authentication Algorithm. (The weak 3DES and RC4 Encryption Algorithms are automatically unchecked when you select TLSv1.2.)
- SSL Forward Proxy: ForServer Certificate Verification, block sessions with expired certificates, untrusted issuers, and unknown certificate status, and restrict certificate extensions. ForUnsupported Mode Checks, block sessions with unsupported versions, unsupported cipher suites, and client authentication. ForFailure 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.
- 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 preventshadowing(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, configureLog at Session Endon theActionstab and set up Log Forwarding to track and analyze rule violations.
- Block all applications from user zones on theapplication-defaultport. Place this ruleafterthe rules that allow legitimate application traffic from user zones to identify unknown or unexpected user applications on standard ports.
- Block all applications from user zones onanyport to catch user traffic attempting to use non-standard ports. Place this rule after the precedingapplication-defaultblock rule to identify unknown or unexpected user applications on non-standard ports, which may be custom applications or evasive applications.
- Blacklist applications youneverwant 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 theFilesharing-Appfilterblocks all other file sharing applications.
- Block all applications fromanyzone on theapplication-defaultport 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.
- Block all applications from any zone onanyport 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.
- Blockunknownusers 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.
- 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, configureLog at Session Endon theActionstab 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.
- 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.
- 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.
- 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.
- 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, configureLog at Session Endon theActionstab 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.
- 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.
- 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.
- 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 that youchoosenot 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:For SSH privileged access:
- 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.
- 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.
- Apply a No Decryption profile to configure server verification for traffic that youchoosenot 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 theFin Serversaddress group.
- 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, configureLog at Session Endon theActionstab 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 theNegateoption to prevent communication with theBad IPs ListEDL.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.
- 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.Create Decryption rules to match traffic that internet-to-data-center Security policy rules allow.
- 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.
- Create a DoS Protection policy rule to specify the web servers you’re protecting and apply the classified DoS Protection profile to it.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 ofL3-External. Separate rules for external and internal attack sources provides separate reporting that makes investigating attack attempts easier.
- 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’sDirectioncontrol to block outbound update files so you only allow downloading for software update files.For each rule, apply best practice Security profiles and configureLog at Session Endon theActionstab.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-Serverscustom URL Category) using theyumapplication and with Microsoft update servers (Win-Update-Serverscustom URL Category) using thems-updateapplication (you must also allowsslbecausems-updatehas a dependency on SSL).
- Allow access to DNS and NTP updates (NTP DNS Update Serverscustom URL Category).
- 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.
- 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.
- 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.
- 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, configureLog at Session Endon theActionstab 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-AppandPayment-App.
- Allow finance application traffic between the web server tier and the application server tier.
- Allow finance application traffic between the application server tier and the database server tier.
- 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.
Recommended For You
Recommended videos not found.