| Author |
Message
|
| Thomasb |
 Posted: Sat Oct 08, 2005 12:14 am Post subject: QM or MQ Client in DMZ |
 |
|
Novice
Joined: 07 Oct 2002
Posts: 15
Location: Sundsvall, Sweden
|
We are developing a simple public Webapplicatiion.
In short it works like this:
1. One form with one field in witch the user puts his social security number
2. These numbers are stored in a SQL database in DMZ
3. Mainframe QM sends a request for these numbers and waits for the answer on a response queue.
It's very likely that we in the future will develop new applications which will use queues to communicate with backend system.
Here's my question:
In general what is best? A full-blown Websphere MQ installation in our DMZ server farm with channel pairs to QM inside out firewall or just a MQ Client that's connected to a QM inside our firewall?
I know there's a Support Pac called 'Internet pass-through' (or something??) which - I guess - can be of interest in this matter.
If anyone of you wants to share your experiences in this area with me I would be very grateful. |
|
| Back to top |
|
 |
| zpat |
| Posted: Sat Oct 08, 2005 12:26 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Internet pass-through is not relevant here, as MQ traffic is not crossing a public network.
I would normally recommend MQ clients on web servers. We have a HA/CMP queue manager in our DMZ which in turn connects to the internal queue manager. |
|
| Back to top |
|
|
| Thomasb |
| Posted: Sat Oct 08, 2005 12:35 am Post subject: |
|
|
Novice
Joined: 07 Oct 2002
Posts: 15
Location: Sundsvall, Sweden
|
Thanks for your quick answer!
I should have added that our webform (webserver) is on the public internet and it talks (port 80) to a small fragment of code on an appserver in DMZ and it's the code on the appserver that have to be MQ aware.
We have no plans to put a MQ Client or QM installation on the webserver. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Oct 08, 2005 3:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I normally put webservers in the DMZ and app servers in the internal network... but that's me.
And I also wouldn't put the database server in the DMZ either.
Zpat's right on. Install the MQ Client on your app server. Unless that code requires a globally coordinated transaction between the database and mq. Then you'll have to install a qmgr on the app server.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Oct 08, 2005 8:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We have a similiar scenario here and we installed just the MQClient on the Web Servers in the DMZ, who then talk to my Queue Managers inside the firewall.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 08, 2005 10:13 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| jefflowrey wrote: |
I normally put webservers in the DMZ and app servers in the internal network... but that's me.
And I also wouldn't put the database server in the DMZ either. |
I agree, you're completely missing out on the point of having DMZ - being a server that contains no info, and only forwards packets from side to side. In a sense, the DMZ is what's *supposed* to be hacked into, the idea being that if that happens, no harm done.
A DMZ setup should look like this: ApplServer <> Firewall <> DMZ <> Firewall <> WebServer, or at least that's how the theory goes...
| jefflowrey wrote: |
| Zpat's right on. Install the MQ Client on your app server. |
I have to ask, why the unanimous agreement on a Client connection? To me it sounds like a normal server/client dilema, which depends upon comm stability, throughput, administration investement etc; why does this case entail MQClient automatically?
(I personally had a full QM on the DMZ, and was indeed thankful for it, since comm+firewall in such cases tends to be less reliable) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Oct 08, 2005 10:21 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
No QM in the DMZ, no data queued up in the DMZ that could get hacked at.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Oct 08, 2005 11:32 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, no extra license fees if not needed.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 08, 2005 12:22 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| PeterPotkay wrote: |
| No QM in the DMZ, no data queued up in the DMZ that could get hacked at. |
Point taken, but it's still quid-pro-quo, with a client there's not much difference- you could sniff the network output; I think the idea is not to have static data on the DMZ machine (such as dbs), since it is much easier to manipulate upon a successful hack. Dynamic data - such as TCP packets or MQ messages should be much harder to read (Since, amongst other things, mq knowledge being much rarer than DB knowledge).
True, in case someone hacks you in the exact same moment you had a long-term comm error, he might be able to get to those msgs, but what are the odds? So the question is, like in every security setup, is the added functionality of a QM is worth the added risk.
Note that if you use the configuration I described, the only way to reach the DMZ is via the webserver machine, and hacking a comp from a hacked comp is quite difficult - usually one doesn't get enough access to continue "hopping" along the net.
| jefflowrey wrote: |
| Also, no extra license fees if not needed. |
Yea, that's what I meant by "a normal server/client dilema"... Of course some sites (few indeed) have a pre-paid license, no matter how many QMs - like a site I used to work for. |
|
| Back to top |
|
|
|
|
