Chapter 20 — Layer 7 DoS Protection and Advanced Bot Protection 20-1 Chapter 20: Layer 7 DoS Mitigation and Advanced Bot Protection Chapter Objectives After completing this chapter, you will be able to: Define Denial of Service Attacks Configure a DoS Profile for TPS protection Configure a DoS Profile for Bot Defense Define Proactive Bot Defense and describe a use case for it Defining Denial of Service Attacks Although Denial of Service (DoS) threats are constantly evolving, F5 has found that attacks can be categorized into four general types: Volumetric, asymmetric, computational, and vulnerability-based: 1. Yolumetrie—Volumetric attacks are designed to overwheIm your network capacity. Traffic might be legitimate or illegal, but the goal is to cause congestion until service is denied to all users, FS researchers have identified trends in which volumetric attacks are about creating noise ‘and distraction so that other attacks, with ransom as the goal, are successful. 2. Computational—Attacks designed to consume CPU and memory in ultimately useless ‘computational cycles. = 3. Asymmetrie—Attacks designed to invoke timeouts or session state changes. For example, the attack may begin as apparently legitimate traffic before administrators have time to identify why sessions are being held open and start timing out. Over time, state resources such as session tables are exhausted. Z 4, Vulnerability-based attacks can target software (unpatched OS or other software can be vulnerable), or abuse protocols such as HTTP, and can be closely related to computational attacks. Vulnerability attacks can be sophisticated. They take advantage of some weakness or ‘vulnerability in 2 network protocol or the receiving system handling that traffic using a certain protocol. Network protocols such as TCP/IP were developed with little regard te_potential malicious usc. Examples are LAND, Bad TCP Options/Size, Invalid DNS Opcode, HTTP Method, Apache Killer, and Post OF Doom attacks. Configuring BIG-IP ASM v13 20-120-2 ‘Chapter 20 - Layer 7 DoS Protection and Advanced Bot Protection ; | Sey es 5 Can arpet Layers 3 4,6r7 i | | i reo nn + Gan target Layers 5, 8, and 7 | 1 Network + Expiokt sonware Naws andlor protocols. | + Typleally target Layer 7 | Ware) TMCS N eC RE): Méltipealtackars (usualy aiorated) : ae = ze Figure 1: Arguably any layer of the OS! model can be vulnerable to denial of service. Bul some layers are ‘more prone (o attacks than others. For example, SYN, ICMP, and DNS floods can target Layers 3-4, and HTTPibusiness logic abuse exploits can target Layer 7. Perpetrators of DoS attacks typically target sites such as credit card payment gateways, banks, and root name servers that host high-end web applications. How L7 DoS Attacks Are Developed The level of sophistication among attackers continuously increases. The tools and coordination required to do pre-attack analysis have become well-automated and casily accessible. Attackers are proficient at network reconnaissance: © They obtain a list of site URIs “ ~ © They sort by time-to-complete requests (CPU cost and latency) * They sort by bandwidth Bots can automate attacks even though they are often known by the security community. Many bots can be executed with a simple wget script, or the OWASP HTTP Post tool. 20-2 Configuring BIG-IP ASM v13J! Chapter 20 - Layer 7 DoS Protection and Advanced Bot Protection 20-3 The General Flow of DoS Protection 1. Collect metrics - Identify bots and other suspicious clients = Requests (transactions per second)/configurable) = Proprietary: Measure server stress (latency) 2. Decide when an attack starts 3. Decide which IPs or URLs are under attack 4. Apply mitigating actions to IPs, URLS, suspicious clicnts, or entire site under attack 5. Decide if and when an attack stops yt 6. Decide if Proactive Bot Defense is needed ¥ et got Re ee BT yee Defining the DoS Profile ‘The DoS Profile protects a server/application in several ways. First, it Macros. Expected Results At the end of this lab, you should witness the DoS profile resct a client connection after ASM has determined it is sending too many requests. Additionally, you should be able to force a client to solve a CAPTCHA challenge before being allowed to continue. You should also be able to locate your configuration mitigations in the DoS application event log. BH BEHBES B&B BEEBSBSHE EB BBChapter 20 - Layer 7 DoS Protection and Advanced Bot Protection 20-19 Defining DoS Profile General Settings $ Heavy URL Prot. eared Oe eae) Borers i ecccar) cal URLS with different ident ucla ee ace ected Figure 17: DoS Profile general settings Heavy URL Protection To define a “heavy” URL let’s look at two example URLs: /index.php and /history.php. ‘The first example, /index.php, displays the landing page for a web site. The server always returns the HTML for this page in nearly the same amount of time, even if the page is dynamic and changes from time to time, because relatively little work must be performed by the server to return the page. The second example, /history.php, performs a historical stock quote query with parameters that might look like thi Jnistory.php?symbol=EFIV&period=5&period_unit=day&resolution=hour ‘The query yields a report for the FFIV stock price every hour over the last 5 days. Unlike the amount of work required to return /index.php, the amount of work the server has to perform for /history.php depends on the parameters of the search, Soa query like this: /history.php?symbol=FFIV&period=10&period_uni ime —say 20 seconds or more, can take a comparatively lor Most of the time users perform reasonable queries which shouldn’t take long—perhaps the same amount of time it takes to serve the index.php page. However, an occasional query could include more complex search clements, and sometimes an even more resource-intensive query can be sent to the server. An attacker that is aware of this might exploit the possibility and perform repeated heavy queries from multiple bots thus depleting the server resources. “Thus, /history.php is a heavy URL, while /index.php is not. Configuring BIG-IP ASM v13 20-1920-20 Chapter 20 - Layer 7 DoS Protection and Advanced Bot Protection In Operation Ababil against US financial institutions in late 2012, attackers successfully identified URLS that took longer to reply (implying grcatcr back-end server load), and targeted their HTTP-based attacks against these URLs with seemingly legitimate traffic. Mitigating Attacks Against Heavy URLs ASM measures the latency tail ratio ~ the percentage of requests that exceed the latency threshold time to complete on the server. This threshold is configured in the security policy and should be set so that approximately 95% of the requests in the virtual server have lower latency. You can tune that figure based on the “URL latencies” report showing a histogram of the latency for individual URLs and for the whole site (virtual server and DoS profile) via Security » Reporting : DoS : Application : URL Latencies. ASM measures the tail latency for each URL and for the entire site over the last 24 hours in order to ‘obtain a representative sample of request behavior. During this period ASM docs not consider latencies measured during periods of stress on the server(s), due to some poo! members being down, for example. This is because at these times, the latency does not reflect the time spent on processing the request, but instead reflects the time to wait in queue until the request is served. Let’s assume the latency threshold is set to 1 second (the default value): © For the whole site, the latency tail ratio was 2%, which means that 2% of the requests to the site exceeded a latency of I second. ‘* For /index.php the ratio was 1.3%. ‘+ For (history.php the ratio was 6%. ‘This means that 94% of the requests were relatively simple and took less than I second to complete. It also means there were some complex queries that took more than I second to complete. ‘The eriterion for being heavy is having a 24-hour average tail latency that is more than twice the site 24- hour average tail latency. Put another way, a heavy URL is the one that is twice as heavy as the others. Using our original example, we sec that this happens with /history.php but not with /index.php making the former a heavy URL. 20-20 Configuring BIG-IP ASM v13Chapter 20 — Layer 7 DoS Protection and Advanced Bot Protection 20-21 Overriding Geolocation Detection Criteria You can specify countries from which to allow or disallow traffic during a DoS attack. Geolocations Overrides the DoS profie’s Geolocation Available Geciocation Geatecaon Dteston Blacklist Geolecations: Whitelist: era threshold satings ae . by selecting countries from erecta = ‘which to alow or block Jaen | trafic during a DoS attack. IAigeria lAmerican [>> landera | [xe] 'Angola \Anguila (Antarctica \Antigua ar ~ Figure 18: This setting will override Geolocation settings configured elsewhere in the DoS profile, such as in the TPS-based detection section. Customizing CAPTCHA Responses You can customize the first CAPTCHA response text ASM sends to users during DoS mitigation, and post-CAPTCHA failure tex CAPTCHA Response ‘Customize the CAPTCHA page users First Response Type: Custom * ‘ee during DoS events Fist Response Body (Linited to (65520 characters) [eoe> — [.00517.capeeha.inagot [t0051.7 eapecha-changot leoe> lcbownat code 1s in the imagers |+00517.capteha. solution I lene> Figure 19: The default response text includes placeholders for generating the image and other elements of the response page. Triggering iRules for DoS Events If you have an iRule for managing DoS events, you must enable iRule processing on the DoS profile. Configuring BIG-IP ASM v13 20-2420-22 Chapter 20 - Layer 7 DoS Protection and Advanced Bot Protection “rigger Rule Enabie tis setingifyouhave an Cinabled ‘fide tal warages DoS evens na ‘custoreted manner lwnen IN_DOSL7_ATTACK {log local, “Aflacker IP: SDOSL7_ATTACKER_IP* log locall. "Mitigation: SOOSL7_MITIGATION" ) Assign iRule to Vituat Server Figure 20: iRule processing must be enabled on the DoS Profile and the (Rule must be assigned to the same virtual server as the DoS Profile. Defining Single Page Applications A standard application sends an HTML response after a request. Each response makes the browser reload the entire page. With technologies such as Angular JavaScript and others, Single Page Applications load new pages using AJAX, and submit form data as JSON. A single URL can be used to serve multiple HTML pages, meaning there is no distinct correlation between a given URL and a web page. The consequence of this is that some applications can have multiple URLs using AJAX /JSON. equests/responses in addition to the standard HTML response. ‘Traditional HTML Page Lifecycle SPA.Lifecycle First Request = Ft Request Mf f Page Reload HIM. | + saascn peioacentwoit | + NomiTMLURLS are rot qualified Figure 21: Single Page Applications are not eligible for standard DoS security checks. ASM qualifies each URL for client-side mitigations by looking for the Content-Type: text/html header in at least 10 responses within a 5 minute period. Single Page Apps may not deliver HTML as expected, and are therefore not cligible for standard CSID ot other injection-based protections. The challenge for ASM in these eases is to inject the JavaScript challenges into the AJAX and JSON actions. Note that although this option is configured in the DoS profile, it also applies to features inside the ASM security policy such as web scraping and brute force protection. 20-22 Configuring BIG-IP ASM v13Chapter 20 — Layer 7 DoS Protection and Advanced Bot Protection 20-23 ‘This means that if the use case is to protect a web application with AJAX and JSON from web scraping, even if a DoS profile is not otherwise needed, you must still have a DoS profile, with Single Page Application enabled, assigned to the virtual server. URL Patterns Itis helpful if you can work with the application development team to identify common URLS with possibly different strings (patterns) in cach. These strings typically act as parameters so that the application knows which page to load, which action to take, ctc., based on some action ficld or variable in the payload. For cxample, a URL pattern might be https: //www.hackit. £5trn.com/item.php? ide4£££7db154cebal407b6£9108cSee26b. An AJAX request might be triggered by some internal page with an identifier of 4£££€7db1$4ceba1 407b6£9108c9ee26b. Remember that single page apps do not use standard HTML forms, and the name attribute for input fields most likely does not exist. By providing identifiers using URL Patterns, you can help ASM secure your single page app. Performance Acceleration ‘A Performance (FastL4) virtual server has a FastL4 profile assigned, which increases the speed at which the virtual server processes packets. This virtual server can take advantage of Packet Velocity ASIC (PVA) hardware acceleration present on the BIG-IP system, but at the expense of inspecting any L7 application data, such as HTTP payload. By selecting Performance Acceleration in the DoS profile, you ensure most TCP flows will be forwarded to the application without HTTP inspection. However, a virtual scrver with Performance Acceleration enabled in the DoS Profile will have two conncetion paths: A slow path subjected to proxy and configured detcction and mitigation settings, and a fast path created automatically through inheritance of the FastL4 profile settings. If ASM detects an attack based on behavioral analysis or server health check, all suspicious flows will be fully proxied, inspected, and mitigated. Performance acceleration will not resume until the attack ends. Performance Configure TCP fast4 None ¥ acceleration profile to be used as fast- TCommon/apm-forwarding fastL4 path for acceleration ICommonffastL4 ‘Common/full-acceleration Figure 22: Performance acceleration can improve peace-time performance by fast-tracking requests. This feature must be used with care. If performance is more important than security processing, Proactive Bot Defense, Bot Signatures, Device ID, Client-Side Identification, and CAPTCHA {all of which operate in full proxy mode) cannot be used. Defining Bot Signatures Bot signature detection capability provides another line of defense for known simple bots that can be easily detected by their signaturcs—typically a User-Agent header, or other headers that are intended to allow the bot to masquerade as something itis not. Bots can sometimes be detected by closely observing their actions. In many cases, bots only request pure HTML and not commonly embedded objects including images, JavaScript, CSS, and other clements because rendering the page is not the goal. Configuring BIG-IP ASM v13 20-2320-24 Chapter 20 - Layer 7 DoS Protection and Advanced Bot Protection + estos! + crmuler Ema cokacor + HTTP bray + Epottet + Searenbor + Network scanner 1 searenengne + Spam bot + Semice agent 1 Vatrerabiy scanner + Stermentor + Web sce Social media agent Figure 23: You assign malicious bot signatures to the Malicious signatures category, and legitimate signatures fo the Benign signatures category. Bot signatures are updated with the ASM signature update. You can then configure ASM to automatically block all requests that match Malicious category signatures while allowing (and/or logging) all requests that match signatures categorized as Benign. De ‘What ifa script, bot, or automated client uses a legitimate user agent string? ‘User-Agent: Mozilla/5.0 (compatible; Googlebot/2. 1; +hi ing Proactive Bot Defense : www google.com/bot html) It would be unacceptable to block this request by signature alone because ASM would block every logitimate clicnt that is sending this User-Agent string. How do you combat these bots if you cannot use a signature? Furthermore, many bots which conduct malicious activity or perpetrate various forms of web fraud use very sophisticated cloaking techniques to hide themsclves—and can potentially defeat signature-based defenses. What can ASM do to combat these types of bots? The solution is to use Proactive Bot Defense which works in several ways. Proactive bot defense can be configured to always run, or to only run during a detected attack. Many attacks often start small and escalate as the attacker determines success. ASM can find bots before @ DoS attack (or web scraping attempt) has started and filter those requests from legitimate users. This is useful against attackers who attempt to operate below suspicious criteria thresholds, and send highly distributed attacks where cach client is sending a low rate of requests. When a bot accesses the application for the first time, ASM injects a computational challenge instead of the original response. The injected challenge is similar to the one use for client-side mitigation, but requires different validation. The assumption is that legitimate users will always request a qualified URL (such as index.php, or similar) first. Proactive bot defense can detect attacks on non-qualified objects, such as images, js files, and .css files—requests which are in an unusual sequence, or fal to request objects in a manner consistent with human interaction. Legitimate clients will resend the request, also ‘causing a signed ASM cookie to be sct. Bots which do not process the challenge will not re-send the request, The ASM cookie is signed together with the client IP address and a timestamp is applied to prevent replay attacks. Ifthe second request is validated by ASM, it is passed to the application, 20-24 Configuring BIG-IP ASM v13Chapter 20 — Layer 7 DoS Protection and Advanced Bot Protection 20-25 bbot defense is not intended to replace the current mitigation methods, but rather complement ' Browser Because this defense system generally Fenian poe aces inspects most traffic, it can affect HTTP Reauest no ooh) system performance. gopaatona cere Detecting suspicious browsers Proactive bot defense can also detect clients that do not contain the characteristics of known browsers, and are therefore suspicious. The feature can be enabled for all requests, oF triggered when potential attack thresholds are reached. In cither case, the feature works by intercepting a cliont request, and issuing a JavaScript Figure 24: The sequence of Proactive Bot Defense challenge to the client. The JavaScript fingerprints browser characteristics, and sets.an internal score that will determine whether the request will be processed. The characteristics by which the score is set are F5 internal intellectual property, but in general a browser should meet certain features that are expected from a browser: Missing headers, obsolete User Agents, or badly formed URLs are a few indicators of bot activity. Clients that have peculiar characteristics such as these are sometimes termed headless browsers. IF the score is within the satisfactory range, the request is allowed to continue to the server. If the score is completely unsatisfactory, the connection will be resct. Ifthe score is within the suspect range, and no CAPTCHA challenge is configured within the Proactive Bot Defense settings, the connection will be reset, Otherwise, a CAPTCHA challenge will be sent and used as the final arbiter as to whether the connection will be dropped. Defining Behavorial and Stress-Based Detection Behavorial and Stress-based detection measures server-side latency in serving requests. ASM uses proprictary Predictive latency measurements to predict how fast the server can serve new incoming, requests from the client. By calculating this ASM can predict the stress on the server before it happens. By measuring various indicators, the predictive latency mechanism can conclude in good probability that the server is now under DDoS attack. The predictive latency technique is based on site wide indicators and is currently internal FS intellectual property. The latcncy threshold settings available in earlier versions of ASM were removed because predictive latency is calculated automatically. Configuring BIG-IP ASM v13 20-2520-26 Chapter 20 - Layer 7 DoS Protection and Advanced Bot Protection Attacker detection and mitigation options include By Source IP, By Device ID, By Gcolocation, By URL, and Site-Wide as with previously defined protection methods. Additionally, Behavioral DoS mitigation can be applied. Application Security » Behavioral & Streas-based (D)DoS Detection Close al Tike racon confowos he detacton ofS tacks Bad on serve es Tho systom auorravealydaacs an nerensa server see and mana DOS ack Operation Mose Species now nesystemrexts ——_-Bleetng ot Specias wnat type ol mestolls io Manual eat Stressbased Delecton By SouroIP ‘upston Request Blocking (Rate Lint) cay ‘and iigaton By Obvce 1 No magaton eon By ORL Mpaton Request Blocng (Rate Lin) Ete stevie No mogston ew Behavioral Detection andy Bad Alors Gakver /SinaresDesbled tigation Praventlon Duration Spectis to tne spentneach _—_Estlabon Ponod 129 seconds eet Figure 25: Stress-based detection attempts fo predict latency before the server experiences DoS. ( =) ny TPS-based and Stress-based DoS protection can work in parallel Defining Behavioral DoS Mitigation Behavioral DoS measures normal traffic and then when server stress occurs, it can start rate limiting or dropping those source IP addresses whose behavior has exceeded the thresholds for legitimate traffic. Behavioral DoS is fully automated and has no configuration other than the four modes of operation. There are no thresholds to configure, and there is no need to maintain and fine tune any settings. The more traffic Behavioral DoS sces, the more accurately it can characterize offending traffic and mitigate it. The ‘engine is self-adjusting and adaptive to change. Differentiating Slowdown and Blocked Mitigation Behavioral DoS has two types of mitigation, Slowdown and Blocked. With Slowdown, bad clients wi be limited to the historic requests per second behavior displayed before the anomaly. If Slowdown fails, and the rate of requests from the bad client increases, then Behavioral DoS will switch to blocking mode. The Application Visibility and Reporting (AVR) graph below displays an example. 20-26 Configuring BIG-IP ASM v13,Chapter 20 - Layer 7 DoS Protection and Advanced Bot Protection 20-27 ‘Figure 26: Behavioral Blocked and Behavioral Slowdown ite once applied they can be seen in the visual graph, ‘Traffle Distribution ava TPS) q Mvcomset Moos blocked Mi shun Blockea Mi behavioral stocked Wi behaviors! siondonn Proactive mit [Bcarrcna wi [BIS integrity maigatior Wi o1c-1P response [cached by scar [Mi wnitetistea Wi assthrough 06:42:55 2s are in the transaction outcome list and Defining Behavioral DoS Mitigation Operation Modes The tradeofT is that go roteet server availability at all cost ‘The default (and recommended) mode is Standard protection -T mode can slow down hea yom anomalous IP addresses based on its anomaly detection confidence and the server's health. I'necessary it rate limits all requests based om the Server's health. It Of eoncurrent connections from anomalous IP addresses and, Yee . it might reset a legitimate connection, _jesszssive mode slows down requests from anomalous IP addresses based on its anomaly detection confidence and the server's health, If necessary, it rate limits al server's health, and limits the This mode proactively perform: Configuring BIG-IP ASM vi3 20-27ab -c 1 -n 100 ~ H “User-Agen| + Amazoogle” http: //10.10.X.101/ 15. In ASM, determine the action taken inst the client and the reason the action was taken. Create a Custom Bot Signature 16. Goto Security > Options : DoS Protection : Bot Signatures List and then click Create. 17, Create a new bot signature using the following settings: ak > 18. Click Create. Repeat Bot Attack 19, Send the following (onc concurrent user sendi 100 page requests): Amazoogle” http://10.10.%,101/ 20. In ASM, determine the action taken against the client and the reason the action was taken. ab -c 1 -n 100 -r -H “User-agent Expected Results When you first launch a bot attack, the DoS profile should respond with a TCP reset, and the reason given should be Bot Signature Detected. When you modify the User-Agent and launch another attack, the DoS profile should respond with a browser challenge, and the reason given should be some variation of No Valid Cookie: Challenge possible because no Referer header arrived. When you add a custom bot signature and repeat the attack, the DoS profile should respond with a TCP resct, and the reason given should be Bot Signature Detected, but this time the detected signature should be your custom signature instead of the system-supplied ab signature.Chapter 21 — ASM and iRules 21-4 Chapter 21: ASM and iRules Chapter Objectives After completing this chapter, you will be able to: ‘* Discuss iRule components and events * Define the iRule events associated with ASM © Create a custom violation ‘© Create an iRule for ealling your custom violation Configure iRule processing for an ASM-cnabled virtual server Common Uses for iRules ‘An iRule isa script that can examine and potentially alter traffic between the BIG-IP system and both its clients and pool members. Ofien, iRules are used to sclect a pool to process a client's request. In this, case, the client’s initial packets can be parsed and that data be used to sclect an appropriate pool. Additionally, iRules are used to change the traffic as it flows between the client and server. In this case, the traffic stream is monitored and changed as dictated by the iRule. iRules give you complete control over what, when and how to change application traffic at any point in the transaction. Application owners now have a programming language in the network focused on application delivery. The iRules you create can be simple or sophisticated, depending on your content- switching or security processing needs. In ASM implementations, administrators can use iRules to execute different commands based on different events. For example, here is a simple iRule that is triggered when ASM detects more than three violations in a single request, and cach violation has a severity level of Error. If this condition occurs, ASM will activate the custom (user-created) violation named TOO_MANY_VIOLATIONS. when ASM_REQUEST_DONE ( if ({ASM::violation count] > 3 and [ASM::severity) eq "Error") { ASM: :raise TOO_MANY_VIOLATIONS ) 1 In the above example, the event is ASM_REQUEST DONE, and the command is ASM::raise TOO_MANY_VIOLATIONS. ‘Rule syntax is based on Tool Command Language (TCL). You can use many of the standard TCL ‘commands plus BIG-IP system extensions to help you manage traffic more effectively. For information about standard TCL syntax, see: hitp:/Amml.sourceforge.ne/doc/teVindex.html. Configuring BIG-IP ASM v13 20121-2 Chapter 21 - ASM and iRules Identifying iRule Components iRule Components ‘Rules generally have the following simple structure: 1. When a certain event occurs. 2. ...fa particular condition exists... 3. Overall, iRules are built from three components: events, conditional statements, and actions. An event defines the traffic processing activity that will trigger the iRule to begin processing. Conditional statements use relational operators to process data and return a Boolean (true or false). Commands or actions define the BIG-IP system's response to the results of the conditional statement, rule { when EVENT ( Perform an action, if { conditional_statemeat } { action_when_condition_true Event declarations iRules are event-driven. When various events occur in the client-side or server-side connection, the BIG- IP system triggers iRules based on those events. Events include CLIENT_ACCEPTED. which occurs whenever a client has established a connection and HTTP_REQUEST, which occurs whenever a client sends a valid HTTP request. Within the iRule, the event declaration includes the keyword “when” followed by the event name. Operators ‘An iRule operator compares operands to determine a relationship. Based on the result, action can be taken, For example, the following statement, defining a goal to use a specific poo! for clients with a specific IP address, can be accomplished with the iRule phrase below. Goal: “If the remote client address equals 10.10.10.10, send 10 pool my_pool." Rule Phrase: if { (1P::client_addr} equals "10.10.10.10" y ( pool /Common/http_pool 21-2 Configuring BIG-IP ASM v13Chapter 21 — ASM and iRules 21-3 The table below lists the some of the available operators that you can use within iRules. Operator Class Operator Relational Operators contains matches equals starts_with ‘ends_with matches_regex Logical Operators not and or Rule commands An iRule command causes the BIG-IP system to take action. Command types include: Query commands ‘These commands search for header and content data, An example ofa query command is 1Pszremote_addr, which searches for and returns the remote [P address of a connection, Aetion/modification commands ‘These commands perform actions such as inserting headers into HTTP requests. An example of an action command is HTTP::header remove , which removes the last occurrence of the named header from a request or response. Statement commands ‘These commands specify traffic destinations such as pools or URLS (for rewriting HTTP redirect 3), An cxample of a statement command is pool , which directs traffic to the named load balancing pool. UIE commands ‘These commands arc functions that perform deep packet inspection to either directly select a pool ‘or specific member of a pool based on the result of searching for any data that you specify in the ‘command. An example of a UIE command is decode_uri , which decodes the named string using HTTP URI encoding and returns the result, ASM commands ‘These commands are functions that cause ASM to take some action. They are listed in the section below. Configuring BIG-IP ASM v13 21321-4 Chapter 21 - ASM and iRules Triggering iRules with Events Events define multiple points in the client’s session that can cause the BIG-IP system to impact traffic. Events are defined in many groups such as ASM, Authentication, Global, HTTP, TCP, and SSL. Each ‘group has specific events that represent stages in the communication between client and server. Event Examples Event Type Description Examples Global Global events deal with connection establishment RULE_INIT LB_SELECTED HTTP HTTP events deal with HTTP requests and HTTP_REQUEST responses HTTP_RESPONSE SSL SSL events deal with client authentication during the | CLIENTSSL_HANDSHAKE initial SSL handshake. Rules responding to such events let the BIG-IP system redirect clients if they CLIENTSSL_CLIENTCERT are not able to support the encryption level desired SERVERSSL_HANDSHAKE by the site or do not have a client certificate. Authentication Authentication events deal with client authentication = AUTH_FAILURE Prior to establishing @ connaction with any poo! member. Depending on the stage in the process, AUTH_ERROR the BIG-IP system might redirect the client to an AUTH_WANTCREDENTIAL, alternate site or silently reject them. ‘AUTH SUCCESS asm ASM events deal with security processing such as ASM_REQUEST_DONE triggering violations and blocking requests. 24-4 Configuring BIG-IP ASM v13BEHEBEBBES — Chapter 21 — ASM and iRules 215 Defining ASM iRule Events {Rules are event-driven, which means that ASM triggers an iRule based on an event that you specify in the iRule. The event can be related to requests and responses. An cvent declaration is the specification of an event nan iRulc that causes ASM to trigger that iRule whenever that event occurs. The following are ASM-based events: Event Description ASM_REQUEST_VIOLATION Triggered when ASM detects a request which violates the current ‘security policy. Can be used to modify the violating request and/or pass it to a different destination. (This event is deprecated in 11.5 but sill supported, f you use this event, you must configure iRules in compatiblity mode.) ASM_RESPONSE_VIOLATION Triggered when ASM detects a response that violates the security policy. Can be used to modify the response that ASM processed. ASM_REQUEST_BLOCKING Triggered when ASM generates a blocking response page. Can be used to modify the blocking response before it is sent out. ASM_REQUEST_DONE Triggered when ASM finishes processing the request regardless of whether there were violations on the request or not. This event must be used with Normal mode. ‘A typical use case is using an iRule to modify a request and/or response based on a spccific violation. Other use cases for iRules within ASM: Log a user out of the application based on a violation. Create custom response pages per violations and per user account. When a violation is detected, route the traffic to a dedicated web application. Manipulate suspicious user input in order to neutralize an attack when violation is detected. ‘Trigger a custom violation that is indifferent to built-in ASM violations before or after ASM processing. ‘Trigger a custom violation if none of the built-in ASM violations were triggered. Configuring BIG-IP ASM v13 21-521-6 Chapter 21 - ASM and iRules Example of an iRule for an ASM Event In the example below, the iRule triggers when ASM is done processing a request. If the request triggered a violation, the violation is logged. if the violation is that the request is missing a mandatory header, the ‘Rule performs a check to sce if the client IP address from which the request was made is whitelisted, then log the action indicating ASM has bypassed the violation and unblock the request if it was blocked. when ASH_REQUEST_DONE ( tog Iocal0. *violation triggered* set violation [ASM::violation names) Af ( $violation eq "VIOLATION MISSING MANDATORY HEADER* } { if {[ class match [HPTP::Uri] equals URI_whitelist } or (class match [TP::client_addr} equals IP whitelist} } [ "bypass adn violation" 21-6 Configuring BIG-IP ASM v13Chapter 21 — ASM and iRules aT Defining ASM iRule Commands The list below defines various ASM commands and what action will be taken: ASM::client_ip - Returns the IP address of the end client that sent the present request ASM::disable - Disables plugin processing on the connection. ASM::enable - Enables plugin processing on the connection. ASMisfingerprint - returns the FP Id If available ASM:payload - This command retrieves or replaces the payload collected by ASM. ASM:raise - Issues @ user-defined violation on the present request ASM::severity - Returns the overall severity of the violations found in the transaction (both request and response) ASM&:status - Returns the current status of the request or response ASM:support_id - Returns the support id of the present HTTP transaction ASM:unblock - Overrides the blocking action for a request that had blocking violation ASM::violation - Returns the list of violations found in the present request or response together with detalls, on each one ASM:violatlon_data - This command exposes violation data using ¢ multiple buffers instance DOSL7:disable - Disables blocking and detection of DoS attacks according to the ASM security policy configuration DOSL?::enable - Enables blocking and detection of DoS attacks according to the ASM security policy configuration DOSL7:profile- returns the DOS profile from which the L7-DoS policy Is extracted Configuring BIG-IP ASM v13 21-721-8 Chapter 21 - ASM and iRules Using ASM iRule Event Modes ‘This sctting is available if you enable the Trigger ASM iRule Events setting. There are two modes: ‘Normal mode: Use this mode if you want ASM to invoke the ASM_REQUEST DONE event after it completes processing each request, regardless of whether the request triggered a violation or not, For example, you may wish to write a custom, user-defined violation, which is triggered after any ASM. request processing. By using Normal mode, you can extend iRule processing after ASM is finished ‘examining requests. Normal mode is the default setting after you cnable Trigger ASM iRule Events. Compatibility mode: Use this mode if you want ASM to invoke the ASM_REQUEST VIOLATION event after it completes processing cach request that triggered a violation. This gives you the option to perform actions after ASM handles only those requests which triggered a violation. This was the only option available prior to BIG-IP version 11.5.0. ASM_REQUEST_DONE and ASM_REQUEST_VIOLATION will never be invoked on the same request. ASM automatically validates that no rule contains both of these events. For up to date information on all iRules and associated security mitigations using iRules visit DevCentral: https://deveentral.£5.comvirules iRule sample The following iRule can be used to give a different error response page depending on the IP address of the requestor. The iRule could be used to send a different alert based on trusted traffic or untrusted traffic. when ASM_RESPONSE_VIOLATION ( f Check source IP address to determine which custom response to send if ( (index [asm::violation data} 4] contains "10.10.1.30" } ( ASM::payload replace 0 0 * ctitle>Response Violation Response Violation Violation Type: [lindex (ASM: :violation_data} 0] Support ID: {lindex {ASM::violation_data] 1} To Application: [index [ASM::violation data] 2] Severity: [lindex [ASM::violation_data} 3} From Source IP: [Lindex (ASM: :violation_data} 4] Attack Type: [lindex [ASM::violation_data) 5] Status: [lindex [ASM::violation_data} 6) " ) else { ‘ASM: :payload replace 0 0 “ The requested URL was rejected. Please consult with your administrator.

Your support 1D is: <8TS. request. 1D()$>
Ssource_ip " 21-8 Configuring BIG-IP ASM v13Chapter 21 — ASM and iRules ASM iRule Configuration Workflow - Create fel ny(-teit) + Pools Using: + Nodes + BIGIP GUI + Profiles + iRules editor + Monitors + Notepad++ + Security policies Configuring BIG-IP ASM v13 21-9 Using GUI: + New VS: Resources section + Existing VS: Resources tab 21-9Lab 21.1- Custom Violations and ASM iRules Lab Objectives © Create a custom violation © Create an iRule for the custom violation © Verify results Estimated time for completion: 20 minutes Lab Requirements ‘+ Completion of Lab 2.1 Create security policy 1. Create a new security policy using the specifications in the table below: Configuration utility Seer acc RS ee See Cerise Policy Name lab_21_iRule Policy Type Security Policy Template ___| Rapid Deployment Policy Enforcement Mode Blocking _ “Application Language Unicode (utf-8) _ ‘ApacheINCSA HTTP Server , MySQL sever Techotges mys Unix/Linux ‘When finished) click Create Policy Assign security policy to virtual server 2. Goto Local Traffic » Virtual Servers : Virtual Server List 3. Select asm_ys and complete the following steps: a, From the Security tab, select Policies. b. Assign your Inb_21_iRule security policy ible the DoS Protection Profile if itis assigned 4d. Remove the lab_20_dos_logging profile if itis assigned ¢, Ensure that you are logging all requests.4. Click Update. Create user-defined violation 5. Create a new user-defined violation using the specifications below: Security » Options : Application Security : Advanced Configuration : Violations List On the User-Defined Violations Tab click Create... i a & B E Violation Name ‘too_many_violations Violation Tite violation limit exceeded (This title will appear on the User- Defined Violations tab and on the Blocking Settings page.) Type Unspecified Severity Critical ‘Attack Ty (Other Application Activity When complete, click....__| Create Create the iRule on BIG-IP 6. Create a new iRule that will send a custom blocking response page in response to a detected violation. a, Navigate to http://does.{5tm.com/studenVasm/v13.|/and open the file named count_violations.tet, select all the text on the page (Ctrl+A), and copy it to your clipboard (Ctrl+C). b. On your BIG-IP system, create a new iRulc using the copied text: Pee ee Crea Tee ea Name count_violations Definition Paste the copied text from your clipboard (Ctrl+V) When complete, click... | Finished Associate iRule with virtual server 7. Goto Local Traffic »» Virtual Servers : Virtual Server List. 8. Click asm_vs. 9. Click the Resources tab. 10, In the Rules section, click the Manage bution. 11, Assign the iRule eount_ 12. Click Finished. lations to the virtual server.Configure iRule processing for application security policy 13. Go to Security »» Application Security : Poli 14. Verify that you are modifying your lab_21_iRule policy. : Policy Properties. 15, From the Policy Properties drop down menu, select Advanced, 16, At the bottom of the section, select the Trigger ASM iRule Events checkbox. 17. Accept the default Normal mode. You are testing an iRule which will trigger a custom violation cach time ASM_REQUEST_DONE is invoked, This event works in Normal mode. 18, Click Save and then click Apply Policy. Configure attack signatures to not block requests: 19. Go to the Learning and Blocking Settings page. 20. Expand the Attack Signatures section. 21. Uncheck the Block checkbox for all signature sets. 22. Uncheck the Enable Signature Staging checkbox. (This will enforce them, but no blocking will occur.) ‘7 Attack Signatures: Loam |(-| Alarm | Block | Signature Sel Name 2 Generic Detection Signatures © |e 2 ApacheiNCSA HTTP Server Signatures je @ MySQt Signatures jo @ PHP Signatures |e a UnisiLinux Signatures ja @ Windows Server iis SOL Server \6 G Linux Apache Mysql PHP apps \e a nginx Enable Signature Staging 23. Click Save. 24, Click Apply Policy. Turn off blocking for all but your custom violation 25, On the Learning and Blocking Settings page, click the Blocking Settings button. Policy Building Settings 26. Tum off blocking for all violations except your custom violation called violation limit exceeded. Ensure that blocking is selected for your custom violation. BRB S a Oo iE HE B EEE SBS a EGS fOo i i | a a EEE BS O 27. Click Change. 28. Click Save and then Apply Policy. Test custom violation 29. Go back to the auction site, and then send a single request with one violation in it. For example, ‘you can enter the