POODLE Vulnerability In SSLv3 Affects IBM WebSphere MQ

Secure Socket Layer version 3 (SSLv3) is largely obsolete, but some software does occasionally fall back to this version of SSL protocol. The bad news is that SSLv3 contains a vulnerability that exposes systems to a potential attack. The vulnerability is nicknamed POODLE, which stands for Padding Oracle On Downgraded Legacy Encryption.

The vulnerability does affect IBM WebSphere MQ because SSLv3 is enabled by default in MQ.
IBM describes the vulnerability like this: IBM WebSphere MQ could allow a remote attacker to obtain sensitive information, caused by a design error when using the SSLv3 protocol. A remote user with the ability to conduct a man-in-the-middle attack could exploit this vulnerability via a POODLE (Padding Oracle On Downgraded Legacy Encryption) attack to decrypt SSL sessions and access the plaintext of encrypted connections.”

The vulnerability affects all versions and releases of IBM WebSphere MQ, IBM WebSphere MQ Internet Pass-Thru and IBM Mobile Messaging and M2M Client Pack.

To harden against the vulnerability, users should disable SSLv3 on all WebSphere MQ servers and clients and instead use the TLS protocol. More specifically, WebSphere MQ channels select either SSL or TLS protocol from the channel cipherspec. The following cipherspecs are associated with the SSLv3 protocol and channels that use these should be changed to use a TLS cipherspec:
AES_SHA_US
RC4_SHA_US
RC4_MD5_US
TRIPLE_DES_SHA_US
DES_SHA_EXPORT1024
RC4_56_SHA_EXPORT1024
RC4_MD5_EXPORT
RC2_MD5_EXPORT
DES_SHA_EXPORT
NULL_SHA
NULL_MD5
FIPS_WITH_DES_CBC_SHA
FIPS_WITH_3DES_EDE_CBC_SHA

On UNIX, Linux, Windows and z/OS platforms, FIPS 140-2 compliance mode enforces the use of TLS protocol. A summary of MQ cipherspecs, protocols and FIPS compliance status can be found here.

On the IBM i platform, use of the SSLv3 protocol can be disabled at a system level by altering the QSSLPCL system value. Use Change System Value (CHGSYSVAL) to modify the QSSLPCL value, changing the default value of *OPSYS to a list that excludes *SSLV3. For example: *TLSV1.2, *TLSV1.1, TLSV1.

TxMQ is an IBM Premier Business Partner and “MQ” is part of our name. For additional information about this vulnerability and all WebSphere-related matters, contact president Chuck Fried: 716-636-0070 x222, chuck@TxMQ.com.

TxMQ recently introduced its MQ Capacity Planner – a new solution developed for performance-metrics analysis of enterprise-wide WebSphere MQ (now IBM MQ) infrastructure. TxMQ’s innovative technology enables MQ administrators to measure usage and capacity of an entire MQ infrastructure with one comprehensive tool.
(Photo from J Jongsma)

MQ Capacity Planner FAQ: Six Questions About The Tool

TxMQ will debut is new MQ Capacity Planner (for IBM WebSphere MQ) next week at the MQ Technical Conference in Sandusky, Ohio. This new tool allows for the testing of a virtually unlimited number of messages from any number of concurrent applications. It reveals micro details and offers a powerful lens to inspect, diagnose and performance-tune your MQ.
In anticipation of the pilot release, here’s a brief FAQ.
Which message patterns can MQCP measure?
MQCP can measure simple and multi-threaded Put: Local and Remote Queues, as well as  Simulated Request/Response using UTurn and MQ-Triggered Process/Publish/Subscribe.
What specific metrics does MQCP deliver?
MQCP captures elapsed time in milliseconds, message size and number of threads to calculate TPS (transactions per second) and volume throughput. It also produces all statistical values to the 90th percentile to offer a more accurate measure of your environment’s Queue Manager/Infrastructure.
Does MQCP measure system usage?
Yes, MQCP measures CPU usage and wait times (using tools like Nmon for Linux and AIX and Perfmon for Microsoft platforms) from MQCP test cycles.
What are some of the customization options?
There are many. Some of the most important include options for configuration relating to the Queue Manager and Queues to be used, MQ Client Connection options, Application Message Size options, and Application Reflection. Additionally, MQCP dynamically invokes the required application for getting and putting messages
Are there any features to be added that are not found in the pilot release?
Yes, we are currently working to add a Trigger Monitor process, which is a custom Java Trigger Monitor supporting the Request/Response flow tests. The Trigger Monitor is a configuration and is a production-ready process. We’re also adding publish/subscriber processes to support both JMS and native MQ Java processing. These publisher processes are configurable for multi-threaded publishing and message sizes.
Is TxMQ willing to address general questions about the product?
Yes, TxMQ will continue to discuss the product and respond to questions before, during and after the rollout. We encourage anyone with questions to contact us. Communications are always confidential.
Interested in trying the MQCP? Contact TxMQ president Chuck Fried and ask about the MQCP Pilot Program: (716) 636-0070 x222, chuck@txmq.com.
(photo by Taber Andrew Bain, Creative Commons license)

MQ Capacity Planner: More Info About MQ Monitoring

TxMQ is set to debut its new MQ Capacity Planner (MQCP) utility next week at the MQ Technical Conference in Sandusky, Ohio. We’re offering two live-demo sessions with MQCP author Allan Bartleywood:

  • Monday, Sept. 29 at 11:15 a.m.
  • Wednesday, Oct. 1 at 11:15 a.m.

For those who can’t attend, MQCP is a brand-new, proprietary MQ monitoring and testing utility for MQ message flow. More specifically, MQCP is a multithread testing tool for IBM WebSphere MQ environments that is capable of testing any volume of application-data messages generated by any number of concurrent application instances assigned to any number of queue managers in order to obtain highly detailed performance reports of queue times and package priorities measured against total message capacity, CPU loads and throughput times.
Results provide accurate estimates of optimal message sizes to better diagnose bottlenecks and boost overall MQ, network and application performance.
To dig a bit deeper into functionality, MQCP’s strength is in the detail. Typical MQ test scripts simply can’t offer the insight and absolute detail of MQCP, which essentially allows the user to shine a light into the dark corners of an MQ environment to reveal any cobwebs that slow down performance. And the tool is indispensible for network change control: Anytime you change out a network configuration item, run MQCP again and compare performance to the previous baseline to measure how an implementation truly affects MQ performance. It’s really that simple.
More details on MQCP will emerge over the following weeks. There’s additional information included on our MQCP page (click here to visit).
Interested in trying the MQCP? Contact TxMQ president Chuck Fried and ask about our MQCP Pilot Program: (716) 636-0070 x222, chuck@txmq.com.

Details: Fix Pack 8.0.0.1 for WebSphere MQ 8.0

IBM recently released its first fix pack for WebSphere MQ 8.0. The 8.0.0.1. fix pack is now available on the following:

  • AIX
  • Linux on x86
  • Linux on x86_64
  • Linux on zSeries 64-bit
  • Linux on POWER
  • HP-UX for Itanium
  • Solaris SPARC
  • Solaris on x86_64
  • Windows
  • IBM i

The 8.0.0.1 fix pack addresses the following APARS:

IT00493         Mqxr server receives probe ID XR071002 unsubscribe failed with mqcc_failed RC=2429 mqrc_subscription_in_use AMQXR0004E
IT00497         WebSphere MQ 7.0.1: queue manager can not start after upgrade TOV7.0.1.10 or V7.0.1.11
IT00960         WebSphere MQ V7 client .NET applications using get with waitinterval greater than 300 seconds fail with MQRC=2009.
IT01241         WebSphere MQ V7 client application reports sigsegv on while connecting to the queue manager using ccdt file.
IT01374         WMQ V7 java: a message may not be converted to unicode when SHARECNV=0 is set on a client channel.
IT01511         WMQ mft: new transfer request panel from the WMQ explorer does not function properly when a sfg agent is selected.
IT01607         WMQ ams: AMQ9044 log message says message was sent to system.protection.error.queue but was rolled back
IT01798         WMQ 7.5: WebSphere MQ default configuration wizard on Windows terminates with no error message.
IT01799         Dspmqrte returns 2046 ‘mqrc_options_error’ when connecting in client mode to a V7.1 queue manager running on z/OS.
IT01966         Creation of a 64-BIT Oracle switch load file for WebSphere MQ Java client fails on Linux 64.
IT01972         Queue manager trace is turned off for an application thread withmultiple shared connections after an mqdisc call is issued
IT02055         FDC probe XC130004 within function rfichooseone reporting sigfpeexception, and termination of queue manager processes
IT02122         Unable to connect to WMQ mft configuration via remote queue manager using ccdt under WMQ explorer
IT02194         WebSphere mq: clwlrank and clwlprty ignored when using like parameter
IT02389         Amqsbcg retreives incorrect message on the destination queue when API exit removed message properties
IT02422         WMQ V7.5 Java application fails with reason code 2025 (mqrc_max_conns_limit_reached) after network outages
IT02480         WebSphere MQ output from ‘dmpmqcfg’ is incorrect for runmqsc input for defining selector strings
IT02684         Data missing from WMQ V7.5 .NET application trace when tracing is repeatedly stopped and started while application is running
IT02701         MQ 7.5 setmqm fails without error when mqs.ini contains a blank line(s) at the end of the file.
IT02920         FDC with probe ID CO052000 and errorcode rrce_bad_data_received is generated by the WebSphere MQ V8 queue manager.
IT02981         WebSphere MQ V7.5: addmqinf command fails if queue manager file system is not available.
IT03124         WMQ 7.5: a svrconn channel terminates when browsing the system.admin.trace.activity.queue
IT03154         Ibm MQ 8.0: AMQ5657 message is written in error log without the text AMQ5657
IT03205         Defxmitq can be set to system.cluster.transmit.queue using the crtmqm -d switch, but this should not be allowed
IT03551         WMQ V7.5: .NET application fails to connect to queue manager with RC=2232 (mqrc_unit_of_work_not_started).
IT03711         WebSphere MQ 7.5 probe ID XC333030 component xlspostevent reports major error code 16 (einval)
IT03825         WMQ V8.0: rc 2195 FDC probe ID XC130031 when using authinfo withauthtype(idpwldap)
IV40268         AMQ9636: ‘ssl distinguished name does not match peer name’ errorwhen using ssl/tls channels with multi-instance queue managers.
IV56612         Channel moves to running state and ping completes on a sender channel with trptype(tcp) and receiver channel TRPTYPE(LU62)
IV58306         Memory leak in amqrmppa observed while queue manager is running
IV59264         ABN=0C4-00000004 in csqmcprh when using the WebSphere MQ classesfor Java
IV59891         Ibm MQ 7.1 or 7.5 dspmqtrc writes out incorrect time stamps whenformatting 7.0.1 trace files
IV62648         Mqcmd_reset_q_stats processing ends for all queues if one queue is damaged
IV63397         WebSphere MQ 7.0.1.7 queue manager is unresponsive and generatedfdc’s with probe id’s XC034070 and XC302005
IV64351         MQ runmqras command fails to ftp data with error message “address unresolved for server address ftp.emea.ibm.com”
PI19991         Various problems encountered in the qmgr and chin late in the final test cycle. fix needed for stability and migration
SE59149        WebSphere MQ V710: language MQ ptf is incorrectly replacing the qsys prx cmds with the real cmds instead
SE59368        After executing the wrkmqmcl command the wrkmqm command falsely shows active queue managers as inactive.
XX00217        MQ V8 explorer password field in the userid pane of the queue manager properties appears populated when no password defined
XX00222        MQ explorer 8.0 on windows: when trying to export/import, using french version, unable to select a destination file or folder
XX00223        MQ managed file transfer plugin for MQ explorer cannot connect to a coordination queue manager configured to use SSL
“It’s In Our Name!” – TxMQ is an IBM Premier Business Partner and we specialize in WebSphere MQ consulting. Initial consultations are free and communications are always confidential. Contact vice president Miles Roty for more information: (716) 636-0070 x228, miles@txmq.com.
(Photo by Kate Ter Haar, Creative Commons license.)

General Best Practices for WebSphere Application Environments

I found a great article written by Asim Saddal outlining  a list of general best practices to apply to any WebSphere Application Server V7 and V8 environment. It is copied exactly below. If you need the original article source, you can find it here.

However, some of the recommendations only apply to specific conditions and scenarios. These recommendations could be used to set up any WebSphere environment.

General Best Practices for WebSphere Application Environments

1. All WebSphere Application processes should be running as non-admin/root user.
It’s not a good practice to run a process as an admin/root user. For obvious reasons, you don’t want more folks to know about the admin/root password and generally the WebSphere admins are not the system admins. Create a services user account on the box and use it for the WebSphere Application’s start and stop purposes.

2. Enabled Global Security.
By default, the WebSphere Application Server enables administrative security. Thus, for the most part, the infrastructure provides for reasonable authentication, authorization, and encryption of administrative traffic by default. When administrative security is enabled, the WebSphere Application Server’s internal links between the deployment manager and the application servers and traffic from the administrative clients (Web and command line) to the deployment manager are encrypted and authenticated. Among other things, this means that administrators will be required to authenticate when running the administrative tools.

3. Enabled Application Security.
In addition to leveraging the application server’s security for administration, it’s strongly recommend that you leverage it for application security. Doing so gives your applications access to a strong and robust standards-based security infrastructure. Applications that didn’t leverage application server security were typically found to have serious security holes. Designing and implementing a secure distributed infrastructure is not easy.

To enable application security, go to the global security panel and select Enable application security.

4. Configure WebSphere Security with proper LDAP repository.
WebSphere security supports different configurations, including LDAP servers, local users and local operating system levels users. However, it’s recommended that you use a proper LDAP server for this purpose.

5. Leverage Administrative roles.
WebSphere Application Server allows for a variety of administrative roles depending on the version: Administrator, Operator, Monitor, Configurator, AdminSecurityManager, iscadmins, Deployer, or Auditor. These roles make it possible to give individuals (and automated systems) access that’s appropriate to their level of need. It’s strongly recommended that you take advantage of roles whenever possible.

By using the less powerful roles of monitor and operator, you can restrict the actions an administrator can take. For example, you can give the less senior administrators just the ability to start and stop servers and the night operators just the ability the watch the system (monitor). These actions greatly limit the risk of damage by trusting people with only the permissions they need.

6. Use HTTP Server as an interface for the Applications.
Use HTTP servers in front of an application layer, i.e., WebSphere Application. Don’t allow communications directly with WebSphere’s http web container port from either a load balance or from browsers.

7. HTTP and WebSphere on the Same box.
At least in higher environments, install and configure the http server on a different box than the WebSphere box. In the lower environments the same box can be used for both layers.

8. Logs on External Drive.
At least in higher environments, write the WebSphere and application log files to an external drive, so it won’t fill up the server’s file space.

9. Logs Archive.
Depending on the application, rotate and clean up the logs in a timely manner.
10. Read-only Logs Access for Developer.

If it’s okay with the security team, grant developers read-only access for WebSphere and the applications logs on the external drive.

11. Alternate Log Access for Developers.
To enable developers to view the production application and WebSphere logs, host those shared folders from the web server instead of giving them access to those boxes. Once the logs are hosted from the web server, developers need only a web browser to view those files from their computers.

12. Log Level.
Configure log level to error in high environments. Logs in the higher environments don’t need to produce unnecessary information. In the lower environments it can be set to info or debug level.

13. Leverage WebSphere Application Servers’ high availability and failover capabilities.
Out-of-the-box WebSphere support high availability and failover functionality. There is no need to use any external component or product for this. One of the key benefits is that  user http session can be shared within the cluster members and, in the case of failover, the other active cluster members can resume the activity using same session.

14. Minimum Cluster Members in Cluster.
In the WebSphere clustered environment, define and create at least three cluster members. In the case of failover with two cluster members, not only the entire load will shift to one node but it also becomes a single point of failure. With three nodes, at least the load will still be distributed to two nodes and there is no single point of failure.

15. Database and WebSphere on Same box.
At least in higher environments, separate the application layer from the data layer and install them on different boxes. In the lower environments the same box can be used for both layers.

16. Use Type-4 JDBC Drivers.
Type-4 JDBC drivers don’t require any component to be installed on the application layer. For the type-2 and type-3, the database’s client needs to install on the WebSphere box.

17. Protect application server to database link.
As with any other network link, confidential information can be written to or read from the database. Most databases support some form of network encryption and you should leverage it.

18. Script based WebSphere Administration.
In general, it’s good practice to use scripts to avoid human errors during the deployment and configuration, especially in higher environments. However, it requires an investment in time and resources to develop these scripts, especially if it is first time and / or script-based administration is not part of the current culture. Once the scripts are created, they can be used in all environments and maybe automate some of the tasks.

19. Monitoring.
Use proper application and infrastructure runtime monitoring tools that can monitor environments and application thresholds and potentially alert you to problems before they cause service interruptions.

20. EAR vs WAR Files.
According to J2EE specs, EAR file should be deployed in WebSphere. However, WebSphere does support deploying WARs and upgrade class functionality. Developers should produce EAR files from their development tool or generate EAR should it be created from the deployment scripts before deploying the application in WebSphere.

21. Don’t run samples in production.
WebSphere Application Server ships with several excellent examples to demonstrate various parts of the WebSphere Application Server. These samples are not intended for use in a production environment. Don’t run them there, as they create significant security risks. In particular, the showCfg and snoop servlets can provide an outsider with tremendous amounts of information about your system. This is precisely the type of information you don’t want to give a potential intruder. This is easily addressed by not installing the samples during the profile creation.

22. Environments.
Generally, it’s good to have more environments. Typically four would be a sufficient enough: development, QA, staging and production. Development and QA environments don’t need a lot of hardware resources. It’s recommended that the staging environment be a replica of production in terms of application data and hardware resources. The staging environment can also be used for stress testing and / or for production support.

23. Performance Tuning.
Tune WebSphere application servers properly for each application. Performance tuning includes optimization of a number of web container threads, JVM heap sizes, JDBC connections, OS tuning, etc. After configuring these parameters to optimize values, boost the application performance. Stress / staging environment should be used for load testing.

24. Separate your production network from your intranet.
Most organizations today understand the value of a DMZ that separates the outsiders on the Internet from the intranet. However, far too many organizations fail to realize that many intruders are on the inside. You need to protect against internal as well as external threats. Just as you protect yourself against the large untrusted Internet, you should also protect your production systems from the large and untrustworthy intranet.

25. Separate your production networks from your internal network using firewalls.
These firewalls, while likely more permissive than the Internet-facing firewalls, can still block numerous forms of attack.

Keep up-to-date with patches and fixes. As with any complex product, IBM occasionally finds and fixes security bugs in WebSphere Application Server, Virtual Enterprise, Datapower and other products. It’s crucial that you keep up-to-date on these fixes. It’s advisable that you subscribe to support bulletins for the products you use and, in the case of WebSphere Application Server and WebSphere Virtual Enterprise, monitor the security bulletin site for your version. Those bulletins often contain notices of recently discovered security bugs and the fixes. You can be certain that potential intruders learn of those security holes quickly. The sooner you act the better.

More information on WebSphere Application Server security, including recommendations on hardening the WebSphere Application Server infrastructure, is available on the WebSphere Application Server security page.

© 2008 SYS-CON Media Inc.