BlockIP version 2.20 |
|||||
|
This page is dedicated to BlockIP, and other security exit stuff News: A new version of BlockIP2 (2.15) is released, this release is extended to contains support z/OS thanks to Neil Casey. It will soon be the only maintained version. |
|||||
|
Important Notice:
|
The suggestions on this site is free and without any guarantee of any kind.
The intension of this page is to help WebSphere MQ system administrators
managing their sites, and reduce the frustration reading the manuals and
repeat the trouble I've gone thru.
|
||||
| Index | BlockIP2 security exit Download BlockIP2 v.2.15 directly BlockIP2 version_old version Download BlockIP2_old version directly BlockIP and Firewalls Added 21. aug 04 Version 1.23 enhancements LogIP the old fashion security exit, just for logging BlockIP the old fashion security exit with z/OS support |
||||
|
|
|||||
|
BlockIP2 is an enhanced version of the popular security exit, which is running all over the world. The latest improvements is: Multi pattern-match, block for userid containing: mqm, musr_mqadmin, MUSR_MQADMIN, and a blank userid. I hope this will cover all most 90% of the comments I've got on the Exit. New features is specified
like: You can also use a single position placeholder in the pattern: How to block bad userids (mqm, musr_mqadmin and ''), this is done using the switch -n in SCYDATA. When the RemoteUserIdentifier of an incoming connection request contains one of the listed users above BlockIP2 sends MQXCC_SUPPRESS_FUNCTION so the communication attempt is abandoned. BlockIP2 have been updated in SCYDATA like this: A debug
option is added, to allow a more comprehensive logging of the activity
inside BlockIP2. This done with the -d option. BlockIP2 have been updated to obtain the security specification from a file.
This feature was added to circumvent the 32 byte limitation in SCYDATA,
and was requested from complex installations. or like this on
Linux and the rest of unix impl.:
BlockIP2 is now able to change MCAUSER depending on the incoming connection credentials. This function is only available on SSL secured channels.
In the example above will connections with a CN=ibmwebspheremqclient2 get the MCAUSER=mrmq. Connections from CN=ibmwebspheremqQM2 will be refused all other connections from CN=ibmwebspheremq* will use the normal userid (or MCAUSER if specified on the channel). Connections made with CN=<anything> will have the MCAUSER=NoBody, which should be no defined. (Could also be SSL=CN=*;BLOCK; have the same function when user NoBody is undefined) Version 1.22 enhancementBlockIP2 is now able to filter on conname and userid, this gives the WebSphere MQ administrator the ability to keep unwanted elements out of a queuemanager. Another enhancement is the option to set the MCAUSER to a specified value controlled by BlockIP2. The syntax for the CON keyword is: CON=<conname>;<userids>[;MCA={*|userid}]; and an optional parameter MCA, where MCA=* means just use the normal user settings and respect an evt. MCAUSER, this is default. If you specify MCA=<userid> you will get this userid put into MCAUSER. Here is an commented example (not from the real world), but still informative:
The list is searched from top to bottom, and when BlockIP2 detects a match on connection-id and userid, this means that it's important to specify the rules in the right order. Caution: Using both SSL and CON keywords in the same specification file, should be done with great caution, because the SSL have precedence over CON. You might see that a MCA change caused by CON, can affect a SSL setting without MCA settings. I hope you can have more use of this security exit in the future. The BlockIP2 exit works with all channel types, however some combinations don't make sense. Like using it on a sender channel... BlockIP2 logs the following information: Time of connect, channel name, connection name, userid and if the connection was successful. Download BlockIP2 (source and DLL for Windows NT/2000 included together with a load-module for Linux-Intel) The BlockIP2 exit have been tested on Solaris, AIX and LINUX. But you have to compile it on Solaris and AIX by yourself. BlockIP2 have been tested on WebSphere MQ version 5.2, 5.3 and 5.3.1. Example of the log:
This enhanced Security exit is currently NOT available for Z/OS BlockIP2 can also be used to enhance the security of the connection between WBIFN server and SWIFT Alliance Gateway(SAG) |
|||||
|
|
|||||
| BlockIP2
version 2.1
BlockIP2 version 2.1 is a brand new and complete redesigned version of the old famous BlockIP2 security exit. New features added is mainly the ability to specify the location of the log file. And the ability to stamp the logfile with date and or channelname etc. And fixing some design errors. Download BlockIP2 version 2 (source and DLL for Windows NT/2000 included together with a load-module for Linux-Intel) The BlockIP2 exit have been tested on and LINUX. But you have to compile it on Solaris and AIX by yourself. And is currently under test on AIX/Solaris. BlockIP2 have been tested on WebSphere MQ version 5.2, 5.3 and 5.3.1. Version 2.12-2.13 enhancementYou can place the logfile as you like, just specify the wanted path in the configuration file. You can even have a logfile per channel per day, this means that it's easy to monitor the channel usage. There have been added two more funtions to ease the specification of filter characteristics: UseridUpperLowerCase=* and BlockUsers=; These two will ease the specification so you can "blacklist" a few of the generic Userids=. Version 2.15 enhancementThanks to Neil Casey who have ported the BlockIP2 exit to the z/OS platform, this have made it possible to have one exit source that is able to run on mostly all supported MQ platforms, and therefore is able to offer the same security strength. There is a short implementation description in the readMe file on how to implement the exit on z/OS. The compilation specs. for HP-UX is also added. Extended maximum pattern lengths to 256 characters. Changed logic for building the pattern strings so the multiple Pattern= or User= etc lines add to the previously built string, instead of overwriting it. This is a function change which makes this version behave differently when faced with multiple lines of data which previously just used the last data found. |
|||||
|
|
|||||
|
LogIP security exit, this exit is designed to log all incoming MQSeries Client connection attempts, so the system MQSeries administrator can see who connected at a given time. LogIP logs the following information: Time of connect, channel name, connection name and the userid. Download LogIP (source and DLL for Win NT/2000 included) To enable this logging you will have to add the SCYEXIT() parameter to on the channels you want to monitor: To add channel definitions to SDR & RCVR: If you want it for Z/OS, you should take BlockIP and use it without any specification or just a "*", then you would have a LogIP for Z/OS. It will place a entry in your xxxxCHIN task log of all incoming connections including userid and connection name. The LogIP exit have been tested on Solaris and works there, but you have to compile it there yourself.
|
|||||
|
|
|||||
| BlockIP security exit,
this exit is designed to only allow certain incoming MQSeries connection
attempts, so the system MQSeries administrator can keep his system
protected against intruders.
BlockIP gets information about what calls to pass from SCYDATA(), which allows trailing wildcard, like 172.20.* which will allow all incoming calls from the 172.20.xx.xx network. BlockIP only supports one mask, but you can use BlockIP on many channels to hopefully solve some of your needs. BlockIP logs the following information: Time of connect, channel name, connection name, userid and if the connection was successful. Download BlockIP (source and DLL for Win NT/2000 included, together with source for Z/OS) The BlockIP exit have been tested on Solaris and works there, but you have to compile it there yourself. BlockIP also now supports WebSphere MQ on Z/OS also To add channel exit definitions to channels: and if we're dealing with a BIG MQ: This would only allow communication with computers with a source address matching 172.20.190.something The BlockIP exit works with all channel types, however some combinations don't make sense. Like placing it on a sender channel... No further improvements planned, use BlockIP2 instead. BlockIP can also be used to enhance the security of the connection between WBIFN server and SWIFT Alliance Gateway(SAG)
|
|||||
|
|
|||||
BlockIP2 and firewallsHow do I configure BlockIP to handle communication using firewalls ? It's just as anything else, there are no problems in this area, just use the converted (NATed) address supplied by you network administrator ;o) I have a configuration like this using two Queue Managers (QM1 and QM2) located in their own LAN, protected with Firewalls which can do NAT.
When I see QM1 from FW2 (marked with red), all I see is the public network address of FW1, in this case 81.12.12.12 ! I don't see the internal addresses inside LAN-1, they are hidden! Therefore I can only translate public address (If i need/like to), in my case I need to change it to a "local" address 192.168.16.5. This means that communication to and from QM1 in LAN-2 is done using 192.168.16.5, this means that BlockIP2 should only allow 192.168.16.5. How I typically start configure BlockIP2 for a new network connection, is using either * (all allowed), or just block anybody, and study the log to find the wanted address. This is normally only necessary if your network specialist is unable to tell you how the incoming network is mapped.... Anyway your network specialist have to supply you with the address towards QM1.... |
|||||
|
|
|||||
| Comments | |||||
| Please feel free to comment this site, so it can be even better, and maybe include more interesting topics regarding WebSphere MQ and WebSphere Business Integration for Finance Networks (WBIFN). | |||||
