BIG-IP Advanced Firewall Manager Operations Guide (PDFDrive)

BIG-IP AFM Operations Guide
Unsurpassed Network Defense
Bringing together security and deep application

fluency, BIG-IP Advanced Firewall Manager
(AFM), delivers the most effective network-level
security for enterprises and service providers
alike.
CONTENTS
Contents
About This Guide 1
Before using this guide 1
Limits of this guide 1
Glossary 2
Customization 2
Issue escalation 2
Feedback and notifications 3
Configuration utility 3
Command-line syntax 3
Finding other documents 4
Introduction 5
BIG-IP AFM features 5
Packet Flow 7
Packet flow in BIG-IP hardware 7
Packet flow in BIG-IP AFM software 9
Post-L4 processing 10
Dynamic Signatures 11
Protocol Inspection 11
Firewall Rules 13
Network Firewall 13
IP Intelligence 15
Protocol security 17
BIG-IP AFM rules 19
BIG-IP AFM policies 21
BIG-IP AFM iRules 24
Rules and policies troubleshooting 27
Network Address Translation (NAT) 29

SNAT 31
NAT iRules 35
i
CONTENTS
Denial of Service 36
BIG-IP AFM DoS mitigations 37
Packet processing (SYN cookie protection) 43
Device DoS 45
BIG-IP AFM DoS vectors 47
DoS policy development 54
Dynamic Signatures 55
DoS reporting and visibility 58
Signaling and intelligence 61
External Tools 62
BIG-IQ Centralized Management 62
SNMP polling and alerting 64
Syslog 65
IPFIX 66
sFlow 67
Change and configuration management 67
Monitoring and Logging BIG-IP AFM 68

BIG-IP AFM monitoring 68
BIG-IP AFM logging 69
Troubleshooting 74
Troubleshooting traffic flow 74
BIG-IP AFM Network Firewall modes 78
Rule actions 83
Policy compilation 83
Logging 85
Statistics 87
Common troubleshooting tasks 89
Troubleshooting using BIG-IQ 92
Stateful failover using connection mirroring 94
DoS statistics output 95
IP Intelligence 96
ii
CONTENTS
Optimizing the Support Experience 98

F5 technical support commitment 98
F5 certification 99
Self-help 100
F5 training programs and education 103
Engage F5 Support 103
Legal Notices 114

Trademarks 114
Patents 114
Notice 114
Publication Date 115
Copyright 115
Change List 116
iii
FIGURES—
Figures
Figure 0.1: F5 documentation coverage 2
Figure 2.1: BIG-IP AFM packet processing 8
Figure 3.1: BIG-IP AFM Network Firewall processing flow 13
Figure 4.2: Inbound NAT 30
Figure 4.3: SNAT on same network using 172.16.0.0/16 32
Figure 4.4: SNAT used when BIG-IP is not the default route 33
Figure 5.1: Detection Threshold Packets Per Second 38
Figure 5.2: Detection Threshold Percentage 39
Figure 5.3: Packets exceeding the Internal Rate Limit are dropped. 39
Figure 5.4: Attack phase example 40
Figure 5.5: BIG-IP AFM DoS attack phases (Fast ramp) 40
Figure 5.6: BIG-IP AFM DoS attack phases (Slow ramp) 41
Figure 5.7: SYN cookie packet flow 44
iv
TABLES—
Tables
Table 0.1 Command-line syntax 3
Table 3.1 HTTP Protocol checks disabled by default 18
Table 3.2 HTTP Protocol checks guidelines 18
Table 3.3 FLOW_INT supported commands 25
Table 3.4 FLOW_INT actions 26
Table 5.1 DoS Logging fields 59
Table 6.1 Relevant BIG-IP AFM notifications to send to SNMP trap receiver 65
v
ABOUT THIS GUIDE—Limits of this guide
About This Guide

The goal of this guide is to help F5® customers keep their BIG-IP® system healthy, optimized, and performing as
designed. It was written by F5 engineers who assist customers with solving complex problems every day. Some
of these engineers were customers before joining F5, and their unique perspective and hands-on experience
serves the guides F5 customers have requested.
This guide describes common information technology procedures, as well as those which are exclusive to BIG-IP
systems. There may be procedures particular to your industry or business that are not identified. While F5
recommends the procedures outlined in this guide, they are intended to supplement your existing operations
requirements and industry standards. F5 suggests that you read and consider the information provided to find the
procedures to suit your implementation, change-management process, and business-operations requirements.
Doing so can result in higher productivity and fewer unscheduled interruptions.
Refer to “Feedback and notifications” for information on how to help improve future versions of the guide.
Before using this guide

To get the most out of this guide, first complete the following steps, as appropriate to your implementation:
• Install your F5 platform according to its requirements and recommendations. Search the AskF5™ (support.
f5.com) for “platform guide” to find the appropriate guide.
• Follow the general environmental guidelines in the hardware platform guide to make sure of proper
placement, airflow, and cooling.
• Set recommended operating thresholds for your industry, accounting for predictable changes in load. For
assistance contact F5 Professional Services (f5.com/support/professional-services).
• Familiarize yourself with F5 technology concepts and reviewed and applied appropriate recommendations
from F5 BIG-IP TMOS: Operations Guide.
Note For information about how to locate F5 product manuals, refer to AskF5 article: K12453464: Finding
product documentation on AskF5.
Limits of this guide

This guide does not focus on installation, setup, or configuration of your BIG-IP system or modules. There is a
wealth of documentation covering these areas in AskF5 (support.f5.com) The F5 self-help community, DevCentral™
(devcentral.f5.com), is also a good place to find answers about initial deployment and configuration.
The following figure shows where the F5 operations guides can best be applied in the product life cycle.
1
ABOUT THIS GUIDE—Issue escalation
Figure 0.1: F5 documentation coverage
Glossary
A glossary is not included in this guide. Instead, the Glossary and Terms page (f5.com/glossary) offers an up-to-
date and complete listing and explanation of common industry and F5-specific terms.
Customization
Customization may benefit your implementation. You can get help with customization from a subject matter expert,
such as a professional services consultant, from F5 Professional Services (f5.com/support/professional-services).
Issue escalation
Refer to Optimizing the Support Experience for issue escalation information.
If you have an F5 websupport contract, you can open a support case by clicking Contact support on AskF5
(support.f5.com)
2
ABOUT THIS GUIDE—Command-line syntax
Feedback and notifications

F5 frequently updates the operations guides and new guides may be released as needed. If you would like to be
notified when new or updated content is available, or if you have feedback, corrections, or suggestions to improve
this guide, email opsguide@f5.com. F5 internal users can file a request using Service-Now.
Configuration utility
The BIG-IP Configuration utility is the name of the graphic user interface (GUI) of the BIG-IP system and its
modules. It is a browser-based application you can use to install, configure, and monitor your BIG-IP system.
For more information about the Configuration utility, refer to Introducing BIG-IP Systems in BIG-IP Systems:
Getting Started Guide.
Command-line syntax
We show command line input and output in courier font. The corresponding prompt is not included. For example,
the following command shows the configuration of the specified pool name:
tmsh show /ltm pool my _ pool
The following table explains additional special conventions used in command-line syntax:
Table 0.1 Command-line syntax
Character Description
Identifies a user-defined variable parameter. For
<> example, if the command has <your name>, type in
your name but do not include the brackets.
[] Indicates that syntax inside the brackets is optional.
... Indicates that you can type a series of items.
TMOS Shell syntax
The BIG-IP system includes a utility known as the TMOS® Shell (tmsh) that you can use to configure and manage
the system at the command line. Using tmsh, you can configure system features and set up network elements.
You can also configure the BIG-IP system to manage local and global traffic passing through the system and view
statistics and system performance data.
You can run tmsh and issue commands in the following ways:
• You can issue a single tmsh command at the BIG-IP system command line using the following syntax:
tmsh [command] [module . . . module] [component] (options)
3
ABOUT THIS GUIDE—Finding other documents
• You can open tmsh by typing tmsh at the BIG-IP system command line:
(tmsh)#
At the tmsh prompt, you can issue the same command syntax, leaving off tmsh at the beginning.
Note You can use the command line utilities directly on the BIG-IP system console, or you can run
commands using a remote shell, such as the SSH client or a Telnet client. For more information about
command line utilities, refer to the Traffic Management Shell (tmsh) Reference Guide.
Finding other documents

For information about how to locate F5 product manuals, refer to AskF5 article: K12453464: Finding product
documentation on AskF5.
4
INTRODUCTION—BIG-IP AFM features
Introduction
BIG-IP® Advanced Firewall Manager™ (AFM™) delivers the most effective network-level security for enterprises and
service providers. Whether on-premises or in a software-defined data center, BIG-IP AFM tracks the state of
network sessions, maintains application awareness, and mitigates threats based on more attack details than
traditional network firewalls. BIG-IP AFM also protects your organization from aggressive distributed denial-of-
service (DDoS) attacks before they can reach your data center.
Uninterrupted data center services
BIG-IP AFM ensures traffic isn’t interrupted, even under the most intense attacks. It protects the data center and
the applications behind it. BIG-IP AFM scales to support millions of concurrent connections per second and
provides more hardware-based vectors than other network firewalls.
Deep attack visibility
BIG-IP AFM helps operators respond to threats quickly and with a full understanding of their security status. It
provides summaries of current attack events, customizable reports, in-depth logging of attack details, and
integration with Security Information and Event Management (SIEM) tools.
Comprehensive DDoS defense
DDoS attacks can enter the network on a variety of protocols—including known bad actors, malformed packets,
slow-and-low, and flood attack types. BIG-IP AFM uses the flexibility of the iRules scripting language,
sophisticated filtering, immediate blacklisting, and over a hundred built-in threat vectors to identify and mitigate
DDoS attacks.
Note “Distributed denial-of-service” (DDoS) is referred to generically as “denial-of-service” (DoS) in the

BIG-IP Configuration utility.
The majority of DDoS attacks exploit the transport and network layers. Layer 7 (L7) DDoS attacks are a
more sophisticated form of DDoS attack which mimic human behavior as they interact with the user
interface at the application level.
Consolidated and strong security
BIG-IP AFM combines with other BIG-IP solutions to enhance security capabilities. It eliminates the need for
single-point products that support application delivery, application security, client-side protections, user access,
and DNS security. That means increased efficiency and lower total cost of ownership.
BIG-IP AFM features

The following are the main features offered by BIG-IP AFM:
• App-centric policy enforcement unifies the application configuration with security parameters for tighter
policy enforcement.
5
INTRODUCTION—BIG-IP AFM features
• Intelligent control automatically guards against known bad actors at the earliest traffic flow point. In BIG-IP
AFM 12.1 and later, bad actor treatment is expanded to cover most DoS vectors to help select and disable
individual sources of malicious traffic. Each bad actor is handed off to IP intelligence and dropped for a
configurable period of time
• Layer-3 and layer-4 attack protection terminates all connections and runs checks to identify and mitigate
network-level threats before they reach the data center.
• Centralized management enables efficient deployment and management for a consistent and effective
security posture across an expanding set of firewall devices.
• High-volume logging controls log DDoS events, provide controls that prevent log servers from becoming
overwhelmed, and support SNMP, SIP, DNS, and IPFIX collectors.
• ScaleN Virtual Clustered Multiprocessing (vCMP) consolidates multiple firewalls onto a single device for
more flexible and isolated allocation of resources.
6
PACKET FLOW—Packet flow in BIG-IP hardware
Packet Flow
Unlike a firewall, which filters traffic based on internal versus external interfaces, BIG-IP® AFM™ 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 BIG-IP AFM.
Packet flow in BIG-IP hardware

When a packet arrives at the ingress interface on a BIG-IP system, it is first processed by 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 detailed information on platforms which include the ePVA chips, refer to AskF5™ article: K12837: Overview
of the ePVA feature.
Flow lookup
The system has two flow tables:
• Hardware flow table, which is maintained in the ePVA.
• Software flow table, maintained by F5®TMOS®.
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.
7
INGRESS EGRESS
Hardware Acceleration ePVA/Turboflex
Global SW Flow Table Lookup Hit

Per-VS IPI
IPI
Global DoS Global DoS Global DoS Global Per-VS Per-VS DoS Per-VS Dy-
Global DoS Per-VS DoS namic Signa-
Per-VS DoS Global DoS Static Vectors Static Vectors Single Single Global DoS Dynamic Static Vector DoS Single
Attacked Endpoint Endpoint Static Vector Signatures Static Endpoint tures
including DNS & SIP including DNS & SIP Bad Actor Bad Actor (L4BDoS)
Destination Flood Sweep (L4BDoS) Vectors Sweep
HW Flow Cache
Miss Hit
Lookup
SW Flow Table
Packet Filters L2 Global DoS Hit
Lookup
Global IPI Context Miss
On the HUD Chain (Unsorted, Partial List)

Global DoS Global DoS Global DoS Global DoS Global Dynamic
Static Vectors Static Vectors Single Endpoint Single Endpoint Global DoS Signatures
Attacked Static Vectors BIG-IP AFM SSH
Bad Actor Flood Sweep (L4BDoS) Protocol Inspection BIG-IP ASM DoS BIG-IP AFM NAT
Destination Proxy
Global Context Route Domain Per-VS DoS Per-VS DoS Per-VS Dynamic Per-VS
Advanced Route Domain Context Listener Lookup Per-VS IPI Static Vector Per-VS DoS Single Endpoint Signatures Advanced
Firewall Rules IPI Advanced Bad Actor Static Vectors Sweep (L4BDoS) Firewall Rules
Firewall Rules
Proxy
Legend
IPI DoS Firewall
Figure 2.1: BIG-IP AFM packet processing

PACKET FLOW—Packet flow in BIG-IP AFM software
For more detailed information on hardware-processed attack vectors, refer to BIG-IP Systems: DoS Protection
and Protocol Firewall Implementations Manual.
Packet flow in BIG-IP AFM software

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.
Flow lookup
At packet ingress, TMOS checks to see if the packet is associated with an already established flow. During
software flow lookup, BIG-IP AFM 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 - 12.1, 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.
Reject Unmatched Packets setting
By default, the BIG-IP system is set to reject unmatched packets.
9
PACKET FLOW—Post-L4 processing
To change the setting to Reject Unmatched Packets using the Configuration utility
1. Navigate to System > Configuration : Local Traffic : General.
2. Under Properties for Reject Unmatched Packets, clear the Enabled checkbox.
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 on 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
Once the system decisively accepts or simply accepts a packet at the virtual server/self IP context, it reaches flow
accept, where it’s recorded in the flow table and passes to the proxy for higher-level protocol processing.
L7 DoS protection
Once the system accepts the flow, BIG-IP AFM evaluates any L7 DoS protection profiles applied to the virtual
server.
BIG-IP AFM 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
10
PACKET FLOW—Protocol Inspection
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 detailed information on profiles, refer to DoS Protection and Protocol Firewall Implementations
Detecting and Preventing DNS DoS Attacks and DoS Protection and Protocol Firewall Implementations
Detecting SIP DoS Attacks.
Note For information about how to locate F5 product guides, refer to K12453464: Finding product
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 BIG-IP AFM.
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 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. Since 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
The Protocol inspection feature adds an Intrusion Detection/Prevention System (IPS) to BIG-IP AMF. 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
11
PACKET FLOW—Protocol Inspection
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 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.
12
FIREWALL RULES —Network Firewall
Firewall Rules
The BIG-IP® AFM™ Network Firewall uses rules to specify traffic handling actions. Rules are collected in policies,
which the system applies at the global context, to a route domain, to a virtual server, or to a self IP address. Rules
for the management port do not require a policy but are defined directly in the management port context.
The BIG-IP system itself provides some access control measures: it drops or rejects packets that do not match a
listener. Additionally, application profiles, such as SIP, add more limits regarding the type of permitted traffic.
BIG-IP AFM provides the following control features:
• Network Firewall provides full-featured access control lists (ACLs).
• IP Intelligence provides host-based controls paired with automation.
• Protocol Security provides fine-grained controls for the DNS and HTTP protocols.
Network Firewall
Figure 3.1: BIG-IP AFM Network Firewall processing flow
13
FIREWALL RULES —Network Firewall
As shown in the previous figure, packet flow arrives at the BIG-IP Network Firewall. The Network Firewall uses a
collection of network ACLs to process it.
BIG-IP AFM applies the global, route domain, virtual server, and self IP contexts to the packets in order, each
context looking for an ACL match.
If no match is found, the Global Default Firewall Action or the Virtual Server & Self IP Default Firewall Action is
triggered.
If the flow matches a configured virtual server but no ACLs match within this context, the Virtual Server & Self IP
Default Firewall Action is triggered.
Network firewall components
Network firewall ACLs are grouped into polices and those policies contain rules or rule lists.
Rules may include protocol, source address and port, source VLAN, destination address and port, schedule,
action, and logging. BIG-IP AFM can also assign an iRule and a service policy to an individual firewall rule, allowing
additional functionality to be added to the Network Firewall.
You can apply a service policy, such as an idle timeout, to an ACL match rather than to a listener. Doing this
enables you to customize a policy at a granular level without requiring a large number of configuration objects.
You can use iRules within a firewall rule to allow scripting to be applied when an ACL-match occurs. Used with the
FLOW_INIT event, you can change ACL actions or other early flow items. iRules can also be triggered for higher-
level events such as HTTP_REQUEST.
In order to make all of the firewall objects reusable, BIG-IP AFM includes a number of lists that can be used in the
policies.
Port list
The port list groups port numbers and port ranges. It contains a list of numbers that are not specific to any
protocol. For example, a list containing port 53 could be used to both TCP and UDP based DNS rules.
Address list
The address list contains IP addresses of a variety of types, including the following:
• Single host IP address
• Network CIDR block
• Geolocation match
• Nested address list
• FQDN (requires DNS resolver)
14
FIREWALL RULES —IP Intelligence
Rule list
The rule list is a grouping of individual rules.
F5 recommends using these lists for all aspects of rule creation. That is, all rules should be made up of address
and port lists and should only be created within a rule list. This practice simplifies administration in the long-term
by allowing groups of components to be used within rule lists or policies.
For more detailed information on rule lists, refer to BIG-IP Network Firewall: Policies and Implementations:
Firewall Rules and Rule Lists and BIG-IP Network Firewall: Policies and Implementations: Setting Timers
with Service Policies.
Note For information about how to locate F5 product guides, refer to AskF5™ article K12453464: Finding
Dual stack support
Beginning in BIG-IP AFM 14.0.0, the system supports dual stack management. IPv4 and IPv6 firewall rules can be
applied to the management port, which is not supported in previous versions. For configuration information, refer
to AskF5 article K12430: IPv4/IPv6 dual-stack support for the management interface.
IP Intelligence
IP Intelligence is a firewall protection, separate from the Network Firewall, which examines only the source address
of a packet. It is possible to create Network Firewall rules and policies to block on source and destination address,
but using IP Intelligence makes automation easier.
IP reputation subscription
An IP reputation database feed, provided by a third-party security vendor, serves as the first input source for IP
Intelligence.
F5 offers a built-in subscription that can be added to any existing BIG-IP AFM deployment.
Dynamic whitelist/blacklist
A dynamic whitelist/blacklist feed provides is another IP Intelligence input source. It allows BIG-IP AFM to
consume a custom feed of IP addresses to be enforced.
The dynamic whitelist/blacklist feed may come from external sources, including firewall logs, IPS alerts, or other
sources of known bad actors.
The format of the feed must contain an IP address and may contain several optional fields.
For more information refer to IP Intelligence in Network Firewall in BIG-IP Network Firewall: Policies and
Implementations.
15
FIREWALL RULES —IP Intelligence
Auto Blacklisting
Most BIG-IP AFM DoS vectors can identify and rate-limit individual bad actors. If the policy is set to block, the
BIG-IP system may automatically block IP addresses identified and categorized by IP Intelligence.
In BIG-IP 12.0, there is a limit of 100 bad actors on all platforms, with the exception of the VIPRION® 2250 blade,
because 100 is the maximum number of bad actors that the single endpoint Sweep vector can process.
The VIPRION 2250 blade implements IP Intelligence in hardware, so it can drop traffic from bad actors before DoS
Protection sees it, which allows the single endpoint Sweep vector to move on to another set of 100 bad actors on
that platform.
On all other platforms, IP Intelligence acts after software DoS Protection. In these cases, DoS Protection continues
to see traffic from the bad actors.
The order of operations in BIG-IP 12.1 causes IP Intelligence to act before software DoS Protection, which allows
IP Intelligence to scrub network traffic of packets from identified bad actors before software DoS Protection sees
it. As a result, software DoS Protection no longer sees traffic from identified bad actors and can move on to
identify another set of 100 bad actors.
In BIG-IP 13.0 and later, Bad Actor detection expands to most static vectors and is not confined to Single Endpoint
Sweep.
Manual blacklist entries

If you need to manually block an address, you can create a blacklist category to configure policy-based responses
to specific types of addresses. You can then assign a blacklist category to an IP address. This allows you to filter
addresses by category and to configure responses on a per-category basis.
To create a blacklist category
1. Navigate to Security > Network Firewall : IP Intelligence : Blacklist Categories.
The Blacklist Categories page opens.
2. Click Create to create a new IP Intelligence blacklist category.
3. In the Name field, type a name for the blacklist category.
4. In the Description field, type a description for the blacklist category.
5. Click Finished.
IP Intelligence whitelist
IP Intelligence uses a comprehensive whitelist feature. F5 recommends including critical infrastructure on it.
You can add whitelist IP addresses to your configuration automatically by setting up feeds and capturing them
with a feed list.
16
FIREWALL RULES —Protocol security
To create a feed list
1. Navigate to Security : Network Firewall : IP Intelligence : Feed Lists.
The Feed Lists page opens.
2. Click Create to create a new IP Intelligence feed list.
3. In the Name field, type a name for the feed list.
4. Configure Feed URLs with an HTTP, HTTPS, or FTP URL, the list type, the blacklist class, and the
polling interval. Specify a username and password, if required to access the feed list.
A feed URL includes the actual URL to the text file, and information about the defaults for that file.
Within the feed file, however, any URL can be configured to be a whitelist or blacklist entry, and
assigned to a blacklist class.
5. Click the Add button to add a feed URL to the feed list.
6. Click Finished.
Note The IP Intelligence whitelist only prevents IP Intelligence from dropping traffic from hosts included on
it: DoS and the Network Firewall do not honor the IP Intelligence whitelist and drop traffic from those entries
if their conditions to do so are met.
Classification for tracking
Use a custom category for classification by auto-blacklist to track the mechanism that classified the host. One
possible classification name is “auto-blacklist.” If several IP Intelligence policies are used, it may be useful to
identify those policies by unique classification names.
Classification for performance
Applying BIG-IP classification categories forces an iprepd lookup in the IP reputation database. This can
significantly slow performance. F5 recommends using custom categories for feed lists and auto-blacklist to avoid
performance degradation.
For information on configuring IP Intelligence, refer to Enabling IP Intelligence in BIG-IP Local Traffic Manager:
Implementations.
Protocol security
Protocol security allows restrict of application behavior for the DNS and HTTP protocols. Protocol Security profiles
are applied to application profiles which are applied to virtual servers.
DNS protocol security profile
A DNS protocol security profile provides a filter for DNS queries. Use the profile to specify the types of DNS record
17
FIREWALL RULES —Protocol security
queries which are allowed (or inversely, disallowed).
A DoS protocol security profile is applied to a Local Traffic DNS profile. It is a prerequisite for using DoS Protection
profiles for DNS.
HTTP protocol security profile
The HTTP Protocol Security profile offers protocol checks, request checks, and a blocking page to respond to
denied requests.
HTTP protocol checks
The following HTTP protocol checks are disabled by default. F5 recommends enabling them:
Table 3.1 HTTP Protocol checks disabled by default
HTTP Protocol Check Details

POST request with Content-Length: 0 A POST should always have non-zero length.
Body in GET or HEAD requests A GET or HEAD request should not have body.
Some HTTP protocol checks are only appropriate for particular web applications which may have clients that
exhibit unusual behavior.
To decide whether or not the HTTP protocol checks are suitable for your application, F5 recommends using the
guidelines in the following table:
Table 3.2 HTTP Protocol checks guidelines
HTTP Protocol Check Details

When an application handles text, a null character
generally indicates the end of the string. Data
coming after the null may represent an injection
Null in request body attack or other misbehavior. However, a client
request to upload binary data (for example, an
image file) triggers a false positive alert for this
check if it is enabled.
High ASCII may hide injected code which the
High ASCII characters in headers application might eventually map to regular ASCII.
It is highly unusual for a client to have a legitimate
need to do this. Unless such a client is used,
enable this check.
Most web applications (such as web browsers)
use a domain name in the Host header. IP
addresses are valid, but are commonly used by
Host header contains IP address
bots. Some mobile applications use IP addresses.
If the expected application traffic is entirely from
“normal” web browsers, enable this check.
By default, an HTTP protocol security profile triggers alarms but does not block traffic.
18
FIREWALL RULES —BIG-IP AFM rules
F5 recommends that you enable Block after a period of tuning your policy to avoid false positives.
Evasion techniques checks
Evasion techniques checks detect suspicious requests for URLs that are in complex formats. Such formats often
indicate an attempt to conceal the request from scrutiny by application firewalls and intrusion prevention.
For example:
/webroot/legit-directory/../../../etc/shadow
Other examples include the use of obscure encodings (multiple encoding, UNICODE, ASCII, and others). The web
server decodes these and may be ignored or misunderstood by security devices.
Some legitimate clients may present behavior that appears evasive. F5 recommends reviewing alarms to
determine a false positive rate and enabling blocking if that rate is acceptable.
Request checks
Requests checks options inspect requests. By default, the checks are set to trigger an alarm, not to block traffic.
Request Checks can be set to Alarm or Block, based on configuration.
• Length Checks: You can configure settings for URL length, Query String length, Request length, and POST
Data length.
F5 recommends alarming on these checks and enabling Blocking if the false positive rate is acceptable.
• Methods: You can select HTTP methods to accept (for example GET, HEAD, and POST).
F5 recommends blocking undesired request methods.
• File Types: You can select the file types to accept.

F5 recommends blocking requests for undesired file types.
• Mandatory Headers: You can select or create custom headers.

F5 recommends blocking requests that do not include mandatory headers.
Blocking page
The profile can return a blocking page in response to a blocked request. You can use the default response, create
a custom response, redirect to a URL, or use a Simple Object Access Protocol (SOAP) error message.
BIG-IP AFM rules
Rule tracking and commenting
F5 recommends the description fields to track rules. These fields include the name, identity, and login of the
person who created the rule, the date and time of rule creation, and change ticket or other system ID information, if
it exists.
19
FIREWALL RULES —BIG-IP AFM rules
Tracking can help determine change details, which is useful when a change generates an outage or needs to be
justified to an auditor, or simply as documentation for future operators.
For consistency and ease of use, F5 recommends using a predetermined, standardized format when entering this
data.
Rule efficiency
BIG-IP AFM 12.0 introduces performance optimizations for the rules compiler that can produce smaller, faster
compiled policies from previous versions of BIG-IP AFM. Complex rules with multiple lists and ports can now be
compiled more efficiently than previous versions.
Rule expiration
When creating standardized descriptions for firewall rules, consider adding an expiration date in the description
section, when applicable.
Expiration dates can assist during firewall audits and help to avoid leaving a temporary troubleshooting rule in
place that was intended to be used for only a short time period.
Note Rule expiration is not meant to be used as a function of the BIG-IP AFM expiration scheduling feature.
The expiration scheduling feature is a separate function, available within a firewall rule.
Redundant and conflicting rules
When creating firewall rules, it is possible a new rule can either overlap or conflict with an existing rule.
• Redundant rule: A rule which has address, user, region, or port information that completely overlaps with
another rule with the same action. Redundant rules should be removed to simplify policy management.
• Conflicting rule: A conflicting rule is a special case of a redundant rule, in which address, user, region or
port information overlaps with another rule, but the rules have different actions, and thus conflict.
Note A rule may be identified as conflicting with another rule, even if the result of applying the two is the
same. For example, two rules designed to accept packets and applied to the same IP address can be
identified as in conflict if one is configured to Accept and the other is configured to Accept Decisively.
Accept and Accept Decisively can lead to different behaviors based on the context and design of the
firewall rule set.
To view redundant and conflicting rules in the Configuration Utility
1. Navigate to Security > Network Firewall : Rules List.
2. Redundant or conflicting rules are indicated in the State column.
To view redundant and conflicting rules using tmsh at the command line
• Type the following command:
20
FIREWALL RULES —BIG-IP AFM policies
tmsh show security firewall policy POLICY _ NAME rules overlapping-status
Rule hit count
You can use Rule Hit Count to analyze rule usage as part of firewall maintenance. It can help diagnose stale rules
based on low or even zero usage, or the timestamp of the last hit time. You may consider resetting Rule Hit Count
for a targeted rule to zero and then waiting for a period of time to assist with determining if a rule has indeed
become stale.
To reset the stats of an individual global rule using tmsh at the command line
• Type the following command
tmsh reset-stats security firewall global-rules {enforced-policy-rules {

rule-5 }}
Beginning in BIG-IP AFM 14.0.0, per-context policy and rule hit counts and timestamps can be displayed for both
enforced and staged BIG-IP AFM policies. This data is also accessible using the SNMP MIB. There are also more
specific controls over the ability to reset statistics using tmsh, the Configuration utility, or iControl REST.
BIG-IP AFM policies

BIG-IP AFM policies are collections of rules or rule lists, applied in context.
Contexts
With the BIG-IP Network Firewall, you use a context to configure the level of specificity of a firewall rule or policy.
Firewall policies can be applied at the global, route domain, virtual server/self IP contexts.
Depending on your organization’s needs, you may prefer to put all active rules in a single policy applied at the
global context or apply firewall policies for specific virtual servers. The latter allows for application-specific policies
to be developed and applied only where required. When processing policies and rules on a virtual server, only
those specific to the application are processed.
Staging
Policies can be enforced or staged within a context. A staged policy logs rule matches and increment statistics but
does not take any enforcement actions.
A staged policy previews a policy’s effect if enforced. A staged policy can easily be promoted to enforced policy
once you’ve validated the policy’s effects.
Logged messages can be filtered by the keywords Staged and Enforced.
Compile and deploy policy changes
BIG-IP AFM allows multiple edits to a policy’s rules before you commit all the changes. By default, the changes
start compiling as soon as they are committed. However, you can set Firewall Compilation Mode to manual.
21
To change Firewall Compilation Mode to manual
1. Navigate to Security > Options : Network Firewall.
The Firewall Options page opens.
2. In the Firewall Policy Management section, for Firewall Compilation Mode, click Manual.
3. Click Update.
When Firewall Compilation Mode is set to Manual, changes to a firewall policy cause the policy to enter
Pending Rules Compilation status. This status line displays in the upper left-hand corner in the Configuration
utility.
To commit manual changes to a firewall policy
1. Click Firewall: Pending Rules Compilation.
2. Security, Event Logs, Network, Policy Status opens.
3. Click Compile.
4. Status line changes to Firewall: Pending Rules Deployment.
To deploy manual changes to a firewall policy
1. Click Deploy.
The following policy information displays:
• Firewall Policy Status: Consistent.
• Compilation Start Time: <start time>.
• Compilation End Time: <end time>.
• Last Successful Compilation Time: <time of deployment>.
• The status line changes to Firewall: Consistent.
If the Network Firewall Options for Firewall Policy Management is configured so that Log Configuration
Changes is set on and either Firewall Compilation Mode or Firewall Deployment Mode is set to Manual, the
following entries display as compilation and deployment progresses:
• Compilation Start
• Compile Success
• Deploy Start
• Deploy Success
22
Firewall compilation and deployment modes
Set the compilation and deployment mode to Manual to collect several rule changes, and then compile and
deploy them all at one time. F5 recommends turning the logging to On so that all policy changes are logged. This
assists with version control and roll back.
Warning: Large policy changes that are being compiled and deployed may put load on logging.
To set Firewall Compilation and Deployment modes
1. Navigate to Security > Options : Network Firewall. The Firewall Options page opens.
2. From the Firewall Compilation Mode list, click the compilation mode for the firewall rule set.
• Select Automatic to compile the firewall rule set whenever a change is made to any firewall item
that is used in the firewall rule set.
• Select Manual to delay compilation of the firewall rule set, collect all firewall rule changes, and
apply the entire set of changes manually at another time.
3. From the Firewall Deployment Mode list, click the deployment mode for firewall rule set changes.
• Select Automatic to deploy the firewall rule set whenever a change is compiled, either manually or
automatically.
• Select Manual to delay deployment of the firewall rule set, collect all compiled firewall rule set
changes, and deploy the entire set of changes manually at another time.
4. From the Log Configuration Changes list specify the logging option for firewall rule set
compilation and deployment configuration changes.
• Select Automatic to specify that configuration changes are logged only if Firewall Compilation
Mode or Firewall Deployment Mode is set to Manual.
• Select On to specify that policy configuration changes are always logged.
• Select Off to specify that policy configuration changes are not logged.
Validate rule sets
Requests to validate rules or policies occur frequently. Maintaining optimized firewall rule sets is a requirement for
an efficiently performing firewall.
As part of firewall maintenance, regularly validate expired rules, unused rules, conflicting rules, and rules not
ordered correctly.
23
FIREWALL RULES —BIG-IP AFM iRules
Review redundant, conflicting, and stale policy rules
View and remove redundant or conflicting rules to simplify the configuration and ensure that the system takes the
correct actions on packets.
To view and remove redundant and/or conflicting policy rules
1. Navigate to Security > Network Firewall : Active Rules.
The Active Rules page opens.
2. From the Type list, click Enforced or Staged policies, as appropriate.
3. View the firewall rule states in the State column.
Each rule is listed as Enabled, Disabled, or Scheduled. In addition, a rule can have one of the
states listed below. View and adjust rules with these states, if necessary.
• Redundant The rule is enabled, disabled, or scheduled, and redundant. All the functionality of
this rule is provided by a previous rule or rules. Hover over the State column to see why the rule is
considered redundant, and possible solutions.
• Conflicting The rule is enabled, disabled, or scheduled, and conflicting. All the match criteria of
this rule is covered by another rule or rules, but this rule has a different action. Hover over the
State column to see why the rule is considered conflicting, and possible solutions.
• Conflicting & Redundant The rule is enabled, disabled, or scheduled, and conflicting or
redundant with the actions of more than one other rule.
4. Resolve conflicting or redundant rules by editing, deleting, or disabling them. To edit, delete, or
disable a rule, click the name and complete the required action.
View and remove unused or infrequently used rules
The system must have staged or enforced rules configured on it, and the system must be processing traffic, to
determine whether rules are hit.
View unused rules to reduce firewall processing and simplify the rules, rule lists, and policies.
The BIG-IP AFM records the ACL hit count and the last hit time in the Configuration utility and tmsh for ease of
identifying unused or infrequently used rules.
BIG-IP AFM iRules

BIG-IP AFM provides support for iRules as another way to intercept and modify network traffic passing through
BIG-IP. BIG-IP AFM-specific iRules can be defined either inside a BIG-IP AFM firewall rule or by attaching these to
a virtual server.
24
If an iRule is defined within a firewall rule, it is called when the firewall rule is processed.
If the iRule is attached to a virtual server, the iRule is called after BIG-IP AFM firewall rules have been processed.
To create a new iRule using the Configuration utility
1. Go Local Traffic > iRules : iRules List : Create.
2. Enter a name for your iRule.
3. Enter your iRule in the Definition area.
4. Click Finished.
BIG-IP AFM iRules commands
FLOW_INIT supports the following commands:
Table 3.3 FLOW_INT supported commands
Command Action
Log Generates and logs specified messages.
Drop Drop packets (silently).
Reject Rejects packets (with RST packet).
Redirects to specified remote host, which could be another virtual server or
Node
pool member.
Virtual Redirects to the specified virtual server.
Pool – Directs the connection to the specified pool.
TCP::[close | respond] – Closes a TCP connection or sends the specified data directly to the peer.
IP::[client_addr|local_
Obtain the client IP address or the IP of the virtual server.
addr|tos|ttl|version] –
FLOW_INIT
BIG-IP AFM iRules can perform the same actions as firewall rules. You can use the FLOW_INIT event in BIG-IP
iRules to override an ACL action, to control bandwidth on client and server flows, and to route to another VIP.
FLOW_INIT is triggered once for TCP and unique UDP/IP flows.
For more information on iRule events refer to Master List of iRule Events on DevCentral™.
FLOW_INIT supports the following actions:
25
Table 3.4 FLOW_INT actions
Action Description
Default Uses the default action on the ACL rule
Drop Drops the connection
Reset Resets the connection
Allow Allows the connection and proceed to the next ACL
Allows the connection and bypass any further ACL. Allow-final is
Allow-final equivalent to Accept-Decisively.
BIG-IP AFM iRules logging
BIG-IP AFM event logs do not log iRules actions. Network firewall event logs and reporting pages only show the
actions of firewall rules in which iRules are nested.
If a firewall rule is configured to accept traffic but an iRule rejects the traffic, the event logs show the traffic as
Accepted.
To log iRules actions, you need to use statements:
• For local logging (var/log/ltm) use log local0.
• For remote HSL use the HSL iRule facilities HSL::open and HSL::send.
BIG-IP AFM iRules Sample
The following sample BIG-IP AFM “bypass” iRule allows a single IP address to bypass the BIG-IP AFM firewall and
log the occurring event to a remote syslog location.
when FLOW _ INIT {
set hsl [HSL::open -publisher /Common/hsl _ syslog _ pub]
set log _ format “Client IP address [IP::remote _ addr], Destination Port:

[TCP::local _ port]”
if { [IP::remote _ addr] equals “10.10.10.20” } {
HSL::send $hsl “[info hostname]|$log _ format| MSG: Pen Tester bypassing AFM rules”
ACL::action allow-final
26
FIREWALL RULES —Rules and policies troubleshooting
Rules and policies troubleshooting
Using daemons
There are daemons and commands available to help troubleshoot your firewall rules and policies:
• The iprepd daemon retrieves IP reputation databases using third-party subscriptions.
• The dwbld daemon retrieves feed lists configured and managed by the user. It logs to /var/log/dwbl/
dwbld.log. A db key governs the log level, but it does not add much detail to the output for this daemon.
To force a feedlist load using tmsh at the command line
• Type the following command syntax:
tmsh load /security ip feed <FEEDLIST NAME| ALL>
To see view the classification of an IP address using tmsh at the command line
tmsh show /security ip info address <IP ADDRESS>
To add a host to a classification using the Configuration utility
• Navigate to Security > Network Firewall : IP Intelligence : Black List Categories
To add a host to a classification using tmsh at the command line
tmsh run /security ip category name <CATEGORY> ip-ttl add { <IP ADDRESS> }
To delete a host from a classification, using tmsh at the command line
tmsh run /security ip category name <CATEGORY> ip-ttl delete { <IP ADDRESS>
}
Note If a host is listed under several classifications, you need to delete the host from every classification that
has an undesired policy action defined.
Example: 10.10.10.10 is classified under botnets and spam_sources, and both are dropped by the relevant
IP Intelligence policy. Deleting it from botnets does not affect its membership in spam_sources, and its
traffic is dropped by IP Intelligence.
You can also check /var/dwbl/.cache/* to see if the system is healthy. The cache is refreshed every cycle,
which should be every five minutes.
27
FIREWALL RULES —Rules and policies troubleshooting
Setting system db variables
If the BIG-IP system connects to the Internet using a forward proxy server, use the following commands to set
these system database variables.
To specify the host name of the proxy server using tmsh at the command line
tmsh modify sys db proxy.host value hostname
To specify the port number of the proxy server using tmsh at the command line
tmsh modify sys db proxy.port value port _ number
To specify the user name to log in to the proxy server using tmsh at the command line
tmsh modify sys db proxy.username value username
To specify the password to log in to the proxy server using tmsh at the command line
tmsh modify sys db proxy.password value password
To check the BIG-IP DNS client configuration using the Configuration utility
• Navigate to System > Configuration : Device : DNS.
Sending traffic to a specified virtual server using a Network Firewall rule
The BIG-IP system allows you to use matching criteria such as source and destination IP addresses and VLAN to
direct traffic to a specified virtual server.
Beginning in BIG-IP 13.0, you can use a Network Firewall rule to direct traffic to a virtual server. You can use any
matching criteria available to an ACL, such as geolocation, user id, and so on, as selection criteria for the virtual
server.
28
NETWORK ADDRESS TRANSLATION (NAT)—
Network Address Translation (NAT)

A Network Address Translation (NAT) is a mapping of one IP address to another IP address. This mapping can be
a translation of source, destination, or both. A NAT can be outbound or inbound.
Outbound NAT
Outbound NAT translates an internal source address to a public address. A NAT can also be used to translate an
internal node’s IP address to an Internet routable IP address.
Figure 4.1: Outbound NAT
Inbound NAT
Inbound NAT translates a public destination address to an internal address. When an external client sends traffic
to the public IP address defined in a NAT, BIG-IP translates that destination address to the internal node IP
address.
29
NETWORK ADDRESS TRANSLATION (NAT)—
Figure 4.2: Inbound NAT
To create NAT to allow translation of one IP address to another using the Configuration utility
1. Navigate to Local Traffic > Address Translation > NAT List.
A list of NATs on the system displays.
2. Click the Create button.
3. In the Name field, type a name for the NAT.
4. In the NAT Address field, type the IP address to use as the translation address, that is, the
address to which the origin address is translated.
5. In the Origin Address field, type the IP address of the node to which the translation is applied.
6. Configure the remaining settings or retain the default values.
Note A virtual server cannot be the origin address.
30
NETWORK ADDRESS TRANSLATION (NAT)—SNAT
To create a new NAT using tmsh at the command line
tmsh create /ltm nat <NAME> originating-address <IP ADDRESS> translation-

address <IP ADDRESS>
At the end of this task, the NAT appears in the list of NATs on the system.
To view pre-existing NAT configuration using the Configuration utility
• Navigate to Local Traffic > Address Translation : NAT List.
A list of NATs on the system displays.
To view a new NAT using tmsh at the command line
• Type the following command
tmsh show /ltm nat all
NAT can leverage IPv6, IPv4 or translate between the two for either the client or server side of the connection.
For more detailed information NATs and SNATs, refer to NATs and SNATs in BIG-IP TMOS: Routing
Administration.
Note For information about how to locate F5™ product guides, refer to AskF5 article: K12453464: Finding
SNAT
NAT, by design, is a one-to-one operation, while Secure Network Address Translation (SNAT) can be used to map
many IP addresses to one IP in order to hide the source IP network(s).
Inbound SNAT
In the most common client-server network configuration, the BIG-IP address translation mechanism ensures that
server responses return to the client through the BIG-IP system.
Clients and servers on the same subnet
To load balance requests to server nodes that are on the same subnet as the client nodes, create a SNAT so that
server responses are sent back through the BIG-IP rather than directly from the server node to the client node.
Otherwise, problems can occur such as the client (172.16.1.30) rejecting the response because the source of the
response (172.16.20.1) does not match the destination of the request (172.16.1.100).
31
Figure 4.3: SNAT on same network using 172.16.0.0/16
BIG-IP system is not server node default gateway
Sometimes a server’s default route cannot be defined to be a route through the BIG-IP system. This can cause
problems such as the client rejecting the response because the source of the response does not match the
destination of the request.
The solution is to create a SNAT. The BIG-IP system then translates the client node’s source IP address in the
request to the SNAT address, causing the server node to use that SNAT address as its destination address when
sending the response. This, in turn, forces the response to return to the client node through the BIG-IP system
rather than through the server default gateway.
32
Figure 4.4: SNAT used when BIG-IP is not the default route
Outbound SNAT
When an internal server initiates a connection to an external host, a SNAT can translate the internal source IP
addresses of one or more servers within the outgoing connection to a single, publicly routable address. The
external destination host can then use this public address as a destination address when sending the response. In
this way, the internal source IP addresses of the internal nodes remain hidden from the external host.
1. BIG-IP receives a packet from an internal server with an internal IP address and checks to see if that source
address is defined in a SNAT.
2. If the internal IP address is defined as the origin IP in SNAT, BIG-IP changes that source IP address to the
translation address defined in the configured SNAT.
3. BIG-IP then sends the packet, with the SNAT translation address as the source address, to the destination
host.
SNAT types
Standard SNAT
A standard SNAT is an object created using the BIG-IP Configuration utility that specifies the mapping of one or
more IP addresses to a translation address. For this type of SNAT, the criteria that the BIG-IP system uses to
decide when to apply the translation address is based strictly on the IP address. If a packet arrives from the IP
address configured in the SNAT, then the BIG-IP system translates that address to the configured translation
address. There are three types of standard SNATs:
33
• A SNAT with configured translation address.
• A SNAT that uses the automap feature.
• A SNAT configured to select an address from the SNAT pool as the translation address.
SNAT pool assigned as a virtual server source
This type of SNAT consists of just a SNAT pool directly assigned as a resource to a virtual server. This type of
SNAT can be implemented by creating a SNAT pool. Neither a SNAT object nor an iRule is required.
Intelligent SNAT
Like a standard SNAT, an intelligent SNAT is the mapping of one or more IP addresses to a translation address.
This type of SNAT mapping is implemented within an iRule instead of creating a SNAT object. For this type of
SNAT, the criteria that BIG-IP uses to decide when to apply a translation address is based on the logic of the iRule.
Port exhaustion
Each SNAT address has only 65,535 ports available. This is a limit of the TCP and User Datagram Protocol (UDP)
protocols, which use a 16-bit unsigned integer for source ports.
Port exhaustion or collisions may occur under heavy usage or unusually distributed client traffic patterns. For
performance reasons, the BIG-IP does not search exhaustively for an available source port. Port exhaustion may
occur well before all 65,535 ports are used. As a result, connections that cannot be translated due to lack of
available ports on a given translation address may be dropped.
To determine when SNAT port exhaustion is occurring by reviewing the system log files. When port exhaustion
occurs, BIG-IP logs messages to the /var/log/ltm file.
The following is an example of a port exhaustion log message:
01010201:2: Inet port exhaustion on 100.10.20.21 to 4.4.4.2:53 (proto 17) 01010201:2:

Inet port exhaustion on 100.10.20.21 to 23.73.217.114:80 (proto 6)
Mitigating port exhaustion

To mitigate port exhaustion, use a SNAT Pool. If already using a SNAT Pool, add more IP addresses to the pool.
Port mapping
When a SNAT is configured on the BIG-IP system (independently or in conjunction with a virtual server), the source
address of each connection is translated to a configured SNAT address, and the source port is mapped to a port
currently available for that SNAT address. By default, the BIG-IP system attempts to preserve the source port, but
if the port is already in use on the selected translation address, the system translates the source port.
34
NETWORK ADDRESS TRANSLATION (NAT)—NAT iRules
Figure 4.5: SNAT Port Translation Example
For more detailed information on SNAT, refer to AskF5 article: K7336: The SNAT Automap and self IP address
selection.
SNAT statistics
To monitor the number of concurrent connections going through the SNAT using the Configuration utility
• Navigate to Statistics > Module Statistics : Local Traffic : Statistics Type.
To monitor the number of concurrent connections going through the SNAT using tmsh at the command line
tmsh show /ltm snat
NAT iRules
iRules® can be used to create intelligent SNAT or to apply NAT to IP addresses that traverse a BIG-IP system.
The following is a sample iRule to apply NAT based on entries in a data group.
when CLIENT _ ACCEPTED {

set ip _ split [split [IP::local _ addr] %]
#log local0. “split $ip _ split”
set remote _ ip [lindex $ip _ split 0]
#log local0. “split remote is $remote _ ip”
set snat _ addr [class match -value $remote _ ip equals /All _ Firewalls]
#log local0. “IP: $remote _ ip SNAT: $snat _ addr”
if { $snat _ addr ne “” } {
#log local0. “IP: $remote _ ip SNAT: $snat _ addr”
snat $snat _ addr
}
}
For more detailed information and examples for iRules, go to DevCentral™.
35
DENIAL OF SERVICE—
Denial of Service
The BIG-IP® AFM™ system provides mitigation techniques against DoS/DDoS attacks.
Denial of Service (DoS) attacks are attempts to render a machine or network resource unavailable to its intended
users. Most network DoS attacks occur at OSI Layers 3, 4, or 7.
The attacks work by overwhelming the server resources by directing traffic at a particular IP address and/or port
with an inordinate amount of either legal traffic or malformed requests that exhaust available resources. For
example, targeting of the number of concurrent L4 connections or available bandwidth are just a couple of
common DoS attacks. The result is service denial to legitimate users.
Distributed denial-of-service attacks
Originally, a DoS attack might have been made by a lone attacker on a single computer targeting another
computer. Now an attacker can command hundreds of compromised computers, or zombies, in an array, called a
botnet, to launch a distributed denial-of-service (DDoS) attack. These DDoS attacks often simultaneously target
the victim’s firewall, DNS and other resources as well. These blended attacks may not be conducted by an
individual attacker. Online, loosely-organized communities work together to multiply the scope and complexity of
a DDoS attack.
Note “Distributed denial-of-service” (DDoS) is referred to generically as “denial-of-service” (DoS) in the

BIG-IP Configuration utility.
Symptoms of DoS/DDoS attacks
Symptoms of denial of service attacks may include:
• Unusually slow network performance (opening files or accessing web sites).
• Inability to access a web site or group of sites.
• Long-term denial of access to the web or any Internet services.
Types of DoS/DDoS attacks
While the DoS threat landscape is constantly evolving, attacks fall within four attack types:
• Volumetric: Flood-based attacks against layer 2, 3, 4, 5, or 7.
• Computational Asymmetric: Attacks designed to consume CPU cycles.
• Stateful Asymmetric: Attacks designed to abuse memory by invoking timeouts of session-state changes.
• Vulnerability-based: Attacks that exploit software vulnerabilities at any layer.
Attacks can be launched as a single attack or a combination of any of the listed typed.
36
DENIAL OF SERVICE—BIG-IP AFM DoS mitigations
BIG-IP AFM DoS mitigations

There are many possible strategies and architectures for mitigating DoS attacks. Some attacks are designed to
overwhelm the on-premises network pipe to affect the availability of all services residing at the location. Since the
volume of the attack is greater than the available network bandwidth to the location, these attacks are best
defended using off-site, cloud-based solutions such as F5® Silverline®: Cloud Based DDoS Protection or large
scale globally distributed architectures.
On-premises equipment is the second tier of DoS mitigation. While the volume of an attack may not be enough to
consume all available network resources, the attacker’s strategy is to consume enough resources to disrupt an
application or group of applications. The mitigation strategy in such cases is to provide capacity to absorb the
DoS while maintaining targeted service delivery goals.
Detecting and mitigating attacks
Using a combination of a robust, scalable operating system and the ability to offload many attack mitigations to
dedicated hardware, the BIG-IP system with BIG-IP AFM is capable of detecting and mitigating a wide range of
network-layer attacks to reduce the likelihood of downtime.
BIG-IP AFM detects attacks based on thresholds in packets per second (PPS) or by percentage deviations from
the previous hour’s baseline observed values. To mitigate attacks detected by these vectors, rate limiting can be
applied to devices violating the thresholds.
In BIG-IP AFM 12.1 and later, auto-thresholds can estimate baseline levels for you if you do not have the time or
ability to research them.
Attack vectors
The BIG-IP system classifies common types of DoS attacks into attack vectors. There are many different types of
attack vectors which have been designed to exploit different system vulnerabilities. The specific number and type
of attack vectors that BIG-IP AFM protects against depends on the BIG-IP TMOS version you’re using. F5 adds
additional attack vectors and configuration options as attack types evolve.
Each DoS attack vector contains settings to customize when BIG-IP AFM detects an attack has started, and when
BIG-IP AFM begins mitigating the attack by rate limiting attack packets.
Attack detection
Each BIG-IP AFM attack vector contains two configuration settings that can be used to recognize when a possible
attack has started against the device: Detection Threshold Packet Per Second (PPS) and Detection Threshold
Percentage.
Detection threshold packets per second (PPS)

Detection Threshold Packets Per Second is used as an early warning indicator that an attack may be occurring.
When the detection threshold is exceeded, BIG-IP AFM generates a log message of this event to notify you of the
condition. This setting is for attack detection only and is not used to mitigate attacks.
37
When an attack vector is enabled, BIG-IP AFM tracks statistics on how many packets arrive at the device related
to that vector. Packets are sampled once every second. This configured value is for the Traffic Management
Microkernel (TMM) instance, not a system total. Set this value based on your preference and the traffic-handling
ability of the application.
For more detailed information on TMM, refer to Ask F5 article K14358: Overview of Clustered Multiprocessing
(11.3.0 and later).
Figure 5.1: Detection Threshold Packets Per Second detects when configured threshold is exceeded
Detection threshold percentage

Detection Threshold Percentage is also used as an early warning indicator that an attack may be occurring. When
the detection threshold is exceeded, BIG-IP AFM generates a log message of this event to notify you of the
condition. This setting is for attack detection only and is not used to mitigate attacks.
When an attack vector is enabled, BIG-IP AFM compares the average rate of traffic related to that vector over the
last hour to the average rate of traffic over the last minute.
When the quotient between the average rate of traffic over the last hour and the average rate of traffic over the last
minute exceeds the threshold setting, BIG-IP AFM creates a log message and reports the PPS every second until
the traffic recedes below the threshold.
Note BIG-IP AFM must first collect three hours’ worth of traffic in order to create a value for the average
rate of traffic over the last hour. In addition the average rate must be above 100 PPS for this threshold to be
triggered.
This configured value is per TMM instance, not a system total. Set this value based on your preference and the
traffic handling ability of the application.
For more information on threshold limits for each TMM refer to Ask F5 article K15023: The BIG-IP AFM system
enforces configured thresholds and limits for each TMM.
38
Figure 5.2: Detection Threshold Percentage compares the average rate of traffic related to that vector over the last hour to the average rate of traffic
over the last minute
Attack mitigation
Each BIG-IP AFM attack vector can be configured to rate-limit traffic based on a specified PPS value.
Internal rate limit

Internal Rate Limit is used to specify an absolute PPS value which cannot be exceeded for traffic related to the
vector. Once the limit is reached, BIG-IP AFM begins dropping traffic which exceeds it. All packets exceeding the
threshold are dropped and continue to be dropped until the PPS rate falls below the configured rate limit.
The Internal Rate Limit configured value applies to each TMM instance, not to a combined system total. Set this
value based on your preference and the traffic handling ability of the application.
Figure 5.3: Packets exceeding the Internal Rate Limit are dropped. In this example, the Internal Rate Limit is set to 10000
Attack phases
There are four phases to a BIG-IP AFM DoS attack mitigation:
• DoS vector is enabled but no attack is present.
• Attack begins and BIG-IP AFM detects it.
39
• Attack is ongoing and BIG-IP AFM takes configured action.
• Attack is stopped by BIG-IP AFM and traffic returns to normal.
Figure 5.4: Attack phase example
BIG-IP AFM mitigation examples
Figure 5.5: BIG-IP AFM DoS attack phases (Fast ramp)
The previous figure models BIG-IP AFM detects a rapid increase (fast ramp) in packets using the Default
Threshold Percent to detect attacks and the Default Internal Rate Limit to mitigate. Detection Threshold set
to Infinite.
40
Vector mitigation is enabled and the rate of packets for the vector maintains an
Phase 1
average of 500 PPS. No attack present.
Event threshold begins with a flood of packets arriving that match the vector. Attack
Phase 2 is detected once the volume of packets crosses the Detection Threshold
Percentage.
BIG-IP AFM logs the packet rate for the detected DoS vector once every second per
TMM. The packet rate continues to increase very quickly (within a few minutes) until it
has exceeded the Default Internal Rate Limit. At this point, BIG-IP AFM begins to
Phase 3 rate limit all packets for this DoS vector above the 10000 PPS threshold. BIG-IP AFM
rate limits packets until the rate drops below the Default Internal Rate Limit. Once
the rate drops below the Default Internal Rate Limit, BIG-IP AFM stops dropping
packets, but logging continues every second the PPS rate for the detected vector.
PPS drops below the Detection Threshold Percentage. BIG-IP AFM stops logging
Phase 4
packets and changes the attack state to none.
Figure 5.6: BIG-IP AFM DoS attack phases (Slow ramp)
41
The previous figure models BIG-IP AFM detects a slow increase (slow ramp) in packets.
Phase 1 Vector mitigation is enabled. No attack present.

Over several hours the number of packets steadily increases, which in turn increases
Phase 2 the Average Rate Over Last Hour statistic. BIG-IP AFM observes and updates.
Phase 2 begins when the packet rate crosses the Detection Threshold PPS.
BIG-IP AFM checks the PPS every second and logs the DoS attack vector event
messages. The rate continues to steadily increase over several hours. This increases
the Average Rate Over Last Hour. The slow rise in PPS prevents the Detection
Phase 3
Threshold Percentage increase from triggering. Eventually the packet rate exceeds
the default internal rate limit and BIG-IP AFM begins to rate limit all packets above
that level until the packet rate drops below the rate limit threshold.
When the attack PPS drops below the rate limit threshold, BIG-IP AFM stops rate-
Phase 4 limiting packets. If the attack is still ongoing BIG-IP AFM continues to log event
information every second until the rate drops below the Detection Threshold PPS.
For more information on using BIG-IP AFM to reduce the impact of DoS attacks, refer to The F5 DDoS Protection
Reference Architecture.
Architecture
DoS configuration occurs either at the device level or the virtual server level. Device DoS configuration is designed
to detect and mitigate network layer DoS attacks across all services protected by the BIG-IP AFM.
DoS profiles configured and applied to the virtual server level usually are applied to detect and mitigate attacks to
a particular application or group of application servers.
Both virtual server and device DoS protection statistics are processed and counted. Global DoS configuration is
applied first then virtual server detection and mitigation thresholds. Attacks dropped at the virtual server are still
counted against the device threshold count.
DoS profiles designated to be applied at the virtual server level offer a subset of the overall DoS attack vectors.
Some DoS vectors can only be configured at the device level. Counters can count against both when determining
thresholds for detection and mitigation.
Note DoS Profiles thresholds values are enforced for the device as a whole not per TMM. For more
information refer to Ask F5 article K15023 The BIG-IP AFM system enforces configured thresholds and limits
for each TMM.
DoS profiles for SIP require that a SIP protocol profile be applied on the virtual server. Likewise, DoS profiles for
DNS require a DNS protocol profile and a DNS protocol protection profile be applied on the virtual server.
To reduce the requirements of the operating system (TMOS) processing attacks and maximize system resources,
many DoS vectors are offloaded into programmable FPGA hardware.
For more information on which vectors are processed in hardware refer to Detecting and Preventing System
DoS and DDoS Attacks in BIG-IP Systems: DoS Protection.
42
DENIAL OF SERVICE—Packet processing (SYN cookie protection)
Note For information about how to locate F5™ product guides, refer to AskF5 article: K12453464: Finding
Whitelisting
DoS whitelists provide a mechanism to configure trusted networks, protocols, and VLANs to bypass DoS checks
and mitigations.
In BIG-IP TMOS 12.0 and later, the DoS whitelist is limited to eight (8) entries. They can be based on source and/or
destination of hosts, networks, or VLANs. They include network protocols with or without specific ports, or
combinations of these settings. Use of super nets and larger masks to white list traffic or ingress VLANs is
typically more efficient due to the limit on entries.
To configure a white list entry using the Configuration utility
1. Navigate to Security > DoS Protection : White List.
2. Click Create.
The New Configuration page displays.
3. Fill in the white list entry as appropriate.
4. Click Finished.
To configure a white list entry using TMOS® Shell (tmsh) at the command line
tmsh modify /security dos network-whitelist dos-network-whitelist entries

add { ha-whitelist { source { vlans 2000 } } }
Packet processing (SYN cookie protection)

The BIG-IP AFM SYN cookie feature protects the system against SYN flood attacks by allowing the BIG-IP system
to continue to establish connections when the SYN queue begins to fill up during an attack.
When the SYN Check Activation Threshold value is reached, the BIG-IP system responds to SYN requests by
sending back to the client the SYN+ACK response containing an encoded secret. The system then discards the
SYN queue entry and waits for a correctly constructed ACK from the client before establishing an entry in the
connection table.
The SYN cookie secret can be calculated in hardware or software depending on the platform. This behavior can
be modified by adjusting the value for the SYN cookie algorithm database key.
For more detailed information on connection SYN Cookies, refer to AskF5™ article: K16500: Overview of the
connection.syncookies.algorithm database key.
When the SYN cookie authentication method is active for a virtual server or self IP address, established
43
DENIAL OF SERVICE—Packet processing (SYN cookie protection)
connection/packet handling and high-availability features such as mirroring should perform normally.
SYN cookie operation
Figure 5.7: SYN cookie packet flow
When SYN cookie protection is enabled for the protocol profile, the feature operates as follows:
1. A client sends a TCP SYN request to the BIG-IP virtual server or self IP address.
2. The receiving Traffic Management Microkernel (TMM) instance determines whether to enable hardware or
software SYN cookie protection as follows:
• If the platform contains the high speed bus (HSBe2) chip, and hardware SYN cookie protection is enabled in
the profile, TMM notifies the HSB chip and other TMM instances in the cluster to enable hardware SYN
cookie protection. The HSB chip and receiving TMM instance then programs HSB hardware for hardware
SYN cookie generation and validation for the virtual server or self IP address, and synchronize the status to
all TMM instances in the cluster.
• For TCP and FastHTTP profiles, if the platform does not contain the HSB chip, or hardware SYN cookie
protection is disabled in the profile, the TMM notifies other TMM instances in the cluster to enable software
SYN cookie protection.
• For FastL4 profiles, if the platform does not contain the HSB chip, or hardware SYN cookie protection is
disabled, SYN cookie protection is not available for the virtual server unless the software SYN cookie
protection option is specifically enabled.
3. The BIG-IP system sends the SYN+ACK response back to the client, but discards the SYN queue entry. The
BIG-IP system does not maintain the SYN-RECEIVED state that is normally stored in the connection table
for the initiated session. Because the system does not maintain the SYN-RECEIVED state for the
44
DENIAL OF SERVICE—Device DoS
connection, the SYN queue is not exhausted, and normal TCP communication continues.
4. If the BIG-IP system then receives a subsequent ACK response from the client, the system reconstructs the
SYN queue entry by decoding data in the TCP sequence number.
5. After the BIG-IP system validates the client’s ACK, the system adds the session to the connection table and
initiates a connection to the pool member.
For more detailed information on SYN cookie protection refer to AskF5 article: K14779: Overview of BIG-IP SYN
cookie protection (11.3.x - 12.x) .
To validate SYN Cookie performance in hardware or software issue using tmsh at the command line
tmsh show /ltm virtual <VIRTUAL>
tmsh show /ltm virtual vip1
Output appears similar to the following example:
SYN Cookies
Status full-hardware
Hardware SYN Cookie Instances 1030
Software SYN Cookie Instances 0
Current SYN Cache 0
SYN Cache Overflow 5
Total Software 6
Total Software Accepted 0
Total Software Rejected 16
Total Hardware 19.1K
Total Hardware Accepted 1030
Device DoS
Device-level DoS protection allows BIG-IP AFM to detect and automatically mitigate DoS attacks.
Various detection options are available, including a packets per second threshold, rate increase, rate limit, and
other parameters for DoS attack types.
For more detailed information on each attack type, refer to Detecting and Preventing System DoS and DDoS
Attacks in BIG-IP Systems: DoS Protection and Protocol Firewall Implementations.
45
DENIAL OF SERVICE—Device DoS
Detect and rate limits thresholds
There are three categories of vectors, based on the confidence with which packets can be regarded as useless or
malicious:
• Invalid packets (bad header*, fragmentation, IP unknown protocol, land attack, and others.)
• Probably invalid packets (TCP RST, TCP SYN-ACK, and TCP Push)
• Presumably valid packets (TCP SYN, TCP ACK, and UDP)
The detection and rate limit properties of these categories and vectors can be set with the following ranges:
• Invalid Packets: MINIMUM (1-100pps)
• Probably Invalid Packets: LOW (100-500pps)
• Presumably Valid Packets: HIGH (1000+pps)
The values vary depending on BIG-IP platform and environment, as well as whether the vector type is configured
through DoS device configuration or a DoS profile:
DoS Device Configuration settings should be set at the level required to protect the stability of the BIG-IP
system. Packets that are presumed to be valid should only drop in an emergency since this action affects every
virtual server on the BIG-IP system.
DoS Profiles are applied to virtual servers. This configuration places the mitigation with the target, so rate limiting
may drop legitimate traffic, it limits the mitigation effects to the virtual server under DoS attack. It is also likely that
the server pool members associated can tolerate less overall stress than the BIG-IP system.
F5 recommends setting a lower detect and rate limit for DoS profiles to protect pool members.
Invalid packets
Invalid packets are those which violate protocol specifications. This includes bad header vectors.
While standard TMOS packet handling silently drops invalid packets, it can be more efficient to allow BIG-IP AFM
DoS to handle them earlier to reduce TMOS workload.
DoS also allows you to configure alerts to your preference. You can configure DoS detection and rate limiting
depending on whether you want to be alerted to all invalid packets or only at higher traffic levels.
Additionally, DoS reporting provides visibility into invalid packets.
Probably invalid packets
Legitimate TCP Push, TCP SYN-ACK, and TCP RST packets does match during the flow table lookup, so any of
these packets received by DoS protection are probably be invalid. However, since they are at least valid packets
as far as protocol compliance, you can’t be sure they are invalid.
This traffic should be restricted.
46
DENIAL OF SERVICE—BIG-IP AFM DoS vectors
Presumably valid packets
TCP SYN, TCP ACK, and UDP flood vectors all represent potentially legitimate traffic. These packets should not be
restricted unless resource availability is threatened.
TCP ACKs are presumably valid because they may be seen when SYN Cookies are active. If they fail a hardware
SYN Cookie check, presumably valid packets are dropped or rejected before they reach DoS protection.
If SYN Cookies are not active, any unsolicited, bare ACKs are dropped by TMOS.
BIG-IP AFM DoS vectors

This section lists examples of attack vectors and mitigations.
Device configuration
You can configure many BIG-IP AFM DoS vectors using Device Configuration steps. Unless otherwise noted, the
following configuration steps apply to each DoS vector in this section.
To select an appropriate DoS protection using the Configuration utility
1. Navigate to Security > DoS Protection : Device Configuration.
2. Click the appropriate protection.
3. Click Update.
To select an appropriate DoS protection using tmsh at the command line
tmsh modify /security dos device-config dos-device-config dos-device-vector {

<VALUE> { <VALUE> <INTEGER VALUE>}}
For example:
tmsh modify /security dos device-config dos-device-config dos-device-vector {

ip-err-chksum { detection-threshold-pps 1 default-internal-rate-limit 1 } }
Bad header
The various bad header vectors all check for packets violating their respective protocol specifications.
Because packets matching a bad header vector are dropped later by TMOS, there are no desirable bad header
packets. There is no reason to keep them around. F5 recommends setting Detection and Rate Limiting thresholds
to MINIMUM for these vectors.
To modify a specific Bad Header attack, refer to Device configuration.
47
DNS
Domain Name System (DNS) attacks allow an attacker to attack use malformed packets and protocol errors in an
attempt to cause disruption of name resolution.
To modify a specific DNS attack, refer to Device configuration.
Flood
Flood attacks attempt to overwhelm a resource. While flood vector packets are Probably Invalid, because they
follow protocol specification, it is possible that they are valid. If the packets are valid, they match on a flow lookup
table and are handled without DoS protection seeing them.
F5 recommends setting Detection and Rate Limiting to LOW for the following vectors:
• TCP BadAck Flood
• TCP RST Flood
• TCP SYN-ACK
• TCP SYN Oversize
• TCP Window Size
Some of the flood vectors are presumably valid. These are valid packets, indistinguishable from legitimate
connection requests. F5 recommends setting Detection and Rate Limiting to HIGH for the following vectors:
• TCP SYN Flood
• TCP ACK (when SYN Cookies are active the ACK does not match a Flow Table Lookup)
• UDP
The recommended settings for the remaining flood vectors depend on the environment. F5 recommends setting
Detection and Rate Limiting to HIGH for the remaining vectors in the flood group, pending an assessment of
traffic patterns. This assessment may indicate LOW or MINIMUM settings are appropriate for specific vectors.
To modify a specific Flood attack refer to Device configuration.
Fragmentation
Fragmentation is the process of breaking a single IP datagram into multiple packets of smaller size.
Fragmentation attacks allow an attacker to use this method as an attack vector. The vectors in the Fragmentation
section all represent invalid packets that are dropped by TMOS. They are not legitimate IP fragments so there is no
reason to keep them around.
The legitimate IP and IPv6 fragment traffic is tracked in the IP Flood and IPv6 Flood vectors. F5 recommends
setting Detection and Rate Limiting thresholds of MINIMUM for these vectors.
To modify a specific Fragmentation attack refer to Device configuration.
48
Single endpoint
Single endpoint vectors allow for detection and rate limit packets-per-second involving a single device.
The single endpoint sweep vector tracks the 100 source addresses sending the most of the selected packet types.
The single endpoint flood vector tracks the 100 destination addresses receiving the most of the selected packet
types. These two vectors are especially useful because their mitigation efforts are directed only at the 100 involved
hosts. The other vectors drop traffic without regard to its legitimacy.
Bad actor detection was introduced with single endpoint sweep with the auto-blacklist feature. This feature works
with IP Intelligence to classify hosts sending too much traffic as malicious, and drop traffic from them.
To modify a specific Single Endpoint from the Configuration utility
1. Navigate to Security > DoS Protection : Device Configuration : Single Endpoint :

<sweep|flood >.
2. Select the Detection Threshold and Rate Limit.
3. If using Sweep, optionally link the Sweep vector to IP Intelligence and select IP Intelligence to use
to classify identified bad actors, how long they must sustain an attack to be blacklisted, and how
long to blacklist them for.
4. Click Update.
To modify a specific Single Endpoint Vector using tmsh at the command line
tmsh modify /security dos device-config dos-device-config { dos-device-vector

{ sweep { detection-threshold-pps 250 default-internal-rate-limit 500 packet-
types add { udp } auto-blacklisting enabled blacklist-category phishing
blacklist-detection-seconds 10 blacklist-duration 65535 }}}
Session Initiation Protocol
Session Intiation Protocol (SIP) is an IP telephony standard developed by the IETF to manage the creation and
destruction of voice-related IP networking sessions. Session Initiation Protocol (SIP) is a typically used for voice
and video calls over IP. SIP protections within BIG-IP AFM allow for detection and mitigation of malformed packets
containing errors intended to intentionally or unintentionally to disrupt this connectivity.
To modify a SIP vector refer to Device configuration.
Other
The Other vector allows for detection and mitigation against other attack types.
The IP Unknown Protocol and Land Attack vectors are invalid packet types. There is no reason to keep them
around. F5 recommends setting Detection and Rate Limiting thresholds of MINIMUM for these vectors.
49
To modify an Other protection refer to Device configuration.
DoS profiles
DoS Profiles allow a BIG-IP provisioned with BIG-IP AFM the ability to detect and automatically mitigate DoS on
an individual virtual server.
Similar to device DoS, various detection and mitigation thresholds can be specified for DoS attack types to more
accurately detect, track, and rate limit attacks.
For more detailed information on each attack type, refer to Detecting and Preventing System DoS and DDoS
Attacks chapter in BIG-IP Systems: DoS Protection and Protocol Firewall Implementations.
DoS profiles provide the ability to mitigate attacks at a granular level, contrary to global settings in Device DoS,
while also giving the operator the ability to further tune many DoS attack vector thresholds on the virtual server
level.
DoS Profiles contain three features:
• Protocol DNS
• Protocol SIP
• Network
Protocol DNS
Protocol DNS DoS profiles allow attack mitigation of both malformed protocol packets as well as volumetric
attacks with valid packets.
Protocol error attack detection
Protocol Error Attack Detections allows BIG-IP AFM to detect and mitigate against malformed DNS queries at a
specified rate of increase.
To modify DNS Error Attack Detection within a DoS profile using the Configuration utility
1. Navigate to Security > DoS Protection: DoS Profile and click the DoS profile.
2. Click Protocol DNS: General Settings.
3. Click the checkbox next to Protocol DNS Protection to enable.
4. Specify the specific rate of increase, rate threshold and rate limit for the protection.
5. Click Update.
To modify the protocol DNS from using tmsh at the command line

50
tmsh modify /security dos profile <PROFILE NAME> protocol-dns modify {all
{<VALUE> <INTEGER VALUE>}}
DNS query attack detection
This feature allows for protection against malformed packets and protocol errors in an attempt to cause disruption
of name query resolution.
To modify DNS query attack detection within a DoS profile
2. Click Protocol DNS: General Settings.
3. Click the checkbox next to Protocol DNS Protection to enable.
4. Within DNS Query Attack Detection, click the checkbox next to the query attacks that are being
configured
6. Click Update.
To modify the DNS Query Attack Detection using tmsh at the command line
tmsh modify /security dos profile <PROFILE NAME> protocol-dns modify { all {
dns-query-vector modify { all { <VALUE> <INTEGER VALUE>} } } }
For more detailed information on DNS DoS attacks, refer to Detecting and Preventing DNS DoS Attacks chapter
in BIG-IP Systems: DoS Protection and Protocol Firewall Implementations.
Protocol SIP
Protocol SIP DoS profiles allow attack mitigation of both malformed protocol specific packets and volumetric
attacks with valid packets. This mechanism can also be useful to detect unusual increases in protocol traffic.
Protocol error detection
This protection allows detection and mitigation against malformed SIP protocol errors at a specified rate of
increase.
To modify SIP Protocol Error Detection within a DoS profile using the Configuration utility
2. Click Protocol SIP: General Settings.
51
3. Click the checkbox next to Protocol SIP Protection to enable.
4. Within Protocol Errors Attack Detection, click the checkbox next to enable.
6. Click Update.
To modify the protocol SIP using tmsh at the command line
tmsh modify /security dos profile <PROFILE NAME> protocol-sip modify {all {
<VALUE> <INTEGER VALUE> } }
SIP method attack detection
SIP Method Attack Detection allows for granular protections for common SIP methods.
To modify SIP Attack Method Detection within a DoS profile using the Configuration utility
1. Navigate to Security > DOS Protection: DOS Profile and click the DOS profile.
2. Click Protocol SIP: General Settings.
3. Click the checkbox next to Protocol SIP Protection to enable.
4. Within SIP Method Attack Detection click the checkbox next to a method type to enable.
5. Specify the specific rate of increase, rate threshold and rate limit for the method.
6. Click Update.
To modify the SIP Attack Method using tmsh at the command line
tmsh modify /security dos profile <PROFILE NAME> protocol-sip modify { all {
<VALUE> <INTEGER _ VALUE> } }
Network
Network DoS protection allows mitigation from a number of attack vectors at a VIP level. This includes both
individual attacks as well as behavioral analysis.
For more detailed information on which vectors are accelerated in hardware, refer to Detecting and Preventing
Network DoS Attacks in BIG-IP Systems: DoS Protection and Protocol Firewall Implementations.
Network DoS protection contains two features: Behavioral Analysis and Attack Types.
52
Behavioral analysis
Behavioral Analysis allows the DoS profile to inspect and report on sampled data that may indicate an attack.
Make sure to allow time for BIG-IP AFM to sample data from multiple sources. If traffic volume is low and from only
one source, you may see false positives.
Important F5 recommends against using the feature called Behavioral Analysis in a production environment
in versions earlier than BIG-IP 13.0. In BIG-IP 13.0 and later, Behavioral Analysis is called Dynamic Signatures
and has been greatly improved.
To modify Network DoS Behavioral Analysis within a DoS profile using the Configuration utility
2. Click Network: General Settings.
3. Click the checkbox next to Network Protection to enable.
4. Within Behavioral Analysis, enable the detection status.
5. Click Update.
To enable or disable Behavioral Analysis using tmsh at the command line
tmsh modify /security dos profile <PROFILE NAME> dos-network modify {all {
behavioral-analysis <VALUE> } }
Attack types
Configure Attack Types to have the DoS profile inspect and protect against L3 and L4 attack vectors at a
specified threshold and/or percentage of increase.
To modify Network DoS Attack Types within a DoS profile using the Configuration utility
1. Navigate to Security > DOS Protection: DoS Profile and click the DoS profile.
2. Click Network: General Settings.
3. Click the checkbox next to Network Protection to enable.
4. Under Attack Types, expand the appropriate attack type.
5. Enable the Detection Status.
6. Modify the threshold, rate increase and rate limit as appropriate.
7. Click Update.
53
DENIAL OF SERVICE—DoS policy development
To modify the Attack Types using tmsh at the command line
tmsh modify /security dos profile <PROFILE NAME> dos-network modify {all {
<VALUE> modify { <VALUE> { <VALUE> <INTEGER VALUE> } } } }
Virtual server configuration
Once you’ve configured a DoS profile, you need to enable it on one or more virtual servers.
To enable a DoS profile on the virtual server using the Configuration Utility
1. Navigate to the virtual server properties Local Traffic > Virtual Servers : Virtual Server List.
2. Select the virtual server to configure.
3. Click the Security tab and click Policies.
4. Set to DoS Protection Profile.
5. Select Enable and then click a log profile from the list.
6. Click Update.
To add a DoS profile to a virtual server using tmsh at the command line
tmsh modify /ltm virtual <VIRTUAL> profiles add { <DOS PROFILE> }
DoS policy development

A BIG-IP AFM DoS policy consists of multiple components working together to protect an infrastructure from DoS
attacks. Some elements of a BIG-IP AFM policy protect the application from protocol-specific attacks, while
others protect more broadly.
Depending on the use case, you may require a simple DoS policy or one requiring more extensive development
and tuning. F5 recommends that you clearly identify your use case—what your policy must protect—before you
create it. Having this information should make development and enforcement easier.
Policy life cycle
The DoS security policy life cycle has three phases:
• Create and deploy policy
• Tune policy
• Maintain policy
54
DENIAL OF SERVICE—Dynamic Signatures
Create and deploy policy
Create a new policy using the network and protocol protections specific to the infrastructure that is being
protected.
Tune policy
False positive violations are identified and policy settings are adjusted to allow legitimate traffic to pass through to
the protected applications and infrastructure. This is necessary as some legitimate traffic may not pass the
configured policy rules and may wrongly be identified as an attack.
Maintain policy
The DoS policy allows for adaption to application and infrastructure changes, new security requirements, and
activities, based on the review of logs, reports and statistics of attacks mitigated by the BIG-IP AFM system.
Policy tuning details
Depending on the policy’s initial settings, the BIG-IP AFM DoS policy may need to be disabled or thresholds may
need to be adjusted if legitimate traffic is blocked. At the end of the tuning process, the policy should contain all
the relevant protections and thresholds.
Tips and guidelines
F5 recommends the following tips and guidelines for policy development:
• Consider a cloud-based solution such as F5 Silverline: Cloud Based DDoS Protection to augment on-
premises DoS mitigation and especially for volumetric attacks that may exceed on-premises bandwidth.
• Start with a policy that allows a higher percentage of traffic nonconformity to allow all legitimate behavior
and disallow malicious requests.
• Remember that Global DoS traffic settings are applied across the entire BIG-IP system, meaning all ingress
traffic is counted.
• Use DoS profiles associated with individual virtual servers for specific attack remediation on a more granular
basis.
• Set a lower detection and rate limiting thresholds for attack vectors where there is no level of desirable
traffic.
• Add critical infrastructure to the DoS White List.
Dynamic Signatures
The Dynamic Signatures feature is an automated approach to identifying anomalous traffic patterns and restricting
them when the BIG-IP experiences stress. Dynamic signatures reduce false positives by alerting and enforcing
signatures only when an attack has a meaningful impact on the BIG-IP system and the applications it supports.
55
Dynamic signatures are ephemeral, which means the BIG-IP system creates them only when needed and discards
them once an attack is over. During the time that dynamic signatures exist, you can review them, disable them, or
modify their thresholds; however, once the system discards the signatures, your modifications to them are also
permanently discarded.
You can enable dynamic signatures by navigating to Device Configuration > Network Security and selecting
from the following Enforcement menu options:
• Enabled turns on enforcement.
• Learn-Only starts collecting the statistics the BIG-IP system uses to determine normal traffic patterns.
• Disabled turns off enforcement.
Adjusting the learning phase period
The Dynamic Signatures feature collects statistics for a learning phase period of 120 minutes by default. The
Configuration utility reports the time remaining in the learning phase or the date and time the learning phase
completed.
You can click Start Relearning to restart the learning phase.
For testing purposes, you may want to shorten the Dynamic Signatures learning phase period.
To adjust learning phase period
1. At the command line, use the following command syntax
tmsh modify sys db l4bdos.baseline.learning.period value <nn>
Note Replace <nn> with the number of minutes you want the learning phase period to run.
2. In the Configuration utility, click Start Relearning.
Adjusting Dynamic Signatures sensitivity
You can configure Dynamic Signatures to be more or less specific in addressing threats by selecting from a range
of sensitivity levels. These levels range from the least specific, none (log/report only), to the most specific, high.
The system factors sensitivity into the automatically generated detection and mitigation thresholds.
Viewing Dynamic Signatures
You can view the system’s dynamic signatures using tmsh or the Configuration utility
To view Dynamic Signatures using tmsh
• Type the following commands:
(tmos)# cd /Common/dos-common/
56
(tmos)# list security dos dynamic-signatures
To view or modify Dynamic Signatures using the Configuration utility
1. Navigate to Security > DoS Protection > DoS Overview.
Modifying Dynamic Signatures
In the Configuration utility, on the DoS Overview, you can modify Dynamic Signatures in the following ways:
• Disable individual dynamic signatures
• Modify detection and mitigation thresholds
• Review elements a signature uses
You can also use tmsh to modify Dynamic Signatures
To modify Dynamic Signatures using tmsh
• Use the following command syntax:
modify /security dos dynamic signatures <signature name>
To enable/disable a Dynamic Signature using tmsh
• Use the following command syntax
status {enabled|disabled}
To enable/disable mitigation for a Dynamic Signature using tmsh
enforce {enabled|disabled}
To configure the Dynamic Signature detection threshold using tmsh
detection-threshold {pps value}
To configure the Dynamic Signature mitigation threshold using tmsh
mitigation-threshold {pps value}
57
DENIAL OF SERVICE—DoS reporting and visibility
Using Dynamic Signature for HA configurations
HA is supported for Dynamic Signatures, but after setting up Dynamic Signatures for HA, you must use tmsh to
configure peer devices to share signatures.
To configure peer devices to share signatures using tmsh
1. Type the following command:
tmsh modify sys folder dos-common/ device-group dos-global-dg
2. Save the config by typing the following command:
tmsh save sys config
DoS Whitelist
Dynamic Signatures honor the DoS Whitelist.
Order of precedence for DoS defense mechanisms
Knowing the order in which the different DoS mechanisms operate may help you troubleshoot unexpected results.
For a given context (for example, Global/Device or DoS Profile) the order of precedence is as follows:
1. Single Endpoint Sweep
2. Single Endpoint Flood
3. Other DoS Vectors (Static Vectors)
4. Dynamic Signatures
DoS reporting and visibility

After a DoS protection is configured on the BIG-IP system, charts, reports, statistics, and event logs related to
DoS attacks and mitigations are available on the system. For example, a DoS Overview page shows at-a-glance
whether or not the system is under attack. It also indicates the impact of DoS attacks on the BIG-IP system
performance.
Other reports show transaction outcomes and correlate the impact of system detection with the mitigation of DoS
attacks. The reports and event logs can show whether or not DoS protection is functioning properly or whether
tuning is necessary. They can also help identify and track DoS attacks. Analyzing attack and trend data can
provide insight into DoS threats.
Note To allow DoS data to populate DoS reports on a virtual server basis, you must associate a DoS profile
with one or more virtual servers.
DoS Overview The DoS Overview displays real-time information about all DoS attacks on the system. The system
displays recent attacks.
58
To view the DoS Overview in the Configuration utility
• Navigate to Security > Reporting : DoS : Overview.
Logged Attacks shows a flag for an attack in progress. The log includes the 100 most recent events per protocol
for application and network attacks. Up to 200 attacks may be shown in the charts. If the information desired is
not shown, try increasing the time period selected in the filter.
You can filter your view by attack impact (High Impact, Medium Impact, Low Impact). To focus in on the specific
details in the charts, hover on the chart for the time period of interest. The system displays in a tooltip the details
about what was happening at that time.
To learn more about attacks that have occurred, click the Attack ID number in the Historical & Recent Attacks
Log.
The system displays events associated with the attack. If there are more than 100 events, there is a link to the
event log, which you can click to see more events.
The Overview page includes information on throughput, RAM and CPU usage. Because the statistics vary from
system to system, it is a good idea to become familiar with typical memory and CPU usage and throughput on
your system in association with recent attacks.
For more detailed information on DoS reporting, refer to the Help tab in the Configuration utility.
Logging
BIG-IP AFM logs when an attack started, when an attack is mitigated, and when an attack has stopped.
Note F5 recommends remote high-speed logging to log DoS events.
Table 5.1 DoS Logging fields
Field Description
Time Time of the event
Virtual Server For DoS profile events, the virtual server on which the profile is enabled.
BIG-IP AFM DoS vectors have the following events:
Attack Started: Indicates at least one of the detection thresholds have been reached.
Event Attack Sampled: Indicates number of vector-related packets sampled once an attack has
started.
Attack Stopped: Indicates traffic has fallen below the detection thresholds and the attack
has ended.
Type Attack vector type
Action displays one of two options:
None: Indicates that the internal rate limit has not been reached and no packets have
Action been dropped.
Drop: Indicates that the internal rate limit has been reached and packets have been
dropped.
59
Field Description
Attack ID Identification number associated with the attack
Packets in / sec Packets related to the vector type that BIG-IP AFM has sampled in the last second.
Dropped
Packets related to the vector type that BIG-IP AFM has dropped in the last second
Packets
For more detailed information on event log messages, refer to Event Messages and Attack Types in External
Monitoring of BIG-IP Systems: Implementations.
Device DoS logging
1. Navigate to Security > DoS Protection: Device Configuration.
2. From the Log Publisher menu, click your publisher.
Note Device DoS does not need a logging profile configured to log events. The system supplied global-
network logging profile logs the results to the configured publisher.
DoS profile logging
Requirements to log DoS Profile events include:
• Enabled DoS logging within the log profile.
• Assign the logging profile within the virtual server that the DoS Profile is being used.
For more information on configuring a logging profile, refer to Monitoring and Logging BIG-IP AFM.
To configure DoS logging with a log profile using the Configuration utility
1. Navigate to Security > Event Logs: Logging Profile and click logging profile.
2. Click the checkbox next to DoS Protection to enable it.
3. Under network DoS Protection, click the publisher from the list.
4. Click Update.
To enable a logging profile on the virtual server using the Configuration utility
1. Navigate to the virtual server properties Local Traffic > Virtual Servers: Virtual Server List.
2. Select the virtual server.
3. Click the Security tab and click Policies.
4. Get to Log Profile, click the publisher from the list.
60
DENIAL OF SERVICE—Signaling and intelligence
5. Click Update.
Signaling and intelligence

The BIG-IP AFM can block bad actors based on external sources of data or other processes within the BIG-IP
platform. This allows the BIG-IP to dynamically react to DoS attacks based on numerous sources of intelligence.
Within BIG-IP AFM, the virtual server DoS profile sweep detection feature can provide intelligence to allow bad
actors to be blocked automatically for a pre-defined period of time based on the detection threshold. This blocking
configuration is mapped to an IP Intelligence category.
Additionally, blacklists can be created from external intelligence sources. F5 offers a subscription IP-intelligence
service for categorization of discovered bad actors and allows the implementation of custom IP Intelligence
policies.
In order to get a feed list for IP Intelligence, the configuration requires an external host to provide via either a
website or FTP server a list of offending IP addresses.
The update interval is configured to specify the timeframe in which BIG-IP AFM regularly polls the server for
updates. If an update poll fails, BIG-IP AFM continues to use the last known good list. The feed list is a simple CSV
file.
To configure the external feed list using tmsh at the command line
tmsh create /security ip-intelligence feed-list extBlacklist feeds add {

<NAME> { default-blacklist-category <CATEGORY> default-list-type <BLACKLIST/
WHITELIST> poll { url <URL> interval <INTERVAL> } } }
For more detailed information on Signaling and Intelligence, refer to About IP Address Intelligence in the Network
Firewall section of BIG-IP Network Firewall: Policies and Implementations.
For more information on DoS, refer to the following resources:
• F5 DDoS Protection Volume 2
• K15368: The BIG-IP AFM system logs Network Firewall events using the logging profile associated with the
Network Firewall rule
• K14813: Detecting and mitigating DoS/DDoS attacks (11.4.x - 12.x)
• The DDoS Threat Spectrum
• The Application Delivery Firewall Paradigm
• Protect Against Evolving DDoS Threats: The Case for Hybrid Mitigation
61
EXTERNAL TOOLS—BIG-IQ Centralized Management
External Tools
Several external tools can be used to assist with management of one or multiple BIG-IP® AFM™ systems, logging,
and transfer of information. The following are covered in this chapter:
• BIG-IQ® Centralized Management
• Simple Network Management Protocol (SNMP) Polling and Alerting
• Syslog
• Internet Protocol Flow Information Export (IPFIX)
• sFlow
BIG-IQ Centralized Management

BIG-IQ Network Security is a platform designed for the central management of one or more BIG-IP systems,
where BIG-IP AFM is installed and provisioned.
The BIG-IQ Network Security system provides:
• Device discovery with import of firewalls referenced by discovered devices.
• Management of shared objects (address lists, port lists, rule lists, policies, and schedules).
• L3 and L4 firewall policy support, including staged and enforced policies.
• Firewall audit log used to record every firewall policy change and event.
• Role-based access control.
• Deployment of configurations from snapshots and the ability to preview differences between snapshots.
• Multi-user editing through a locking mechanism.
• Monitoring of rules.
• Reports on security.
This section describes common operational tasks that can be performed when leveraging BIG-IQ for BIG-IP AFM
management.
Manage policies
When using BIG-IQ for policy management, BIG-IQ acts as a centralized database and a backup source for
BIG-IP AFM firewall policies. By design, BIG-IP AFM devices are discovered by BIG-IQ and the management
authority for firewall policies and shared security is given to BIG-IQ.
When using BIG-IQ to manage BIG-IP AFM devices, F5® recommends making all changes to the systems in
BIG-IQ. If changes are made directly to the BIG-IP, they are lost when BIG-IQ deploys a new change set unless
62
EXTERNAL TOOLS—BIG-IQ Centralized Management
BIG-IQ is made aware of the changes using one of two of the following methods:
• BIG-IQ re-discovers BIG-IP AFM and changes discovered are designated as Use BIG-IP.
Note This practice can affect shared objects used by other BIG-IP AFM devices such as address lists,
ports lists, policies, and rule lists.).
• Changes performed locally to the BIG-IP AFM device are replicated in BIG-IQ prior to deploying other
changes from BIG-IQ.
Compare policies
As the central manager, BIG-IQ is has authority over all policy objects.
To manage revisions and changes to policy and shared objects, BIG-IQ keeps snapshots of the entire policy set as
it relates to all firewalls. Because snapshots are kept, no individual firewall backups are maintained. From a policy
standpoint, a central shared data set exists with point in time copies of policy state.
Full BIG-IP system backups can be initiated through the device module in BIG-IQ; however doing this is not
required to maintain policy backups.
When a deployment task executes, a snapshot is automatically created that contains all BIG-IQ data at that
specific point in time. A deployment task can contain multiple device deployments. The policy point is used to
compare an existing policy on the BIG-IP AFM with the working configuration stored in BIG-IQ. Differences in the
two are recognized as changes.
You can compare changes on a BIG-IP AFM by creating an evaluation task and selecting Working Config or
selecting a specific snapshot to compare with the firewall. If you choose an earlier snapshot, it is possible to view
the differences in policy changes that have been deployed to the firewall since that point.
For small-to-medium environments with infrequent changes, F5 recommends that you generate a snapshot of the
configuration prior to making modifications to the policy.
In larger environments with frequent changes, you may want to consider creating a snapshot at least once a day.
Frequent snapshots provide a consistent set to compare against older policies, and this makes rollback of policy
changes easier if a quick restore is required after deploying firewall policy changes.
Restore a policy
When you restore a policy using BIG-IQ, you can evaluate policies against historical snapshots so that only change
sets are restored.
The following steps provide a high-level overview of policy rollback:
1. Identify the timestamp of the previous policy deployment by searching the deployment tasks for the firewall
name. If the deployment task isn’t available through the BIG-IQ configuration manager, search BIG-IP LTM
logs for previous pccd compile times.
2. Create a new deployment task by selecting the snapshot from the previous deployment. If it is unavailable,
select the next most-recent snapshot.
63
EXTERNAL TOOLS—SNMP polling and alerting
BIG-IQ provides a change set between the current deployment and the deployment snapshot you selected.
3. Review the change set.
4. Deploy the changes to restore the BIG-IP AFM policy to the earlier configuration.
While the previous steps restore the policy to the BIG-IP AFM, BIG-IQ retains a working configuration of the
previously made changes. To reapply that configuration, BIG-IQ must first re-discover BIG-IP AFM or you have to
edit the BIG-IQ policy objects.
Note To restore a BIG-IP AFM policy without using BIG-IQ, you must back out of the changes you’ve made
to the policy or restore a previous version of the configuration using a SCF or UCS file.
Use BIG-IQ audit logs
BIG-IQ provides an audit log of all security policy configuration changes. You can view them in the BIG-IQ
configuration manager or through an archived text file, if one exists. By default, BIG-IQ keeps 30 days of audit log
entries within the BIG-IQ data store and archives older log events to the file system. You can update the number of
days in the Audit Logs Settings.
For more information, refer to BIG-IQ Centralized Management: Security Managing Audit Logs in BIG-IQ
Network Security.
Note For information about how to locate F5 product guides, refer to AskF5™ article: K12453464: Finding
Reporting
BIG-IP AFM creates several reports for displaying DoS device information and firewall rule statistics. You can view
these reports through the Configuration utility for an individual BIG-IP AFM system or through the BIG-IQ Security
Reporting interface, where you can view the results for one or more BIG-IP AFM systems.
Note Bi-directional HTTPS access between the BIG-IQ and BIG-IP AFM is required to generate reports for
centralized viewing in BIG-IQ.
Manage software
BIG-IQ supports automation and scheduling of the collection of BIG-IP backup files, as well as management of
TMOS software images. With the BIG-IQ Device it is possible to stage and deploy TMOS upgrades directly from
BIG-IQ, eliminating the need to log into individual BIG-IP AFM devices to import, install, and reboot devices.
SNMP polling and alerting

BIG-IP AFM supports SNMP and is capable of sending SNMP traps and being polled by a third party SNMP
management system.
BIG-IP AFM supports version 1, 2c, and 3 of SNMP for manager access and trap destinations.
For more detailed information on the initial configuration of SNMP, refer to BIG-IP TMOS: Concepts SNMP.
64
EXTERNAL TOOLS—Syslog
Use SNMP polling
SNMP polling is an inbound query submitted against a BIG-IP device. You can download enterprise management
information base files (MIBs) specific to BIG-IP AFM using the Configuration utility.
You can find events specific to BIG-IP AFM in the F5-BIGIP-LOCAL-MIB.txt file.
Using an SNMP manager, you can collect information for firewall rules, contexts, and rule hits for BIG-IP AFM. You
can use the following SNMP command syntax to pull rule statistics:
snmpwalk -c public <HOSTNAME> ltmFwRuleStat
In addition to firewall rules, you can query BIG-IP AFM DoS statistics and attack information using an SNMP
manager. You can use the following SNMP command syntax to pull DoS statistics:
snmpwalk -c public <HOSTNAME> ltmDosAttackDataStat
Use SNMP traps
SNMP traps are outbound alerts which can be sent to an external management system for processing. The
following table outlines relevant BIG-IP AFM related notifications that can be sent to an SNMP trap receiver.
Table 6.1 Relevant BIG-IP AFM notifications to send to SNMP trap receiver
Trap Name Description Recommended Action

BIGIP_TMM_TMMERR_DOS_
The start of a possible DoS attack Determine your response to this
ATTACK_START
was registered. type of DoS attack, if required.
(.1.3.6.1.4.1.3375.2.4.0.133)
BIGIP_TMM_TMMERR_DOS_
The end of a possible DoS attack
ATTACK_STOP None, informational.
was detected.
(.1.3.6.1.4.1.3375.2.4.0.134)
BIGIP_DOSPROTECT_
The flow sweeper started or
DOSPROTECT_AGGRREAPEROID None, informational.
stopped.
(.1.3.6.1.4.1.3375.2.4.0.22)
Syslog
Syslog is a widely used standard for message logging. Each message is labeled with a facility code and assigned
a severity. The facility code indicates the software type of the application that generated the message. The syslog
messages may be directed to various destinations, tuned by facility and severity, including console, files, remote
syslog servers, or relays.
The default information sent to a syslog destination may contain more detailed log information than required for
firewall rule event logging. F5 recommends modifying the output with logging filters to reduce the size of the
messages, as well as to make the messages more easily understood. F5 also recommends controlling access to
65
EXTERNAL TOOLS—IPFIX
the logs to a select group of administrators and operators on a need-to-know basis. Log collectors are designed
to prevent or notify, based on log modification attempts.
BIG-IP AFM also contains logging formats for commercial log aggregation and security information and event
management (SIEM) solutions such as Splunk and Arcsight. These log destinations are pre-configured for ease of
deployment.
For more detailed information refer to “Monitoring and Logging BIG-IP AFM”.
External logging
The BIG-IP system uses a high-speed logging (HSL) mechanism, which allows it to efficiently generate and
transmit log messages to one or more log collectors.
F5 recommends sending logs of system and firewall messages to a remote server for event collection and
indexing. Doing so allows you to view messages without impacting the performance of the system generating
them, and in the event of a system failure, remote logs can help troubleshoot the cause of the failure.
You can configure remote logging destinations for long-term storage of data to use for trend analysis and auditing.
Many third-party logging collectors can display time-series events to help with troubleshooting.
For more detailed information on external logging configurations, refer to External Monitoring of BIG-IP
Systems: Implementation guide.
IPFIX
IPFIX is a universal standard of export for IP flow information from devices that are used by mediation systems,
accounting/billing systems, and network management systems to facilitate services such as measurement,
accounting, and billing.
IPFIX provides a means for standardizing IP flow information to be formatted and transferred to an external
collector. The details of the protocol are defined by RFC 5103, and RFCs 7011 through 7015. The BIG-IP system
can be configured to send IPFIX data to a collector for consumption.
Using IPFIX for traffic analysis provides guidance on traffic patterns and system usage for capacity planning and
charge back based on consumption, troubleshooting network and application issues, identifying volumetric DoS
attacks, and evaluating the effectiveness of security policies.
For more detailed on IPFIX configuration and options, refer to Logging Network Firewall Events to IPFIX
Collectors in BIG-IP Network Firewall: Policies and Implementations.
The IPFIX entities IANA definitions of the supported Information Elements (IEs) within the BIG-IP software release
can be found in the Downloads section of the Welcome page of the Configuration utility.
66
EXTERNAL TOOLS—Change and configuration management
sFlow
Sampled flow (sFlow) is an industry standard for packet export. sFlow provides a means for exporting truncated
packets, together with interface counters. The BIG-IP system can be configured to poll internal data sources and
send data samples to an sFlow receiver. The collected data can be used to analyze the traffic that traverses the
BIG-IP system.
Using sFlow for traffic analysis can provide guidance on traffic patterns and system usage for capacity planning
and charge back based on consumption, troubleshoot network and application issues, identify volumetric DoS
attacks, and evaluate the effectiveness of security policies.
For more detailed sFlow configuration and options, refer to Implementations Monitoring BIG-IP System Traffic
with sFlow in External Monitoring of BIG-IP Systems.
Change and configuration management

F5 recommends that you establish, follow, and document a change and configuration management process
appropriate to your organization. At a minimum, the process should detail methods for requesting changes,
evaluating the risk of the change, and all responsible parties involved in the changes. Documentation and recorded
change results should be archived for historical and auditing purposes.
In smaller environments, the BIG-IP AFM policy rule description field may be used to track change requests. The
description field is limited to 255 characters.
In larger environments, F5 recommends using an external tracking system in combination with in-policy
documentation. There are many third-party external configuration management databases (CMDB) for facilitating
and documenting larger use cases. F5 recommends selecting a system that follows the Information Technology
Infrastructure Library (ITIL) or similar methodologies.
67
MONITORING AND LOGGING BIG-IP AFM—BIG-IP AFM monitoring
Monitoring and Logging BIG-IP AFM

Monitoring and logging processes ensure that systems are running smoothly and provide important insight into
what is happening in an environment. Because BIG-IP® AFM™ is a critical component of a security infrastructure,
F5 recommends periodic review of BIG-IP AFM deployment logs to actively monitor the device and baseline
performance.
F5 also highly recommends establishing, documenting, and following a log maintenance plan so that any security
incidents can be reviewed during the defined log retention period.
Note This chapter covers only monitoring and logging elements and processes relevant to BIG-IP AFM. For
information about logging the BIG-IP system or other modules, refer to TMOS Operations Guide .
Note For information about how to locate F5® product guides, refer to AskF5™ article: K12453464: Finding
BIG-IP AFM monitoring
Establish a baseline
Establishing a baseline for your system is necessary to understand what is normal for your environment so that
deviation from expected values can be recognized. It can also help you with capacity planning and scaling of
infrastructure.
SNMP
F5 supports the industry-standard SNMP protocol to manage BIG-IP devices on a network. The SNMP policy item
on the BIG-IP system must be configured. The primary tasks in configuring the SNMP policy item are configuring
client access to the SNMP policy item, and controlling access to SNMP data.
The following are some SNMP management information base (MIB) files to look at for alerting and monitoring of
your BIG-IP AFM system:
BIG-IP AFM statistics
BIG-IP AFM OIDS are defined in /usr/share/snmp/mibs/F5-BIGIP-LOCAL-MIB.txt. The data is gathered under
the following sections:
• ltmFw*
• ltmFwIpint*
• ltmDos*
For example:
snmpwalk -c public localhost F5-BIGIP-LOCAL-MIB::ltmFwRuleStatCounter
F5-BIGIP-LOCAL-MIB::ltmFwRuleStatCounter.”global”.”/Common/global-firewall-rules”.”rd-
68
MONITORING AND LOGGING BIG-IP AFM—BIG-IP AFM logging
fw-rule1”.””.”/Common/rd-fw-policy”.staged = Counter64: 4220
F5-BIGIP-LOCAL-MIB::ltmFwRuleStatCounter.”global”.”/Common/global-firewall-
rules”.”allow-udp-53”.””.”/Common/global-fw-policy”.enforced = Counter64: 0
rules”.”port-2002-global”.””.”/Common/global-fw-policy”.enforced = Counter64: 4220
rules”.”disallow-source-10.12.27.214”.””.”/Common/global-fw-policy”.enforced =
Counter64: 0
F5-BIGIP-LOCAL-MIB::ltmFwRuleStatCounter.”virtual”.”/Common/http _ vs”.”rd-rule1”.””.”/
Common/fw-policy-vs”.enforced = Counter64: 0
F5-BIGIP-LOCAL-MIB::ltmFwRuleStatCounter.”virtual”.”/Common/http _ vs”.”http-rule”.””.”/
Common/fw-policy-vs”.enforced = Counter64: 0
Overall health statistics
In addition to the BIG-IP AFM statistics, it is important to monitor the overall health of the BIG-IP. SNMP can
provide information on:
• CPU
• RAM
• DISK
• TMOS Connection table
For more detailed information on this SNMP traps, refer to SNMP Trap Configuration in BIG-IP Systems: DoS
Protection and Protocol Firewall Implementations.
For more detailed information on SNMP MIBs, refer to AskF5 article: K13322: Overview of BIG-IP MIB files (10.x -
12.x).
Note For information about how to locate F5 product guides, refer to K12453464: Finding product
BIG-IP AFM logging

The BIG-IP system uses several logging systems depending on the source and the repository storing the log
message. Host side processes—daemons running outside the Traffic Management Microkernel (TMM)—use the
standard UNIX logging utility, syslog-ng, to deliver system messages to log files, often called local syslog. The
level of information that syslog-ng delivers to log files is configurable. For more information, refer to AskF5 article:
K13317: Configuring the level of information that syslog-ng sends to log files.
Additionally, local syslog can be configured to log to remote destinations.
69
To configure local.syslog
• Navigate to System > Logs > Configuration > Remote Logging.
The core BIG-IP AFM functions are part of TMM and use a separate logging system. Messages from this logging
system can be forwarded to: local syslog by using the logging destination local-syslog-publisher, the native
BIG-IP AFM database. You can use the logging destination local-db-publisher, a remote logging server that uses
syslog, the IPFIX protocol, Splunk, or Arcsight
Logging guidelines
F5 recommends enabling logging on each drop|reject rule applied to the Network Firewall and IP Intelligence.
Configure this logging for every object that the firewall applies to. Configure an Aggregate Rate Limit in logging
profiles used with the Network Firewall and IP Intelligence.
F5 also highly recommends external logging to ensure optimal performance of your BIG-IP AFM system.
Some regulatory environments require logging all firewall events, including those whose action is Accept.
Profile settings
Logging profiles are used to define how firewall and DoS logs are sent to the log publisher. In logging profiles you
can configure or modify log components such as the fields to send in a log message.
The Network Firewall profile also allows aggregate rate-limiting of log messages. This rate-limiting controls how
many messages/second BIG-IP AFM sends to the destination.
This setting is useful for extremely high throughput firewalls or firewalls being flooded with bad traffic. After the
rate limit is reached, additional messages are not logged. Log message volume is sampled from that point, as well
as summary messages detailing how many log messages have been dropped. Log throttling is an important tool
to keep the log destination functional.
For more information on logging profiles, refer to AskF5 article: K17398: Configuring the High Speed Logging traffic
distribution method.
Logging daemons
BIG-IP AFM uses two daemons to display and populate log data:
• Mgmt_acld = mgmt_acld is primarily responsible for maintaining statistics, logging, and reporting of
Management Port BIG-IP AFM Rules. In addition, it also periodically updates the statistics counters for
management port rules.
• Mysqld is the database server storing data for reporting/charts and event logs reports.
For more detailed information on BIG-IP AFM daemons, refer to AskF5 article: K14387: Overview of BIG-IP AFM
daemons.
70
Logging destinations
BIG-IP AFM messages can be logged directly on the BIG-IP system or to an external system. In making the
decision, consider performance impact factors such as disk space use, log retention policy, number of logs being
sent, logging while under attack, and log throttling.
F5 recommends using the IPFIX logging format for external logging for the fastest performance.
BIG-IP systems can be configured to log messages locally or to remote high-speed log servers.
For more detailed information on configuring log destination, refer to Configuring Remote High-Speed Logging
in External Monitoring of BIG-IP Systems: Implementations.
Local logging
If logging locally, events are logged to local-db-publisher if using the Security > Event Logs viewer and local-
syslog-publisher for local syslog.
Local logging of BIG-IP AFM and DoS events are useful for initial setup and testing but the recommended practice
is to use only remote logging for production level traffic. This is because there is a performance cost associated
with local log destinations due to I/O constraints and other factors. Turning on local logging as a troubleshooting
step may also be useful.
If using local-db-publisher, be aware that the number of messages stored is capped at 1.25 million. This may not
be adequate for some environments.
Tip Firewall rules can be created from a log entry when using the Security Event Logs viewer for network
firewall events. Check the log entry and click create rule. This opens the New Rule editing page. This is
useful in situations where there is a need to quickly resolve an issue or create a temporary rule in place for
traffic being blocked or allowed.
Remote logging
In order to log remotely, a pool of servers must be created and added to an unformatted destination which can in
turn be added to a formatted destination. The first consideration is the pool. This is a standard LTM pool that
contains all of the remote servers that should receive logs. By default, messages goes to the first pool member
selected until either the rate of the HSL traffic exceeds what the remote log server is capable of accepting or the
HSL connection to the remote log server is lost.
Tip When troubleshooting, remember pool stats can be used to determine where logs are being sent. When
using the pool in a high speed log destination, traffic can be distributed in an adaptive, balanced or
replicated manner.
For more detailed information on remote logging, refer to AskF5 article: K17398: Configuring the High Speed
Logging traffic distribution method.
Another consideration with log destinations, is the format to send the logs in. Firewall and DoS logs can both be
71
forwarded in ArcSight, Splunk, Syslog or IPFIX formats. If logs do not appear as expected on the remote device, it
may be that the formatted destination does not match the remote server.
IPFIX has been observed to have the fastest performance. It’s a binary format and so is not directly human
readable.
Syslog destinations on the BIG-IP come in three varieties:
• BSD: provides field names at the cost of larger log messages.
• Syslog: provides just the field data which is harder to read but leaner. Most log consoles can provide the
fields for human readability.
• Legacy BIG-IP: deprecated.
The following are a few third-party tools available to use:
• Splunk
• ArcSight
IPFIX
The BIG-IP system may be configured to log BIG-IP AFM events over the IPFIX protocol. These are binary-
encoded strings that are defined by IPFIX templates. These strings are then sent off-box to an external IPFIX
collector.
For more detailed information on configuring IPFIX, refer to Logging Network Firewall Events to IPFIX
Collectors in External Monitoring of BIG-IP Systems: Implementations.
Debug logging
The BIG-IP system’s default logging levels are set to capture useful information about BIG-IP system events while
maintaining minimal impact on system resources.
If the default logging level does not provide enough detail, and you can enable debug logging to gather more
detailed diagnostic information. The greater logging detail the debug level logs places added demand on BIG-IP
system processor and hard disk space.
With the BIG-IP system, you can configure the level of information that the system logs for events related to traffic
management.
For more detailed information on levels of logging, refer to AskF5 article: K5532: Configuring the level of information
logged for TMM-specific events.
Disk space
Disk space use can increase significantly with local logging, debug log level, and a runaway tcpdump process.
72
For more detailed information on disk space maintenance on a BIG-IP system, refer to AskF5 article: K14403:
Maintaining disk space on the BIG-IP system (11.x - 12.x).
73
TROUBLESHOOTING—Troubleshooting traffic flow
Troubleshooting
In order to troubleshoot issues related to BIG-IP® AFM™, a solid understanding is needed of the traffic flow
process and the internal structure of BIG-IP. This chapter gives an introduction to the packet flow process and the
tools needed for troubleshooting.
Troubleshooting traffic flow

BIG-IP uses traffic flows to efficiently pass traffic from a client to internal resources. BIG-IP AFM works with
TMOS® to manage the access control process which includes flow management. When a packet arrives at BIG-IP,
TMOS first examines whether the packet received belongs to an already existing flow or the first packet is a new
flow.
Figure 8.1: BIG-IP AFM packet flow
For a detailed understanding of the packet processing flow, refer to “Packet Flow”.
Packet Tester
Beginning in BIG-IP 13.0, you can troubleshoot your BIG-IP AFM issues using the Packet Tester. The Packet Tester
can help troubleshoot issues such as when packets are dropped because a policy doesn’t exist for a particular
feature (IP Intelligence, Network Firewall, or DoS Protection) or context (Global, Route Domain, or Virtual Server) or
when there’s no listener for a particular destination IP address.
74
Packet Tester allows you to inject a packet, configured with parameters of your choosing, into the BIG-IP system
traffic processing (L3/IP Input in figure x.x) and track what happens to that packet. Packet Tester can report
whether or not IP Intelligence, Network Firewall, or DoS Protection drop the packet and, if so, provide the context
(Global, Route Domain, or Virtual Server) in which the drop occurs.
You can configure the Packet Tester for with options specific for TCP, UDP, SCTP, or ICMP, as well as source and
destination address information, and TTL.
To test staged policies before activating them, enable Use Staged Policy (disabled by default).
To generate log messages from interactions with injected packets, enable Trigger Log (disabled by default).
To run the Packet Tester using the TMOS Shell (tmsh)
• Use the following command syntax:
#tmsh show net packet-tester dst-addr <destination ip address> src-addr

<source ip address> protocol <protocol name> src-<source location>
For example:
# tmsh show net packet-tester security dst-addr 10.10.10.210 src-addr 6.6.1.1

protocol icmp src-vlan /Common/internal
Output appears similar to the following:
*************************
Packet Tester Data:
*************************
Packet SrcIP/Port:6.6.1.1/0 Src Vlan /Common/internal
Packet DstIP/Port:10.10.10.210/0
Packet Protocol: icmp
Packet Trace Option: Check Staged:Disable, Trigger Log:Disable
Stage:Device-IP Intelligence
Result: Allow (No Policy)
Stage:Device-DoS
Result: Allow (No Anomaly)
Stage:Device-Access Control
Result: Allow (No Match)
Stage:Route Domain-IP Intelligence (/Common/0)
Stage:Route Domain-Access Control (/Common/0)
75
Stage:Listener-IP Intelligence (No Listener)
Result: Not Applicable
Stage:Listener-DoS (No Listener)
Stage:Listener-Access Control (No Listener)
Stage:Device Default
Result: Drop (Flow Miss)
Final Result
Packet SrcIP/Port:6.6.1.1/0 Src Vlan /Common/internal
Packet DstIP/Port:10.10.10.210/0
Packet Protocol: icmp
Packet Trace Option: Check Staged:Disable, Trigger Log:Disable
Device Default Rule
Final Action : Drop
Total records returned: 1
Use case examples
Problem: You are experiencing repeated, consistent packet drops to or from a specified host. The connections
are always dropped or rejected. Logs are not informative, either because they haven’t been set up or because
they’re too excessive to review due to noise.
Approach: You configure a packet that matches the host and inject it.
You review the results to discover whether packets are being dropped and, if so, by which feature.
Problem: You are experiencing repeated but intermittent packet drops to or from a specified host. You suspect
that the DoS Protection feature may be rate-limiting legitimate application traffic.
Approach: During times of DoS stress, you inject a packet that matches your host information.
You review the results. In this case, you may get a false negative in that you can’t rule out DoS protection
interference because your injected packets may not exceed the enforced rate limit and trigger the issue; however,
if the Packet Tester shows that DoS Protection does drop a test packet, then you know that it DoS Protection
rate-limiting is an issue.
76
Limitations
The Packet Tester has some limitations to keep in mind:
• You can only insert one packet at a time, even if you tmsh command scripts, so it is difficult to test DoS
Protection. See “Use case examples”.
• Dynamic Signatures is not supported and does not appear in the Packet Tester report.
• At this time you can generate only a limited range of packet types, which don’t include many DoS vectors for
invalid packet types.
• Injected packets will not traverse hardware.
• Injected packets can’t be captured using tcpdump.
Note Packet Testing checks each individual mechanism (Device IP Intelligence, Device DoS Processing,
and so on) through which the test packet passes and displays the results in a platform-dependent order
that do not conform to the actual order of packet processing.
L4 mirroring
While F5 recommends enabling connection mirroring only for essential connections, a BIG-IP system can be
configured to mirror some, all, or no connection flows in a high availability environment.
The Connection Mirroring checkbox is apparent when creating a virtual server and is only functional when a high
availability group is properly configured and has at least two members in it.
When configuring mirroring, F5 recommends using a dedicated VLAN and physical interface for all session
mirroring traffic.
Environments requiring a significant amount of connection mirroring may impact BIG-IP performance. F5
recommends using the following settings for optimal performance:
Set tm.fastl4_ack_mirror db setting to Disable to increase overall system performance when mirroring traffic for
fastL4 virtual servers.
To disable tm.fastl4_ack_mirror using tmsh at the command line
tmsh modify /sys db tm.fastl4 _ ack _ mirror value disable
If you do not disable this setting, you may experience HA Table disconnects under heavy load.
To view HA Table disconnects in iHealth
1. Log in to iHealth.
2. Click the name of the QKView file you want to view.
77
TROUBLESHOOTING—BIG-IP AFM Network Firewall modes
3. Navigate to Commands > UNIX > TMOS > tmctl –a (cluster).
4. Click ha_stat.
5. Look at the overflows, expires, and aborts.
Hits in these fields indicate that the buffer setting for statemirror.queuelen may be set too low for
the volume of mirroring required (min:1048576, max:268435456, default: 8388608). To fix this
problem, raise the queue length value until the overflows reported are near zero.
To modify the statemirror.queuelen value using tmsh from the command line
tmsh modify /sys db statemirror.queuelen value <new value>
To check the statemirror.queuelen value using tmctl from the command line
tmctl -w 250 -i -d /var/tmstat/blade ha _ stat
Another optimization for mirroring performance requires setting Nagle in the mirroring connection key.
To set Nagle in the mirroring connection key using tmsh from the command line
tmsh modify /sys db tm.fastl4 _ mirroring _ taciturn { value “enable” }
BIG-IP AFM Network Firewall modes

You can configure BIG-IP AFM Network Firewall to operate in ADC mode or firewall mode. You can also
configure it to globally drop or reject traffic.
ADC mode
By default, the Network Firewall is configured in ADC mode. In ADC mode all traffic destined for a virtual server is
allowed unless an ACL specifically denies it. In this mode, all traffic is allowed to virtual servers and self IPs on the
system, and any traffic you want to block must be explicitly specified. This applies only to the virtual server and
self IP contexts on the system.
To configure the Network Firewall in ADC mode using the Configuration utility
If you have changed the firewall setting to Firewall mode, you can configure the BIG-IP Network Firewall back to
ADC mode.
78
2. From the Virtual Server & Self IP Contexts list, click the default action Accept for the self IP and
virtual server contexts.
3. Click Update.
Firewall mode
You can configure the BIG-IP Network Firewall to drop or reject all traffic not explicitly allowed. Firewall mode
applies a default deny policy to all self IPs and virtual servers.
To configure the Network Firewall in Firewall mode using the Configuration utility
2. From the Virtual Server & Self IP Contexts list, click the default action for the self IP and virtual
server contexts.
3. Select Drop to silently drop all traffic to virtual servers and self IPs unless specifically allowed.
4. Select Reject to drop all traffic to virtual servers and self IPs unless specifically allowed, and to
send the appropriate reject message for the protocol.
5. Click Update.
Globally drop or reject traffic
If traffic to or from the BIG-IP Network Firewall does not match a rule, the global rule handles the traffic. You can
set the global rule to drop traffic or to reject traffic. The global rule rejects unmatched traffic by default.
Note Management port traffic is not handled by the global rule. Management port rules must be explicitly
defined for the management port context.
To configure the Network Firewall to globally drop or reject traffic
2. From the Global Context list, click the default action for the global rule, when the traffic matches
no other rule.
3. Select Drop to drop traffic silently.
4. Select Reject to drop traffic, and send the appropriate reject message for the protocol.
79
5. Click Update.
To configure the Network Firewall using tmsh at the command line
tmsh modify /sys db tm.fw.defaultaction value <value>
Note If you are using ConfigSync to synchronize two or more BIG-IPs in a Device Group and if the BIG-IP
AFM is operating in firewall mode, traffic between the BIG-IPs must be explicitly allowed by policy. This is
because traffic destined to a self IP or virtual server in this mode has an implicit deny rule, which prevents
BIG-IP systems from establishing connectivity between self IP addresses for services such as network
failover, connection mirroring, or configSync.
To explicitly allow this traffic, you can use the built-in firewall rules_sys_self_allow_defaults or _sys_self_
allow_management, applied to the specific self IPs used for connectivity between the device group.
BIG-IP device rules
A subset of traffic is sourced from or destined to the BIG-IP AFM as part of normal management and operations.
This traffic should be managed and secured with policies.
Management and troubleshooting varies, depending on the type of traffic as well as the interface processing the
traffic.
Traffic sourced from a BIG-IP self IP is allowed outbound of the BIG-IP AFM and does not require any ACL policy
to correctly operate for cases such as outbound log traffic or network high availability. Inbound self IP traffic must
be allowed through a firewall context, to be accepted and processed by the self IP and TMOS.
The BIG-IP management port is out of band, accessed from the control plane and is not affected by global firewall
rules. This port can be secured through a management port firewall policy that explicitly allows or denies traffic to
and from the management port. Unlike self IPs, outbound traffic allowed by the management port policy does not
create a stateful flow. Therefore, return traffic must be allowed into the management port when appropriate.
For example, a policy may allow traffic from remote authentication servers into the BIG-IP system using a
management policy rule in response to the outbound authentication request.
Flow eviction
As part of BIG-IP device security, TMOS manages the memory used by the system, including the connection table
resources. If a BIG-IP system becomes memory-constrained due to network events such as a DDoS attack or
other high traffic condition, TMOS evicts older idle flows in order to protect the BIG-IP from memory exhaustion
using adaptive connection reaping.
Eviction policies for adaptive reaping can be configured at the global, route domain, and virtual server contexts.
This allows granular control over how resources are preserved during these memory-constrained conditions.
If BIG-IP AFM is experiencing memory constraint, idle flows can be removed, forcing connections to be re-
established when they are no longer idle. This might interrupt client traffic.
80
There are four eviction strategies which can influence the reaper’s selection of connections to remove from the
connection table:
• Bias Idle specifies that the system biases flow removal toward the existing flows that have been idle, with
no payload bytes, for the longest.
• Bias Oldest specifies that the system biases flow removal toward the oldest existing flows.
• Bias Bytes evicts traffic flows that show less data being transferred. Configure the grace period to allow
new connections to be spun up.
• Low Priority specifies objects identified as lower priority by the flow removal strategy:
• Route-domains
• Virtual servers
• Specified ports and protocols
• Countries
To create an eviction policy at the global context using tmsh at the command line
tmsh create /ltm eviction-policy my-dos-eviction-policy slow-flow {enabled

true } strategies { bias-bytes { enabled true delay 10 } low-priority-
geographies { countries add { US } enabled true } }
To apply the eviction policy to the virtual server context (based on connection counts) using tmsh at the
command line
tmsh modify /ltm virtual vs _ web flow-eviction-policy my-evict-policy
tmsh modify /net route-domain 0 connection-limit 100000
To apply the eviction policy to the route domain context (based on connection counts) using tmsh at the
command line
tmsh modify /net route-domain 1 flow-eviction-policy my-evict-policy
tmsh modify /ltm virtual vs _ web connection-limit 100000
To apply the eviction policy to the global context (based on connection counts) using tmsh at the command
line
81
tmsh modify /ltm global-settings connection global-flow-eviction-policy

my-evict-policy
To validate the eviction policy performance in any context using tmsh at the command line
watch tmctl flow _ eviction _ policy _ stat
The output appears similar to the following:
policy _ name swept _ context context _ name evicted
/Common/default-eviction-policy route domain /Common/0 0
/Common/default-eviction-policy virtual server /Common/vs _ web 0
/Common/my-dos-eviction-policy route domain /Common/0 701
/Common/my-dos-eviction-policy virtual server /Common/vs _ web 501
/Common/my-dos-eviction-policy virtual server /Common/vs _ web2 200
route domain
/Common/sweeper /Common/0 5460
virtual server
/Common/sweeper /Common/vs _ web 5460
virtual server
/Common/sweeper /Common/vs _ web2 0
For more detailed information on flow eviction, refer to AskF5™ article: K15740: Overview of adaptive connection
reaping (11.6.0 and later).
Slow flow eviction
The Slowloris attack is a denial of service attack which allows an attacker to take down a web server with minimal
bandwidth and side effects on unrelated services and ports. Slowloris initiates an HTTP request but never
completes it. This keeps connections to the target web server open and holds them open as long as possible by
opening connections to the target web server and sending a partial request.
BIG-IP AFM uses slow flow monitoring to mitigate this class of attack. Slow flow monitoring directs the sweeper to
detect and optionally delete connections that are not moving data below the defined threshold rate. The sweeper
routinely goes through the connection table and evicts expired connections, so this additional task does not have
a significant performance impact.
The slow flow monitoring settings allow some flexibility to allow applications that require slow connections. These
settings include the following:
• Grace Period provides connections with time to ramp up before they are required to move data above the
threshold rate.
• Slow Flow Throttling – Percent permits a configured percentage of slow connections to remain.
• Slow Flow Throttling – Absolute permits the configured number of slow connections to remain.
82
TROUBLESHOOTING—Policy compilation
For more detailed information on eviction policies eviction, refer to AskF5 article: K15821: Overview of eviction
policies.
Rule actions
During troubleshooting, you may find that rule actions adversely affect the behavior of BIG-IP AFM.
For example, if a rule is set at a global context with an action of Accept but when troubleshooting the connection
flow traffic does not flow from source to destination, it may be that rule actions are at issue. If so, you can
troubleshoot by finding the answers to the following questions:
• Is there a route domain policy in place that could be dropping the traffic?
• Is there a virtual server policy in place that could be dropping the traffic?
• If running in Firewall mode (and not ADC mode) is the virtual server default action dropping the traffic?
If the firewall rule’s expected behavior is to accept and create a new flow rather than continue evaluating the
connection in another firewall context, use Accept Decisively as the rule action.
If the firewall rule’s expected behavior is to accept but continue evaluating other contexts, make sure there are
appropriate accept rules to match all contexts to allow the traffic to pass.
One way to resolve the issue described in the example is to use a staged policy and track ACL matches there.
For more detailed information on firewall rule actions, refer to Network Firewall Implementation Guide.
Note For information about how to locate F5 product guides, refer to AskF5 article: K12453464: Finding
Policy compilation
BIG-IP AFM contains control plane processes that compile and instantiate firewall policies to TMOS. When a
configuration change is made, the following processes implement the new firewall policy:
1. mcpd validates the configuration changes and signals the compiler.
2. pccd compiles the new policy into a binary format.
The policy compiles.
3. pccd signals tmm to use the new policy (serialization).
For detailed information of BIG-IP AFM processes, refer to AskF5 article: K14387: Overview of BIG-IP AFM
daemons.
Firewall compiler
Depending on the size of the policy, pccd can take up to a couple minutes to compile and serialize a new policy.
83
TROUBLESHOOTING—
To view existing policy statistics in the Configuration utility
1. Navigate to Security ›› Network Firewall : Active Rules.
2. Select the context you want to view (in this case, Global, Route Domain, or Virtual Server).
To view existing policy statistics using tmsh at the command line
tmsh show /security firewall container-stat field-fmt
Output of the command appears similar to the following example:
security firewall security {
activation-time-fmt Mar 29 2016 00:47:14-0400
compile-duration-fmt 0:0:0
container-size 12.2K
context-name global-firewall-rules
context-type global
ovrlpck-duration-fmt 0:0:0
policy-name my _ global _ policy
policy-type Enforced
process-mem 3.3M
rule-count 2
• activation-time-fmt is the timestamp the policy was serialized and activated.
• compile-duration-fmt is time required to build the policy.
• container-size is size of the compiled policy.
• process-mem is amount of transient memory required to build the policy: pccd uses control
plane memory to compile policies
• rule-count is the number of rules in the compiled policy.Each change in firewall policy (including
scheduled rules) results in a compilation and serialization of the policy. For historical data, see /
var/log/ltm for local syslog entries of the pccd daemon or remote syslog storage of these
messages.
84
TROUBLESHOOTING—Logging
Logging
Default rule logging
By default, implicit default firewall actions are not logged unless configured to do so. For example, when
troubleshooting a flow that is dropped by the default rule, no drop log messages are generated.
To turn on logging for implicit firewall actions using tmsh at the command line
• Type the following commands:
tmsh modify /sys db tm.fw.defaultrule.log

tmsh modify /sys db tm.fw.globaldefaultrule.log
tmsh modify /sys db tm.fw.stageddefaultrule.log
tmsh modify /sys db tm.fw.stagedglobaldefaultrule.log
Turning on logging for these actions may be helpful when troubleshooting dropped traffic; however, having these
actions logged during normal operation may create an unnecessary amount of logging.
Another method to troubleshoot the dropped traffic is to add an explicit Default Deny rule at the end of the
applied policy in BIG-IP AFM and configure the log attribute in the rule to avoid modifying the system db variables
listed above.
Audit
By default, BIG-IP is configured to log audit information of the BIG-IP system configuration to /var/log/audit.
Audit logging information includes configuration changes and the users that made them.
When audit logging is disabled, BIG-IP does not log configuration changes.
Note In BIG-IP TMOS 11.6 and earlier, audit logging is disabled by default. If you upgrade to a newer
version, this setting may be retained.
For more detailed information, refer to AskF5 article: K16304: Audit logging for BIG-IP configuration changes is
now enabled by default.
Tip BIG-IQ® Security offers more comprehensive Firewall Policy auditing and may be used to centrally
manage Firewall Policies, allowing auditing of multiple BIG-IP firewalls.
TCP reset troubleshooting
The BIG-IP system can be configured to issue TCP resets under various situations, both during flow creation as
well as after flow creation as part of idle flow eviction enforcement.
• When the Default Firewall Action under Security > Options : Network Firewall is set to Reject, BIG-IP
AFM generates a TCP reset message.
• When a flow connection idles out, by default the BIG-IP system sends a TCP reset to both the client and
server side of the connection flow. (This behavior can be enabled or disabled as a function of the relevant
85
TROUBLESHOOTING—Logging
FastL4 profile).
The BIG-IP system supports logging TCP reset causes within the packet, logging the TCP reset reason through
Syslog, or both. Depending on system load, local logging may not capture all resets due to rate limiting.
Enabling packet-level TCP reset provides a mechanism to view the TCP reset cause from a packet capture by
using tcpdump and the F5 Wireshark dissector.
For more detailed information on BIG-IP TCP reset logging and configuration settings, refer to AskF5 article:
K13223: Configuring the BIG-IP system to log TCP RST packets.
Logging troubleshooting
To view local log files in the /var/log/ directory from the command line
tail –f /var/local/ltm
If logging is not apparent locally or on your remote logging destination, verify that the log publisher
has been assigned.
To view DoS logging for the current configuration using tmsh at the command line
tmsh list /security dos device-security log-publisher
To view the current firewall logging settings using tmsh at the command line
tmsh list /security log profile global-network
If no profile is assigned it may be necessary to assign one.
To assign a DoS logging profile using tmsh at the command line
tmsh modify /security dos device-config dos-device-config log-publisher

<NAME>
To view DoS logging or to apply a log-publisher for BIG-IP AFM logging using tmsh at the command line
tmsh modify /security log profile global-network { network modify { global-

network publisher <NAME> } } }
86
TROUBLESHOOTING—Statistics
For additional information of creating or modifying logging configuration refer to: Configuring Remote High-
Speed Logging.
Statistics
Statistics are an important aspect of maintaining and troubleshooting BIG-IP AFM. When trying to identify whether
or not a firewall rule is working or how a DOS attack was detected and mitigated, it is helpful to know where to
look.
Statistics are available in the Configuration utility on the Security > Overview tab and the Reporting tab.
Overview provides a high-level view of what is going on with the system. It is divided into the following sections:
• Summary displays a mix of network and DoS information.
• Protocol displays HTTPS and DNS protocol security statistics (if configured for HTTPS and DNS security).
• Network displays Network Firewall statistics for BIG-IP AFM.
• DoS displays statistics related to global device DoS.
• Reporting provides detailed views of statistics for protocol, network, and DoS.
For more detailed information on BIG-IP AFM Security > Overview : Summary page, refer to AskF5 article:
K16703: The BIG-IP AFM Overview Summary page has two Add Widget links that offer different sets of display
methods.
Rules
To view statistics for firewall rules using the Configuration utility
1. Navigate to Security > Network Firewall : Active Rules.
This page displays important details on active rules, including rule hit counters and time stamps
for the last time the rule was hit.
2. The statistics for firewall rules only updates counters for active rules and not accumulated
counters for a rule list.
To view statistics for firewall rules using tmsh at the command line
tmsh show /security firewall rule-stat
Troubleshooting with tmsh at the command line
Several tools to with troubleshooting and analysis of BIG-IP AFM are available only using tmsh at the command
line.
87
TROUBLESHOOTING—Statistics
You can use tmsh to show security firewall matching-rule matches, tuples/arguments with the existing rule base,
and outputs rules that can match the arguments.
In the following example, the tmsh command requires all filters for match criteria. Wildcards are not supported for
VLAN or protocol.
tmsh show /security firewall matching-rule source-addr 10.1.1.245 source-port any

dest-addr 192.168.1.245 dest-port 80 vlan /Common/internal-vlab protocol tcp
Firewall Matching Rule:
-------------------------------------------------------------------
Context Type Context Name Policy Name Rule Name Action
-------------------------------------------------------------------
Route Domain /Common/0 /Common/rd _ policy accept _ defer Accept
When viewing Device DoS statistics, the tmsh command show security dos displays statistics of all global attack
vectors. This information can then be analyzed and is useful for additional tuning of DoS settings.
For each DoS attack type, the detection threshold signifies the packet rate at which BIG-IP DoS logs attack-
detected messages, based on the one-minute average, which is a value displayed in the security DoS output.
By watching the averages of typical system traffic, you can determine a baseline of expected packet rates and use
that baseline to set the detection thresholds and optionally the rate limit for DoS attack types.
The output of the command appears similar to the following example:
--------------------------------
Security::DoS Config: UDP flood
--------------------------------
Statistics Type Count
Attack Detected 0
Attack Count 0
Stats 1h Samples 46050652
Stats 185847228337
Stats Rate 137065
Stats 1m 136901
Stats 1h 158933
Drops 0
Drops Rate 0
88
TROUBLESHOOTING—Common troubleshooting tasks
Drops 1m 0
Drops 1h 0
Int Drops 4171
Int Drops Rate 0
Int Drops 1m 0
Int Drops 1h 0
WhiteList Hits 537102135052
Common troubleshooting tasks
Connection table management
The BIG-IP system contains a connection table for all flows. You can view the connection table and alter it to
remove existing flows prior to normal flow closure or idle timeout enforcement.
The interface to the connection table is provided by tmsh. You can use the connection table to see if a flow exists.
The following are best practices when working with the connection table:
• Always use IP address/Port/Protocol filters to narrow the return set of a show /sys connection command.
• Do not show all connection flows on a heavily loaded production system.
• Use the all-properties option to view detailed statistics of a flow including idle time, bits in/out.
The following shows a sample filter used to search for connection table entries:
tmsh show /sys conn cs-client-addr <IP ADDRESS> cs-server-port 4353
tmsh show /sys conn cs-client-addr 192.168.142.248 cs-server-port 4353
Sys::Connections
192.168.142.248:50241 10.10.20.245:4353 192.168.142.248:50241 10.10.20.245:4353 tcp 1 (tmm:

0) none
The following shows a more granular filter example with detailed output:
tmsh show /sys connection cs-client-addr <IP ADDRESS> cs-server-port 4353 all-
properties
tmsh show /sys connection cs-client-addr 192.168.142.248 cs-server-port 4353 all-

properties
Sys::Connections
192.168.142.248:50241 - 10.10.20.245:4353 - 192.168.142.248:50241 - 10.10.20.245:4353
-------------------------------------------------------------------------------------
89
TMM 0
Type self
Acceleration none
Protocol tcp
Idle Time 1
Idle Timeout 5
Unit ID 0
Lasthop /Common/internal 00:0c:29:e5:eb:6c
Virtual Path 10.10.20.245:4353
Conn Id 0
ClientSide ServerSide
Client Addr 192.168.142.248:50241 192.168.142.248:50241
Server Addr 10.10.20.245:4353 10.10.20.245:4353
Bits In 1.9K 0
Bits Out 0 1.9K
Packets In 4 0
Packets Out 0 4
tcpdump
The tcpdump utility is a command-line packet sniffer with many features and options. Use tcpdump to capture (to
a file) or view (to the console) packets for a tagged VLAN on the BIG-IP system. The syntax, flags, and options
specified when performing a packet capture using tcpdump determine what information is included in the packet
capture file and/or displayed to the console. F5 recommends filtering to limit the capture packet count and filter
what is being captured since running tcpdump can impact system performance.
Common flags for use with tcpdump
• -i specify an interface or VLAN name to capture data on
• :n low noise details
• :nn low and medium noise details
• :nnn low medium and high details
• -n disables name resolution

90
• -nn used to disable both name and service port resolution
• -c number of packets to capture
• -s snaplen used to specify the amount of each packet to capture.
• -w used to save to a file for review later requires <filename> to save data
• -r used to view a binary capture file requires <filename> to read capture file
Filtering is possible by host with the following options:
• port <port#> displays packets are either sourced from or destined to a port.
• src port <port#> displays packets that are sourced from a port.
• dst port <port#> displays packets that are destined to a port.
Filters can be combined with the expressions and example:
tcpdump -s0 src host <HOSTNAME> and dst port <PORT NUMBER>
tcpdump -s0 src host 192.168.1.1 and dst port 80
When using tcpdump with BIG-IP AFM, the directional flags of traffic can show traffic passing ACL evaluation or
potentially not passing ACL evaluation.
Consider the two following examples (remember to set the snaplen=0 to capture the full packet to see the f5
trailers).
tcpdump -nni 0.0 -s0 -c100 port 80 and host 10.1.1.245
16:26:38.726579 IP 192.168.245.245.1268 > 10.1.1.245.80: S 1614628366:1614628366(0) win

5792 <mss 1460,nop,nop,timestamp 1079282556 0> in tmm0 lis=
16:26:38.727625 IP 192.168.245.245.6017 > 10.1.1.245.80: S 3728806033:3728806033(0) win

16:26:37.217835 IP 192.168.245.245.58367 > 10.1.1.245.80: S 2430396241:2430396241(0) win

This second example illustrates the flow ingress and egress the BIG-IP.
tcpdump -nni 0.0 -s0 -c100 and host 10.1.1.245
16:13:56.946046 IP 192.168.245.245.6422 > 10.1.1.245.80: S 2181731049:2181731049(0) win

16:13:56.946079 IP 192.168.245.245.6422 > 10.1.1.245.80: S 2181731049:2181731049(0) win

5792 <mss 1460,nop,nop,timestamp 3586289132 0> out tmm8 lis=/Common/Forwarding _
TCP _ VS
In the first example, TCP SYNs are received and show coming in to the BIG-IP AFM, but there is no egress packet.
This may indicate that an ACL is blocking this traffic. If logging drops, this can be validated through syslog
analysis.
91
TROUBLESHOOTING—Troubleshooting using BIG-IQ
In the second example, the TCP SYN shows out of the BIG-IP AFM as well as matching a listener Forwarding_
TCP_VS. For this to occur, the initial connection must pass ACL evaluation.
For detailed information on tcpdump utility, refer to AskF5 article: K411: Overview of packet tracing with the
tcpdump utility.
ePVA Acceleration
When using BIG-IP platforms that support ePVA, tcpdump does not show all packets using the default
configuration.
If a packet capture is required on the BIG-IP, modify the fastl4 profile to change the offload state or fully disable
ePVA as required. Disabling ePVA acceleration may cause a performance impact, so F5 recommends careful
consideration before making these changes.
To minimize the effect of disabling acceleration when using network listeners, or on heavily utilized network traffic
virtual servers, create a host or network specific listener to apply the changes to for the troubleshooting session.
For detailed information on the ePVA feature, refer to AskF5 article: K12837: Overview of the ePVA feature and
AskF5 article: K6546: Recommended methods and limitations for running tcpdump on a BIG-IP system.
Troubleshooting using BIG-IQ

When using BIG-IQ to centrally manage BIG-IP AFM, there are some additional communication requirements and
processes that may affect security and device management operations.
BIG-IQ requires TCP 443 and 22 ports bi-directionally to ensure all functionality. When troubleshooting BIG-IQ
connectivity issues on the BIG-IP system, make sure that these ports are open using tools such as SSH, telnet,
and curl.
Perform these tests from the BIG-IQ to the BIG-IP system:
SSH command:
ssh -l root <IP ADDRESS>
SSH example:
ssh –l root 192.168.3.158
The authenticity of host ‘192.168.3.158 (192.168.3.158)’ can’t be established.
RSA key fingerprint is 6e:35:a8:8c:39:3f:24:90:c1:91:97:a9:3e:ed:23:99.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.168.3.158’ (RSA) to the list of known hosts.
Password:
Last login: Wed Mar 30 21:29:54 2016 from 192.168.3.1
[root@big-ip:Active:Standalone] config
92
TROUBLESHOOTING—Troubleshooting using BIG-IQ
Curl command:
curl –Ik <IP ADDRESS> | grep ‘HTTP/1.1’
Curl from BIG-IQ example:
curl -Ik https://10.192.165.76 | grep ‘HTTP/1.1’
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 173 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
HTTP/1.1 301 Moved Permanently
Curl from BIG-IP:
curl -Ik https://192.168.255.130 | grep ‘HTTP/1.1’
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 3991 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
HTTP/1.1 200 OK
REST version
BIG-IQ maintains REST packages on all managed BIG-IPs through an update process that deploys the requisite
RPM files from BIG-IP system to BIG-IP system.
To check the version installed on the BIG-IP using the advanced shell
rpm -qa | grep rest
f5-rest-java-libs-access-bigip-12.0.0-0.0.3800.i686
TS-asm-config-rest-12.0.0-0.0.606.i686
f5-rest-node-libs-12.0.0-0.0.3800.i686
f5-rest-presentation-adc-12.0.0-0.0.3800.i686
f5-rest-java-libs-adc-bigip-12.0.0-0.0.3800.i686
f5-rest-java-libs-adc-12.0.0-0.0.3800.i686
f5-rest-java-libs-mam-12.0.0-0.0.3800.i686
f5-rest-node-0.12.7-0.0.3800.x86 _ 64
f5-rest-rpmbuild-4.11.1-0.0.3800.i686
93
TROUBLESHOOTING—Stateful failover using connection mirroring
f5-rest-node-bigstart-12.0.0-0.0.3800.i686
f5-rest-java-host-12.0.0-0.0.3800.i686
f5-rest-presentation-libs-12.0.0-0.0.3800.i686
f5-rest-java-libs-indexing-12.0.0-0.0.3800.i686
f5-rest-mcp-schema-12.0.0-0.0.3800.i686
f5-rest-presentation-blocks-12.0.0-0.0.3800.i686
f5-rest-auth-lib-12.0.0-0.0.606.i686
f5-rest-java-libs-12.0.0-0.0.3800.i686
If the version is not correct, or some packages are incorrect, consider re-deploying the REST framework from
BIG-IQ to the managed BIG-IP system.
For more detailed information on troubleshooting BIG-IQ, refer to the following resource refer to AskF5 article:
K16307: Troubleshooting BIG-IQ device discovery failures.
REST processes
The BIG-IP REST interface contains several control plane daemons to provide API framework to manage and
control the BIG-IP system. Occasionally the processes may require troubleshooting or restarting to resolve REST
communication issues.
For more detailed information on how to restart processes via the advanced shell, refer to AskF5 article: K14736:
BIG-IQ daemons.
Device certificate
BIG-IQ uses the device certificate to communicate to BIG-IP systems. If the BIG-IP device certificate has expired
or there is a problem with the certificate contributing to an authentication issue, a possible solution is to generate
a new device certificate on the BIG-IP, followed by re-discovering the BIG-IP into BIG-IQ.
For more detailed information device certificates, refer to AskF5 article: K15664: Overview of BIG-IP device
certificates (11.x - 12.x) .
Stateful failover using connection mirroring

BIG-IP TMOS is stateful for TCP flows by design. This security feature causes an existing TCP flow, which is not
configured for mirroring to other devices in the cluster, to be rejected after a firewall failover. UDP flows are not
affected.
If the network design requires stateful failover of long-lived connections, connection mirroring must be used to
maintain the default stateful inspection behavior of BIG-IP. When failover from an active to standby BIG-IP occurs,
mirrored connection table entries are available for flow lookup and do not require an additional ACL match to be
re-applied.
94
TROUBLESHOOTING—DoS statistics output
To determine whether or not this process affects an existing flow, perform a filtered show sys connection
command on both the active and standby BIG-IP system. If the connection flow exists on both, the flow is
mirrored and failover is stateful.
For more detailed information on stateful failover using connection mirroring, refer to AskF5 article: K13478:
Overview of connection and persistence mirroring (11.x - 12.x).
DoS statistics output

The following fields appear in the DoS statistics output for an attack type:
• Attack Detected toggles from 0 to 1 when a potential attack is detected. This resets to 0 once the attack
is stopped.
• Attack Count represents the total number of times the attack was detected for this BIG-IP AFM DoS
vector since the last boot.
The stats_1h_samples counter tracks the number of samples that BIG-IP AFM received in the previous hour.
BIG-IP AFM sampling rate is once per second. Each second it increases by one until an attack is detected.
Once the stats_1h_samples reaches 3600, BIG-IP AFM uses a detection threshold percent value for that DoS
vector for attack detection.
BIG-IP AFM uses the lower value between detection threshold pps and detection threshold percent value for
attack detection when it has an enough number of samples.
Stats: Total number of packets that BIG-IP/AFM-DoS vector received since the last boot.
Stats Rate: Packets that BIG-IP AFM-DoS vector saw in last second.
Stats 1m: Packets that BIG-IP AFM-DoS vector saw in last minute.
Stats 1h: Packets that BIG-IP AFM-DoS vector saw in last hour until attack detected.
Drops: Total number of packets dropped by BIG-IP AFM-DoS vector since the last boot.
Drops Rate: Total number of packets dropped by BIG-IP AFM-DoS vector in the last second.
Drops 1m: Total number of packets dropped by BIG-IP AFM-DoS vector in last minute.
Drops 1h: Total number of packets dropped by BIG-IP AFM-DoS vector in last hour until attack detected.
Int Drops: Total number of packets dropped in hardware since the last boot.
Int Drops Rate: Total number of packets dropped by BIG-IP AFM-DoS vector in hardware in last second.
Int Drops 1m: Total number of packets dropped by BIG-IP AFM-DoS vector in hardware in last minute.
Int Drops 1h: Total number of packets dropped by BIG-IP AFM-DoS vector in hardware in last hour.
Whitelist Hits: Total number of packets that hit the Whitelist for a particular BIG-IP AFM-DoS vector since
the last boot. This includes total packet count that match the Whitelist for that vector both in software and
95
TROUBLESHOOTING—IP Intelligence
hardware.
IP Intelligence
IP Intelligence statistics can be viewed from tmsh. tmsh commands show the current status of the IP reputation
feed as well as IP Intelligence information.
IP reputation status shows the current timestamp of the IP Intelligence update and the address count from the
most recent update.
tmsh show /sys iprep-status
-----------------------------------------------------------------------
Sys::IP Reputation Database Status
-----------------------------------------------------------------------
Last time the server was contacted for updates 03/14/2016 17:41:10
Last time an update was received 03/14/2016 16:50:34
Total number of IP Addresses in the database 8243809
Number of IP Addresses received in the last update 34766
If Last time an update was received returns a value of failed or none verify a BIG-IP DNS resolver is
configured.
To show an IP address in the IP Intelligence database using tmsh at the command line
tmsh show /security ip info address 1.1.1.1
The output of the command appears similar to the following example:
Security::IP Intelligence Address : 1.1.1.1
Global context
IP Intelligence Sources : User-defined
Whitelisted (Source) : no
Whitelisted (Destination) : no
Policy Action (Source) : drop
Policy Action (Destination) : allow
Match Type : Source
96
TROUBLESHOOTING—IP Intelligence
Categories (Source) (1) : auto-blacklist
Categories (Destination) (0)
97
OPTIMIZING THE SUPPORT EXPERIENCE—F5 technical support commitment
Optimizing the Support Experience

F5 technical support commitment
F5® strives to continuously improve its support service and create closer customer relationships. Designed to
provide assistance with specific break-fix issues and ongoing maintenance of F5 products, F5 professional
support services are consistently high-quality.
This means:
• F5 network support engineers conduct themselves professionally at all times.
• F5 is committed to providing the best customer experience possible.
• F5 treats customers are with respect and give them every consideration possible.
• F5 aims to provide resolutions the first time, every time.
• You can ask for manager escalation for unresolved or “site down” issues.
Some technical support issues arise from configuration errors, either within the BIG-IP® system or with other
devices in the network. In other cases, a misunderstanding of BIG-IP capabilities can lead to support questions
and issues. Although F5 does everything possible to prevent defects in BIG-IP hardware and software, these
issues may still arise periodically. Regardless of the root cause of a problem, the goal is to resolve any issues
quickly.
F5 technical support offerings
A variety of technical support offerings are available to provide the right level of support for any organization.
F5 Standard and Premium Support include remote assistance from F5 network support engineers, both online and
over the phone.
Premium Plus customers receive priority status at F5, with fast, easy access to a dedicated team of senior-level,
F5-certified network support engineers and a Technical Account Manager.
To learn more, refer to F5 Technical Support Offerings or send email to services@f5.com.
Professional services
Take advantage of the full range of F5 Professional Services to help you design, customize, and implement a
solution that is right for your IT infrastructure and which supports your business goals.
Professional Services (f5.com/support/professional-services) provides information on a wide range of F5

Professional Services offerings and Professional Services Partners. You can use our online forms to request
Consulting Services OnDemand for custom, shorter scope consulting engagements, or iRules® OnDemand to get
fast access to iRules scripts tailored to your specific needs.
You can make an online request for specific support services by filling out a request form:
98
OPTIMIZING THE SUPPORT EXPERIENCE—F5 certification
• Consulting request form (https://www.f5.com/services/professional-services/request-f5-professional-

services).
GUARDIAN Professional Services Partners
F5 GUARDIAN® Professional Services Partners are authorized as installation providers and are also available to
assist you. F5 GUARDIANs are selected because they have the skills and experience required to ensure successful
implementations of F5 BIG-IP installations.
Refer to F5 GUARDIAN Professional Service Partners (f5.com/support/professional-services#guardian) for a

complete list of partners.
F5 certification
F5 Certified® exams test the skills and knowledge necessary to be successful when working with today’s
application delivery challenges. Our technically relevant and appropriate exams deliver consistently reproducible
results that guarantee excellence in those that achieve certification.
Certification levels
F5 Certified! is the F5 certification program, with a progressive program of four levels (Administrator, Specialist,
Expert, and Professional), each of which build on the skills and knowledge demonstrated on previous exams.
C1 – F5 Certified BIG-IP Administrator (F5-CA)
The starting point for all certifications: a certified BIG-IP Administrator has basic network and application
knowledge to be successful in application delivery.
C2 – F5 Certified Technology Specialists (F5-CTS)
The Technology Specialist certification assures employers that the candidate is fully qualified to design,
implement, and maintain that specific product and its advanced features.
C3 – F5 Certified Solution Expert (F5-CSE)
The Solution Expert focuses on how F5 technologies combine with industry technology to create real-world
business solutions.
C4 – F5 Certified Application Delivery Engineer (F5-CADE)
The Application Delivery Engineer certification exam and requirements are still under development.
C5 – F5 Certified Application Delivery Architect (F5-CADA)
The Application Delivery Architect certification exam and requirements are still under development.
Certificate expiration
F5 certifications are valid for two (2) years. Three months before the expiration date, the holder becomes
recertification-eligible and can register for the exam necessary to re-certify. Only the last exam in the highest level
99
OPTIMIZING THE SUPPORT EXPERIENCE—Self-help
certification achieved needs to be retaken.
Certification beta program
F5 uses beta exams in the creation of all our exams and to maintain their relevancy and accuracy after production.
Beta exams are open to all and give candidates an opportunity to have an impact on the F5 Certified program.
While beta exams are twice as long, they cost less than regular exams and give candidates the chance to leave
feedback on the exam. Beta exams are critical to our exam development process and a great way to change the
F5 Certified program for the better.
Get involved
There are a several ways to get involved with the F5 certification beta program:
• Beta participation. Interested in taking our beta exams? Contact us at F5Certification@f5.com to learn
more.
• Exam development. Contact us at F5Certification@f5.com if you’re interested in helping us create our

Certified exams.
• LinkedIn community. Join us on LinkedIn (https://www.linkedin.com/company/f5-networks) for answers to

frequently asked questions, community developed resources, and more.
Note: This link takes you to a resource outside of F5, and it is possible that the document may be removed
without our knowledge.
Visit F5 Credential Manager System (certification.f5.com) for information or follow the steps to get registered.
Self-help
F5 offers a number of resources to assist in managing and supporting your F5 systems:
• AskF5™ (support.f5.com)
• Downloads (downloads.f5.com) User name and password required.
• Security Updates (interact.f5.com/AskF5-SubscriptionCenter.html)
• BIG-IP iHealth® (f5.com/support/tools/ihealth)
• TechNews (interact.f5.com/AskF5-SubscriptionCenter.html)
• RSS feeds (https://support.f5.com/csp/article/K9957)
• DevCentral (devcentral.f5.com/) User name and password required.
• F5 Training Programs and Education (f5.com/education/training)
100
AskF5
AskF5 (support.f5.com) is a great resource for thousands of articles and other documents to help you manage your
F5 products more effectively. Step-by-step instructions, downloads, and links to additional resources give you the
means to solve known issues quickly and without delay, and to address potential issues before they become
reality.
Whether you want to search the knowledge base to research an issue, or you need the most recent news on your
F5 products, AskF5 is your source for product manuals, operations guides, and release notes, including the
following:
• F5 announcements
• Known issues
• Security advisories
• Recommended practices
• Troubleshooting tips
• How-to documents
• Changes in behavior
• Diagnostic and firmware upgrades
• Hotfix information
• Product life cycle information
Downloads
Downloads are available from the F5 website. F5 strongly recommends that you keep your F5 software up-to-date,
including hotfixes, security updates, OPSWAT updates, BIG-IP Application Security Manager™ (ASM®) signature
files, and geolocation database updates. All software downloads are available from F5 Downloads (https://
downloads.f5.com).
Security updates
You can receive timely security updates and BIG-IP ASM attack signature updates from F5. When remote
vulnerabilities are discovered, F5 implements, tests, and releases security hotfixes for any vulnerable supported
version, and sends an email alert to the F5 Security mailing list. F5 encourages customers with an active support
account to subscribe to this list. For more information, refer to AskF5 article: K41942608: Overview of AskF5
security advisory articles.
101
BIG-IP iHealth
The BIG-IP iHealth® (iHealth.f5.com) diagnostic viewer is among the most important preventative tools to verify the
proper operation of your BIG-IP system. It ensures hardware and software are functioning at peak efficiency and
helps detect and address issues that may potentially affect F5 systems. BIG-IP iHealth is not integrated within the
BIG-IP system. It is hosted by F5 and can be accessed with any web browser.
F5 recommends you generate a BIG-IP iHealth QKView file on the BIG-IP system and upload it to iHealth on a
weekly basis in order to benefit from the many regularly occurring diagnostic updates. Uploading QKView files to
iHealth also provides F5 technical support with access to your QKView files if you open a support case.
By reviewing the iHealth output, many of the issues commonly experienced by customers can be resolved without
the need for opening a support case with F5.
TechNews
Communications Preference Center provides two email publications to help keep administrators up-to-date on
various F5 updates and other offerings:
• TechNews Weekly eNewsletter Up-to-date information about product and hotfix releases, new and
updated articles, and new feature notices.
• TechNews Notifications Do you want to get release information, but not a weekly eNewsletter? Sign up to
get an HTML notification email any time F5 releases a product or hotfix.
• Security Alerts Receive timely security updates and ASM attack signature updates from F5.
AskF5 recent additions and updates
You can subscribe to F5 RSS feeds to stay informed about new documents pertaining to your installed products or
products of interest. The Recent additions and updates page on AskF5 provides an overview of all the documents
recently added to AskF5.
New and updated articles are published over RSS. You can configure feeds that pertain to specific products,
product versions, and/or document sets. You can also aggregate multiple feeds into your RSS reader to display
one unified list of all selected documents.
DevCentral
DevCentral™ (devcentral.f5.com) is an online forum of F5 employees and customers that provides technical
documentation, discussion forums, blogs, media and more, related to application delivery networking. DevCentral
is a resource for education and advice on F5 technologies and is especially helpful for iRules and iApps®
developers. Access to DevCentral is free, but registration is required.
102
OPTIMIZING THE SUPPORT EXPERIENCE—Engage F5 Support
As a DevCentral member, you can do the following:
• Ask forum questions.
• Rate and comment on content.
• Contribute to “wikis.”
• Download lab projects.
• Join community interest groups.
• Solve problems and search for information.
• Attend online community events.
• View educational videos.
F5 training programs and education

F5 provides training programs and education, including traditional classroom learning opportunities, live online
training, and free, self-paced online courses to help you get the most out of your investment. F5 Education (f5.
com/education/training) provides links to course schedules, pricing, and registration details. It also has information
about alternative training solutions such as virtual and web-based training for those who cannot attend training in
person.
• In-person courses: F5 courses are available in multiple training facilities across five continents. Each one
combines instructor presentations, classroom discussions, and interactive labs. The hands-on learning
environment helps provide a fast track to accomplishing your goals.
• Virtual instructor-led training: Remote on-line courses mirror classroom training. Participants watch the
remote instructors’ live lecture online, participate in discussions, and perform lab exercises using remote
desktop control.
• Free online training: You can use the self-paced Getting Started series of free, web-based courses to learn
how to deploy F5 solutions to address your most common application delivery problems.
Engage F5 Support
F5 Support is designed to provide support for specific break-fix issues for customers with active support
contracts. For more information about F5 scope of support, refer to Support Policies.
103
F5 Support resources
F5 Support resources are available 24 hours a day, seven days a week, and are distributed around the world in
multiple support centers. Live support is provided by our professional network support engineers. Hours of
availability may vary depending on the service contract with F5.
Contact numbers
Standard, Premium, and Premium Plus Support customers can open and manage cases by calling one of the
contact numbers listed below.
North America
North America: 1-888-882-7535 or (206) 272-6500
Traffix® Support Only: 1-855-849-5673 or (206) 272-5774
Outside North America
Outside North America, Universal Toll-Free: +800 11 ASK 4 F5 or (800 11275 435)
Additional contact numbers by country
Australia: 1800 784 977
China: 010 5923 4123
Egypt: 0800-000-0537
Greece: 00-800-11275435
Hong Kong: 001-800-11275435
India: 000-800-650-1448; 000-800-650-0356 (Bharti Air users)
Indonesia: 001-803-657-904
Israel: 972-37630516
Japan: 81-3-5114-3260 or 0066-33-812670
Malaysia: 1-800-814994
New Zealand: 0800-44-9151
Philippines: 1-800-1-114-2564
Saudi Arabia: 800-844-7835
Singapore: 6411-1800
South Africa: 080-09-88889
104
South Korea: 002-800-11275435
Taiwan: 00-800-11275435
Thailand: 001-800-12-0666763
United Arab Emirates: 8000-3570-2437
United Kingdom: 44-(0)8707-744-655
Vietnam: 120-11585
Open a support case
F5 provides several resources to help find solutions to problems. Before opening a support case with F5 technical
support, check to see if the issue you are encountering is already documented.
The following is a list of resources to consult before opening a support case with F5:
• Deployment guides and white papers provide information about specific deployment configurations.
• AskF5 provides many articles including known issues, how-to guides, security issues, release notes, and
general information about products. Many of the issues customers encounter are already documented on
this site.
• BIG-IP iHealth enables customers to upload QKView files in order to verify operation of any BIG-IP system.
Gather information to open a support case
If your issue cannot be solved using the resources listed, and you need to open a support case, you must first
gather several pieces of important information about your issue. Providing full and accurate information helps
speed the path to resolution. The required information for the majority of situations is summarized below:
• The serial number or base registration key of the specific BIG-IP system requiring support. For more
information, refer to AskF5 article: K917: Finding the serial number or registration key of your F5 device.
• A full description of the issue. A clear problem statement is the best tool in helping to troubleshoot issues.
Your description should include as much of the following information as you can provide.
• Occurrences and changes: The date and times of initial and subsequent recurrences. Did this issue arise at
implementation or later? Were there any changes or updates made to the BIG-IP system prior to the issue
arising? If so, what were they?
• Symptoms: Ensuring your list of symptoms is as detailed as possible gives more information for support
personnel to correlate with.
• Scope of the problem: Note whether the problem is system-wide or limited to a particular configuration
feature, service, or element (such as VLAN, interface, application service, virtual server, pool, and so on).
• BIG-IP component: The feature, configuration element, or service being used when the problem occurred
(for example: portal access, network access, authentication services, VDI, Exchange).
105
• Steps to reproduce: The steps to reproduce the problem as accurately and in as much detail as possible.
Include expected behavior (what should happen) as well as actual behavior (what does happen).
• Errors: Complete text of any error messages produced.
• Environment: Current usage of the system. (Is this unit in production? If so, is there currently a workaround
in place?)
• Browsers: Types and versions, if applicable.
• Changes: System changes made immediately prior to the problem’s first occurrence. This may include
upgrades, hardware changes, network maintenance, and so on. Have any changes been made to resolve
the problem? If so, what were they?
• Issue Severity: A description of the impact the issue is having on your site or case severity
• Severity 1: Software or hardware conditions on your F5 device are preventing the execution of critical
business activities. The device does not power up or is not passing traffic.
• Severity 2: Software or hardware conditions on your F5 device are preventing or significantly impairing
high-level commerce or business activities.
• Severity 3: Software or hardware conditions on your F5 device are creating degradation of service or
functionality in normal business or commerce activities.
• Severity 4: Questions regarding configurations (“how to”), troubleshooting non-critical issues, or requests
for product functionality that are not part of the current product feature set.
• Contact and availability information including alternate contacts authorized to work on the problem with F5
Support. When there are more personnel available to work with F5 Support, the resolution of your issue may
be expedited.
• Remote access information, if possible.
• A QKView file obtained while problem symptoms are manifesting. A QKView of the system before the
occurrence is also useful. F5 recommends archiving QKView files regularly. For more information, refer to
BIG-IP iHealth in the TMOS Operations Guide.
• Product-specific information: Software versions and types of equipment in use.
• Platform and system. Version and provisioned software modules of the affected system.
To locate platform and system information using tmsh at the command line
tmsh show /sys hardware
106
<SNIP some of the output>
Platform
Name BIG-IP 3900
BIOS Revision F5 Platform: C106 OBJ-0314-03 BIOS (build: 010) Date: 02/15/12
Base MAC 00:01:d7:be:bf:80
System Information
Type C106
Chassis Serial f5-jspv-lzxw
Level 200/400 Part 200-0322-02 REV C
Switchboard Serial
Switchboard Part Revision
Host Board Serial
Host Board Part Revision
To copy software version and build number information at the command line
cat /VERSION
Product: BIG-IP
Version: 11.6.0
Build: 0.0.401
Sequence: 11.6.0.0.0.401.0
BaseBuild: 0.0.401
Edition: Final
Date: Mon Aug 11 21:08:03 PDT 2014
Built: 140811210803
Changelist: 1255500
JobID: 386543
2. Highlight and copy the output information and include it with your support case.
107
To copy provisioned module information at the command line
tmsh list /sys provision
sys provision afm { }
sys provision am { }
sys provision apm {
level nominal
sys provision asm { }
sys provision avr { }
sys provision fps { }
sys provision gtm { }
sys provision lc { }
sys provision ltm {
level minimum
sys provision pem { }
sys provision swg { }
2. Highlight and copy the output information and include it with your support case.
Open a support case
If you cannot find the answer to your problem using the resources listed above, you can open a support case
online, using F5 Support (f5.com/support).
Before you open a support case, you need to log in to F5. If you do not have an F5 login, you’ll need to register for
one.
To register for support access
1. Navigate to login.f5.com.
2. Click Register for an F5 Support Account.
3. Enter your email address.
108
4. Enter your contact information. If you have a support contract, click I have a support contract
and need access to MySupport.
5. Enter your serial number or registration key in the Serial Number or Registration Key (optional)
field.
After you’ve submitted your information, your service contract is reviewed. If your information is
accurate you receive an email from MySupport, and you can use this to open your case.
Send information to Support
After you have the information listed in “Gather information to open a support case”, transfer it to F5 technical
support following the steps in “Share diagnostic files with F5 technical support”. For more information, refer to
AskF5 article: K2486: Providing files to F5 Technical Support.
Share diagnostic files with F5 technical support
You can provide files to F5 Support using BIG-IP iHealth or Support Files, the F5 file transfer tool. Support Files
complies with global data protection standards to safeguard the data you send.
Prerequisites
Two categories of customers provide files to F5 Technical Support:
• Permanent account holders—Customers who have an F5 support account, including a user email and
password for the AskF5 website
• Temporary users—Associates of permanent account holders who assist them with uploading or
downloading files for an F5 service request
Obtaining a Support Files tool user name and password for a temporary user
If you are a permanent account holder who wants a temporary user to upload or download files for one of your
service requests, you must provide them with a user name and password for logging in to the Support Files
website.
The user name is the case ID from your service request, and the password is in the activity notes of your service
request. You can also request the password directly from F5 Technical Support via email. Temporary passwords
cannot be provided over the phone.
Note Temporary user credentials are only active for a specific service request.
To locate a password for a temporary user in the activity notes of your service request
1. Open the Service Request Details view.
2. In the Activities section, locate the temporary password which should appear in the following
format:
109
Case file access password : XXyy=zZzZ123
Uploading QKView files to BIG-IP iHealth
BIG-IP iHealth allows you to quickly diagnose the health and proper operation of your BIG-IP system, and provides
a convenient location for you to send diagnostic data for case resolution with F5 Technical Support.
If you are running BIG-IP 10.x or later and need to provide a QKView file to F5, the preferred way to do so is to
upload the file to the BIG-IP iHealth website. For more information, refer to K12878: Generating diagnostic data
using the qkview utility.
Uploading and downloading files using support files
Accessing support files
To access Support Files as a permanent account holder
1. In the upper-right corner of the AskF5 home page, click My Support.
If you have not already logged in, you are prompted to do so.
2. Under Service Requests, click the service request for which you want to upload or download
files.
3. On the right side of the Service Request Details section, click Manage Attachments.
The F5 Support Files site opens in a new window.
To access Support Files as a temporary user
• Navigate to the Support Files website and log in using the user name and password provided by a
permanent account holder.
Uploading files using a web browser
1. On the Home folder page, click the folder for the service request you want.
2. Click Incoming (upload to F5).
3. In the upper-right corner of the Upload to F5 page, click the Upload files icon.
4. In the Upload files dialog box, click Browse.
5. In the Open dialog box, navigate to each file you want to upload, point at it with your cursor, select
the check box that displays, and when you are finished selecting files, click Open.
Either a success or failure notification displays. When an upload fails, close the notification and try
110
again.
6. In the Upload Files dialog box, click Done.
Note You cannot see the files in the folder after uploading them.
Downloading files using a web browser
1. On the Home folder page, click the folder for the service request you want.
2. Click Outgoing (download from F5).
3. Select the check box next to the files you want to download.
4. In the upper-right corner of the Download from F5 page, click the Download selected items
icon.
5. Depending on which browser you have, you may be prompted to save your files to the location of
your choice, or they may simply download to your Downloads folder.
Uploading files using SFTP

For permanent account holders, your user name and password are the same as your AskF5 credentials. For
temporary users, your user name is the service request number, and your password must be the correct
passphrase for that service request.
Important Support Files does not support the Secure Copy (SCP) protocol.
Note Support Files supports the SFTP protocol, but only a subset of features provided by many SFTP
clients. The SFTP server does not support or allow setting file ownership or permissions, updating
timestamps, or creating symlinks.
Note The supportfiles.f5.com RSA server key MD5 fingerprint is MD5: 04:a6:4b:9b:d4:eb:48:97:15:e6:7f:90
:64:bf:35:96 and the SHA256 fingerprint is SHA256:stQCq50hEwDPfRMeRf/
Ya9dXcm1KCdx5I5llOwODgNU.
1. From the F5 device, SFTP to the supportfiles.f5.com site using the following syntax:
sftp user@host
For example:
sftp c123456@supportfiles.f5.com
or
sftp 1-12345678@supportfiles.f5.com
111
Note On the first attempt to connect, you must accept the host key. You should compare that output
with the fingerprints listed in this article.
2. When prompted for the password, enter the email address of the user associated with the case.
3. To upload the requested files, use the following command syntax for each file:
put <name _ of _ file> <SR _ number>/INCOMING/
For example:
put mybigip.conf C123456/INCOMING/
4. To exit the SFTP utility when all files have been uploaded, type the following command:
quit
For more information, refer to the manual or man pages for the SFTP utility by typing man sftp at the command
line.
You may also use external SFTP applications to upload files if they are on a workstation or other system.
Downloading files using SFTP

To download a file from Support Files, you must use the exact file name and location (path) provided by your F5
Technical Support representative.
Important Support Files does not support the SCP protocol.
Note Support Files supports the SFTP protocol, but only a subset of features provided by many SFTP
clients. The SFTP server does not support or allow setting file ownership or permissions, updating
timestamps, or creating symlinks.
1. From the F5 device, SFTP to the supportfiles.f5.com site using the following syntax:
sftp user@host
For example:
sftp C123456@supportfiles.f5.com
or
sftp 1-12345678@supportfiles.f5.com
2. When prompted for the password, enter the password.
3. To list the files available for download, type the following command:
ls C123456/OUTGOING
112
4. To download the requested files, use the following command syntax for each file:
Note The <full_path_to_file> section indicates the full path to the file.
get <full _ path _ to _ file>
For example:
get C123456/OUTGOING/ Hotfix-BIGIP-12.1.0.0.40.1434-ENG.iso
5. To exit the SFTP utility when all files have been downloaded, type the following command:
quit
You may also use external SFTP applications to download files if the files are on a workstation or on another
system.
113
LEGAL NOTICES—
Legal Notices
Trademarks
AAM, Access Policy Manager, Advanced Client Authentication, Advanced Firewall Manager, Advanced Routing,
AFM, APM, Application Acceleration Manager, Application Security Manager, Applications without Constraints,
ARX, AskF5, ASM, BIG-IP, BIG-IP EDGE GATEWAY, BIG-IQ, BIG-IP iControl, Cloud Extender, CloudFucious,
Cloud Manager, Clustered Multiprocessing, CMP, COHESION, Data Manager, DDoS Frontline, DDoS Hybrid
Defender, DDoS SWAT, Defense.net, DevCentral, DevCentral [DESIGN], DNS Express, DSC, DSI, Edge Client,
Edge Gateway, EDGE MOBILE, EDGE MOBILITY, EdgePortal, ELEVATE, EM, Enterprise Manager, ENGAGE, F5,
F5 Agility, F5 iApps, F5[DESIGN], F5 Certified [DESIGN], F5 iControl, F5 LINK CONTROLLER, F5 Networks,
F5SalesXchange [DESIGN], F5Synthesis, f5Synthesis, F5Synthesis[DESIGN], F5 TechXchange [DESIGN], F5
TMOS, Fast Application Proxy, Fast Cache, FCINCO, Global Traffic Manager, GTM, GUARDIAN, Herculon, iApps,
IBR, Intelligent Browser Referencing, Intelligent Compression, IPv6 Gateway, iCall, iControl, iHealth, iQuery,
iRules, iRules OnDemand, iSeries, iSession, L7 RateShaping, LC, Link Controller, Local Traffic Manager, LTM,
LineRate Operating System, LineRate Point, LineRate Precision, LineRate Systems [DESIGN], LROS, LTM,
Message Security Manager, MSM, OneConnect, Packet Velocity, PEM, Policy Enforcement Manager, Protocol
Security Manager, PSM, Real Traffic Policy Builder, Ready Defense, SalesXchange, ScaleN, Signalling Delivery
Controller, Silverline, Silverline Threat Intelligence, SDC, SSL Acceleration, SSL Everywhere, SSL Orchestrator,
SDAC (except in Japan), StrongBox, SuperVIP, SYN Check, SYNTHESIS, TCP Express, TDR, TechXchange,
TMOS, TotALL, Traffic Management Operating System, Traffix Systems, Traffix Systems (DESIGN), Transparent
Data Reduction, UNITY, VAULT, vCMP, VE F5 [DESIGN], Versafe, Versafe [DESIGN], VIPRION, Virtual Clustered
Multiprocessing, WAF Express, WebSafe, We Make Apps Go [DESIGN], We Make Apps GO, and ZoneRunner, are
trademarks or service marks of F5 Networks, Inc., in the U.S. and other countries, and may not be used without
express written consent.
All other product and company names herein may be trademarks of their respective owners.
Patents
This product may be protected by one or more patents. See the F5 Patents page (https://www.f5.com/about/
guidelines-policies/patents).
Notice
THE SOFTWARE, SCRIPTING, AND COMMAND EXAMPLES ARE PROVIDED “AS IS,” WITHOUT WARRANTY OF
ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE, SCRIPTING AND COMMAND EXAMPLES, OR THE USE OR OTHER
DEALINGS WITH THE SOFTWARE, SCRIPTING, AND COMMAND EXAMPLES.
114
LEGAL NOTICES—Copyright
Publication Date
This document was published in December 2018.
Copyright
Copyright © 2013-2018, F5 Networks®, Inc. All rights reserved.
F5 Networks, Inc. (F5) believes the information it furnishes to be accurate and reliable. However, F5 assumes no
responsibility for the use of this information, nor any infringement of patents or other rights of third parties which
may result from its use. No license is granted by implication or otherwise under any patent, copyright, or other
intellectual property right of F5 except as specifically described by applicable user licenses. F5 reserves the right
to change specifications at any time without notice.
115
CHANGE LIST—
Change List
Date Chapter/Section Change Reason

Packet Flow
July 2016 Updates for BIG-IP 12.1 BIG-IP 12.1 release
Denial of Service
June 2017 All Updates for BIG-IP 13.0 BIG-IP 13.0 release
Optimizing the Support Removed reference to Dropbox use
August 2017
Experience F5 Dropbox discontinued
Packet Flow/Flow Change steps in Flow
Error
Lookup Lookup sequence
September 2017 Added section on
Optimize the Support providing files to F5
New
Experience Technical Support using
F5 Support Files
Updates requested by
April 2018 Packet Flow Updated Figure 2.1
TechComm.
June 2018 Packet Flow Updated Figure 2.1 Error
Packet Flow
December 2018 Updates for BIG-IP 14.0 BIG-IP 14.0 release
Firewall Rules
116

BIG-IP Advanced Firewall Manager Operations Guide (PDFDrive)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BIG-IP Advanced Firewall Manager Operations Guide (PDFDrive)

Uploaded by

Copyright:

Available Formats

BIG-IP AFM Operations Guide

Unsurpassed Network Defense

Bringing together security and deep application

Limits of this guide 1

Feedback and notifications 3

Finding other documents 4

Packet flow in BIG-IP AFM software 9

BIG-IP AFM rules 19

BIG-IP AFM policies 21

BIG-IP AFM iRules 24

Rules and policies troubleshooting 27

Network Address Translation (NAT) 29

Packet processing (SYN cookie protection) 43

BIG-IP AFM DoS vectors 47

DoS policy development 54

DoS reporting and visibility 58

Signaling and intelligence 61

SNMP polling and alerting 64

Change and configuration management 67

Monitoring and Logging BIG-IP AFM 68

BIG-IP AFM logging 69

BIG-IP AFM Network Firewall modes 78

Common troubleshooting tasks 89

Troubleshooting using BIG-IQ 92

Stateful failover using connection mirroring 94

DoS statistics output 95

Optimizing the Support Experience 98

F5 training programs and education 103

Engage F5 Support 103

Legal Notices 114

Publication Date 115

Change List 116

Figure 2.1: BIG-IP AFM packet processing 8

Figure 3.1: BIG-IP AFM Network Firewall processing flow 13

Figure 4.2: Inbound NAT 30

Figure 4.3: SNAT on same network using 172.16.0.0/16 32

Figure 5.1: Detection Threshold Packets Per Second 38

Figure 5.2: Detection Threshold Percentage 39

Figure 5.4: Attack phase example 40

Figure 5.5: BIG-IP AFM DoS attack phases (Fast ramp) 40

Figure 5.6: BIG-IP AFM DoS attack phases (Slow ramp) 41

Figure 5.7: SYN cookie packet flow 44

Table 3.1 HTTP Protocol checks disabled by default 18

Table 3.2 HTTP Protocol checks guidelines 18

Table 3.3 FLOW_INT supported commands 25

Table 3.4 FLOW_INT actions 26

Table 5.1 DoS Logging fields 59

About This Guide

Before using this guide

Limits of this guide

Figure 0.1: F5 documentation coverage

Feedback and notifications

tmsh show /ltm pool my _ pool

Table 0.1 Command-line syntax

TMOS Shell syntax

tmsh [command] [module . . . module] [component] (options)

Finding other documents

Uninterrupted data center services

Deep attack visibility

Comprehensive DDoS defense

Note “Distributed denial-of-service” (DDoS) is referred to generically as “denial-of-service” (DoS) in the

Consolidated and strong security

BIG-IP AFM features