I think you should be able to create queues using the
LIKE parameter.
Sam
--- "Potkay, Peter M (PLC, IT)"
<[EMAIL PROTECTED]> wrote: > T.Rob wrote:
> "Every time I bring this up, people always reply
> that you can accomplish the
> same thing with an exit or MCAUSER. My answer to
> that is that you cannot
> restrict traffic to a specific channel. For
> example, if you define XYZ.RCVR
> with MCAUSER('xyz'), there is nothing to prevent ABC
> Corp from connecting to
> it."
>
> If ABC corp connects to XYZ.RCVR, and XYZ.RCVR has a
> MCA USer Identifier set
> to 'xyz', then all the messages coming across this
> channel will have xyz,
> even ABC's messages. How is that different than if
> the ABC got to XYZ.RCVR
> through another listner / port? If ABC connects
> XYZ.RCVR over port 2222,
> where a listener is running as def, aren't the
> messages still put as xyz,
> not def, xyz is in the MCAUSER?
>
>
>
>
>
> Also, you mentioned "we also delete all SYSTEM.DEF*
> objects". I tried
> deleting SYSTEM.DEFAULT.LOCAL.QUEUE on a dummy QM,
> and now I cant create any
> queues, which I suppose is the goal. But does that
> meaning that from this
> point forward, I can never create any more local
> queues on this QM?
>
>
>
>
> -----Original Message-----
> From: Wyatt, T. Rob
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 05, 2003 4:44 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Penetrating an outbound firewall
>
>
> Peter,
>
> I've not used MQIPT so I don't know what security
> concerns it addresses - or
> introduces. Since I work for a bank, I always start
> with the assumption
> that my DMZ servers are targets of attack and I try
> to nail them down as
> tight as possible. In my shop we would do that last
> paragraph regardless of
> any assumed security provided by MQIPT, our firewall
> or private circuits.
>
> And that's just the beginning. In the DMZ we also
> delete all SYSTEM.DEF*
> objects, set up LOCALADDR to bind the
> internal-facing channels to
> internal-facing NICs and run security exits (or SSL
> where available). We
> also never use a SVR channel in the DMZ or define a
> SVRCONN for external
> use. As a rule, the Command Server and Trigger
> Monitor are turned off
> unless specifically required. If we do run a
> trigger monitor, it runs under
> a low-privileged ID. All channels use MCAUSER set
> to a low-privileged ID.
> The QMgr runs under an ID other than mqm and mqm is
> removed from the mqm
> group. UserIDs in the DMZ are never authorized to
> SET*. All of these
> configurations address one or more specific
> vulnerabilities and when you
> apply all of them in combination, it is VERY
> difficult to get admin access
> to the QMgr from outside or to hijack queues and
> channels for other than
> their intended use.
>
> Incidentally, you mentioned a dedicated QMgr "for
> outbound messaging (to
> other companies)" and I notice that's plural. Are
> you hosting interfaces to
> more than one company on the same QMgr? In that
> case, I would DEFINITELY
> want to lock down each interface under a separate
> ID. Can you imagine the
> fallout if company A used your MQ interface to
> maliciously attack Company B?
> If your naming standards make it easy to guess
> channel names and queue names
> based on customer name or ID, hijacking someone
> else's channel or queue is
> not so farfetched. Hell, you might even do it by
> accident when copying MQSC
> scripts from one customer to another and miss the
> RNAME in a QREMOTE or
> something. If you made this mistake with the
> listener running as mqm,
> nothing would stop the messages from going to the
> wrong queue or out to the
> wrong customer.
>
> -- T.Rob
>
> -----Original Message-----
> From: Potkay, Peter M (PLC, IT)
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 05, 2003 3:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Penetrating an outbound firewall
>
>
> T.Rob, in regards to your last paragraph, is that
> still necessary if
>
> A. Your queue manager is a dedicated one just for
> outbound messaging (to
> other companies) sitting in the DMZ
>
> and
>
> B. MQIPT sits between your DMZ queue manager and any
> outside companies?
>
> (There are very specific firewall rules between the
> DMZ queue manager and
> the internal queue manager inside of the internal
> firewall that it connects
> to.)
>
>
>
> -----Original Message-----
> From: Wyatt, T. Rob
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 05, 2003 12:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Penetrating an outbound firewall
>
>
> Doug,
>
> We are using direct MQ connections with firewall
> rules as specified in MA86
> (
>
http://www-3.ibm.com/software/integration/support/supportpacs/individual/sup
> portpacs/ma86.pdf
>
<http://www-3.ibm.com/software/integration/support/supportpacs/individual/su
> pportpacs/ma86.pdf> ).
>
> This has been working fine for us except that
> servers with dual NICs or
> virtual IP addresses (our Veritas clusters), the
> socket would sometimes bind
> to a different address under MQ pre-5.3 and be
> blocked by the firewall.
> Prior to 5.3 we had to set up rules for the physical
> AND virtual addresses
> since the binding was unspecified. The LOCALADDR
> field has really
> simplified things. We have tried setting up rules
> for entire subnets but
> have since switched to using a set of rules for each
> point-to-point
> connection. Although there are more rules, there
> are less surprises when
> you change one.
>
> Might I also suggest that you run a listener (not
> inetd) for external
> traffic that is different from your internal
> traffic. This way, you can
> shut down the external connection without impacting
> your internal network.
> If you have multiple business partners connecting to
> the same QMgr, run a
> different listener for each. Then you can disable
> one without impacting the
> others.
>
> If you are really security conscious, run the
> listeners under a
> low-privileged ID. For example, if you have
> connections to XYZ Corp and ABC
> Corp, you can create UserIDs xyz and abc and put
> them into groups xyz and
> abc, respectively. Then start listeners under each
> ID. This will allow you
> to set up authorizations on the queues such that
> traffic from ABC and XYZ
> cannot end up on each other's queues or, worse yet,
> on your Command Queue.
> Every time I bring this up, people always reply that
> you can accomplish the
> same thing with an exit or MCAUSER. My answer to
> that is that you cannot
> restrict traffic to a specific channel. For
> example, if you define XYZ.RCVR
> with MCAUSER('xyz'), there is nothing to prevent ABC
> Corp from connecting to
> it. For that matter, there is nothing to prevent
> ABC Corp from connecting
> to SYSTEM.DEF.SVRCONN or any other channel unless
> you run exits on ALL of
> them or use SSL on ALL of them. Running the
> listeners under low-privileged
> IDs allows you to lock down a specific path from the
> firewall all the way
> down to specific queues.
>
> Regards,
> -- T.Rob
>
> -----Original Message-----
> From: Pierson, Doug (ITD)
> [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 05, 2003 10:30 AM
> To: [EMAIL PROTECTED]
> Subject: Penetrating an outbound firewall
>
>
>
> Hi MQers,
>
> Does anyone have any experience with sending MQ
> messages outbound through a
> firewall that restricts outbound traffic? The
> traffic needs to be delivered
> to numerous destination servers. Are you using
> MQ-IPT? If so, are you
> using multiple ports to define multiple routes and
> sending the traffic to
> IPT instances deployed at each of the target
> servers? Or, is all of your
> traffic sent to a single IPT instance outside of the
> firewall using a single
> route? From there, queue name resolution can be
> used to direct it to the
> true destination server with the messages in MQ
> protocol.
>
> The goal of the firewall administrator is to
> restrict us to minimal port
> usage. We see the restriction to a single port
> using IPT to be to costly in
> terms of performance. The traffic volume is
> significant. I'm also aware of
> MQ5.3's introduction of the LOCLADDR channel
> attribute to restrict outbound
> traffic to a single port or range of ports.
>
> Any comments or feedback would be much appreciated.
>
> Thanks,
> Doug Pierson
>
>
>
>
>
>
> This communication, including attachments, is for
> the exclusive use of
> addressee and may contain proprietary, confidential
> or privileged
> information. If you are not the intended recipient,
> any use, copying,
> disclosure, dissemination or distribution is
> strictly prohibited. If
> you are not the intended recipient, please notify
> the sender
> immediately by return email and delete this
> communication and destroy all
> copies.
>
>
>
________________________________________________________________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
