Is anybody lookin' in?
While putting this commentary together, I was fortunate enough to be enjoying a rare work-at-home week. There’s nothing better than sitting in your home office in "comfortable attire" on a dreary March day, with the heat turned up, and your favorite music playing (okay, well, maybe sitting on a cruise ship, or a beach, or...). One of the treasures of the Internet is Wolfgang's Vault, a site that hosts recordings from the "vaults" of legendary rock promoter Bill Graham’s Fillmore East, West, and other venues. There are treasures here in the form of live shows from bands like Led Zeppelin, Allman Brothers, Pink Floyd, and many others from the 60s, 70s, and 80s (dude, I was at some of these shows!), and it’s all free for the listening (however, you can buy tons of concert memorabilia!).
So, as I write this, I’m listening to a Creedence Clearwater Revival (CCR) show from 1971 in San Francisco (Fillmore West). It brought to mind one of my favorite CCR songs, and a suddenly-realized tie-in to the topic of my commentary. Thus begins a studious and academic analysis of the fun, happy, bouncy, up-beat song "Lookin’ Out My Back Door" as it applies to the topic of Web security.
Please, everyone be seated and hold your applause until after the show.
CCR lead singer John Fogerty’s classic work begins:
Just got home from Illinois, lock the front door, oh boy
How does this relate to Web security? Well, typically we are all very good at locking the front door. When I see security topology diagrams in the field, the front or client facing portion of the network is inevitably well locked-down. DMZ in place? Check. SSL? Check. Client connections terminated in the DMZ? Check. Front door all locked up? Affirmative, Dave, I read you (in memoriam: Arthur C. Clarke). These days, we’re pretty good at locking down that front door.
However, from this point on we typically see mistakes. The chorus of Fogerty’s hit song is:
Doo, doo, doo lookin’ out my back door
People think this was a simple happy song, but as often happens with rock music, they miss the hidden meaning (today’s generation just always forgets to play the music backwards). The brilliance of these lyrics is that once Mr. Fogerty had secured his front door, he then turned his attention to the back door. And that’s some thing we altogether too often forget to do in IT shops.
Okay, so enough with the lame analogy for now. But what are some common "back door" mistakes that we often find in the field?
Suppose you’ve got those SSL configurations in the DMZ all locked down. Your clients can be assured that when they use https to enter your site, they are indeed talking to the "real" site and there is no phishing or spoofing going on (you always check for "https" in the URL and that the host name is correct before entering sensitive information on a Web page, right?). SSL provides transport encryption, so that messages flowing between your client’s workstation and the DMZ server are encrypted -- nobody sniffing the traffic can read those messages (well, unless you are using insecure ciphers like NONE, but that’s another article). Can your clients now safely enter their credit card information to buy things from your site? Not so fast.
Let’s look at some common DMZ/back door mistakes that we frequently encounter:
No SSL from the DMZ server to the trusted zone servers. Are you leaving that connection open to anyone who is sniffing traffic in the DMZ? The DMZ is your "war zone," right? You are allowing the enemy (the bad guys, not your clients) to enter. It should be a hostile environment to anyone intending ill will.
There is SSL, but it is not properly configured. SSL connections from your DMZ servers to your backend servers for configurations that will carry sensitive data should be mutual-SSL-secured tunnels. This involves configuring two-way "client-authentication" as well as the traditional SSL configuration, so that both ends of the SSL connection verify each other, validate their certificates, and so on. As part of this configuration, all signers should be removed from the trust stores on both sides, except for the other end’s signers, which should not be from well-known certificate authorities (CA). Otherwise, anyone with a certificate from one of those CAs could connect.
Complexity in the DMZ. There should be no "large attack surfaces" in the DMZ. Often these are in the form of complex processes that are difficult to harden. For this reason, many organizations have a "no Java™" rule for the DMZ. There are wonderful products such as the IBM® WebSphere® Extended Deployment On-Demand Router that are not intended for DMZ use because of this, but often we find them installed there anyway. Inspect the DMZ components for any such installed applications. Check the run time processes to ensure there is no java* process running. Ensure that no JREs (let alone JDKs!) have been left behind by product installers (not unlike leaving a burglar’s toolkit outside your home’s back door for any potential bad persons to make their lives easier). To this list, you might also add the new ability to include your Web server as a managed process in the WebSphere Application Server cell. Although this is pretty cool and can save you some grief in terms of having WebSphere Application Server distribute out newly generated versions of keystores, and updating the WebSphere Application Server plug-in for you when it is regenerated, it does mean that you have to now run a Java process for this in the DMZ, which also open ports in your firewall to support the communication. This is nice for development, but not recommended for production.
DMZ not sufficiently hardened. This is an easy one to screw up. If file system permissions are not correctly set in the DMZ, there are many tricks that can return sensitive files from your server file system (such as embedded include-type statements, script statements, or URLs in malicious messages). Even if permissions are set correctly, if the DMZ processes for your Web or proxy server are running as root admin, they have access and can fetch and return them. Have you taken care to harden the operating system and all components? There is a great website that contains a number of papers and scoring tools for hardening many known platforms.
Not using WebSphere DataPower® for XML-bearing messages. Those who know me won’t be surprised to see me stick this one in here. I’m a huge advocate for these devices. Purely as a technical person, I feel that these are the most effective and amazing products I’ve ever used. DataPower appliances wipe out any concern about the previous two points listed above, as they are hardened out of the box. If you’ve read my previous Comment lines article, The (XML) threat is out there..., then you understand. If you haven’t, then do so. Please. For those who won’t, suffice it to say that it’s quite possible for a single, small, well formed XML message to bring down your carefully secured infrastructure. ‘Nuff said.
Coolness for the sake of coolness. I recently went through an exercise in configuring a DataPower device to authenticate a Web services SOAP message via a WS-Security Username Token against an LDAP server, and then have DataPower create the LTPA credential for WebSphere Application Server (saving WebSphere Application Server from all of that heavy lifting!), and then put the LTPA credential into the SOAP WS-Security header as a BinarySecurityToken (BST). Coolness! I was quite impressed with myself. But in reviewing the solution (okay, Keys Botzum pointed this out to me), I found that it was overly complex for the goal I was trying to achieve. You can see the overhead that this adds to the message in Figure 1. What you can’t see is the overhead that this adds to the runtime. WS-Security is useful for message-level security in some situations, such as when you have untrusted intermediaries that the message must flow through. But if you only need point-to-point message flows between two trusted servers, why not use good old SSL and pass the credential (LTPA in this case) as an encrypted cookie in the HTTP header? That’s what I did, and I achieved my goals with a much less complex solution, with the added benefit of having the runtime return the credential to the client browser for use on future requests. WS-Security can achieve message privacy and integrity (let’s not talk about the fallacy of non-repudiation) through the use of digital signatures and encryption, but there is a lot of run time overhead that comes with that convenience.
Figure 1. WS-Security BinarySecurity token
Of course, that does not mean you should forego security! Think in terms of your goals and don’t let your team get caught up in the coolness factor. Remember: "Web services security" is not the same thing as WS-Security! Test carefully. Of course, DataPower can do either one, including the WS-Security scenarios and much more in the way of WS-* and pretty much anything else you could think of security-wise -- at near-wire speed since it’s so secure and fast!
And so this concludes my song and Web security analysis. I’ve got to flip over the LP on my dinosaur Victrola and go put some clothes on before someone comes to the door. It’s regrettable that I could not work with tambourines and elephants, giants doing cartwheels, or statues wearing high heels. But if you take security seriously, and carefully analyze your entire topology diagram for security exposures, you might be able to peer out from your office or cubicle window and see all the happy creatures dancing on the lawn.
Sorry, I couldn’t resist. Keep on chooglin’...
- WebSphere DataPower SOA Appliances product information
- Comment lines: The (XML) threat is out there...
- Web services security with WebSphere Application Server V6, Part 5: DataPower as a gateway device
- Integrating Web applications with the DataPower Web application firewall service
- Sign and verify XML documents using Apache WSS4J and WebSphere DataPower SOA Appliances
- Integrating WebSphere DataPower XML Security Gateway XS40 with WebSphere Message Broker
- IBM developerWorks WebSphere Application Server zone
- Center for Internet Security