BIG-IP AFM Operations Guide

Transcription

1 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.

2 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 8 Post-L4 processing 10 Dynamic Signatures 11 Firewall Rules 12 Network Firewall 12 IP Intelligence 14 Protocol security 16 BIG-IP AFM rules 18 BIG-IP AFM policies 20 BIG-IP AFM irules 23 Rules and policies troubleshooting 25 Network Address Translation (NAT) 28 SNAT 30 NAT irules 34 Denial of Service 35 i

3 CONTENTS BIG-IP AFM DoS mitigations 36 Packet processing (SYN cookie protection) 42 Device DoS 44 BIG-IP AFM DoS vectors 46 DoS policy development 53 Dynamic Signatures 54 DoS reporting and visibility 57 Signaling and intelligence 60 External Tools 61 BIG-IQ Centralized Management 61 SNMP polling and alerting 63 Syslog 64 IPFIX 65 sflow 65 Change and configuration management 66 Monitoring and Logging BIG-IP AFM 67 BIG-IP AFM monitoring 67 BIG-IP AFM logging 68 Troubleshooting 72 Troubleshooting traffic flow 72 BIG-IP AFM Network Firewall modes 76 Rule actions 81 Policy compilation 81 Logging 83 Statistics 85 Common troubleshooting tasks 87 Troubleshooting using BIG-IQ 90 Stateful failover using connection mirroring 92 DoS statistics output 93 IP Intelligence 94 Optimizing the Support Experience 95 F5 technical support commitment 95 ii

4 CONTENTS F5 certification 96 Self-help 97 F5 training programs and education 100 Engage F5 Support 100 Legal Notices 111 Trademarks 111 Patents 111 Notice 111 Publication Date 112 Copyright 112 Change List 113 iii

5 FIGURES Figures Figure 0.1: F5 documentation coverage 2 Figure 2.1: BIG-IP AFM packet processing 7 Figure 3.1: BIG-IP AFM Network Firewall processing flow 12 Figure 4.2: Inbound NAT 29 Figure 4.3: SNAT on same network using /16 31 Figure 4.4: SNAT used when BIG-IP is not the default route 32 Figure 5.1: Detection Threshold Packets Per Second detects when configured threshold is exceeded 37 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 38 Figure 5.3: Packets exceeding the Internal Rate Limit are dropped 38 Figure 5.4: Attack phase example 39 Figure 5.5: BIG-IP AFM DoS attack phases (Fast ramp) 39 Figure 5.6: BIG-IP AFM DoS attack phases (Slow ramp) 40 Figure 5.7: SYN cookie packet flow 43 iv

6 TABLES Tables Table 0.1 Command-line syntax 3 Table 3.1 HTTP Protocol checks disabled by default 17 Table 3.2 HTTP Protocol checks guidelines 17 Table 3.3 FLOW_INT supported commands 24 Table 3.4 FLOW_INT actions 24 Table 5.1 DoS Logging fields 58 Table 6.1 Relevant BIG-IP AFM notifications to send to SNMP trap receiver 64 v

7 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. 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

8 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-todate 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 Consulting 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 Open a support case on AskF5 (support.f5.com) 2

9 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, 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) You can open tmsh by typing tmsh at the BIG-IP system command line: (tmsh)# 3

10 ABOUT THIS GUIDE FINDING other documents Once 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 guides, refer to AskF5 article: K : Finding product documentation on AskF5. 4

11 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-ofservice (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

12 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

13 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. The following figure provides an overview of the packet processing path as it traverses BIG-IP AFM. Figure 2.1: BIG-IP AFM packet processing 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: 7

14 PACKET FLOW PACKET flow in BIG-IP AFM software 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 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. 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. 8

15 PACKET FLOW PACKET flow in BIG-IP AFM software 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 , 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. 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: 9

16 PACKET FLOW POST-L4 processing 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 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 K : Finding product documentation on AskF5. 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. 10

17 PACKET FLOW DynamIC SIGNATURES 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. 11

18 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 12

19 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 higherlevel 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) 13

20 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 K : Finding product documentation on AskF5. 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. 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. 14

21 FIREWALL RULES IP Intelligence 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. Go to Security >> Network Firewall : IP Intelligence : Blacklist Categories. The Blacklist Categories screen 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. To create a feed list 1. Go to Security : Network Firewall : IP Intelligence : Feed Lists. The Feed Lists screen opens. 2. Click Create to create a new IP Intelligence feed list. 15

22 FIREWALL RULES PROTOCOL security 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 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 16

23 FIREWALL RULES PROTOCOL security 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 POST request with Content-Length: 0 Body in GET or HEAD requests Details A POST should always have non-zero length. 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 Null in request body High ASCII characters in headers Host header contains IP address 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 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 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 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. 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: 17

24 FIREWALL RULES BIG-IP AFM rules /we broot/legit-d irectory/../../../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. 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 18

25 FIREWALL RULES BIG-IP AFM rules 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. Go 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: 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. 19

26 FIREWALL RULES BIG-IP AFM policies 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 }} 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. To change Firewall Compilation Mode to manual 1. Go to Security >> Options : Network Firewall. The Firewall Options screen opens. 2. In the Firewall Policy Management section, for Firewall Compilation Mode, select 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. 20

27 FIREWALL RULES BIG-IP AFM policies 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 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. Go to Security >> Options : Network Firewall. The Firewall Options screen opens. 2. From the Firewall Compilation Mode list, select the compilation mode for the firewall rule set. 21

28 FIREWALL RULES BIG-IP AFM policies 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, select 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. 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. Go to Security >> Network Firewall : Active Rules. The Active Rules screen opens. 2. From the Type list, select Enforced or Staged policies, as appropriate. 3. View the firewall rule states in the State column. 22

29 FIREWALL RULES BIG-IP AFM irules 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. 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. 23

30 FIREWALL RULES BIG-IP AFM irules BIG-IP AFM irules commands FLOW_INIT supports the following commands: Table 3.3 FLOW_INT supported commands Log Drop Reject Node Command Virtual Pool TCP::[close respond] IP::[client_addr local_ addr tos ttl version] Action Generates and logs specified messages. Drop packets (silently). Rejects packets (with RST packet). Redirects to specified remote host, which could be another virtual server or pool member. Redirects to the specified virtual server. Directs the connection to the specified pool. Closes a TCP connection or sends the specified data directly to the peer. Obtain the client IP address or the IP of the virtual server. 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: Table 3.4 FLOW_INT actions Default Drop Reset Allow Allow-final Action Description Uses the default action on the ACL rule Drops the connection Resets the connection Allows the connection and proceed to the next ACL Allows the connection and bypass any further ACL. Allow-final is 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 screens only show the actions of firewall rules in which irules are nested. 24

31 FIREWALL RULES RULES and policies troubleshooting 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 } { HSL::send $hsl [info hostname] $log _ format MSG: Pen Tester bypassing AFM rules ACL::action allow-final } 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 Type the following command syntax: 25

32 FIREWALL RULES RULES and policies troubleshooting tmsh show /security ip info address <IP ADDRESS> To add a host to a classification using the Configuration utility Go to Security >> Network Firewall : IP Intelligence : Black List Categories To add a host to a classification using tmsh at the command line Type the following command syntax: 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: 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. 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 Type the following command syntax: tmsh modify sys db proxy.host value hostname To specify the port number of the proxy server using tmsh at the command line Type the following command syntax: 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 Type the following command syntax: tmsh modify sys db proxy.username value username 26

33 FIREWALL RULES RULES and policies troubleshooting To specify the password to log in to the proxy server using tmsh at the command line Type the following command syntax: tmsh modify sys db proxy.password value password To check the BIG-IP DNS client configuration using the Configuration utility Go 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. 27

34 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. 28

35 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. Go 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. 29

36 NETWORK ADDRESS TRANSLATION (NAT) SNAT To create a new NAT using tmsh at the command line Type the following command syntax: tmsh create /ltm nat <NAME> originating-address <IP ADDRESS> translationaddress <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 Go 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: K : Finding product documentation on AskF5. 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 ( ) rejecting the response because the source of the response ( ) does not match the destination of the request ( ). 30

37 NETWORK ADDRESS TRANSLATION (NAT) SNAT Figure 4.3: SNAT on same network using /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. 31

38 NETWORK ADDRESS TRANSLATION (NAT) SNAT 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: 32

39 NETWORK ADDRESS TRANSLATION (NAT) SNAT 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: :2: Inet port exhaustion on to :53 (proto 17) :2: Inet port exhaustion on to :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. 33

40 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 Go to Statistics >> Module Statistics : Local Traffic : Statistics Type. NAT irules To monitor the number of concurrent connections going through the SNAT using tmsh at the command line Type the following command: tmsh show /ltm snat 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. 34

41 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. 35

42 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. 36

43 DENIAL OF SERVICE BIG-IP AFM DoS mitigations 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 ( 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. 37

44 DENIAL OF SERVICE BIG-IP AFM DoS mitigations 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 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. 38

45 DENIAL OF SERVICE BIG-IP AFM DoS mitigations 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. 39

46 DENIAL OF SERVICE BIG-IP AFM DoS mitigations Phase 1 Phase 2 Phase 3 Phase 4 Vector mitigation is enabled and the rate of packets for the vector maintains an average of 500 PPS. No attack present. Event threshold begins with a flood of packets arriving that match the vector. Attack 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 rate limit all packets for this DoS vector above the 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 packets and changes the attack state to none. Figure 5.6: BIG-IP AFM DoS attack phases (Slow ramp) 40

47 DENIAL OF SERVICE BIG-IP AFM DoS mitigations The previous figure models BIG-IP AFM detects a slow increase (slow ramp) in packets. Phase 1 Phase 2 Phase 3 Phase 4 Vector mitigation is enabled. No attack present. Over several hours the number of packets steadily increases, which in turn increases 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 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 ratelimiting 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. 41

48 DENIAL OF SERVICE PACKET processing (SYN cookie protection) Note For information about how to locate F5 product guides, refer to AskF5 article: K : Finding product documentation on AskF5. 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. Go to Security >> DoS Protection : White List. 2. Click Create. The New Configuration screen 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 Type the following command: 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 42

49 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 connection, 43

50 DENIAL OF SERVICE Device DoS 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 Type the following command syntax: 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. 44

51 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 ( pps) 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. 45

52 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. Go to Security >> DoS Protection : Device Configuration. 2. Select the appropriate protection. 3. Click Update. To select an appropriate DoS protection using tmsh at the command line Type the following command syntax: 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. 46

53 DENIAL OF SERVICE BIG-IP AFM DoS vectors 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. 47

54 DENIAL OF SERVICE BIG-IP AFM DoS vectors 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. Go 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 Type the following command syntax: tmsh modify /security dos device-config dos-device-config { dos-device-vector { sweep { detection-threshold-pps 250 default-internal-rate-limit 500 packettypes add { udp } auto-blacklisting enabled blacklist-category phishing blacklist-detection-seconds 10 blacklist-duration }}} 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. 48

55 DENIAL OF SERVICE BIG-IP AFM DoS vectors 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. Go to Security >> DoS Protection: DoS Profile and select 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 Type the following command syntax: 49

56 DENIAL OF SERVICE BIG-IP AFM DoS vectors 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 1. Go to Security >> DoS Protection: DoS Profile and select the 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 5. Specify the specific rate of increase, rate threshold and rate limit for the protection. 6. Click Update. To modify the DNS Query Attack Detection using tmsh at the command line Type the following command syntax: 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 1. Go to Security >> DoS Protection: DoS Profile and select the DoS profile. 2. Click Protocol SIP: General Settings. 50

57 DENIAL OF SERVICE BIG-IP AFM DoS vectors 3. Click the checkbox next to Protocol SIP Protection to enable. 4. Within Protocol Errors Attack Detection, click the checkbox next to enable. 5. Specify the specific rate of increase, rate threshold and rate limit for the protection. 6. Click Update. To modify the protocol SIP using tmsh at the command line Type the following command syntax: 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. Go to Security >> DOS Protection: DOS Profile and select 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 Type the following command syntax: 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. 51

58 DENIAL OF SERVICE BIG-IP AFM DoS vectors 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 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 1. Go to Security >> DoS Protection: DoS Profile and select the DoS profile. 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 Type the following command syntax: 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. Go to Security >> DOS Protection: DoS Profile and select 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. 52

59 DENIAL OF SERVICE DoS policy development 7. Click Update. To modify the Attack Types using tmsh at the command line Type the following command syntax: 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. Go 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 select Policies. 4. Set to DoS Protection Profile. 5. Select Enable and then use the drop-down menu to select a log profile. 6. Click Update. To add a DoS profile to a virtual server using tmsh at the command line Type the following command syntax: 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 53

60 DENIAL OF SERVICE DynamIC SIGNATURES Maintain policy 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 onpremises 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 54

61 DENIAL OF SERVICE DynamIC SIGNATURES 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. 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: 55

62 DENIAL OF SERVICE DynamIC SIGNATURES (tmos)# cd /Common/dos-common/ (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 Use the following command syntax enforce {enabled disabled} To configure the Dynamic Signature detection threshold using tmsh Use the following command syntax detection-threshold {pps value} To configure the Dynamic Signature mitigation threshold using tmsh Use the following command syntax mitigation-threshold {pps value} 56

63 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 screen 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. 57

64 DENIAL OF SERVICE DoS reporting and visibility To view the DoS Overview in the Configuration utility Go 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 screen 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 Time Virtual Server Description Time of the event 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 Type Action 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. Attack vector type Action displays one of two options: None: Indicates that the internal rate limit has not been reached and no packets have been dropped. Drop: Indicates that the internal rate limit has been reached and packets have been dropped. 58

65 DENIAL OF SERVICE DoS reporting and visibility Field Attack ID Packets in / sec Dropped Packets Description Identification number associated with the attack Packets related to the vector type that BIG-IP AFM has sampled in the last second. Packets related to the vector type that BIG-IP AFM has dropped in the last second 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. Go to Security >> DoS Protection: Device Configuration. 2. From the Log Publisher menu, select your publisher. Note Device DoS does not need a logging profile configured to log events. The system supplied globalnetwork 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. Go to Security >> Event Logs: Logging Profile and select logging profile. 2. Click the checkbox next to DoS Protection to enable it. 3. Under network DoS Protection, use the drop-down menu to select publisher. 4. Click Update. To enable a logging profile on the virtual server using the Configuration utility 1. Go to the virtual server properties Local Traffic >> Virtual Servers: Virtual Server List. 2. Select the virtual server. 3. Click the Security tab and select Policies. 4. Get to Log Profile, use the drop-down menu to select the log profile. 59

66 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 Type the following command syntax: 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 60

67 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 61

68 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. 62

69 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: K : Finding product documentation on AskF5. 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. 63

70 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_ ATTACK_START ( ) BIGIP_TMM_TMMERR_DOS_ ATTACK_STOP ( ) BIGIP_DOSPROTECT_ DOSPROTECT_AGGRREAPEROID ( ) The start of a possible DoS attack was registered. The end of a possible DoS attack was detected. The flow sweeper started or stopped. Determine your response to this type of DoS attack, if required. None, informational. None, informational. 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 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. 64

71 EXTERNAL TOOLS sflow 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 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 screen of the Configuration utility. 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 65

72 EXTERNAL TOOLS CHANGE and configuration management 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. 66

73 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: K : Finding product documentation on AskF5. 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 agent on the BIG-IP system must be configured. The primary tasks in configuring the SNMP agent are configuring client access to the SNMP agent, 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- 67

74 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-firewallrules. allow-udp-53.. /Common/global-fw-policy.enforced = Counter64: 0 F5-BIGIP-LOCAL-MIB::ltmFwRuleStatCounter. global. /Common/global-firewallrules. port-2002-global.. /Common/global-fw-policy.enforced = Counter64: 4220 F5-BIGIP-LOCAL-MIB::ltmFwRuleStatCounter. global. /Common/global-firewallrules. disallow-source /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 K : Finding product documentation on AskF5. 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. 68

75 MONITORING AND LOGGING BIG-IP AFM BIG-IP AFM logging To configure local.syslog Go 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. Logging destinations 69

76 MONITORING AND LOGGING BIG-IP AFM BIG-IP AFM logging 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 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. 70

77 MONITORING AND LOGGING BIG-IP AFM BIG-IP AFM logging 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 binaryencoded 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. 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). 71

78 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. 72