| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| BlockIP intermittently refusing connections |
« View previous topic :: View next topic » |
| Author |
Message
|
| alexf400 |
 Posted: Wed Nov 05, 2014 12:55 am Post subject: BlockIP intermittently refusing connections |
 |
|
Newbie
Joined: 10 Apr 2014
Posts: 8
|
Hi
We implemented a BlockIP2 whitelist on a test server a few weeks back and every few days we see this happen.
2014-11-04|11:40:23|1074551104|Connection accepted, Channel [SYSTEM.DEF.SVRCONN] ConName [10.85.28.36] Flags [BlockMqmUsers=Y AllowBlankUserID=Y ] User []
2014-11-04|11:40:23|1088194880|Connection accepted, Channel [SYSTEM.DEF.SVRCONN] ConName [10.85.28.36] Flags [BlockMqmUsers=Y AllowBlankUserID=Y ] User []
2014-11-04|11:40:23|1074817344|Connection accepted, Channel [SYSTEM.DEF.SVRCONN] ConName [10.85.28.36] Flags [BlockMqmUsers=Y AllowBlankUserID=Y ] User []
2014-11-04|11:40:23|1102448960|Connection accepted, Channel [SYSTEM.DEF.SVRCONN] ConName [10.85.28.36] Flags [BlockMqmUsers=Y AllowBlankUserID=Y ] User []
2014-11-04|11:40:23|1100593472|Channel closed [SYSTEM.DEF.SVRCONN] Connection Name [10.85.28.36]
2014-11-04|11:40:23|1103898944|Channel closed [SYSTEM.DEF.SVRCONN] Connection Name [10.85.28.36]
2014-11-04|11:40:23|1107142976|Connection refused, Channel [SYSTEM.DEF.SVRCONN] ConName [10.85.28.36] User [] was not accepted in CON=
2014-11-04|11:40:23|1107142976|Channel closed [SYSTEM.DEF.SVRCONN] Connection Name [10.85.28.36]
2014-11-04|11:40:38|1106020672|Connection accepted, Channel [SYSTEM.DEF.SVRCONN] ConName [10.85.28.36] Flags [BlockMqmUsers=Y AllowBlankUserID=Y ] User []
2014-11-04|11:40:38|1106753856|Connection accepted, Channel [SYSTEM.DEF.SVRCONN] ConName [10.85.28.36] Flags [BlockMqmUsers=Y AllowBlankUserID=Y ] User []
2014-11-04|11:40:38|1105328448|Connection accepted, Channel [SYSTEM.DEF.SVRCONN] ConName [10.85.28.36] Flags [BlockMqmUsers=Y AllowBlankUserID=Y ] User []
The MaxChannels parameter in qm.ini is fine, it is set to 2000, there are only 600-800.
There is no explicit MAXCHL set in BlockIP for SYSTEM.DEF.SVRCONN.
I thought it may be MAXHANDLES qmgr setting but I have seen over 300 connections coming from this host, so it would seem unlikely that the 256 setting is causing this.
Any help much appreciated
Thanks
Alex |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Nov 05, 2014 1:16 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
1. Test or not, don't use SYSTEM.DEF.SVRCONN, use a channel created for the testing purpose - these things have a contact admin habit of being promoted into the upper environments;
2. What's the MAXINST and MAXINSTC settings on the SVRCONN?
3. If your IBM MQ version has CHLAUTH capability, why use BlockIP2?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 05, 2014 1:23 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
CHLAUTH doesn't do all of the things BlockIP2 can do - or does them less flexibly.
Trouble is that IBM tend to decide that something is not totally secure and refuse to implement it, whereas it should be at the discretion of the customer to use such a feature or not in that way. Eventually they relent under pressure (such as the DNS name resolution feature).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Nov 05, 2014 1:39 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| zpat wrote: |
CHLAUTH doesn't do all of the things BlockIP2 can do - or does them less flexibly.
Trouble is that IBM tend to decide that something is not totally secure and refuse to implement it, whereas it should be at the discretion of the customer to use such a feature or not in that way. Eventually they relent under pressure (such as the DNS name resolution feature). |
And it can be a pig to maintain the BlockIp2 ini files across a large estate when there is a personnel churn dynamic within an organisation, whereas it's easier to roll out CHLAUTH definitions across the estate - depends on what is more valid for the organisation within which we work.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| alexf400 |
| Posted: Wed Nov 05, 2014 2:10 am Post subject: |
|
|
Newbie
Joined: 10 Apr 2014
Posts: 8
|
Thanks for the reply
| Quote: |
| 1. Test or not, don't use SYSTEM.DEF.SVRCONN, use a channel created for the testing purpose - these things have a contact admin habit of being promoted into the upper environments; |
Absolutely, I've been telling anybody who will listen this for over a year now. Unfortunately there is a load of legacy code and old clients knocking about. I would close down SYSTEM.DEF.SVRCONN tomorrow, and have been stopped from doing it by senior management.
| Quote: |
| 2. What's the MAXINST and MAXINSTC settings on the SVRCONN? |
MAXINST(999999999) MAXINSTC(999999999)
3. If your IBM MQ version has CHLAUTH capability, why use BlockIP2?
Stopped from doing it by Senior Management, they wanted to go with what was tried and trusted on the site and not be on the "bleeding edge". |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Nov 05, 2014 2:20 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| alexf400 wrote: |
Thanks for the reply
| Quote: |
| 1. Test or not, don't use SYSTEM.DEF.SVRCONN, use a channel created for the testing purpose - these things have a contact admin habit of being promoted into the upper environments; |
Absolutely, I've been telling anybody who will listen this for over a year now. Unfortunately there is a load of legacy code and old clients knocking about. I would close down SYSTEM.DEF.SVRCONN tomorrow, and have been stopped from doing it by senior management.
| Quote: |
| 2. What's the MAXINST and MAXINSTC settings on the SVRCONN? |
MAXINST(999999999) MAXINSTC(999999999)
3. If your IBM MQ version has CHLAUTH capability, why use BlockIP2?
Stopped from doing it by Senior Management, they wanted to go with what was tried and trusted on the site and not be on the "bleeding edge". |
I feel your pain...
...no idea why BlockIp2 is doing what it's doing intermittently by the way - you could try tracing it I suppose, and may be lucky to trap it when it happens.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Nov 05, 2014 2:34 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| exerk wrote: |
And it can be a pig to maintain the BlockIp2 ini files across a large estate when there is a personnel churn dynamic within an organisation, whereas it's easier to roll out CHLAUTH definitions across the estate - depends on what is more valid for the organisation within which we work. |
If your CHLAUTH rules or BlockIP2 rules require changing for each person who comes or leaves - you have my sympathy and you should re-design your security rules to avoid such.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| 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
|
|
|
|
