Latest News from Jason Rahm

Come Join DevCentral for the Seattle DotNetNuke User Group Meeting

Thu, 02 Feb 2012 03:07:20 EST

If you didn’t know, the DevCentral platform runs on DotNetNuke, the leading open source ASP.Net CMS. It’s a great development platform for turning out rich sites, and we’re excited to be hosting the next Seattle DNN User Group meeting next Wednesday, February 8th, beginning at 6pm at 401 Elliot Ave West, Seattle, WA.

Agenda

6:00 - Arrive Sign in
6:10 - Tour F5 facilities
6:30 – Presentation Begins

Steven – Introductions and DC/DNN Overview
April – Managing a Community
Jason – Overview of the infrastructure we run

7:20 – Q & A
7:30 – Social Hour – Buckley’s

We’re super excited to be involved in this next DNN user group, hope to see you there!

Technorati Tags: F5 DevCentral,DotNetNuke,DNN,Seattle DNN User Group,Buckley's

Juice-Jacking Revisited

Tue, 31 Jan 2012 03:22:09 EST

It’s a crazy world out there. I ran (well, by “ran” I mean jogged slowly enough to pass the old ladies on the track) this morning at the YMCA, lifted weights for a little while, and then hit the elliptical for 20 minutes before heading home. My gym’s ellipticals have the Nike+ package where you can store your workouts on your iPhone/iPod, and without thinking I jacked in. Approximately 38 ms later (my internal meter is not calibrated) I facepalmed and disconnected my iPhone in shame. Have I learned nothing?

Turns out, after closer inspection, the cable was a standard cable plugged into a standard elliptical trainer, but I didn’t inspect it initially. I just trusted that everything was as it should be. Josh wrote about this trust back in December. This offense, of course, would be fine if it was my iPod, which holds nothing of value on it. But my iPhone? Well, it has quite a bit more I’d rather not share with Mr. or Mrs. Hacker. So what am I worried about?

Juice-Jacking is another physical security attack vector. With smartphones battery charging capabilites tied also to the data access port, any maliciously minded individual could stand up a charging booth, offer it up for free, and the lambs would willingly head to the slaughter. As power surges into their batteries, their data surges into the hands of the enemy. Such was the case at DefCon this year, where at least 360 attendees, made acutely aware of connecting in any way to anything within a 2 mile radius of the conference, still powered up. Brian Krebs had a good post-DefCon write-up on Juice-Jacking you should check out. Be careful out there.

Technorati Tags: F5 DevCentral,Security,Juice-Jacking,Jason Rahm,Josh Michaels

Managing Ramcache Entries with Pycontrol

Tue, 10 Jan 2012 10:30:00 EST

A DevCentral user posted a question in the forums asking for verification of an attribute on the RamCacheKey structure. The maximum_responses attribute should be a long integer. With his C# code, the maximum_responses returned from his iControl call is always double the setting. I fired up pycontrol to see if this was a bug, and in my pycontrol code, I received the expected responses. While he’s taking a look at his code and the .Net library he’s using, I took an interest in the ramcache methods as I have not messed with the Ramcache module much. In this article, I’ll build out a pycontrol script that will enable users to query/evict ramcache entries.

The Interface

The iControl interface for querying/evicting Ramcache entries is RAMCacheInformation. The methods I’ll handle in the script are:

There are two more methods defined:

get_version – All interfaces have this method, not important to Ramcache function
get_ramcache_entry – Deprecated in favor of _v2 above.

Preparing the BIG-IP

Beginning in v11, the ramcache configuration was removed from the http profile and moved into its own under Local Traffic->Profiles->Services->Web Acceleration. I created a profile called lcache with a parent profile of optimized-caching, increasing the cache size to 25 MB and decreasing the max age to 3600 seconds for testing. I left all the other settings default.

Apply this profile to an http virtual and a pool member with some content and I’m ready to move to the iControl work.

Building the Script

Because there are multiple actions in this interface I want to address, I’ll use command line options to control the script flow:

Host – (-H) Required
Username (-u) Required
Get Entries (-g) Profile Required
Get Exact Entry (-x) Profile, Host and URI required (as a white-space separated list in quotes. Ex. “lcache 10.10.20.60 /images/img1.png”
Evict Entry (-E) Profile, Host and partial URI required
Evict Exact Entry (-X) Profile, Host and URI required
Evict All Entries (-A) No arguments necessary, empties the ramcache

With that plan in place, I can configure the parser options, shown in the following code snippet:

  1:  from optparse import OptionParser

  2:   

  3:  parser = OptionParser()

  4:  parser.add_option("-H", "--host", action="store", type="string", dest="host")

  5:  parser.add_option("-u", "--user", action="store", type="string", dest="uname")

  6:  parser.add_option("-g", "--get", action="store", type="string", dest="get", help="Supply profile name")

  7:  parser.add_option("-x", "--get_exact", action="store", type="string", dest="get_exact", help="Supply profile name, host, and URI")

  8:  parser.add_option("-E", "--evict", action="store", type="string", dest="evict_entry")

  9:  parser.add_option("-X", "--evict_exact", action="store", type="string", dest="evict_exact")

 10:  parser.add_option("-A", "--evict_all", action="store_false", default=False, dest="evict_all")

 11:  (options, args) = parser.parse_args()

 12: 

 13:  if (options.host is None) or (options.uname is None):

 14:   print "\n\tHost (-H) and username (-u) must be supplied, exiting..."

 15:   sys.exit()

Now that the options are in place, we need to act based on the options provided

  1:  if options.get is not None:

  2:   rce = getRAMCacheEntries(rc, options.get)

  3:   print rce

  4: 

  5:  elif options.get_exact is not None:

  6:   rce = getRAMCacheExactEntry(rc, options.get_exact)

  7:   print rce

  8: 

  9:  elif options.evict_entry is not None:

 10:   rce = evictRAMCacheEntry(rc, options.evict_entry)

 11:   print rce

 12: 

 13:  elif options.evict_exact is not None:

 14:   rce = evictRAMCacheExactEntry(rc, options.evict_exact)

 15:   print rce

 16: 

 17:  elif options.evict_all is not None:

 18:   rce = evictRAMCacheAllEntries(rc)

 19:   print rce

 20: 

 21:  else:

 22:   print "No options selected!"

 23:   sys.exit()

In this code, I’m checking for the options and if none are set, I’m exiting. For each option, I’m calling a function to operate on that particular action. I’m passing the iControl object (see code below) and the argument list (“profile host uri”) as necessary to each function.

  1:  b = pc.BIGIP(

  2:   hostname = options.host,

  3:   username = options.uname,

  4:   password = upass,

  5:   fromurl = True,

  6:   wsdls = ['LocalLB.RAMCacheInformation']

  7:  )

  8: 

  9:  rc = b.LocalLB.RAMCacheInformation

For all the functions except the one to handle evicting all ramcache entries, I need to create an object for the RamCacheKey structure. This is done in pycontrol with the typefactory. Once the structure is created, I just need to add the appropriate attributes as defined in the API: profile_name, host_name, uri, and maximum_responses. The first three are strings, the last is a long integer. So the code is very similar in each function:

  1:  rc_key=obj.typefactory.create('LocalLB.RAMCacheInformation.RAMCacheKey')

  2: 

  3:  key_attr = rc_info.split(' ')

  4:  rc_key.profile_name = key_attr[0]

  5:  rc_key.host_name = ''

  6:  rc_key.uri = ''

  7:  rc_key.maximum_responses = 100L

I split the arguments to get each attribute isolated, then assign as appropriate. For a general get, I only need the profile name so I set the host and uri to an empty string. I chose 100 as a max response just to pick something. Now that the structure is defined, I can make an iControl call, in this case, to get all ramcache entries, then I return those values from the function to the variable making the function call above.

  1:  rc_entry = obj.get_ramcache_entry(keys=[rc_key])

  2:  return rc_entry

So if I put all this together, I can issue this command at the command line, with the data below returned:

C:\Users\jrahm\PycharmProjects\pyControl_Scripts>python ramcache_manager.py -H 10.10.20.5 -u admin -g lcache
Please enter the password for user admin
Password:
[](LocalLB.RAMCacheInformation.RAMCacheEntry){
   profile_name = "lcache"
   host_name = "10.10.20.60"
   uri = "/images/gnome-64.png"
   vary_type = "RAM_CACHE_VARY_NONE"
   vary_count = 1
   hits = 0
   received = 1326237864
   last_sent = 1326237864
   expiration = 1326241060
   size = 4677
 }, (LocalLB.RAMCacheInformation.RAMCacheEntry){
   profile_name = "lcache"
   host_name = "10.10.20.60"
   uri = "/images/ad_remoteauth_ssh_1.png"
   vary_type = "RAM_CACHE_VARY_NONE"
   vary_count = 1
   hits = 0
   received = 1326237873
   last_sent = 1326237873
   expiration = 1326241069
   size = 16304
 }, (LocalLB.RAMCacheInformation.RAMCacheEntry){
   profile_name = "lcache"
   host_name = "10.10.20.60"
   uri = "/images/ad_descr.png"
   vary_type = "RAM_CACHE_VARY_NONE"
   vary_count = 1
   hits = 0
   received = 1326237818
   last_sent = 1326237818
   expiration = 1326241014
   size = 17942
 }[]

Now, if I want to evict one of those, I can change my options a little and try again, then do another query:

C:\Users\jrahm\PycharmProjects\pyControl_Scripts>python ramcache_manager.py -H 10.10.20.5 -u admin -E "lcache 10.10.20.60 /images/ad_descr.png"
Please enter the password for user admin
Password:
None

C:\Users\jrahm\PycharmProjects\pyControl_Scripts>python ramcache_manager.py -H 10.10.20.5 -u admin -g lcache
Please enter the password for user admin
Password:
[](LocalLB.RAMCacheInformation.RAMCacheEntry){
   profile_name = "lcache"
   host_name = "10.10.20.60"
   uri = "/images/gnome-64.png"
   vary_type = "RAM_CACHE_VARY_NONE"
   vary_count = 1
   hits = 0
   received = 1326237864
   last_sent = 1326237864
   expiration = 1326241060
   size = 4677
 }, (LocalLB.RAMCacheInformation.RAMCacheEntry){
   profile_name = "lcache"
   host_name = "10.10.20.60"
   uri = "/images/ad_remoteauth_ssh_1.png"
   vary_type = "RAM_CACHE_VARY_NONE"
   vary_count = 1
   hits = 0
   received = 1326237873
   last_sent = 1326237873
   expiration = 1326241069
   size = 16304
 }[]

You can see that the entry is now gone. And finally, If I evict all:

C:\Users\jrahm\PycharmProjects\pyControl_Scripts>python ramcache_manager.py -H 10.10.20.5 -u admin -A
Please enter the password for user admin
Password:
None

C:\Users\jrahm\PycharmProjects\pyControl_Scripts>python ramcache_manager.py -H 10.10.20.5 -u admin -g lcache
Please enter the password for user admin
Password:
[][]

Conclusion

There is access to great power via the iControl interface of your BIG-IP. With just a few lines of code, you can manage the ramcache from the CLI. For the full script, please check out the RAMCache Manager wiki page in the iControl codeshare. Happy Coding!

v11.1: DNS Blackhole with iRules

Wed, 28 Dec 2011 09:06:00 EST

Back in October, I attended a Security B-Sides event in Jefferson City (review here). One of the presenters (@bethayoung) talked about poisoning the internal DNS intentionally for known purveyors of all things bad. I indicated in my write-up that I’d be detailing an F5-based solution, and whereas a few weeks has turned into a couple months, well, here we are. As much as I had hoped to get it all together on my own, F5er Hugh O’Donnell beat me to it, and did a fantastic job. F5er Lee Orrick also contributed to the solution and I’ll have more from him in a future article.

Conceptual Overview

Before jumping into the nuts and bolts, I’d like to describe the solution. First, consider normal operation: Joe Anonymous is surfing and hits a popular page that has been compromised. He hits a link for a cute video about puppies and rainbows and NOT SO FAST MY FRIEND! Instead of said cute puppies and rainbows video, he ends up with a nasty case of malware and his friendly neighborhood IT staff gets to spend some time remediating the damage—if it’s caught at all. See, DNS is if not the backbone of the internet, at least several of the vertebrae. And it does its job very well. Asked and answered. Done. If you hit a link with a malicious domain, there’s a very very good chance your DNS server will have no safeguards in place, it’ll answer away. This is what a blackhole DNS solution is configured to overcome. The networking folks in the audience will be familiar with blackhole routing, and this is really no different a concept. When a user makes a query, the service inspects the destination, and if it matches a list of well known badness, it returns an address of an internal site where remediation or at least notification can take place. In either event, the request is not hitting the malicious destination, which protects user and organization. See Figure 1 for the flow detail.

Building the Datagroup

As with iFiles in v11.1, datagroups can also be imported via the GUI and then referenced similarly. To import your blacklisted domains (there’s a big list here: mirror1.malwaredomains.com), make sure your text editor is set for line feed terminator only (CR-LF won’t work) and use this format for each entry:

“.abbcp.cn” := “harmful”,

“.3dglases-panasonic-tv.com” := “zeusv2”,

The first field is the domain, and the second field is a type description. The first will match your traffic, the second is strictly for classification purposes and can be edited as necessary.

Intercepting the DNS Requests

This solution can be implemented with LTM or GTM, though if the latter, the iRule will still need to be attached to the virtual server associated with the wideIP instead of the wideIP itself. In this article, I’ll implement the LTM-based solution. As I’ll be utilizing the new DNS:: commands, a DNS profile will need to be attached to the virtual server as well as the iRule below. Note that the blackhole class (named appropriately Blackhole_Class in the iRule below) should be present on the system for this solution to work.

# Author:  Hugh O'Donnell, F5 Consulting

when RULE_INIT {

    # Set IPV4 address that is returned for Blackhole matches for A records

    set static::blackhole_reply_IPV4 "10.10.20.50"

    # Set IPV6 address that is returned for Blackhole matches for AAAA records

    set static::blackhole_reply_IPV6 "2001:19b8:101:2::f5f5:1d"

    # Set TTL used for all Blackhole replies

    set static::blackhole_ttl "300"

}



when DNS_REQUEST {

    # debugging statement see all questions and request details

  # log -noname local0. "Client: [IP::client_addr] Question:[DNS::question name] Type:[DNS::question type] Class:[DNS::question class] Origin:[DNS::origin]"



    # Blackhole_Match is used to track when a Query matches the blackhole list

    # Ensure it is always set to 0 or false at beginning of the DNS request

    set Blackhole_Match 0



    # Blackhole_Type is used to track why this FQDN was added to the Blackhole_Class

    set Blackhole_Type ""



    # When the FQDN from the DNS Query is checked against the Blackhole class, the FQDN must start with a

    # period.  This ensures we match a FQDN and all names to the left of it.  This prevents against

    # malware that dynamically prepends characters to the domain name in order to bypass exact matches

    if {!([DNS::question name] == ".")} {

        set fqdn_name .[DNS::question name]

    }



    if { [class match $fqdn_name ends_with Blackhole_Class] } {

        # Client made a DNS request for a Blackhole site.

        set Blackhole_Match 1

        set Blackhole_Type [class match -value $fqdn_name ends_with Blackhole_Class ]



        # Prevent processing by GTM, DNS Express, BIND and GTM Listener's pool. 

        # Want to ensure we don't request a prohibited site and allow their server to identify or track the GTM source IP.

        DNS::return

    }    

}



when DNS_RESPONSE {

    # debugging statement to see all questions and request details

    # log -noname local0. "Request: $fqdn_name Answer: [DNS::answer] Origin:[DNS::origin] Status: [DNS::header rcode] Flags: RD [DNS::header rd] RA [DNS::header ra]"



    if { $Blackhole_Match } {

        # This DNS request was for a Blackhole FQDN. Take different actions based on the request type.

        switch [DNS::question type] {

            "A"     {

                    # Clear out any DNS responses and insert the custom response.  RA header = recursive answer

                    DNS::answer clear

                    DNS::answer insert "[DNS::question name]. $static::blackhole_ttl [DNS::question class] [DNS::question type] $static::blackhole_reply_IPV4"

                    DNS::header ra "1"



                    # log example:  Apr  3 14:54:23 local/tmm info tmm[4694]:

                    #     Blackhole: 10.1.1.148#4902 requested foo.com query type: A class IN A-response: 10.1.1.60

                    log -noname local0. "Blackhole: [IP::client_addr]#[UDP::client_port] requested [DNS::question name] query type: [DNS::question type] class [DNS::question class] A-response: $static::blackhole_reply_IPV4 BH type: $Blackhole_Type"

                    }

            "AAAA"     {

                    # Clear out any DNS responses and insert the custom response.  RA header = recursive answer

                    DNS::answer clear

                    DNS::answer insert "[DNS::question name]. $static::blackhole_ttl [DNS::question class] [DNS::question type] $static::blackhole_reply_IPV6"

                    DNS::header ra "1"



                    # log example:  Apr  3 14:54:23 local/tmm info tmm[4694]:

                    #     Blackhole: 10.1.1.148#4902 requested foo.com query type: A class IN AAAA-response: 2001:19b8:101:2::f5f5:1d

                    log -noname local0. "Blackhole: [IP::client_addr]#[UDP::client_port] requested [DNS::question name] query type: [DNS::question type] class [DNS::question class] AAAA-response: $static::blackhole_reply_IPV6 BH type: $Blackhole_Type"

                    }

            default {

                    # For other record types, e.g. MX, NS, TXT, etc, provide a blank NOERROR response

                    DNS::last_act reject



                    # log example:  Apr  3 14:54:23 local/tmm info tmm[4694]:

                    #     Blackhole: 10.1.1.148#4902 requested foo.com query type: A class IN unable to respond

                    log -noname local0. "Blackhole: [IP::client_addr]#[UDP::client_port] requested [DNS::question name] query type: [DNS::question type] class [DNS::question class] unable to respond  BH type: $Blackhole_Type"

                    }

        }

    }

}



This iRule handles the DNS request, responding on behalf of GTM or any DNS servers being load balanced by LTM. And since we’re handling the blackhole site, we can serve that up as well from an iRule on an HTTP virtual server.

Serving the Remediation Page

The remediation page can be as simple as a text message indicating malware, or it can be a little more complex to show the category of the problem site as well as provide some contact information. The iRule below is an example of the latter.

# Author: Hugh O’Donnell, F5 Consulting



when HTTP_REQUEST {



    # the static HTML pages include the logo that is referenced in HTML as corp-logo.gif

    # intercept requests for this and reply with the image that is stored in an iFile defined in RULE_INIT below

    if {[HTTP::uri] ends_with "/_maintenance-page/corp-logo.png" } {

        # Present

       HTTP::respond 200 content $static::corp_logo



    } else {

        # Request for Blackhole webpage.  Identify what type of block was in place

        switch -glob [class match -value ".]HTTP::host[" ends_with Blackhole_Class ] {

                "virus"     { set block_reason "Virus site" }

                "phishing"     { set block_reason "Phishing site" }

                "generic"     { set block_reason "Unacceptable Usage" }

                default     { set block_reason "Denied Per Policy - Other Sites" }

        }



        # Log details about the blackhole request to the remote syslog server

        log -noname local0. "Blackhole: From [IP::client_addr]:[TCP::client_port] \

          to [IP::local_addr]:[TCP::local_port], [HTTP::request_num], \

          [HTTP::method],[HTTP::uri],[HTTP::version], [HTTP::host],  [HTTP::header value Referer], \

          [HTTP::header User-Agent], [HTTP::header names],[HTTP::cookie names], BH category: $block_reason,"



        # Send an HTML page to the user.  The page is defined in the RULE_INIT event below

        HTTP::respond 200 content "$static::block_page [HTTP::host][HTTP::uri] $static::after_url $block_reason $static::after_block_reason "

    }   

}





when RULE_INIT {

    # load the logo that was stored as an iFile

    set static::corp_logo [ifile get "/Common/f5ball"]



    # Beginning of the block page

    set static::block_page "

        <html lang=\"en_US\">

        <head>

        <title>Web Access Denied - Enterprise Network Operations Center</title>

        <meta http-equiv=\"Content-Type\" content=\"text/html; charset=us-ascii\">

        <meta http-equiv=\"CACHE-CONTROL\" content=\"NO-CACHE\">

        <meta http-equiv=\"PRAGMA\" content=\"NO-CACHE\">

        <meta http-equiv=\"EXPIRES\" content=\"Mon, 22 Jul 2002 11:12:01 GMT\">

        <style>

        <!--

        .mainbody {

            background-color: #C0C0C0;

            color: #000000;

            font-family: Verdana, Geneva, sans-serif;

            font-size: 12px;

            margin: 0px;

            padding: 20px 0px 20px 0px;

            position: relative;

            text-align: center;

            width: 100%;

        }

        .bdywrpr {

            width:996px;

            height:auto;

            text-align:left;

            margin:0 auto; 

            z-index:1;

            position: relative;

        }

        #banner-wrapper {

            width: 950px;

            padding: 0px;

            margin: 0px;

            overflow:hidden;

            background-color: #FFFFFF;

            background-repeat: no-repeat;

        }

        #banner-image {

            float: left;

            margin-left: auto;

            margin-right: auto;

            padding: 3px 0px 2px 7px;

            width: 950px;

        }

        #textbody {

            background-color: #FFFFFF;

            color: #000000;

            font-family: Verdana, Geneva, sans-serif;

            font-size: 13px;

            width: 950px;

            padding:0px;

            text-align:justify;

            margin: 0px;

  

        }

        -->

        </style>

        </head>

        <body class=\"mainbody\">

        <div class=\"bdywrpr\">

  

                   <div id=\"banner-wrapper\">

                        <!-- BANNER -->

                        <div id=\"banner-image\">

                             <center><img src=\"/_maintenance-page/corp-logo.png\" alt=\"Enterprise Network Operations Center\"></center>

                        </div>

                    </div>

                    <div id=\"textbody\">

                    <table border=\"0\" cellpadding=\"40\"><tr><td>

                        <center><p style=\"font-size:18px\"><b>Access has been denied.<br><br> URL: "



    set static::after_url "</p></center></b></font> <br>

                    Your request was denied because it is blacklisted in DNS. <br><br>

                    Blacklist category: "



    set static::after_block_reason "<br>

                    <p>

                    The Internet Gateways are for official use only. Misuse violates policy.

                    If you believe that this site is categorized incorrectly, and that you have a valid business

                    reason for access to this site please contact your manager for approval

                    and the Enterprise Network Operations Center via

                    <br><br>

                    E-mail: <a href=\"mailto:enoc@example.com\">enoc@example.com</a> <br><br>

                    Please use the Web Access Request Form and include a business justification.

                    &nbsp;

                    Only e-mail that originates from valid internal e-mail addresses will be processed. 

                    If you do not have a valid e-mail address, your manager will need to submit a request on your behalf.

                    </center>

                    <p>

                    <font size=-1><i>Generated by bigip1.f5.com.</i></font>

                </td></tr></table>

                </div>

            </div>

            </body> </html>

        "

}

Note that the remediation page references an iFile for a logo. For details on configuring iFiles, please reference my article on iFiles. Also note that in addition to the client getting a heads-up notification of malfeasance, the visit is logged so other processes, individuals can act on the information.

The Results

First, our DNS query and response. Rather than test out a real well-known bad site, I added espn.com to my blacklist so if I forgot a step and leaked through to the real site I wouldn’t compromise anything. The response from my DNS virtual server is shown in Figure 2 below.

You can see that the address matches the address set in the iRule as our blackhole IPv4 address. Also, the log information from that DNS query:

Dec 28 15:35:08 tmm info tmm[6883]: Blackhole: 10.10.20.251#57714 requested espn.com query type: A class IN A-response: 10.10.20.50 BH type: sports

Next, the resulting remediation page in my browser (Figure 3):

And finally, the log entry from the HTTP request:

Dec 28 15:35:08 tmm info tmm[6883]: Blackhole: From 10.10.20.251:32447 to 10.10.20.50:80, 1, GET,/,1.1, espn.com, , Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7, Host Connection User-Agent Accept Accept-Encoding Accept-Language Accept-Charset,, BH category: Denied Per Policy - Other Sites,

Conclusion

This is a wicked application of iRules with new DNS and file handling features delivered in v11.1. If you wanted to take it even further, you could use sideband connections and reference an external list instead of a datagroup that will need constant refreshing. The GTM version of this solution is documented in the wiki: http://devcentral.f5.com/wiki/iRules.DNS_Blackhole.ashx. If you’re curious about the DNS commands used in the iRule above, I’ll be discussing them in my next tech tip, so check back soon!

v11.1–Add Signatures or Checksums to iRules via an iApp

Mon, 19 Dec 2011 10:06:00 EST

iApps, introduced in v11, have a primary function in controlling the object creation and management for an application delivered by BIG-IP. As discussed previously, however, anything that can be accomplished in TMSH can be done in an iApp, so what better way to quickly generate checksums on iRules than via an iApp. New in v11.1, you can add either a checksum or a digital signature to an iRule (but not both). For iRules that have been signed or had a checksum applied, there will be a line immediately following the final line of code (the last closing curly brace):

#Checksum

definition-checksum <checksum>

#Signature

definition-signature <signature>

The GUI iRules listing will show the verification status of each iRule (see below in Figure 1):

Note that the iRules that are F5 Verified are signed in-house by F5 with the f5-irule certificate. The private key is not distributed with your BIG-IP installation. To sign your own iRules, create a certificate (self signed or otherwise) or just use one on your system. I’d recommend creating one specific for signing iRules so you can distribute amongst all the pairs that will receive iRules that need verification. For this exercise, I created a 10-yr self signed cert called iRulesSignature with throwaway common name and other details. To sign an iRule in the GUI, check the checkbox to the left of the iRule in the iRules listing and then click the Add Signature button at the bottom of the screen as shown in Figure 2.

Select the appropriate key and then click the Add Signature button at the button of the screen as show in Figure 3.

The process is the same as in Figure 2 for the checksum, though the Add Checksum button should be selected instead. There is a pop-up window (see Figure 4 below) confirming the checksum, but no additional configuration parameters are presented before the checksum is applied.

A few quick notes before moving on.

There is no remove signature or checksum button. To do this, just enter the iRule and remove the definition-<checksum|signature> line at the bottom of the iRule.
You can replace/overwrite checksums with checksums and signatures with signatures, but you can’t cross the streams. Attempting to apply a signature to an iRule with a checksum will fail (and vice versa). If you want to sign an iRule with a checksum, remove the checkum first.
You can add a checksum to multiple iRules concurrently, but signing multiple iRules in one pass is not currently supported.

Building the iApp

Now that the basics of iRules signatures and checksums have been addressed, I can build an iApp that will prompt a user to select checksum or signature, prompt for the key if signing, and then prompt for the iRules. The presentation layer (APL) code for this is below, followed by the result of this code in Figure 5 (checksum) and Figure 6 (signature).

section genInfo {
choice sig_or_csum default "Checksum" { "Checksum", "Signature" }
optional (sig_or_csum == "Signature") {
    choice sigKey tcl {
      set objs [tmsh::get_config /sys crypto key]
      foreach obj $objs {
        append results [tmsh::get_name $obj]
        append results "\n"
      }
      return $results
    }
}
multichoice iRulesList tcl {
    set objs [tmsh::get_config /ltm rule]
    foreach obj $objs {
      append results [tmsh::get_name $obj]
      append results "\n"
    }
    return $results
}
}
text {
genInfo "Add Signature or Checksum to iRules"
genInfo.sig_or_csum "Please select Signature or Checksum."
genInfo.sigKey "Please select the key for iRule signature."
genInfo.iRulesList "Please select one or more iRules."
}

Now that the presentation layer is complete, all that remains is the tmsh scripting to take the information from the GUI and apply it to the system. The tmsh command to create the signature or checksum is

tmsh generate /ltm checksum|signature <rule> [signing-key <key>]

This is easy in the shell, but in the scripting language there is not currently a tmsh::generate command, so I’ll need to use exec to call back into the shell as a workaround. With the exec command, every object separated by whitespace must be wrapped in quotes, as shown below in the implementation section of the iApp:

if { $::genInfo__sig_or_csum == "Checksum" } {
foreach obj $::genInfo__iRulesList {
    #puts "Checksum for $obj"
    exec "tmsh" "generate" "ltm" "rule" "checksum" $obj
}
} elseif { $::genInfo__sig_or_csum == "Signature" } {
foreach obj $::genInfo__iRulesList {
    #puts "Signature for $obj with key $::genInfo__sigKey"
    exec "tmsh" "generate" "ltm" "rule" "signature" $obj "signing-key" $::genInfo__sigKey
}
}

I always start with puts instead of the actual execution of tmsh commands so I know what the presentation layer is actually passing to the implementation scripts. The output of puts is /var/tmp/scriptd.out. To make this iApp more complete, you could load the contents of each iRule and strip any previous signature or checksum before applying a new one. I’ll send the latest DevCentral t-shirt to the first submission with this enhancement. Until then, happy coding!

This template is available in the iApp wiki: Add a Signature or Checksum to Multiple iRules

DNS Services Architecture

Fri, 16 Dec 2011 00:59:00 EST

F5 has been in the DNS business for quite some time, beginning with the 3-DNS GSLB product introduced in 1998. While steadily growing the GSLB market through product advances, the platform is incredibly feature rich now, offering far more than GSLB services. Some of the other services added over the years (articles written on services in parentheses):

Standard name services via BIND, as a fallback or as primary domain auth
Local SLB for DNS
DNSSEC (Configuring GTM’s DNS Security Extensions)
Quova geolocation data (New Geolocation Capabilities, Heatmaps)
DNS Express (DNS Express Part 1, DNS Express Part 2)
IP Anycast
DNS 64

As the service offering has grown, the underlying architecture supporting DNS has changed as well to improve performance and scale. Through versions 10.2.x, GTM services were handled outside of TMM in Linux. That means that GTM prior to version 11 had no access to the multi-processor benefits of TMM. Screening mode was introduced in GTM version 10.2, which allowed GTM to load balance DNS services with limited LTM functions. Reference Figure 1 below.

BIG-IP version 11 (see Figure 2 below) introduced a true DNS proxy running natively in TMM. Not only does this deliver a major performance improvement, TMM also understands the DNS traffic if the virtual has a DNS profile attached, it’s no longer just a packet. This means the queries/responses must meet some minimum protocol sanity checks. The DNS proxy also enables (depending on profile configuration) the DNS iRules commands, DNS 64, DNS Express, etc.

The DNS profile options can be seen below in Figure 3. Notice you can enable the services that a particular virtual server will handle, and disable the remaining ones.

Finally, in the most recent v11.1 release, the only change to the architecture was to move the server-side ingress iRules handling (the DNS_RESPONSE event) to the client side of the proxy. This was moved so that responses generated by GTM or DNS Express can be captured/acted upon.

In my next article, I’ll delve into the DNS request/response handling workflows in version 11.1 and cover the new DNS iRules extensions.

v11.1–External File Access from iRules via iFiles

Fri, 09 Dec 2011 07:46:00 EST

New in BIG-IP version 11.1 are iFiles, a feature that allows users to load files through tmsh or the GUI onto the BIG-IP which can be referenced from iRules. This has an immediate use case of supplanting several of our codeshare entries for sorry and/or maintenance pages delivered directly from the BIG-IP instead of redirecting to a server to handle those requests. In this tech tip, I’ll cover the command options, the GUI configuration, and finally offer up a maintenance page iRule referencing iFiles.

Planning the Maintenance Page

When serving up html pages from an iRule in a variable or a data-group, several things, such as encoding images and escaping special characters to prevent Tcl errors or unfortunate interpretations, must be considered. With iFiles, however, much (and potentially all) of that trouble is eliminated. For this maintenance page, I want to return an HTML5 canvas bouncing F5 ball (original script source can be found here at vectorlight.net) to distract users during maintenance. So I’ll need two files, one image file for the F5 bouncing ball, and one text file for the html elements. The html text I’m using is below:

<html><script>
        var surface;
        var happy;
        var x = 50;
        var y = 0;
        var dirX = 1;
        var dirY = 1;

        function drawCanvas() {
            // Get our Canvas element
            surface = document.getElementById("myCanvas");

            if (surface.getContext) {
                // If Canvas is supported, load the image
                happy = new Image();
                happy.onload = loadingComplete;
                happy.src = "f5b_mini.png";
            }
        }

        function loadingComplete(e) {
            // When the image has loaded begin the loop
            setInterval(loop, 15);
        }

        function loop() {
            // Each loop we move the image by altering its x/y position

            // Grab the context
            var surfaceContext = surface.getContext('2d');

            // Draw the image
            surfaceContext.drawImage(happy, x, y);

            x += dirX;
            y += dirY;

            if (x <= 0 || x > 500 - 18) {
                dirX = -dirX;
            }
            if (y <= 0 || y > 250 - 28) {
                dirY = -dirY;
            }
        }
</script>

<body onload="drawCanvas();">
<center>
    <h1>Hey there...</h1><br>
    <h2>Relax and be mesmerized by the F5 ball as we make some changes</h2><br>
    <div>
        <canvas id="myCanvas" width="500" height="250">
            <p>Your browser doesn't support canvas.</p>
        </canvas>
    </div><br>
    <h2>We'll be back online shortly...the DevCentral team</h2>
</center>
</body></html>

Creating the iFiles

Now that my page is ready, I can upload the files. This is done in System->File Management->iFile List->Import:

A couple quick notes on importing files. First, iFiles maximum size is 4M. Second, it’s probably a good idea to adopt a naming standard early in use of iFiles. I’m using <app_function|name_type>, but whatever works, right? Now that the files are on the system (default location: /config/filestore/files_d/Common_d/ifile_d), I need to create a reference for each of them under Local Traffic->iRules->iFile List. I’m just repeating the name I used for the iFile itself:

The iFile Command Syntax

The complete syntax for the iFile command is below. For details on each command, please visit the iFile wiki page.

ifile get <iFile Name>
ifile listall
ifile attributes <iFile Name>
ifile size <iFile Name>
ifile last_updated_by <iFile Name>
ifile last_update_time <iFile Name>
ifile revision <iFile Name>
ifile checksum <iFile Name>
array set <variable> [ifile attributes <iFile Name>]

Creating the iRule

Obviously the logic to serve up the maintenance page would need to be adjusted for a production environment, but for this example I’m just doing an HTTP::respond if the URL is “/”, and then I need a condition for the image as well. So what used to be a lot more work with encoding images and massaging javascript, with iFiles, I can just return the contents with no concerns utilizing the [ifile get <iFile Name>] command. It really is that simple.

when HTTP_REQUEST {
    if { [HTTP::uri] eq "/" } {
        HTTP::respond 200 content [ifile get testapp_index_txt]
    } elseif { [HTTP::uri] eq "/f5b_mini.png" } {
        HTTP::respond 200 content [ifile get testapp_f5ball_img]
    } else { discard }
}

Browsing to the virtual results in this page:

Conclusion

I highlighted the maintenance page use case, but data served from external files will be useful for a large number of scenarios. Happy coding with the new iFiles feature delivered in BIG-IP v11.1.

BIG-IP Configuration Object Naming Conventions

Mon, 28 Nov 2011 10:19:02 EST

George posted an excellent blog on hostname nomenclature a while back, but something we haven’t discussed much in this space is a naming convention for the BIG-IP configuration objects. Last week, DevCentral community user Deon posted a question on exactly that. Sometimes there are standards just for the sake of having one, but in most cases, and particularly in this case, having standards is a very good thing. Señor Forum, hoolio, and MVP hamish weighed in with some good advice.

[app name]_[protocol]_[object type]

Examples:

www.example.com_http_vs
www.example.com_http_pool
www.example.com_http_monitor

As hoolio pointed out in the forum, each object now has a description field, so the metadata capability is there to establish identifying information (knowledge base IDs, troubleshooting info, application owners), but having an object name that is quickly searchable and identifiable to operational staff is key. Hamish had a slight alternative format for virtuals:

[fqdn]_[port]

For network virtuals, I’ve always made the network part of the name, as hamish also recommends in his guidance:

network VS's tend to be named net-net.num.dot.ed-masklen. e.g. net-0.0.0.0-0 is the default address. Where they conflict (e.g. two defaults depending on src clan, it gets an extra descriptor between net- and the ip address. e.g. net-wireless-0.0.0.0-0 (Default network VS for a wireless VLAN). I don't currently have any network VS's for specific ports. But they'd be something like net-0.0.0.0-0-port

Your Turn

What standards do you use? Share in the comments section below, or post to the forum thread.

Technorati Tags: F5 DevCentral,Standards,Nomenclature,BIG-IP,George Watkins,Jason Rahm,hoolio,hamish

Stop that F5 Key From Refreshing the Page

Wed, 16 Nov 2011 09:08:23 EST

No, not “us” F5, the F5 key on the keyboard. You know, the one you hit relentlessly to refresh the page (well, the one I hit relentlessly during NFL games to update my fantasy football stats). Anyway, I was perusing the forums today, trying to catch up from a week attending our very excellent annual sales conference, and I noticed a thread that had to be shared.

The Question

Is there a way of preventing users from using the F5 button to refresh a web page? – DevCentral user ringoseagull (nice handle, btw!)

The Solution

F5er and very active forum patrolman nitass posted back within 30 minutes with a solution, featuring iRules of course! We’ve seen javascript insert iRules before, but this is a pretty handy use case, so I thought I’d share.

when HTTP_REQUEST {
STREAM::disable
if {[HTTP::version] eq "1.1"} {
    if { [HTTP::header is_keepalive] } {
      HTTP::header replace "Connection" "Keep-Alive"
    }
    HTTP::version 1.0
}
}
when HTTP_RESPONSE {
if {[HTTP::header Content-Type] starts_with "text/"} {
    STREAM::expression "@</\[Hh]\[Ee]\[Aa]\[Dd]>@<script language=javascript>function document.onkeydown() { if (event.keyCode==116) { event.keyCode=0; event.cancelBubble=true; return false; } }</script></head>@"
    STREAM::enable
}
}
when STREAM_MATCHED {
STREAM::disable
}

This iRule uses the stream profile to find the head tag and insert the javascript necessary to control the F5 keycode behavior. Curl testing shows the javascript successfully delivered:

[root@ve1023:Active] config # curl -i http://172.28.65.152
HTTP/1.1 200 OK
Dat e: Fri, 11 Nov 2011 15:24:33 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Fri, 11 Nov 2011 14:48:14 GMT
ETag: "4183e4-3e-9c564780"
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=UTF-8

<html>
<head><script language=javascript>function document.onkeydown() { if (event.keyCode==116) { event.keyCode=0; event.cancelBubble=true; return false; } }</script></head>
<body>
This is 101 host.
</body>
</html>

Nice work, nitass!

Related Articles

Technorati Tags: F5 DevCentral,iRules,Jason Rahm

v11: iRules Data Group Updates

Tue, 15 Nov 2011 07:32:00 EST

Several months ago I wrote up the v10 formatting for internal and external datagroups: iRules Data Group Formatting Rules. In v11, however, there is a change to the format of the internal data group and the data group reference to external class files (the formatting in the external class file itself is unchanged). The formatting rules in v11 for data groups more closely resembles the tmsh commands necessary to build the class at the CLI (these command attributes are masked if you are using the GUI). I’ll follow the same format as the original write-up in showing the various data group types. The format is the same among internal data group types. If there is no value associated with the key, there is a curly bracket pair trailing the key on the same line. If there is an associated value with a key, the curly bracket opens the value, followed by a newline with the keyword data and the value, then another newline with the closing curly bracket. After the records are listed, the type is specified. For external data groups, the file name and the type are specified. If the filename is in /var/class, the path is omitted from the filename reference.

Address Data Groups

# Internal Data Group

ltm data-group internal addr_testclass {
    records {
        192.168.1.1/32 { }
        192.168.1.2/32 {
            data "host 2"
        }
        192.168.2.0/24 { }
        192.168.3.0/24 {
            data "network 2"
        }
    }
    type ip
}

# External Data Group

ltm data-group external addr_testclass_ext {
    external-file-name addr_testclass.class
    type ip
}

Integer Data Groups

# Internal Data Group

ltm data-group internal int_testclass {
    records {
        1 {
            data "test 1"
        }
        2 {
            data "test 2"
        }
    }
    type integer
}

# External Data Group

ltm data-group external int_testclass_ext {
    external-file-name int_testclass
    type integer
}

String Data Groups

# Internal Data Group

ltm data-group internal str_testclass {
    records {
        str1 {
            data "value 1"
        }
        str2 {
            data "value 2"
        }
    }
    type string
}

# External Data Group

ltm data-group external str_testclass_ext {
    external-file-name str_testclass.class
    type string
}

iRule::ology–SMTP Start TLS

Wed, 26 Oct 2011 09:49:00 EDT

F5er and DevCentral member natty76 wrote a few iRules a while back on interactive TLS session starting on the SMTP, IMAP, and POP3 protocols. A lot of the iRules can be understood from a flow perspective by reading the iRule top to bottom. This is not the case for these iRules. In this article, I’ll break down the SMTP communication context for the BIG-IP as middleman between client and server. I’ve saved the iRule as an image below so I reference line numbers as I go. The SMTP iRule as well as the IMAP and POP3 iRules are available in the iRules Codeshare. Before digging into the iRule, the usage example in section six of RFC 2487 is illustrated in the drawing below with the steps from our description to follow highlighted on each leg of the protocol exchange.

The iRule

The process starts with the standard TCP 3-way handshake, which results in the CLIENT_ACCEPTED event firing (line 2). At this point I don’t know if the client is requiring TLS yet, so ehlo is set to 0 and SSL is disabled (set by default in the virtual server profile.)
With the SMTP protocol, the client initiates the connection but it’s the server that sends data first. This means that after the client connection occurs, we need to collect data on the server side of the connection, which is performed here when the SERVER_CONNECTED event fires (lines 6-7).
SERVER_DATA fires when the server sends (and has been collected by the collect in line 7). The if will not match yet as the ehlo variable is still zero with no client data to match. The data is also released here (line 29)
I do however, want to catch when the client sends data, so I do a clientside collect. (line 30)
When the client does send data, the CLIENT_DATA event fires (line 9). The payload is de-cased and stored in the variable lcpayload (line 10) and then is checked for the existence of the ehlo command (line 11).
If the ehlo was present, I collect on the serverside again (looking for TLS support messages) and make sure I set ehlo to true (lines 12-13).
I release client data to continue flow, then collect again to look for the starttls command from the client.
Now on the server side, if ehlo is set and the starttls is not in the message, replace the payload with a starttls message. (line 27)
And again release the data (line 29)
Now when client data arrives with starttls, LTM responds directly informing the client to start TLS communication (lines 16-17) and then swallows the payload (line 18).
After responding to the client, I need to enable SSL to the virtual is ready for the client hello from the client (line 20).
Finally, if there is no ehlo or starttls from the client, I’ll just release the payload. This is to allow clients not supporting starttls through. (line 22)

There is a modified version of this iRule as well contributed by user asharicz in this forum thread that changes a few of the condition statements but doesn’t touch the collect/release logic.

Related Articles

BSidesMO Wrap-up

Tue, 25 Oct 2011 03:41:46 EDT

Last Friday I attended my first BSides event in Missouri’s capitol (literally in the capitol building!) Jefferson City. The BSides community exists to bring fellow security practitioners together to present and participate in a small-scale environment that encourages collaboration. I’m not the outgoing sort and I generally like to fade into the background and just learn, but this environment really lends itself well to establishing relationships with others. There were quite a few St Louis based individuals and the chatter is already taking off for setting up a BSides event closer to home in the Spring. Two tracks were offered at BSidesMO; I chose track 2. A brief review of a few of my favorite talks follows below. Many thanks to Jerry Gamblin (@jgamblin), Randy Raw (@randyraw), & Beth Young (@bethayoung) for putting on a great show.

The Evolution of Malware – Chris Quinn

I don’t spend any time studying malware, but I spend quite a bit of time cleaning it up. This talk was pretty eye opening on several levels. The increase of viruses (250k in 2007 –> 286M in 2010) is a shocking display of slope. The growth is primarily attributed to the mutating nature of most of the new viruses, targeting only a few dozen before mutating again. That narrowing of focus in targeting victims kind of reminds me of the scene in Jurassic Park where one of the raptors lays as bait while the other hides in the bushes ready to pounce: Clever Girl! The real payoff of the talk, however, was the discussion on Stuxnet. Some high level details on design:

Used seven distinct mechanisms to spread, six of which leveraged 0-day vulnerabilities)
Comprised of 15 modules
Five mechanisms to conceal itself
reprograms industrial PLCs w/ 10k lines of code (10k!)
rootkits for windows PC and the PLC
used two stolen certificates to sign its files making them look legitimate

For systems infected without the appropriate configuration, the virus did nothing. Otherwise, it would collect telemetry data for days and then replay to monitoring systems while then controlling the PLCs at will. Amazing stuff. Bruce Schneier has a nice summary of the knowns/unknowns (at time of writing), and you can read Symantec’s comprehensive dossier on the subject as well.

Make the World Go Away – Beth Young

Beth’s talk focuses on reducing your threat landscape. She discussed inbound reduction techniques like blocking ip ranges from areas of the world that would have no business accessing a particular resource. This was interesting as the legwork required to build this yourself and implement on the firewalls is fairly cumbersome, but worthwhile. F5 customers can tap the built-in Quova geo-location services in BIG-IP LTM to stop requests at the door using the iRules whereis command, performing the same function in minutes what probably took Beth and her team a considerably longer time to achieve. The most interesting part of the talk concerned protecting internal users and in turn the organization by poisoning the DNS for known bad domains. This is done either by routing said requests to a bit bucket (IP based) or redirecting the requests to an alternative web-server for stats collection and remediation (name based). Both are intriguing, and I expect I’ll write this solution up utilizing F5 gear in the next few weeks.

Web Exploitation Trends – Larry Battle

Larry had some great information, a lot of which was similar to Chris Quinn’s, so I won’t rehash that. The social engineering discussion was engaging, however. I don’t recall the place (Surprise Valley, Sunrise Valley?) but Larry described a place in Idaho that had an entire real-estate website for people wanting to relocate there, only the place didn’t even exist. The entire site was a scam, and when you clicked on the videos, a flash “upgrade” would be presented, at which time it appeared flash was updating (with real-looking flash screens) but actually malware was being downloaded instead. The craftiness of these criminals is amazing. The other uncool but fascinating part was the “You have a virus, pay $25 and we’ll clean it” scam. I always go straight to task manager and kill the processes as soon as these pop-up, but I wasn’t aware that they aren’t malware in the sense that they do damage to your system. It’s really just a scare tactic to get you to spend $25. The whole thing is a ruse, and does nothing to infect or clean your system. Fascinating stuff.

Related Articles

Technorati Tags: F5 Devcentral,BSides,BSidesMO,Chris Quinn,Beth Young,Larry Battle,Jerry Gamblin,Randy Raw,Jason Rahm,malware,security

v11: RDP Access via BIG-IP APM–Part 3

Tue, 04 Oct 2011 05:24:41 EDT

In Part 1, I configured a full Webtop in APM with a static RDP host. In Part 2 ,I modified that configuration to allow users to specify their RDP destination. In this article, I’ll make a couple changes to the final configuration in Part 2 to have the last hostname “remembered” across sessions.

Add an iRule Event

Yes! Finally an iRule in this series. In order for an iRule to be triggered, however, I need to add an iRule event to the policy. Why do I need an iRule? Well, in order to recall the previous session’s hostname, I need to store it somewhere. In this case, I’ll be using the BIG-IP session table, accessing it with the table command. I’ll add the iRule event immediately before the RDP Hostname page so the previous hostname can be displayed there if applicable. I gave the event an ID of 1.

The iRule itself is pretty simple. Set the user to a variable, which becomes the table key for the user’s rdp host destination. If it’s there, it’ll be pre-populated, otherwise, it won’t. In the completed event, it’s much the same except the hostname is stored instead of being looked up.

when ACCESS_POLICY_AGENT_EVENT {
  # This event runs immediately before the RDP Hostname logon page
  # Grab username entered on the logon page
  set user [ACCESS::session data get session.logon.last.username]
  # Look up in session table to see if a hostname is already saved for a user
  set hostname [table lookup $user]
  # Pre-fill the hostname session variable (to be shown on the RDP hostname entry page)
  ACCESS::session data set session.logon.last.hostname $hostname
}
when ACCESS_POLICY_COMPLETED {
  # This event runs after the RDP hostname entry page
  # Grab username entered on the logon page
  set user [ACCESS::session data get session.logon.last.username]
  # Grab hostname entered on the RDP hostname entry page
  set hostname [ACCESS::session data get session.logon.last.hostname]
  # Save this in the session table (does not time out)
  table set $user $hostname "indefinite"
}

Once the iRule is saved to the system, it should be applied to the rdp virtual as shown in Figure 2.

Customize RDP Hostname

Before the auto-population will work, I need to comment out a few lines in the logon.inc file for the RDP Hostname logon page to make sure the field is always auto-populated (even with an empty string). To get to the file, I click the Access Policy tab in the menu and then Customization and then expand out Customization Settings->/Common/rdptest->Access Policy->RDP Hostname. Click on Views at the top and select Advanced. Click logon.inc under RDP Hostname and then comment out the lines selected in Figure 3.

After clicking Save Draft then Save, I navigate to Access Policy->Access Profiles and click Apply Access Policy to update the changes.

Testing the Changes

Now that the policy is applied, I can login and see that the field on first attempt is empty.

On the second time through, I see that the hostname I selected is pre-populated as expected.

I added a log statement to each of the iRule events to track the table key/value pair. For first time through, notice the host is empty on the ACCESS_POLICY_AGENT_EVENT, but is populated by the time the policy completes:

Oct 4 11:18:03 tmm info tmm[19079]: Rule /Common/rdptest_autopopulate <ACCESS_POLICY_AGENT_EVENT>: User=dc.user, Host=
Oct 4 11:18:12 tmm info tmm[19079]: Rule /Common/rdptest_autopopulate <ACCESS_POLICY_COMPLETED>: User=dc.user, Host=ad01.devcentral.test.local

Conclusion

All three parts of this series explored the Webtop functionality and different ways to customize the approach for user access to Windows resources secured by BIG-IP Access Policy Manager. Many thanks to James Goodwin and the APM team for great source material and continued development of excellent access solutions.

Related Articles

v11: RDP Access via BIG-IP APM–Part 2

Thu, 15 Sep 2011 06:00:00 EDT

In the first article in this series, I configured a full Webtop in APM with a static RDP host. In this article, I’ll make some changes to the original configuration to allow users to specify an RDP host destination.

Modify the Access Policy

Immediately after the active directory authentication on the successful branch, click the “+” and add a logon page.

In the logon page configuration, change the name (optional) to RDP Hostname, set the field 1 post variable and session variable names to hostname, change the type for field two to none, then add some explanatory text to the Form Header Text field and specify Hostname in the text box for field 1. I also changed the Logon Button text to Continue instead of Logon since the logon has already occurred.

Click save. Now the policy should look like the image in Figure 3.

Modify the RDP Resource

After closing the policy editor, I open the Remote Desktop (Access Policy->Application Access->Remote Desktops->Remote Desktops) and change the destination from the static resource I assigned in part 1 to the variable I created in the policy: %{session.logon.last.hostname}

Optional Customization

To provide a description on the button that includes the user configured RDP host name, go to Access Policy->Customization and select the configured Remote Desktop, select the Localization tab in the menu and configure the Caption and Detailed Descriptions. Use the same session variable from above in the description field.

Make sure the caption is configured for each of the languages you support. I only changed the English one in this example. Next, apply the policy.

Testing the Changes

Now that my changes are complete, I can test them. Same initial login screen as part 1:

Now I’m presented with the second logon page, this time asking for the host I'd like to connect to:

Note the continue I modified in the policy instead of it being labeled Logon. Now, My Webtop shows the Caption (RDP Connection) and the Description (ad01.devcen…) that I defined in the customizations in the policy.

Finally, clicking on the button takes me to my desired resource:

Conclusion

This solution extended the functionality in part 1 to allow for dynamic configuration of the RDP host destination for user access. In part 3, I’ll explore an iRules option for providing session history as part of the solution.

v11: RDP Access via BIG-IP APM–Part 1

Mon, 12 Sep 2011 15:00:00 EDT

I wrote an article several months back on auto-launching Remote Desktop sessions with APM. With the introduction of BIG-IP APM v11, there is a new built-in capability to support a full webtop. This means that server, desktop, or other resources can be placed on the webtop for users to select once logging in. In this first example, I’ll set up a static internal resource for users to connect to after logging in.

Create the Webtop

After logging in to the BIG-IP, open up the Access Policy tab and select Webtops->Webtop List and then click Create (or you can hit the “+” circled to the right of the Webtop List.) Give the Webtop a meaningful name and the type needs to be Full as show in Figure 1.

Create the RDP Resource

Still in the Access Policy tab, click Application Access->Remote Desktops->Remote Desktops and then click Create. There are a number of fields here, but for this example the only ones that need to be set are the Type (RDP), the Destination (Server or Desktop hostname or IP), and Auto Logon (Enable). When Auto Logon is selected, the username, password, and domain source variable fields are shown. I accepted the defaults.

Create the Access Policy

Now that the two custom objects for the RDP Webtop are created, I’ll create the access policy (and virtuals) with the Network Access Setup Wizard for Remote Access under the Wizards tab. I create all my access policies this way, the wizard is very thorough and eliminates my tendency to overlook an object or misconfigure one, not to mention the time savings. In the first screen, I disabled AV checks (though in production I wouldn’t recommend this) as shown in Figure 3 below.

Next I create a new authentication resource (you can select existing if this is not a new installation), utilizing my test active directory server.

Next I configure the lease pool. It’s just me in my test lab, so I only create a single client address, but you’ll likely need to choose the IP address range.

The next step is for network access configuration. Corporate policies will dictate whether all traffic is forced through the tunnel or if split-tunneling is appropriate. For this example, I stuck with forcing all traffic through the tunnel to minimize the necessary configuration to show the features.

I only have one name server, my ad01 directory server, so I enter that and leave the rest blank.

Next I’ll enter the VIP address and leave the http->https redirect virtual enabled.

At this point, I review the configuration and click next. If there are any errors, you can return to previous steps in the wizard and make corrections. Before clicking Finished in the next screen, I need to edit the access policy.

Once in the policy editor, click on the Logon Page object and set Field 3 from none to text and use domain as the post and session variable name. Then below in the Logon Page Input Field #3 text box, enter Domain.

Next, click on the Resource Assign object and then click Add/Delete in the expression. I need to replace the webtop the network access wizard created and I need to select the RDP Resource I created.

Close out the policy and then click Finished in the Setup Summary screen. For my configuration I need to snat the traffic, so I enabled snat-automap on the virtual created by the wizard. Because I made changes to the policy, I need to re-apply it, so in the Access Policy tab I clicked on Access Profiles and then selected my profile and clicked Apply Access Policy.

That completes the configuration steps. Now it’s time to test.

Testing the Configuration

First I open a browser and navigate to my vip, https://10.10.20.30.

After login, my RDP resource is shown on my Webtop, along with my network access.

After clicking the rdptest icon, I am logged in automatically to my server.

It seems like a lot of steps, but I configured this in less than five minutes, which is far more efficient and far less error-prone than the previous solution. The video below shares the same steps covered here in screen captures.

BIG-IP APM RDP Webtop

Conclusion

This solution introduces a full Webtop environment for BIG-IP APM in version 11, which I took advantage of for statically configuring RDP resources for clients. In part 2, I’ll introduce a dynamic option for the RDP resource.

Create a User Lockout Policy with Access Policy Manager

Fri, 26 Aug 2011 03:08:00 EDT

This article will cover a simple access policy that when completed will lock out a user using BIG-IP Access Policy Manager. Start by making an access policy with the Device Wizard. Since I just want to make a quick and easy example, I’ll be using the fourth radio option, Web Application Access Management for Local Traffic Virtual Servers.

Create a virtual server via the wizard or use an existing virtual server if you already have a HTTPS virtual server. I called my Policy “Lockout” and I disabled the Antivirus Check just because I don’t want to crowd my access policy.

I chose Active Directory as my authentication factor but feel free to use what you like. Next, create a virtual server if you don’t already have one. I have one already but if didn’t, I would do the following.

Review the configuration and before finishing the wizard, click on Edit Access Policy in Visual Policy Editor.

Your access policy should look like the following. First change the Max Logon Attempts Allowed to one.

Next, I just added a Lockout macro (I need to be more creative with the naming scheme). Our macro will only consist of one block but for the sake of encapsulation, I made it into a macro in case in the future we want to add something else to it.

In the macro, create a new iRule Event with ID “lookup user” and with the following branch rules.

Name Expression

Lockout user expr { [mcget {session.custom.badpwdcount}] >= [mcget {session.custom.lockout}] }

Can allow through expr { [mcget {session.custom.badpwdcount}] < [mcget {session.custom.lockout}] }

Now add some more appropriate terminals to our macro since the default “Out” is not very descriptive.

Great, now just add the macro between the Logon Page and the AD Auth. The AD Auth is most likely on the Lockout branch but we can easily move it to the correct, Allow Through, branch by clicking on the little down arrow on the AD Auth block.

Now that everything is in place, we should edit the endings of the access policy so that it would make more sense. Right now we only have Allow and Deny but we should add something like a Lockout with more information for the user. Don’t forget to attach the lockout ending to the lockout branch (use a different name if you want).

Error Title	Error Message
You’ve been locked out, %{session.logon.last.username}	Please try again in %{session.custom.timeout} minutes.

In the Error title, I added a session variable that personalizes the lockout. Also, I added a custom session variable I added in iRules that lets the users know how much more they have to wait to try again. Apply the access policy and finish the device wizard. The final step is to attach the iRule below.

when ACCESS_POLICY_AGENT_EVENT {

  set user [ACCESS::session data get session.logon.last.username]

  if {[ACCESS::policy agent_id] eq "lookup user"} {

    # The lockout and timeout variables are customizable here.

    # The lockout variable determines how many times a user may try

    # before getting locked out. The timeout variable determines how

    # long a user has to wait until they can come out of their lockout.

    set lockout 5

    set timeout 900

    # We do not want to touch (reset the timer) the user unless we know

    # for sure that this user’s bad password count has not exceeded the

    # lockout number.

    set badpwd [table lookup -notouch $user]

    if {$badpwd == {}} {

      table add $user 0 $timeout

    } elseif {$badpwd < $lockout} {

      table lookup $user

    ACCESS::session data set session.custom.badpwdcount $badpwd

    ACCESS::session data set session.custom.lockout $lockout

    ACCESS::session data set session.custom.timeout [expr {]table timeout -remaining $user[ / 60}]

# When the policy completed we want to check the authentication results.

# If the user failed, we want to increment their bad password count. If

# they have succeeded logon, we want to remove them from the session table.

when ACCESS_POLICY_COMPLETED {

  set user [ACCESS::session data get session.logon.last.username]

  set result [ACCESS::session data get session.ad.last.authresult]

  # If we never went to authentication, the auth result would be null

  # and we don’t want to do anything in that case.

  if {$result == ""} {

    return

  } elseif {$result} {

    table delete $user

  } else {

    table incr $user

A failed login should result in this screen:

Thanks again to ystephie for another great solution!

About the Author

Stephanie is a summer intern at F5, heading back to school soon to continue her EECS degree at UC Berkeley, and has been having a blast creating interesting solutions for BIG-IP. Stephanie’s passion for engineering, and smile, is contagious.

Related Articles

Preventing Brute Force Password Guessing Attacks with APM–Part 4

Fri, 19 Aug 2011 05:36:00 EDT

F5er and DevCentral community member ystephie is back with another great solution (check out her first solution here: BIG-IP APM Customized Logon Page), this time tackling brute force attacks utilizing customizations with the BIG-IP Access Policy Manager. This solution requires BIG-IP 10.2.2 Hotfix 1 or later.

Introduction

In our second example (Part 2), we modified our configuration to only display the CAPTCHA challenge if a user has previously failed authentication (by checking the user’s badPwdCount attribute from Active Directory).

In our third example (Part 3), we kept track of authentication failures ourselves on box (through use of an iRules Session Table). This removed the dependency on Active Directory and solved the issue around tracking failures for invalid users (providing the same external behavior, whether a user is valid or invalid).

In this final example, we’ll modify our policy to also temporarily lock out users from attempting login to APM after failing authentication too many times. This can further protect against both automated and manual credentials guessing attacks, and also prevent intentional or unintentional internal account lockout (for example, an Active Directory domain lockout from too many failures).

Locking Out Users After Failed Logon Attempts

Our previous example allowed the user to try authentication combined with the CAPTCHA challenge as many times as they liked, but that opens the possibility of an attacker locking a legitimate user’s account within an internal domain authentication server (e.g. Active Directory). Also allows for the possibility of a manual password guessing attack (by those really good at entering CAPTCHA challenges!). To prevent these possibilities, we can set a lockout variable in our example iRules and set the reset timer to the time we’d like to temporarily lock out a user (after a defined number of authentication failures). As with Part 3, we use iRules to create a Session Table that keeps track of all the usernames and number of failed authentication attempts for each user. Before we begin, please start with the access policy we created in Part 3.

Policy Additions

To incorporate lockout functionality, we simply need to add some branch rules and edit a bit of the iRule. The changes are described in each section below. The overall access policy isn’t changing much. The only modifications I’ve made are in the branch rules and some of the endings.

The places we need to change are where a user’s information is first accessed or updated. This happens in more than five places. But, luckily with our use of macros, we only need to add branch rules in three places.

Macro: AD Auth & iRule

Since the Empty block (compares badpwdcount with maxtries) in the AD Auth and iRule macro checks the updated badpwdcount of the user against our CAPTCHA challenge variable (maxtries), this is a place we also want to check the badpwdcount against the lockout variable. Please see the modified iRule below (updates in red). We will add a new rule branch that compares the bad password count with a preset variable, lockout. Lockout is defined in the iRule and it is very easy to customize how many authentication failures should be allowed before temporarily locking them out.

when ACCESS_POLICY_AGENT_EVENT {

    # Maxtries is a variable that sets how many times you want the regular logon page to show before showing the captcha.

    # Timeout is a variable that sets how long a user entry will persist in the session table. Lockout is a variable that sets how

    # many tries a user gets before getting locked out. This is the only place you need to change these variables.

    set maxtries 2

    set timeout 900

    set lockout 5

    set user [ACCESS::session data get session.logon.last.username]

    ACCESS::session data set session.custom.maxtries $maxtries

    ACCESS::session data set session.custom.lockout $lockout

    if {[ACCESS::policy agent_id] eq "set session vars"} {

        ACCESS::session data set session.custom.badpwdcount [table lookup -notouch $user]

    if {[ACCESS::policy agent_id] eq "session lookups"} {

        set badpwd [table lookup $user]

        if {$badpwd == {}} {

            set badpwd [table add $user 0 $timeout]

        ACCESS::session data set session.custom.badpwdcount $badpwd

        # log local0. "$user has this number of incorrect logons(lookups): $badpwd"

    if {[ACCESS::policy agent_id] eq "badpwd"} {

        table incr $user

    if {[ACCESS::policy agent_id] eq "goodpwd"} {

        table delete $user

Branch Rule #1:

Name:	Expression:
Lockout	expr { [mcget {session.custom.badpwdcount}] >= [mcget {session.custom.lockout}]}

Add an additional Terminal called “Lockout.” Change the ending of the branch we created to “Lockout.” This way, we can differentiate this from all the other endings.

Macro: Captcha Auth with AD Auth

After the Captcha Logon Page, add a new iRule Event with ID “set session vars” with Branch Rule # 1 and Branch Rule # 2. Repeat the above process to add the lockout ending.

Branch Rule #1:

Name:	Expression:
Lockout	expr { [mcget {session.custom.badpwdcount}] >= [mcget {session.custom.lockout}]}

Branch Rule #2:

Name:	Expression:
Allow user to continue	expr { [mcget {session.custom.badpwdcount}] < [mcget {session.custom.lockout}]}

The reason we’re not using session lookups as the event ID is because that in session lookups, we want to “touch” the user - reset the timeout back to the max value defined as timeout. With our new set session vars event ID, we will add an optional flag (-notouch) that tells the table not to reset the user’s timer. Without the -notouch flag for this event, even if our user is patiently waiting for the 15 minute (in our example) lockout timeout to expire, but tries to connect again before the timer expires, the timer gets reset and the user would have to wait for ANOTHER 15 minutes.

when ACCESS_POLICY_AGENT_EVENT {

    # Maxtries is a variable that sets how many times you want the regular logon page

    # to show before showing the captcha. Timeout is a variable that sets how long a

    # user entry will persist in the session table. Lockout is a variable that sets

    # how many tries a user gets before getting locked out. This is the only place

    # you need to change these variables.

    set maxtries 2

    set timeout 900

    set lockout 5

    set user [ACCESS::session data get session.logon.last.username]

    ACCESS::session data set session.custom.maxtries $maxtries

    ACCESS::session data set session.custom.lockout $lockout

    if {[ACCESS::policy agent_id] eq "set session vars"} {

        ACCESS::session data set session.custom.badpwdcount [table lookup -notouch $user]

…

Macro: Verify with Captcha Page

Add the lockout ending and attach it to the Lockout branch of AD Auth and iRule.

Macro: iRule Lookups and Auth

Add an iRule Event with ID, set session vars, right after “In” with Branch Rule # 1 and Branch Rule # 2, Lockout and Allow user to continue. Don’t forget to update the endings to lockout.

Branch Rule #1:

Name:	Expression:
Lockout	expr { [mcget {session.custom.badpwdcount}] >= [mcget {session.custom.lockout}]}

Branch Rule #2:

Name:	Expression:
Allow user to continue	expr { [mcget {session.custom.badpwdcount}] < [mcget {session.custom.lockout}]}

Access Policy: CaptchaProj_4

The last thing you need to do is edit/customize the default Deny ending (or add your own) to let the users know that they’ve been locked out and attach the ending to the branches labeled lockout.

An example of this page:

The Final iRule

when ACCESS_POLICY_AGENT_EVENT {

    # Maxtries is a variable that sets how many times you want

    # the regular logon page to show before showing the captcha.

    # Timeout is a variable that sets how long a user entry will

    # persist in the session table. Lockout is a variable that sets

    # how many tries a user gets before getting locked out. This is

    # the only place you need to change these variables.

    set maxtries 2

    set timeout 900

    set lockout 5

    set user [ACCESS::session data get session.logon.last.username]

    ACCESS::session data set session.custom.maxtries $maxtries

    ACCESS::session data set session.custom.lockout $lockout

    if {[ACCESS::policy agent_id] eq "set session vars"} {

        ACCESS::session data set session.custom.badpwdcount [table lookup -notouch $user]

    if {[ACCESS::policy agent_id] eq "session lookups"} {

        set badpwd [table lookup $user]

        if {$badpwd == {}} {

            set badpwd [table add $user 0 $timeout]

        ACCESS::session data set session.custom.badpwdcount $badpwd

        # log local0. "$user has this number of incorrect logons(lookups): $badpwd"

    if {[ACCESS::policy agent_id] eq "badpwd"} {

        table incr $user

    if {[ACCESS::policy agent_id] eq "goodpwd"} {

        table delete $user

Final Notes

This solution builds on everything we learned in Parts 1-3. Exposing applications or services to the Internet opens inherent security risks. APM can help by providing advanced authentication, authorization, and endpoint security checks. With a bit of customization, iRules, and creative access policies, you can provide additional security layers beyond those built as standard features in APM. This was our final solution in this series. I hope you’ve enjoyed playing with BIG-IP Access Policy Manager and now feel comfortable creating your own new and innovative solutions. Best of luck!

About the Author

Scheduling BIG-IP Configuration Backups via the GUI with an iApp

Tue, 16 Aug 2011 10:45:43 EDT

Beginning with BIG-IP version 11, the idea of templates has not only changed in amazing and powerful ways, it has been extended to be far more than just templates. The replacement for templates is called iApp^TM. But to call the iApp^TM just a template would be woefully inaccurate and narrow. It does templates well, and takes the concept further by allowing you to re-enter a templated application and make changes. Previously, deploying an application via a template was sort of like the Ron Popeil rotisserie: “Set it, and forget it!” Once it was executed, the template process was over, it was up to you to track and potentially clean up all those objects. Now, the application service you create based on an iApp^TM template effectively “owns” all the objects it created, so any change to the deployment adds/changes/deletes objects as necessary. The other exciting change from the template perspective is the idea of strictness. Once an application service is configured, any object created that is owned by that service cannot be changed outside of the service itself. This means that if you want to add a pool member, it must be done within the application service, not within the pool. You can turn this off, but what a powerful protection of your services!

The Problem

I received a request from one of our MVPs that he’d really like to be able to allow his users to schedule configuration backups without dropping to the command line. Knowing that the iApp^TM feature was releasing soon with version 11, I started to see how I might be able to coax a command line configuration from the GUI. In training, I was told that “anything you can do in tmsh, you can do with an iApp^TM.” This is excellent, and the basis for why I think they are going to be incredibly popular for not only controlling and managing applications, but also for extending CLI functions to the GUI. Anyway, so in order to schedule a configuration backup, I need:

A backup script
A cron job to call said script

That’s really all there is to it.

The Solution

Thankfully, the background work is already done courtesy of a config backup codeshare entry by community user Colin Stubbs in the Advanced Design & Config Wiki. I did have to update the following bigpipe lines from the script:

bigpipe export oneline “${SCF_FILE}” to tmsh save /sys config one-line file “${SCF_FILE}”

bigpipe export “${SCF_FILE}” to tmsh save /sys config file "${SCF_FILE}"

bigpipe config save “${UCS_FILE}” passphrase “${UCS_PASSPHRASE}” to tmsh save /sys ucs "${UCS_FILE}" passphrase "${UCS_PASSPHRASE}"

bigpipe config save “${UCS_FILE}” to tmsh save /sys ucs "${UCS_FILE}"

Also, I created (according the script comments from the codeshare entry) a /var/local/bin directory to place the script and a /var/local/backups directory for the script to dump the backup files in. These are optional and can be changed as necessary in your deployment, you’ll just need to update the script to reflect your file system preferences. Now that I have everything I need to support a backup, I can move on to the iApp^TM template configuration.

iApp^TM Components

A template consists of three parts: implementation, presentation, and help. You can create an empty template, or just start with presentation or help if you like.

The implementation is tmsh script language, based on the Tcl language so loved by all of us iRulers. Please reference the tmsh wiki for the available tmsh extensions to the Tcl language.
The presentation is written with the Application Presentation Language, or APL, which is new and custom-built for templates. It is defined on the APL page in the iApp^TM wiki.
The help is written in HTML, and is used to guide users in the use of the template.

I’ll focus on the presentation first, and then the implementation. I’ll forego the help section in this article.

Presentation

The reason I’m starting with the presentation section of the template is that the implementation section’s Tcl variables reflect the presentation methods naming conventions. I want to accomplish a few things in the template presentation:

Ask users for the frequency of backups (daily, weekly, monthly)
If weekly, ask for the day of the week
If monthly, ask for the day of the month and provide a warning about days 29-31
For all frequencies, ask for the hour and minute the backup should occur

The APL code for this looks like this:

section time_select {

  choice day_select display "large" { "Daily", "Weekly", "Monthly" }

  optional ( day_select == "Weekly" ) {

    choice dow_select display "medium" { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" }

  optional ( day_select == "Monthly" ) {

    message dom_warning "The day of the month should be the 1st-28th.  Selecting the 29th-31st will result in missed backups on some months."

    choice dom_select display "medium" tcl {

      for { set x 1 } { $x < 32 } { incr x } {

        append dom "$x\n"

      return $dom

  choice hr_select display "medium" tcl {

    for { set x 0 } { $x < 24 } { incr x} {

      append hrs "$x\n"

    return $hrs

  choice min_select display "medium" tcl {

    for { set x 0 } { $x < 60 } { incr x } {

      append mins "$x\n"

    return $mins

text {

  time_select "Backup Schedule"

  time_select.day_select "Choose the frequency the backup should occur:"

  time_select.dow_select "Choose the day of the week the backup should occur:"

  time_select.dom_warning "WARNING: "

  time_select.dom_select "Choose the day of the month the backup should occur:"

  time_select.hr_select "Choose the hour the backup should occur:"

  time_select.min_select "Choose the minute the backup should occur:"

A few things to point out. First, the sections (which can’t be nested) provide a way to set apart functional differences in your form. I only needed one here, but it’s very useful if I were to build on and add options for selecting a UCS or SCF format, or specifying a mail address for the backups to be mailed to. Second, order matters. The objects will be displayed in the template as you define them. Third, the optional command allows me to hide questions that wouldn’t make sense given previous answers. If you dig into some of the canned templates shipping with v11, you’ll also see another use case for the optional command. Fourth, you can use Tcl commands to populate fields for you. This can be generated data like I did above, or you can loop through configuration objects to present in the template as well. Finally, the text section is where you define the language you want to appear with each of your objects. The nomenclature here is section.variable. To give you an idea what this looks like, here is a screenshot of a monthly backup configuration:

Once my template (f5.archiving) is saved, I can configure it in the Application Services section by selecting the template. At this point, I have a functioning presentation, but with no implementation, it’s effectively useless.

Implementation

Now that the presentation is complete, I can move on to an implementation. I need to do a couple things in the implementation:

Grab the data entered into the application service
Convert the day of week information from long name to the appropriate 0-6 (or 1-7) number for cron
Use that data to build a cron file (statically assigned at this point to /etc/cron.d/f5backups)

Here is the implementation section:

array set dow_map {
Sunday 0
Monday 1
Tuesday 2
Wednesday 3
Thursday 4
Friday 5
Saturday 6
}

set hr $::time_select__hr_select
set min $::time_select__min_select

set infile [open "/etc/cron.d/f5backups" "w" "0755"]

puts $infile "SHELL=\/bin\/bash"
puts $infile "PATH=\/sbin:\/bin:\/usr\/sbin:\/usr\/bin"
puts $infile "#MAILTO=user@somewhere"
puts $infile "HOME=\/var\/tmp\/"
if { $::time_select__day_select == "Daily" } {
puts $infile "$min $hr * * * root \/bin\/bash \/var\/local\/bin\/f5backup.sh 1>\/var\/tmp\/f5backup.log 2>\&1"
} elseif { $::time_select__day_select == "Weekly" } {
puts $infile "$min $hr * * $dow_map($::time_select__dow_select) root \/bin\/bash \/var\/local\/bin\/f5backup.sh 1>\/var\/tmp\/f5backup.log 2>\&1"
} elseif { $::time_select__day_select == "Monthly" } {
puts $infile "$min $hr $::time_select__dom_select * * root \/bin\/bash \/var\/local\/bin\/f5backup.sh 1>\/var\/tmp\/f5backup.log 2>\&1"
}

close $infile

A few notes:

The dow_map array is to convert the selected day (ie, Saturday) to a number for cron (6).
The variables in the implementation section reference the data supplied from the presentation like so:

$::<section>__<presentation variable name> (Note the double underscore between them. As such, DO NOT use double underscores in your presentation variables)

tmsh special characters need to be escaped if you’re using them for strings.

A succesful configuration of the application service results in this file configuration for /etc/cron.d/f5backups:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
#MAILTO=user@somewhere
HOME=/var/tmp/
54 15 * * * root /bin/bash /var/local/bin/f5backup.sh 1>/var/tmp/f5backup.log 2>&1

So this backup is scheduled to run daily at 15:54. This is confirmed with this directory listing on my BIG-IP:

[root@golgotha:Active] bin # ls -las /var/local/backups
total 2168
8 drwx------ 2 root root 4096 Aug 16 15:54 .
8 drwxr-xr-x 9 root root 4096 Aug 3 14:44 ..
1076 -rw-r--r-- 1 root root 1091639 Aug 15 15:54 f5backup-golgotha.test.local-20110815155401.tar.bz2
1076 -rw-r--r-- 1 root root 1092259 Aug 16 15:54 f5backup-golgotha.test.local-20110816155401.tar.bz2

Conclusion

This is just scratching the surface of what can be done with the new iApp^TM feature in v11. I didn’t even cover the ability to use presentation and implementation libraries, but that will be covered in due time. If you’re impatient, there are already several examples (including this one here) in the codeshare.

Related Articles

Preventing Brute Force Password Guessing Attacks with APM–Part 3

Thu, 11 Aug 2011 00:00:00 EDT

Introduction

In this third example, we’ll build on the previous example but keep track of authentication failures ourselves on box (through use of an iRules Session Table). This will remove the dependency on Active Directory and solves the issue around tracking failures for invalid users (providing the same external behavior, whether a user is valid or invalid).

Replacing the AD Query with an iRules Session Table

As we explained in the previous example, we’d rather not inconvenience users by forcing a CAPTCHA challenge on them unless we start seeing authentication failures. Using iRules, we can create a Session Table that keeps track of all the usernames and number of failed authentication attempts for each user. Since we’re tracking all authentication failures (for both valid and invalid users), we can increase the number of failures before showing the CAPTCHA challenge without giving a hacker any hint about who might be a valid user (opening for a username guessing attack). With the Active Directory badPwdCount technique, we could only track failures for valid AD users. With the Session Table iRules approach, you can set policies around how long before resetting a user’s bad authentication count, as well as how many authentication failures to allow before forcing a CAPTCHA challenge. Here’s a bit more on the iRules Table command:

Table Command Article Series

Table Command Wiki Entry

Some pretty powerful stuff here, and a good place to track other bits of information across APM user sessions. For example, this example could be extended to track and compare geo IP location data across user sessions to detect suspicious activity. (See APM Access Policy Geolocation for an example where we look up a user’s geolocation information via iRules.) In this example, we’ll be using a combined logon page with both username/password and CAPTCHA challenge as in Part 1. Before we begin, please create a new access policy, set up an HTTP Auth Agent as described in Part 1, as well as an authentication server (e.g. Active Directory, RADIUS, LDAP).

Access Policy Overview

The following behavior is what we want to accomplish with our access policy.

1. A user wants to logon for the first time. He’ll see the standard APM logon page.

If the user passes our Active Directory authentication (or your choice of auth factor), the user will be allowed access to the SSL VPN.
If the user fails authentication, we want to first add him to our Session Table and check to see if the user has maxed out his authentication tries (set in the iRule). Please see logic in red below.

when ACCESS_POLICY_AGENT_EVENT {
# Maxtries is a variable that sets how many times you want the regular
    # logon page to show before showing the CAPTCHA. Timeout is a variable
    # that sets how long a user entry will persist in the session table.
    # This is the only place you need to change these variables.
set maxtries 2
set timeout 900
set user [ACCESS::session data get session.logon.last.username]
ACCESS::session data set session.custom.maxtries $maxtries
if {[ACCESS::policy agent_id] eq "session lookups"} {
    set badpwd [table lookup $user]
    if {$badpwd == {}} {
      set badpwd [table add $user 0 $timeout]
    }
    ACCESS::session data set session.custom.badpwdcount $badpwd
    # log local0. "$user has this number of incorrect logons: $badpwd"
}
if {[ACCESS::policy agent_id] eq "badpwd"} {
    table incr $user
}
if {[ACCESS::policy agent_id] eq "goodpwd"} {
    table delete $user
}
}

If we detect that the user maxed out his authentication tries, the next logon page should be one with a CAPTCHA challenge included.

If we detect that the user hasn’t maxed out his authentication tries, the next logon page should be the APM logon page with some helpful text that tells the user that his credentials were incorrect and to try again.

Note: The user will continue to return to this logon page with the error message until they exceed the max tries threshold. Once the user exceeds the threshold, we need to take them to the logon page with the CAPTCHA challenge.

2. A user comes back to the logon page after closing the previous (failed) session. Since this user is already in our Session Table, we can check immediately how many times this user has failed authentication.

If this user hasn’t reached the max authentication tries threshold, we can send him to the error message logon page as usual.

If this user has already reached the max tries threshold, we run into a problem. Should we send them directly to the CAPTCHA challenge page and ignore the credentials they just entered? Or can we just ask them to enter a CAPTCHA challenge without reentering their credentials? In our example, we’re doing the latter.

How can we make it so that the various types of logon pages come one after another seamlessly without creating a very long access policy? A neat trick we can use is APM’s redirect ending. The redirect ending can be used to send a user to any URL. But in our case, we want to direct the access policy to return to the very beginning of the access policy (the “Start” block), without asking the user to click on a link such as in a deny ending.

After clicking Edit Endings in the VPE, add two redirect endings the way I have it above. The URL field should be the virtual server with “/captcha” or “/error” appended to it. Those paths allow us to pass some context about the results of the previous run through the access policy. With each new access policy run, all information about the previous run is forgotten (a new session is created). But, what if I needed to know if the user had already maxed out their authentication failures and needed the CAPTCHA challenge? That’s how these redirects come into play. We can just attach a path to the end of the redirect URL.

Now that we know how to redirect users back to the start of access policy, how do we tell “/captcha” apart from “/error”? Well, with a block called Landing URI, we can change the behavior of a new run through the access policy depending on the results from the previous run. In the branch rules of the Landing URI block have the following expressions under advanced. The Landing URI block looks for the landing uri which is the path we appended in the redirect ending.

Name:	Expression:
Direct to Captcha	expr { [mcget {session.server.landinguri}] == “/captcha” \|\| [mcget {session.server.landinguri}] == “/captcha/” }
Direct to logon page with err msg	expr { [mcget {session.server.landinguri}] == “/error” \|\| [mcget {session.server.landinguri}] == “/error/” }

With this, we can take a different path depending on the information passed from the redirect ending (captcha or error). The following is the access policy where you can see both the initial Landing URI block and final Redirect endings.

Let’s now step through the paths a user may follow, and review the logic in the access policy.

1. The user follows the “fallback” normal path (no previous redirect), enters their credentials, and goes through the iRule lookups and Auth macro. This macro will help us determine if they’re allowed access to the SSL VPN service or web app, sent to the Error Logon Page (via the Redirect to Error ending), or Captcha Logon Page (via the Redirect to Captcha ending).

2. The user fails authentication somewhere in the access policy but not enough times to reach maxtries. In this case, the user gets sent to the Error Logon Page via the Redirect to Error redirect ending. The Error Logon Page block is the regular logon page with a message that informs the user that they have entered incorrect credentials.

To add the error message to the standard logon page, add the following html code to Form Header Text in the VPE:

3. The user either failed authentication somewhere in the access policy and reached maxtries, or failed the CAPTCHA challenge inside the Captcha Auth w AD Auth macro above. In either of these cases, the user gets redirected to CAPTCHA Auth w AD Auth (again with the Redirect to Captcha redirect ending) which has a CAPTCHA challenge page with username/password fields. We will continue to redirect to this page until the user enters correct credentials and CAPTCHA challenge.

Visual Policy Editor Macros

Macros are an important addition in the VPE because it allows us to manage one configuration block and use it in several places within an access policy. This way, we avoid having to change or add blocks that have the same behavior in more than one place within the VPE. Macros are also a great way to maintain a simple to understand top level policy (readability).

There are four macros total in the access policy. You can see Captcha Auth w AD Auth and iRule Lookups and Auth in this top-level access policy. There are two additional macros (AD Auth and iRule and Verify with Captcha) that are used within the first two macros (nested macros). The purpose of the macro AD Auth and iRule is used for authentication and to trigger an iRule for updating our Session Table (for tracking users and authentication failures). On authentication failure, it also compares the bad authentication count with maxtries to determine where to send the user next.

This macro first authenticates the user (please remember to change the Max Logon Attempts Allowed in the AD Auth to 1).

If the user passes authentication, the iRule Event goodpwd (with ID “goodpwd”) triggers an iRule event that removes the user from the Session Table.

when ACCESS_POLICY_AGENT_EVENT {

...

  if {[ACCESS::policy agent_id] eq "goodpwd"} {

    # delete the user, they passed authentication,

    # so we don't need to remember their badpwdcount anymore

    table delete $user

The user is then assigned resources and allowed access (to the SSL VPN service or web application). If the user fails authentication, the iRule Event badpwd (with ID “badpwd”) triggers an iRule event that increments the user’s bad password count by one.

when ACCESS_POLICY_AGENT_EVENT {

…

  if {[ACCESS::policy agent_id] eq "badpwd"} {

    # Increment the badpwdcount,

    # This user just failed authentication.

    table incr $user

…

The Variable Assign block with the following configuration, increments the bad password count within the active executing policy.

Custom Variable:	Custom Expression:
session.custom.badpwdcount	expr { [mcget {session.custom.badpwdcount}]+1}

After the user fails authentication once, we must be sure to compare the badpwdcount (custom session variable name for bad password count) against maxtries (custom session variable name for max tries) so that we can determine whether or not to send them to a logon page with CAPTCHA challenge next or to a regular logon page.

Please note that session.custom.maxtries is a custom APM session variable initialized as part of the iRule. The session.custom.badpwdcount APM session variable is also set as part of the iRule shown later (count pulled from the iRule table).

We accomplish this comparison using an Empty block with the following branch rule.

Name:	Expression:
User may try again	expr { [mcget {session.custom.badpwdcount}] < [mcget {session.custom.maxtries}] }

You may have noticed that the endings shown (Successful, Redirect to Error, and Redirect to Captcha) are different from the default endings. To edit endings, click on Edit Terminals and add/edit the terminals to match the figure below. You can also edit the colors.

The macro, Captcha Auth w AD Auth is there to display the logon page with CAPTCHA challenge and authenticate the CAPTCHA via the HTTP Auth agent. If the user passes the CAPTCHA, we will authenticate them with our regular Active Directory auth agent.

In the access policy, the Landing URI will direct to this macro (Captcha Auth w AD Auth) if it sees that the landing uri contains the string “/captcha”.

Note that the Captcha Auth w AD Auth macro above is almost the same as the policy you created in Part 1 of this series, but includes the AD Auth and iRule macro covered earlier.

The next macro is a slight variation of the macro above. In fact the only difference is that Captcha Logon Page block above has username/password inputs plus the CAPTCHA challenge while Verify Logon Page block below only has the CAPTCHA challenge like we created in Part 2 of this series.

The reason we have the macro below is to avoid asking a user to re-enter their credentials again (if we determine they need to pass the CAPTCHA challenge only after already collecting their username and password).

The last and final macro below helps us decide if we should authenticate the user or send the user to a CAPTCHA challenge.

We start with the iRule Event session lookups block (with ID “session lookups”).

when ACCESS_POLICY_AGENT_EVENT {

    # Maxtries is a variable that sets how many times you want the regular

        # logon page to show before showing the CAPTCHA. Timeout is a variable

        # that sets how long a user entry will persist in the session table.

        # This is the only place you need to change these variables.

        # we set how many tries we want to give a user here

    set maxtries 2

        # we set how long we want to keep a user in the Session Table here

    set timeout 900

        # we retrieve the username information from the session var

    set user [ACCESS::session data get session.logon.last.username]

    # set the session variable maxtries so we can compare it to our badpwdcount

        ACCESS::session data set session.custom.maxtries $maxtries

    if {[ACCESS::policy agent_id] eq "session lookups"} {

      # look up the user, if the user isn’t already in the Session Table, add it.

            set badpwd [table lookup $user]

      if {$badpwd == {}} {

        set badpwd [table add $user 0 $timeout]

            # set the session variable badpwdcount so we can compare it to our maxtries

      ACCESS::session data set session.custom.badpwdcount $badpwd

    # log local0. "$user has this number of incorrect logons: $badpwd"

…

We will trigger an iRule that checks our iRule session table and determines how many badpwdcounts a particular user has. If a user has not been entered into our database, this event adds the user to the table with badpwdcount equal to zero. The iRule block also has several branch rules shown below.

Name:	Expression:
Send users to the CAPTCHA	expr { [mcget {session.custom.badpwdcount}] >= [mcget {session.custom.maxtries}] }
The user may authenticate	expr { [mcget {session.custom.badpwdcount}] < [mcget {session.custom.maxtries}] }

Let’s review the behavior here:

1. The user has failed authentication too many times, we will go down the Send users to the Captcha branch. When we reach the Verify with Captcha Page macro, the user is prompted with a plain CAPTCHA challenge. By only showing the plain CAPTCHA challenge, the user doesn’t have to reenter their credentials. If they pass the CAPTCHA, they are allowed to authenticate against AD. If they fail either the CAPTCHA challenge or AD Auth, they’ll be redirected to the beginning of the access policy.

2. If the user hasn’t failed authentication too many times, we will authenticate them right away using the AD Auth and iRule macro.

Access Policy – Putting it all Together

Now we’re ready to revisit our complete access policy. Please see below.

We were able to accomplish the desired behavior with our access policy with the help of iRule Session Tables, redirect endings, macros and Landing URI functionality. With the combined help of the Landing URI and redirect ending, we make switching between different logon pages seamless. Using Session Tables we were able to track authentication failures for all users, valid or not. The point of tracking all users (whether they exist in Active Directory or not), is to ensure that a hacker can’t see any difference in behavior and guess valid user names. Finally, macros help us simplify our access policy (more readable). The last step is to attach the following iRule to the access policy.

when ACCESS_POLICY_AGENT_EVENT {

    # Maxtries is a variable that sets how many times you want the regular

        # logon page to show before showing the CAPTCHA. Timeout is a variable

        # that sets how long a user entry will persist in the session table.

        # This is the only place you need to change these variables.

    set maxtries 2

    set timeout 900

    set user [ACCESS::session data get session.logon.last.username]

    ACCESS::session data set session.custom.maxtries $maxtries

    if {[ACCESS::policy agent_id] eq "session lookups"} {

        set badpwd [table lookup $user]

        if {$badpwd == {}} {

          set badpwd [table add $user 0 $timeout]

        ACCESS::session data set session.custom.badpwdcount $badpwd

        # log local0. "$user has this number of incorrect logons: $badpwd"

    if {[ACCESS::policy agent_id] eq "badpwd"} {

        table incr $user

    if {[ACCESS::policy agent_id] eq "goodpwd"} {

        table delete $user

Final Notes

This solution is a more complex example where we created an advanced access policy with macros, along with APM iRules events, redirect endings, and iRules plus session table, to track authentication failures across user sessions. In part 4, we’ll make some minor modifications to this policy to also support a temporary lockout of users after failing authentication too many times. This provides a more complete solution for blocking credentials guessing attacks, and can help protect against DOS attacks towards internal AD servers (where it might be possible to lock a user out of the internal corporate Active Directory server via too many authentication failures).

About the Author

iRules 101–#18–Revisiting the TCL Scan Command

Tue, 09 Aug 2011 00:00:00 EDT

I covered the Tcl scan command back in the iRules 101 – #16 – Parsing Strings with the TCL Scan Command, but this example (by Hoolio, who else?) was too good not to share with the community. The request involved parsing a log entry as efficiently as possible. The log entry is as follows:

Aug 05 08:01:13 ethos-re0 (FPC Slot 1, PIC Slot 1) TEST-{ss-nat-2}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 1 (ICMP ECHO REQUEST) application: icmp, xe- 0/0/0.21:10.1.1.1:33639 -> 192.168.22.254, creating forward or watch flow ; source address and identifier translate to 172.16.4.32:1135

The goal is to pull out the origin IP address (10.1.1.1) and the translation IP and port (172.16.4.32, 1135, respectively). This could be done with a lot of lindex/split combinations, but this requirement is what the scan command is made for. Before moving on to the formatting, let’s break this string into chunks that we can match on. We want to parse as few fields as possible, so we can match all the way to the first “/”, then the first “:” to get to the IP address. Then we move along to the first “;”, and further to the next digits, and finally to the last “:”. The strings we’ll build are formatting around are thus:

Aug 05 08:01:13 ethos-re0 (FPC Slot 1, PIC Slot 1) TEST-{ss-nat-2}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 1 (ICMP ECHO REQUEST) application: icmp, xe- 0/
0/0.21:
10.1.1.1:
33639 -> 192.168.22.254, creating forward or watch flow ;
source address and identifier translate to
172.16.4.32:
1135

The only fields we really care about here are 3, 6, & 7. There are options with formatting around fields you don’t want, I’ll show both below.

Option 1 – Set Unnecessary Fields to 0

scan $str {%[^/]%[^:]:%[^:]:%[^;];%[^0-9]%[0-9.]:%[0-9]} 0 0 ip1 0 0 ip2 port

Let’s list these out individually to understand what’s occuring:

%[^/] – store all data in the string to the first occurrence of “/” to <null>
%[^:] – store the remaining data in the string to the first occurence of “:” to <null>
:%[^:] –skip the colon and store the remaining data in the string to the next occurrence of “:” to ip1
:%[^;] – skip the colon and store the remaining data in the string to the next occurrence of “;” to <null>
;%[^0-9] –skip the semi-colon and store the remaining data in the string to the next occurrence of a number to <null>
%[0-9.] –store the remaining data until a non “.” or number to ip2
:%[0-9] – skip the colon and store the remaining numbers in port

In practice, I’ll set those <null> fields to garbage variables so you can see them matches:

% set a "Aug 05 08:01:13 ethos-re0 (FPC Slot 1, PIC Slot 1) TEST-{ss-nat-2}\[FWNAT\]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 1 (ICMP ECHO REQUEST) application: icmp, xe- 0/0/0.21:10.1.1.1:33639 -> 192.168.22.254, creating forward or watch flow ; source address and identifier translate to 172.16.4.32:1135"
Aug 05 08:01:13 ethos-re0 (FPC Slot 1, PIC Slot 1) TEST-{ss-nat-2}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 1 (ICMP ECHO REQUEST) application: icmp, xe- 0/0/0.21:10.1.1.1:33639 -> 192.168.22.254, creating forward or watch flow ; source address and identifier translate to 172.16.4.32:1135
% scan $a {%[^/]%[^:]:%[^:]:%[^;];%[^0-9]%[0-9.]:%[0-9]} g1 g2 ip1 g3 g4 ip2 port
7
% puts $g1
Aug 05 08:01:13 ethos-re0 (FPC Slot 1, PIC Slot 1) TEST-{ss-nat-2}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 1 (ICMP ECHO REQUEST) application: icmp, xe- 0
% puts $g2
/0/0.21
% puts $ip1
10.1.1.1
% puts $g3
33639 -> 192.168.22.254, creating forward or watch flow
% puts $g4
source address and identifier translate to
% puts $ip2
172.16.4.32
% puts $port
1135

Option 2 – Skip Over Unnecessary Fields in the Scan Formatting

The scan formatting allows you to use the "*" to skip data instead of forcing you to use a null variable for fields you don't need. I’ll just re-list the fields, with a slight change in the formatting of the fields we don’t care about:

%*[^/] – skip over all the data in the string to the first occurrence of “/”
%*[^:] – skip over the remaining data in the string to the first occurence of “:”
:%[^:] –skip the colon and store the remaining data in the string to the next occurrence of “:” to ip1
:%*[^;] – skip the colon and skip over the remaining data in the string to the next occurrence of “;”
;%*[^0-9] –skip the semi-colon and skip over the remaining data in the string to the next occurrence of a number
%[0-9.] –store the remaining data until a non “.” or number to ip2
:%[0-9] – skip the colon and store the remaining numbers in port

So the command altogether looks like this:

scan $a {%*[^/]%*[^:]:%[^:]:%*[^;];%*[^0-9]%[0-9.]:%[0-9]} ip1 ip2 port

And in practice:

% scan $a {%*[^/]%*[^:]:%[^:]:%*[^;];%*[^0-9]%[0-9.]:%[0-9]} ip1 ip2 port
3
% puts $ip1
10.1.1.1
% puts $ip2
172.16.4.32
% puts $port
1135

I was curious if there is a performance difference between the two approaches, so I put each scan command in a proc and timed it over one million iterations:

% proc test1 {arg} {
scan $arg {%[^/]%[^:]:%[^:]:%[^;];%[^0-9]%[0-9.]:%[0-9]} 0 0 ip1 0 0 ip2 port
}
% proc test2 {arg} {
scan $arg {%*[^/]%*[^:]:%[^:]:%*[^;];%*[^0-9]%[0-9.]:%[0-9]} ip1 ip2 port
}
% time {test1 $a} 1000000
8.183545 microseconds per iteration
% time {test2 $a} 1000000
7.20703 microseconds per iteration

Both are pretty lean and mean, but skipping the data rather then “storing” to null is slightly more efficient.

Caveats

The scan command is amazing, but it is rigid in that if EVERY log entry isn’t formatted exactly the same, then this won’t work 100% of the time. This is the case here:

Aug 05 08:02:25 ethos-re0 (FPC Slot 1, PIC Slot 1) {sset2}\[FWNAT\]: ASP_SFW_DELETE_FLOW: proto 6 (TCP) application: any, (null)(null)10.1.1.1:8956 –> 192.168.22.254:80, deleting forward or watch flow ; source address and port translate to 172.16.4.32:1128

Notice that our first match from the scan command above is nowhere to be found! Not good. There is hope, however. If you know all the possible formats and can find a unique identifier among them, you could switch on the unique identifier and then have a custom scan format for each as necessary.

The Challenge

I have a DevCentral t-shirt (message in image below) for the first non-F5er to provide the scan syntax to pull out the highlighted fields in the string provided in the Caveats section. Happy coding!

Related Articles

Preventing Brute Force Password Guessing Attacks with APM–Part 2

Fri, 05 Aug 2011 09:15:00 EDT

Introduction

In our first example (Part 1), we walked through the process of including a CAPTCHA on the APM logon page via a web service (Google reCAPTCHA project), to provide some protection against script based or other automated attacks. In this second example (Part 2), we’ll be a bit more selective around when to display the CAPTCHA challenge (no point inconveniencing valid users) by displaying a CAPTCHA only after the user has failed full authentication. This is done using an AD Query for the user’s bad password count attribute. The selective CAPTCHA challenge provides the same benefits as with Part 1 (always on CAPTCHA) by blocking automated password-guessing attacks as well as DOS attacks against Active Directory. In this case a user’s internal corporate AD account may be locked after a number of sequential failed authentication failures in an external DOS attack – a serious inconvenience to the user affected as well as his IT department! In this example we’ll be using a two page configuration. If a user fails authentication, the next time they sign on, they’ll be prompted for a CAPTCHA challenge after entering their login credentials (via a separate page).

Visual Policy Editor – Macros

Start with a new access policy (you can use a wizard to do this – See Part 1 of this series). Create a Macro; I called mine Plain Captcha. This will just be a page with a CAPTCHA. We’re using a macro because we’ll be using this Plain Captcha many times in this policy so it’s easier than creating a new logon page each time we need it. See Figure 1.

Configure the Logon Page as in Part 1 with the extra post variables. Then go into Advanced Customization as discussed in Part 1. Remove the same PHP code and add the following:

<tr>

  <td colspan=2 class="credentials_table_unified_cell">

  <script type="text/javascript"

     src="https://www.google.com/recaptcha/api/challenge?k=replace_with_your_public_key">

  </script>

  <noscript>

     <iframe src="https://www.google.com/recaptcha/api/noscript?k=replace_with_your_public_key"

         height="300" width="500" frameborder="0"></iframe><br>

     <textarea name="recaptcha_challenge_field" rows="3" cols="40">

     </textarea>

     <input type="hidden" name="recaptcha_response_field"

         value="manual_challenge">

  </noscript>

  </td>

</tr>

Don’t forget to do all the necessary steps for advanced customization. See Part 1 - Advanced Customization Checklist for directions.

Next, let’s add another macro that does the authentication and resource assignment. We don’t need to build this macro ourselves; we can simply select the macro template AD auth and resources (you may use your choice of auth factors but my examples will be using AD auth). Remove the Logon Page from the macro after saving. Configure the AD Auth with your AD server and change Max Logon Attempts Allowed to one.

Once you add a Webtop to Resource Assign, your macro should look like Figure 2.

Now that we have finished building the macros, we can start with our access policy. The general flow of the policy should be that we only directly authenticate a user if we know they exist in Active Directory (a valid username) and they have not previously failed authentication. We can determine this through use an AD Query. If the user is invalid, we stop them here. If the user is valid, but has previously failed authentication, we will give them a CAPTCHA challenge. The policy is quite simple. Create a Logon Page followed by AD Query, and based on the following branch rules we can determine which leg to take.

Cases:

If we have a valid user and they have not previously failed authentication (badPwdCount is zero), we can authenticate them directly with our AD auth and resources macro. If the user passes, then he is allowed to access the VPN.
If we have a valid user and they have not previously failed authentication but the user fails the auth agent for the first time, we still need to show the CAPTCHA at the end just to ensure that the behavior follows all the other cases.
If we had a valid user and they previously failed authentication (badPwdCount is one or higher), we can display the CAPTCHA challenge and authenticate the response against Google’s reCAPTCHA web service using HTTP Auth. If the user was able to enter the CAPTCHA correctly, the user is then allowed to authenticate.
If we find that this is an invalid user, we don’t have to authenticate them (as they are going to fail authentication anyway). However, since we don’t want to give a hacker any hints about who’s a valid user and who’s not (allow for a username guessing attack), we must present the same end user behavior as if someone had entered incorrect credentials.

See Figure 3 for the complete VPE.

The HTTP Auth should be set up exactly as described in Part 1. If you wanted to configure a new HTTP Auth without having to go through the device wizard, you can go to AAA Servers under Access Policy. Now the user will encounter a CAPTCHA if they ever fail authentication. The Deny provides gives a lot of information but we can edit it to make it more readable and helpful to our users. To accomplish this, click on Edit Endings and under Deny, and then the plus sign next to Customization.

Final Notes

This solution is a great example where we used AD Query to selectively determine when to show our CAPTCHA challenge, in order to reduce the inconvenience of typing CAPTCHA challenges. But, this solution is not perfect. We’re limited to only allowing one bad authentication before showing the CAPTCHA. This is because AD Query only knows about users who exist in its database (valid users). If you’re trying to use the badPwdCount attribute to track more than one authentication failure, it is possible for a hacker to figure out if they have guessed a valid username (CAPTCHA challenge shown after a single failure for unknown usernames, but after two or more failures for legitimate usernames). In our next example (Part 3), we’ll build on this work and demonstrate a new technique for safely tracking multiple authentication failures. We’ll also remove the dependency on Active Directory for the authentication failure tracking.

Preventing Brute Force Password Guessing Attacks with APM–Part 1

Thu, 04 Aug 2011 04:39:00 EDT

Introduction

Exposing applications or services to the Internet opens inherent security risks. BIG-IP Access Policy Manager (APM) provides edge authentication and access control services for applications, BIG-IP Edge Gateway provides secure SSL VPN services, and BIG-IP Application Security Manager (ASM) provides protection against a variety of attacks. In this series of APM deployment examples, we will cover a couple of techniques for protecting against brute force password-guessing attacks. We’ll start with examples where a CAPTCHA challenge is used to block automated password guessing attacks, followed by an example providing temporary account lockout after a configured number of authentication failures.

CAPTCHA stands for Completely Automated Public Turing Test to Tell Computers and Humans Apart (quite a mouthful), but basically consists of a challenge that a human can pass but a computer program cannot. It is used to protect against bots, and in the examples here can help protect against an automated password guessing attack.

We can take advantage of Google’s reCAPTCHA web service and APM’s flexible advanced customization to provide basic defense against automated password guessing attacks. In addition, we will play around with the general look of your logon page. With reCAPTCHA available as a web service, we’ll be incorporating the CAPTCHA challenge within the APM logon page via advanced customization. The JavaScript added to the logon page will request a challenge (image with distorted text) from the reCAPTCHA web service and display it within the page. We’ll then create a custom APM Access Policy where we validate the user’s CAPTCHA challenge answer against the same reCAPTCHA web service (using the APM HTTP Auth agent). The links below describe the Google reCAPTCHA service in greater detail:

Initial Setup – Create a Google Account for the reCAPTCHA Project

Sign up for Google’s reCAPTCHA project through http://www.google.com/recaptcha/whyrecaptcha. Fill in a domain name and jot down the private and public keys for we’ll be using them later.

Device Wizard

For the purpose of this example, we’ll be using the Network Access Setup Wizard for Remote Access option under Templates and Wizards -> Device Wizards shown in Figure 1.

Select HTTP Authentication with the following setup. This is required to verify the CAPTCHA challenge answer from the user against the reCAPTCHA web service.

Follow the steps in the wizard (AAA Server, Lease Pool, Network Access, and etc.) to get to the summary page shown below in Figure 2. Before clicking finished, enter the Visual Policy Editor (VPE) to make a few changes.

Click on Logon Page and modify field 3 and 4 under Logon Page Agent with the following configuration and save.

Note: The logon page agent will only parse and store POST parameters it knows about (that are defined here). We’ll be hiding these two new fields on the logon page via advanced customization later.

You should add an Ad Auth after the success leg of HTTP Auth. That way, you only need to check their credentials once we know for sure that this is a human user (passes the CAPTCHA challenge).

Update the access policy by clicking Apply Access Policy and finish the Device Wizard.

Advanced Customization

Follow steps 1-3 under the section “Customize the Logon Page” in the BIG-IP APM-Customized Logon Page article. We’ll be replacing the auto-generated logon form with HTML that includes the username and password
fields, along with some JavaScript that calls the reCAPTCHA service and includes the challenge within the page. Edit logon_en.inc file: remove this block of PHP code:

<? 

//------------------------------------------------------------ 

foreach( $fields_settings as $field_settings ) 

{ 

    if( $field_settings["type"] != "none" ) 

    { 

        if( $GLOBALS["label_position"] == "above" ){ 

?> 

    <tr> 

        <td colspan=2 class="credentials_table_unified_cell" ><label for="<? print( $field_settings["type"] ); ?>"><? print( 

$field_settings["caption"] ); ?></label><input type=<? print( $field_settings["type"] ); ?> name=<? print( $field_settings["name"] ); ?> 

class="credentials_input_<? print( $field_settings["type"] ); ?>" <? print( ( $field_settings["rw"] == 0 ? "disabled" : "" ) ); ?> value="<? 

print( $field_settings["value"] ); ?>" autocomplete="off"></td> 

    </tr> 

<? 

        }else{ 

?> 

    <tr> 

        <td class="credentials_table_label_cell" ><? print( $field_settings["caption"] ); ?></td> 

        <td class="credentials_table_field_cell"><input type="<? print( $field_settings["type"] ); ?>" name="<? print( $field_settings["name"] 

); ?>" class="credentials_input_<? print( $field_settings["type"] ); ?>" <? print( ( $field_settings["rw"] == 0 ? "disabled" : "" ) ); ?> 

value="<? print( $field_settings["value"] ); ?>" autocomplete="off"></td> 

    </tr> 

<? 

        } 

    } 

} 

//------------------------------------------------------------ 

?>

In its place, paste this second block of code. Make sure to replace the red text with your own information.

<tr> 

       <td colspan=2 class="credentials_table_unified_cell" ><label for="text">Username</label><input type=text name=username 

lass="credentials_input_text"  value="" autocomplete="off" autocapitalize="off"></td> 

   </tr> 

   <tr> 

       <td colspan=2 class="credentials_table_unified_cell" ><label for="password">Password</label><input type=password 

ame=password class="credentials_input_password"  value="" autocomplete="off" autocapitalize="off"></td> 

   </tr> 

tr> 

 <td colspan=2 class="credentials_table_unified_cell"> 

 <script type="text/javascript" 

    src="https://www.google.com/recaptcha/api/challenge?k=replace_with_your_public_key"> 

 </script> 

 <noscript> 

    <iframe src="https://www.google.com/recaptcha/api/noscript?k=replace_with_your_public_key" 

        height="300" width="500" frameborder="0"></iframe><br> 

    <textarea name="recaptcha_challenge_field" rows="3" cols="40"> 

    </textarea> 

    <input type="hidden" name="recaptcha_response_field" 

        value="manual_challenge"> 

 </noscript> 

 </td> 

/tr>

Apply the customizations to the policy with the following commands:

b customization group <your policy name>_act_logon_page_ag action update
b profile access <your policy name> generation action increment

Extra Touches

Currently the page should like like Figure 3.

But we can easily customize this page. First, let us start by adding a helpful message before the CAPTCHA. Open the logon_en.inc file again and add some HTML like below. Place it between the <td...> tag and <script…> tag we added earlier.

<td colspan=2 class="credentials_table_unified_cell">

<label for="text">Security Check<p>Enter <b>both words</b> below, <b>separated by a space</b>.</p></label>

<script type="text/javascript"

Edit this message as fits your organization. Don’t forget to update the access policy! The page now looks like Figure 4:

The color scheme of the CAPTCHA may not work for every page so Google provides a few more templates shown in Figure 5. If you feel that you would like to do more customization, see the documentation found on this page -http://code.google.com/apis/recaptcha/docs/customization.html.

<script type="text/javascript">

var RecaptchaOptions = {

   theme : 'theme_name'

};

</script>

To display a standard theme, add the following script into logon_en.inc anywhere before the <form> element where we inserted our code. Replace ‘theme_name’ with one of the above theme names. In Figure 6, I’m using the ‘white’ theme. Remember to update!

More Extra Touches – Changing the Look of Your Page

To customize the look of your page, click on your access profile- Access Policy -> Access Profiles -> <your access policy> -> Customization (third tab from the left on the top) -> general UI -> Find Customization.

Feel free to make whatever changes you like, in Figure 7, I changed the color of the Header background color, and Form background color to #63919E and #94BBC2 respectively.

Advanced Customization (Logon Page) Checklist

When you copy and paste to a template file, it has the following formatting: logon_<language>.inc
Set permissions using the following command
- chmod a+r logon_<language>.inc
After editing, update with the following two commands
- b customization group <your policy name>_act_logon_page_ag action update
- b profile access <your policy name> generation action increment

Final Notes

Exposing applications or services to the Internet opens inherent security risks. APM can help by providing advanced authentication, authorization, and endpoint security checks. With a bit of customization you can integrate with web services such as the Google reCAPTCHA project to provide additional security layers. In our next example, we’ll build on this work to display the CAPTCHA only after the user has failed full authentication, to reduce the inconvenience of typing CATPCHA challenges. We’ll be demonstrating how to do an AD Query and use the bad password count attribute to determine when to show the CAPTCHA challenge.

Back in the Saddle

Mon, 01 Aug 2011 03:34:48 EDT

July was a busy month. I took the first three weeks off and drove much of what’s left of the “mother road” on Historic Route 66.with the family, our Ford Expedition, and way too many nights in our 31’ travel trailer. Great memories and stories for a lifetime out of that trip. I was home long enough to unpack, do laundry, and repack for a great week in Chicago with the DevCentral team. On Monday, we had a great time diving in to F5 technology goodness with the MVPs (and hoolio and Chris Miller!) at the Thinkubator. It was a great meeting place with a rooftop deck accessible only by a spiral staircase. The view of downtown was amazing:

It’s a good thing we all like each other ‘cause we spent the whole day together—three meals and some great content along the way. I particularly enjoyed the lightning talks from the MVPs, but the content from our product development/product management teams was great as well. Tuesday, THE Colin Walker and I taught a “Short Course” (7 hours!) on iRules and had a great session. The F5 Agility conference took place Wednesday and Thursday and the DevCentral booth was hopping with video interviews throughout. Check out DCTV for a great variety of partner/MVP interviews.

Anyway, circling back to my title for this post: I’m back in the saddle, baby. It’s a new week, a new month, and a new era for F5 with the announcement of BIG-IP v11. We here at DevCentral are getting the gears turning on all the content coming your way. There will be plenty, as there is an astounding amount of innovation coming in this release. I’m super excited, as are all the folks I’ve talked to that evaluated v11 during the beta windows. Much to learn, much to do, so I’m signing off for now…

Technorati Tags: F5 DevCentral,MVP,Thinkubator,BIG-IP,iRules,BIG-IP v11,Jason Rahm

So Yeah, Regex is Bad

Wed, 22 Jun 2011 10:12:00 EDT

Don’t get me wrong, regex is awesome, and entirely useful—sometimes it’s the only option, it’s just not the best tool of choice for wire speed applications. Often the sys-admin and network type converts to BIG-IP will find the regexp tcl command and go that route because it’s familiar. If that describes you, please let me introduce you to a couple more appropriate commands:

scan
string

These two commands will cover a great percentage of regexp’s use cases, and will save significant resources on the system. Don’t buy it? Here’s an example:

% set ip "10.10.20.200"

10.10.20.200

% time { scan $ip {%d.%d.%d.%d} a b c d} 10000

2.1713 microseconds per iteration

% time {regexp {([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})\.([0-9]{1,3})} $ip matched a b c d} 10000

34.2604 microseconds per iteration

Two approaches, same result. The time to achieve that result? The scan command bests regexp by far. I’ll save you the calculation…that’s a 93.7% reduction in processing time. 93.7 percent! Now, mind you, the difference between 2 and 34 microseconds will be negligible to an individual request’s response time, but in the context of a single system handling hundreds of thousands or even millions of request per second, the difference matters. A lot.

Thanks to (who else?) hoolio for the example. For other optimization considerations, check out the iRules Optimization 101 series.

Related Articles

Technorati Tags: F5 DevCentral,regex,regexp,scan,string,tcl,iRules,performance,Jason Rahm

BIG-IP APM–Customized Logon Page

Tue, 21 Jun 2011 05:30:00 EDT

The default logon page for the Access Policy Manager module is pretty basic, particularly so if only the minimal username and password is configured. However, APM is wildly flexible. In this tech tip, I’ll cover customizing the logon page by adding a dropdown box of services to the standard username and password fields.

Introduction

Background Information

The goal here is to provide access to multiple web applications behind APM through the use of an admin-defined dropdown menu and different LTM pools for each web application. We will be generating the list dynamically through the use of data groups so there will be no need to manually edit the iRule code each time an admin decides to add another option.

Solution Overview

Combining advanced customization, data groups, and iRules, we can dynamically generate html code for each key value pair in the data group. We simply add a session variable in the logon page through advanced customization and insert our html code, generated with iRules, through the session variable. The data group serves as a user friendly way of adding more applications as a layer of indirection.

Create the Access Policy

Before I can create the custom logon page, I need to have an access policy defined. I’ll do this by utilizing the Device Wizards option under the Templates and Wizards main tab. Select Web Application Access Management for Local Traffic Virtual Servers as show below in Figure 1.

After following the steps in the wizard (AAA server, virtual IP, pool info, etc), I get to the summary page shown below in Figure 2. Before clicking finished, I need to enter the Visual Policy Editor to make a couple edits.

Immediately after the start box in the VPE, I add an iRule Event as show in Figure 3. This will trigger the iRule event ACCESS_POLICY_AGENT_EVENT in the iRule featured later in this article.

I make sure to assign an ID to the event before saving it. Next, I click into the Logon Page event in the VPE and add a text field immediately after the password field. I then set the Post Variable Name and the Session Variable Name to ‘appname’. (The name is not significant but will need to match a statement in some HTML I’ll replace later in the article.) In the Logon Page Input Field #3 box, I enter ‘Application’ (this ensures the logon page agent will know to expect it as one of the POST parameters) and then click save. See Figure 4 below for details.

Note: The logon page agent will only parse and store POST parameters it knows about.

Finally, I update the access policy by clicking Apply Access Policy and then finish the Device Wizard.

Customize the Logon Page

Now that the policy is created, I need to login to the CLI to complete several steps.

1. Change Directory into the specific policy’s logon directory:

cd/config/customization/advanced/logon/<policy_name>_act_logon_page_ag (where <policy_name> is your policy name. devCenEx_act_logon_page_ag in my case.

2. Make a copy of the tmp_logon_en.inc file (the name logon_en.inc is significant.)

cp tmp_logon_en.inc logon_en.inc

3. Add group and world read permissions to the logon_en.inc file

chmod a+r logon_en.inc

4. Edit and save the logon_en.inc file, replacing this auto-generated PHP code with the HTML code below it. Notice the label and select tags reference Applications and appname (respectively) from our Logon Page in Figure 4.

Auto-generated PHP (remove)

<?
//------------------------------------------------------------
foreach( $fields_settings as $field_settings )
{
    if( $field_settings["type"] != "none" )
    {
        if( $GLOBALS["label_position"] == "above" ){
?>
    <tr>
        <td colspan=2 class="credentials_table_unified_cell" ><label for="<? print( $field_settings["type"] );

?>"><? print( $field_settings["caption"] );

?></label><input type=<? print( $field_settings["type"] );

?> name=<? print( $field_settings["name"] );

?> class="credentials_input_<? print( $field_settings["type"] );

?>" <? print( ( $field_settings["rw"] == 0 ? "disabled" : "" ) );

?> value="<? print( $field_settings["value"] );

?>" autocomplete="off"></td>
    </tr>
<?
        }else{
?>
    <tr>
        <td class="credentials_table_label_cell" ><? print( $field_settings["caption"] );

?></td>
        <td class="credentials_table_field_cell"><input type="<? print( $field_settings["type"] );

?>" name="<? print( $field_settings["name"] ); 

?>" class="credentials_input_<? print( $field_settings["type"] ); 

?>" <? print( ( $field_settings["rw"] == 0 ? "disabled" : "" ) ); 

?> value="<? print( $field_settings["value"] ); 

?>" autocomplete="off"></td>
    </tr>
<?
        }
    }
}
//------------------------------------------------------------
?>

Custom HTML (add)

<tr>
        <td colspan=2 class="credentials_table_unified_cell" ><label for="text">Username</label>
        <input type=text name=username class="credentials_input_text"  value="" autocomplete="off" autocapitalize="off"></td>
    </tr>
    <tr>
        <td colspan=2 class="credentials_table_unified_cell" ><label for="password">Password</label>
        <input type=password name=password class="credentials_input_password"  value="" autocomplete="off" autocapitalize="off"></td>
    </tr>
    <tr>
        <td colspan=2 class="credentials_table_unified_cell" ><label for="text">Applications</label>
          <select name="appname">
            %{session.custom.logon_opt} 
          </select>
       </td>
    </tr>

Note: The HTML above can be further customized if desired. The important section of code is:

     <select name>=”appname”>

         %{session.custom.logon_opt}

     </select>

The POST variable was created in the Logon page and then the dummy session variable that will be utilized in the iRule.

5. Apply the customizations to the policy

advCustHelp <your policy name>

b customization group <your policy_name>_general_ui action update

b profile access <your policy name> generation action increment

6. Create a string class for the applications. The string should be the name of the application to be displayed in the Logon Page and the value should be the pool that hosts the applicable service. See Figure 5 below for the GUI entry for the class.

class ExampleDataGroup {
   {
      "OWA" { "intranet-pool" }
      "Share Point" { "sharepoint-pool" }
   }
}

7. Create the iRule (via iRule editor, GUI, or tmsh)

when ACCESS_POLICY_AGENT_EVENT {
  set htmlstr ""
  # Pull data from the data group
  set keys [class names ExampleDataGroup]
  # log local0. "DATA GROUP:: $keys"
  foreach key $keys {
  # log local0. "KEY:: $key"
  # Add a new option in the drop down box for each key
    set htmlstr [concat $htmlstr "<option value=\"$key\">$key</option>"]
  }
  # log local0. "HTML STRING:: $htmlstr"
  # Using the session variable we inserted through advanced customization, we can insert the html code we generated above
  ACCESS::session data set "session.custom.logon_opt" $htmlstr
}

when ACCESS_ACL_ALLOWED {
  set appname [ACCESS::session data get "session.logon.last.appname"]
  # log local0. "appname: $appname"
  set keys [class names ExampleDataGroup]
  set index [lsearch $keys $appname]
  # log local0. "index: $index"
  if {$index >= 0} {
    set keyValue [class element $index ExampleDataGroup]
    pool [lindex $keyValue 1]
    # log local0. "POOL:: [lindex $keyValue 1]"
  }
}

Note that the class name referenced in the iRule should match the actual class name (instead of ExampleDataGroup as shown above)

8. Apply the iRule to the APM virtual server and I’m done!

tmsh modify /ltm virtual custom_dropdown_vs rules { custom_dropdown_iRule }

Figure 6 below shows the resulting logon page from the customizations performed. This is just the surface of what can be done to customize the logon page. Many thanks to F5er ystephie for writing up the documentation steps for this solution.

Related Articles

Changing the BIG-IP Default Syslog-NG Facilities

Mon, 20 Jun 2011 04:44:26 EDT

DevCentral community member geffr had a problem. The BIG-IP Application Security Manager module logs to the local3 facility but he needs to send them to the local7 facility on a remote server. Before giving up entirely, he posted to this thread in the Monitoring & Management group forum, where user nitass helped him jump through the syslog-ng hoops (click here for tips & tricks on syslog-ng) to the working solution posted below. It’s pretty straight forward. Define a template, a filter, and a destination, and then put the pieces together in a log statement.

b syslog include '"

filter f_local3a {
facility(local3);
};

template t_asm {
template(\"<190> $MSGHDR$MSG\n\");
template_escape(no);
};

destination d_loghost5a {
udp(\"2.2.2.2\" port (514) template(t_asm));
};

log {
source(local);
filter(f_local3a);
destination(d_loghost5a);
};

"'

Note: The b syslog include ‘ “ “ ‘ wrapper around the custom configuration is merely for importing the configuration, it’s note part of the configuration itself.

Related Articles

LTM 9.4.2+: Custom Syslog Configuration > DevCentral > F5 ...

setting up syslog? - DevCentral - F5 DevCentral > Community ...

DevCentral Wiki: Syslog NG Email Configuration

Configuring syslog-ng to email messages > DevCentral > F5 ...

Syslog Priority Translation > DevCentral > F5 DevCentral > Tech Tips

Deb Allen - syslog

Customizing syslog-ng f_local0 filter - DevCentral - F5 DevCentral ...

Syslog locally and remote with specific facility level ...

Duplicate syslog traffic to multiple destinations - DevCentral ...

Custom syslog-ng facility - DevCentral - F5 DevCentral > Community ...

Technorati Tags: F5 DevCentral,BIG-IP,ASM,Application Security Manager,syslog,syslog-ng,Jason Rahm
read more

Hosting Sorry, Error, or Maintenance Pages on BIG-IP LTM with iRules

Tue, 14 Jun 2011 14:04:50 EDT

I’ve posted on this before (Host that Sorry Page on your BIG-IP!) but it’s been a while and there have been a few updates. Besides, narrowing the application to only sorry pages is a bit myopic—I’m sure my BIG-IP is offended that I treated it so callously. Anyway, I got an inquiry a week or so ago about the images in tables not being picked up by the script. The images in the table were referenced as such:

#<table background="genericofflinebackground.gif" align="center" width="1024" height="768" >

I reached out to the author, Kirk Bauer, and he gave me some pointers as where to look. There’s a function in the perl script that parses the html to look for items of interest:

sub start {
my ($self, $tag, $attr, $attrseq, $origtext) = @_;
# print out original text
if ($tag eq 'img') {
if ($attr->{'src'}) {
$attr->{'src'} = &handle_object($tag, 'src', $attr->{'src'});
}
}

Modifying the if ($tag..) conditional to match the table wasn’t that hard at all:

sub start {
my ($self, $tag, $attr, $attrseq, $origtext) = @_;
# print out original text
if ($tag eq 'img') {
if ($attr->{'src'}) {
$attr->{'src'} = &handle_object($tag, 'src', $attr->{'src'});
}
}
if ($tag eq 'table') {
if ($attr->{'background'}) {
$attr->{'background'} = &handle_object($tag, 'background', $attr->{'background'});
}
}

That solved problem number one. The second problem with the script was that it wasn’t asking about partition preference, rather it just dumped the iRule and datagroups into the last partition defined in bigip.conf. This was strange, as the code to handle partitions was in place:

my @partitions;
open (CONF, "/config/bigip.conf") or die "Could not read /config/bigip.conf: $!\n";
while (my $line = <CONF>) {
if ($line =~ /^partition (.+) {/) {
push @partitions, $1;
}
}

The problem is that the regex is trying to match “partition <my partition> {“ and that is (at least in 10.2.1 HF3) no longer in the bigip.conf file. It has been moved to bigip_sys.conf. Updating the code as shown below solved the issue and now the user is asked for the appropriate partition and the iRule and datagroup gets deployed as expected.

my @partitions;
open (CONF, "/config/bigip_sys.conf") or die "Could not read /config/bigip_sys.conf: $!\n";
while (my $line = <CONF>) {
if ($line =~ /^partition (.+) {/) {
push @partitions, $1;
}
}

For the full script, head to the iRules wiki entry LTM Maintenance Page Generator and grab version 2.2.

Related Articles

Host that Sorry Page on your BIG-IP!

about i-rule sorry page configuration - DevCentral - F5 DevCentral ...

DevCentral Wiki: Automatic_maintenance_page___ Sorry_page_with_images

DevCentral Wiki: Sorry Page I Rule Generator_ Perl

DevCentral Wiki: LTM Maintenance Page Generator

DevCentral Wiki: CodeShare

Sorry Page when Severs are down - DevCentral - F5 DevCentral ...

Site Dwon Page form https virtual server - DevCentral - F5 ...

Technorati Tags: F5 DevCentral,sorry page,error page,maintenance page,perl,iRules,Jason Rahm,Kirk Bauer
read more

Removing A Strange HTTP Header with iRules

Tue, 31 May 2011 09:24:33 EDT

User Ralph Hoflich dropped an interesting problem off in the forums for his first post evah…he had a wireshark capture with a highly unusual header name:

Yes, the header name was “:”. This is interesting as it is also the separator in headers between the field name/value pair as described in rfc 2616 section 4.2. Thankfully, it’s just another character and is parsed out as such with iRules. So the simple task of removing a header like this is completed painlessly (as Ralph suspected in his own question). I added a couple logging statements to check before/after request headers:

when HTTP_REQUEST {

log local0. "[HTTP::header names]"

HTTP::header remove :

}

when HTTP_REQUEST_SEND {

clientside {

log local0. "[HTTP::header names]"

}

}

The HTTP::header remove command will not error out if the header isn’t present, so there’s no need for a conditional check.

Testing

From the browser, I couldn’t generate the load as desired with the Firefox modify headers plugin, but I was able to insert the header with cURL:

root@jrahm-dev:~# curl -v -H ':: /r/n' http://10.10.20.50/
* About to connect() to 10.10.20.50 port 80 (#0)
*   Trying 10.10.20.50... connected
* Connected to 10.10.20.50 (10.10.20.50) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: 10.10.20.50
> Accept: */*
> :: /r/n
>
< HTTP/1.1 200 OK
< Date: Tue, 31 May 2011 20:02:57 GMT
< Server: Apache/2.2.14 (Ubuntu)
< Last-Modified: Thu, 24 Jun 2010 14:26:22 GMT
< ETag: "381fef-b1-489c77054eef8"
< Accept-Ranges: bytes
< Content-Length: 177
< Vary: Accept-Encoding
< Content-Type: text/html
< X-Pad: avoid browser bug
<
<html><body><h1>It works!</h1>
<p>This is the default web page for this server.</p>
<p>The web server software is running but no content has been added, yet.</p>
</body></html>
* Connection #0 to host 10.10.20.50 left intact
* Closing connection #0

And the resulting log statements:

May 31 15:27:45 local/tmm info tmm[4972]: Rule header_remove <HTTP_REQUEST>: User-Agent Host Accept :
May 31 15:27:45 local/tmm info tmm[4972]: Rule header_remove <HTTP_REQUEST_SEND>: User-Agent Host Accept

Related Articles

I am in your HTTP headers, attacking your application

DevCentral Wiki: HTTP::header

Working around client-side limitations on custom HTTP headers

Add http header of Server IP address? - DevCentral - F5 DevCentral ...

Syntax for http header manipulation - DevCentral - F5 DevCentral ...

iRule persistance based on HTTP header - DevCentral - F5 ...

redirect base on HTTP header - DevCentral - F5 DevCentral ...

http header inserts - DevCentral - F5 DevCentral > Community ...

Error on HTTP::header insert - DevCentral - F5 DevCentral ...

Technorati Tags: F5 DevCentral,iRules,HTTP::header,Jason Rahm
read more

Fun with iRules: Haiku Error Responses

Wed, 27 Apr 2011 09:41:39 EDT

One of our stellar sales engineers, Rob Eberhardt, whipped up a fun iRule after one of his customers showed him some HTTP 404 errors returning haiku in BeOS. The class, and iRule, followed by the result. Enjoy!

The Class

Stored as an external class in /var/class/haiku_int.class (integer type).

1 := "The web site you seek<br>Lies beyond our perception<br>But others await.",

2 := "Sites you are seeking<br>From your path they are fleeing<br>Their winter has come.",

3 := "A truth found, be told<br>You are far from the fold, Go<br>Come back yet again.",

4 := "Wind catches lily<br>Scatt'ring petals to the wind:<br>Your site is not found.",

5 := "These three are certain:<br>Death, taxes, and site not found.<br>You, victim of one.",

6 := "Ephemeral site.<br>I am the Blue Screen of Death.<br>No one hears your screams.",

This continues on through 38, but the remaining ones removed for brevity. Now the class reference:

class haiku_class {

type value

filename "/var/class/haiku_int.class"

separator ":="

}

The iRule

when RULE_INIT {

set static::error_404 {

<html>

<head>

</head>

<body bgcolor="#E7E7E7">

<div class=Section1>

<br>

<p class=MsoNormal align=center>

<span>

<div align=center>

<table width=500 height=258>

<tr>

<td width=105 valign=center style='background:#0078AD'>

<p align=center>

<span style='font-family:"Arial","sans-serif"; color: white; font-size: large'>

Error 404:<br>File Not Found

</span></p></td>

<td width=236 style='background:white'>

<p align=center><strong><span style='font-family:"Arial","sans-serif"'>

}

}

when HTTP_RESPONSE {

if { [HTTP::status] == 404 } {

set randomnumber [expr { int (38 * rand()) }]

set haiku [class match -value $randomnumber equals haiku_class]

set response [concat $static::error_404 $haiku]

HTTP::respond 200 content [subst $response]

}

}

The Result

Here’s a couple snapshots of the browser (I commented out the if clause to generate the error every request)

Related Articles

more fun with iRules - DevCentral - F5 DevCentral > Community ...

iRule: Fun with 404s

iRules: Rewriting URIs for Fun and Profit

Fun with 404s - DevCentral - F5 DevCentral > Community > Group ...

Fun with regexp... - DevCentral - F5 DevCentral > Community ...

Fun with 404s - DevCentral - F5 DevCentral > Community > Group ...

Fun with ldap - DevCentral - F5 DevCentral > Community > Group ...

more fun with jsessionid persistence - DevCentral - F5 DevCentral ...

Akamai, True-Client-IP, and fun with logging - DevCentral - F5 ...

Fun with Hash Performance and Google Charts > DevCentral > F5 ...

read more

Remote Authorization via Active Directory

Wed, 27 Apr 2011 05:05:00 EDT

A while back I wrote an article on remote authorization via tacacs+. I got a question in the comments yesterday about the same functionality with active directory. I hadn’t done anything with active directory outside of APM, so I wasn’t sure I could help. However, after reading up on a few solutions on askF5 (10929 and 11072 specifically), I gave it a shot and turns out it’s not so difficult at all. For more details on the roles themselves, reference the tacacs+ article. This tech tip will focus solely on defining the administrator and guest roles in the remoterole configuration on BIG-IP and setting up the active directory attributes.

Mapping AD Attributes

The attribute in the remoterole for active directory will look like this:

memberOF=cn=<common name>, ou=<organizational unit>,dc=x,dc=y

Some notes on this

The cn can be a single account, or a group. For example, jason.rahm (single account) or grp-Admins (security group) In the string, they’re represented as such:

memberOF=cn=jason.rahm

memberOF=cn=grp-Admins

The ou is the organization unit where the cn is defined. It can be deeper than one level (So if the OU organization was IT->Ops and IT->Eng, the ou part of the string would like this:

ou=Ops,ou=IT

ou=Eng,ou=IT

The dc is the domain component. So for a domain like devcentral.test, the dc looks like this

dc=devcentral,dc=test

Putting the examples all together, one attribute would look like this:

memberOF=cn=grp-Admins,ou=Ops,ou=IT,dc=devcentral,dc=test

Defining the Remote Role Configuration

In tmsh, the remote-role configuration is under the auth module. The configuration options available to a specific role (defined under role-info) are shown below

(tmos.auth.remote-role)# modify role-info add { F5Guest { ?
Properties:
"}"             Close the left brace
attribute       Specifies the name of the group of remotely-authenticated users for whom you are configuring specific access rights to the BIG-IP system.
                  This value is required.
console         Enables or disables console access for the specified group of remotely authenticated users. You may specify bpsh, disabled, tmsh or use
                  variable substitution as describe in the help page. The default value is disabled.
deny            Enables or disables remote access for the specified group of remotely authenticated users. The default value is disable.
line-order      Specifies the order of the line in the file, /config/bigip/auth/remoterole. The LDAP and Active Directory servers read this file line by
                  line. The order of the information is important; therefore, F5 recommends that you set the first line at 1000. This allows you, in the
                  future, to insert lines before the first line. This value is required.
role            Specifies the role that you want to grant to the specified group of remotely authenticated users. The default value is no-access. The
                  available roles and the corresponding number that you use to specify the role are: admin (0), resource-admin (20), user-manager (40),
                  manager (100), application-editor (300), operator (400), guest (700), policy-editor (800) and no-access (900).
user-partition Specifies the user partition to which you are assigning access to the specified group of remotely authenticated users. The default value
                  is Common.

With that syntax information and the AD attribute strings, I can define both roles:

tmsh modify auth remote-role role-info add { F5Admins { attribute memberOF=cn=grp-F5Admins,ou=Groups,dc=devcentral,dc=test console enable line-order 1 role administrator user-partition all } }

tmsh modify auth remote-role role-info add { F5Guests { attribute memberOF=cn=grp-F5Staff,ou=Groups,dc=devcentral,dc=test console disabled line-order 2 role guest user-partition all } }

Next I confirm the settings took.

tmsh show running-config /auth remote-role

auth remote-role {
    role-info {
        F5Admins {
            attribute memberOF=cn=grp-F5Admins,ou=Groups,dc=devcentral,dc=test
            console enable
            line-order 1
            role administrator
            user-partition all
        }
        F5Guests {
            attribute memberOF=cn=grp-F5Staff,ou=Groups,dc=devcentral,dc=test
            console disabled
            line-order 2
            role guest
            user-partition all
        }
    }
}

Configure the BIG-IP to Use Active Directory

Here I set the BIG-IP to use ldap authentication, defining my base-dn and the login attribute (samaccountname) and the user template (%s@devcentral.test).

tmsh modify auth ldap system-auth login-attribute samaccountname search-base-dn dc=devcentral,dc=test servers add { 192.168.202.110 } user-template %s@devcentral.test

And once again confirming the settings:

tmsh show running-config /auth ldap system-auth

auth ldap system-auth {
    login-attribute samaccountname
    search-base-dn dc=devcentral,dc=test
    servers { 192.168.202.110 }
    user-template %s@devcentral.test
}

Testing the Configuration

For the test there are two users. test.user belongs the grp-F5Staff cn, and jason.rahm belongs to the grp-F5Admins cn. Therefore, test.user should have Guest access to the GUI and no access to the console, whereas jason.rahm should have Administrator access to the GUI and console access. Let’s see if that’s the case.

Conclusion

In this tech tip I walked through the steps required to configure remote authorization utilizing the BIG-IP remoterole configuration and Active Directory. I didn’t cover the custom attributes like the in tacacs+ article, but the same process applies, so if you’d rather define the roles within Active Directory that can be done as well.

read more

Getting Started with Splunk for F5

Tue, 26 Apr 2011 10:09:00 EDT

Pete Silva & Lori MacVittie both had blog posts last week featuring the F5 Application for Splunk, so I thought I’d take the opportunity to get Splunk installed and check it out. In this first part, I’ll cover the installation process. This is one of the easiest installions I've ever written about--it's almost like I'm cheating or something.

Installing Splunk

My platform of choice for this article is Ubuntu, so I downloaded the 4.2.1 Debian package for 64-bit systems from the Splunk site. Installation is a one step breeze:

dpkg –i /var/tmp/splunk-4.2.1-98165-linux-2.6-amd64.deb

After installation (defaulting to /opt/splunk) start the Splunk server:

/opt/splunk/bin/splunk start

I had to accept the license agreement during the startup process. Afterwards, I was instructed to point my browser to http:<server>:8000. I logged in with the default credentials (admin / changeme) and then was instructed to change my password, which I did (you can skip this step if you prefer). Pretty easy path to an completed installation. The browser should now be in the state shown below in Figure 1.

Installing Splunk for F5

Click on Manager in the upper right-hand corner of the screen, which should take you to the screen shown below in Figure 2.

Next, click on Apps as shown below in Figure 3.

At this point you have a choice. If you downloaded the Splunk for F5 app from splunkbase, you can click the “install app from file” button. I chose to install from the web, so I clicked the “find more apps online” button. This loaded a listing from splunkbase, with the Splunk for F5 app shown at the bottom of Figure 4 below.

After clicking the “install Free” button, I had to enter my splunk.com credentials, then the application installed. Splunk requested a restart, so I restarted and then logged back in. My new session was returned to the online apps screen, so to get to my new F5 app, I clicked “back to search” in the upper left corner, which took my to the Search app home page. Finally, in the upper right corner I selected App and then clicked “Splunk for F5 Security”. This resulted in the screen show below in Figure 5.

Success! Now…what to do with it? How is this useful? Check back for part two next week… For some hints, check out the blogs I mentioned at the top of this article from Pete and Lori:

Spelunking for Big Data

Do You Splunk 2.0

Other Related Articles

Do you Splunk?

ASM & Splunk integration - DevCentral - F5 DevCentral > Community ...

F5 Networks Partner Spotlight - Splunk

f5 ltm dashboard in splunk - DevCentral - F5 DevCentral ...

Logging HTTP traffic to Splunk - DevCentral - F5 DevCentral ...

Client IP Logging with F5 & Splunk - DevCentral - F5 DevCentral ...

read more

To the Cloud! (On a Wing and a Prayer)

Mon, 25 Apr 2011 04:08:17 EDT

Being the ~~incredible~~ horrible planner I am, I started to order invitations early last week for a party I’m throwing for my wife’s graduation and it turns out they wanted double the cost of the invitations in overnight shipping! So…I sent evites. It took a day, however, to actually get them out. I started the process but was interrupted by the EC2 outage. I only know that for sure because the evite site I used was very quick to tell me in their error message that the problem was with the “Amazon EC2 Datacenter.” Was Amazon down? Yes. Is it Amazon’s fault the evite site couldn’t deliver? Absolutely not. The only failure that’s really noteworthy is that the issues they faced cascaded beyond a single availability zone and impacted others. That shouldn’t happen—Amazon has some explaining to do on that front.

Infrastructure as a service is a platform, not a design. To set it and forget it in EC2 is just begging for problems, as hundreds of app owners found out last week. “The Cloud” is hot, trendy, sexy, whatever you want to call it, but it’s not a panacea. It’s difficult enough to find all the hard and soft points of failure in your own datacenter, but the problem is even more exacerbated when most of the systems your application runs on is abstracted and inaccessible for you to isolate problems.

Everything fails, all the time

--Werner Vogels, CTO Amazon.com

So for a better experience in deploying applications to the cloud, you must assume that everything will break at every point. That means that multiple availability zones in a single region is probably not a smart move. If your application is mission critical, perhaps even multiple regions with a single vendor is not a smart move. It’s time to stop looking to the cloud as the “easy button” and face reality—you still need people with solid network and systems design skills to get you from an application in the cloud to a cloud application.

Resources

EC2 Outage Reactions Showcase Widespread Ignorance Regarding the Cloud

The AWS Outage: The Cloud’s Shining Moment

Three Things We Can Learn from AWS Failure

Cloud Computing Podcast Episode 144

How to “Think Cloud”: Architectural Design Patterns for Cloud Computing

Related Articles

Maybe Ubuntu Enterprise Cloud Makes Cloud Computing Too Easy

On Cloud, Integration and Performance

Lori MacVittie - cloud computing

Cloud Computing: Location is important, but not the way you think

Cloud is the How not the What

Dynamic Infrastructure: The Cloud within the Cloud

Cloud Computing: The Last Definition You'll Ever Need

Infrastructure Matters: Challenges of Cloud-based Testing

Load balancing is key to successful cloud-based (dynamic ...

F5 and the Cloud

Get your SaaS off my cloud

Technorati Tags: F5 DevCentral,Amazon EC2,EC2,Cloud,Cloud Computing,Jason Rahm,Werner Vogels
read more

Auto-launch Remote Desktop Sessions with APM

Tue, 19 Apr 2011 23:53:00 EDT

In my spare time, I do volunteer IT work and for quite some time my users have used the SSL-Explorer fork AditoVPN to get remote access to their work machines remotely. Adito does the job, but it requires a server (albeit virtual, but still) that must be maintained, seems to have been forked again (OpenVPN ALS) and occasionally locks up and requires more hands-on attention than I really have time for. I bought a copy of LTM VE last year to handle the web/mail services and was excited about moving users off the Adito solution when I learned that APM VE would be available when version 10.2.1 was released. I never have more than a handful of users accessing at the same time, so the base APM Limited license that is included with LTM VE suited me just fine. This article will show users how to configure APM to auto-launch a remote desktop session to an Active Directory user’s specified computer.

APM Required Components

The network access wizard does a tremendous job of getting the configuration kicked off, so I’d recommend that as a starting point. A couple things however that weren’t exactly obvious or just didn’t work:

If you already have your domain controller defined and in use on another application, you’ll need to define a dummy AD scenario or the wizard will fail. After the configuration is complete, you can reselect the proper server in your policy and then you can delete the dummy config.

The ssl certificates/profiles are absent from the wizard, so you’ll need to configure these separately.

After the wizard is complete, you end up with these configuration objects:

Access Profile w/ Policy

AAA Server

Network Access Resource

Lease Pool

Webtop

Virtual Server (or two if configuring the redirect from http)

Connectivity Profile

As stated previously, you’ll need to separately configure your ssl certificate and profile and update your virtual server accordingly.

Preparing Active Directory

The goal here is to minimize the amount of work required of remote users. Once a user is logged in, the remote desktop client should launch for the user and be populated with the server (or desktop) name/ip. If you choose, you can also have the users store credentials in an rdp file on their desktop so it would only require a single logon, but since that’s not a secure practice I won’t cover that here. To auto-launch rdp, you need to call the mstsc.exe executable with the /v option:

Any attribute on the account will do, but for this example I’m using the description attribute on the test.user AD account:

Access Policy Configuration

The network access wizard created an access policy that looks like this:

If you created your real AD server, you won’t need to update the AD Auth object. However, if you created a dummy AD in the network wizard, you’ll need to open AD Auth, select your real server, then click save. Because I know where my users are, I’m going to start the policy with an IP Geolocation Match object and restrict to the United States.

You can see the actual object on the left and the configuration of the “successful” branch in the expression above. If the location data matches the US, the logon page is presented. I used a standard Logon Page object here. After the logon page is the AD_Auth object, and then I added an AD Query object immediately after on the Successful branch of the AD Auth object. First, I removed the first branch rule (highlighted) from the object as it is unnecessary:

Then, I entered the search filter for the username:

Text in the above image is:

(samAccountName=%{session.logon.last.username})

On the fallback path of the AD Query object, insert a Variable Assign object (should sit in between AD Query and the already present Resource Assign objects):

Add an entry as shown above. Change to a configuration variable and set the type/name/property as shown below:

The expression text is:

expr {"<application_launch><item><path>mstsc.exe</path><parameter>[mcget {session.ad.last.attr.description} ]</parameter><os_type>WINDOWS</os_type></item></application_launch>"}

If you used the network access wizard, the Resource Assign object is already complete, but if starting from scratch, you’ll want to assign a network access resource and a webtop from your configuration:

Final step is to change the Deny flag after the Resource Assign object to Allow. This should result in an overview of the Access Policy as such:

On the Access Profiles list, make sure you apply the access policy if you haven’t:

That should do it!

Testing RDP Auto-Launch

Enough of configuration…does it work? Let’s give it a try:

APM RDP Auto-Launch

Conclusion

The APM module for BIG-IP is an amazing access solution. The default behavior in this scenario is to auto-launch the remote desktop session, but in addition to that functionality the user also has normal network-level access to whatever networks you defined while working through the wizard. Much thanks to F5er Doug Lohf for configuration details and insight.

Related Articles

Pete Silva - apm

DevCentral Wiki: BIG-IP Access Policy Manager (APM) Wiki Home

Does LTM any advanced health monitor for RDP service? - DevCentral ...

F5 Tutorial: BIG-IP APM with SecureAuth

Web Application Login Integration with APM > DevCentral > F5 ...

Set APM Cookies to HttpOnly - DevCentral - F5 DevCentral ...

nested virtuals with APM - DevCentral - F5 DevCentral > Community ...

RDP acceleration - DevCentral - F5 DevCentral > Community > Group ...

DevCentral Wiki: APM

NTLM/ Outlook Anywhere/ Big-IP APM - DevCentral - F5 DevCentral ...

read more

iRules IP Comparison Considerations with IP::addr Command

Thu, 31 Mar 2011 21:00:00 EDT

Anyone utilizing IP network comparisons in iRules is probably familiar with this syntax:

1: if { [IP::addr ]IP::client_addr[/24 equals 10.10.20.0] } {

2: ##Do this

3: }

In fact, there are several methods for doing a comparison. Here are three functional equivalents that include the most common form shown above:

[IP::addr ]IP::remote_addr[/24 equals 10.10.20.0]

[IP::addr ]IP::remote_addr[/255.255.255.0 equals 10.10.20.0]

[IP::addr "]IP::remote_addr[ mask 255.255.255.0" equals 10.10.20.0]

All three work, returning true if there is match and false if not. These formats, however, are not as ideal as it was never intended to work this way. What occurs when performing the comparison this way is the system has to convert the internal IP address to string form, apply the network mask, then re-convert the result back into an IP network object for comparison to the last argument. While possible, it isn’t as efficient and technically is an oversight in the syntax validation checking. It’s not slated to be “fixed” at this point, but it could be in the future, so you should consider updating any iRules to one of these formats:

[IP::addr ]IP::remote_addr[ equals 10.10.20.0/24]

[IP::addr ]IP::remote_addr[ equals 10.10.20.0/255.255.255.0]

[IP::addr ]IP::remote_addr[ equals "10.10.20.0 mask 255.255.255.0"]

In these formats, the input address does not need to be masked and can be directly compared with the pre-parsed network specification. Finally, there is one more format that works:

[IP::addr ]IP::addr [IP::remote_addr] mask 255.255.255.0[ equals 10.10.20.0]

This also doesn’t require any additional conversion, but the sheer volume of commands in that statement is an immediate indicator (to me, anyway) that it’s probably not very efficient.

Performance

Before running each format through a simple test (ab –n 10000 –c 25 http://<vip>), I set up a control so I could isolate the cycles for each format:

when HTTP_REQUEST timing on {

### CONTROL ###

if { 1 } { }

}

Since all the formats will return true if the match is found, then subtracting out the average cycles from this iRule should give me a pretty accurate accounting of cycles required for each specific format. So I can replace the “1” from the conditional with each format, as shown in this iRule:

when HTTP_REQUEST timing on {

### FUNCTIONAL EQUIVALENTS "RECOMMENDED" ###

# Format #1 Cycles: 6839 - 1136 = 5703

# if { [IP::addr ]IP::remote_addr[ equals 10.10.20.0/24] } { }

# Format #2 Cycles: 6903 - 1136 = 5767

# if { [IP::addr ]IP::remote_addr[ equals 10.10.20.0/255.255.255.0] } { }

# Format #3 Cycles: 7290 - 1136 = 6154

# if { [IP::addr ]IP::remote_addr[ equals "10.10.20.0 mask 255.255.255.0"] } { }

### FUNCTIONAL EQUIVALENTS "NOT RECOMMENDED" ###

# Format #4 Cycles: 8500 - 1136 = 7364

# if { [IP::addr ]IP::remote_addr[/24 equals 10.10.20.0] } { }

# Format #5 Cycles: 8543 - 1136 = 7407

# if { [IP::addr ]IP::remote_addr[/255.255.255.0 equals 10.10.20.0] } { }

# Format #6 Cycles: 8827 - 1136 = 7691

# if { [IP::addr "]IP::remote_addr[ mask 255.255.255.0" equals 10.10.20.0] } { }

### ALTERNATE FORMAT ###

# Format #7 Cycles: 9124 - 1136 = 7988

# if { [IP::addr ]IP::addr [IP::remote_addr] mask 255.255.255.0[ equals 10.10.20.0] } { }

### CONTROL ###

# Cycles: 1136

# if { 1 } { }

}

You can see from the average cycles data I added to each of the formats comments above that the recommended formats are all faster than the formats that are not recommended. What’s interesting is the subtle differences in the “/” formats within each group of functional equivalents and then the significant outliers that the “<net> mask <mask>” formats are within their group. Also of note is that the last format, while acceptable, is really inefficient and should probably be avoided. The table below breaks down the increase in cycles for each of the formats compared to the best performer: [IP::addr ]IP::remote_addr[ equals 10.10.20.0/24].

Whereas the number of cycles required to execute this operation are all quite small, the difference beyond the first two similar formats is quite significant.

Conclusion

Many ways to skin a cat, some good, some not so good. Just to be clear, using the mask on the initial argument of the comparison should be avoided, and if you currently have iRules utilizing this format, it would be best to update them sooner rather than later. I’ll be doing the same on all the DevCentral wikis, forums, articles, and blogs. If you find some references where we haven’t made this distinction, please comment below.

Related Articles

IP::addr and IPv6

DevCentral Wiki: IP::addr

Why do we need to use [IP::addr ]IP::client_addr[]? - DevCentral ...

IP Address based iRule - DevCentral - F5 DevCentral > Community ...

read more

iRules Data Group Formatting Rules

Tue, 29 Mar 2011 10:50:00 EDT

BIG-IP LTM supports internal and external classes (called Data Groups in the GUI) of address, string, and integer types. An internal class is stored in the bigip.conf file, whereas external classes are split between the bigip.conf and the file system (the class itself is defined in the bigip.conf file, but the values of the class are stored in the file system in a location of your choice, though /var/class is the location defined for synchronization in the cs.dat file) Which flavor? Depends on the requirements. External classes are generally best suited for very large datasets or for datasets that require frequent updates like blacklists. Formatting is slightly different depending on whether the class is internal or external, and is also different based on the class type: address, integer, or string. Below I’ll show the formatting requirements for each scenario. If you are using the GUI to create key/value pairs in a class (and therefore deciding on an internal class), the formatting is handled for you. Note that with internal classes, the dataset is defined with the class, but with external classes, the class is defined with type, separator, and the filename where the dataset is stored. If there is no value for the type (internal or external) it is omitted with no separator.

Address Classes

[internal class]
class addr_testclass {
   {
      host 192.168.1.1
      host 192.168.1.2 { "host 2" }
      network 192.168.2.0/24
      network 192.168.3.0/24 { "network 2" }
   }
}

[external class]
class addr_testclass_ext {
   type ip
   filename "/var/class/addr_testclass.class"
   separator ":="
   }

[/var/class/addr_testclass.class]
host 192.168.1.1,
host 192.168.1.2 := "host 2",
network 192.168.2.0/24,
network 192.168.3.0/24 := "network 2",

Note: You can also add network entries in the address type external file like shown immediately below, but when the class is updated, it will be converted to the CIDR format.

network 192.168.4.0 mask 255.255.255.0 := “network 3”,
network 192.168.5.0 prefixlen 24 := "network 4",

Integer Classes

[internal class]
class int_testclass {
   {
      1 { "test 1" }
      2 { "test 2" }
   }
}

[external class]
class int_testclass_ext {
   type value
   filename "/var/class/int_testclass.class"
   separator ":="
   }

[/var/class/int_testclass.class]
1 := "test 1",
2 := "test 2",

String Classes

With string classes, quotes are necessary on the types and values:

[internal class]
class str_testclass {
   {
      "str1" { "value 1" }
      "str2" { "value 2" }
   }
}

[external class]
class str_testclass_ext {
   type string
   filename "/var/class/str_testclass.class"
   separator ":="
   }

[/var/class/str_class.class]
"str1" := "value 1",
"str2" := "value 2",

Working With External Files

Now that the formatting of the classes themselves are complete, I’d like to point out one more issue, and that’s file formatting. If you’re editing all the external classes by hand on the BIG-IP, you have nothing to worry about. However, if you edit them on an external system and copy them over, be careful on which editor you choose. The Unix/Linux line terminator is a line feed (0x0A) whereas Windows default is a carriage return/line feed (0x0D0A) and Mac typically employs just a carriage return (0x0D). The file needs to be formatted in unix-style. I use gVim on my windows laptop. By default, it uses the dos-style, as evidenced in my hex readout in gVim below:

0000000: 6865 6c6c 6f2c 2077 6f72 6c64 0d0a 7468 hello, world..th
0000010: 6973 2069 7320 6120 6c69 6e65 2074 6572 is is a line ter
0000020: 6d69 6e61 746f 7220 7465 7374 0d0a 0d0a minator test....
0000030: 0d0a                                     ..

Now, this is easily changed in gVim: “set fileformat=unix”. After this setting, now my linefeeds are correct:

0000000: 6865 6c6c 6f2c 2077 6f72 6c64 0a74 6869 hello, world.thi
0000010: 7320 6973 2061 206c 696e 6520 7465 726d s is a line term
0000020: 696e 6174 6f72 2074 6573 740a 0a0a       inator test...

The guidance here is…use a good editor (hint..Notepad and Word are not on that list!)

Related Articles

v.10 - New class features in iRules > DevCentral > F5 DevCentral ...

Validating Data Group (Class) References > DevCentral > F5 ...

Datagroup access during a datagroup update - DevCentral - F5 ...

Address Datagroup "value" field - DevCentral - F5 DevCentral ...

External class and class command - DevCentral - F5 DevCentral ...

Format of external (STring) class file - DevCentral - F5 ...

Question around Datagroup manipulation - DevCentral - F5 ...

Create an External class file - DevCentral - F5 DevCentral ...

read more

BIG-IP Configuration Conversion Scripts

Mon, 28 Mar 2011 05:06:35 EDT

Two of our biggest internal contributors, Kirk Bauer and John Alam, are at it again with a handful of perl scripts aimed at easing your migration from some of the “other guys” to BIG-IP. While they aren’t going to map every nook and cranny of the configurations to a BIG-IP feature, they will get you well along the way, taking out as much of the human error element as possible. I built a few pages in the Advanced Design & Configuration wiki to host these scripts.

Migrating from Cisco ACE, CSM, or CSS

Migrating from Citrix Netscaler

Migrating from Radware

Obviously with these being perl scripts you’ll need a copy of perl, or just load the script on your BIG-IP and do the migration there!
Related Articles

DevCentral Wiki: Perl

If Radware Succeeds in Purchasing Alteon, Will Anyone Care?

64-bit numbers in perl

DevCentral Wiki: Perl Ltm Config To Xml

GTM Network Map - Perl - DevCentral - F5 DevCentral > Community ...

DevCentral Wiki: CSS To BIGIP Conversion Script

Perl script to parse Siebel lbconfig.txt file update for BIG-IP ...

Convert Cisco CSS config to Big IP 3600 - DevCentral - F5 ...

Perl script to dump API response->result - DevCentral - F5 ...

Cisco CSS cookie persistency - DevCentral - F5 DevCentral ...

another potential 64 bit conversion issue in perl - DevCentral ...

DevCentral Wiki: Radware

CSS Config to F5 Config - DevCentral - F5 DevCentral > Community ...

Technorati Tags: F5 DevCentral,BIG-IP LTM,Perl,Migration,Jason Rahm,John Alam,Kirk Bauer
read more

Accessing TCP Options from iRules

Fri, 25 Mar 2011 10:15:00 EDT

I’ve written several articles on the TCP profile (click here) and enjoy digging into TCP. It’s a beast, and I am constantly re-learning the inner workings. Still etched in my visual memory map, however, is the TCP header format, shown in Figure 1 below.

Since 9.0 was released, TCP payload data (that which comes after the header) has been consumable in iRules via the TCP::payload and the port information has been available in the contextual commands TCP::local_port/TCP::remote_port and of course TCP::client_port/TCP::server_port. Options, however, have been inaccessible. However, beginning with version 10.2.0-HF2, it is now possible to retrieve data from the options fields.

Preparing the BIG-IP

Currently, it is necessary to set a bigpipe database key with the option (or options) of interest:

bigpipe db Rules.Tcpoption.settings [option, first|last], [option, first|last]

The option is an integer between 2 and 255, and the first/last setting indicates whether the system will retain the first or last instance of the specified option. Once that key is set, you’ll need to do a bigstart restart for it to take (warning: service impacting). This is only necessary prior to 10.2.1. Note also that the LTM only collects option data starting with the ACK of a connection. The initial SYN is ignored even if you select the first keyword. This is done to prevent a SYN flood attack (in keeping with SYN-cookies).

A New iRules Command: TCP::option

The TCP::option command has the following syntax:

TCP::option get <option>

Pretty simple, no? So now that you can access them, what fun can be had?

Real World Scenario: Akamai

In Akamai’s IPA and SXL product lines, they support client IP visibility by embedding a version number (one byte) and an IPv4 address (four bytes) as part of their overlay path feature in tcp option number 28. To access this data, we first set the database key:

b db Rules.Tcpoption.settings [28,first]

Now, the iRule utilizing the TCP::option command:

1: when CLIENT_ACCEPTED {

2: set opt28 [TCP::option get 28]

3: if { [string length $opt28] == 5 } {

4: binary scan $opt cH8 ver addr

5: if { $ver != 1 } {

6: log local0. "Unsupported Akamai version: $ver"

7: } else {

8: scan $addr "%2x%2x%2x%2x" ip1 ip2 ip3 ip4

9: set optaddr "$ip1.$ip2.$ip3.$ip4"

10: }

11: }

12: }

13: when HTTP_REQUEST {

14: if { [info exists optaddr] } {

15: HTTP::header insert "X-Forwarded-For" $optaddr

16: }

17: }

The Akamai version should be one, so we log if not. Otherwise, we take the address (stored in the variable addr in hex) and scan it to get the decimal equivalents to build the address for inserting in the X-Forwarded-For header. Cool, right? Also cool—along with the new TCP::option command, an extension was made to the IP::addr command to parse binary fields into a dotted decimal IP address. This extension is also available beginning in 10.2.0-HF2. Here’s the syntax:

IP::addr parse [-swap] <binary field> [<offset>]

So in the context of our TCP option, we have 5-bytes of data with the first byte not mattering in the context of an address, so we get at the address with this:

set optaddr [IP::addr parse ]TCP::option get 28[ 1]

This cleans up the rule a bit:

1: when CLIENT_ACCEPTED {

2: set opt28 [TCP::option get 28]

3: if { [string length $opt28] == 5 } {

4: binary scan $opt c ver

5: if { $ver != 1 } {

6: log local0. "Unsupported Akamai version: $ver"

7: } else {

8: set optaddr [IP::addr parse $opt28 1]

9: }

10: }

11: }

12: when HTTP_REQUEST {

13: if { [info exists optaddr] } {

14: HTTP::header insert "X-Forwarded-For" $optaddr

15: }

16: }

No need to store the address in the first binary scan and no need for the scan command at all so I eliminated those. Setting a forwarding header is not the only thing we can do with this data. It could also be shipped off to a logging server, or used as a snat address (assuming the server had either a default route to the BIG-IP, or specific routes for the customer destinations, which is doubtful). Logging is trivial, shown below with the log command. The HSL commands could be used in lieu of log if sending off-box to a log server.

1: when CLIENT_ACCEPTED {

2: set opt28 [TCP::option get 28]

3: if { [string length $opt28] == 5 } {

4: binary scan $opt c ver

5: if { $ver != 1 } {

6: log local0. "Unsupported Akamai version: $ver"

7: } else {

8: set optaddr [IP::addr parse $opt28 1]

9: log local0. "Client IP extracted from Akamai TCP option is $optaddr"

10: }

11: }

12: }

If setting the provided IP as a snat address, you’ll want to make sure it’s a valid IP address before doing so. You can use the TCL catch command and IP::addr to perform this check as seen in the iRule below:

1: when CLIENT_ACCEPTED {

2: set addrs [list \

3: "192.168.1.1" \

4: "256.168.1.1" \

5: "192.256.1.1" \

6: "192.168.256.1" \

7: "192.168.1.256" \

8: ]

9: foreach x $addrs {

10: if { [catch {IP::addr $x mask 255.255.255.255}] } {

11: log local0. "IP $x is invalid"

12: } else { log local0. "IP $x is valid" }

13: }

14: }

The output of this iRule:

<CLIENT_ACCEPTED>: IP 192.168.1.1 is valid
<CLIENT_ACCEPTED>: IP 256.168.1.1 is invalid
<CLIENT_ACCEPTED>: IP 192.256.1.1 is invalid
<CLIENT_ACCEPTED>: IP 192.168.256.1 is invalid
<CLIENT_ACCEPTED>: IP 192.168.1.256 is invalid

Adding this logic into a functional rule with snat:

1: when CLIENT_ACCEPTED {

2: set opt28 [TCP::option get 28]

3: if { [string length $opt28] == 5 } {

4: binary scan $opt c ver

5: if { $ver != 1 } {

6: log local0. "Unsupported Akamai version: $ver"

7: } else {

8: set optaddr [IP::addr parse $opt28 1]

9: if { [catch {IP::addr $x mask 255.255.255.255}] } {

10: log local0. "$optaddr is not a valid address"

11: snat automap

12: } else {

13: log local0. "Akamai inserted Client IP is $optaddr. Setting as snat address."

14: snat $optaddr

15: }

16: }

17: }

18: }

Alternative TCP Option Use Cases

The Akamai solution shows an application implementation taking advantage of normally unused space in TCP headers.    There are, however, defined uses for several option “kind” numbers. The list is available here: http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xml. Some options that might be useful in troubleshooting efforts:

Opkind 2 – Max Segment Size

Opkind 3 – Window Scaling

Opkind 5 – Selective Acknowledgements

Opkind 8 – Timestamps

Of course, with tcpdump you get all this plus the context of other header information and data, but hey, another tool in the toolbox, right?

Related Articles

3 Really good reasons you should use TCP multiplexing

New TCP vulnerability about trust, not technology

DevCentral Wiki: log

Investigating the LTM TCP Profile: Max Syn Retransmissions & Idle ...

Investigating the LTM TCP Profile: Acknowledgements > DevCentral ...

X-Forwarded-For Log Filter for Windows Servers

Investigating the LTM TCP Profile: Windows & Buffers > DevCentral ...

Investigating the LTM TCP Profile: Nagle's Algorithm > DevCentral ...

Investigating the LTM TCP Profile: The Finish Line > DevCentral ...

iRules Update: New options for the "log" command > DevCentral > F5 ...

IP::addr and IPv6

Investigating the LTM TCP Profile: ECN & LTR > DevCentral > F5 ...

Writing to and rotating custom log files > DevCentral > F5 ...

read more

GTM Classless Classes

Wed, 23 Mar 2011 10:47:18 EDT

I love ingenuity. DevCentral community member wassim asked a question a little more than a month ago that has been asked several times before: How do you build a class in GTM so you don’t have to use a hoard of if statements to account for your addresses? Well, classes (datagroups) aren’t yet supported in GTM iRules, so the options have been sparse. One option that could be utilized is to build a list that you can initialize in RULE_INIT:

1: when RULE_INIT {

2: set addr_group1 [list \

3: "10.10.10.0" \

4: "10.10.20.0" \

5: "10.10.30.0" \

6: ]

7: set addr_group2 [list \

8:    "10.20.10.0" \

9: "10.20.20.0" \

10: "10.20.30.0" \

11: ]

12: }

This, while possible, is hardly ideal. A few days ago, rather than drop the issue, wassim posted back with an alternative solution: Regions. GTM Regions allows one to assemble groups of topology records, which once assembled, can be referenced from an iRule:

1: when DNS_REQUEST {

2: if { [matchregion ldns addr_group1] } {

3: host 1.2.3.4

4: elseif { [matchregion ldns addr_group2] } {

5: host 5.6.7.8

6: } else {

7: host 1.1.1.1

8: }

9: }

Still have if/else statements, but it will be trimmed down to as many regions as you have defined. Nice work, wassim!
Related Articles

GTM irule help with matchregion? - devcentral - F5 devcentral ...

GTM and iRules allowing intelligent redirection for most protocols ...

v10.1 - Configuring GTM's DNS Security Extensions > DevCentral ...

GTM Geo Target based on State US -- Version 10.2 HF1 - DevCentral ...

Technorati Tags: F5 DevCentral,BIG-IP GTM,GTM,iRules,wassim,Jason Rahm
read more

IP::addr and IPv6

Wed, 23 Mar 2011 04:26:50 EDT

Did you know that all address internal to tmm are kept in IPv6 format? If you’ve written external monitors, I’m guessing you knew this. In the external monitors, for IPv4 networks the IPv6 “header” is removed with the line:

IP=`echo $1 | sed 's/::ffff://'`

IPv4 address are stored in what’s called “IPv4-mapped” format. An IPv4-mapped address has its first 80 bits set to zero and the next 16 set to one, followed by the 32 bits of the IPv4 address. The prefix looks like this:

0000:0000:0000:0000:0000:ffff: (abbreviated as ::ffff:, which looks strickingly simliar—ok, identical—to the pattern stripped above)

Notation of the IPv4 section of the IPv4-formatted address vary in implementations between ::ffff:192.168.1.1 and ::ffff:c0a8:c8c8, but only the latter notation (in hex) is supported. If you need the decimal version, you can extract it like so:

% puts $x
::ffff:c0a8:c8c8
% if { [string range $x 0 6] == "::ffff:" } {
scan [string range $x 7 end] "%2x%2x:%2x%2x" ip1 ip2 ip3 ip4
set ipv4addr "$ip1.$ip2.$ip3.$ip4"
}
192.168.200.200

Address Comparisons

The text format is not what controls whether the IP::addr command (nor the class command) does an IPv4 or IPv6 comparison. Whether or not the IP address is IPv4-mapped is what controls the comparison. The text format merely controls how the text is then translated into the internal IPv6 format (ie: whether it becomes a IPv4-mapped address or not). Normally, this is not an issue, however, if you are trying to compare an IPv6 address against an IPv4 address, then you really need to understand this mapping business. Also, it is not recommended to use 0.0.0.0/0.0.0.0 for testing whether something is IPv4 versus IPv6 as that is not really valid a IP address—using the 0.0.0.0 mask (technically the same as /0) is a loophole and ultimately, what you are doing is loading the equivalent form of a IPv4-mapped mask. Rather, you should just use the following to test whether it is an IPv4-mapped address:

if { [IP::addr $IP1 equals ::ffff:0000:0000/96] } { log local0. “Yep, that’s an IPv4 address” }

These notes are covered in the IP::addr wiki entry. Any updates to the command and/or supporting notes will exist there, so keep the links handy.

Related Articles

F5 Friday: 'IPv4 and IPv6 Can Coexist' or 'How to eat your cake ...

Service Provider Series: Managing the ipv6 Migration

IPv6 and the End of the World

No More IPv4. You do have your IPv6 plan running now, right ...

Question about IPv6 - BIGIP - DevCentral - F5 DevCentral ...

Insert IPv6 address into header - DevCentral - F5 DevCentral ...

Business Case for IPv6 - DevCentral - F5 DevCentral > Community ...

We're sorry. The IPv4 address you are trying to reach has been ...

Don MacVittie - F5 BIG-IP IPv6 Gateway Module

Technorati Tags: F5 DevCentral,iRules,IPv6,IP::addr,class,Jason Rahm
read more

Microsoft Exchange 2010 iRule Workflow Visualized

Tue, 15 Mar 2011 05:04:01 EDT

F5’s own John Alam sent over his latest Visio creation to share with the DevCentral community. This diagram details the workflow of the comprehensive exchange services iRule described in the Microsoft Exchange 2010 Deployment Guide. Enjoy.

For visio, pdf, png, & svg versions of this image, click here.

Related Articles

Microsoft Exchange 2010: HELO New Architecture

Webcast - Microsoft Exchange Server Availability And Scalability

Exchange Persistence Duality and iRules > DevCentral > F5 ...

How Microsoft deployed Exchange Server 2010 with hardware load ...

Planning an Exchange Migration? - DevCentral - F5 DevCentral ...

Exchange 2010 with F5 BIG-IP and Dell Article Published

devconnections 2010: Attendee discusses Exchange and Cloud Computing

F5 with mixed Exchange 2007 and 2010 Client Access Servers ...

Trying to implement Exchange 2010 - DevCentral - F5 DevCentral ...

Exchange 2010 Monitors for LTM - DevCentral - F5 DevCentral ...

Exchange 2010/LTM10.2 RPC mail delivery delay ? - DevCentral - F5 ...

Exchange 2010 Global address list issue - DevCentral - F5 ...

F5 solution for Microsoft Exchange

DevCentral Weekly Roundup | Audio Podcast - Exchange

Exchange 2007 - What Type of SSL certificate required (single ...

Technorati Tags: F5 DevCentral,iRules,Visio,Exchange,Exchange 2010,Jason Rahm,John Alam
read more

Documenting iRules with Comment Headers

Wed, 09 Mar 2011 04:30:00 EST

Did I lose you at “Documenting?” Documentation is rarely at the top of the list of things we make time for, yet the practice is critical. You never know when you’re going to see that iRule again, and if it’s six months later after an upgrade and you have to stare at code for a while just to figure out what its purpose is, well, that’s a problem. With iRules, comments are not compiled into byte-code, so there is no performance hit taken with their presence.    Some things you could consider for the documentation header:

Overall concept for the rule or some simple workflow

Date/Time the header was created

Revision information

External Requirements (profiles, classes, dns configurations)

LTM Platform

TMOS Version and Hotfix level the iRule was developed on

Known versions the iRule does NOT work on (and why if known)

CMP Compatibility flag

iRule performance data

This in comment format would look something like this (not all the above list included):

## GRACEFUL SSL SECURITY STRENGTH ENFORCEMENT
##
## Sends users with browsers not capable of 256-bit encryption to
## error page, forces capable browsers to higher security profile
##
## CMP compatible: Yes
##
## This rule requires:
## 1. Default clientssl profile allowing 128-bit encryption: DEFAULT:!ADH:!EXPORT40:!EXP:!LOW
## 2. Additional clientssl profile set to higher security: DEFAULT:!ADH:!EXPORT40:!EXP:!LOW:!MEDIUM
## 3. HTTP profile
## 4. Datagroup (accepted_ciphers in this example) with hex strings of 256-bit accepted ciphers:
## class accepted_ciphers {
##     "0035"
##     "c014"
## }
## # NOTE that the "" should not be added when submitting the strings in the GUI
##
## This rule developed on:
## TMOS v9.4.8 355.0
## LTM1500
##
## Note: Confirmed NOT WORKING on TMOS vBIG-IP Version 10.2.0 1707.0
##   (due to failure of eval of SSL::profile in CLIENT_DATA event)
##
## Sizing Data:
## RULE clientssl_issue
## +-> CLIENT_ACCEPTED   200 total   0 fail   0 abort
## |   |     Cycles (min, avg, max) = (0, 0, 0)
## +-> CLIENT_DATA   200 total   0 fail   0 abort
## |   |     Cycles (min, avg, max) = (439752, 491878, 3673016)
## +-> HTTP_REQUEST   200 total   0 fail   0 abort
##     |     Cycles (min, avg, max) = (0, 0, 0)
##
## NOTES: Test case: httperf --server=x.x.x.x --port=443 --uri=/ --ssl --ssl-no-reuse --num-conn=200 --rate=5

That’s incredibly useful going into a scenario where you have to troubleshoot or validate upgrades or patches to infrastructure or applications. Whereas some of that information would have to be manually generated, some of it can be auto-generated.

Automating iRule Header Information via pyControl

Looking back to the pyControl iRule Timing script I started in 2x5 Minute iRules on Timing, what if I turned the timing on/off from the script, and removed the old header (if present) and inserted a new one after testing? The first changes to the script is to add a section of code to download the iRule (via the query_rule iControl method) from the LTM and pull out any existing header information. I also am using a counter for the number of performance trials. After yanking this information from the iRule, I add timing and then re-bundle the iRule and send it back to the LTM (via the modify_rule method.)

rule_contents = rl.query_rule(rule_names = [irule])
brl = rule_contents[0].rule_definition.split('\n')
rl_ver = 1
for x in brl:
    if x[:18] == '#hdr_info: Trials:':
        rl_ver = int(x.split(' ')[2].encode('ascii')) + 1
brl = filter (lambda a: a[:10] != '#hdr_info:', brl)
brl.insert(0, u'timing on')
brl = '\n'.join(brl)
rule_contents[0].rule_definition = brl
rl.modify_rule(rules = rule_contents)

Note the " u'timing on' " insert. The list items in the iRule object are all unicode. Rather than converting to ascii to work with them, I just left the objects as unicode, so each insert utilizes the unicode designator in python. Load is then sent as before in the script and then after the stats have been calculated and displayed to console, I package the header information in a list that I then add to the existing iRule after removing timing.

rule_contents = rl.query_rule(rule_names = [irule])
brl = rule_contents[0].rule_definition.split('\n')
brl.remove(u'timing on')
irules_header = []
irules_header.append(u'#hdr_info: ### END ###')
irules_header.append(u'#hdr_info: CPU Util / request: %s' % (z*100.0/tmm_cpu_cycles))
irules_header.append(u'#hdr_info: Total Avg Cycles: %s' % z)
irules_header.append(u'#hdr_info: Target: %s' % url)
irules_header.append(u'#hdr_info: Cores: %s, Speed: %s' % (cpu_cores, cpu_num))
irules_header.append(u'#hdr_info: Platform: %s' % platform_ID)
irules_header.append(u'#hdr_info: Time: %s' % time.asctime(time.localtime(time.time())))
irules_header.append(u'#hdr_info: Trials: %s' % rl_ver)
irules_header.append(u'#hdr_info: Name: %s' % irule)
irules_header.append(u'#hdr_info: ### BEGIN ###')
for x in irules_header:
    brl.insert(0, x)
brl = '\n'.join(brl)
rule_contents[0].rule_definition = brl
rl.modify_rule(rules = rule_contents)

Finally, I pull the complete rule back down from the LTM and display to console:

rule_contents = rl.query_rule(rule_names = [irule])
print "\nFinal iRule:\n"
print rule_contents[0].rule_definition

The result of this with the full script is:

jrahm@ubuntu:~/scripts$ python2.6 is2.py 172.16.99.5 admin w3c http://172.16.100.99 200

Please enter your password:
Password:

Resetting statistics for the w3c iRule

Enabling timing and removing header information

Making 200 requests to host http://172.16.100.99

### iRule w3c Performance Results
        BIG-IP LTM Z100 has 2454400000 availabe CPU Cycles (1 cores, 3068.000 MHz)
        Average Cycles/sec:     665391
        CPU Utilization/req:    0.0271101287484 percent
        Max Requests/sec:       3688

Inserting Header in iRule and disabling timing

Final iRule:

#hdr_info: ### BEGIN ###
#hdr_info: Name: w3c
#hdr_info: Trials: 4
#hdr_info: Time: Wed Mar 9 09:16:21 2011
#hdr_info: Platform: Z100
#hdr_info: Cores: 1, Speed: 3068.000
#hdr_info: Target: http://172.16.100.99
#hdr_info: Total Avg Cycles: 665391
#hdr_info: CPU Util / request: 0.0271101287484
#hdr_info: ### END ###
when HTTP_REQUEST {
   # < CONDENSED FOR CLARITY
}

Parting Thoughts

If you wanted to incorporate some of the ideas from above that wouldn’t be fit for auto-generation (like rule concept and workflow), you could place that information immediately before your first event with a different pattern than “#hdr_info:” since the script will remove any line matching that pattern. The full script is in the iControl codeshare under pycontrol irule timing and comment header insert.

What other ideas do you have for rule documentation? Post them in the comments section below.

read more

2x5-Minute iRules - Timing

Thu, 03 Mar 2011 07:53:00 EST

Timing is a command in iRules that triggers the system to track the number of cycles each event in an iRule consumes. Deb has covered timing previously in iRules Optimization 101 – #05 – Evaluating iRule Performance, so I took that and a presentation someone internally put together from that information and recorded a walkthrough on what makes timing tick. (ba-dah, ching!)

iRule Timing Part 1

I also took the opportunity to dust off my pycontrol skills and whipped up a script that will do some load testing against a virtual with your iRule applied, then download and crunch the stats specific to your platform cores/speeds so the numbers should be accurate.

iRule Timing Part 2

I uploaded the script to the iControl codeshare, titled pycontroliRuleTiming. A sample of the output from the script is below:

jrahm@jrahm-dev:/var/tmp$ ./iRuleStats.py 10.10.20.5 admin timing_test http://10.10.20.50
Please enter your password:
Password:

Resetting Statistics for the timing_test iRule

Running load test to host http://10.10.20.50
### Raw Data ###
Event: HTTP_REQUEST
        STATISTIC_RULE_AVERAGE_CYCLES = 41767
Event: HTTP_RESPONSE
        STATISTIC_RULE_AVERAGE_CYCLES = 92363

### iRule timing_test Performance Results
        BIG-IP LTM 3600 has 3413568000 availabe CPU Cycles (2 cores, 2133.480 MHz)
        Average Cycles/sec:     134130
        CPU Utilization/req:    0.00392931970302 percent
        Max Requests/sec:       25449

Happy coding!

Related Articles

Timing iRules - DevCentral - F5 DevCentral > Community > Group ...

irule timing: how to convert Cycles to Seconds - DevCentral - F5 ...

iRules Optimization 101 - #05 - Evaluating iRule Performance ...

Time-based iRules - DevCentral - F5 DevCentral > Community > Group ...

When Optimization Techniques Fail -- Why Testing is so Important

Perfomance gain of using HTTP Classes over iRules - DevCentral ...

iRule causing ever-increasing TMM CPU utilization - DevCentral ...

iRules 101 - #06 - When > DevCentral > F5 DevCentral > Tech Tips

read more

Mitigate Java Vulnerability with iRules

Thu, 10 Feb 2011 07:15:00 EST
I got a request yesterday morning to asking if there was a way to drop HTTP requests if a certain number was referenced in the Accept-Language header. The user referenced this post on Exploring Binary. The number, 2.2250738585072012e-308, causes the Java runtime and compiler to go into an infinite loop when converting it to java_tweetsdouble-precision binary floating-point. Not good. Twitter is ablaze on the issue, and there is a good discussion thread on Hacker News as well. So how do you stop it?
read more

One Time Passwords via an SMS Gateway with BIG-IP Access Policy Manager

Tue, 08 Feb 2011 00:00:00 EST

One time passwords, or OTP, are used (as the name indicates) for a single session or transaction. The plus side is a more secure deployment, the downside is two-fold—first, most solutions involve a token system, which is costly in management, dollars, and complexity, and second, people are lousy at remembering things, so a delivery system for that OTP is necessary. The exercise in this tech tip is to employ BIG-IP APM to generate the OTP and pass it to the user via an SMS Gateway, eliminating the need for a token creating server/security appliance while reducing cost and complexity.

Getting Started

This guide was developed by F5er Per Boe utilizing the newly released BIG-IP version 10.2.1. The “-secure” option for the mcget command is new in this version and is required in one of the steps for this solution. Also, this solution uses the Clickatell SMS Gateway to deliver the OTPs. Their API is documented at http://www.clickatell.com/downloads/http/Clickatell_HTTP.pdf. Other gateway providers with a web-based API could easily be substituted. Also, there are steps at the tail end of this guide to utilize the BIG-IP’s built-in mail capabilities to email the OTP during testing in lieu of SMS. The process in delivering the OTP is shown in Figure 1.

First a request is made to the BIG-IP APM. The policy is configured to authenticate the user’s phone number in Active Directory, and if successful, generate a OTP and pass along to the SMS via the HTTP API. The user will then use the OTP to enter into the form updated by APM before allowing the user through to the server resources.

BIG-IP APM Configuration

Before configuring the policy, an access profile needs to be created, as do a couple authentication servers. First, let’s look at the authentication servers

Authentication Servers

To create servers used by BIG-IP APM, navigate to Access Policy->AAA Servers and then click create. This profile is simple, supply your domain server, domain name, and admin username and password as shown in Figure 2.

The other authentication server is for the SMS Gateway, and since it is an HTTP API we’re using, we need the HTTP type server as shown in Figure 3.

Note that the hidden form values highlighted in red will come from your Clickatell account information. Also note that the form method is GET, the form action references the Clickatell API interface, and that the match type is set to look for a specific string. The Clickatell SMS Gateway expects the following format:

https://api.clickatell.com/http/sendmsg?api_id=xxxx&user=xxxx&password=xxxx&to=xxxx&text=xxxx

Finally, successful logon detection value highlighted in red at the bottom of Figure 3 should be modified to response code returned from SMS Gateway. Now that the authentication servers are configured, let’s take a look at the access profile and create the policy.

Access Profile & Policy

Before we can create the policy, we need an access profile, shown below in Figure 4 with all default settings.

Now that that is done, we click on Edit under the Access Policy column highlighted in red in Figure 5.

The default policy is bare bones, or as some call it, empty. We’ll work our way through the objects, taking screen captures as we go and making notes as necessary. To add an object, just click the “+” sign after the Start flag. The first object we’ll add is a Logon Page as shown in Figure 6. No modifications are necessary here, so you can just click save.

Next, we’ll configure the Active Directory authentication, so we’ll add an AD Auth object. Only setting here in Figure 7 is selecting the server we created earlier.

Following the AD Auth object, we need to add an AD Query object on the AD Auth successful branch as shown in Figures 8 and 9. The server is selected in the properties tab, and then we create an expression in the branch rules tab. To create the expression, click change, and then select the Advanced tab.

The expression used in this AD Query branch rule:

expr { [mcget {session.ad.last.attr.mobile}] != "" }

Next we add an iRule Event object to the AD Query OK branch that will generate the one time password and provide logging. Figure 10 Shows the iRule Event object configuration.

The iRule referenced by this event is below. The logging is there for troubleshooting purposes, and should probably be disabled in production.

when ACCESS_POLICY_AGENT_EVENT {

expr srand([clock clicks])

set otp [string range ]format "%08d" [expr int(rand() * 1e9)][ 1 6 ]

set mail [ACCESS::session data get "session.ad.last.attr.mail"]

set mobile [ACCESS::session data get "session.ad.last.attr.mobile"]

set logstring mail,$mail,otp,$otp,mobile,$mobile

ACCESS::session data set session.user.otp.pw $otp

ACCESS::session data set session.user.otp.log $logstring

ACCESS::session data set session.user.otp.username [ACCESS::session data get "session.logon.last.username"]

ACCESS::session data set session.logon.last.username [ACCESS::session data get "session.ad.last.attr.mobile"]

log local0.alert "Event [ACCESS::policy agent_id] Log $logstring"

}

when ACCESS_POLICY_COMPLETED {

log local0.alert "Result: [ACCESS::policy result]"

}

On the fallback path of the AD Query object, add a Message Box object as shown in Figure 11 to alert the user if no mobile number is configured in Active Directory.

On the fallback path of the Event OTP object, we need to add the HTTP Auth object. This is where the SMS Gateway we configured in the authentication server is referenced. It is shown in Figure 12.

On the fallback path of the HTTP Auth object, we need to add a Message Box as shown in Figure 13 to communicate the error to the client.

On the Successful branch of the HTTP Auth object, we need to add a Variable Assign object to store the username. A simple expression and a unique name for this variable object is all that is changed. This is shown in Figure 14.

On the fallback branch of the Username Variable Assign object, we’ll configure the OTP Logon page, which requires a Logon Page object (shown in Figure 15). I haven’t mentioned it yet, but the name field of all these objects isn’t a required change, but adding information specific to the object helps with readability. On this form, only one entry field is required, the one time password, so the second password field (enabled by default) is set to none and the initial username field is changed to password. The Input field below is changed to reflect the type of logon to better queue the user.

Finally, we’ll finish off with an Empty Action object where we’ll insert an expression to verify the OTP. The name is configured in properties and the expression in the branch rules, as shown in Figures 16 and 17. Again, you’ll want to click advanced on the branch rules to enter the expression.

The expression used in the branch rules above is:

expr { [mcget {session.user.otp.pw}] == [mcget -secure {session.logon.last.otp}] }

Note again that the –secure option is only available in version 10.2.1 forward. Now that we’re done adding objects to the policy, one final step is to click on the Deny following the OK branch of the OTP Verify Empty Action object and change it from Deny to Allow. Figure 18 shows how it should look in the visual policy editor window.

Now that the policy is completed, we can attach the access profile to the virtual server and test it out, as can be seen in Figures 19 and 20 below.

Email Option

If during testing you’d rather send emails than utilize the SMS Gateway, then configure your BIG-IP for mail support (Solution 3664), keep the Logging object, lose the HTTP Auth object, and configure the system with this script to listen for the messages sent to /var/log/ltm from the configured Logging object:

#!/bin/bash
while true
do
   tail -n0 -f /var/log/ltm | while read line
   do
      var2=`echo $line | grep otp | awk -F'[,]' '{ print $2 }'`
      var3=`echo $line | grep otp | awk -F'[,]' '{ print $3 }'`
      var4=`echo $line | grep otp | awk -F'[,]' '{ print $4 }'`
      if [ "$var3" = "otp" -a -n "$var4" ]; then
        echo Sending pin $var4 to $var2
        echo One Time Password is $var4 | mail -s $var4 $var2
      fi
   done
done

The log messages look like this:

Jan 26 13:37:24 local/bigip1 notice apd[4118]: 01490113:5: b94f603a: session.user.otp.log is mail,user1@home.local,otp,609819,mobile,12345678

The output from the script as configured looks like this:

[root@bigip1:Active] config # ./otp_mail.sh
Sending pin 239272 to user1@home.local

Conclusion

The BIG-IP APM is an incredibly powerful tool to add to the LTM toolbox. Whether using the mail system or an SMS gateway, you can take a bite out of your infrastructure complexity by using this solution to eliminate the need for a token management service. Many thanks again to F5er Per Boe for this excellent solution!

read more

iRules HTTP Event Order Update

Tue, 01 Feb 2011 11:18:58 EST

I received an update to the HTTP Event Order diagram last night from the excellent F5er John Alam. Here it is, in all its glory!

Fire up the printer, the laminator, whatever, and get this on your cubicle wall pronto! For comparison, the original drawing is in the second link below. For visio, pdf, and svg versions of this image, click here.

Related Articles

iRules Event Order > DevCentral > F5 DevCentral > Tech Tips

iRules Insight - HTTP Event Order

Stacking iRules: A Modular Approach > DevCentral > F5 DevCentral ...

HTTP::payload replace with MORE data? - DevCentral - F5 DevCentral ...

Technorati Tags: F5 DevCentral,iRules,HTTP,Jason Rahm,John Alam
read more

BIG-IP Configuration Visualizer - iControl Style

Tue, 25 Jan 2011 05:01:00 EST

I posted almost two years ago to the day on a cool tool called BIG-IP Config Visualizer, or BCV, that one of our field engineers put together that utilizes a BIG-IP config parser and GraphViz to create images visualizing the relationship of configuration objects for a particular virtual server. Well, I’m here to report that another community user, Russell Moore, has taken that work to the next level. Rather than trying to figure out the nuances of configuration objects amongst all the versions of BIG-IP, he converted the script to utilize iControl! In this tech tip, I’ll walk through the installation steps necessary to get this tool off the ground.

The Setup

Install a few libraries and GraphViz via apt-get

apt-get install libssl-dev libcrypt-ssleay-perl libio-socket-ssl-perl libgraph-writer-graphviz-perl

Open a CPAN shell and install SOAP::Lite and Net::Netmask

perl –MCPAN –e shell

install SOAP::Lite

install Net::Netmask

After installing those libraries and tools, grab the BCV-iControl source from the codeshare, save it as an executable (bcv.pl on my system) and set these variables (I only changed the ones in bold type):

#Declare CLI $vars
my $vs1;
my $new_dir   = 'NO_DIR';
my $extension = 'NO_EXT';
my $ltm_host = "172.16.99.5";
my $ltm_port = '443';
my $user_id = "admin";
my $req_partition;
my $user_password = "admin";
my $ltm_protocol = 'https';
my $path;
my $dir;

Finally, some command-line options:

root@ubuntu:/home/jrahm# ./bcv.pl -h
Thank you for using BIG-IP Configuration Visualizer (BCV 1.16.1-revisited with soap)
-v <VS_NAME> this prints the specified virtual server and requires option -c.
     Default is to print all

-c Specify the partition/container to look in for option -v

-t <iControl host LTM> specify ltm_host IP we will connect to

-d specifies a directory you want the images in.
      Has to be in Current working Directory:
      /home/jrahm
      Default is /img)

-e Define image format options: svg, png (default is jpg)

-help for help but you already found it

The Payoff

Now that all the legwork is complete, we can play!

root@ubuntu:/home/jrahm# ./bcv.pl

Please wait while we build some maps of your system.
Retrieving SelfIPs in Partition: ** Common **
Mapping Partition: ** Common ** routes to gateways
Mapping Partition: ** Common ** selfIPs and VLANs..
Mapping Partition: ** Common ** pools and iRule references to pools............
Mapping Partition: ** Common ** virtual servers and properties...
Drawing VS: dc.hashtest which is 1 of 3 in Partition: Common
Drawing VS: testvip1 which is 2 of 3 in Partition: Common
Drawing VS: management_vip which is 3 of 3 in Partition: Common

All drawings completed! They can be found in:
/home/jrahm/img

Taking a look at the virtual server I used for the hashing algorithm distribution tech tip:

Conclusion

Visual representations of configurations are incredibly helpful in identifying issues quickly. An interesting next step would be to track state of objects from iteration of the drawings, and build a page to include all the images. That would make a nice and cheap dashboard for application owners or operating centers. Any takers? Thanks to community user Russell Moore that took a great contributed tool and made it better with iControl!

Technorati Tags: f5 DevCentral,iControl,GraphViz,Perl,BIG-IP,LTM,Jason Rahm,Russell Moore

read more

Revisiting Hash Load Balancing and Persistence on BIG-IP LTM

Fri, 21 Jan 2011 06:14:00 EST

A good while back (Dec ‘07!), Deb wrote up hash load balancing in six pages of goodness. She made some really good points in her introduction that bear repeating:

Load balancing of cache and proxy servers has long been a standard task for F5's BIG-IP LTM. However, cache and proxies have unique requirements over other types of applications. It's not realistically possible to cache an entire site, let alone the Internet, on a single cache device. The solution is to intelligently load balance requests and 'persist' them to a specific cache not based on who the client is, but based on the content requested. In a forward proxy example, all requests for site1.com would go to cache1 while all requests for site2.com go to cache2. Since each cache gets all the requests for their respective sites, they will have the most up to date version of the content cached. This also allows the caches to scale more efficiently as each would only need to cache N percent of the possible destination content. In BIG-IP LTM nomenclature, adding more members (nodes or servers) to the pool reduces the percent of content such as URIs that any cache server needs to store.

The point of this article is not to rewrite Deb’s excellent work, so please go read that article first. Back? Great…let’s move on. In my previous article, Fun with Hash Performance, I tested each of the hashing algorithms (minus the persist carp function), pushing fifty-thousand executions of the hash and timing it for comparison. This time, I’d like to take a look at how each of the hashes distributes the traffic amongst different pool sizes and with two different numbers of unique URLs. In the event you are priming cache arrays, or merely want to use all the resources you allocate to an application, using a hash gives you a deterministic way to plan. However, not all hashes are created equal in this regard, and I know a little (very little) on how they work in general, but have never seen any testing to prove out exactly how they behave with load balancing. Knowing how they react to your application and how they perform arms you, the technician, with another tool in the toolbox when it comes time to architect a solution. The goal here is to chart the standard deviation for each of the hashes. The lower the standard deviation, the more evenly distributed the connections/content would be. We'll get to the charts later on, however. Let's start with the test cases, which can be seen in Table 1.

Table 1 - Hashing Algorithm Tests

Test Case # Pool Members Unique URLs

1 3 2000

2 3 5000

3 4 2000

4 4 5000

5 8 2000

6 8 5000

7 16 2000

8 16 5000

9 32 2000

10 32 5000

Generating the Unique URLs

I don’t have five-thousand, or even two-thousand unique URLs laying around, so I’ll need to generate them. I need each of them in two formats as well. When I began testing, my intention was to run every request from a class through an iRule loop, and for all but one of the hashes that’s still true. For the built-in carp persistence, however, I couldn’t figure a way to grab the data without a pool member connection, so I added another LTM to serve as pool members and used curl to request the URLs. It was important for consistency, so I used this python code to generate the random string and save the list as a file of complete URLs for curl and a list of URIs for the class:

#!/usr/bin/python
import sys, os, random, string

num = int(sys.argv[1])
classfile = "/home/jrahm/randomURLs_%s" % num
urlfile = "/home/jrahm/urllist_%s.txt" % num

c = open(classfile, 'w')
u = open(urlfile, 'w')

for x in range(1, num+1):
    y="".join(random.choice(string.letters) for i in xrange(random.randrange(3,15,1))) + "/image%s.jpg" % x
    c.write(y+ "\n")
    u.write("http://172.16.101.50/" + y + "\n")

Configuring the Test Environment

For most of the hashes, I just needed an LTM and a browser. For the carp testing, I needed another LTM and a client to loop through the unique URLs. With LTM VE and a laptop with 8G of RAM, I was able to set up the entire environment virtually, as shown below.

LTM1 is doing the heavy lifting. A single virtual server (172.16.101.50) is configured with one of several pools, each with a specific number of pool members (shown in the pool name in the image above). These pools were configured in tmsh with the aptly named create_pool.tcl script from the wiki. The pool members are actually virtual servers hosted on LTM 2. I created those virtuals with a new tmsh script based on the create_pool.tcl script called, shockingly, create_virtuals.tcl, which I added to the tmsh wiki under CreateLTMVirtuals. Yea, tmsh!

The iRule I used for these virtual servers is very short, and used just to respond to queries passed on by LTM 1:

1: when HTTP_REQUEST {

2: HTTP::respond 200 content "<html><body>[LB::server addr]</body></html>"

3: }

The Test iRule

I’m utilizing tables to store the hash results/pool hit counts, once the urls are processed, I lookup the data in the table, store it in a variable, then delete the table. The carp urls are coming from a client, the rest of the hashing algorithms are processed internally to the iRule (shown below). As I worked through the test cases, only things I changed were the class name (random_urls_2k or random_urls_5k) and the pool name. For the carp test preceding the /hashtest step, I also changed the default pool on the virtual to match the iRule. I could have automated all this to death, but chose expediency on some things.

1: when HTTP_REQUEST {

2: set uri [HTTP::uri]

3: persist carp $uri

4: if { $uri eq "/hashtest" } {

5: foreach hash [list "md5" "crc32" "sha1" "sha256" "sha384" "sha512"] {

6: set clen [class size random_urls_2k]

7: for { set x 0 } {$x < $clen} { incr x } {

8: binary scan [$hash ]class element -name $x random_urls_2k[] w1 hashval

9: set hashval [expr {$hashval % ]active_members hashpool_3[}]

10: if { [table incr -subtable $hash -mustexist pm$hashval] eq ""} {

11: table set -subtable $hash pm$hashval 1 indefinite indefinite

12: }

13: }

14: foreach pm [table keys -subtable $hash] {

15: append hash_$hash "[table lookup -subtable $hash $pm], "

16: }

17: table delete -subtable $hash -all

18: }

19: foreach pm [table keys -subtable carp] {

20: append hash_carp "[table lookup -subtable carp $pm], "

21: }

22: table delete -subtable carp -all

23: HTTP::respond 200 content "<html><body>crc32:$hash_crc32<br>md5:$hash_md5<br>\

24: sha1:$hash_sha1<br>sha256:$hash_sha256<br>sha384:$hash_sha384<br>\

25: sha512:$hash_sha512<br>carp:$hash_carp</body></html>"

26: }

27: }

28: when HTTP_REQUEST_SEND {

29: if { $uri ne "/hashtest" } {

30: set psel [getfield ]LB::server addr[ "." 4][

31: if { ]table incr -subtable carp -mustexist pm$psel[ eq ""} {

32: table set -subtable carp pm$psel 1 indefinite indefinite

33: }

34: }

35: }

Because I couldn’t test carp in the same was as the other hashes, each test case is a two step process. First, I hit the LTM 1 virtual server from my Ubuntu client with this command, referencing the urllist built earlier:

xargs curl –I < /home/jrahm/urlllist_2000.txt

Once that completes, I hit the virtual directly with this command, which returns the data shown immediately below the command:

curl http://172.16.101.50/hashtest
<html><body>crc32:655, 682, 663, <br>md5:634, 653, 713, <br>
            sha1:684, 655, 661, <br>sha256:669, 714, 617, <br>
            sha384:689, 635, 676, <br>sha512:634, 684, 682, <br>
            carp:671, 642, 646, </body></html>

That gives me the data I need to move on and calculate and graph the standard deviation for test case 1. After going through each test case, I have results for each of the hashes for each of the urllist lengths, which I set arbitrarily at 2000 and 5000.

The Graphs

The data (and more graphs) are available if you want to manipulate and graph a different way. I broke down the data and each of the graphs below represent a single hash and it’s standard deviation given the number of unique URLs and the number of members in the pool. Note that for CRC32, the max pool members with connections was always ten, so for a 16 member pool, six members had no connection at all. I wasn’t entirely sure how to handle this in the calculations, so I just entered zeroes for the remaining pool members. But that said, you surely will not want to use CRC32 as a load balancing/persistence algorithm in pools larger than three. In case it's not apparent, the x-axis is number of pool members (shown as mbr), and the y-axis is the value of the standard deviation. As alluded to earlier, a lower standard deviation is more desirable if you want an even distribution of your content (in a caching scenario, or connections elsewise).

It’s interesting data, isn’t it? All the cryptographic hashes largely perform better distributions with more targets. Keep all this in context, though. Remember that SHA384/SHA512 was six times longer in processing than the CRC32, and double MD5/SHA1. Finding the sweet spot between algorithm/distribution will come down to available resources, business requirements, or both.

Conclusion

Advanced load balancing and persistence with hashing algorithms offers a great deal of benefit, but great care should be exercised in testing and knowing your environment.

]
read more

An Homage to LTM

Thu, 06 Jan 2011 11:35:51 EST

Sad, I know. But I had Shakespeare on the brain this morning, and whereas I’m pretty sure he’ll roll over in his grave at me identifying with him in the same blog post as what’s below, well, I figured I’d tap into my (not so) creative side.

An Homage to LTM

Gather my packets, LTM
And give to all comprising flows
Careful analysis on which to
Accept or deny my humble requests.

The lower layers thou swiftly removes,
The heart of my request reveals
A simple GET or two or fifty.
Carest thou doesn't; an effortless task.

Wherest shall thou dispatch my requests?
Is thy Master's TCL'd iRules logic sound?
HTTP_REQUEST doctors my solicitation and
Relinquishes its firm grip--sweet release!

Alright, DevCentralites…flame away!

Technorati Tags: F5 DevCentral,LTM,Jason Rahm
read more

F5 BIG-IP LTM Image Hosting–Redeux!

Fri, 12 Nov 2010 11:52:48 EST

We’ve covered pushing images from LTM before with Kirk’s excellent perl script work on sorry pages. But that’s not the only thing you can host images for, and it’s not the only approach. DevCentral community user kevin.stewart crafted up a nifty bash script to achieve the same ends, and gobbles up every image in /var/images, b64 encodes them, then drops them into a class. The script is minimal in lines, but powerful in output:

#!/bin/bash

## clear /var/class_build/images_build.class
echo -n "" > /var/class/images.class;

## loop through real images and create base64 data for images_build.class
for i in $(ls /var/images); do
echo \"`echo $i |tr '[:upper:]' '[:lower:]'`\" := \"`base64 /var/images/$i |tr -d '\n'`\", >> /var/class/images.class;
done

This results in a class with lines that look like this:

"favicon.ico" := "iVBORw0KGgoAAAANSUhEUgAAAJ8AAACfC…”

Create the class in the GUI, then the iRule is pretty simple as well:

when RULE_INIT {
## define the class names
set static::IMAGES_CLASS “images.class”
}
when HTTP_REQUEST {
## is the request an image? Process images from the base64 encoded image class
if { [string tolower [HTTP::path]] ends_with “.jpg” or [string tolower [HTTP::path]] ends_with “.png” \
    or [string tolower [HTTP::path]] ends_with “.gif” } {
      ## assume image name is after the last forward slash character in the URI
      if { [class match [string range [HTTP::uri] [expr [string last “/” [HTTP::uri]] + 1] end] equals $static::IMAGES_CLASS] } {
        HTTP::respond 200 content [b64decode [class lookup [string range [HTTP::uri] [expr [string last “/” [HTTP::uri]] + 1] end] $static::IMAGES_CLASS]] \
          “Content-Type” “image/png” “Last-Modified” “Sun, 29 Mar 1970 18:53:56 GMT”
      }
}
}

Pretty powerful stuff, huh? Note you’ll need v10 for this implementation, it could, however, be rewritten for v9. Full write-up is in the codeshare: http://devcentral.f5.com/wiki/default.aspx/iRules/LTMImageHosting.html
Related Articles

Host that Sorry Page on your BIG-IP!

about i-rule sorry page configuration - DevCentral - F5 DevCentral ...

DevCentral Wiki: Sorry Page I Rule Generator_ Perl

DevCentral Wiki: Automatic_maintenance_page___ Sorry_page_with_images

Technorati Tags: F5 DevCentral,iRules,Jason Rahm
read more

2048-bit Infrastructure Impact Reporting Tool

Mon, 04 Oct 2010 13:20:46 EDT

A few weeks ago Lori nailed it with a post (The 2048-bit Keys to the Kingdom) on the coming forced migration to 2048-bit keys. A few days prior, I got a call from “THE” Matt Cauthorn, DevCentral resident stud contributor L4L7 about the very same issue. Not surprisingly, he was ahead of the game on this and has spent some time developing a tool that will take the mystery out of the licensing and infrastructure impact checklist items Lori mentioned. Well what does this tool do?

Function

Generates a high-level report in pdf format on what 2048-bit keys will do to your infrastructure

Graphs the last seven days of TPS data by default (you can also run against 24 hour and 30 day data as well)

Highlight any platforms in your infrastructure that might be improperly sized for 2048-bit keys under existing loads

Details

Fetches some graph data, the license file, the platform ID, the TMOS version, and general system information. These are all read-only calls.

Assumptions

Using 1024-bit keys today. This may not be true for you. If you’re using 2048-bit keys, the report will still generate useful information

To estimate your maximum platform TPS, the tool simply takes the maximum 1024-bit TPS for your platforms and reports 20% of that value. Note that this is maximum platform TPS, not maximum licensed TPS.

Requirements

If you haven’t taken the time to configure your environment for pyControl, you’ll need to do so to use this tool. There are installation tutorials for Windows and Ubuntu. Here are the packages you’ll need:

Python 2.5, 2.6, or 2.7 (avoid 2.6 if you can)

Setuptools

Suds (Grab the GA version, which is currently 0.4)

pyControl

Reportlab (I grabbed the latest daily windows installer)

These details and the reporting tool itself are ready for you here in the iControl codeshare. Enjoy!
Related Articles

WILS: SSL TPS versus HTTP TPS over SSL

SSL TPS license - DevCentral - F5 DevCentral > Community > Group ...

SSL transaction (TPS) rate limit reached - DevCentral - F5 ...

Data Center Feng Shui: SSL

F5 Friday: The 2048-bit Keys to the Kingdom

Experimenting with pyControl on LTM VE > DevCentral > F5 ...

Getting Started with pyControl v2: Installing on Windows ...

Getting Started with pyControl v2: Installing on Ubuntu Desktop ...

Does pycontrol work in Linux? - DevCentral - F5 DevCentral ...

pyControl v2.0 - DevCentral - F5 DevCentral > Forums - Social ...

Technorati Tags: F5 DevCentral,SSL TPS,2048-bit,pyControl,iControl,reportlab,suds,python,Matt Cauthorn,Jason Rahm
read more

Name	Expression
Lockout user	expr { [mcget {session.custom.badpwdcount}] >= [mcget {session.custom.lockout}] }
Can allow through	expr { [mcget {session.custom.badpwdcount}] < [mcget {session.custom.lockout}] }

Table 1 - Hashing Algorithm Tests
Test Case #	Pool Members	Unique URLs
1	3	2000
2	3	5000
3	4	2000
4	4	5000
5	8	2000
6	8	5000
7	16	2000
8	16	5000
9	32	2000
10	32	5000

Latest News from Jason Rahm

Come Join DevCentral for the Seattle DotNetNuke User Group Meeting

Agenda

Juice-Jacking Revisited

Managing Ramcache Entries with Pycontrol

The Interface

Preparing the BIG-IP

Building the Script

Conclusion

v11.1: DNS Blackhole with iRules

Conceptual Overview

Building the Datagroup

Intercepting the DNS Requests

Serving the Remediation Page

The Results

And finally, the log entry from the HTTP request:

Conclusion

v11.1–Add Signatures or Checksums to iRules via an iApp

Building the iApp

DNS Services Architecture

v11.1–External File Access from iRules via iFiles

Planning the Maintenance Page

Creating the iFiles

The iFile Command Syntax

Creating the iRule

Conclusion

BIG-IP Configuration Object Naming Conventions

Your Turn

Stop that F5 Key From Refreshing the Page

The Question

The Solution

v11: iRules Data Group Updates

Address Data Groups

Integer Data Groups

String Data Groups

iRule::ology–SMTP Start TLS

The iRule

BSidesMO Wrap-up

The Evolution of Malware – Chris Quinn

Make the World Go Away – Beth Young

Web Exploitation Trends – Larry Battle

v11: RDP Access via BIG-IP APM–Part 3

Add an iRule Event

Customize RDP Hostname

Testing the Changes

Conclusion

v11: RDP Access via BIG-IP APM–Part 2

Modify the Access Policy

Modify the RDP Resource

Optional Customization

Testing the Changes

Conclusion

v11: RDP Access via BIG-IP APM–Part 1

Create the Webtop

Create the RDP Resource

Create the Access Policy

Testing the Configuration

Conclusion

Create a User Lockout Policy with Access Policy Manager

About the Author

Preventing Brute Force Password Guessing Attacks with APM–Part 4

Introduction

Locking Out Users After Failed Logon Attempts

Policy Additions

Macro: AD Auth & iRule

Macro: Captcha Auth with AD Auth

Macro: Verify with Captcha Page

Macro: iRule Lookups and Auth

Access Policy: CaptchaProj_4

The Final iRule

Final Notes

About the Author

Scheduling BIG-IP Configuration Backups via the GUI with an iApp

The Problem

The Solution

iAppTM Components

Presentation

Implementation

Conclusion

Preventing Brute Force Password Guessing Attacks with APM–Part 3

iApp^TM Components