mfirewall   User-space firewall for Solaris

With MxG2000 2.11, Murex steers away from the "old-style" ECN drivers interfacing directly to a RTI/deal import session, and towards the "new-style" drivers talking to an MxML workflow. This gives new flexibility in handling all kind of mappings (traders, product, portfolios and so on), at a slightly higher cost of maintenance.

In case you need to deploy these drivers in your environment where a firewall is utilized to seperate your Murex servers from the client that is running the market's native software (e.g. like when running the drivers directly on an Eurex MISS, or an EBS client), you may face some problems.
As the new drivers will be started from their dedicated launcher, you may need to put it, together with an XML server and XML hub, on the separate machine into an dedicated site. The MxG2000 architecture covers this quite easily, and even allows to use SOAP (with the SOAP bridge) or HTTP transport rather than RMI.

When you configure your sites and inter-site communication in the site matrix, you can direct the architecture to use specific TCP ports, and this in turn makes your security officer happy as a discrete set of ports can be enabled instead of opening up all TCP communication or largish port ranges between the hosts.
Now as you live in a unfriendly environment and your security officer might be a bit paranoid anyway, usually packets are dropped instead of rejected. Discussing this feature with him/her may turn out to be a bit cumbersome. This may seem not such of a problem...

But: parts of the XML server code does not care about the site matrix, and routing information given there is considered a hint, not mandatory. Consequently, it keeps on talking directly to the remote site, and quite frequently you will see. Your routing information is only used as a fallback. This of course makes your security officers not very happy as it fills their log files and eventually triggers even alarms or automatic counter-measures. And it won't make you happy either, because what you will experience is a longish delay on any operation that involves querying services from the XML server:


This annoying behaviour seems to not being solved with the 2.11 code, so unless using the Mx.3 versions, you will have to live with it. Or not use that firewall.
In fact, a second problem shows up, as the Java RMI calls to the servers and launchers behind the firewall, and vice versa to the MxML exchange and the servers on the Murex server side, will trigger Java's distributed garbage collection (DGC). This is the reason the whole system will start reacting sluggish as soon as DGC tries to clean up objects behind the firewall as it does not know about the site routing. Using proxies here might be a solution, though.

What to do?

Just deploy your very own user-space firewall!

This is where this little piece of software kicks in: Just forbid the questionable processes to contact certain hosts on certain TCP ports.

This works by intercepting any call to certain network-related functions, and passing or rejecting connections based upon a simple rule. The mechanism utilized is a feature of the shared linker ld.so called LD_PRELOAD (environment variable), it works by pre-loading a shared library before other (the systems') libraries are loaded. The rules are also set as environment variables as follows:


The rules are not as flexible as the usual rules for packet filters (may be an feature for an upcoming version), but very much sufficient for the little task to be carried out here.

An example? Consider you have a telnet daemon enabled on your local machine: 

env LD_PRELOAD=libmfirewall.so \
MFIREWALL_ADDR="127.0.0.1" MFIREWALL_PORTS="23" MFIREWALL_DEBUG=1 \
telnet localhost
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Verbindungsaufbau abgelehnt
This little example prevents connections to the local telnet daemon, only for that particular running telnet client. Any other program on the same machine would have succeeded at that time.
Please note: the shell environment variables should not globally exported, as this might cause unexpected problems. That's why the env program is used instead of simply exporting the shell variables. Also, for suid binaries, the mechanism is disabled by the OS for security reasons, this might cause error messages. Also special care should be taken for 64-bit binaries (like ps, top, lsof, ...) as preloading a 32-bit library won't work for them.

For Murex, just put this block into your launchmxj.app script: 

##########################################
# MR: Workaround for timeouts during communication via firewall
# The java start line is prepended by this setting where necessary
##########################################

MFIREWALL_SETTINGS=""

# Eurex MISSes side as seen from Murex
if [ "$env" = "xxxx" ]; then
MFIREWALL_SETTINGS="env LD_PRELOAD=lib/libmfirewall.so \
MFIREWALL_ADDRS=1.2.3.4,1.2.3.5 \
MFIREWALL_PORTS=4711,4712"
#MFIREWALL_SETTINGS="$MFIREWALL_SETTINGS MFIREWALL_DEBUG=1"
fi

# Murex side as seen from Eurex MISSes
if [ "$env" = "yyyyy" ]; then
MFIREWALL_SETTINGS="env LD_PRELOAD=lib/libmfirewall.so \
MFIREWALL_ADDRS=10.1.2.3,10.1.2.4,10.1.2.5 \
MFIREWALL_PORTS=7777,8888,9999"
#MFIREWALL_SETTINGS="$MFIREWALL_SETTINGS MFIREWALL_DEBUG=1"
fi

# override the setting: disable the workaround
#MFIREWALL_SETTINGS=""
and where necessary, prepend the Java call to the respective launchers with ${MFIREWALL_SETTINGS} : 
$_ECHO "Java cmd:\n$JAVA_CMD\n" >>$LOG_PATH/$LOG_FILE.log
${MFIREWALL_SETTINGS} \
$JAVA_CMD 2>&1 | $_TEE -a $LOG_PATH/$LOG_FILE.log &

Of course, this little software may come handy for other situations as well. In any case, I'd like to hear from you if it solved your problem, so please drop me a note if you successfully deployed this software, or if you have any further questions.
This is the tarball with the source code and precompiled binaries for Solaris 8:

Home Michael Rausch <mrausch  @  netadair.de>, last change 31.3.2007, 22:31