ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ Installation/Configuration SupportNOT running amqcrsta as 'mqm'...

Post new topicReply to topic Goto page 1, 2  Next
NOT running amqcrsta as 'mqm'... View previous topic :: View next topic
Author Message
friedl.otto
PostPosted: Thu Feb 26, 2009 4:59 am Post subject: NOT running amqcrsta as 'mqm'... Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Thu Feb 26, 2009 5:04 am Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Feb 26, 2009 5:13 am Post subject: Reply with quote

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
View user's profile Send private message
friedl.otto
PostPosted: Thu Feb 26, 2009 5:26 am Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu Feb 26, 2009 5:34 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6280

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
View user's profile Send private message
friedl.otto
PostPosted: Thu Feb 26, 2009 5:38 am Post subject: Reply with quote

Centurion

Joined: 06 Jul 2007
Posts: 116

exerk wrote:
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?


After seeing this:

http://eusecwest.com/esw08/esw08-ruks.pdf
http://video.google.co.uk/videoplay?docid=-8419995190349463473

I don't want to gamble on what 'they' can and cannot do!
_________________
Here's an idea - don't destroy semaphores unless you're certain of what you're doing! -- Vitor
Back to top
View user's profile Send private message
exerk
PostPosted: Thu Feb 26, 2009 5:48 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6280

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
View user's profile Send private message
Vitor
PostPosted: Thu Feb 26, 2009 5:54 am Post subject: Reply with quote

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
View user's profile Send private message
friedl.otto
PostPosted: Thu Feb 26, 2009 5:54 am Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Feb 26, 2009 6:01 am Post subject: Reply with quote

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
View user's profile Send private message
friedl.otto
PostPosted: Thu Feb 26, 2009 6:35 am Post subject: Reply with quote

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:
Dont have the command server turned on if you dont need it

Cool ... shouldn't have negative effects on a gateway queue manager.

Quote:
Dont 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
View user's profile Send private message
mqjeff
PostPosted: Thu Feb 26, 2009 7:14 am Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Thu Feb 26, 2009 7:26 am Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Thu Feb 26, 2009 7:38 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6280

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
View user's profile Send private message
Vitor
PostPosted: Thu Feb 26, 2009 7:51 am Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexIBM MQ Installation/Configuration SupportNOT running amqcrsta as 'mqm'...
Jump to:



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.