Запустите команды Linux/MQSC из клиента mq

Question

Запустите команды Linux/MQSC из клиента mq

Хорошо, я хочу проверить, могу ли я запускать некоторые команды ОС или MQSC на сервере MQ удаленно. Насколько я знаю, это можно сделать с SYSTEM.ADMIN.SVRCONN, Для этого я добавляю удаленный администратор очередей в мой клиент WebSphere MQ. Я ставлю имя диспетчера очереди на сервер с правильным IP, но когда я использую SYSTEM.ADMIN.SVRCONN В качестве названия канала я получил: Channel name not recognized (AMQ4871) ошибка.

Кроме того, если у меня есть название канала, например, MY.CHANNEL.NAME, и это канал подключения к серверу с mqm как его MCAUSERМожно ли запустить некоторые команды (MQSC или OS) через этот канал на сервере?

Благодарю.

Edit1

Я использую WebSphere MQ v.7.0

Под "добавлением удаленного диспетчера очереди в мой клиент WebSphere MQ" я подразумевал добавление удаленного диспетчера очереди в MQ Explorer.

Edit2

Я хочу объяснить мой вопрос более точно в этом редактировании. Я хочу подключиться к удаленному Qmanager через MQ Explorer. Я знаю имя Qmanager и его IP-адрес. Кроме того, удаленный Qmanager имеет как SYSTEM.ADMIN.SVRCONN а также SYSTEM.AUTO.SVRCONN канал доступен. Когда я проверяю CHLAUTH для этих каналов у меня есть:

AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.ADMIN.SVRCONN)           TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)
dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
     5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.
dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
     6 : dis chl(SYSTEM.AUTO.SVRCONN) MCAUSER
AMQ8414: Display Channel details.
   CHANNEL(SYSTEM.AUTO.SVRCONN)            CHLTYPE(SVRCONN)
   MCAUSER( )

Как вы можете видеть здесь, я должен быть в состоянии соединиться через эти два канала и выполнить некоторые команды. Но когда я выбираю SYSTEM.ADMIN.SVRCONN В качестве имени канала в удаленной конфигурации я получаю: Channel name not recognized (AMQ4871) и когда я выбираю SYSTEM.AUTO.SVRCONN в качестве названия канала я получаю: You are not authorized to perform this operation (AMQ4036).

Любая идея?

6

linux ibm-mq

Источник

user1597059 05 май '15 в 12:53

2 ответа

Решение

Когда я использую SYSTEM.ADMIN.SVRCONN в качестве имени канала, я получаю: Ошибка имени канала не распознана (AMQ4871).

Вы определили канал в удаленном администраторе очередей?

если у меня есть имя канала, например, MY.CHANNEL.NAME, и это канал подключения к серверу с mqm в качестве MCAUSER, могу ли я выполнить некоторые команды (MQSC или OS) через этот канал на сервере?

Конечно. И так может кто-то еще. Вы должны прочитать о безопасности MQ и не подвергать свой менеджер очередей хакерам.

4

Источник

user1431734 05 май '15 в 19:55

Другие вопросы по тегам linux ibm-mq

user214668 06 май '15 в 02:13 2015-05-06 02:13 · Accepted Answer · 2015-05-06 02:13

Я добавляю удаленный администратор очередей в мой клиент WebSphere MQ.

Я не совсем уверен, что это значит точно. MQ Explorer хранит список определений администратора очередей. MQ Client - это просто библиотека для создания соединений.

Если вы имели в виду, что добавили в MQ Explorer удаленный администратор очередей, то это имеет смысл. В дополнение к определению соединения в проводнике вам также нужно будет предоставить соединение в администраторе очередей. Это означает определение SYSTEM.ADMIN.SVRCONN канал или один с именем по вашему выбору, определения и запуска слушателя. Если вы работаете с менеджером очередей версии 7.1 или выше (при запросе о MQ всегда полезно перечислять версии), вам также потребуется создать правило CHLAUTH, чтобы разрешить соединение, и другое правило CHLAUTH, чтобы разрешить соединение с административными привилегиями. либо отключите, либо отключите правила CHLAUTH, но это не рекомендуется.

Если у меня есть название канала, как MY.CHANNEL.NAME и это канал подключения к серверу с mqm как его MCAUSER Можно ли запустить некоторые команды (MQSC или OS) через этот канал на сервере?

Может быть.

Из коробки MQ запрещает все клиентские подключения. Существуют правила CHLAUTH, запрещающие административные подключения, и другие правила CHLAUTH, запрещающие подключения для любых SYSTEM.* канал, кроме SYSTEM.ADMIN.SVRCONN, Поскольку соединения администратора запрещены, пользователи без прав администратора должны иметь доступ, предоставленный с использованием SET AUTHREC или же setmqaut команды, прежде чем они могут использовать SYSTEM.ADMIN.SVRCONN следовательно, MQ называется "безопасным по умолчанию".

Когда вы создаете MY.CHANNEL.NAME и подключитесь как администратор, и если CHLAUTH включен, соединение будет отклонено. Вы должны будете добавить новое правило CHLAUTH, например...

SET CHLAUTH('MY.CHANNEL.NAME') TYPE(BLOCKUSER) USERLIST('*NOBODY') WARN(NO) ACTION(ADD)

... чтобы разрешить подключение администратора.

(Примечание: правила блокировки MQ CHLAUTH используют методологию черного списка. Блоки правил по умолчанию *MQADMIN со всех каналов. Правило, которое я перечислил выше, переопределяет правило по умолчанию, потому что имя канала является более конкретным, и оно блокирует *NOBODY - который представляет собой список идентификаторов пользователя, который не включает mqm или любой другой административный идентификатор пользователя. Это странно, но вот как это работает.)

Больше на эту тему на http://t-rob.net/links, и в частности презентация конференции Morag на CHLAUTH правила это обязательно прочитать.

20150506 Обновление
Ответ на правки № 1 и № 2 в исходном вопросе выглядит следующим образом:

Первое редактирование говорит, что QMgr находится на v7.0, а второе показывает, что QMgr имеет определенные записи CHLAUTH. Поскольку CHLAUTH не был доступен до v7.1, эти два утверждения являются взаимоисключающими - они не могут быть оба истинными. При предоставлении версии MQ-сервера или клиента лучше всего вставить в вывод dspmqver, Если вопрос касается GSKit, кода Java или других компонентов, выходящих за рамки базового кода, то dspmqver -a было бы еще лучше.

Вывод MQSC, представленный в обновлении вопроса, полностью объясняет ошибки.

dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
     5 : dis chl(SYSTEM.ADMIN.SVRCONN) MCAUSER
AMQ8147: WebSphere MQ object SYSTEM.ADMIN.SVRCONN not found.

Как отмечает Мораг, SYSTEM.ADMIN.SVRCONN не может быть использован, потому что он не был определен.

AMQ8878: Display channel authentication record details.
   CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
   ADDRESS(*)                              USERSRC(NOACCESS)

Ошибка аутентификации происходит потому, что любое соединение с любым SYSTEM.* Канал SVRCONN, который явно не переопределен, блокируется этим правилом. Правило CHLAUTH для SYSTEM.ADMIN.SVRCONN имеет приоритет, потому что он более явный, и разрешает не-админские соединения с этим каналом. Отсутствие аналогичного основного правила для SYSTEM.AUTO.SVRCONN означает, что это отрицается существующим правилом для SYSTEM.* каналы, как указано выше.

Как отмечалось ранее, НАСТОЯТЕЛЬНО рекомендуется зайти на связанный веб-сайт и прочитать презентацию Morag на конференции, посвященную безопасности MQ v7.1 и правилам CHLAUTH. Он объясняет, как применяются правила CHLAUTH, как работает приоритет, и, возможно, самое главное, как проверить их с помощью MATCH(RUNCHECK) параметр.

Чтобы сделать MQ Security правильным, вам нужно как минимум следующее:

Определите канал с именем, которое не начинается с SYSTEM.* и установить MCAUSER('*NOBODY'),
Определите правило CHLAUTH, чтобы разрешить подключения к этому каналу, сопоставляя MCAUSER по мере необходимости.
Если вы хотите подключиться к каналу с mqm или доступ администратора, определение правил CHLAUTH для аутентификации канала, предпочтительно с использованием TLS и сертификатов.

Есть несколько вещей, которые вы не хотите делать по причинам, которые объясняются в Мораге и моих презентациях. Они включают...

С помощью SYSTEM.AUTO.SVRCONN для любых законных связей.
По этому вопросу, используя SYSTEM.* ничего (кроме SYSTEM.ADMIN.SVRCONN или же SYSTEM.BROKER.*) для законных связей.
Разрешение неаутентифицированных соединений администратора.
Отключение правил CHLAUTH.
Отключение OAM.

Я хочу, чтобы люди изучали безопасность MQ и изучали ее очень хорошо. Однако, как консультант, который специализируется на этом, я должен сказать вам, что даже у клиентов, которые наняли меня, чтобы я проводил занятия на месте и помогал с их внедрением, возникли проблемы с его блокировкой. Из этого факта следует извлечь две идеи.

Во-первых, если у вас недостаточно времени, чтобы быстро освоить безопасность MQ, реализация не будет безопасной. Чтобы изучить тему и понять, как все части достаточно хорошо сочетаются друг с другом, чтобы разработать достойную модель безопасности, требуется практическое обучение с использованием QMgr, которое вы можете создавать, разбивать, разбирать, строить снова и т. Д. посвященное практическое изучение, или месяцы или годы случайного изучения. Мой совет здесь, чтобы получить MQ Advanced для разработчиков. Он полностью функционален, бесплатен и имеет расширенный набор элементов управления, которые есть у вас на QMgr v7.1 или v7.5, над которым вы сейчас работаете.

Второе понимание заключается в том, что не существует ярлыка для изучения безопасности MQ (или любого другого ИТ). Если подходить так, как будто это просто вопрос конфигурации, то почти гарантированно не будет безопасным при реализации. Если к нему приблизиться как к изучению всех различных элементов управления, доступных для аутентификации, авторизации и применения политик, а затем к изучению того, как все они взаимодействуют, и если безопасность рассматривается как практическая дисциплина, то можно достичь некоторой значимой безопасности.

Решение этой второй проблемы потребует инвестиций в образование. Прочитайте презентации и опробуйте различные элементы управления вживую на тестовом QMgr, которым вы управляете. Поймите, какие ошибки идут в какие журналы ошибок, которые генерируют сообщения о событиях и какой тип событий генерируется. Получить некоторые диагностические инструменты в SupportPacs, такие как MS0P, который является одним из моих любимых, и ознакомиться с ними. Подумайте о том, чтобы посетить MQ Tech Conference (где вы можете встретиться со многими из тех, кто отвечает здесь на SO) для более углубленного обучения.

Если вы (или ваш работодатель) не готовы посвятить себя углубленному наращиванию навыков или пытаетесь научиться этому в ближайшее время, тогда подумайте о том, чтобы нанимать глубокие навыки MQ Security по мере необходимости, потому что полагайтесь только на Обучение по данной теме на рабочем месте - это рецепт для незащищенной сети.