Counter-strike Mirai with F5 iRules

David Holmes from F5 is back with one bad-ass iRule to combat Mirai. After reviewing the source code for Mirai and a post by Scott Tenaglia David put together an iRule to cause Mirai to do a bad memory move and crash. Check out his post here:

https://devcentral.f5.com/articles/mirai-strikeback-an-irule-to-kill-iot-bot-processes-from-your-f5-22644

Lastly, the iRule in question:

when RULE_INIT {
        set static::mseconds 10000
        set static::maxdupreq 10
    }
    when CLIENT_ACCEPTED {
        set dup_req 0
        set last_req ""
    }
    when HTTP_REQUEST { 
        if { $last_req equals "" } {
            set last_req [HTTP::uri]
            set dup_req 0
        }
        elseif { $last_req == [HTTP::uri] } {
            incr dup_req
            after $static::mseconds { if {$dup_req > 0} {incr dup_req -1} } 
            if { $dup_req > $static::maxdupreq } {
                log "Killing suspected Mirai at [IP::client_addr]"
                TCP::respond "HTTP/1.0\r\n200 OK\r\nLocation: http\r\n\r\n"
                TCP::close
            }
        }
        else {
            set dup_req 0
        }
    }

Best Regards,

BD

 

ASM Proactive bot detection – Selective URLs

I would love to say that all URLs are created equal but that is not always the case. The same could be said about applying a security policy. Sometimes the logic behind one URL needs to be completely different. With the power of ASM + iRules, we can kick that logic up a notch.

when RULE_INIT {
  # Friends don't let friends log in production.
  # Logging off=0, Logging on =1
  set static::DEBUG_LEVEL 0
  }
when BOTDEFENSE_ACTION {
        if {[HTTP::uri] ends_with "/faq"} {
            if { $static::DEBUG_LEVEL == 1} { 
            log local0.alert "Allowed [HTTP::header User-Agent] to access [HTTP::uri]"
            log local0.alert "*************************************"
            log local0.alert ""
            log local0.alert "" }
            BOTDEFENSE::cs_allowed true
            set res [BOTDEFENSE::action allow]
        }   
        # EXAMPLE 2: Instead of blocking the request with TCP RST, respond with a
        # blocking-page
        if {[BOTDEFENSE::action] eq "tcp_rst" and [HTTP::uri] eq "/bloc_page_test" } {
                # if the custom_response action fails, the tcp_rst action will remain,
                # so we don't need to check the return string in this case
                BOTDEFENSE::action custom_response "sorry\ni am blocking you again\n"
        }
        if {not (([BOTDEFENSE::action] eq "allow") && ([BOTDEFENSE::reason] eq "valid cookie; no need to renew"))}
        {
          if { $static::DEBUG_LEVEL == 1} {
            log local0.alert "Got request from IP [IP::client_addr]"
            log local0.alert "UA is [HTTP::header User-Agent]"
            log local0.alert "Bot action is [BOTDEFENSE::action] because [BOTDEFENSE::reason]"
            log local0.alert "DeviceID is [BOTDEFENSE::device_id]"
            log local0.alert "*************************************"
            log local0.alert ""
            log local0.alert ""}
        }

        # EXAMPLE: Send a CAPTCHA challenge on the login page, and only allow the
        # login if the user passed the CAPTCHA challenge 

            if {[BOTDEFENSE::action] eq "allow"} {
            if {[BOTDEFENSE::captcha_status] ne "correct"} {
                if {[HTTP::uri] eq "/user/login"} {
                    set res [BOTDEFENSE::action captcha_challenge]
                    if {$res ne "ok"} {
                      if { $static::DEBUG_LEVEL == 1} {
                        log local0. "cannot send captcha_challenge: \"$res\"" }
                        BOTDEFENSE::action tcp_rst
                    }
                } elseif {[HTTP::uri] eq "/user/login"} {
                    set res [BOTDEFENSE::action custom_response {
                        login failed because you may not be human
                    }]
                    if {$res ne "ok"} {
                      if { $static::DEBUG_LEVEL == 1} {
                        log local0. "cannot send blocking page: \"$res\"" }
                        BOTDEFENSE::action tcp_rst
                    }
                }
            }
        }

}

As you can see, the power of iRules we can make decisions based on the following:

  • URI
  • DeviceID
  • TCP RST OR DROP
  • CAPTCHA

And that’s just how we do it at F5, stop the bad guys and look good doing it.

Best Regards,

BD

 

iRule: CAPTCHA Challenge during Brute Force Attack

Brute force attacks can be painful especially if your application has no logic to help mitigate the attack. Since December of 2015 I have seen several brute force attacks that have traversed multiple business verticals.

I know what you are thinking, “But Brian, we have a cloud based WAF so we are protected.” In every vertical listed above, they all had a cloud based WAF, specifically one of the following:  Akamai Kona, Imperva Incapsula, and CloudFlare WAF. To the customers surprise, these services were not able to mitigate these attacks.

Customer feedback on Akamai Kona:

“They (Akamai Kona) are supposed to be our cloud WAF. Until recent events, we thought we were covered. Turns out, they can’t stop simple HTTP POST attacks!” CISO

Customer feedback on Imperva Incapsula:

“We were originally led to believe that Incapsula was their SecureSphere product in the cloud–it is actually nothing more than a modified version of ModSecurity.

Note: Incapsula is NOT a modified version of ModSecurity–the lack of features in Incapsula led them to believe it was.

When we asked why they didn’t detect the attack they told us that the 4,000 to 6,000 IPs that did the brute force attack (we had to provide the IPs too) weren’t classified in Incapsula as known bad actors. They do not have any mechanisms available to detect bot traffic based on behavior, only IP. The tricky part of this Bot Net was how it behaved, it wasn’t a ton of HTTP POSTS, the Bot behaved as a regular user and only performed 33 to 50 POSTs over a 48 hour period. ” -Security Correlation Specialist

Edit: I had a reference to Skyfence in the above paragraph, copy/paste mistake on my behalf. Credit Ofer Gayer.

Customer feedback on CloudFlare WAF:

“I think CloudFlare’s WAF most innovative feature is holding customers hostage with their crippling low self esteem. Seriously, they are like the prettiest Denny’s waitress of cloud based services and their attitude is “Appreciate what you got, even if what you got is a woman built like mashed potatoes.”” -Network Engineer

Not all cloud based WAFs are created equal. F5 Siverline WAF is the only  cloud based WAF  (F5 ASM) that is recognized in the Gartner Magic Quadrant for Web Application Firewalls. What does this mean to  you? Well for starters, you get:

  • Consistent Security Policy for both on prem and in the cloud
  • Perfect forward secrecy so you can obtain that A+ rating on SSL Labs
  • Complete managed solution, just wear your architect hat if you want to
  • Positive logic security model; ability to learn every HTTP method, header, url, parameter, referrer, cookie, etc
  • Behavioral based detection for botnets, not just IP based
  • The power of iRules!

Since each customer had F5 on prem, they were able to mitigate these attacks when their Cloud WAF couldn’t. One popular technique that was effective was F5 Proactive BOT Defense and CAPTCHA.  Using the iRule below, when the site was being brute forced, we were able to throw a CAPTCHA page to the BOTs and successfully mitigate the attack.

when BOTDEFENSE_ACTION {
    # LOGGING OFF  = 0
    # LOGGING ON   = 1
    set DEBUG_LEVEL 0
    if {[BOTDEFENSE::action] eq "allow"} {
        if {[BOTDEFENSE::captcha_status] ne "correct"} {
                set res [BOTDEFENSE::action captcha_challenge]
                if {$res ne "ok"} {
                    if { $DEBUG_LEVEL == 1} { log local0. "Unable to send captcha_challenge: \"$res\"""}
                    BOTDEFENSE::action tcp_rst
                }
        }
    }
}

While this iRule was used to mitigate the attack on prem, if the customer wanted to use the exact same iRule with F5 Silverline WAF they could. Pretty sweet.

Regards,

BD