Lori MacVittie

4 reasons not to use mod_security

Lori MacVittie — Wed, 23 Jul 2008 12: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 - but not mod_security - 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

Categories: Development and General , Security

Your Stack Trace, Show It To Me

Lori MacVittie — Tue, 22 Jul 2008 15: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

Categories: Development and General , Security

Interactive F5 SOA Reference Architecture

Lori MacVittie — Tue, 22 Jul 2008 11: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

Categories: Development and General , General SOA , SOA Delivery

Does your virtualization strategy create an SEP field?

Lori MacVittie — Mon, 21 Jul 2008 11: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

Categories: Development and General

Three Web Application Vulnerabilities You Need to Know

Lori MacVittie — Fri, 18 Jul 2008 19: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

Categories: Development and General , Security , Web 2.0 Security

Links, Sex, and Application Fluency

Lori MacVittie — Fri, 18 Jul 2008 12: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

Categories: Development and General

I say cloud, you say grid

Lori MacVittie — Thu, 17 Jul 2008 12: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

Categories: Development and General

Dear Plurk: We're Through. Kthxbye.

Lori MacVittie — Wed, 16 Jul 2008 21: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

Categories: Development and General , Randomness

Horizontal and Vertical Security: Which do you need?

Lori MacVittie — Wed, 16 Jul 2008 15:24:14 GMT

No one questions the need to secure applications today, we just argue over how we should do it. Let's take a break for a minute from that debate to ensure that we don't get so focused on layer 7 (application) that we forget about the rest of the stack and the importance of securing it as well.

Just as a chain is only as strong as its weakest link, an application is only as secured as its most vulnerable layer in the stack. If your application is well secured, but the network layer (IP) is wide open, you're at risk.

SANS Internet Storm Center has some interesting stats on the "survival" time of a Windows-based server on the public internet. The "survival" time is the time it takes for an unpatched Windows server to be p0wned once it's publicly accessible.

Now no reasonable administrator is going to put an unpatched, unprotected server running any operating system on the public Internet, so this information isn't as interesting as it first sounds. What is exceedingly interesting, however, is the list of "ports" and applications that are attacked when a system is available for public access. The list contains both what we would consider "applications" as well as protocols up and down the TCP/IP stack. It includes protocols from layer 4 to layer 7 such as: FTP, HTTP, DNS, MSSQL, and NetBIOS.

What this simple exercise should teach us is that it's not enough to just be concerned with application security just at the application layer; it's imperative that we consider all layers of the stack when we're trying to secure an application and ensure that layer 2, 3, and 4 is just as secure as layer 7. As the recent DNS vulnerability discovered by Dan Kaminsky proved, it's just as important to be concerned about protocols and their security as it is the application and its (lack of) security.

That means securing the platforms on which applications are deployed as well as application delivery solutions through which they are delivered and the routers and switches which ultimately route the data in and out of the data center. Every link in the chain must be secured, and that means vertically (platform and OS) as well as horizontally (network path). Just as you wouldn't consider putting an unpatched server in public reach, you probably wouldn't consider putting putting up a patched server without the protection of a firewall.

But we also need to consider the rest of the horizontal and the vertical chains that protect our applications to ensure that they are all properly hardened. So the question, "Which do you need?" is fairly easily answered. "You need both."

Leaving even one weak link in either direction is likely to result in your organization becoming yet another statistic.

Technorati Tags: MacVittie,F5,security,applications,protocols,web,internet,patches,Windows,Microsoft,SANS,DNS,Kaminsky

Categories: Development and General , Security

Recession Proofing Your Application Infrastructure

Lori MacVittie — Tue, 15 Jul 2008 12:16:32 GMT

Cisco CEO John Chambers recently announced that the slowdown in corporate IT spending will continue until 2009.

NEW YORK (Fortune) -- Cisco chief John Chambers has some bad news for the technology sector: He no longer expects the recent slowdown in tech spending to pick up until next year at the earliest.

IT is still spending dollars, but not as freely as in past years. In a constrained budgetary environment, IT now has to ask the question, "What's going to give me the best bang for my buck?"

What makes this question even more difficult to answer is that IT still has to address all the same concerns it always has: how to increase capacity, improve application performance, and maintain security. It's just that now it has a more limited budget within which it must work.

Jim Metzler, vice president of Ashton, Metzler & Associates, has an answer to that question. You may recall that Mr. Metzler is a proponent of knocking down the silos that exist within IT in order to successfully deliver applications in a secure, fast, and available manner.

He recently completed another brief, this time focusing on the best way to maximize IT investments in a constrained economy.

From Mr. Metzler's latest brief

In demanding economic times, organizations must focus on reducing budgets. This brief will discuss effective technologies that network teams should deploy to help their businesses succeed, even when faced with budget constraints. Also, this brief will point out how these technologies enable network teams to support key business initiatives as well as reduce cost.

Despite a constrained economy, market research indicates CIOs’ top three business priorities in 2008 are:

Business Process Improvement
Attracting and retaining new customers
Creating new products and services

This research also indicates that CIOs’ top three technology priorities are:

Business intelligence applications
Enterprise applications such as ERP and CRM
Servers and storage technologies

Even in a booming economy, network teams are challenged to support these priorities.

Assuming Mr. Chambers is correct, and organizations will continue to be financially constrained throughout 2008 and into 2009, Mr. Metzler's brief on Maximizing IT Investments is an excellent read with solid advice on how best to spend what few dollars you may have in order to see the greatest "bang for your buck" while meeting the priorities of the organization.

Get the brief here: Maximizing IT Investments: Recession Proofing your Network

Technorati Tags: MacVittie,F5,Metzler,recession,applications,infrastructure,spending,ROI,investments,Chambers,Cisco,network,internet,web

Categories: Development and General

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

Lori MacVittie — Mon, 14 Jul 2008 15:31:38 GMT

Neil McAllister @ InfoWorld has a great blog post on The Web development skills crisis. He postulates at that "The most agile developers, however, are those who approach programming with a firm grounding in computer science."

Amen, brother. Say it again, only this time loud enough my son hears you.

The basic premise of Neil's post revolves around the frenetic rate at which programming technology is changing. It isn't just languages, though that is certainly part of the mix, it's also the increasing number of libraries and frameworks from which web developers can choose to develop web applications.

In order to switch from Python to Java to C to JavaScript, and do so almost seamlessly, requires, as Neil points out, a firm grounding in computer science. The kind of firm grounding that comes from an accredited computer science degree program at an established university. Or does it?

If you know young adults studying computer science in college today, you may find it disheartening that even a four year degree at an accredited, reputable university no longer ensures a "firm grounding in computer science." The continued transformation of computer science degrees into web programming degrees replete with CSS and JavaScript courses have become the norm, and traditional theoretical classes like compiler and language theory have gone the route of the dodo bird. The same college where I earned my undergraduate degree no longer offers Compiler Theory or Theory of Programming Languages, or even a Graphics course. It now offers "software design" classes in which students are taught Visual Basic, CSS, and JavaScript. They're taught the concrete implementation of programming, not the abstract theories behind it. Students aren't being taught computer science, they're being taught rote programming and not computer science.

That's increasingly disturbing, as it is these theoretical classes in which students build a strong foundational understanding of languages and computer science that can be used to become the agile developer required in today's quickly changing web development environment. If you graduated with a degree in computer science but don't know the difference between a hash table, a stack, and a linked list, then your degree program has failed you.

If you just "import" a queue, or a linked list, or a vector, and you don't understand the implementation of these basic data types you might be choosing one that will not only affect the performance of your application, but put limitations on further development down the road.

The best programmers, agile programmers, are the ones that understand not only the language but the basic constructs of all programming languages because they are, in essence, the same. They understand the theory and data structures and algorithms and it is that which enables them to move between languages and environments with alacrity.

And you network administrators out there - don't think you're off the hook so easily. If you don't know the difference between a queue and a weighted-queue and the advantages and disadvantages of each, then you don't really understand what you're doing when you click that checkbox on a firewall or traffic management device that implements queuing as a method of quality of service. Many of the techniques used to implement network-oriented tasks are based solidly in computer science algorithms, like basic routing and load-balancing that form the basis of application acceleration solutions and good old fashioned routers. That means that you, too, could benefit from a firm foundation in computer science. After all, the software that makes those network devices work in the first place is just that - software. In the end, it's all code and it all boils down to the same thing: data structures, control structures, and compilers.

Knowing why something performs the way it does gives you an edge; it gives you insight into why things go wrong and why things go right when you're configuring a device or writing an application or architecting a solution.

It may be cliché, but it's true: knowing is half the battle.

The other half is realizing that you need to know in the first place.

Do you think a computer science degree is required to be an agile developer? ( surveys)

Technorati Tags: MacVittie,F5,developers,computer science,data structures,network,software,web,internet,programming

Categories: Development and General , Randomness

Cloud Computing Infrastructure: Secure Remote Access

Lori MacVittie — Mon, 14 Jul 2008 12:15:27 GMT

The increasing webification of applications both for external and internal consumption combined with the concept of outsourced data centers and applications, i.e. cloud computing and Software as a Service (SaaS), may resolve in a perfect storm for proponents of telecommuting.

Consider the scenario: A small to medium organization needs more horsepower but it really doesn't have the budget yet to build out its own enterprise-class data center. Cloud computing offers an off-site, managed data-center that can be used to deploy applications for use by both external and internal constituents. Take advantage of SaaS offerings such as those from Salesforce.com and you've very nearly outsourced all your application needs. It's all off-site, which is allegedly better for your bottom line and saves you the headaches of hiring a lot of IT staff to manage that infrastructure yourself.

What these means for internal employees, however, is that all the applications they need to use on a daily basis are off-site. They don't require a lot of internal infrastructure, even mail services could be hosted "in the cloud" for additional efficiencies in storage and infrastructure costs. The question becomes, then, why is the organization wasting more money leasing office space so their employees can commute to the "office" and then spend their day accessing applications outside the organization?

The potential is that cloud computing, used liberally, could turn nearly every employee into a telecommuter because once you're accessing an application across the Internet it really doesn't matter from a technological viewpoint from what location you're accessing them.

I know what you're thinking - there's more to a data center and its infrastructure than just web apps. There's file storage, e-mail and productivity applications, and other network-based applications that are not, perhaps necessarily, web-based. Outsourcing all those responsibilities to a third-party cloud computing provider seems a bit far-fetched without the proper method of accessing them securely across the public internet. That's where a secure remote access solution such as an SSL VPN comes in.

By ensuring access to an SSL VPN cloud computing infrastructure providers can offer access to all appropriate data center resources in a secure way without requiring a lot of the PKI overhead that comes from IPSEC-based VPN implementations. Most SSL VPN gateways provide an on-demand client, so there's almost no management overhead on the client-side and it's a no-brainer for the end-user no matter how technical or non-technical they may be.

An SSL VPN would also ensure that end-users are compliant with the provider's and the organization's security policies through their implementation of endpoint security. This includes actions such as requiring anti-virus solutions to be running, verifying that specific OS patches are installed, and even checking to see if certain applications are running, such as malware or bots.

Basically, an SSL VPN is the perfect complement to a nearly complete outsourced data center in the "cloud" because it secures access to the applications and the infrastructure in the cloud in a simple, cost and management efficient way.

That means an as organization you could offer, if you like, more telecommuting opportunities for employees, which can reduce office costs dramatically and provide a wider selection of employees because you aren't limited to a specific locale or requiring relocation.

You might want to ditch the video-conferencing idea, though. Just in case.

Technorati Tags: MacVittie,F5,cloud computing,cloud computing infrastructure,secure remote access,SSL VPN,VPN,telecommuting,web,internet,IPSEC

Categories: Development and General , Security

Apple twitters

Lori MacVittie — Fri, 11 Jul 2008 21:19:22 GMT

twitter (v) to allow your services go up and down randomly under heavy load due to inadequate architecture or planning, annoying a lot of the known (online) world

In case you've been living under a rock (or been heads down coding for the past week), Apple launched its latest iPhone today to the delight and, it appears, consternation of customers. A colleague relates his experience not just purchasing one of the eagerly awaited phones, but the disaster that was the activation process. Apparently Apple wasn't satisfied with all the good press it gets about how hip and trendy its products are so it decided to get some of that embarrassing press that Twitter's been getting due to unreliable services. At least Twitter is free, so it isn't as if you paid for the pleasure of having its services go down. Apple, on the other hand, well, we all know Apple products ain't cheap.

So, some 6 hours after leaving my house, I am now sitting with a fully functional, synching 16Gb iPhone 3G on my desk. My original AT&T store destination had 30-40 people in line 2.5 hours before opening (and most of them looked wet and cold like they’d been there all night). I then went to an alternate, which is an AT&T store that has only been open 3 weeks. At 6 am local time, I became the 4^th person in line, by 6:30 there were 30.

Once the store finally opened the first four of us were let in. It would be 30 minutes before I walked back out with my phone. The phone I walked out with was still bricked and it did not have my number, but a temporary one. Why? First, the phone number: Some brainiac at AT&T decided that they needed new POS software to be used for the first time today—and guess what? The number porting function doesn’t appear to work—at all. Of the first 4 customers, 2 of us were porting numbers and neither of us was able. Second, the phone was still bricked because the unbricking requires you to connect the phone to iTunes—and guess what? Yup, the first two activations took 15 minutes each—and the other two still hadn’t gone through.

So I take my new phone home and after 2 hours of trying to get it to connect to iTunes myself and receiving various network errors (Timeouts and at one point iTunes was just resetting my connection) I finally received a “We are unable to process anymore iPhone registrations at this time” page. The, encouraged that I actually got a response other than an error code, I tried again and Poof!! Unbricked. Now all I have to do is get my number ported.

Is it just me or does Apple just not get this? After all the problems they had during the first iPhone launch, you’d think that they would have been prepared. To me, it just looks like they didn’t even bother.

According to Engadget, Apple's activation servers have indeed been down, with customers instructed to "try again later." And CNN reports similar admissions by the gadget giant:

A spokesman for AT&T, the exclusive carrier for the iPhone in the U.S., said there was a global problem with Apple's iTunes servers that prevented the phones from being fully activated in-store, as had been planned.

Instead, employees are telling buyers to go home and perform the last step by connecting their phones to their own computers, spokesman Michael Coe said. However, the iTunes servers were equally hard to reach from home, leaving the phones unusable except for emergency calls

Apparently Apple hasn't figured out how to scale its services to properly handle sudden spikes in volume such as those that occur when releasing a new, very popular product. Hint: it involves an application delivery controller and more servers. It's not much different than the experience many teenagers - mine included - have had around Christmas since the explosion of the iPod. After receiving enough Apple cash to keep them happily downloading tunes and movies throughout their vacation, every teenager rushes to their computer to ... play Solitaire or Bejeweled, apparently, because iTunes and its servers can't handle the sudden spike in users.

C'mon Apple - you could probably cut out a bit of the money used to promote the launch and put it towards a couple of more servers and a nice application delivery controller to make sure you can actually service your customers properly. You can meet the connection management challenge that is often the cause of server overload when suddenly faced with high volumes of traffic (e.g. the slashdot or fark effect).

You aren't a startup, you aren't Twitter, you're APPLE. Surely you can afford to scale up your infrastructure and make sure that using your services isn't a gambling proposition.

And if you won't do that, you could at least adopt a cool mascot like Twitter's Fail Whale to amuse customers while they're denied access to your services.

Technorati Tags: MacVittie,Apple,iTunes,iPhone,3G,Twitter,scalability,web,internet

Categories: Development and General