: Global Data Center Objects, Policies, and Actions
Focus
Focus

Global Data Center Objects, Policies, and Actions

Table of Contents
End-of-Life (EoL)

Global Data Center Objects, Policies, and Actions

Ensure that you can protect custom applications if you use them. Configure Security profiles and Decryption profiles and install Cortex XDR Agent on all data center endpoints.
  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 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.
      Allow traffic only to sanctioned DNS servers. Use the DNS Security service to prevent connections to malicious DNS servers.
    • 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
      Monitor
      Logs
      Data 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.) Use TLSv1.3 for traffic that supports TLSv1.3 (many mobile applications use certificate pinning, which prevent decryption when using TLSv1.3, so for these applications, use 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, except TLSv1.3 traffic (TLSv1.3 encrypts certificate information, so the firewall cannot block traffic based on certificate information). 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.
    • 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.
    • Block 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 allow rules so that, for example, you allow sanctioned file sharing applications before the
      Filesharing
      application filter blocks all other file sharing applications.
    • 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 an allow rule. Place this rule after the application allow rules and the preceding block rule.
    • 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 allow rules and the preceding block rule.
    • 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 allow rules and the preceding block rule.
    • In addition to blocking unwanted potentially malicious traffic, block Quick UDP Internet Connections (QUIC) protocol, unless for business reasons, you want to allow encrypted browser traffic. Chrome and some other browsers establish sessions using QUIC instead of TLS, but QUIC uses proprietary encryption that the firewall can’t decrypt, so potentially dangerous traffic may enter the network as encrypted traffic. Block both the QUIC application and UDP ports 80 and 443 to force the browser to use TLS. First create a Service (
      Objects
      Services
      ) that includes UDP ports 80 and 443:
      Use the Service to specify the UDP ports to block for QUIC. In the second rule, block the QUIC application so that the first two rules in your rulebase block QUIC:
  5. Install Cortex XDR Agent on all data center endpoints to protect against malware and exploits on the endpoints.
    Cortex XDR Agent protects all endpoints the same way, so the deployment process and malware protection policy best practices are the same for the data center as for any other network area.

Recommended For You