For those of you who missed it, Morag presented the WMQ Security session at this year’s WebSphere Technical Conference last week. This was exciting for a few reasons, not the least of which was – did I mention MORAG presented? So good to have her back at the conference.
Of course, for this iteration she had written all new content for the conference. There are so many changes related to security in v7.1 that almost all of the session was devoted to the new features! There is almost nothing left of my content from the deck but hey, it was pushed out by new features and that’s a problem I love to have. This blog post is a very high level overview of those new features.
WMQ Configuration backup
Although MS03 is great and the various owners of the SupportPac have been very responsive over the years, customers have long asked for a supported tool to back up their configurations and access control lists. WebSphere MQ now has such a tool! Though this may seem like a small detail,my definition of security includes the ability to recover after a breach. Pulling this tool into the product means that you will now always have this capability, and it will remain current with each new release.
RUNMQSC versions of setmqaut commands
This is related to the previous item in that configuration backups can contain access control lists. The new twist is that you can now define these in the same script where you define the objects they pertain to. Define a queue, define the access rules for that queue right after it. Again, this may seem like a small thing but I can’t count the number of shops I’ve visited where the objects were backed up centrally but the setmqaut commands were not captured. Part of the reason why was complexity and having to deal with two sets of files. Problem solved. Next!
Authorization control on non-local cluster queues
Here is where many of you are thinking “things just got interesting.” Finally! No more QAlias definitions over clustered queues! You can now define a profile that matches either a non-local cluster queue or even a non-local fully-qualified queue (where both queue and QMgr are specified on the open). This does not replace security on the receiving end of course, but it sure does make life simpler on the sending side.
Channel Authentication Records
These records provide rules that can reduce or eliminate the need for exits such as BlockIP2. For example, you can now set up rules that dynamically map an X.509 certificate Distinguished Name to a particular user ID and set the MCAUSER to contain that ID. You can also have multiple rules with different specificity, for example one to admit connections from all administrators based on the Organizational Unit in the DN and another to deny access to that guy you fired last week based on his fully-qualified DN. This provides some limited revocation capability in shops that do not enable WMQ’s native CRL or OCSP revocation checking. There is even an option to ban administrative IDs and WMQ knows on a platform-by-platform basis which IDs are administrative. That means you can have a baseline QMgr object inventory that includes a read-only Explorer channel, across all platforms, that is guaranteed to not allow administrative access. Sweet!
This is a very useful addition if you have ever had a runaway client or a remote QMgr with a typo in the channel name stuck in a reconnect loop. This feature doesn’t replace the firewall but sometimes the process of enabling and disabling firewall rules is too heavyweight for a temporary fix that the WMQ administrator needs right now. The idea is that the listener can now be configured to ignore connections based on their originating IP address. This happens before any data is read from the socket so is capable of absorbing a lot of connection requests.
Morag tells a story about how someone in Hursley started port-scanning the development servers. Since WMQ cuts an FDC file when something unknown connects to a listener, the port scanner generated FDC files on all servers, every day. Since they were in the process of writing this feature at the time, they simply enabled it and configured WMQ to ignore the port scanners. Problem solved! Of course if you are using some sort of IP sprayer that needs to know if the listener is up, you are better off configuring it for a TCP half-connect instead.
SSL FIPS and Suite B
Over time some of the ciphersuites that were once considered safe have been superseded by stronger versions. WMQ needs to stay current with these and so v7.1 now supports newer FIPS-compatible algorithms as well as adding support for Suite B. If you don’t know what these are then don’t worry about it. For everyone else, probably a good idea to start planning your upgrade now.
Explorer Role Based Authorities Wizard
In my original presentation I used to have a list of setmqaut commands that would create a read-only Explorer channel. I’m glad to see these removed and replace with a wizard that does the same thing! You have a choice to set up either administrator or read-only access and the administrator generates a window with the commands it will run. You can then copy the commands out or hit OK to have them executed by the wizard.
In the session someone asked whether there would be additional roles defined. Currently the wizard has only the administrative and the read-only roles. The thing is, these are the only two roles that are generic. You know you will need an administrator role. You probably need a read-only role, just for instrumentation if not for real human users. But between these two extremes, everything else falls into the “it depends” category. If you come up with additional roles that you think are generic or at least broadly useful, I’d love to hear about it.
API Exit for clients
The foils say that this is the same interface as the API exit for the QMgr. If that is true, I’d expect to be able to use MA0W at the client side. In any case, a client API exit opens up a whole raft of new possibilities, such as the client equivalent of a message exit!
Client version in channel status
From time to time a FixPack will contain a security-related fix. Any installation prior to that FixPack would then be considered vulnerable and need to be updated. But how do you know which client version is attached to the QMgr? As of v7.1, just display the channel status! As of WMQ v7.1 the client version down to the FixPack level can be determined in the channel status display.
Last but not least, you can now have WMQ v18.104.22.168 and higher coexisting on the same server as one or more installations at v7.1 or higher. How many? I believe someone from Hursley said they’d tested up to 128 installations on one box. I’m imagining their summer intern saying “you want me to do WHAT?” Anyway, this is again not strictly a security feature but in the event you wanted to implement v7.1 for it’s security features, you may need a nice migration path. The coexistence feature lets you do that on the same hardware you are using now. How sweet is that?
What I’ve listed here are just the security-related items and only a high-level overview. The next step will be to get a copy after November 11th and actually play around with it a bit. Between now and then there will be webinars hosted by Global WebSphere Community and I expect maybe a developerWorks article or two. I’ll be sure to publish the dates and times for these events, links and so forth as they are announced so watch this space!