DevCentral Top 5 01/06/2012

The holidays have passed, the new year is upon us and there is much geeky goodness to be thankful for. I am thankful for the forums and the wikis, the tech tips and blogs. I am thankful for the outstanding community that drives it all, and the supporting cast of hundreds within F5 that helps support this DevCentral thing we get to do. I am so thankful, in fact, that I am here to share five of my favorite recent DevCentral additions with you. Hurried over the holidays? Nagged after the new year? Fall behind on your feeds? Never fear, I'm more than happy to give you my Top5 picks from past weeks to give you a place to start. Keep in mind there will always be more goodness on DevCentral than anyone could pack into a single missive, even someone as wordy as me, so be sure to get out there and check it out for yourselves. For now, though, here is my first DevCentral Top 5 of 2012:

$DevCentral +=  1;

http://bit.ly/yNw8zs

We've grown! The team has gained a new face, a new name, and some wicked security chops. Josh joined the team before the holiday season and has been cranking away largely in secret since. His focus has been and will continue to be security. He'll be answering forums, checking in from conferences, keeping you abreast of the most twisted, brutal and/or interesting vulnerabilities out in the wild, hopefully with a means to fix them, and more. Part of said "more" will be contributing to the ever growing content engine that is DevCentral. He has already started, in fact! Check out this latest blog of his wherein he discuses the new(ish) slowread vulnerability along with a helpful fix from F5. He assures me there is more to discuss regarding this vuln, and having gotten to know him a bit I have no doubt this is just one of many helpful, timely, security centric posts to come. Add him to your feeds, drop a note and say hi, and check back often to see what security science Josh is dropping next.

Two-Factor Auth with Google Authenticator and LDAP

http://bit.ly/yO8G6a

Speaking of science, I feel it is a crime that George was not gifted a lab coat and appropriately mad scientist-esque safety goggles over the holidays. He has upped the iRules Tech Tip game to a level that Jason and I agree is both awesome, and inspiring. In this article George documents how to turn your LTM and the inherent beauty within known as iRules into a two-factor auth system, integrated with LDAP, by way of Google Authenticator. In simpler terms: you can scan a QR code, enter a time based secure token, and authenticate into your systems...all via an iRule. That is the very definition of iRules science, kids. I've been raving about this one for weeks, and likely will for weeks to come. So before you hear me tell you again later, go check it out. Not only is the concept outstanding, but the write-up is second to none, so don't be dissuaded by the double black diamond sounding description. George turns this one into a bunny slope compared to what it could be if you tried to tackle it alone.

External File Access from iRules via iFiles

http://bit.ly/ArfZS6

There is a new tool in iRules town, and it's known as iFiles. Jason does an excellent job writing up this powerful, exciting new feature that was released for iRules in version 11.1. iFiles allow you to, as you might imagine, access files on the file system from within your iRules. This has been a popular request for years now, but there are inherent security and performance issues with giving out file system access to the LTM, something the PD crew here at F5 is understandably hesitant about. They have, however, cracked that proverbial nut and provided us with a solution that is both fast and secure. If you want the details on how it works you'll have to go read Jason's article, which you should do anyway because it rocks. Between v11 and v11.1, the iRules landscape continues to grow and become more hawesome by the version. I'm eager to see what comes next. Until then, though...go learn about iFiles. They rock.

The Three Axioms of Application Delivery

http://bit.ly/Av5oPf

Lori took on what I have often thought an unenviable task: defining Application Delivery. This is more slippery than it sounds as the landscape is constantly changing with new technologies, application concerns and demands, security liabilities and more. Trying to specifically define exactly what one means when using the term "Application Delivery" has proved foolhardy before, and as such Lori's approach is one that appeals to me greatly. Namely, she decided not to define it directly, but instead laid out three axioms that describe the bedrock upon which the term lives and breathes, changing as it is apt to do, based on the needs and solutions of the times. Application Centric, Operational Risk Mitigating, Contextual. Those are effectively the concepts that are conveyed as the root of all things Application Delivery. Of course, many more juicy details and descriptions are a click away. Go see what you think. Do you agree? How would you define it, if you could?

iRules Concepts: Connection States and Command Suspension

http://bit.ly/wxY5f3

The iRules Concepts series is something I started a couple of months back in order to address some of the more esoteric functionality within iRules. Not everything fits so squarely into a command namespace or man page. Things such as command suspension and connection states within TMM warrant a bit more conversation and explanation. Given that I have seen this question come up multiple times in recent months, it seemed time to delve more deeply into the inner workings and shed some light on just what we're talking about when we use these terms. If you're an iRules geek like me, or frankly if you're curious about how F5 gear does what it does, I believe this is an interesting look at a tiny slice  of that picture. If you have questions about how other things within iRules work, this would be a great place to ask. I'm really enjoying discussing the nuts and bolts of how this awesome technology does its thing, and am always keen on taking requests for future articles.

There you have it, five ways to spend some time learning about what has been happening on DevCentral. For more frequent updates make sure you're registered and signed up for some of our many groups and feeds.

20 Lines or Less #52: Handshakes, Dynamic IPs, and Destinations

What could you do with your code in 20 Lines or Less? That's the question I ask (sometimes?) every week for the DevCentral community, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

This week nitass and hoolio deliver the 1-2-3 punch with 3 cool iRules to perform various tasks that I deem useful, or interesting, or...both. We get a look at dealing with destination servers with a dynamic IP, handling SSL and non SSL connections on the same VIP to proxy both seamlessly, and selecting a hostname based on destination. No, that isn't backwards, you heard that right. Hostname based on destination, not destination based on hostname. Just the kind of fun stuff I love looking at! So let's get to it.

CLIENTSSL_HANDSHAKE without a client SSL profile

http://bit.ly/yYqGcW

We've seen a similar take before, but this is a new look and a good one, courtesy of hoolio. If you're looking to process HTTP and HTTPS traffic on the same VIP, this iRule will get you there. Keep in mind that it's using a couple of tricks. One is hiding the SSL::cipher command within an eval, and the other is using the catch command to prevent the iRule from dumping the connection based on a TCL error in non SSL cases. While this works, it's good to know that this is using a bit of wizardry to achieve the goal. At some point in the future there may well be a more straight-forward way to do this.

   1: when HTTP_REQUEST {

   2:  

   3:    # Hide the SSL:: command from the iRule parser

   4:    # so the iRule can be used on a non-client SSL VS

   5:    set cipher_cmd "SSL::cipher version"

   6:  

   7:    # Check if the client used an SSL cipher and it's not "none"

   8:    if {not ([catch {eval $cipher_cmd} result]) && $result ne "none"}{

   9:       # Client did use a cipher

  10:       set proto "https"

  11:    } else {

  12:       # Client did not use a cipher

  13:       set proto "http"

  14:    }

  15: }

Node with dynamic IP

http://bit.ly/xisrlX

In this cool example nitass solves the problem of a destination server with a dynamic IP address, and how to route to it. Most people tend to think about dynamic addresses always being on the front end, with back-end resources being static and dependable. That is, of course, not always the case. Given iRules and the power therein however, that is hardly a problem. A quick RESOLV::lookup and you're able to route traffic easily to the appropriate resource. A cool look at using simple, built-in commands in inventive ways to solve problems that could be head scratchers otherwise.

   1: when HTTP_REQUEST {

   2:      set dest [RESOLV::lookup @8.8.8.8 -a "www.google.com"]

   3:      log local0. "\[RESOLV::lookup @8.8.8.8 -a \"www.google.com\"\]: $dest"

   4:      log local0. "\[getfield $dest \" \" 1\]: [getfield $dest " " 1]"

   5:      node [getfield $dest " " 1] 80

   6: }

   7:  

   8: when HTTP_RESPONSE {

   9:      log local0. "[IP::client_addr]:[TCP::client_port] -> [IP::remote_addr]:[TCP::remote_port]"

  10: }

Destination based hostnames

http://bit.ly/ysuN4R

In another example that is actually quite simple and elegant in code, but made me stop and do a triple take because it just sounds so wrong, logically, nitass shows us destination based hostname modification. Hostname based destination modification is amazingly commonplace. We've seen and done that a thousand times. Perhaps it is because of that very prevalence that this feels so backwards, and took me a few seconds to allow my brain to logically process it. Regardless, this is a darn cool example and this would be extremely hard to do anywhere else without redirects and other tom-foolery. Fun stuff!

   1: when LB_SELECTED {

   2:        if {[HTTP::host] equals "xxx.com"} {

   3:                 switch [LB::server addr] {

   4:                         "200.200.200.101" { HTTP::header replace Host "yyy.com" }

   5:                         "200.200.200.102" { HTTP::header replace Host "zzz.com" }

   6:                 }

   7:         }

   8: }

There are your three iRules for the week that can go into the "in case of monotony, read me" bin. iRules, as a technology, continues to impress me, as does the community and the differing ways in which you all come up with to put this stuff to work. Keep it up, and we'll get this series to 100 in no time.

#Colin

20 Lines or Less #51: Domain blocking, Geo redirection and Math!

What could you do with your code in 20 Lines or Less? That's the question I ask (sometimes?) every week for the DevCentral community, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

This week I'm digging through my list of cool threads from the past month or so and picking out a few that I think are interesting. More to follow, but we're starting with a cool little geolocation redirection rule that will allow you to direct people from different countries (or states) to different URLs, a nifty domain blocking rule to help thwart would be defamers with derogatory subdomains, and some math in iRules...because well, George is a math geek, and so am I. This is a heck of a variety this week, so buckle up for some fun code.

iRule Redirect via Geolocation

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/2156858/showtab/groupforums/Default.aspx

This example shows off just how easy it is to do geolocation look ups in iRules. The user was looking for a way to redirect people to different URLs based on their geographical location. At first it was thought that a CDN would make it necessary to read the XFF header, but it turned out not to be the case. Regardless, this same idea would work either way, assuming you can trust the XFF header (which...you often can't).

   1: when HTTP_REQUEST {

   2:  

   3:     # Parse the client IP from the CDN header

   4:     set client_ip [HTTP::header value "Client-IP"]

   5:     if { $client_ip eq "" }{

   6:         # The header was empty/did not exist, so use the actual client IP

   7:         set client_ip [IP::client_addr]

   8:     }

   9:     switch [whereis $client_ip abbrev] {

  10:         "MO" -

  11:         "IL" {

  12:             # Do nothing and allow the request

  13:         }

  14:         default {

  15:             # Redirect all others

  16:             HTTP::redirect "http://www.example.com/

  17:         }

  18:     }

  19: }

Block Domain Redirect

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/2156835/showtab/groupforums/Default.aspx

Chiming in to help a user who was trying to prevent users from encounter a defamation page under a derogatory subdomain, George chimed in with some relatively simple code he and I poked at a little bit. He made it all fancy with a static::debug variable even, because George is fancy. We were tossing ideas back and forth about how to make the set base_domain section as efficient as possible. If you have thoughts on improving it, chime in!

   1: ltm data-group internal /Common/domain_blacklist { 

   2:   records {

   3:     anotherbaddomain.com { }

   4:     somebaddomain.com { }

   5:   }

   6:   type string 

   7: } 

   8:  

   9: ltm rule /Common/http_domain_blacklist {

  10:   when RULE_INIT { 

  11:      set static::domain_blacklist_dg "domain_blacklist"

  12:      set static::debug 1 

  13:   }

  14:  

  15:   when HTTP_REQUEST { 

  16:     # grab the base domain (top level plus subdomain) from HTTP::host 

  17:     set base_domain [join [lrange [split [HTTP::host] .] end-1 end] .] 

  18:  

  19:     if { [class search $static::domain_blacklist_dg equals $base_domain] } { 

  20:       if { $static::debug > 0 } { log local0. "[IP::remote_addr] attempted to access a blacklisted_domain: $base_domain" } 

  21:       # send a TCP reset

  22:        reject

  23:     }

  24:   } 

  25: }

iRule Math - Square Root

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/2158736/showtab/groupforums/Default.aspx

And now something for fun, because math is fun kids. George, feeling his geek cred at risk after someone accused him of being "just one of those marketing folks" decided that he would write his very own square root function in iRules. No part of that story is true, but he DID write a square root function in iRules to answer a user's question in the forums, and I think that's dang cool of him. Will I ever use square roots in an iRule? I have no idea. Do I love the fact that this got written? You bet your curly braces I do.

   1: when HTTP_REQUEST {

   2:   set input [URI::query [HTTP::uri] "input"]

   3:  

   4:   if { ([HTTP::path] equals "/sqrt") && ($input ne "") } {

   5:     if { $input == 0 } {

   6:       set sqrt 0

   7:     } else {

   8:       set x [expr {abs($input)}]

   9:  

  10:       while { 1 } {

  11:         set y [expr (($x+($input/$x))/2)]

  12:         if { [expr (abs($x-$y))] < 0.01 } break

  13:         set x $y

  14:       }

  15:  

  16:       set sqrt $y

  17:     }

  18:  

  19:     HTTP::respond 200 content "The square root of $input is $sqrt"

  20:   }

  21: }

There you have it, three more examples of iRules grandeur in less than 21 lines of code a piece. This language is just getting more and more powerful, flexible and accessible with the improvements being made in each version. Keep an eye out for even more awesome iRules making use of some of the wicked cool new v11 features.

#Colin

To The Man Who Reached 10,000: I Salute You

10,000 is a relatively momentous number for many reasons. It's a nice, round number like 10, 100, 500, and so on. It's a stepping stone into the five digit numeric space, and it's quite an accomplishment depending on what it is you're counting. A few fun facts about 10,000:

• It is the square root of 100,000,000
• Each neuron in the human brain is estimated to connect to 10,000 others
• There are approximately 10,000 species of birds.
• 10,000 days can be expressed in these alternative units:
  • 864,000,000 seconds
  • 14,400,000 minutes
  • 240,000 hours
  • 1428 weeks (rounded down)

For us here at DevCentral, 10,000 is just as significant but in a far different manner. Almost everything we do here on this team is done with the hopes of enabling a great community to thrive. We're constantly attempting to foster the right environment to allow the right people to contribute, communicate, and connect with one another to better their experiences with F5 technologies and technology as a whole. To do so, we need the right kind of people, special people that are eager to dig in and contribute, to help others out, to dig into problems just for the satisfaction of knowing the answer, and to then share that information with a wide audience to better the whole community as they better themselves. We're very, very fortunate to have a myriad (The classical Greeks used Μ to represent 10,000, whose name in Greek is myriad, btw...) of those people engaging every day.

Leading that charge, and consistently encouraging others to aspire to the same levels of contributions, engagement and overall involvement has been Hoolio. For years now Hoolio has been a monster contributor to the forums, wikis, private DC discussions and just about anything else he can get his hands on as it relates to F5 technology and DevCentral. He's helped countless thousands of people with iRules, ASM configurations, monitors and more, truly helping us and his amazing fellow MVPs define just what that title means. As such I want to take this opportunity to recognize his recent achievement.

As most of us slept last night, Aaron did what he usually does: dug in to community posted problems and questions to help them out. In doing so, he happened to reach a goal that no one else has even come close to yet on DevCentral: he broke 10,000 posts in the forums. This is a pretty amazing feat, and it deserves a little recognition. His tireless efforts to better himself, the community and F5 technology have not gone unnoticed, and have likely had a far great impact than even he realizes.

So from me to you Aaron, many thanks man, and keep up the good work. You sir, are a beast, and I want to be like you when I grow up.

#Colin

DevCentral Top5 6/27/2011

As rare as the Hippocampus and as fleeting as the Pegasus, this special Monday edition of the Top5 is brought to you by "too much to get done on Friday"(tm). Think of it as a bonus edition though, not delayed, as this Top5 comes bearing wondrous gifts from around DevCentral. From iRules Challenges to MVP contributed Tech Tips to a special 20LoL and more, the community has borne deliciously geeky fruit of all manner the past weeks. So much so in fact that the bounty could not possibly be contained within this abbreviated format. Even still, I feel that the five I've chosen are worthy, and I hope you enjoy this week's Top 5:

iRules Challenge #4 Results: Contemplating Context

http://bit.ly/mjvwAx 

Every time I get the joy of participating in one of these FSE iRules Challenges I have a blast, but I'm also repeatedly blown away by the abilities of these new recruits. Not only are these people new to F5, but many have no scripting background whatsoever. If that weren't enough, while here in boot camp they're receiving a massive amount of information to process and imbibe every day. Given only their spare time to work on the iRule for the challenge, it's impressive that they even complete an iRule. Despite all of that, however, they somehow persevere and submit awesome entries, every time. This particular challenge was a doozy from the "What the heck did he just ask us to do?" stand point. A brief 20 minutes of questions goes by pretty fast when they're trying to formulate a plan and figure out what the heck they need to know. In spite of the intentionally confusing challenge some strong results cropped up, and I'm looking forward to the next challenge. Well played, one and all.

BIG-IP and Merge File Configuration Changes

http://bit.ly/iKWcVA

Whenever a DevCentral MVP steps up to the plate, watch the fences for the outcome. Michael Yates continued the trend of awesome MVP contributions with his Tech Tip detailing how to make use of the a Merge File to make non disruptive changes to your BIG-IP's config. In a high throughput environment where downtime isn't an option, sometimes even largely simple changes can be a no-go if they cause even a brief hiccup in traffic while the config re-loads. With a merge file you can avoid that interruption, assuming the change itself doesn't cause one (I.E. things like removing a pool or pool member will always cause an interruption, even with a merge file). I get the feeling that this handy technique is something that many other users will be able to benefit from, in part thanks to the solid document Michael has put together to educate future BIG-IP experts. MVP indeed, well earned Michael and thanks for the contribution.

BIG-IP APM-Customized Logon Page

http://bit.ly/kEJrJe

While APM offers some impressive power and inspection capabilities, let's be honest about the default login page: it's basic. Not bad basic, mind you, just simple and functional basic without a lot of bells and whistles that you don't need anyway. Why don't you need them? I'm glad you asked. You don't need our bells and whistles on your APM default login page because it is designed with the concept in mind that you will be adding your very own bells, whistles and any other doo-dads you see fit via customization. The login page is completely under your control. Whether you want to statically alter it, do away with it or like in Jason's fine example here, set up some automation around the way that it's customized via iRules fu, the choice is yours. In this example Jason is displaying how you can combine APM configuration options with a little iRules know how to get a powerful, dynamic result. Take a look for yourself for the details.

F5 Friday: Performance, Throughput and DPS

http://bit.ly/la6wsA

Lori found a topic last week for her F5 Friday post that resonated so clearly with me that it would have been beyond the power of my will to refrain from adding it here today: DPS vs. Performance vs. Throughput. Now I admit that as a reformed WoW aficionado when I first saw DPS I was confused as to how it was applicable here, but the DPS of which Lori speaks is in fact Decisions Per Second. When dealing with metrics in an application world, how much do you really want to measure network throughput or the number of TCP transactions the network was able to set up and tear down in a given time period? These things are not directly applicable to the application, the way it behaves, what portion of the application's decision making chores have been offloaded to the network in one way or another, etc. What you really want to know, or likely should if you don't, is how many decisions per second are occurring and where. Just how much heavy lifting - application lifting that is - is your network really doing? If you aren't sure, maybe you should be. This is a great topic for discussion, though I warn that it may grow heated as you involve the different groups necessary to gauge this slippery concept. I'm not saying that throughput or TPS or whatever other metrics you're used to looking at are bad or shouldn't be reported, that would be asinine. I'm merely saying, thanks to Lori's unintentional prodding, that you should probably start looking at DPS as well to see where the real work is being done, and how to best tweak that. This one is worth a read for sure to get more depth.

20 Lines or Less #50: iRules Challenge Round-up

http://bit.ly/mPqMbN

Last on the page but first in my heart, I bring to you the (marginally) momentous 50th installment of the 20 Lines or Less series. This series has been running for 3+ years now, and I enjoy it every single time I get to take the time to write it. It's a pleasure sharing the awesome code snippets produced by the community, our engineers, the DC team and sometimes even by me. With over 150 examples of how iRules can provide serious power in under 21 lines of code, clearly no one could refute the benefit iRules bring to the table if they would but take a few minutes to browse through this series and see the proverbial rabbits being pulled out of hats by F5 users worldwide. For this 50th edition I shared my solutions to three of the iRules Challenges that have been issued so far. 50 down and I'm just getting started, so stay tuned for many more, and thanks for reading.

That'll do it for this (last) week's DC Top5. As always thanks for playing and let me know if you've got any feedback, questions or contributions. Until then...

#Colin

20 Lines or Less #50: iRules Challenge Round-Up

What could you do with your code in 20 Lines or Less? That's the question I ask (almost) every week for the devcentral community, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

By a show of hands, who else here is surprised and/or excited that we finally made it to the 50th 20 Lines or Less? I'm a little of both, though more excited than anything. Years ago when I started the series I wasn't sure if anyone would find value in it, whether it was too dry to follow regularly, or even if I'd be able to drum up enough iRule examples to somewhat regularly put one of these things out. All of my trepidation was for naught, though, as the wicked awesome DevCentral community came through in spades. Both via support and interest, and a constant supply of killer iRules examples for me to pilfer.

This week, though, I'll be using my own code. I've been writing up these iRules Challenges the past few months and I'm really enjoying them. As part of the process I've been building the solution I'd offer to each challenge. Keep in mind, as I've told each class of FSEs, this does not mean it's the "correct" solution, just the way I'd do it. There are always variances in coding techniques and logical approaches, and I'm prone to missing possible solutions or shortcuts just like anyone else, but I wanted to share my solutions as part of this momentous 20LoL installment. I made even made sure they were all 20LoL when building them (I know, planning ahead...weird, right?). Keep in mind that most of these require some configuration tweaks (syslog-ng routing through a certain IP, classes being added, etc.) to function, so don't go trying them without that.

Also, before I forget, I want to give a big thanks to those that have read, commented, contributed and/or passed along the 20LoL over the years. We're "over the hump" to 100, and that's the next target in my sights. Thanks for the support, here's some code to feed the geek in you and me.

Challenge #4:

Desired Solution:

If a user is making a request to one of a list of URIs (50+), and that request is bound for one of the 4 “secure servers” (4 servers, non-sequential IPs, in one pool) in the DMZ, the Client must originate from a particular subnet (10.10.10.0/28), or from an IP resolving to one of the partners in a given list of hosts (20+).

Requirements:

    a) Identify the URI being requested

    b) Identify the IP address of the server the request is being sent to

    c) Identify the network and/or the PTR host the client is initiating the request from

    d) Drop any errant requests

    e) Log any “bad” requests, including: IP Address of Client, IP Address of Server, requested URI

 

   1: when CLIENT_ACCEPTED {

   2:  if { ([IP::addr [IP::client_addr] equals 10.10.10.0/28]) || ([class match [RESOLV::lookup -ptr [IP::client_addr]] eq authed_hosts]) } {

   3:    set secure 1

   4:  }

   5: }

   6:  

   7: when HTTP_REQUEST_SEND {

   8:  if {!($secure)} {

   9:    if { ([class match [IP::server_addr] eq secure_servers]) && ([class match [clientside {[HTTP::uri]}] eq uris]) } {

  10:      drop

  11:      log 172.27.10.10 local0.info "Bad request from [IP::client_addr] to [IP::server_addr] requesting [clientside {[HTTP::uri]}]"

  12:    }

  13:  }

  14: }

Challenge #3

Requirements:

    1. Identify the origin country of each incoming HTTPS request

     2. If the request does not originate from within the US, track the number of requests being issued from that source.

     3. If a single source makes more than 500 requests per minute, perform the following:

          1. Log the IP, country of origin, and the page requested that put them over the limit.

          2. Delay all requests from that source by 1 second for the next minute

          3. For the duration of that minute, forward all requests from that particular source to a separate pool for further inspection (in addition to the default pool, not in place of it)

 

   1: when CLIENT_ACCEPTED {

   2:   set country [string tolower [whereis [IP::client_addr] country]]

   3: }

   4:  

   5: when HTTP_REQUEST {

   6:   if { $country eq "us" } { return }

   7:  

   8:   if {[table lookup -subtable delay [IP::client_addr]] eq ""} {

   9:     table set -subtable [IP::client_addr] -excl [IP::client_addr] 0 indefinite 60

  10:     set count [table incr -subtable [IP::client_addr] [IP::client_addr]]

  11:     if {$count > 500} {

  12:       table set -subtable delay -excl [IP::client_addr] bad indefinite 60

  13:       if {$count == 501} {

  14:         log local0. "Bad people from $country at IP: [IP::client_addr] hit 501 requests per minute with [HTTP::uri]"

  15:       }

  16:     }

  17:   } else {  

  18:     clone pool inspection_pool

  19:     after 1000

  20:   }

  21: }

Challenge #1:

Requirements:

1. Client HTTP request must be sent to a specified URI based on the CNAME requested.

2. Over 1000 unique CNAMEs to be matched.

3. If no match is found, respond to the user (from the iRule) with a simple HTML message stating as such.

4. If a match is found, insert a cookie with the resulting URL of the CNAME match, ensuring the next time they request domain.com they are automatically sent to the appropriate <cname>.domain.com based on the cookie.

5. Log the country of origin for each successful request along with the URI they were routed to and why.

6. Logs must be shipped to an external syslog server (10.10.10.1). External syslog server is only routable via the Management interface, not via Self-IP.

 

   1: when HTTP_REQUEST {

   2:  if {[HTTP::cookie exists "ltm_cname"]} {

   3:    set redirURI [HTTP::cookie vlaue "LTM_cname"]

   4:  } else {

   5:    set redirURI [class search -value cnameclass equals [getfield [HTTP::host] "." 1]]

   6:    if {$redirURI ne ""} {

   7:      set setcookie "yes"

   8:    } else {

   9:      HTTP::respond 200 Content "No match was found for [HTTP::host]. Please try another CNAME."

  10:      return

  11:    }

  12:  }

  13:  log local0. "Inboud Req from IP: [IP::client_addr], Country: [whereis [IP::client_addr]] \

  14: sent from CNAME: [HTTP::host] to URI: $redirURI"

  15: }

  16:  

  17:  

  18: when HTTP_RESPONSE {

  19:  if {$setcookie eq "yes"} {

  20:    HTTP::cookie insert name "ltm_cname" value $redirURI

  21:    unset setcookie

  22:  }

  23: }

That'll do it for the 50th installment of 20 Lines or Less. With over 150 examples of what iRules can do for you in less than 21 lines of code, surely by now there's no question of how much power this technology packs with minimal overhead. That, of course, won't stop me from posting. Onward to 100! And thanks again for reading.

• 20 Lines or Less #30
• 20 Lines or Less #24
• 20 Lines or Less #23
• 20 Lines or Less #20
• 20 Lines or Less #48: Splicing, Scrubbing and Matching

#Colin

iRules Challenge #4 Results: Contemplating Context

In a shocking turn of events, the gracious sales readiness team invited me back to yet again present an iRules Challenge to the inbound FSEs during their multi-week grooming process here at F5 Seattle, lovingly known as "boot camp". It's a joy for me to be a part of these boot camps not only because I get to geek out about iRules and dream up challenges to get people more involved with DevCentral and iRules, two of my main squeezes in the tech world. But also because it's killer to see the talent rolling through, chat with some of them about how and why they ended up here at F5, and get a constant stream of reassurance about just how wicked powerful our engineers out in the world are, not that I had any doubts.

Why so fired up about the worldwide crew of Engineers? What's an FSE? To uphold tradition (and because I don't think I could write it better if I tried) I'll borrow from my first introduction of the iRules Challenge to depict what FSEs are, and why I'm such a fan of getting to work with them:

FSEs are the engineering lifeblood of the sales force here at F5.  They’re the ones out in the trenches dealing with customer requirements and issues, building real world solutions, and generally doing all the cool sh stuff that I get to talk about theoretically, but in the real world.  I’ve got mad respect for those FSEs that take their jobs seriously and learn how to build full fledged F5 solutions that leverage our crazy broad product set and, you guessed it, our out of the box tools like iControl and iRules.  Those that choose to flex those muscles garner a special place in my encrypted little heart.  Lucky for me (and F5) this is an increasingly large number, but that’s a different conversation.

As you can see, I'm a fan, and it's fun to get to help get them indoctrinated into the DevCentral and iRules cultures. Apparently I make some tasty Kool-Aid, and I'm more than happy to share. Speaking of which, on to the challenge!

Desired Solution:

If a user is making a request to one of a list of URIs (50+), and that request is bound for one of the 4 “secure servers” (4 servers, non-sequential IPs, in one pool) in the DMZ, the Client must originate from a particular subnet (10.10.10.0/28), or from an IP resolving to one of the partners in a given list of hosts (20+).

Requirements:

     a) Identify the URI being requested

     b) Identify the IP address of the server the request is being sent to

     c) Identify the network and/or the PTR host the client is initiating the request from

     d) Drop any errant requests

     e) Log any “bad” requests, including: IP Address of Client, IP Address of Server, requested URI

Each individual part of this isn't necessarily difficult, but the combination presents some unique challenges. First and foremost, intentionally, is the concept of context. Being a full proxy system is a wonderful, powerful thing, but it means that any engineers working in-depth with F5 devices need to keep the different proxy states in mind, and understand what information is available on each side of the connection. Combine that with the need to access information that might not be immediately available in your current state, lists of info to manage, multiple tiers of conditionals and one of my favorites: Session vs. Request based conditionals, and there are plenty of traps to fall into for an unsuspecting iRuler. That's was kind of the point, after all. As it turns out, however, this new batch of FSEs was largely up to the task right out of the gates, which was plenty impressive.

3.) First up is the second runner up, coming in at third place, David Parez Aznarez.

David's iRule was well thought out and showed solid potential. It had a great logical flow and showed that he was adept at not only thinking through the problem, but also researching possible solutions on DevCentral, which I appropriate. In the end it was a bit more complex than necessary, but efficiency and coding elegance come with experience, so I have no doubts that David will be writing even more powerful iRules code in no time.

2.)  Next in second place, the first runner up Anurak Chuetanapinyo!

Anurak did a truly admirable job of keeping his code simple and efficient. He was at the opposite end of the spectrum from David, also with very solid logical flow and some good concepts such as RESOLV::lookup mixed in. In the end his simplification went slightly too far and earned him a respectable second place finish, due to a couple pieces of the challenge not being 100% in place, though he was close enough that a short chat later and he knew where he had left bits out, and I could see he was picking the concepts up mighty quick. He'll soon be an old hand at simple iRules like this, and be on to bigger, better coding tasks I'm sure.

1.)  Last, but certainly not least, is our Winner, Vince Tognaci!

Vince displayed a very solid understanding of not only contextual awareness and information availability, but also of connection vs. request based processing, two of the big "gotcha" concepts I was hoping to impart on these engineers with this challenge. That combined with his use of DevCentral scouring, solid coding concepts and practices and even some nice commenting earned him a well deserved first place finish. With a few minor tweaks this rule could solve all of the problems laid out and that, for someone with mere weeks as an F5 employee, is impressive indeed.

Overall another outstanding showing from all of the engineers that were in the training course and had to endure the challenge. Thank you all very much for your hard work and the code submissions. It was a blast, as always, to participate and get to share a little of my passion for this technology with all of you, and I look forward to doing so more in the future.

For those new hires out there that might be reading this, knowing you'll be in boot camp soon...get to reading, researching and learning the ins and outs of DevCentral & iRules. There's a Challenge heading your way, I'd bet on it.

#Colin

DevCentral Top 5 05/06/2011

The 20 Lines or Less, the DC weekly podcast, 99% of the hundreds of blogs Don and Lori seem to put out each week...these are but a few of the things you won't see this week in the DC Top 5. With as good as the content is that's getting left out, you can only imagine how good the stuff that made the cut is. It's been a jam packed few weeks since the last installment. I've survived, somehow, and I'm here to tell the story of what DevCentral's been up to, at least this last week. So check it out, in this week's DevCentral Top 5:

iRules Challenge Results: Can Everyone Win?

http://bit.ly/maEiPC

Every so often the Sales folks invite me over to throw a challenge at the new FSEs that are moving through the initiation/training program, getting their feet wet. This challenge is intended to stretch them a bit and get them thinking about iRules as well as DevCentral and the other resources they'll need to survive when asked to start writing these things in the wild. This time through I pushed a bit harder and created a challenge that would lead, ideally, to the investigation and use of the table command(s), and the beauty therein. I'm impressed at the results I got and I'm quite happy to announce the winner of said Challenge as well as the very honorable mentions.

Ruby and iControl: Remote BIG-IP Software Image Installation

http://bit.ly/kFNpXo

George is up to his wily ways again, what with the Ruby-iControl coding and all. This time he's churned out a tool that looks like it could be extremely handy. This snippet will not only upload but actually install a new image to your F5 device. This is a dream come true for those of you that have been managing such things manually. Even to those that might not use it directly, it's a great peek at some of the things that iControl can do and the lengths to which you can automate things. This one's worth a read for sure.

If a Network Can't Go Virtual Then Virtual Must Come to the Network

http://bit.ly/mT6jH6

In her typical fashion, Lori got me thinking (and a bit fired up) with her post regarding virtualization and multi-tenancy. She accurately points out some pros and cons, as well as where we've been and where we very well might be going when it comes to scaling application solutions and the networks that support them. Regardless of whether you're looking for ultimate performance scaling or silos of resources with no outage overlap, this one is a very good read. Everyone's situation is obviously different but if you're not thinking about this yet, you should be. Sooner rather than later these issues will be facing you, it's good to be prepared.

SSL Renegotiation DOS attack - An iRule Countermeasure

http://bit.ly/j0Y0Wy 

David Holmes, our resident security guru, is back and posting about a possible attack vector that could affect nearly the entire web. Sound scary? Well, when you're talking about a vulnerability in a broadly accepted protocol, it's bad enough. When it's a protocol normally associated with the most secure of applications and data, like SSL, then it gets even more worrisome. In this attack, would be miscreants attempt to hang an SSL enabled server by performing a series of renegotiations, thereby overloading the system. In steps iRules to save the day, as seems to often be the case. With a relatively simple iRule, Jason was able to whip up a solution to this problem by limiting the number of renegotiations allowed on a given connection in a certain time frame. With only a scant amount of development time, this very real threat was able to be completely negated. Take a read to get all the details for yourself.

Post of the Week - SMTP TLS Encryption

http://bit.ly/lZxnhw

Last on the list this time around is the Post of the Week. Since being revived this popular series is again picking up a following of those interested in either seeing Joe and I goofing off in front of the camera, or some wicked cool solutions offered up in the forums thanks to the awesome community...or maybe both. This week we dig into SMTP TLS Encryption via iRules. Long ago Nat wrote an iRule that did just this but along came a user who wanted more, and more they got. Digging back into the problem a discussion broke out and when the dust settled the solution was even more impressive than it was in its previous form, as formidable as that was. Take a look for yourselves if you want the nitty gritty, and be sure to click through to the post for the real goods straight from the source.

That's it for this week's Top5, thanks much for reading.

#Colin

iRules Challenge Results: Can Everyone Win?

It would seem that, at least in this contest, everyone can indeed be a winner. I got the distinct pleasure to, once again, help contribute to the iRules delinquency education of our inbound FSE crew while they were here in Seattle for their boot camp. These folks are all technical, but very few have any iRules experience. Heck, most don't even have much scripting experience, so to lay down the gauntlet and say "Here, act like I'm a customer giving you these requirements, and go write me an iRule that'll make me happy." is a tall order. I'm very pleased to report, though, that they answered that challenge with vigor.

Amongst the entries I received there were a host of solid efforts and obvious understanding of the challenge, the inner workings of the LTM and a very solid showing of budding iRules knowledge. It was also obvious that, as I had hoped, the challengees made heavy use of DevCentral for ideas. Sourcing publicly available code is the first step for almost any coder these days, and iRules are no different. If they hadn't made use of the CodeShare, search functions, the forums, etc. I'd be highly disappointed.

All of that being said, we have to declare a winner. Even with the overall quality of the entries being so high, there were a few that stood out as real gems. Before we get to the top entries, a quick reminder about the challenge. If you recall from my last post, here's what they were up against:

Requirements:

1. Identify the origin country of each incoming HTTPS request
2. If the request does not originate from within the US, track the number of requests being issued from that source.
3. If a single source makes more than 500  requests per minute, perform the following:
   1. Log the IP, country of origin, and the page requested that put them over the limit.
   2. Delay all requests from that source by 1 second for the next minute
   3. For the duration of that minute, forward all requests from that particular source to a separate pool for further inspection (in addition to the default pool, not in place of it)

And now, without further adieu, the Top3 FSE iRules Challenge Entries:

3.) First on the list, our Second Runner Up, Gavin Zhou:

Gavin showed a very solid grasp of what he needed to do, and made some wise choices in how he approached the task at hand. Multiple tables for sorting the blacklist vs. counts, very close to the entire list of required functionality, and some good looking code were among the strong points for Gavin's entry. Once he figures out how to use the static:: variables rather than demoting to CMP, he'll quickly be an iRuler to watch.

2.) Next up, our First Runner Up, Sachin Thatte:

Sachin used many of the same concepts as Gavin, with the important optimization of the aforementioned static:: commands. He also tied up the clone pool requirement nicely. Overall a very solid rule, and one that's darn near production ready. This was a very, very solid attempt indeed.

3.) Last but not least, our Winner, Chris Miller!

Chris may possibly be the most seasoned iRuler in the bunch, and it showed in his entry. He used tables, the clone pool command, the after command...frankly he did just about everything I'd do. Be that good or bad, I'll leave it up to him to decide. With a few minor tweaks to the logic to save some cycles and doing away with a couple variables that might not be necessary, this would be ready to plug in and live in Prod for quite some time. An excellent, impressive entry from what's sure to be a rock star iRules contributor in the future.

A huge thanks to everyone that participated, and a big pat on the back to all of those that submitted their examples. They were all very strong and judging was tight. Keep your eye out for a special 20LoL in the near future to show my take on the first 3 iRules Challenges and the solutions I'd provide.

For now though, keep iRuling.

#Colin

20 Lines or Less #49: SSL Renegotiation, Execution Halting and HTTP Rewriting

What could you do with your code in 20 Lines or Less? That's the question I ask (almost) every week for the devcentral community, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

This week I do the unthinkable ... I write my own code! Well, some of it, anyway. While I've been happily using the community's examples for this series this week I ended up writing a couple of neat 20LoL worthy entries as responses to forum posts, so I figured I'd give the rest of the community a breather from doing all my heavy lifting this week. Two of the examples are mine and the third is from Jason. You can tell which one is his, just look for the really wicked awesome one that I wish I had written.

On to the code!

Host Header Route and Re-write

http://bit.ly/lQEmie

First up is a request from user willko (please tell me your name is Roger, too perfect...) who is looking to combine two iRules into one that suits his needs. One iRule is performing a check against inbound hosts and routing to the appropriate node based on which host the request was sent to. The other is doing some header rewriting to make sure the extraneous characters get removed. Those two are definitely things that play well together, so I whipped up a little example using class and some fun scan magic to make it happen.

   1: when HTTP_REQUEST {

   2:   if {[class match [HTTP::host] equals mappings]} {

   3:     set list [split [class lookup [HTTP::host] mappings] " "]

   4:     node [lindex $list 0] [lindex $list 1]

   5:     scan [HTTP::host] {%[^.].%s} cname host

   6:     HTTP::header replace Host "www.$host"

   7:   }

   8: }

SSL Renegotiation DOS attack - an iRule Countermeasure

http://bit.ly/j0Y0Wy

So the really cool iRule, the one that I wish I had written, comes from Jason Rahm. He wrote up a very nifty iRule to help block a possible renegotiation attack that resident security guru David Holmes brought to our attention recently. The rule ensures that no one is able to make more than x (in this case 5) renegotiations over y (60 in the example) seconds. It's handy, it's smart, and it's wicked compact. With some improvements built in straight from the hands of one of the iRules core developers, this one is pretty sweet indeed.

   1: when RULE_INIT {

   2:   set static::maxquery 5

   3:   set static::seconds 60

   4: }

   5: when CLIENTSSL_HANDSHAKE {

   6:   set flow "[IP::client_addr]:[TCP::client_port]@[IP::server_addr][TCP::server_port]"

   7:   incr reqno

   8:   table set -subtable "reqrate:$flow" $reqno "ignored" indefinite $static::seconds

   9:   if { [table keys -count -subtable "reqrate:$flow"] > $static::maxquery } {

  10:     after 5000

  11:     drop

  12:   }

  13: }

  14: when CLIENT_CLOSED {

  15:   table delete -subtable reqrate:$flow -all

  16: }

Halt iRules Processing Upon Condition

http://bit.ly/ivWozi

Lastly we've got an iRule designed to ensure that processing is halted, effectively, upon a given condition being met. This can be done with event disable, but the scope of that is the entire connection. If you run an event disable from within an iRule on, say, HTTP_REQUEST, you'd better not have any other iRules using that event or you're in trouble. The user wanted to stop the processing occurring in the HTTP_REQUEST event only for the context of this particular iRule iteration if criteria in the CLIENT_ACCEPTED event were met. After pondering for a minute, this really isn't that complicated. The obvious answer might be the return command, but keep in mind that only dumps you out of the iRule event context you're in, not the entire iRule. So a return in the CLIENT_ACCEPTED event will still allow processing in the HTTP_REQUEST event. There are, of course, many ways to skin this cat, but here's the brand I chose.

   1: when CLIENT_ACCEPTED {

   2:   set httpfunctions 1

   3:   if { [IP::client_addr] equals 1.2.3.4 } {

   4:     node 192.168.10.10 80

   5:     unset httpfunctions

   6:   }

   7: }

   8:  

   9: when HTTP_REQUEST {

  10:   if { [info exists httpfunctions]} {

  11:     if { [HTTP::host] contains domain1.com {

  12:       pool domain1.com_pool

  13:     }

  14:     elseif { [HTTP::host] contains domain2.com {

  15:       pool domain2.com_pool

  16:     }

  17:     else {

  18:       pool domain.com_pool

  19:     }

  20:   }

  21: }

Another batch of FSEs, another iRules Challenge

The Sales Readiness team is back at it, training another awesome crop of FSE type peoples here at F5 headquarters. And for the third time in a row, I get the esteemed honor/fun of building an iRules challenge to push them into learning iRules, the tools it takes to build them, how to research them, how to use DevCentral, etc. It's a super fun exercise for me, and I've gotten good feedback from the previous classes of FSEs as well, so hopefully it's a trend that'll continue.

Continuing the tradition of my last two posts announcing iRules challenges, let me pause for a moment here to explain for those that might not have seen it before what FSEs are here at F5:

FSEs are the engineering lifeblood of the sales force here at F5.  They’re the ones out in the trenches dealing with customer requirements and issues, building real world solutions, and generally doing all the cool sh stuff that I get to talk about theoretically, but in the real world.  I’ve got mad respect for those FSEs that take their jobs seriously and learn how to build full fledged F5 solutions that leverage our crazy broad product set and, you guessed it, our out of the box tools like iControl and iRules.  Those that choose to flex those muscles garner a special place in my encrypted little heart.  Lucky for me (and F5) this is an increasingly large number, but that’s a different conversation.

So the setup for the challenge is basically the same. The class of FSEs is here in town, I wander over Monday morning and dish out a set of requirements. They get about 20 minutes to ask questions, get details, bounce ideas off me, call me names, throw rotten fruit (WHY DO YOU CARRY ROTTEN FRUIT?!), what have you. Then I'm on my way and back to the wild world of DC madness, leaving the 20 or so FSEs to fend for themselves. They delve into DevCentral's archives of iRules riches, ask peers, email me directly...whatever they can think of, they can use as a resource. The only stipulation is they can't have the rule (or any of the code therein) written for them directly. Suggestions from a peer are one thing, chunks of code are another. So here are the requirements for the challenge this time around:

Requirements:

1. Identify the origin country of each incoming HTTPS request
2. If the request does not originate from within the US, track the number of requests being issued from that source.
3. If a single source makes more than 500  requests per minute, perform the following:
   1. Log the IP, country of origin, and the page requested that put them over the limit.
   2. Delay all requests from that source by 1 second for the next minute
   3. For the duration of that minute, forward all requests from that particular source to a separate pool for further inspection (in addition to the default pool, not in place of it)

So there it is, what do you think? Hard enough? Too hard? Can you solve it? Go ahead, take a stab at it and I'll let you know how close you get.

I'm looking forward to the submissions (due tomorrow, folks, get on it!) as they're always hawesome to go through.

Good luck challengees (hi, I'm Colin and I make up words), and I'll see you on Friday with some goodies for the winner.

#Colin