| Author |
Message
|
| friedl.otto |
 Posted: Thu Feb 26, 2009 4:59 am Post subject: NOT running amqcrsta as 'mqm'... |
 |
|
Centurion
Joined: 06 Jul 2007
Posts: 116
|
...can it be done?
As probably knows by now, I am playing around on:
* SLES 10 SP2 x86 64-bit
* IBM WebSphere MQ 7.0.0.1
Here is my '/etc/services' file:
| Code: |
.
.
.
MQSeries 1410/tcp # MQSeries channel listener
MQTest 1420/tcp # MQSeries channel listener
|
Here are my '/etc/xinet.d/mqlistener' file:
| Code: |
service MQSeries
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = mqm
server = /opt/mqm/bin/amqcrsta
server_args = -m ALICE
log_on_failure += USERID
}
service MQTest
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = test
server = /opt/mqm/bin/amqcrsta
server_args = -m ALICE
log_on_failure += USERID
} |
Which yielded:
| Code: |
root@~> telnet localhost 1410
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
root@~> telnet localhost 1420
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
root@~> |
Which hinted that xinetd actually listened on port 1420, but failed to start
the listener. Hunch confirmed by this:
| Code: |
test@~> ls -l /opt/mqm/bin/amqcrsta
-r-sr-s--- 1 mqm mqm 18234 2008-12-19 21:58 /opt/mqm/bin/amqcrsta
test@~> strings /opt/mqm/bin/amqcrsta | head -10
strings: /opt/mqm/bin/amqcrsta: Permission denied |
I don't want test to be a member of the mqm group ... can this be done?
_________________
Here's an idea - don't destroy semaphores unless you're certain of what you're doing!  -- Vitor |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Feb 26, 2009 5:04 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
No nono no.
Please don't use anything other than an MQ Listener Object with MQ v6 or v7. Don't use runmqlsr and don't use inetd!
I can't imagine a scenario in which running a listener as a non MQM user is useful... If you are concerned about default users, it's a lot lot lot lot easier to set MCAUSER on all of your channels than it is to try and run the listener as non-MQM. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 26, 2009 5:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
Please don't use anything other than an MQ Listener Object with MQ v6 or v7. Don't use runmqlsr and don't use inetd!
I can't imagine a scenario in which running a listener as a non MQM user is useful... If you are concerned about default users, it's a lot lot lot lot easier to set MCAUSER on all of your channels than it is to try and run the listener as non-MQM. |
Running internal processes as non-mqm is like putting a jet engine in a Model T Ford; you could probably getting it working but it's not worth the effort and will give you serious problems when you use it. Especially the first time you hit a bump or try and turn.
Also inetd has been depreciated since WMQv5.2. I dread to think why you came to the conclusion it was a good idea but this kind of thinking will have you doing a bungee jump off a 200' bridge with a 200' cord. If for some bizarre and incomprehensible reason you don't want a queue manager object, use runmqlsr.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| friedl.otto |
| Posted: Thu Feb 26, 2009 5:26 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007
Posts: 116
|
| mqjeff wrote: |
No nono no.
Please don't use anything other than an MQ Listener Object with MQ v6 or v7. Don't use runmqlsr and don't use inetd! |
Uhm ... why?
| mqjeff wrote: |
| I can't imagine a scenario in which running a listener as a non MQM user is useful... If you are concerned about default users, it's a lot lot lot lot easier to set MCAUSER on all of your channels than it is to try and run the listener as non-MQM. |
I am toying with securing an encrypted RCVR channel from an offsite
service provider into a gateway queuemanager ... and started wondering
about the following questions:
1. What if someone spoofs the IP of the provider? Even though the host
will be firewalled to the hilt, a firewall cannot catch that!
2. If they then proceed to be contact admin to my RCVR (via my listener) they
could conceivably get 'mqm' access.
3. Surely it is better if the process which is hit first by 'aliens' does not
run as a privileged user.
You have some pointers on this topic?
_________________
Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Feb 26, 2009 5:34 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| friedl.otto wrote: |
| Uhm ... why? |
Because, as stated, it was deprecated in V5.3, when runmqlsr was promoted as the preferred method.
| friedl.otto wrote: |
I am toying with securing an encrypted RCVR channel from an offsite service provider into a gateway queuemanager ... and started wondering about the following questions:
1. What if someone spoofs the IP of the provider? Even though the host will be firewalled to the hilt, a firewall cannot catch that!
2. If they then proceed to be contact admin to my RCVR (via my listener) they could conceivably get 'mqm' access.
3. Surely it is better if the process which is hit first by 'aliens' does not run as a privileged user.
You have some pointers on this topic? |
Even if they spoof the IP, will they also be able to spoof an SSL certificate? Will they be able to over-ride the MCAUSER in your RCVR channel?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| friedl.otto |
| Posted: Thu Feb 26, 2009 5:38 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007
Posts: 116
|
|
| Back to top |
|
|
| exerk |
| Posted: Thu Feb 26, 2009 5:48 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
The Technical and High-Level recommendations at http://eusecwest.com/esw08/esw08-ruks.pdf certainly seem to close all the doors you're worried about.
Why not put a Broker flow that inspects message content and acts on it? Why not have a stand-alone queue manager as a Gateway? Then have a client-based application move it to your internal WMQ network? I'm all for a healthy dose of paranoia, but it can go a little too far
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 26, 2009 5:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| friedl.otto wrote: |
[I don't want to gamble on what 'they' can and cannot do!  |
But there's nothing new in this. Certainly all the "recommendation" in the PDF have been best practice for donkey's years.
If you're trying to increase security by running processes as a non-mqm user, you'll achieve much the same effect by not running the processes at all, and will have provable security as access to the queue manager will be impossible. You can then extend the security by removing all the SVRCONN channels, and prevent unauthorised clients from connecting.
Usability might decrease a little.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| friedl.otto |
| Posted: Thu Feb 26, 2009 5:54 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007
Posts: 116
|
| exerk wrote: |
| I'm all for a healthy dose of paranoia, but it can go a little too far |
True ... I am tasked with proving that:
| Code: |
| TLS_RSA_WITH_AES_256_CBC_SHA + SSLPEER() + MCAUSER() + LOCLADDR() + Gateway QMGR + setmqauth + Firewall |
... is sufficient, and a dedicated leased line is an unnecessary expense
(telecoms is an expensive luxury in the third world).
_________________
Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 26, 2009 6:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| friedl.otto wrote: |
... is sufficient, and a dedicated leased line is an unnecessary expense
|
Is sufficient for what? Financial transaction? Football scores?
The only way to make a system completely secure is to rip out the network connections. How secure is "sufficiently" secure is a management decision. Remember that the majority of successful attacks these days are either performed from inside the organisation or with assistance from inside the organisation, so no single layer technical solution is bulletproof.
Another question - how much does all this additional software & configuration add up to in terms of development, support and increased administration over the years? Against the cost of a leased line (which doesn't provide total security but is just an additional layer)?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| friedl.otto |
| Posted: Thu Feb 26, 2009 6:35 am Post subject: |
|
|
Centurion
Joined: 06 Jul 2007
Posts: 116
|
| Vitor wrote: |
| Is sufficient for what? Financial transaction? Football scores? |
What would the answer be for 'accounting reports'?
And for ... let's say 'financial transactions'? 
| Vitor wrote: |
| The only way to make a system completely secure is to rip out the network connections. |
You forgot switching it off, pulling out all plugs and casting it in 2m of steel
reinforced concrete.
| Vitor wrote: |
| How secure is "sufficiently" secure is a management decision. |
Based, of course, on the inputs from technical advisors.
| Vitor wrote: |
| Remember that the majority of successful attacks these days are either performed from inside the organisation or with assistance from inside the organisation, so no single layer technical solution is bulletproof. |
This would suggest that the dedicated line does not offer much in way of
additional protection, since it won't be the 'aliens' who would hijack the
data and take it home (unencrypted) on a USB stick.
Moving onto the ancient wisdom recommended by Mr. Ruks:
| Quote: |
| • Never rely on the MCAUSER parameter for security |
Meaning what? ... Not as the only defense, or not as a defense at all?
| Quote: |
| • Always use security exits on channels and make sure you have the code audited. |
Uhm ... what about Vitor's exit heuristics (which I happen to like)?
| Quote: |
| • Don’t have the command server turned on if you don’t need it |
Cool ... shouldn't have negative effects on a gateway queue manager.
| Quote: |
| • Don’t use Channel Auto Definition |
Obviously! 
| Quote: |
| • Be specific with the User Filtering strings |
Say what!? 
_________________
Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Feb 26, 2009 7:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| friedl.otto wrote: |
Moving onto the ancient wisdom recommended by Mr. Ruks:
| Quote: |
| • Never rely on the MCAUSER parameter for security |
Meaning what? ... Not as the only defense, or not as a defense at all? |
I disagree with this personally, as I believe it is assuming that it is possible to bypass the part of the network protocol exchange that enforces MCAUSER on the qmgr side. I'm fairly certain that this vulnerability has been closed already - see some of the fixes in the 6.0.2.2 timeframe.
Regardless, MCAUSER by itself is not sufficient and in fact can be viewed as a security hole in and of itself. Everyone who can establish a network connection to the listener port can then become the MCAUSER, if you don't have SSL enabled on your channels.
| friedl.otto wrote: |
| Quote: |
| • Be specific with the User Filtering strings |
Say what!? |
This just means set SSLPEER to as fully qualified a string as you can, rather than specifying something like "*country=USA*". |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 26, 2009 7:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| friedl.otto wrote: |
You forgot switching it off, pulling out all plugs and casting it in 2m of steel
reinforced concrete. |
This has the added advantage of eliminating issues connected to software upgrades.
| friedl.otto wrote: |
| Vitor wrote: |
| How secure is "sufficiently" secure is a management decision. |
Based, of course, on the inputs from technical advisors. |
No - based on the management requirements driven principally by legislation & audit needs.
| friedl.otto wrote: |
This would suggest that the dedicated line does not offer much in way of
additional protection, since it won't be the 'aliens' who would hijack the
data and take it home (unencrypted) on a USB stick. |
A leased line does not prevent an attack from aliens with some knowledge of digital signals and a pair of crocodile clips unless you've taken additional measures (typically hardware crypto).
| friedl.otto wrote: |
| Moving onto the ancient wisdom recommended by Mr. Ruks: |
Very ancient and somewhat obvious.
| friedl.otto wrote: |
| Never rely on the MCAUSER parameter for security |
Meaning what? ... Not as the only defense, or not as a defense at all?[/quote]
I don't think MCAUSER is as vunerable as he thinks, provided you've secured it in the first place.
[quote="friedl.otto"]
| Quote: |
| • Always use security exits on channels and make sure you have the code audited. |
What, like on a commercial solution? But again, how much more secure is that than "native" SSL? Against an alien with a certificate from a trusted CA (I believe I'm quoting him here)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Feb 26, 2009 7:38 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| friedl.otto wrote: |
You forgot switching it off, pulling out all plugs and casting it in 2m of steel
reinforced concrete. |
This has the added advantage of eliminating issues connected to software upgrades. |
Hardware upgrades become a bit more problematical though... 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 26, 2009 7:51 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Vitor wrote: |
| friedl.otto wrote: |
You forgot switching it off, pulling out all plugs and casting it in 2m of steel
reinforced concrete. |
This has the added advantage of eliminating issues connected to software upgrades. |
Hardware upgrades become a bit more problematical though... |
No problem at all - you don't have issues from hardware upgrades any more than you have issues from software upgrades. Because you don't do either.
The serious point (and yes there is a serious point) is that an utterly secure system, protected from all forms of breakdown and attack, is unusable. Hence any design represents a tradeoff between security/uptime and access.
To use an image as illustration, a machine which did have the network links pulled out, housed and locked in a very secure vault, was still vunerable to Tom Cruise on a flying harness, vunerable to the guy who worked there and almost unusable as any data being transmitted had to fit on a single floppy.......
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
