DevCentral Weblogs

20 Lines or Less #12

Colin Walker — Thu, 24 Jul 2008 21:51:31 GMT

What could you do with your code in 20 Lines or Less? That's the question I ask every week, 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.

Here we go again, three more examples of the powerful and interesting things you can do with iRules in less than 21 lines. Dipping again into the forums, with a few tweaks here and there (don't worry, I stayed honest to the rule, just took out comments and extra case comparisons, that kind of thing), we've got an action packed 20LoL this week. Here we go:

SSL iRule on a non-SSL VIP

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=26299&view=topic

This is a great example of using a single iRule for both HTTP and HTTPS traffic. In the forum post Deb shows a cool trick to allow us to sneak SSL commands past the iRule interpreter so that they are there when we need them, if a cert is found, but aren't used when the connection turns out to be straight HTTP. Pretty cool stuff.

when HTTP_REQUEST {
HTTP::header replace ClientIP [IP::remote_addr]
if {[PROFILE::exists clientssl] == 1} {
    set cname "SSL::cipher name"
    set cbits "SSL::cipher bits"
    set cver "SSL::cipher version"
    HTTP::header replace SSLCipher [eval $cname]:[eval $cbits]-[eval $cver]
    if { [SSL::cert count] > 0} {
      HTTP::header replace SSLSubject [b64encode [X509::subject [SSL::cert 0]]]
      HTTP::header replace SSLClientCert [b64encode [SSL::cert 0]]
      HTTP::header replace WebProtocol "HTTPS-auth"
    } else {
      HTTP::header replace WebProtocol "HTTPS"
    }
} else {
    HTTP::header replace WebProtocol "HTTP"
}
}

Extracting DHCP Info

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=25727&view=topic

This example for extracting DHCP info is very specific. It's looking for option 82 (Support for Routed Bridge Encapsulation) which may not be particularly useful to everyone out there, but the example stands as a great display of how iRules can help you tear into almost any kind of data, even DHCP data, and make intelligent decisions or actions based on that. Sure, it might take some re-working for your purposes, but what a cool example to get started with!

when CLIENT_DATA {
binary scan [UDP::payload] x240H* dhcp_option_payload
set option 0
set option_length [expr {([UDP::payload length] -240) * 2 }]
for {set i 0} {$option != 52 && $i < $option_length} {incr i [expr { $length * 2 +2 }]} {
    binary scan $dhcp_option_payload x[expr $i]a2 option
    incr i 2
    binary scan $dhcp_option_payload x[expr $i]a2 length_hex
    set length [expr 0x$length_hex]
}
if { $i < $option_length } {
    incr i -[expr { $length * 2 -2 }]
    binary scan $dhcp_option_payload x[expr $i]a2 length_hex
    set length [expr 0x$length_hex]
    incr i 2
    binary scan $dhcp_option_payload x[expr $i]a[expr { $length * 2 }] circuit_id
} else {
    drop
}
}

URI re-writing based on Load Balancing decision

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=25791&view=topic

Talk about a chicken and egg demonstration. Hearing the title, you might think I have it backwards. When making this kind of decision in an iRule, the URI is often used to help make the load balancing decision. In this case, it's just the opposite. In this example we're letting the BIG-IP make a load balancing decision, then going back and updating the URI based on that decision, before the request is sent to the servers. Very cool stuff!

when HTTP_REQUEST_SEND {
set uri [string tolower [clientside {HTTP::uri}]]
log local0. "[IP::client_addr]:[TCP::client_port]: selected server details: [LB::server] - \$uri: $uri"
if {[IP::addr [LB::server addr] equals 10.207.225.101] or [IP::addr [LB::server addr] equals 10.207.225.102] or [IP::addr [LB::server addr] equals 10.207.225.103] }{
    log local0. "[IP::client_addr]:[TCP::client_port]: matched server check for .3 or .4"
    switch -glob [HTTP::uri] {
      "*/gsfo/gsfopub*" {
        clientside {HTTP::uri "/Async/CMReceive.ashx"}
        log local0. "[IP::client_addr]:[TCP::client_port]: updated URI to /Async/CMReceive.ashx"
      }
      "*/era/erapub*" {
        clientside {HTTP::uri "/Async/ERAReceive.ashx"}
        log local0. "[IP::client_addr]:[TCP::client_port]: updated URI to /Async/ERAReceive.ashx"
      }
      default {
        log local0. "[IP::client_addr]:[TCP::client_port]: didn't match URI checks"
      }
    }
}
}

There you have it, the forums deliver yet again. I have to say I love checking out all these cool, new, compact examples of iRules goodness. Many thanks to the awesome DevCentral community for their continued contributions. I'll see you next week for another 20 Lines or Less.

Technorati Tags: DevCentral,20 Lines or Less,iRules,DHCP,URI Rewriting,SSL Information,Colin Walker

#Colin

Madness? THIS. IS. SOA!

Lori MacVittie — Thu, 24 Jul 2008 11:35:05 GMT

There is an interesting war being fought in the blogosphere over the use (or overuse) of ESB (enterprise service buses) to build out a SOA (service oriented architecture). It certainly appears that Dave Linthicum is taking on the role of Leonidas and the Spartans at the battle of Thermopylae while everyone else is on the side of Xerxes and the Persians.

Dave is defending his view that ESBs are overused and often, apparently, misused against a host of ESB and SOA focused bloggers like Joe McKendrick and Jeff Schneider.

But everyone is talking in abstractions, and no one's really giving anyone a good idea of when to use an ESB or when to avoid them. No one seems to be looking at why people are or aren't using ESBs and getting to the root of the question - when are they appropriate for use in a SOA and when are they simply being implemented for the sake of being implemented?

So when should you consider implementing an ESB as part of your SOA?

1. You have a need to orchestrate services. Orchestration of services is one of the greatest strengths of an ESB. ESBs layer transaction management around orchestration of services and provide value when two or more services need to be composed into a single "transaction".

2. You have a need to integrate middleware messaging with applications. Let's face it, service-enabling MQ or JMS is a pain in the ... neck. An ESB makes this process simple and allows for orchestration of asynchronous services that might otherwise be difficult to integrate into an architecture.

3. Multi-application updates (a la integration). I know this is an unpopular thing to say, but sometimes the best solution to the problem of enterprise application integration in a SOA world is to use an ESB. ESBs are more than capable of orchestrating updates in a parallel processing scenario, and if you have multiple legacy applications or services that need updating during the same process, then an ESB is going to provide significant value in implementing such processes.

4. You plan on doing any of the above in the future. Laying the foundation for orchestration, integration, and parallel processing of messages means laying the foundation now, not rip-and-replace later. If there are plans in your SOA's future that would include an ESB, then implement sooner rather than later.

SOA is supposed to help align IT with the business. If you need an ESB, or three or ten, to accomplish that goal, then that's what you need to do. While it may not be a "pure" SOA in implementation, if you're staying true to its goal then it's definitely a "pure" SOA in design and intent.

Technorati Tags: MacVittie,F5,ESB,SOA,architecture,enterprise architecture,McKendrick,Linthicum,EAI,orchestration

Taco Tuesday with Jason Hoffman, Joyent CTO

Colin Walker — Wed, 23 Jul 2008 18:09:39 GMT

So it looks like Joe and I are going to have to take a trip down to San Fran to check out Nick's Crispy Tacos with Jason Hoffman, CTO and co-founder of Joyent. Jason puts on a "Taco Tuesday" on the third Tuesday of just about every month. We've been invited down to check it out and geek out over the hawesome iRules/iControl/Ruby/*Nix/geeky stuff they're doing. Yeah...I'm not completely geeking out and excited, honest. Don't worry though, we'll try to make the best of it.

We got a fantastic opportunity today to talk with Jason about Joyent, what they're doing, their architecture, their background, etc. and how they're heavily leveraging F5 technology to make it all happen. For those of you that don't know, Joyent is a long-time F5 customer that provides a wickedly cool, scalable, flexible cloud infrastructure to users ranging anywhere from the Mom and Pop size to truly robust Enterprise level applications. You may have seen Joe's blog post about Joyent hosting LinkedIn's BumperSticker Facebook app that recently surpassed a billion page views per month. That spurred an offer to chat, and Jason was more than happy to oblige.

It was absolutely fantastic to talk to Jason who himself is an avid engineer that's got a long history with Unix and many of the flavors of coding that go along with it. As one of the first major adopters of Ruby and, in fact, the very first person to check in source to the Rails source control system, he definitely knows what he's talking about when it comes to *Nix programming, Ruby, and RoR. It turns out we even share a common love for and history with FreeBSD, go figure.

Over the course of our discussion we got to chat with Jason about his role at Joyent, what they're delivering to users, why it's unique and powerful, obstacles they faced along they way, how they got around them which, I'm happy to say, largely included F5 technology and specifically iRules and iControl, and many other such things impressively full of win. From many of their security policies relying on iRules instead of FireWalls, to iControl being an integral part of their provisioning system, to building iRules as solutions to countless customer problems or requirements, these guys are definitely power users and avid DevCentral members, I'm happy to say.

We also got to talk about the modern application, how it's architected, how the old school ways of thinking don't apply anymore and the massive benefits that can come from allowing yourself to see the possibilities with a modern, flexible, layered architecture. This architecture with powerful caches, application aware network devices serving large portions of the application functionality, and scalable, interchangeable back ends thanks to the load balancing that also occurs at that tier is hugely powerful and really more and more of a "must have" as things continue to progress in the application and application delivery world. Pretty darn cool stuff to hear from a PhD helping to run a hugely popular and successful hosting company. How's that for real world application?

This is the exact message I (we) have been pushing for a long time. Every time I talk about "preaching the good word", this is what I'm talking about. Times have changed, technology has improved, and F5 can be a big part of building a powerful, flexible, scalable, reliable architecture if you just let yourself think about things in the new, more modern world that Jason and Joyent have fully embraced. It's allowing them to be as powerful and usable as they are at extremely reasonable costs with incredible scalability as needed.

Check out the podcast to get more of the details. Obviously I'm excited, and am currently trying to refrain from a big squeeeee of geekitude, but that's just how I get when I get to riff about awesome technology with even more awesome people.

Stay tuned for the follow up where Joe and I tear into some tacos, margaritas and hopefully some iControl/Ruby/iRules with Jason down in his neck of the woods. Not that it's been approved yet or anything, but hey, I can hope, right?

Thanks again Jason for the great chat, and keep up the killer work.

Technorati Tags: DevCentral,iRules,iControl,Ruby,iContRuby,LinkedIn,FaceBook,BumperSticker,Joyent,Jason Hoffman,Colin Walker

#Colin

4 reasons not to use mod_security

Lori MacVittie — Wed, 23 Jul 2008 11:53:54 GMT

Apache is a great web server if for no other reason than it offers more flexibility through modules than just about any other web server. You can plug-in all sorts of modules to enhance the functionality of Apache.

But as I often say, just because you can doesn't mean you should.

One of the modules you can install is mod_security. If you aren't familiar with mod_security, essentially it's a "roll your own" web application firewall plug-in for the Apache web server.

Some of the security functions you can implement via mod_security are:

Simple filtering
Regular Expression based filtering
URL Encoding Validation
Unicode Encoding Validation
Auditing
Null byte attack prevention
Upload memory limits
Server identity masking
Built in Chroot support

Using mod_security you can also implement protocol security, which is an excellent idea for ensuring that holes in protocols aren't exploited. If you aren't sold on protocol security you should read up on the recent DNS vulnerability discovered by Dan Kaminsky - it's all about the protocol and has nothing to do with vulnerabilities introduced by implementation.

mod_security provides many options for validating URLs, URIs, and application data. You are, essentially, implementing a custom web application firewall using configuration directives.

If you're on this path then you probably agree that a web application firewall is a good thing, so why would I caution against using mod_security?

Well, there's four reasons, actually.

It runs on every web server. This is an additional load on the servers that can be easily offloaded for a more efficient architecture. The need for partial duplication of configuration files across multiple machines can also result in the introduction of errors or extraneous configuration that is unnecessary. Running mod_security on every web server decreases capacity to serve users and applications accordingly, which may require additional servers to scale to meet demand.
You have to become a security expert. You have to understand the attacks you are trying to stop in order to write a rule to prevent them. So either you become an expert or you trust a third-party to be the expert. The former takes time and that latter takes guts, as you're introducing unnecessary risk by trusting a third-party.
You have to become a protocol expert. In addition to understanding all the attacks you're trying to prevent, you must become an expert in the HTTP protocol. Part of providing web application security is to sanitize and enforce the HTTP protocol to ensure it isn't abused to create a hole where none previously appeared. You also have to become an expert in Apache configuration directives, and the specific directives used to configure mod_security.
The configuration must be done manually. Unless you're going to purchase a commercially supported version of mod_security, you're writing complex rules manually. You'll need to brush up on your regular expression skills if you're going to attempt this. Maintaining those rules is just as painful, as any update necessarily requires manual intervention.

Of course you could introduce an additional instance of Apache with mod_security installed that essentially proxies all requests through mod_security, thus providing a centralized security architecture, but at that point you've just introduced a huge bottleneck into your infrastructure. If you're already load-balancing multiple instances of a web site or application, then it's not likely that a single instance of Apache with mod_security is going to be able to handle the volume of requests without increasing downtime or degrading performance such that applications might as well be down because they're too painful to use.

Centralizing security can improve performance, reduce the potential avenues of risk through configuration error, and keeps your security up-to-date by providing easy access to updated signatures, patterns, and defenses against existing and emerging web application attacks. Some web application firewalls offer pre-configured templates for specific applications like Microsoft OWA, providing a simple configuration experience that belies the depth of security knowledge applied to protected the application. Web application firewalls can enable compliance with requirement 6.6 of PCI DSS.

And they're built to scale, which means the scenario in which mod_security is used as a reverse proxy to protect all web servers from harm but quickly becomes a bottleneck and impediment to performance doesn't happen with purpose-built web application firewalls.

If you're considering using mod_security then you already recognize the value of and need for a web application firewall. That's great. But consider carefully where you will deploy that web application firewall, because the decision will have an impact on the performance and availability of your site and applications.

Technorati Tags: MacVittie,F5,application security,security,web application firewall,http,internet,web,microsoft,apache,mod_security,Kaminsky,protocol security

New ASM Discussion Forum is Live

Jeff Browning — Tue, 22 Jul 2008 20:12:25 GMT

After many requests, we've just launched a new discussion area for folks that want to talk about the F5 Application Security Module (ASM). This is a new opportunity for the community - existing users or those just curious about ASM - to post questions, share ideas, and generally discuss the possibilities and solutions available with ASM.

To learn more about ASM, you can go here. When you combine ASM with other technologies from folks like our friends at White Hat Security, there are some interesting applications and scenarios that will surely spark some interesting dialog.

You know what I like most about this new Forum? Some of the most enthusiastic supporters were actually our own ASM team. They're already active in the other forums, passionate about this technology, and are excited to discuss ASM with the DevCentral community and you.

So, have at it and enjoy.

Technorati Tags: devcentral, ASM, application security, white hat security, jeff browning

Your Stack Trace, Show It To Me

Lori MacVittie — Tue, 22 Jul 2008 14:46:15 GMT

Of all the reasons you need an application delivery controller capable of bi-directional inspection of application data this is one of the best. I was trying to check out the results of a poll on PollDaddy.com and ended up with this beautiful Microsoft .NET error page, filled with so much valuable information that potential attackers must even now be laughing in that "evil genius" laugh you so often hear in retro-cartoons.

This error page tells me so many things about the application, it's environment, and its associated infrastructure that it should be a crime to let this information out. I know it's a Microsoft .NET C# application, and what the underlying directory structure looks like. I know it's using a third party library for authentication and authorization (and where it's located) and I can tell you exactly what version of .NET is running (Microsoft .NET Framework Version:2.0.50727.1433; ASP.NET Version:2.0.50727.1433).

I also get an idea of internal data structure, as a nice piece of code is included in the error page. Hmmm...looks like "user ids" are numeric in the database.

Now I'm no evil genius, so I can only imagine just how much this tells a real evil genius. I do know, however, that this simply an unacceptable security practice and that it should never happen. Ever.

We often discuss catching "errors", but that's usually wrapped around catching 404 (not found) errors. Using iRules you can easily catch 500 (Internal server errors) as well as any other HTTP status code.

And even if the status code somehow comes back as "200 OK" but the content is full of juicy application and infrastructure information, you can use iRules to deal with it. iRules can verify that the content of a page is what it should be and if isn't, you can do something about it. Rewrite it. Change it. Redirect the user to a new page. Show a page full of dancing bananas or a picture of a whale. Whatever you want.

The point is that you recognize when information that may lead to or assist in perpetrating a breach is being presented to users and that you prevent it from happening. The chances of the information being used against you is minimal, but when you have the opportunity to mitigate that risk entirely, why wouldn't you?

Technorati Tags: MacVittie,security,data scrubbing,F5,iRules,application delivery,application security,Microsoft,polldaddy.com

Interactive F5 SOA Reference Architecture

Lori MacVittie — Tue, 22 Jul 2008 10:17:59 GMT

I do an awful lot of talking about SOA: problems, challenges, concepts, solutions, security, products. But I don't often present "the big picture", and certainly rarely discuss how F5 and SOA go together like ice-cream and pretzels. I know, that isn't a traditional simile, but if you've ever tried hot pretzels and ice-cream you might agree with me in saying that while they don't sound like they go together they really do, and they do so well.

It's also applicable because when you think of ice-cream you don't immediately think of pretzels, and I'm fairly certain when you think of SOA you don't think of F5. But once you've tried ice-cream and pretzels, you probably will associate the two, and the same is true of SOA and F5.

But it's a lot less of an investment to run out and grab a hot pretzel and some ice-cream than it is to invest in all the products that make up an application delivery network. So you probably want to know a bit more before you consider it an option.

SOA reference architectures are nothing new, and there's a fairly well-defined reference architecture model for folks to use in order to fit all the applicable pieces together and understand what each entails. So what this interactive presentation offers is a look at F5 and how it fits into that reference architecture in an interactive Articulate presentation, and the suggestion to go ahead - try the pretzel with some ice-cream.

Launch the Interactive F5 SOA Reference Architecture.

Additional resources:

F5 SOA Reference Architecture (White Paper)

SOA Challenges and Solutions (White Paper)

Technorati Tags: MacVittie,F5,SOA,application delivery,web services,HTTP,internet,web,architecture

Does your virtualization strategy create an SEP field?

Lori MacVittie — Mon, 21 Jul 2008 10:33:35 GMT

There is a lot of hype around all types of virtualization today, with one of the primary drivers often cited being a reduction in management costs. I was pondering whether or not that hype was true, given the amount of work that goes into setting up not only the virtual image, but the infrastructure necessary to properly deliver the images and the applications they contain.

We've been using imaging technology for a long time, especially in lab and testing environments. It made sense then because a lot of work goes into setting up a server and the applications running on it before it's "imaged' for rapid deployment use. Virtual images that run inside virtualization servers like VMWare brought not just the ability to rapidly deploy a new server and its associated applications, but the ability to do so in near real-time.

But it's not the virtualization of the operating system that really offers a huge return on investment, it's the virtualization of the applications that are packaged up in a virtual image that offers the most benefits. While there's certainly a lot of work that goes into deploying a server OS - the actual installation, configuration, patching, more patching, and licensing - there's even more work that goes into deploying an application simply because they can be ... fussy. So once you have a server and application configured and ready to deploy, it certainly makes sense that you'd want to "capture" it so that it can be rapidly deployed in the future.

Without the proper infrastructure, however, the benefits can be drastically reduced. Four questions immediately come to mind that require some answers:

Where will the images be stored?

How will you manage the applications running on deployed virtual images?

What about updates and patches to not only the server OS but the applications themselves?

What about changes to your infrastructure?

The savings realized by reducing the management and administrative costs of building, testing, and deploying an application in a virtual environment can be negated by a simple change to your infrastructure, or the need to upgrade/patch the application or operating system. Because the image is a basically a snapshot, that snapshot needs to change as the environment in which it runs changes. And the environment means more than just the server OS, it means the network, application, and delivery infrastructure.

Addressing the complexity involved in such an environment requires an intelligent, flexible infrastructure that supports virtualization. And not just OS virtualization, but other forms of virtualization such as server virtualization and storage or file virtualization. There's a lot more to virtualization than just setting up a VMWare server, creating some images and slapping each other on the back for a job well done. If your infrastructure isn't ready to support a virtualized environment then you've simply shifted the costs - and responsibility - associated with deploying servers and applications to someone else and, in many cases, several someone elses.

If you haven't considered how you're going to deliver the applications on those virtual images then you're in danger of simply shifting the costs of delivering applications elsewhere. Without a solid infrastructure that can support the dynamic environment created by virtual imaging the benefits you think you're getting quickly diminish as other groups are suddenly working overtime to configure and manage the rest of the infrastructure necessary to deliver those images and applications to servers and users.

We often talk about silos in terms of network and applications' groups; but virtualization has the potential to create yet another silo, and that silo may be taller and more costly than anyone has yet considered.

Virtualization has many benefits to you and your organization. Consider carefully whether you're infrastructure is prepared to support virtualization or risk discovering that implementing a virtualized solution is creating an SEP (Somebody Else's Problem) field around delivering and managing those images.

Technorati Tags: MacVittie,F5,virtualization,os virtualization,vmware,application delivery,infrastructure,strategy,server virtualization,file virtualization,storage virtualization

DevCentral Top5 7/18/2008

Colin Walker — Fri, 18 Jul 2008 19:39:05 GMT

This week's Top5 takes you from Application Health Monitoring to queues formed by CS students. The team has been hard at it, as always, and there's plenty to dig through on DevCentral this week. Choosing just five things to talk about seems to be an increasingly difficult task thanks to the mounds of content out there every week, but that's a good problem to have. Here are this week's Top picks:

Scaling Ruby on Rails to 1 Billion Page Views a Month

http://devcentral.f5.com/weblogs/Joe/archive/2008/07/15/scaling-ruby-on-rails-to-1-billion-page-views-a.aspx

Joe talks about Joyent's successful scaling of their Ruby on Rails deployment for Linkedin's "BumperSticker" Facebook app to a billion page views a month. That's some pretty serious traffic, and an awesome accomplishment to be able to tout. It's doubly important due to the naysayers out there that would have you believe that Ruby on Rails doesn't scale for high traffic situations. Joe talks about some of the finer details of this recently announced achievement as well as inviting them to jump on a DC podcast with us, which I'm pleased to say they agreed to. Definitely keep an eye out for that chat!

Storage - Where do we go from here?

http://devcentral.f5.com/weblogs/dmacvittie/archive/2008/07/14/3449.aspx

It's no surprise to anyone that's been around computers even a short while that data storage is growing at an amazing rate, as is the demand for storage space due to increased use of media and more and more users of resources already in place. Don shows off some of his in-depth experience in the storage arena by delving into a discussion of different issues facing the storage community these days. He talks about stale data, data tiering, high-speed filers and more. Discussing about different methods of using and dealing with each, this post is definitely worth a read.

20 Lines or Less #11

http://devcentral.f5.com/weblogs/cwalker/archive/2008/07/16/20-lines-or-less-11.aspx

Back on track with three examples each weighing in under 21 lines, this week's 20LoL continues to demonstrate the power you can pack into easily written and managed, short iRules. Feel free to drop in a request for an iRule you need written to solve a certain problem or requirement and who knows, your solution might just be featured in the next 20 Lines or Less. Take a peek and tune in every week as we continue on our exploration of the possibilities that iRules offers to deliver compact yet powerful solutions.

DC Post of the Week - Application Health Monitors: Alternate Ports

http://devcentral.f5.com/weblogs/dctv/archive/2008/07/17/3461.aspx

Deb dives into the Post of the Week yet again to highlight a question asked in the forums, giving an in-depth answer and example to go with it. This week she's addressing Health Monitors and trying to monitor a member of a pool on a port not configured for the pool. Tune in for a walk-through and discussion of how this can be done, benefits, caveats and more.

A queue is a (a) line (b) a pony tail (c) a data structure

http://devcentral.f5.com/weblogs/macvittie/archive/2008/07/14/3448.aspx

In our only multiple choice blog post of the week Lori agrees with a fellow blogger's assertion that "The most agile developers, however, are those who approach programming with a firm grounding in computer science." I suppose that means I'm off that list, but I won't hold that against her. This insightful and interesting post discusses the way that programming has evolved and works in today's world, and why those computer science degrees that actually focus on, well, computer science, might be more valuable than some people think. Take a look inside to see why.

Safely through another five awesome topics from DevCentral, here we are, at the end of this week's Top5. I'll be back next week with more DC goodness. Until then, feel free to drop me any feedback you might have.

Technorati Tags: DevCentral,DC Top5,Colin Walker

#Colin

Three Web Application Vulnerabilities You Need to Know

Lori MacVittie — Fri, 18 Jul 2008 18:52:32 GMT

Via Hacker News and Peteris Kumins' blog on programming, hacking, software reuse and stuff comes the latest Google tech talk, this one on web application vulnerabilities and "how cybercriminals steal money".

While Peteris and Google are targeting web developers with this informative video talk, it's a great resource as well for security folks as well as network administrators tasked with understanding how to thwart web application attacks.

Even if you've deployed a web application firewall to protect you from these kinds of vulnerabilities, it's still a great idea to watch this one and get a better understanding of the attacks.

The three vulnerabilities covered are:

SQL Injection
Cross-Site Request Forgery (XSRF)
Cross-Site Script Inclusion (XSSI)

The video and direct link are included here as well, but check out Peteris' blog for an overview of interesting points in the tech talk.

Direct URL: http://www.youtube.com/watch?v=jc6Q1uCnbMo

Technorati Tags: MacVittie,security,Google,web application firewall,vulnerabilities,SQL injection,XSRF,XSSI,developers

Links, Sex, and Application Fluency

Lori MacVittie — Fri, 18 Jul 2008 11:11:27 GMT

I ran across an interesting site containing an algorithm that predicts your sex based on browser history. This algorithm uses demographics from popular sites, determines which popular sites you have visited by digging through your browser history, and then predicts what gender you are based on your browsing habits.

This algorithm sounds a lot like an adaptation of the Turing Test. But instead of predicting which of two participants in the test is human, this one predicts what gender they are. The Turing Test has long been the standard for judging the intelligence of a computer system, even though it is flawed in many ways.

The Turing Test, and this entertaining site attempting to guess my gender, are similar in nature to the way that traffic shaping/management devices have traditionally identified applications. And like this browser gender test, they are often wrong.

That's because traditional traffic shaping/management devices originally based their assumptions on ports and protocols. If it was served on port 80 over HTTP, then it must be HTTP. These devices learned, eventually, that this information was not enough upon which to base identification when every application out there attempted to circumvent corporate firewalls by running on port 80 over HTTP.

The devices, however, were primarily packet-based. This meant they inspected individual packets, which may not carry enough information to make a determination regarding which application is being used. They tried "signatures", but found that even that failed to accurately identify the majority of applications.

That's why flow-based inspection is so important. We call that application fluency, and it is the ability to examine and inspect flows rather than packets. Flows are built by reassembling packets into a full application message at which time it is inspected and a determination made on what it really is.

Application fluency is the cornerstone of a wide variety of technologies related to application delivery. Without application fluency you can't provide web application firewalling, you can't optimize and accelerate specific applications like SharePoint or Exchange, and you certainly can't intelligently route application messages. In order to apply policies, whether related to security or acceleration or routing, you first have to determine what the application is. The same security and routing policies that should be applied to IM (Instant Messaging) are not necessarily the right ones to apply to your web application. Even though both may be transported over HTTP and through port 80. You need to be able to accurately identify the application before you can start applying policies.

Application delivery requires application fluency; intelligence. It can't just look at ports or protocols to determine how best to deliver an applications. It needs to understand the application, to really know - not just predict based on a few attributes - what it is in order to ensure that it is delivered fast and securely.

If it doesn't, you could end up with a solution that might decide your SharePoint application is really PeopleSoft much in the same way the test decided I was probably male (61% likelihood).

Technorati Tags: MacVittie,F5,HTTP,web,internet,applications,SharePoint,PeopleSoft,Exchange,Microsoft,Turing test,application fluency

When SOAP has failed.

Don MacVittie — Thu, 17 Jul 2008 18:27:22 GMT

Interesting read over at The Register that posits the question "will Flex SOAP 1.1 work with .NET betas?"

The steps he went through and how he got things going was mildly interesting, more interesting to me was that he even had to ask.

I cannot say how happy I am that the answer was a resounding "Yes, they work together", because if we ever see a "no, these two mainstream Web Services products don't inter-operate" (ignoring those first few painful versions of yesteryear when people were figuring it out), then SOAP has well and truly failed.

The entire purpose of SOAP is interoperability, we shouldn't need to ask these questions. Indeed, they shouldn't even occur to us and the environment should be such that if we try and they don't work together, we assume that we did something wrong.

But some vendor will do it, guaranteed. Trying to get you to use their tools only, they'll fail to support the standard correctly. When that happens, we, as an industry, need to slap them.

Until then, we get to continue to flourish in Nirvana.

Don.

/reading: Programming Ruby - free electronic version.

Share this post :

I say cloud, you say grid

Lori MacVittie — Thu, 17 Jul 2008 11:49:49 GMT

With more and more focus on cloud computing one theme seems to be running consistently: the "cloud" is public, and anyone who claims to be building a "private" cloud, a.k.a. mini-cloud or enterprise cloud, is just doing it wrong.

John Foley @ InformationWeek has it mostly right when he says that what's important is the technology.

The Rise of Enterprise-Class Cloud Computing

That's an oxymoron since cloud computing, by definition, happens outside of the corporate data center, but it's the technology that's important here, not the semantics. [emphasis added]

Focusing on what you call your compute environment based on whether it's public or private seems a bit silly. There are some who try to elucidate the difference between "grid" and "cloud" computing, and do manage to make a technical distinction between the two.

RightScale's blog quoting Rich Wolski

Grid computing has been used in environments where users make few but large allocation requests. For example, a lab may have a 1000 node cluster and users make allocations for all 1000, or 500, or 200, etc. So only a few of these allocations can be serviced at a time and others need to be scheduled for when resources are released. This results in sophisticated batch job scheduling algorithms of parallel computations.

Cloud computing really is about lots of small allocation requests. The Amazon EC2 accounts are limited to 20 servers each by default and lots and lots of users allocate up to 20 servers out of the pool of many thousands of servers at Amazon. The allocations are real-time and in fact there is no provision for queueing allocations until someone else releases resources. This is a completely different resource allocation paradigm, a completely different usage pattern, and all this results in completely different method of using compute resources.

Given that definition there are enterprises engaged in building their own mini-clouds: private, real-time on-demand data centers that service only one entity (the organization) with potentially many customers (business units).

"Private" clouds employ metering (chargebacks), rely heavily on multiple forms of virtualization, and provision resources in real-time using an on-demand model. That's a cloud as much as it is a grid.

Like SOA, it's not as if there's some certification board that's going to tell you that you're doing it "wrong", or "right" for that matter. SOA, grid, cloud - it's all about meeting the needs of the business in an operationally and financially efficient way. If that means a private cloud, than that's what you build. If that means using a public cloud, that's what you use.

Cloud computing is no more required to be public than any other computing model. It's just that - a model - and where it is implemented is of no consequence.

Besides, I thought part of cloud computing was that we weren't supposed to care about location anyway.

What are your plans for cloud computing?

We're going to ignore the whole thing
We're likely to use an external cloud provider for as much as possible
We're likely to use an external cloud provider for some applications and services
We're rolling our own mini-clouds

> View Results
PollDaddy.com

Technorati Tags: MacVittie,F5,cloud computing,cloud computing infrastructure,grid computing,mini-cloud,private cloud,RightScale,Amazon

20 Lines or Less #11

Colin Walker — Wed, 16 Jul 2008 23:08:58 GMT

This week's 20LoL comes care of both the codeshare and the forums alike. I got to deal with a couple of particularly cool forum posts this week, one of which made the list, as did an iRule from the infamous hoolio himself. Dealing with HTTP and ranging from spiders to working around a work-week, these examples are yet more ways you can leverage iRules in less than 21 lines. Here we go:

Rate Limiting Search Spiders

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=26064&view=topic

Spiders on the web aren't the same pests as spiders in your house, but they can certainly have adverse effects if they're making an inordinate number of requests to your web-servers, and driving the load up. Here's a cool example of how to avoid just that scenario. We've seen something similar a long time ago on DevCentral for Network Computing, but this is a good refresher.

when RULE_INIT {
array set ::active_crawlers { }
set ::min_interval 1
}
when HTTP_REQUEST {
set user_agent [string tolower [HTTP::header "User-Agent"]]
# Logic only relevant for crawler user agents
if { [matchclass $user_agent contains $::Crawlers] } {
    # Throttle crawlers.
    set curr_time [clock seconds]
    if { [info exists ::active_crawlers($user_agent)] } {
      if { [ $::active_crawlers($user_agent) < $curr_time ] } {
        set ::active_crawlers($user_agent) [expr {$curr_time + $::min_interval}]
      } else {
        reject
      }
    } else {
      set ::active_crawlers($user_agent) [expr {$curr_time + $::min_interval}]
    }
}
}

Compression During the Work Week

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&view=topic&postid=25992

Coming through with a great example of how to have compression enabled only from 8AM-5PM, otherwise known as the normal US Workday, citizen_elah shows of his iRules kung fooery to help a fellow community member out. This same logic could be applied to almost anything else, besides compression, making this a great iRule to keep around in your back pocket.

 when HTTP_RESPONSE { 
   set time_r [split [clock format [clock seconds] -format {%H:%M} ] " "] 
   set time_f [expr [expr [lindex $time_r 0]*100] + [lindex $time_r 1]] 
   if { not(($time_f >= 0800) && ($time_f <= 1700)) } { 
     COMPRESS::disable 
   } 
 }

I then came through and offered some optional optimization, so I guess this could be considered your bonus-rule for the week. It's easy when someone like elah does the legwork up front. ;) Check the link to see the extra example.

Fully Decode URI

http://devcentral.f5.com/wiki/default.aspx/iRules/FullyDecodeURI.html

Representing the last leg of this HTTP tri-ath-a-post is an entry from our illustrious iRules CodeShare. This example shows how to be sure you're FULLY decoding your URI before processing. It correctly points out that sometimes encoded characters can contain encoded characters can contain encoded characters can contain....well, you get the point. See how one person decided to work around such issues in a scant 11 lines of code.

when HTTP_REQUEST {
  # decode original URI.
  set tmpUri [HTTP::uri]
  set uri [URI::decode $tmpUri]

  # repeat decoding until the decoded version equals the previous value.
  while { $uri ne $tmpUri } {
    set tmpUri $uri
    set uri [URI::decode $tmpUri]
  }
  HTTP::uri $uri

  log local0. "Original URI: [HTTP::uri]"
  log local0. "Fully decoded URI: $uri"
}

There you have it, three more choice examples of iRules goodness in 20 Lines or Less. Tune in again next week!

Technorati Tags: DevCentral,20 Lines or Less,HTTP,Colin Walker

#Colin

Dear Plurk: We're Through. Kthxbye.

Lori MacVittie — Wed, 16 Jul 2008 20:16:43 GMT

Plurk. Twitter. Plurk? Twitter? When Twitter is down (which is often) many denizens of the "life streaming" site rush to plurk to continue sharing news, blog posts, gossip, and general tidbits of interest.

The difference between the two is that Twitter doesn't put any pressure on your to tweet. Sure, your "followers" can "nudge" you to update, but it's not the headless-dog-staring-at-you-on-every-page pressure of plurk. If you haven't plurked, that may be lost on you. So let me explain.

Plurk is partially a karma-based site. You can raise your karma by inviting friends, gaining followers, plurking, and responding to other plurks. There's an icon of a dog that starts out headless on every page and as your karma increases your dog gets more body parts and accoutrements. Cute, right?

Except that the karma system feels too much like high school. Even the encouragement to meet other plurkers makes you feel like you're a loser: "Check out more interesting plurkers" it says. As if you're not interesting enough to check out.I know, it could be read as "more" as in "other" but when that headless dog is staring you in the face you just know it means "you aren't interesting". It's a popularity contest that rewards people with more social skills than I am apparently endowed with special emoticons (I admit I will miss the dancing banana) and a full bodied dog.

So the more questions you pose, and the more answers you give, the better your karma. But if you're like me, this begins to feel like a popularity contest. If I don't say the right things or ask the right questions or share the right sites, no one will respond to me. Not only does this keep my karma from rising but it actually decreases my karma.

Twitter doesn't judge me. It accepts me for who I am. It doesn't grade my tweets, it doesn't make fun of me with headless dogs for not being social enough. It doesn't urge me to become a social networking pimp by inviting my friends to plurk in order to increase my karma. It doesn't distinguish between "friends" and "fans", or make you feel bad that you don't have fans, you just have friends.

Plurk just makes me feel like an awkward teenage geek (again) and honestly, I prefer the simpler interface of Twitter and the quality of information and questions shared among those I choose to follow.

I guess I just prefer a social networking site that doesn't punish me for being me.

So so long, Plurk, and thanks for all the fish.

Technorati Tags: MacVittie,Twitter,plurk,social networking,karma,geek