Best Practices for Securing Your Network from Layer 4 and Layer 7 Evasions
Focus
Focus
Advanced Threat Prevention

Best Practices for Securing Your Network from Layer 4 and Layer 7 Evasions

Table of Contents

Best Practices for Securing Your Network from Layer 4 and Layer 7 Evasions

Where Can I Use This?
What Do I Need?
  • Prisma Access (Cloud Management)
  • Prisma Access (Panorama Managed)
  • NGFW (Cloud Managed)
  • NGFW (PAN-OS or Panorama Managed)
  • VM-Series
  • CN-Series
  • Advanced Threat Prevention or Threat Prevention License
To monitor and protect your network from most Layer 4 and Layer 7 attacks, here are a few recommendations.
  • Upgrade to the most current PAN-OS software version and content release version to ensure that you have the latest security updates. See Install Content and Software Updates.
  • Enable DNS Security (requires a Threat Prevention and DNS Security subscription license) to sinkhole malicious DNS requests. Palo Alto Networks recommends using the following DNS Security category configuration settings in your Anti-Spyware profile:
    • For the log severity settings, use the default settings:
    • For the policy action, set all signature sources to
      sinkhole
      .
    • For packet capture, set Command and Control Domains to
      extended-capture
      . Leave all other categories to default settings.
    For more information on related anti-spyware settings, see Best Practice Internet Gateway Anti-Spyware Profile.
  • If you have an active Advanced Threat Prevention subscription, enable Inline Cloud Analysis to block advanced C2 threats in real-time. The default action for each analysis engine is
    alert
    , which generates a threat log when a corresponding threat is detected; however, Palo Alto Networks recommends setting all analysis model actions to
    Reset-Both
    . This drops matching packets and sends an RST to the client and server, breaking the connection, as well as generating a threat log entry.
  • Set up the firewall to act as a DNS proxy and enable evasion signatures:
    DNS proxy is not part of the firewall security policy engine; instead, it directs the firewall to resolve DNS hostnames, while maintaining domain to IP mapping, which is crucial for preventing TLS/HTTP evasion.
    • When acting as a DNS proxy, the firewall resolves DNS requests and caches hostname-to-IP address mappings to quickly and efficiently resolve future DNS queries.
    • Evasion signatures that detect crafted HTTP or TLS requests can send alerts when clients connect to a domain other than the domain specified in the original DNS request. Make sure to configure DNS proxy before you enable evasion signatures. Without DNS proxy, evasion signatures can trigger alerts when a DNS server in the DNS load balancing configuration returns different IP addresses—for servers hosting identical resources—to the firewall and client in response to the same DNS request.
  • For deployments operating
    Prisma Access
    or networks without an internal DNS server, configure your DNS policy to use the Palo Alto Networks sinkhole IP address (72.5.65.111) instead of the default sinkhole FQDN (sinkhole.paloaltonetworks.com).
    The DNS sinkhole used by the Anti-Spyware Profile enables the firewall to forge a response to a DNS query for domains that match the category configured for a sinkhole action to the specified sinkhole server, to assist in identifying compromised hosts. When the default sinkhole FQDN is used, the firewall sends the CNAME record as a response to the client, with the expectation that an internal DNS server will resolve the CNAME record, allowing malicious communications from the client to the configured sinkhole server to be logged and readily identifiable. However, if clients are operating
    Prisma Access
    , are in networks without an internal DNS server, or using other software or tools that cannot be properly resolve a CNAME into an A record response, the DNS request is dropped, resulting in incomplete traffic log details that are crucial for threat analysis.
  • For servers, create Security policy rules to allow only the application(s) that you sanction on each server. Verify that the standard port for the application matches the listening port on the server. For example, to ensure that only SMTP traffic is allowed to your email server, set the Application to
    smtp
    and set the Service to
    application-default
    . If your server uses only a subset of the standard ports (for example, if your SMTP server uses only port 587 while the SMTP application has standard ports defined as 25 and 587), create a new custom service that includes only port 587 and use that new service in your security policy rule instead of application-default. Additionally, make sure you restrict access to specific source and destinations zones and sets of IP addresses.
  • Block all unknown applications and traffic using the Security policy. Typically, the only applications classified as unknown traffic are internal or custom applications on your network and potential threats. Unknown traffic can be either non-compliant applications or protocols that are anomalous or abnormal or it can be known applications that are using non-standard ports, both of which should be blocked. See Manage Custom or Unknown Applications.
  • Set Up File Blocking to block Portable Executable (PE) file types for internet-based SMB (Server Message Block) traffic from traversing trust to untrust zones (ms-ds-smb applications).
  • Block malicious variants of PE (portable executables), ELF and MS Office files, and PowerShell and shell scripts in real-time. Enabling WildFire Inline ML allows you to dynamically analyze files using machine learning on the firewall. This additional layer of antivirus protection complements the WildFire-based signatures to provide extended coverage for files of which signatures do not already exist.
  • Create a Zone Protection profile that is configured to protect against packet-based attacks (
    Network
    Network Profiles
    Zone Protection
    ):
    • Select the option to drop
      Malformed
      IP packets (
      Packet Based Attack Protection
      IP Drop
      ).
    • Enable the drop
      Mismatched overlapping TCP segment
      option (
      Packet Based Attack Protection
      TCP Drop
      ).
      By deliberately constructing connections with overlapping but different data in them, attackers attempt to cause misinterpretation of the intent of the connection and deliberately induce false positives or false negatives. Attackers also use IP spoofing and sequence number prediction to intercept a user's connection and inject their own data into that connection. Selecting the
      Mismatched overlapping TCP segment
      option specifies that PAN-OS discards frames with mismatched and overlapping data. Received segments are discarded when they are contained within another segment, when they overlap with part of another segment, or when they contain another complete segment.
    • Enable the drop
      TCP SYN with Data
      and drop
      TCP SYNACK with Data
      options (
      Packet Based Attack Protection
      TCP Drop
      ).
      Dropping SYN and SYN-ACK packets that contain data in the payload during a three-way handshake increases security by blocking malware contained in the payload and preventing it from extracting unauthorized data before the TCP handshake is completed.
    • Strip TCP timestamps from SYN packets before the firewall forwards the packet (
      Packet Based Attack Protection
      TCP Drop
      ).
      When you enable the
      Strip TCP Options - TCP Timestamp
      option, the TCP stack on both ends of the TCP connection will not support TCP timestamps. This prevents attacks that use different timestamps on multiple packets for the same sequence number.
  • If you configure IPv6 addresses on your network hosts, be sure to enable support for IPv6 if not already enabled (
    Network
    Interfaces
    Ethernet
    > IPv6
    ).
    Enabling support for IPv6 allows access to IPv6 hosts and also filters IPv6 packets encapsulated in IPv4 packets, which prevents IPv6 over IPv4 multicast addresses from being leveraged for network reconnaissance.
  • Enable support for multicast traffic so that the firewall can enforce policy on multicast traffic (
    Network
    Virtual Router
    Multicast
    ).
  • Disable the options to
    Forward datagrams exceeding UDP content inspection queue
    and
    Forward segments exceeding TCP content inspection queue
    (
    Device
    Setup
    Content-ID
    Content-ID Settings
    ).
    By default, when the TCP or UDP content inspection queues are full, the firewall skips content inspection for TCP segments or UDP datagrams that exceed the queue limit of 64. Disabling this option ensures content inspection for all TCP and UDP datagrams that the firewall allows. Only under specific circumstances—for example, if the firewall platform is not sized appropriately to align with a use case—could disabling this setting impact performance.
  • Disable the
    Allow HTTP partial response
    (
    Device
    Setup
    Content-ID
    Content-ID Settings
    ).
    The HTTP partial response option allows a client to fetch only part of a file. When a next-generation firewall in the path of a transfer identifies and drops a malicious file, it terminates the TCP session with an RST packet. If the web browser implements the HTTP header range option, it can start a new session to fetch only the remaining part of the file, which prevents the firewall from triggering the same signature again due to the lack of context into the initial session and, at the same time, allows the web browser to reassemble the file and deliver the malicious content. Disabling this option prevents this from happening.
    Allow HTTP partial response is enabled on the firewall by default. This provides maximum availability but increases the risk of a successful cyberattack. For maximum security, disable this option to prevent the web browser from starting a new session to fetch the rest of a file after the firewall terminates the original session due to malicious activity. Disabling HTTP partial response affects HTTP-based data transfers which use the RANGE header, which may cause service anomalies for certain applications. After you disable HTTP partial response, validate the operation of your business-critical applications.
    If you experience HTTP data transfer disruption on a business-critical application, you can create an Application Override policy for that specific application. Because Application Override bypasses App-ID (including threat and content inspection), create an Application Override policy for only the specific business-critical application, and specify sources and destinations to limit the rule (principle of least privilege access). Do not create Application Override policy unless you must. For information about Application Override policies, refer to https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClVLCA0.
  • Create a Vulnerability Protection Profile that blocks protocol anomalies and all vulnerabilities with low and higher severities.
    A protocol anomaly occurs when a protocol behavior deviates from standard and compliant usage. For example, a malformed packet, poorly written application, or an application running on a non-standard port would all be considered protocol anomalies, and could be used as evasion tools.
    If yours is a mission-critical network, where the business’s highest priority is application availability, you should begin by alerting on protocol anomalies for a period of time to ensure that no critical internal applications are using established protocols in a non-standard way. If you find that certain critical applications trigger protocol anomaly signatures, you can then exclude those applications from protocol anomaly enforcement. To do this, add another rule to the Vulnerability Protection Profile that allows protocol anomalies and attach the profile to the security policy rule that enforces traffic to and from the critical applications.
    Make sure that Vulnerability Protection Profile rules and security policy rules that allow protocol anomalies for critical internal applications are listed above rules that block protocol anomalies. Traffic is evaluated against security policy rules and associated Vulnerability Protection Profiles rules from top to bottom, and is enforced based on the first matching rule.
    • Begin by alerting on protocol anomalies:
      Create a Vulnerability Protection Profile rule with the
      Action
      set to Alert, the
      Category
      set to protocol-anomaly, and the
      Severity
      set to Any. Monitor your traffic to determine if any critical internal applications are using established protocols in non-standard ways. If you find this to be true, continue to allow protocol anomalies for those applications, and then block protocol anomalies for all other applications.
    • Block protocol anomalies:
      Create a Vulnerability Protection Profile rule with the
      Category
      set to protocol-anomaly, the rule
      Action
      set to Reset Both, and the
      Severity
      set to Any.
    • Optionally allow protocol anomalies for critical applications that use established protocols in a non-standard way. To do this, create a Vulnerability Protection Profile rule that allows protocol anomalies: set the rule
      Action
      to Allow, the
      Category
      to protocol-anomaly, and the
      Severity
      to any. Attach the Vulnerability Protection Profile rule to the security policy rule that enforces traffic to and from critical applications.
    • Add another rule to the Vulnerability Protection profile to block all vulnerabilities with low and higher severity. This rule must be listed after the rule that blocks protocol anomalies.
  • Continue to attach the following security profiles to your Security policy rules to provide signature-based protection:
    • An Anti-Spyware profile to block all spyware with severity low and higher.
    • An Antivirus profile to block all content that matches an antivirus signature.

Recommended For You