Describes the best-practices for integrating Threat Prevention into your network
deployment.
To monitor and protect your network from most Layer 4 and Layer
7 attacks, here are a few recommendations.
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.
If you have an active
Advanced Threat Prevention subscription, enable
Inline Cloud Analysis and Local Deep
Learning, where available, to block advanced C2 and spyware 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.
Defend against brute force attacks involving a large volume of requests/responses
from the same source or destination IP address, in an attempt to break into a
system. The attacker employs a trial-and-error method to guess the response to a
challenge or a request.
The Vulnerability Protection profile includes signatures to protect against brute
force attacks. Each signature has an ID, Threat Name, and Severity and is
triggered when a pattern is recorded. The pattern specifies the conditions and
interval at which the traffic is identified as a brute-force attack; some
signatures are associated with another child signature that is of a lower
severity and specifies the pattern to match against. When a pattern matches
against the signature or child signature, it triggers the default action for the
signature.
To enforce protection:
Create a Zone Protection profile that is configured to protect
against packet-based attacks ():
Select the option to drop Malformed IP
packets ().
Enable the drop Mismatched overlapping TCP segment option
().
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 ().
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 ().
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 ( > 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 ().
Disable the options to Forward datagrams exceeding
UDP content inspection queue and Forward
segments exceeding TCP content inspection queue ().
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 ().
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:
