2010-09-22 15 views
2

Nous avons une configuration de client WMQ - WAS/JMS via des canaux de connexion au serveur où nous essayons de mettre en sécurité les ID utilisateur.WMQ considération spéciale pour les clients WAS?

Maintenant, nous avons mis en place un ID utilisateur local sur la boîte MQ, mquserid, et laissé vide MCAUSER du canal.

Nous avons pensé: l'ID exécutant le client MQ (WAS dans notre cas) wasuserid, lorsqu'il est passé à MQ échouera car il n'est pas configuré sur la boîte MQ. Nous allons donc configurer l'alias JAAS (avec l'ID utilisateur: mquserid) pour la fabrique de connexions de file d'attente sur WAS, qui sera ensuite transmis à MQ et autorisera les connexions.

Mais, nous sont capables de se connecter et de mettre des messages sans l'alias JAAS :(

j'ai écrit un programme Java autonome pour se connecter à SMQ et il se comporte correctement en fonction de l'ID utilisateur que je passe lors de l'obtention connexion.

traite-t WMQ était dans une manière spéciale permettant des connexions sans vérifier contre son registre d'utilisateur local?

Répondre

2

Non, WAS est traitée comme toute autre connexion.

Dans la version 6 et les versions antérieures de WAS, il envoie un ID vide si l'ID utilisateur de la connexion WMQ n'est pas spécifié. Vous pouvez dire si c'est le cas en regardant l'état du canal pendant que WAS est connecté. Le MCAUSER du canal en cours de fonctionnement contiendra l'ID utilisé pour se connecter. Si l'état du canal en cours n'affiche aucune valeur MCAUSER, alors WAS n'a pas présenté d'ID.

L'autre possibilité est que le canal SVRCONN définition (pas d'état) a une valeur telle que mqm dans le MCAUSER. Dans ce cas, l'ID présenté lors de la demande de connexion est ignoré. Encore une fois, vérifiez l'état du canal pour voir quel ID est utilisé au moment de l'exécution ou vérifiez simplement la définition du canal SVRCONN pour rechercher une valeur MCAUSER.

Maintenant, voici le kicker - si le MCAUSER du canal est vide, alors WMQ acceptera quel ID est présenté. Si aucun ID n'est présenté, l'application ou l'utilisateur connecté s'exécute en tant qu'administrateur. Si une application ou un utilisateur peut être un administrateur WMQ, alors ils peuvent faire n'importe quoi sur QMgr et peuvent également exécuter à distance des commandes OS arbitraires sur le serveur sous QMgr. Pas bon.

La bonne réponse consiste à définir le MCAUSER sur le canal à la valeur que l'application est censée se connecter. À ce stade, l'application ne peut utiliser aucun autre ID, car le canal le remplace. Cependant, n'importe qui peut se connecter à ce canal, l'étape suivante consiste à authentifier la demande de connexion. Vous pouvez utiliser une sortie comme BlockIP2 qui est libre ou MQAUSX qui est un produit de fournisseur commercial. BlockIP2 va filtrer les demandes entrantes par adresse IP, ce qui peut être suffisant pour les connexions arrivant d'une IP statique dans un centre de données verrouillé. MQAUSX vérifiera réellement le UserID et le mot de passe envoyé pendant la demande de connexion de WAS (ou n'importe quel client, d'ailleurs). Vous pouvez également utiliser SSL et l'attribut SSLPEER de la chaîne pour authentifier les demandes à l'aide des certificats X.509. Notez que si vous utilisez MQAUSX pour valider un ID utilisateur et un mot de passe, utilisez le chiffrement SSL ou utilisez les versions côté client et côté serveur de la sortie. Sinon, vos informations d'identification sont diffusées en clair sur le câble, ce qui va à l'encontre du but recherché. Bien sûr, si vous sécurisez le canal de l'application, il est nécessaire de sécuriser les autres canaux sur l'hôte tels que SYSTEM.DEF. * Et SYSTEM.AUTO. * Sinon un attaquant contournera simplement le canal de l'application.

Notez que si les canaux RCVR, RQSTR et CLUSRCVR n'authentifient pas les demandes ou ne contiennent pas de valeur MCAUSER, ils exposent également l'accès administrateur. Par exemple, si je veux contrôler votre QMgr et verrouillé les canaux SVRCONN, je créer un QMgr sur mon bureau, supprimer mon SYSTEM.DEF.RECEIVER, créer un nouveau canal SDR appelé SYSTEM.DEF.RCVR et le point à votre QMgr. Si votre SYSTEM.DEF.RCVR (ou SDRQSTR ou SDCLUSRCVR) ou n'importe quel autre type de canal que vous avez défini manque de SSL ou de sortie, alors je peux me connecter et s'ils lcak un MCAUER alors je peux administrer le QMgr anonymement et exécuter Commandes OS Toute définition de canal sans valeur MCAUSER permet un accès administratif.
Tout canal sans SSL/SSLPEER et/ou une sortie permet des connexions anonymes. Pour plus d'informations à ce sujet, veuillez consulter les documents WMQ Hardening et WMQ Security Lab au https://t-rob.net/links. Consultez également les articles sur SSL et d'autres rubriques relatives à la sécurité WMQ dans la colonne Mission:Messaging d'IBM developerWorks Tech Journal.

+0

Merci Rob! C'est une réponse très claire. – dvlpr

+0

Je pensais que peut-être la transformation JMS Message -> MQ Message supprimait les champs User ID. Mais je vais vérifier le MCAUSER de la chaîne en cours d'exécution comme vous l'avez suggéré. Merci. – dvlpr

+0

Oui, les champs JMS sont mappés dans ou hors du MQMD. C'est un message MQ en premier et la structure JMS est mappée par-dessus. Le champ JMS peut être visualisé sous la forme d'un alias pour la valeur MQMD sous-jacente. –