Risk Remediation And The Power Of iRules

Published on behalf of Nathan McKay, F5 Security Marketing Solutions Architect

The incidence and severity of attacks on your network and the applications your business relies upon increase every year. The first line of defense is often your BIG-IP device, which functions as a strategic point of control to manage critical information flow, while also improving the delivery of applications through security enhancements.

In addition to the built-in security features of the BIG-IP platform, you can take advantage of an easy-to-use scripting language to customize security for your specific environment. Based on TCL and JavaScript (iRules LX), iRules enables you to select how you route, redirect, reject, intercept, inspect, transform, and basically control all inbound or outbound application traffic.

How iRules works

iRules makes it easy to modify any HTTP application, including events, headers, content modification, traffic redirection, and more. Binary applications are a bit more complicated to parse and analyze, but iRules allows you to look for specific data in binary streams, which can be useful when facing an exploit attempt. iRules also provides support for many non-HTTP protocols and events, such as DNS and SSL.

Analysts predict that encrypted traffic will jump to nearly 64% of all North American online traffic in 2016, up from just 29% in 2015. Because SSL makes traffic invisible to intermediary devices, your BIG-IP device must terminate SSL traffic in order to perform layer 7 inspection and content modifications through iRules. The good news is that the BIG-IP platform is great at doing this, easing the computational burden on your application servers by serving as a full proxy for TCP, HTTP, and SSL.

Finally, there are a number of iRules commands designed specifically to help you manage DNS traffic. From enabling or disabling a specified packet to returning geographical information on a particular packet and setting a record class field, iRules gives you control over your DNS traffic from a central point in the network.

How to use iRules

The ideal time to use an iRule is when you’re looking to add functionality to your application or app deployment at the network layer—and that functionality is not readily available via the built-in configuration options in your BIG-IP device. There are several major use cases that show how effective iRules can be in mitigating common attacks and patching vulnerabilities.

DDoS attack mitigation

Apply dynamic connection rate limiting
Block or drop connections by source or destination network, protocol, or IP geo-location
Deny requests or drop connections that attempt to exploit bugs in third-party and open-source software

SSL-level requirements and enforcement

Log attempts to use weak ciphers or downgrade SSL connections
Redirect users of older browsers and cipher suites
Detect, drop, or redirect requests attempting to target SSL vulnerabilities

Virtual patching

Filter content on a granular level such as requesting URL, method, etc.
Detect, filter, and block malicious payloads in application streams
Utilize and integrate with third-party signatures

What makes iRules different

As a full-featured, custom-built scripting language, iRules offers BIG-IP users an unparalleled level of control. Full programmability means that there’s no waiting for third-party signatures; instead, you can write rules to respond to situations as they develop. In addition, because it’s so flexible, you can even create rules to address issues in your in-house or custom-built software.

iRules makes it simple to respond automatically to detected attack attempts. This functionality can help enable your in-house SIRT (Security Incident Response Team) as F5 or the community provide virtual patches for various vulnerabilities in the form of iRules mitigations, often the same day they are announced. Furthermore, the simple and transparent nature of iRules enables SIRT teams to evaluate the efficacy of each mitigation using the built-in statistics and logging functionality.

Finally, the DevCentral community provides an excellent resource base to learn about the mitigations developed by peers, discover ways to adapt and improve your own methods, and share particularly successful implementations.

Code examples

The following are just a few examples of how organizations have used iRules to protect their networks and applications from common attacks and vulnerabilities. They are by no means exhaustive, but provide a good foundation for learning about the construction and application of iRules events and code structure.

Layer 3 example
Here we have an example that uses GeoIp location data to identify the source country of inbound connections. This might be useful if a large number of malicious connections are originating from a particular nation or set of nations. The example leverages a “data class” to evaluate against. Using the data class allows us to dynamically update the list of blocked countries without having to update the iRule itself.

This particular example shows how to block connections that originate from a certain set of countries (blacklist model); however, this could easily be inverted to only allow connections from a certain set of countries (whitelist model).

First the data class as configured on the BIG-IP:

ltm data-group internal blocked_ccs {
    records {
        CA { }
        ES { }
        FR { }
        GB { }
        US { }
    }
    type string

Next the iRule itself:

when CLIENT_ACCEPTED {

    ### Evaluate the client's country code against a data group
    ### containing the country codes we want to block
    if { [class match [whereis [IP::client_addr] country] equals blocked_ccs] } {
        
        ### Optionally log a message that the client connection was dropped
        ### Disable or use High Speed Logging if actually under attack
        log "Dropping connection from client: [IP::client_addr], country code: [whereis [IP::client_addr] country]"
        
        ### Drop the connection if a country code match was located
        drop
        
    }
}

And here is an example of a simplified version of the whitelist model that does not use a data group:

when CLIENT_ACCEPTED {
   set CC [whereis [IP::client_addr] country]
   ### Allow from the US, Spain, France)
   if { !($CC equals "US" or $CC equals "ES" or $CC equals "FR") } {
    drop
    ### Disable or use High Speed Logging if actually under attack
    log "Dropped connection from client: [IP::client_addr], country code: [whereis [IP::client_addr] country]"   
   }
}

Layer 7 example
This is a rule to mitigate Slowloris attacks where the attacker opens new connections to the web server, but doesn’t send a complete request in a timely fashion, eventually consuming all of the target webserver’s available threads. In this case, we start a timer when the client initially connects, and we give them a full second to send a complete HTTP request, including headers. Once we have the complete request, we set a Boolean variable to be evaluated after the timer expires. If the value is false, we silently drop the connection.

when CLIENT_ACCEPTED {
    
    ### Set an initial false value for $rtimer
    set rtimer 0
    
    ### Execute this block after 1 second
    after 1000 {
        ### If $rtimer hasn't been set to true then drop the connection
        if {not $rtimer} {
            drop
        }
    }
}

when HTTP_REQUEST {
    ### Set $rtimer to true to indicate that 
    ### we have received a HTTP complete request
    set rtimer 1
}

See also: Mitigating Slowloris denial-of-service (DoS) attacks with the BIG-IP system
https://support.f5.com/kb/en-us/solutions/public/10000/200/sol10260.html?sr=55535838
Binary protocol example
The following is an example of using iRules to do binary protocol analysis. In this case, we are analyzing the SSL handshake between a client and server where a BIG-IP device is not terminating SSL for whatever reason (were SSL being terminated by the BIG-IP device, this would be mitigated natively). We first have to capture the client-side data in order to subsequently evaluate it using the “binary scan” command later in the rule.

These kinds of rules can be more difficult to write and implement, but in the case of larger scale vulnerabilities, F5 engineers are likely to provide them to the community at large (such as the case with the iRule below). In any case, it is a viable mitigation strategy should the need arise.

##############################################
# Name: heatbleed.c rejector irule.
# Description: This irule is a tweak to https://devcentral.f5.com/s/articles/ssl-heartbleed-irule-update
# Purpose: to block heartbleed requests.
# - added check for 768 and 769 ( SSLv3 and TLSv1 )
# - Ensure r is a positive value. This only happens when there is no valid SSL record.
# VERSION: 4 - 16.apr.14
##############################################
when CLIENT_ACCEPTED {
    TCP::collect
    set s 0
    set r 0
}
when CLIENT_DATA {
    set c [TCP::payload length]
    set i 0
    while { $i < $c } {
    set b [expr {$c - $i}]
    if { $s } {
        # skipping payload
        if { $b >= $r } {
        set s 0
        set i [expr {$i + $r}]
        } else {
        set r [expr {$r - $b}]
        set i [expr {$i + $b}]
        }
    } else {
        # parsing TLS record header
        if { $b < 5 } {            
           break
        }
        binary scan [TCP::payload] @${i}cSS t v r
        set r [expr {$r & 0xFFFF}]
        set i [expr {$i + 5}]
        if { $t == 24 }{
        switch -- $v {
            "768" -
            "769" -
            "770" -
            "771" -
            "772" {
             log local0. "Detected Heartbeat Request from [IP::remote_addr]. REJECTING!"
             reject
            }
        }
        }
        set s 1
    }
    }
    TCP::release $i
    TCP::collect
}

See also: SSL Heartbleed iRule update
https://devcentral.f5.com/s/articles/ssl-heartbleed-irule-update

Conclusion

Thanks to the programmability and flexibility of iRules, the sky’s the limit for what you can do with this easy-to-use custom scripting language. Whether you want to do SSL inspection, rate limiting, fine-grain content filtering or more, iRules allows you to customize the BIG-IP platform for your needs. As a network-aware, event-driven language, iRules make it easy to add business and application logic to your deployment—while protecting your network and applications from common attacks.

It is also important to note that iRules are just one tool available to address DDoS and other types of attacks. The BIG-IP system includes many built-in mechanisms for mitigating these types of issues that don't require iRules.

For some examples, see the following resources:

SOL14813: Detecting and mitigating DoS/DDoS attacks (11.4.x–12.x)
https://support.f5.com/kb/en-us/solutions/public/14000/800/sol14813.html?sr=55535838

F5 DDoS Protection: Recommended Practices
https://f5.com/resources/white-papers/f5-ddos-protection-recommended-practices

SOL5670: Overview of adaptive connection reaping
https://support.f5.com/kb/en-us/solutions/public/5000/600/sol5670.html

SOL7301: Protecting BIG-IP LTM against denial of service attacks
https://support.f5.com/kb/en-us/solutions/public/7000/300/sol7301.html

SOL7113: Limiting responses from BIG-IP LTM for ICMP errors and ICMP Unreachable events
https://support.f5.com/kb/en-us/solutions/public/7000/100/sol7113.html

SOL5780: Error message: Limiting < closed | open > port RST response from to packets/sec
https://support.f5.com/kb/en-us/solutions/public/5000/700/sol5780.html

SOL9259: Limiting the rate at which the BIG-IP system issues TCP RSTs or ICMP unreachable packets
https://support.f5.com/kb/en-us/solutions/public/9000/200/sol9259.html

Published Aug 29, 2016

Version 1.0

ddos

devops