iRules

DevCentral Top5 02/03/2012

Colin Walker — Sat, 04 Feb 2012 00:16:58 GMT

We're putting the band back together. And by band, I mean team. And by "putting back together" I mean we're all going to be in the same place, physically. This is a rarity for our remotely distributed team, but next week it is happening, and that is a great thing. It means planning, policies, preparation, prognostication and many other things that don't begin with the same letter. It also means that there will be some new, cool things to look forward to in what will likely be the near future, from a DevCentral perspective. Rarely do we get the whole team together to brainstorm and plan without something hawesome coming out of it. For that, I recommend you keep your eyes peeled the next few weeks. In the meantime, however, there is nowhere near a shortage of killer content on DevCentral just waiting for your perusal. So much so, in fact, I find myself again compelled to pick a few of my favorites and disseminate them to you in a format that takes the guess work out for those of you not neck deep in DC goodness, as I am. For the fun of it I'll pick only 5 topics this week, and here they are. Oh, and there might be some iRules involved. A lot of iRules. All over the place. Once you recover from your shocked state, given my lack of a propensity for sharing iRules topics, read on:

Transparent Web Bot Application Protection

http://bit.ly/zRt5TF

Joe takes us out of the gates this week with an awesome new take on an old problem. Forms being abused by web bots is a story as old as ... well ... forms and web bots. It has been "solved" or worked around or just plain dealt with through gritted teeth for years. One of the most common, reliable ways of stopping bots from abusing the forms on your site is to implement captchas. Captchas, in case you haven't been on the web since 14.4 was blistering, have gotten pretty advanced these days, asking you to input multiple phrases, playing back audio to help you decipher them, etc. There are even some iRules on DevCentral to help you implement them seamlessly. Also? I hate them. I am not a captcha fan. They are annoying, time consuming, and just plain not fun. Necessary bits of not fun that I tolerate, certainly, but I, much like Joe it would seem, am not a fan. So, when Joe presents a solution to provide what is effectively a transparent captcha, meaning the user has no interaction but the functionality is very much similar to a traditional captcha, I sat up and took notice. I suggest you do the same, it's worth the read.

Introduction to iStats Part1: Overview

http://bit.ly/AAmDhv

I'm kind of in the business of documenting iRules. Along with talking about them to anyone that will listen, or is in earshot, or is passing by, or sits next to me on the plane or ... well you get the idea. In addition to talking about them and writing them and working with the wicked smart folks in the depths of F5 to better them for future generations of iRulers, I document them a fair amount, as do my DC compatriots. That process is great and all, but every so often one of the software engineers will produce a chunk of documentation that allows an article to all but write itself. That is what happened here. One of our iRules engineers put together a simply outstanding document detailing what iStats are, how they work, how to use them, etc. and sent it off to the iRules experts. I couldn't help myself, so I wrote it up in more detail, with some more background, etc. and put it out on DevCentral for the masses to consume. iStats will change the way many people are using iRules. They will allow things that were previously impossible. iStats are cool, but you'll have to read the document to find out just how cool and why.

Populating Tables With CSV Data Via Sideband Connections

http://bit.ly/wqtg8f

George is off in his own world these days. It's a world wherein awesome iRule ideas leap from the walls, complex code lays itself out at his feet, and outstanding Tech Tips come flowing out as the result. If you find where that place is, send me directions, would you? I have serious article envy. George continues making it absolutely rain wicked solutions with his newest installment of applications hawesomeness by way of the new super powers garnered to iRules in v11, namely Sideband Connections. In this example George shows off an iRule that will connect to an out of band server to look up CSV data pertinent to the connection before processing the client request, then cache that data as necessary within the BIG-IP. Yeah, if you're not impressed and thinking that's pretty darn cool, you're doing it wrong. That or I'm just bonkers for this stuff. Perhaps both. Seriously folks, go read this article right now. It's worth it. I'll be over re-mapping the keys on George's keyboard to slow him down a bit so he stops making me look bad.

Advanced Load Balancing for Developers. The Network Dev Tool.

http://bit.ly/zfWnuM

Hitting near and dear to my heart, Don dusts off his Load Balancing for Developers series and dives straight into one of my favored topics: Business logic offloading to the network. He draws you the picture, first, of ZapnGo (a make believe company) and their growth, the struggles brought with it, and how they're working to address them. This is something that is very real to many businesses in a similar place as ZapnGo. Growth is fantastic but it brings along very real issues that need addressing, and doesn't always provide the extra cycles to deal with them. Offloading some of the functionality that might traditionally go into the back-end to the network layer can be an extremely effective way of saving cycles, both in man-hours and processing time. This is something that I've spoken with droves of people about over the years, and I love seeing it brought up in another light and hearing someone else's take on it. This is a good read and very well may give you some insight into how to solve some issues you're having, if you're in a similar place as ZapnGo.

Enterprise Apps are Not Written for Speed

http://bit.ly/wK84ib

Another topic that will often times quickly lead to a soap-box being produced out of thin air and those perhaps unfortunate people near enough to be caught in the path of the diatribe that follows is performance vs. maintainability. Lori hits the nail on the head with her topic, and the ensuing discussion she presents in this blog post. The reality is, most developers building enterprise level applications are focused on reliability, maintainability, and functionality. Performance is a nice to have in a world of strict requirements. That's not even taking into account the real time killer - security. Back in the day when I was writing such apps and automation tools in an enterprise environment the concept of "performance" was relegated to "Does it work? Does it work twice? Awesome..." and that was about it. In a world of more and more web accessible or hosted apps, increasing numbers of mobile users, larger object counts and sizes, and a host of other performance degrading factors, now more than ever the ability to up the performance outside of the application is a valuable one. The network layer can help with that, if you let it, and Lori talks about how in this post.

There are five more picks from the past couple weeks of content surging through DevCentral. It shows no signs of stopping, so I guess I'll have to come back in a week or so to give you some more hints on where to look for the pieces that were my favorite. Until then, happy coding, configuring, networking or whatever else it is that you do when not cruising DevCentral.

#Colin

Technorati Tags: DevCentral,Top5,iRules,Performance,Security,Networking,Sideband Connections,iStats,Colin Walker

20 Lines or Less # 54: Pools, Geo-IP, and Mobile

Colin Walker — Tue, 24 Jan 2012 15:55:45 GMT

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 the forums provide us with more examples of iRules wizardry (or at least apprentice awesomeness) in a scant 20 lines or less each. The credit goes to the awesome community for providing such frequent and awesome examples. This week's installation of iRules goodness in particular is brought to you by hoolio, who despite the snow storm (perhaps because of it?) was iRuling away like the mad man he is. Showing off how to simplify geographical based redirection, how to smoothly access a particular pool given the right configuration, and how to do some fancy matching to search for strings of digits.

Mobile Redirects

http://bit.ly/xRJ6Ig

In this example user Ruchir is looking to do some matching based on some mobile device needs. They have a somewhat complex set of requirements to strip out a set of 4 or 6 digits from a URI that could take multiple forms. Making clever use of the URI::path depth command and some intelligence built into switch, Aaron shows that this can be near trivial if you know what knobs to turn.

1: when HTTP_REQUEST {

2: # Get the index of the last URI directory

3: set depth [URI::path [HTTP::uri] depth]

4:

5: # Parse the last directory in the path

6: set last_dir [URI::path [HTTP::uri] $depth $depth]

7:

8: # Parse everything after the last hyphen in the last directory

9: set digits [string trimleft [string range $last_dir [expr {[string last - $last_dir]}] end-1] -/]

10:

11: log local0. "URI=[HTTP::uri], \$depth=$depth, \$last_dir=$last_dir, \$digits=$digits"

12:

13: # Check if we parsed 4 or 6 digits

14: switch $digits {

15: [0-9][0-9][0-9][0-9] -

16: [0-9][0-9][0-9][0-9][0-9][0-9] {

17: # Found 4 or 6 digits, send a redirect

18: HTTP::redirect "http://m.site.com/test/?gid=$digits"

19: }

20: }

21: }

Geo-IP Redirection

http://bit.ly/yGw81z

Geolocation is not a new concept in our products, but it is new to many users out there, and it's fantastic to see people bringing it up in the forums. In this example, the desire was to separate out several countries into their own landing pages. Aaron came through and made a much simpler version using switch and some cleaned up matching logic that shows this can be pretty easy indeed. I removed some of the country cases for brevity, but the idea remains intact.

1: when HTTP_REQUEST {

2: if { [string tolower [HTTP::host]] equals "www.example.com" && [HTTP::path] eq "/" }{

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: set country [string tolower [whereis $client_ip abbrev]]

10: switch $country {

11: "af" -

12: "bh" -

13: "ye" { HTTP::redirect "http://www.example.com/home-${country}" }

14: default {

15: # Redirect all others

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

17: }

18: }

19: } else {

20: pool example_web_pool

21: }

22: }

Pool Based on Inbound Port

http://bit.ly/yxSIJa

Every so often we get a request from a user that wants to select a pool directly based off of something within the request. I.E. they want to add "/pool1" to the URI or they want to, as in this case, use the port number and append that to a pre-defined pool name and automatically direct traffic to a specific pool. In this case it is a way to specifically select a given node, as the user has one member per pool. That being said, we can do this, but not without one inherent issue in particular. If the pool doesn't exist, the connection will, understandably, fail. So what is a good way around this? The catch command! Aaron demonstrates how this works and gives a way for a backup plan in this snippet.

1: when CLIENT_ACCPEPTED {

2:

3: # Try assigning the pool based on the client destination port

4: # If the pool assignment fails, use the VS default pool

5: if {[catch {pool pool_[TCP::local_port]} result]}{

6: # Pool did not exist, so log the value for testing

7: # The VS default pool will be used

8: log local0. "pool_[TCP::local_port] doe not exist"

9: } else {

10: # Pool assignment succeeded

11: }

12: }

Check back again next week, or better yet subscribe to the feed, for more examples of iRules less than 21 lines that you can add to your bag of tricks.

#Colin

Technorati Tags: 20LoL,20 Lines or Less,iRules,Pools,Redirects,Geolocation,Mobile,Colin Walker

20 Lines or Less #53: Security, Security & more Security

Colin Walker — Tue, 10 Jan 2012 22:37:33 GMT

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 we've got three awesome examples of iRules that are designed to increase your application's security in less than 21 lines of code. Dealing with header size, cache control, and a Microsoft advisory, we get to see a couple of different ways in which iRules can save the day. This isn't a new theme. iRules can be an amazingly powerful security resource in the hands of someone with the security mindset to be aware of what is going on, and the F5/iRules knowledge to craft the solutions necessary to put in place the preventative measures necessary to thwart incoming attacks.

Preventing Overzealous Headers

http://bit.ly/wZHvRC

To work around a recently released bug that allowed attackers to exploit excess parameters in an HTTP request, Aaron whipped up an iRule to count the parameters. User Wizdem had an excellent start, looking through the payload, but Aaron and Jason teamed up to make it more efficient and expanding it to look through the query string as well. If either of these have more than 100 parameters, it drops the request, assuming it to be an attack. Given that most requests shouldn't have anywhere near 100 parameters, that should be a pretty safe assumption, but your mileage may vary, as always. A very slick look at an iRule protecting against a known attack in a short period of time with only a few lines of code. This one looks longer than it is. Take out white space, comments, and log lines and you end up at 20. Honest.

1: when HTTP_REQUEST {

2:

3: # Check if the query string contains more than 100 parameters

4: if { [llength [split [HTTP::query] &]] > 100 } {

5: log local0.alert "Microsoft Security Advisory (2659883)\

6: IP Address [IP::client_addr]:[TCP::client_port] requested [HTTP::uri]"

7:

8: # Drop the request

9: drop

10: return

11: }

12:

13: # Collect up to 1Mb of POST data

14: if { [HTTP::method] equals "POST"}{

15: set clength 0

16: if {[HTTP::header "Content-Length"] ne "" && [HTTP::header "Content-Length"] <= 1048576 && [HTTP::header "Content-Length"] > 0}{

17: set clength [HTTP::header Content-Length]

18: } else {

19: set clength 1048576

20: }

21: HTTP::collect $clength

22: }

23: }

24:

25: when HTTP_REQUEST_DATA {

26:

27: # Check if the collected payload contains more than 100 parameters

28: if { [llength [split [HTTP::payload] &]] > 100 } {

29: log local0.alert "Microsoft Security Advisory (2659883)\

30: IP Address [IP::client_addr]:[TCP::client_port] requested [HTTP::uri]"

31:

32: # Drop the request

33: drop

34: }

35: }

Header Size Restrictions

http://bit.ly/zOI2wZ

Similar yet different, in this snippet the size of each header is inspected to ensure it is not over 1000 characters. While this is not necessarily a malicious attack it was causing problems for the OP in the thread, and Aaron was kind enough to lend an updated version to log the header lengths as they come through, since this thread was brought back up recently. In this incarnation the rule is only logging but it would be trivial to modify it to drop requests as necessary if you experience a particular client attempting to send through egregiously large headers in an attempt to cause problems.

1: when HTTP_REQUEST {

2:

3: # Check the total HTTP headers size

4: if {[string length [HTTP::request]] > 10000 }{

5:

6: # Loop through the headers by name

7: foreach header {[HTTP::header names]} {

8:

9: # Check for a long header value

10: if {[string length [HTTP::header value $header]] > 1000 } {

11: log local0. "Header is long. Header Name: $header,\

12: Length: [string length [HTTP::header value $header]], Value: [HTTP::header value $header]"

13: }

14: }

15: }

16: }

No-Cache ... For Real

http://bit.ly/wEiAK3

In this post user Joanna shares the problem she's facing with us

"The problem is that Google Chrome will cache, in the current sessions memory only, responses which have had the no-cache directive applied. This means that after a user logs out of an application and walks away, another user can come up to the computer, press the back arrow and potentially see private information. The way round this is to use the no-store directive with a couple of other headers thrown in for good measure. "

That is less than optimal...a browser that refuses to respect no-cache headers for secure pages. I'm not sure in what environments or across which versions this applies, but having a fix readily available is a good thing. Fortunately Joanna was kind enough to provide exactly that. With this simple iRule she was able to more firmly enforce her caching directives and create a more secure application in the process.

1: when HTTP_RESPONSE {

2: # The purpose of this iRule event processing is to force no-store so that browsers will not store this content

3: # which would enable users to hit the 'back' button, even after a logout, and potentially see customer PII

4:

5:

6: if {[HTTP::header Content-Type] contains "html"} {

7: HTTP::header insert Pragma "no-cache"

8: HTTP::header insert Expires "Fri, 01 Jan 1990 00:00:00 GMT"

9: HTTP::header replace Cache-Control "no-cache,no-store,must-revalidate"

10: }

11: }

There you have it, <= 60 lines of code to help make your iRuling life better, more interesting and in this case more secure, too. More iRules goodness is sure to follow in coming weeks.

#Colin

Technorati Tags: DevCentral,20LoL,20 Lines or Less,Security,HTTP,Headers,Caching,Parameters,Colin Walker

DevCentral Top 5 01/06/2012

Colin Walker — Sat, 07 Jan 2012 00:24:20 GMT

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.

Technorati Tags: DevCentral,Top5,iRules,Security,Application Delivery,LDAP,Google,Colin Walker

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

Colin Walker — Fri, 06 Jan 2012 18:38:58 GMT

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

Technorati Tags: DevCentral,iRules,20LoL,20 lines or Less,dynamic IPs,SSL,HTTP,Colin Walker

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

Colin Walker — Tue, 20 Dec 2011 16:49:13 GMT

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.

Technorati Tags: 20 Lines or Less,20LoL,DevCentral,iRules,Math,Geolocation,Security,Colin Walker

#Colin

DevCentral Top5 6/27/2011

Colin Walker — Mon, 27 Jun 2011 17:35:07 GMT

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...

Technorati Tags: DevCentral Top5,DevCentral,iRules Challenge,iRules,APM,Cloud,Reporting,MVP,Colin Walker

#Colin

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

Colin Walker — Tue, 21 Jun 2011 18:58:25 GMT

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.
Related Articles

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

Technorati Tags: 20LoL,20 Lines or Less,DevCentral,iRules,iRules Challenge,F5,Colin Walker

#Colin

iRules Challenge #4 Results: Contemplating Context

Colin Walker — Mon, 20 Jun 2011 17:30:02 GMT

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.

Technorati Tags: iRules Challenge,iRules,FSEs,DevCentral,F5,Colin Walker

#Colin

DevCentral Top 5 05/06/2011

Colin Walker — Fri, 06 May 2011 21:27:11 GMT

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.

Technorati Tags: DevCentral,Top5,iRules,Ruby,iControl,Security,SSL,Virtualization,Multi-Tenancy,Colin Walker

#Colin