It’s been far too long since I’ve posted here but I finally came up for air and even managed to take a week off. I was supposed to be in Germany last week at the Guide Share Europe WMQ Working Group talking about security but those plans went up in smoke – volcanic ash, to be precise. I was extremely disappointed because one of the reason’s I dropped out of sight for a while was to prepare a new security slide deck for GSE called Security is not a destination, it’s a journey. I’ve been wanting to tackle this subject for a while now and the folks at GSE were kind enough to let me run with it. I just wish I could have been there to deliver it. Thanks to Hubert Kleinmanns for stepping in at the last minute to do the presentation. I’ll post the deck here shortly in case anyone is interested.
Next week I’ll be at IMPACT 2010, or #ibmimpact for those of you following the event in the aggregator. Preparing the new WMQ Hands-On Security Lab materials was the other reason I’ve been out of sight lately. It was a huge effort which nearly cost me my current client, my marriage and some IRS late filing penalties, but it was totally worth it. There are several modules in the lab which will walk you through all of the tasks to do basic admin hardening. These include setting up SSL between two QMgrs, between WMQ Explorer and two QMgrs, and then setting up BlockIP2 to filter connections and dynamically set MCAUSER. The lab makes good use of several SupportPacs including the Ian Vanstone’s SSL Wizard and Mark Taylor’s WMQ Explorer configuration and Display Plug-In.
The lab is on a really nice Red Hat Enterprise Linux image which means that I had access to all the usual *nix scripting utilities. My issue with a lab like this is that if you are not already familiar with the subject matter and drop behind the lab instructor, it’s easy to get so lost you give up. Since I had all the scripting tools, I tried to address this problem. Each module has a set of scripts, including a build script. If you run the build script for one module, it runs the build script for the previous module then runs the remaining scripts for the current module. When it finishes, all the exercises for the previous modules are completed and you are ready to start the current module. For example, if you want to work on Module #5, first run the Module #4 build script. It stops and deletes the queue managers, rebuilds them from scratch, creates keystores, generates keys, exchanges keys, builds channels and installs BlockIP2. Whew! Now you are ready to start Module #5 and don’t need to worry about falling behind.
The scripts are a great asset for you to use when you get back to the office as well. I tailored them for use in the lab but they are basically the same scripts I use at client sites. As I mentioned in Mission:Messaging: Scripted WebSphere MQ key file management for UNIX and Windows, I’m an enthusiastic proponent of automation when it comes to things like key management. This is a perfect example of why. You’ll need to do some customization but the lab scripts are a good head start on tools for your own WMQ security hardening project. I don’t know whether they will be posted on the IMPACT site but I’ll post them here shortly so people can download them regardless of whether they went to IMPACT. I’ve had a chance to try the lab on an AIX box as well and, other than having to replace the Linux version of Q (SupportPac MA01) with an AIX version, it worked great. As I get the chance to test on other platforms, I’ll modify it to figure out which platform it’s on and use the right compiled code versions.
So that’s it for now. I hope the wait was worth it. Please come to the WMQ Hands-On Security Lab at IMPACT and give me your brutally honest feedback.