| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| SSLPEERMAP question |
« View previous topic :: View next topic » |
| Author |
Message
|
| crashdog |
 Posted: Fri Jul 24, 2020 2:58 am Post subject: SSLPEERMAP question |
 |
|
Voyager
Joined: 02 Apr 2017
Posts: 77
|
Hello all,
It is my understanding that when a chlauth uses an SSLPEERMAP that has no wildcard / asterisk in the SSLPEER attribute, the certificates subject must be a complete match to the SSLPEER attribute.
However after testing a bit I have following situation that I can't fully understand.
I use L, usually used for location, but since there is only one location I use it to distinguish environments. That is dev, test, uat and prod.
I've created channels setting SSLCAUTH(REQUIRED) and set a SSLCIPH. MCAUSER is empty for now.
The CHLAUTH contains one entry to allow admin to the channel.
| Code: |
CHLAUTH(QMNAME.ADMIN) +
TYPE(BLOCKUSER) +
USERLIST(NOBODY)
|
other then that there are only SSLPEERMAPS like
| Code: |
CHLAUTH(QMNAME.ADMIN) +
TYPE(SSLPEERMAP) +
SSLPEER('CN=myid,L=uat,DC=companydomain,DC=net') +
SSLCERTI('CN=subordinate-companydomain.net,DC=companydomain,DC=net') +
ADDRESS(192.0.178.*) +
USERSRC(MAP) +
MCAUSER('mqm')
|
Now my problem is that any certificate with the same signing CA can connect using that admin channel. But the idea is to only allow certificates matching the SSLPEER to connect.
I tried to follow the red book "secure messaging scenarios" chaper 9 to set things up. But I guess I must have missed something.
Queue managers involved are from 8.0.0.4 to 9.1.0.4.
Kind Regards,
Gerhard
_________________
You win again gravity ! |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Jul 24, 2020 5:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
As you're setting this on the chlauth do you have a default MCAUSER on the channel that would prevent access, or a chlauth backstop rule for SSLPEERMAP?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| crashdog |
| Posted: Fri Jul 24, 2020 11:47 am Post subject: |
|
|
Voyager
Joined: 02 Apr 2017
Posts: 77
|
Thank you for the hint. But unfortunately just another embarrassing moment... some of the queue managers have chlauth disabled 
I could have checked that one earlier. 
Cheers,
Gerhard
_________________
You win again gravity ! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jul 24, 2020 1:38 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Have I misunderstood? Are you saying that there is currently no channel security in place? That clients and other qmgrs can connect to your channels unrestricted? That you are now trying to secure your channels?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| hughson |
| Posted: Sat Jul 25, 2020 2:29 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
You don't mention creating a backstop rule. Do you have one in place? If not, then the channel will still be able to connect.
If you are retrospectively adding channel security to an existing working setup, you may be interested in the method described in the second half of this blog post:
CHLAUTH - the back-stop rule
Also, on a separate note, you say "the certificates subject must be a complete match to the SSLPEER attribute". Just to be clear, if the SSLPEER attribute in a CHLAUTH rule is say "CN='Morag Hughson'" and nothing else, it matches as if the SSLPEER attribute said "CN='Morag Hughson',O=*,OU=*,L=*,S=*,C=*". i.e. anything omitted from the pattern is assumed to be asterisk.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| crashdog |
| Posted: Sat Jul 25, 2020 7:04 am Post subject: |
|
|
Voyager
Joined: 02 Apr 2017
Posts: 77
|
| Quote: |
| That you are now trying to secure your channels? |
Yes, one of my current tasks is to secure previously unsecured qmgrs. Some companies are a bit behind on that matter... or just look at what happened to Garmin two days ago... they're still down as of now. I wonder if Garmin uses MQ ?
| Quote: |
| you don't mention creating a backstop rule. Do you have one in place? If not, then the channel will still be able to connect. |
Actually some qmgrs already had a back-stop rule in place, but not all. I've added where they where missing.
| Quote: |
| Also, on a separate note, you say "the certificates subject must be a complete match to the SSLPEER attribute". Just to be clear, if the SSLPEER attribute in a CHLAUTH rule is say "CN='Morag Hughson'" and nothing else, it matches as if the SSLPEER attribute said "CN='Morag Hughson',O=*,OU=*,L=*,S=*,C=*". i.e. anything omitted from the pattern is assumed to be asterisk. |
It is configured like in the sample. So the complete subject, not ony "CN=userid" but "CN=myid,L=uat,DC=companydomain,DC=net".
I've tested that and it appears to work. Means now I get an access denied when trying to connect to a "L=test" rule with a "L=uat" certificate.
There's still much to do with those systems. I also have to implement the whole authorization part.
I will come back on the MQEdit subject later August, as I'm off for holidays now. I will make a demo of the tool to the team once I'm back. Then a trail license would be handy. I'll contact you direct when I'm back.
Kind Regards,
Gerhard
_________________
You win again gravity ! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jul 25, 2020 7:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
[quote="crashdog"]
| Quote: |
| ... or just look at what happened to Garmin two days ago... they're still down as of now. I wonder if Garmin uses MQ ? |
What does MQ channel security have to do with extortionware virus attack at Garmin?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| crashdog |
| Posted: Sat Jul 25, 2020 8:31 am Post subject: |
|
|
Voyager
Joined: 02 Apr 2017
Posts: 77
|
Nothing. It was meant more as a general side note as what can happen to companies that have security flaws. I doubt that the Garmin outage came from one email attachment some one should not have opened.
By the way, I think they're rather talking of ransomeware attack then extortionware.
Kind Regards,
Gerhard
_________________
You win again gravity ! |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jul 26, 2020 4:45 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Extortion is the crime.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| tczielke |
| Posted: Sun Jul 26, 2020 6:12 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
