Lori MacVittie’s posterous

Random Postings on Application Delivery, Development, and SOA 

4 Reasons not to use mod_security

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.

Read the rest at DevCentral

Comments [0]

Your Stack Trace, Show It To Me

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

 

Read the rest at DevCentral

Comments [0]

Interactive F5 SOA Reference Architecture

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.

 

 

Read the rest at DevCentral

Comments [0]

Does your virtualization strategy create an SEP field?

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.

 

Read the rest at DevCentral.

Comments [0]

Three Web Application Vulnerabilities You Need To Know

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.

Read the Rest at DevCentral

Comments [0]

Links, Sex, and Application Fluency

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.

 

Read the rest at DevCentral.

Comments [0]

You say grid, I say cloud

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 is just fooling themselves.

Or are they? John Foley points out that in theory the notion of "private clouds" doesn't make sense but that in practice, it really doesn't matter to those taking advantage of cloud computing infrastructure and solutions to roll their own "mini-clouds", as it were.

 

Read the rest at DevCentral

Comments [0]

Dear Plurk: We're through. Kthxbye.

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?

 

Read the rest at DevCentral.

Comments [0]

Horizontal and Vertical Security: Which do you need?

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.

 

 

Read the rest at DevCentral.

Comments [0]

cession Proofing Your Application Infrastructure

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?"

Read the rest at DevCentral.

Comments [0]