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:  
To use multipattern: just seperate the patterns with a semicolon(;) like this:

alt chl(MQT2.TCP.MQT1) chltype(SVRCONN) + * OR: any other type
    SCYDATA('172.20.109.*;172.221.*;10.31.*') +
    scyexit('c:\path..\BlockIP2(BlockExit)') * NT
This will allow communication from any computer in the 172.20.109.*, 172.221.* and 10.31.* networks. 

You can also use a single position placeholder in the pattern:
alt chl(MQT2.TCP.MQT1) chltype(SVRCONN) + * OR: any other type
   SCYDATA('192.168.??.20;10.31.*') +
   scyexit('/var/mqm/exits/BlockIP2(BlockExit)') * LINUX
This will allow any IP-addr matching 192.168.10.20, 192.168.11.20.. 192.168.99.20 and 10.31.* to pass verification.

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:
alt chl(MQT2.TCP.MQT1) chltype(SVRCONN) + * OR: any other type
  SCYDATA('172.20.10.*;172.221.*;10.31.*;-n') +
  scyexit('/var/mqm/exits/BlockIP2(BlockExit)') * LINUX

A quiet mode option have been added, so there will be only one line per connection attempt in the log. This is done with the -q option.
alt chl(MQT2.TCP.MQT1) chltype(SVRCONN) + * OR: any other type
   SCYDATA('172.20.10.*;172.221.*;-q') +
   scyexit('/var/mqm/exits/BlockIP2(BlockExit)') * LINUX

A debug option is added, to allow a more comprehensive logging of the activity inside BlockIP2. This done with the -d option.
alt chl(MQT2.TCP.MQT1) chltype(RQSTR) + * OR: any other type
   SCYDATA('172.20.10.*;172.221.*;-d') +
   scyexit('c:\path..\BlockIP(BlockExit)') * NT

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.
The filename is  specified in SCYDATA like this on windows:
alt chl(MQT2.TCP.MQT1) chltype(RQSTR) + * OR: any other type
  SCYDATA('FN=c:\path..\Blockspec.txt;') +
  scyexit('c:\path..\BlockIP(BlockExit)') * NT

or like this on Linux and the rest of unix impl.:
alt chl(MQT2.TCP.MQT1) chltype(RQSTR) + * OR: any other type
  SCYDATA('FN=/var/mqm/exits/Blockspec.txt;') +
  scyexit('/var/mqm/exits/BlockIP2(BlockExit)') * LINUX
NB: The FN=<filename>; requires the ending semicolon(;).

 

# This is a comment BlockIP2 security specification Blockspec.txt
Patterns=10.1.*,172.20.31.*,127.0.?.1;  
Userids=xxx,yyy,zzz*,etc,mrmq,root,us???mq; 
BlockMqmUsers=Y;
#-----------------------------------------------------------------
# Description of security specification:
# This specification will allow:
#  - connections from 10.1.*, 172.20.31, and 127.0.0.1, 127.0.1.1, ... 127.0.9.1  
#    Networks.  Entries are separated using comma(,)
#  - allow  userids: xxx, yyy, etc, mqm and mrmq.  Together with users
# starting  with zzz<something> and users beginning with us<three chars>mq.  
#  
# - BlockMqmUsers=Y; means that following users are blocked: mqm,
#    MUSR_MQADMIN and musr_mqadmin.
#  All specs must end with a semicolon ; anything after ; is parsed as a comment
# Important:
# If you specify Patterns twice it's only the last specification that are used
# for matching.
#
# It's very important that all specs are terminated with semicolon(;) otherwise
# you will receive connection refused. Because I think it's best only to use
# positive error-free identification
# The patterns are separated using comma(,) This is also important to remember

BlockIP2 is now able to change MCAUSER depending on the incoming connection credentials. This function is only available  on  SSL secured channels.

# This is a comment BlockIP34.txt
Patterns=10.1.*,10.1.11.*,etc,127.0.?.1;
SSL=CN=ibmwebspheremqclient2;MCA=mrmq; ok userid
SSL=CN=ibmwebspheremqQM2;BLOCK; blocked user
SSL=CN=ibmwebspheremq*;MCA=*; just do nothing
SSL=CN=*;MCA=NoBody; Set all other to NoBody
# EOF

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 enhancement

BlockIP2 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}];
where <conname> is a generic connection name
where <userids> is a generic userid (not yet a list)

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:

#
# Simple filter implemented in BlockIP2 version 1.22

# 1. stop all connection attempts from mqm (NoBody is an undefined or blocked userid).
CON=*;mqm;MCA=NoBody;
#
# 2. Stop users starting with dk14 from 10.31.* Might be a foregin network
CON=10.31.*;dk14*;MCA=NoBody;
#
# 3. Allow master03 when comming from 172.20.10.31
CON=172.20.10.31;master03;
#
# 4. Allow spider when comming from 10.*, and set MCAUSER to master04
CON=10.*;spider;MCA=master04;
#
# 5. Block all other attempts.
CON=*;*;MCA=NoBody;

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:

04.01.20 00:11:04 BlockIP2: BlockExit ver=1.112 env=non-MVS ExitId=11 ExitReason=16 ChannelType=7
04.01.20 00:11:04 BlockIP2: BlockExit QMgr="QSJHPT01" ChannelName="CHANNEL2" ConnectionName="127.0.0.1" Userid="mrmq"
04.01.20 00:11:04 BlockIP2: ConName"127.0.0.1" Pattern "127.0.0.*;172.221.*;10.31.*;" Flags"-n ".
04.01.20 00:11:04 BlockIP2: BlockExit Connection accepted for pattern 127.0.0.* .
04.01.20 00:11:28 BlockIP2: BlockExit ver=1.112 env=non-MVS ExitId=11 ExitReason=16 ChannelType=7
04.01.20 00:11:28 BlockIP2: BlockExit QMgr="QSJHPT01" ChannelName="CHANNEL3" ConnectionName="127.0.0.1" Userid="mrmq"
04.01.20 00:11:28 BlockIP2: ConName"127.0.0.1" Pattern "127.0.0.2" Flags"".
04.01.20 00:11:28 BlockIP2: BlockExit Connection refused.
04.01.20 00:15:33 BlockIP2: BlockExit ver=1.112 env=non-MVS ExitId=11 ExitReason=16 ChannelType=7
04.01.20 00:15:33 BlockIP2: BlockExit QMgr="QSJHPT01" ChannelName="CHANNEL2" ConnectionName="127.0.0.1" Userid="musr_mqadmin"
04.01.20 00:15:33 BlockIP2: BlockExit Connection refused for system user identifier.-3
04.01.20 00:16:23 BlockIP2: BlockExit ver=1.112 env=non-MVS ExitId=11 ExitReason=16 ChannelType=7
04.01.20 00:16:23 BlockIP2: BlockExit QMgr="QSJHPT01" ChannelName="CHANNEL2" ConnectionName="127.0.0.1" Userid=""
04.01.20 00:16:23 BlockIP2: BlockExit Connection refused for blank user identifier.
04.01.22 23:22:45 BlockIP2: BlockExit ver=1.12 env=non-MVS ExitId=11 ExitReason=16 ChannelType=7
04.01.22 23:22:45 BlockIP2: BlockExit QMgr="QSJHPT01" ChannelName="JHP" ConnectionName="127.0.0.1" Userid="root"
04.01.22 23:22:45 BlockIP2: ConName"127.0.0.1" Pattern "128*" Flags "".
04.01.22 23:22:45 BlockIP2: BlockExit Connection refused for Conname 127.0.0.1 .
04.01.22 23:23:07 BlockIP2: BlockExit ver=1.12 env=non-MVS ExitId=11 ExitReason=16 ChannelType=7
04.01.22 23:23:07 BlockIP2: BlockExit QMgr="QSJHPT01" ChannelName="CHANNEL2" ConnectionName="127.0.0.1" Userid="root"
04.01.22 23:23:07 BlockIP2: ConName"127.0.0.1" Pattern "128*;127.*;" Flags "-n".
04.01.22 23:23:07 BlockIP2: BlockExit Connection accepted for pattern 127.* .
04.02.15 09:07:17 BlockIP2: BlockExit QMgr="QSJHPT01" ChannelName="CHANNEL2" ConnectionName="127.0.0.1" Userid="root"
04.02.15 09:07:17 BlockIP2: BlockExit Connection refused, invalid file name pattern specified: FN=<filename...>; "FN=/var/mqm/exit/blockip2.txt " .04.02.15 09:08:08 BlockIP2: BlockExit QMgr="QSJHPT99" ChannelName="JHP" ConnectionName="127.0.0.1" Userid="root"
04.02.15 09:08:08 BlockIP2: BlockExit Connection refused, Specified file "/var/mqm/exit/blockip2.txt" was not found.
04.02.15 09:09:57 BlockIP2: BlockExit QMgr="QSJHPT01" ChannelName="CHANNEL2" ConnectionName="127.0.0.1" Userid="root"
04.02.15 09:09:57 BlockIP2: BlockExit Connection refused, user don't match positive list xxx,yyy,zzz*,etc,mrmq,us???mq .
04.02.15 09:15:06 BlockIP2: BlockExit ConName "127.0.0.1" Pattern "10.1.*;10.1.11.*;etc;127.0.?.1" Flags "BlockMqmUsers=Y" users "xxx,yyy,zzz*,etc,mrmq,root,us???mq".
04.02.15 09:15:06 BlockIP2: BlockExit Connection accepted QMgr="QSJHPT01" ChannelName="CHANNEL2" ConnectionName="127.0.0.1" Userid="root"

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)

History of changes on BlockIP2


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 enhancement

You 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 enhancement

Thanks 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.

History of changes on BlockIP2


 

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:
alt chl(MQT2.TCP.MQT1) chltype(RQSTR) + * OR: chltype(RCVR)
     scyexit('c:\path..\LogIP(LogExit)') * NT

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:
alt chl(MQT2.TCP.MQT1) chltype(RQSTR) + * OR: any other type
     SCYDATA('172.20.109.*') +
     scyexit('c:\path..\BlockIP(BlockExit)') * NT

and if we're dealing with a BIG MQ:
alt chl(MQT2.TCP.MQT1) chltype(RQSTR) + * OR: any other type
     SCYDATA('172.20.109.*') +
     scyexit(BLOCKIP') * Z/OS

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 firewalls

How 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).

The following are trademarks of International Business Machines Corporation:
IBM, MERVA, MQSeries, WebSphere, WBIFN, Object REXX, AIX

Copyright © 2002, 2009 MrMQ.dk. All rights are reserved.
Last updated: 2009.08.03 .