Wow! What a whirlwind it's been the past few weeks. Between holidays and vacation and people traveling out of town, it's been an absolute zoo around here. Though I've been out the past week or so there has been an avalanche of content. I've hemmed and hawed and finally managed to slim my picks down to just five, though there are at least a dozen awesome things worth checking out on DevCentral in the past week or so. So don't be shy, get out there and poke around for yourself. For now, though, here are my top 5 picks for the week:

v10.1 - The table Command - The Basics

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=2375

The new table command introduced in 10.1 is so hawesome and powerful it's hard for me to decide where to even begin describing the grandeur that is the table command. I've decided to begin at the beginning, and point you to the basics first. There are nine (yes, 9) tech tips published in the past week or so having to do with the new table command. They range from this intro doc to some pretty powerful, in depth, well explained examples. They are all penned by the creator of the command and go into amazing detail. This series has instantly become a contender for one of my favorite batches of content ever released on DevCentral, which is saying something. If you're looking for a way to store data, store data in a structured format, perform counting operations or about a bagillion other things dealing with data storage and manipulation in iRules, you must read about the table command. Huge thanks to spark for the work on the command and going above and beyond on the documentation.

TMSH Scripting in v10.1

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=2374

This week's Top5 has not one, but two awesome docs regarding scripting on your BIG-IP. While iRules are near and dear to my heart, TMSH is quickly catching my interest as well. The new shell along with the powerful new scripting capabilities are wicked cool and have the potential to do some pretty amazing things. TMSH crams a huge amount of utility into an easily approachable package. This great doc Jason wrote up gets you started in style with an excellent description of where to begin, then takes you quite a bit further giving you examples of just how to build your own script. The possibilities seem rather limitless so I'm excited to see what people start doing once they get the hang of it. Check this one out for sure, and if you like what you see I'd recommend taking a look at the TMSH wiki and maybe giving this week's podcast where we spoke with Mark Crosland in depth about TMSH a listen.

ARX Config, Day One

http://devcentral.f5.com/weblogs/dmacvittie/archive/2010/01/18/arx-config-day-one.aspx

In the first installment of what I'm hoping proves to be a long, detailed series describing his experiences with his ARX, Don dishes out a great intro post about getting his ARX out of the box and working. He's honest and gives plenty of details about both what he loved and what he…didn't, which I appreciate. It sounds like he also plans to go into detail about any troubles he's having or things that he finds that stand out to him and the users should know about. With his vast experience in the storage world, getting to see an ARX through his eyes is just about the next best thing to getting to fiddle with one yourself. So if you have any interest in learning what it's like to set up and start using an ARX device, I recommend keeping a keen eye on this series. Having no ARX experience myself I'm quite interested to get his impressions, so I'll be one of the subscribed readers too.

iRule Editor - Offline Editing

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=2385

Joe's amazing creation, the iRule Editor, just got better. He's released a couple new features for it recently but the one that caught my attention the most is something that people have been asking about for quite some time now: offline editing. The iRule Editor has previously been a 100% online tool. You'd fire it up, connect to your device and start editing away. But what if you're on a plane or just don't have a device to connect to? Well, you were out of luck. Even though you could save the iRules themselves to your on disk archive, the editor wouldn't allow you to edit them offline before. But now, you can. Keep in mind that you won't be able to use any syntax checking because that uses tmm on the BIG-IP to test compile the code, but you can edit to your heart's content along with all the handy features of the iRule Editor you've grown to love. Joe even took the time to go through a walkthrough of how this works and show you how to use the cool new feature in this video. This is a very cool improvement…thanks Joe!

Following Google's Lead on Security? Don't Forget to Encrypt Cookies

http://devcentral.f5.com/weblogs/macvittie/archive/2010/01/15/google-gmail-ssl-cookie-encryption.aspx

Last but certainly not least is Lori's post talking about SSL and why it isn't the only thing you need to think about when working on securing an application. Yes, SSL is an excellent and pretty standard first step to securing an online application these days. I, just like Lori, completely agree that you should be using SSL encryption as a security measure if you're at all concerned about your users or their data. Something Lori mentions though is spot on, "it’s not a panacea, especially where cookies are involved". Just because something is being encrypted across the wire doesn't mean that you can necessarily assume that it's going to be 100% safe once it gets where it's going. Data being stored on a client system, such as cookies that carry auth information, are a prime target for many malicious attacks trying to pry at user info. Cooke Encryption can be a powerful agent in stopping this and stepping up your security one more level. Have a look for yourself for a more detailed description of how this works.

There you have this week's DevCentral Top5. As always, feedback is welcomed and you can check out previous versions of the Top5 here - http://devcentral.f5.com/Default.aspx?tabid=101

#Colin

One of the new features added to BIG-IP in version 10.1 was the table command, implemented in iRules. Of all the new features I've seen, I have to say this one is easily one of my favorites. Hopefully by now you've seen Spark's amazing series of articles on the table command and have gotten some sort of understanding of what it is and can do. If not, I highly recommend checking out the first of his many fantastic docs here, to get started, then browse through them all when you can. They’re awesome, and well worth the read. Given the many capabilities of the new commands, it really pushes the boundaries for what you're able to accomplish with iRules. It not only makes for more options, but makes some things you could already do much, much simpler.

One of the many things that people seem to want to do often via iRules is rate limit connections. Whether they're limiting the number of HTTP connections to a given URI a user is allowed to have open, or how many connections a given virtual can have, they're always looking to track a given number of connections of a certain type over a given amount of time. While this was possible before, it was relatively clunky and complex. With the new table command, it has gotten significantly easier.

It has gotten so easy, in fact, that I found myself sitting in a meeting months ago when the table command was being revealed internally to a group of us iRuleish types and thinking about the possibilities. The person sitting next to me and I quickly found ourselves engaged in a conversation about just how simple it would be to write iRules to do this kind of thing now with the new command, and how much of a pain it was before, comparatively. He was talking about limiting the number of SSH connections to his system to keep out would be intruders, and we quickly white-boarded a simple version out, sans white board (verbally). When I later saw the finished product I had to share.

Here's a look at just how simple previously complex tasks can be made thanks to the table command and its ability to manage sub table entries. In this example you'll find a simple way to check for a given number of connections coming from a single IP address, within a configurable time period, and black list those connections for a separately configurable period of time if they exceed your allowed number of tries.

For instance, let's say you have some resource you want to rate limit access to. In this example it's an ssh server, but it could be anything. You want to make sure that any given IP address only opens up 1 connection every 10 seconds. This may seem strict, but for a resource like SSH, there shouldn't be many people that need to open more connections than that. Plus this is easily configurable, it's just an example. If, in this case, someone opens more than a single connection in a 10 second period, they get dropped any time they try to connect for 10 seconds. If they continue to offend and try to connect, they get blocked for even longer.

To look a bit more deeply at the way this is set up we simply look at the sub tables set up with the table command. When the initial request comes in, we look to see if it's in the "long_haul" table, meaning they're a double offender and locked out for 24 hours (86400 seconds). If they're not in that table, we check to see if they're in the "short_haul" table. Entries in this table only last 10 seconds, so they won't be in there unless they've tried to connect  within that period. If they're not in either sub table, then we add them to the shorter duration table and pass the traffic normally. Assuming they don't try to re-connect for 10 seconds, that's the last interaction they'll have with the iRule until next time they log in and all will be well.

If they do try again within 10 seconds, however, the iRule will find them in the short table, since the entry hasn't expired yet, and it will drop the connection. It will also then promote them to the longer duration table. This means that, because they are now suspected of mischievous activity, their connections to this resource will be dropped for 24 hours. Strict? Well yeah, but a great example of the kind of logic you can quickly and easily build with the table command in iRules. I might change these settings to allow for 3 connections in 10 seconds, rather than one, and to time someone out for 10 minutes, not 24 hours..but hey, that part's up to you. That's half of the beauty of a language like iRules. A great way to do this would be to simply increment the value found in the short_haul table until it hits whatever threshold you want, rather than promoting them the first time you find them in the short table. Once it hits say 5 or 10 tries, then promote their IP to the long_haul table for a longer lasting slap on the wrist. But those details are all up to you and your situation.

Now keep in mind with anything that's going to automatically start dropping connections you'll want to build some kind of a fail safe. Maybe a simple iRule on an internal only virtual that you can send IP addresses to to un-block them so they stop getting dropped. The last thing you want to do is start dropping your boss' connections because he got his login wrong, and not have an easy way to fix it. Just keep that in mind and tune the settings to your preference and you'll be set.

   1: rule rule_block_ssh_attack {

   2:   when RULE_INIT {

   3:     set static::short_life 10

   4:     set static::long_life 86400

   5:   }

   6:   when CLIENT_ACCEPTED {

   7:     set ip_addr [IP::client_addr]

   8:     set dest_addr [IP::local_addr]

   9:     set key "$ip_addr:$dest_addr"

  10:     set val [table lookup -notouch -subtable ssh_hosts_long $key]

  11:     if {$val == 1} {

  12:       log local0. "Dropped $ip_addr -> $dest_addr for the long haul."

  13:       drop

  14:     } else {

  15:       set val2 [table lookup -notouch -subtable ssh_hosts_short $key]

  16:       if {$val2 == 1} {

  17:         table set -subtable ssh_hosts_long $ip_addr 1 $static::long_life

  18:         log local0. "Dropped $ip_addr -> $dest_addr for the short haul."

  19:         drop

  20:       } else {

  21:         table set -subtable ssh_hosts_short $key 1 $static::short_life

  22:       }

  23:     }

  24:   }

  25: }

I’m positive there will be a thousand more examples of how cool the table command is and what you can do with it, but here’s one more added to Frank’s already great examples. Big thanks to user knox for the chat months ago, and the code.

iRules gained some new commands in version10.  The after command allows you to delay code execution, repeatedly execute a block of code, and maybe even make some of your old iRules better.  Check it out.

In this in-depth look at events and the order in which they execute all mystery surrounding which event fires when is removed.  If you've ever wanted to know where to put your code, the order events fire in, or more about how events themselves work, this is a must read.