R

AskF5 Home / K31591013

K31591013: BIG-IP AFM operations guide | Chapter 2: Packet ow

Operations Guide

Original Publication Date: Oct 09, 2018

Updated Date: Mar 11, 2020

Table of contents | << Previous chapter | Next chapter >>

Unlike a firewall, which filters traffic based on internal versus external interfaces, the BIG-IP AFM system
processes traffic through any non-management interface using the same ingress to egress packet flow
method. This means the packet processing is handled the same way, regardless of the BIG-IP AFM interface
being traversed.

Figure 2.1 provides an overview of the packet processing path as it traverses the BIG-IP AFM system.

Contents
Chapter sections
Packet flow in the BIG-IP system

Packet flow in BIG-IP hardware

Flow lookup
IP Intelligence hardware
DoS protection hardware

Packet flow in BIG-IP AFM software

Flow lookup
L2-L4 DoS protection
Listener lookup
IP Intelligence
Network Firewall

Post-L4 processing

Flow accept
L7 DoS protection
Protocol security
TMOS proxy

Dynamic signatures
Protocol inspection
 Protocol inspection staging, learning, and automatic updates
Different types of protocol inspections: Compliance checks and signatures
Operational concerns
Recommendations for protocol inspections that generate false positives
Multiple policy layers
Logging
Suggestions and confidence level

Figures
Figure 2.1: BIG-IP AFM packet processing
Figure 2.2: DoS Device Protection processing order
Figure 2.3: Per-VS DoS Profile processing order
Figure 2.4: Hardware packet processing
Figure 2.5: Software packet processing

Packet ow in the BIG-IP system

When a packet arrives at the ingress interface on a BIG-IP system, it is first processed by the embedded
Packet Velocity Accelerator (ePVA). The ePVA chip is a hardware-acceleration field programmable gate array
(FPGA) that delivers high-performance L4 IP throughput. The use of an FPGA allows the ePVA firmware to be
updated, as required, for future upgrades and hotfixes.

For more information about platforms, which include the ePVA chips, refer to K12837: Overview of the ePVA
feature.

For packets that are not handled by BIG-IP hardware, BIG-IP AFM software examines them in a series of
contexts. A context is the category of object to which a rule applies. Rules can be global, apply to all addresses
on the BIG-IP system that match the rule, or they can be specific, applying only to a specific virtual server, self
IP address, route domain, or the management port.

The BIG-IP AFM system has two flow tables:

The hardware flow table, which is maintained in the ePVA.

The software flow table, which is maintained by F5 TMOS.
 Figure 2.1 BIG-IP AFM packet processing

Figure 2.2 DoS Device Protection processing order

Figure 2.3 Per-VS DoS Profile processing order

Note: For easier viewing of these figures, you can right-click the image and open it in a new browser window.

Packet ow in BIG-IP hardware

Flow lookup
When a new packet is received, the BIG-IP system performs flow lookup by querying the hardware flow table.

The packet process flows in the following sequence:

1. If the BIG-IP platform uses ePVA hardware acceleration and the flow matches the hardware flow table,
then the packet is passed on to flow input for post-L4 processing, in the direction of egress.
2. If there is no match to an existing flow, the packet is processed for IP Intelligence and L2-L7 DoS
protection before being passed on to TMOS flow lookup.

IP Intelligence hardware
The ePVA is also used to process and implement IP Intelligence (IPI) rules to block malicious actors. If DoS
sweep protection detects a bad actor or group of actors, it can set an auto-blacklist. It can also signal the ePVA
to drop the offending IP addresses in hardware on some BIG-IP platforms so that they are not sent to software
for further processing.

DoS protection hardware

DoS attacks can also be mitigated in hardware. Many attack vectors such as bad headers, floods, and
fragmented packets are processed in hardware and mitigated using the ePVA chip. Mitigating these attacks
using hardware rather than software improves performance of the BIG-IP device.
 Figure 2.4 Hardware packet processing

Note: For easier viewing of this figure, you can right-click the image and open it in a new browser window.

For more information about hardware-processed attack vectors, refer to the Preventing Device DoS/DDoS
Attacks section of the BIG-IP AFM: DoS/DDoS Protection Implementations manual. For BIG-IP versions
prior to 15.0.0, refer to the BIG-IP Systems: DoS Protection and Protocol Firewall Implementations
manual.

Note: For information about how to locate F5 product manuals, refer to K98133564: Tips for searching AskF5
and finding product documentation.

Packet ow in BIG-IP AFM software

Flow lookup
During software flow lookup, the BIG-IP AFM system tries to match the packet to an entry in the software
connection flow table. There are two possible results:

If the packet does not match an existing flow, it is considered a new connection. TMOS then tests the
packet against L2-L4 DoS protection, listener lookup, IP Intelligence, and Network Firewall contexts.
If the packet matches a software flow connection table entry, TMOS sends it to flow input, bypassing the
flow lookup tests.

L2-L4 DoS protection

If an incoming packet exceeds the detection limit for that type of packet during L2-L4 DoS protection, the BIG-
IP system logs an attack message.

If an incoming packet exceeds the rate limit for that type of packet, the system drops it. DoS protection device
configuration and DoS profiles provide different vector protections; however, applying DoS protection device
configuration is essentially the same as applying a DoS protection profile at the global context.

Auto-blacklisting option

If you configure auto-blacklisting and packets exceed the rate limit, DoS protection triggers IP Intelligence to
block the source whether a packet is legitimate or part of an attack. (In BIG-IP 12.0.0 through 12.1.x, auto-
blacklisting is only available with the Single Endpoint Sweep vector.)

Listener lookup
Listener lookup checks to see if the packet's destination is valid.

If there is no listener at the packet destination address, the system drops or rejects the packet, depending on
your configuration.
IP Intelligence
IP Intelligence blocking can block requests from IP addresses that have questionable reputations.

IP Intelligence is applied to packets in the global, route domain, and virtual server contexts. A set of IP
Intelligence policies can be configured so that they can allow a packet to pass through at the global context
and the route domain context, but drop the packet in a virtual server context.

Network Firewall
The BIG-IP AFM Network Firewall provides policy-based access control to and from address and port pairs,
inside and outside of your network.

The Network Firewall uses the same three context settings as IP Intelligence: global, route domain, and virtual
server. In each context, the IP Intelligence packet handling occurs first, followed by the Network Firewall
handling:

IP Intelligence global context, then Network Firewall global context.

IP Intelligence route domain context, then Network Firewall route domain context.
IP Intelligence virtual server context, then Network Firewall virtual server context.

For more information about the Network Firewall, refer to Firewall rules.

Post-L4 processing
When the system routes packets to post-L4 processing, they arrive through flow input after passing through
hardware processing or through flow accept after passing through both hardware and software processing.

Flow accept
After the system decisively accepts or simply accepts a packet at the virtual server/self IP context, it reaches
flow accept, where it is recorded in the flow table and passes to the proxy for higher-level protocol processing.

L7 DoS protection
After the system accepts the flow, the BIG-IP AFM system evaluates any L7 DoS protection profiles applied to
the virtual server.

The BIG-IP AFM system includes L7 DoS profiles for DNS and SIP.

BIG-IP AFM 12.1 and later allows you to specify the L7 protocol you want to use. HTTP traffic allowed through
a firewall typically uses port 80, and malicious traffic often tunnels through this port. The L7 protocol option
allows you to specify the port you want to use, which doesn't need to be the customary application port. You
can restrict traffic to only that suited to that application to ensure that holes in the firewall are used only for
intended applications.

For more information about profiles, refer to Detecting and Preventing DNS DoS Attacks and Detecting SIP
DoS Attacks in BIG-IP System: DoS Protection and Protocol Firewall Implementations.

Note: For information about how to locate F5 product manuals, refer to K98133564: Tips for searching AskF5
and finding product documentation.

Protocol security
After L7 DoS protection profile processing, the system applies L7 protocol protection profiles, which are
available for HTTP and DNS profiles.

The protocol security profile for DNS determines which DNS queries are permitted.
The protocol security profile for HTTP performs protocol checks, length checks, checks request types (for
example GET and POST), and file types. The profile can also send a custom response page to any requests
blocked by the policy.

TMOS proxy
The system passes traffic to the proxy, where normal BIG-IP module processing occurs. This may include BIG-
IP ASM DoS vectors to enhance the other layers of DoS protection covered by the BIG-IP AFM system.

Figure 2.5 Software packet processing

Note: For easier viewing of this figure, you can right-click the image and open it in a new browser window.

Dynamic Signatures
L2-L4 DoS protection uses DoS vectors that do not change over time. These are considered static signatures.
In BIG-IP 13.0.0 and later, the Dynamic Signatures feature looks at traffic history and builds a statistical model
tracking over 3,000 separate categories. When the device is under stress, the system generates signatures for
significant deviations from historical norms and can alert and block traffic matching those signatures. Because
dynamic signatures are generally composed of multiple characteristics, they have the potential to be more
precise than static vectors, which look at only a single thing.

Protocol inspection
Protocol inspection adds an intrusion prevention system (IPS) to the BIG-IP AFM system. It allows the creation
of custom signatures that generally perform better than iRules equivalents and are easier to write. Protocol
inspection supplants protocol security because it is easier to extend to add new applications with a signature
update and makes it easier to mitigate particular security exploits better than iRules are able to.

To use the feature, you configure a Protocol Inspection profile with the DNS service and the compliance
checks and signature matching enabled, then you attach the profile to a virtual server. You can also invoke a
Protocol Inspection profile in the global context using a Network Firewall rule action.

Compliance checks are a positive security model in which the client the system drops specific traffic if it does
not meet specified conditions. Signature matching is a negative security model in which the system drops
traffic if it meets specified conditions.
Protocol inspection includes a dashboard and full BIG-IP Analytics and Application Visibility and Reporting
(AVR) support, including graphs of data on policy matches, individual inspection matches, attacks, and other
data.

Protocol inspection staging, learning, and automatic updates

Beginning in BIG-IP 14.0.0, protocol inspection includes automatic signature updates and usability features,
such as staging and automated learning. Automated learning allows the BIG-IP system to train itself based on
observed traffic and to provide suggestions. This enhancement makes it possible to identify signatures and
compliance checks that are useful to your environment without having to sift through false positives.

Di erent types of protocol inspections: Compliance checks and signatures

Compliance checks implement a positive security model. They define what is the system finds
acceptable and what it drops. This can stop unknown attacks that do not follow the approved protocol
specifications.
Signatures implement a negative security model. They define what is bad, which is infinite and therefore
impossible to cover completely. Signatures can be useful for specific remediation. They are similar in
concept to antivirus definitions and can be subject to the same grave limitations (polymorphism,
obfuscation, and so on).

Signatures versus iRules

iRules have long been used to mitigate known attacks but can be difficult to author and don't scale well. It is
not feasible to include large numbers of attack patterns in a single iRule.

Signatures are generally faster than iRules and easier to write and maintain. They are also potentially easier to
troubleshoot since protocol inspection is included in the set of obvious enforcement mechanisms.

Visibility is better with signatures. Neither iRules nor inspection signatures force you to log, but protocol
inspection statistics counters increment even without logging.

Operational concerns
Deployment of individual protocol inspections

A protocol inspection action should be Accept+Log until acceptance due to risk of dropped traffic from a false
positive. By default, many signatures and compliance checks are configured to drop traffic. If you enable these,
you may drop valid traffic, so be sure to bulk edit the inspections to set the action to Allow and only then bulk
enable them.

Managing false positives

False positives (signature or compliance check matches that were not caused by malicious traffic) are the
major operational challenge for implementing an intrusion prevention system like BIG-IP Protocol Inspection.
To address this challenge, F5 provides a Suggestion function that provides the user with guidance as to the
likelihood an inspection may generate false positives. This guidance is based on statistical history. Beginning in
BIG-IP 14.1.0, the learning process to gather these statistics and generate the guidance is continuously
updated rather than set permanently after the learning period is complete. The guidance is also heavily
weighted against the completeness of the historical record: by default, a one-week period is considered an
adequate sample upon which to base guidance.

Important: This guidance does not guarantee efficacy or accuracy of an inspection: it only provides the
likelihood of a false positives from an inspection. It does not provide information about the likelihood of false
negatives missing an attack. A signature that never matches due to an error in coding is recommended
because it never generates a false positive.

Recommendations for protocol inspections that generate false positives

 Disable protocol inspections that match benign traffic. This is an important part of tuning a configuration.
It improves performance and the signal to noise ratio of logging and reporting.
Optionally replace signature inspections with more accurately targeted custom signatures. Copy the
signature that is generating false positives and add more conclusive content checks to the custom
signature. Refer to the original in the Signature Description or Documentation settings. You can find
the signature definition in the /defaults/ips_snort_signatures.txt file. Search for the signature_id that
you are interested in.
Deploy protocol inspections more restrictively, only using them where they are relevant.
Consider that some compliance checks have user-configurable parameters which can be tuned to
reduce false positives.

Multiple Policy Layers

Be aware that a protocol inspection policy applied to a virtual server takes precedence over a policy invoked
through a firewall rule applied in the global context. You can think of the global context policy as a default,
subject to override.

Real-world experience with network firewall policies shows an overwhelmingly preference to use a single,
global policy rather than maintaining multiple customized policies at the virtual server or route domain level.
There is no significant performance penalty for doing so. With protocol inspection, there are more significant
benefits to using multiple policies for the protected objects. For example:

A few customized policies reduce the workload by applying only relevant signatures.
Policies applied to a virtual server to inspect traffic after the Client SSL profile decrypts it. Unencrypted
web traffic is becoming the exception, not the rule. Logging identifies the object context when an
inspection matches.

Logging
F5 recommends remote logging because the BIG-IP system is not optimized for heavy disk read/write
operations. Local logging is more demanding for protocol inspection than for other features. The following
describes the logging burden imposed by the different BIG-IP AFM mechanisms:

DoS can be configured to log locally when the volume is low (Attack started, Attack sample 1/sec with
stats collected over the interval, Attack stopped). The BIG-IP system can handle low-volume logging;
however, remote logging is still useful to consolidate security events in a single console.
Network firewall and IP intelligence use one-log-message-per-rule match (if the rule enables logging).
Aggregate log throttling in the security log profile can save system resources, at the cost of discarded
log messages. Remote logging is still useful for event consolidation and you do not lose information as
you may with rate-limited local logging.
Protocol inspection logs per-match of any signature or compliance check with logging enabled, by
default up to 10 messages per flow with no aggregate throttling implemented. You can reduce it to one
message per flow using a database key, but, with potentially millions of flows, this still can threaten the
stability of the BIG-IP system.
When logging to a remote system, consider enabling Log Packet Payload in the security log profile.
The analysis of the packet payload extracted from the logs can be crucial in determining whether an
event is a false positive or a real attack.

Suggestions and con dence level

The primary task for users of an IPS like BIG-IP AFM Protocol Inspection is managing false positives. If you
cannot review the alerts because there are too many of them, you may as well not have the IPS at all. The
problem is even worse if you block legitimate traffic. The system performs statistical analysis on traffic to
provide guidance as to which inspections may generate false positives. This guidance is provided in the form
of suggestions with an associated confidence value.
To help implement protocol inspection, the system offers suggested settings for each signature and compliance
check. These suggestions are based solely on traffic statistics and do not address the inherent accuracy of an
inspection. The suggestion has nothing to say about how good an inspection is at finding malicious traffic, it
just indicates how statistically likely the inspection is to generate a false positive. An extremely detailed,
sophisticated signature that never generates a false positive may still look suspicious to the system if it
generates a lot of hits relative to the normal traffic load.

The system uses statistics to determine how likely an inspection is to generate a false positive based on
whether the inspection has a match in the rolling 7-day baseline period. If it has no matches, that means it has
never generated a false positive. The BIG-IP system suggests enabling the inspection on that basis. This is the
single most significant factor in the analysis.

The system also considers factors such as the number of traffic sources. For example whether it involves a
one-to-one relationship, a one-to-many relationship, or a many-to-many relationship. the system also considers
the proportion of traffic that the signature match represents. The assumption is that attacks will not be a major
element of overall traffic, but this may not be a valid assumption for some attacks.

The confidence level primarily indicates how much of the baseline period has transpired. For example, if there
is an entire week of data to refer to, the confidence level will be 100 percent.

BIG-IP AFM operations guide

Chapter 1: Guide introduction and contents
Chapter 3: Firewall rules
Chapter 4: Network Address Translation (NAT)
Chapter 5: Denial of Service
Chapter 6: External tools
Chapter 7: Monitoring and Logging BIG-IP AFM
Chapter 8: Troubleshooting

Supplemental Information
About operations guides
Optimizing the support experience

Applies to:

Product: BIG-IP, BIG-IP AFM

15.X.X, 14.X.X, 13.X.X, 12.1.X