| Author |
Message
|
| vishBroker |
 Posted: Tue Feb 26, 2013 11:37 am Post subject: Client IPs connecting to Channel |
 |
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
Requirement - get the list of all the client IPs, who connected to QM
Backgroud - Review the IP whitelist which we have for channel security Exit and remove the IPs from whitelist, which is NO more connecting to MQ QM.
MQ version - 7.0.1.6
OS- AIX version 6
Now, as evident, we have channel security exit as IP whitelist.
A .log file is also generated which shows - which 'unauthorized' IPs tried to access and were denied access.
Now, I have a script which does 'chstatus' and lists unique IPs which are connected to the channel.
So far so good.
But the issue is the script gives me snapshot of client connections at that time. As of now, I am runnign the script with sleep interval of 60 seconds.
I can dump the unique IPs from 1st run in a file and keep on adding IPs to it, if I found an IP which is NOT present in the file.
But as it is snapshot at given time, I MAY miss some connections which happened between two runs.
I can decrease it to say 30 sec. but this just reduces the probability not the possibility.
Also running this script ( capture the IPs-> find unique IPs from them-> check the file for each IP and add it if does not exist) looks more overhead. Add to that the performance hit, it may cause on PROD box - if I run it every 30 seconds.
So, I would like to know, is there any better way to find which all IPs connected to QM over a day. |
|
| Back to top |
|
 |
| vishBroker |
| Posted: Tue Feb 26, 2013 11:49 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
To add clarification
This is how I capture the client IPs
cat QMRUNMQSC.out DPCHSTATUS.out END.OUT | runmqadm | grep 'CONNAME' > DPIPOut.out
cat DPIPOut.out | sort -u | cut -f 2 -d '(' | cut -f 1 -d ')' > DPUniqueIPs.out
where 'QMRUNMQSC.out' => runmqsc QM
DPCHSTATUS.out => display chstatus(%channelName%)
and END.OUT => end
I mean to say - I am NOT grepping 'RUNNING' in channel status display.
So I guess, I am capturing STALE connections ( which are NOT closed) as well along with LIVE connections. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 26, 2013 12:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Surely the IP whitelist should be a list (or range) of addresses who are permitted to use the connection, the contents of which are generated not from the IPs who actually use the connection but those who you've determined are allowed to because they have a legitimate need? Even if they don't have a legitimate need every day?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vishBroker |
| Posted: Tue Feb 26, 2013 12:16 pm Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
 .
Yes. But, the requirement is review the IPs that we have whitelisted and remove the IP from the whitelist, if it is NOT being used anymore.
I know the IPs which are connecting, are from the whitelist only.
Audit team needs us to review it periodically and keep the list updated. So we need to identify and remove the IPs from the list, which are talking to MQ ( say - the server is decommissioned or IP is changed) |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 26, 2013 12:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vishBroker wrote: |
| So we need to identify and remove the IPs from the list, which are talking to MQ ( say - the server is decommissioned or IP is changed) |
That's my point - it's backwards. The whitelist should be driven from what servers are allowed to use the queue manager, not what are actually using the queue manager. Your method assumes that any authorized server is constantly in use, and is still used for the purpose for which it was added to the whitelist. You don't know from your method if the server has been repurposed or retasked.
The correct way to do this is to take the current whitelist, contact the owners of those servers & have them verify they still use the server for valid reasons which require access to WMQ. If they can't you remove them.
Aside from the problem you posted, your method doesn't cater for the application which only connects to WMQ at month end. If you run your audit trawl for 3 weeks in the middle of the month you'll miss it.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vishBroker |
| Posted: Tue Feb 26, 2013 12:43 pm Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
I wish, my manager would have understood(rather agreed) this.
Again FYI - We do have process in place - to add IP to whitelist and we do checks with corresponding parites.
as you might guess, We have some subnets in the whitelist as well.
(and from manager's shoe) - it seems we were not able to find owners of some IPs/sunnets and hence the OTHER WAY ROUND method. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 26, 2013 12:52 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vishBroker wrote: |
| (and from manager's shoe) - it seems we were not able to find owners of some IPs/sunnets and hence the OTHER WAY ROUND method. |
So if you can't find any owners what does that tell you about the validity of their position on the whitelist?
Let's assume that one of these subnets you can't find the owner of turns up as still in use (it appears in your scanning thing). As I understand it, you will consider this valid and leave them on the whitelist as still in use. A year later, it turns out that the users of that subnet have no right to use WMQ (or more likely no right / legal authority to use the functions thus exposed even if they think they do). What will be your manager's response?
You might want to ask him that so he's got some time to prepare his response to the relevant internal or external enforcement authoritites.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vishBroker |
| Posted: Tue Feb 26, 2013 1:18 pm Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
Thanks for the inputs. Just to be clear - I am not denying what you are saying.
We can discuss the best practice at length - But the requirement is to get list of IPs which accessed MQ over a time period and how to do it from MQ side.
Is there any tool.
And I am thinking(about script), there is none ( or atleast not a 'recommendable' way of doing it).
And for tool, Will check if Tivoli can monitor that easily. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 26, 2013 1:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vishBroker wrote: |
| Thanks for the inputs. Just to be clear - I am not denying what you are saying. |
Didn't think you were; I'm trying to provide you with lines of attack through which you can challenge your manager over this flawed practice.
| vishBroker wrote: |
| But the requirement is to get list of IPs which accessed MQ over a time period and how to do it from MQ side. |
And this requirement is flawed, as I've outlined above. Again, I understand it's not your requirement.
| vishBroker wrote: |
| Is there any tool. |
No. Because no tool can meet a flawed requirement. You can't monitor what doesn't happen, even assuming that usage equals permission to use (which it doesn't).
| vishBroker wrote: |
| And I am thinking(about script), there is none ( or atleast not a 'recommendable' way of doing it). |
No. See above.
| vishBroker wrote: |
| And for tool, Will check if Tivoli can monitor that easily. |
No. And again, even if it could, all it's telling you is that a current member of the whitelist is accessing the queue manager. It doesn't tell you if that member should still be accessing the queue manager, nor does it tell you that a valid member of the whitelist isn't currently accessing the queue manager.
It's not a question of best practice, it's a question of this method not telling you what you need to know. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Feb 26, 2013 4:25 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I agree with everything Vitor said. Except there is a tool. Its not free, but it can do exactly what you want, among a lot of other things. Search for a product called MQAUSX from Capitalware. I have a nice log of every connection made (or attempted but rejected - suckers) to my Queue Managers.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 27, 2013 6:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| I agree with everything Vitor said. |
Thank you.
| PeterPotkay wrote: |
| Except there is a tool. Its not free, but it can do exactly what you want, among a lot of other things. Search for a product called MQAUSX from Capitalware. |
In my own defence, that's not a tool for doing what the OP wants. That's a tool for doing a better job of being a security exit and running a whitelist.
| PeterPotkay wrote: |
| I have a nice log of every connection made (or attempted but rejected - suckers) to my Queue Managers. |
I agree that MQAUSX is a full featured product. I have concerns that a manager dim enough to believe in this audit methodology will believe that the solution is to spend money buying a tool that does what he wants.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vishBroker |
| Posted: Wed Feb 27, 2013 7:37 am Post subject: |
|
|
Centurion
Joined: 08 Dec 2010
Posts: 135
|
| Vitor wrote: |
| vishBroker wrote: |
Thanks for the inputs. Just to be clear - I am not denying what you are saying.
|
Didn't think you were; |
Well, you are right here. I was just trying to be nice - as every newcomer would be.
Manager requirement or Not, there should be a way to log each new IP address, which is making MQ connection(->channel security exit). This kind of information will give statistical data including
1. Which of the client makes most of the connections
2. What is the peak time
This info can be checked against IP whitelist and more conclusions MIGHT be drawn e.g.
1. so and so client makes more conenctions, lets have separate dedicated channel for this.
2.Group the channel according to the usage so that there is NO high traffic at the same time.
Well, candidly,I am thankful to the forum and you guys(experts) as I learn lot many things here. And most of guys(atleast learners) will have same sentiments. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 27, 2013 8:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| channel events should provide most of this. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Feb 27, 2013 9:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vishBroker wrote: |
This info can be checked against IP whitelist and more conclusions MIGHT be drawn e.g.
1. so and so client makes more conenctions, lets have separate dedicated channel for this.
2.Group the channel according to the usage so that there is NO high traffic at the same time. |
Which is all well and good for the purposes you correctly list, but doesn't go one step towards validating the contents of the whitelist
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
