は、V7.0およびそれ以前のためのHardening WebSphere MQプレゼンテーションを見てみましょう。覚えておくべきことは、WMQは何も認証しないということです。それはOSのアイデンティティとグループに基づいて認証しますが、パスワードチェックは行われません。
QMgrsとクライアントがWindowsネットワーク上に存在する状況では、接続でSIDが使用されるため、便利な認証が実行されたようです。 Windows以外のプラットフォームからの接続が試行された場合、Windows QMgrはIDの文字列表現を使用します。たとえば、デスクトップにLinux VMがある場合、MUSR_MQADMINというユーザーIDを簡単に作成でき、Windows QMgrがその接続を受け入れます。 Windows QMgrが解決できるSIDSとの接続だけを受け入れる設定がありますが、接続上でSID値をスプーフィングすることがわかっているだけです。
ここでの教訓はです。 Windowsでは1つでも、リモート接続を認証するようにQMgrを構成する必要があります。 WMQ v7.1以降では、QMgrにX.509証明書DNをユーザーIDにマップしたり、IPフィルタリングを実行する機能があります。 v7.1より前のこれらの関数では、BlockIP2などの終了が必要でした。 CapitalWareはBlockIP2の機能を持つMQAUSXを販売しています。さらに、IDとパスワードの認証を行い、サポートされています。
最初の推奨事項は、マッピングとフィルタリングのためのCHLAUTH
ルールを得るためにv7.1 QMgrを使用することです。証明書を使用しない場合でも、v7.1では管理上の接続が制限されているため、攻撃者は完全な管理権を得ることが難しくなります。パスワードの検証が必要な場合は、SSLチャネルを使用してパスワードを暗号化し、単純に再生攻撃を防ぎます。
ドメイン外からの接続を許可しても、新たな課題はありません。チャネル定義または終了によってMCAUSERが設定されていないv7.1より前のWindows QMgrでは、ローカルWindowsドメインからの接続であっても、リモート管理アクセスが可能です。管理者が認証情報を設定していない場合、誠実なユーザーは認証エラーを受け取ったにもかかわらず、が常にでしたが、そのQMgrを強化する必要がありました。
概要:管理ドメインの外部から発信クライアントの場合
、私は、相互認証TLS/SSLチャネルをお勧めします。上記にリンクした同じページには、WMQセキュリティラボガイドと、WMQ証明書の作成と交換のスクリプトを作成し、WMQ Explorerを設定する方法を示すスクリプトも含まれています。
他の方法を実行する場合は、正当なチャネルのMCAUSER
を設定または終了のいずれかに設定する必要があります。クライアントがIDを指定することが許可されている場合、管理IDの指定を妨げるものは何もありません。 SYSTEM.DEF.*
およびSYSTEM.AUTO.*
などの使用されていないチャネルの場合は、MCAUSERをno!body
またはv7.1以降の*NOACCESS
などのローカルIDにできない値に設定します。
いつもの回答は貴重です。ありがとうT.Rob。私はさらなる質問があれば私は新しいSOの要求を作成します.... S – scarpacci