| Author |
Message
|
| HubertKleinmanns |
 Posted: Sun Apr 29, 2012 2:57 am Post subject: New RFE: CHLAUTH, Using DNS instead of IP |
 |
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
|
| Back to top |
|
 |
| rcp_mq |
| Posted: Sun Apr 29, 2012 4:01 pm Post subject: |
|
|
Centurion
Joined: 13 Dec 2011
Posts: 133
|
Won't it require major code change? DNS names can be so disparate. IP addresses follow a pattern. Just putting forward a point.
If IBM implements the feature everything would be as easy as "localhost" |
|
| Back to top |
|
|
| mvic |
| Posted: Sun Apr 29, 2012 4:26 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| rcp_mq wrote: |
| Won't it require major code change? |
Not a reason to avoid mentioning a requirement. It's it's a requirement for you, it's worth raising with your IBM account reps / supporting via developerWorks. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Mon Apr 30, 2012 12:00 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
I worked for customers, who require using DNS names, other customers use IP addresses.
The sense of my RFE is, to have an option, choosing IP or DNS.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| rvicter2 |
| Posted: Mon Apr 30, 2012 5:58 am Post subject: |
|
|
Novice
Joined: 14 Apr 2012
Posts: 17
|
@mvic
You talk just like my boss. He never read the latter(conclusive) part of the message. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Apr 30, 2012 6:30 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| rvicter2 wrote: |
| You talk just like my boss. He never read the latter(conclusive) part of the message. |
I guess I'll take that as a compliment. 
I must be missing something: what is the "latter(conclusive) part of the message" you refer to?
My point was, you will not get a requirement implemented, if you do not actually open the request with the vendor in the first place.
That is engineering, you don't have to be a boss to think that. |
|
| Back to top |
|
|
| rvicter2 |
| Posted: Mon Apr 30, 2012 7:29 am Post subject: |
|
|
Novice
Joined: 14 Apr 2012
Posts: 17
|
(and it was a fact not a compliment)...
latter (and conclusive) part of message was
If IBM implements the feature everything would be as easy as "localhost"
...
I agree with your point completely though.
I have an addendum.
How about some wiz come up with a supportpac with that feature. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Apr 30, 2012 7:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I am reposting some comments from T-Rob through the same message topic in the vienna listserv.
| T.Rob wrote: |
This one is a bit scary from a security perspective. IP filtering is
already the least secure authentication in WMQ. (Technically, it's not
actually authentication at all. It is simply filtering.) Although
CHLAUTH by DNS would certainly provide a considerable degree of
convenience, there's a significant security cost associated with it.
Since TCP is a connection-oriented protocol, an attacker must arrange for
a spoofed TCP connection to not only get to the QMgr, but also for the
replies to get back to the attacker instead of the true owner of that IP
address. This is difficult to do without compromising the routers and/or
launching the attack from the same subnet as the legitimate server. That
difficulty is the reasoning behind the recommendation not to use IP
filtering for interactive users and instead only use it for servers in a
physically secure location.
On the other hand, it is relatively easy to poison DNS (hence all the
discussion about finally formalizing the DNSSEC spec). Suppose for
example ,that you have set a CHLAUTH rule to allow access based on DNS
name. If I add my IP address to the DNS cache along with your legitimate
IP address, then connections between you and the QMgr are not affected.
Your connection will continue to operate just fine. Problem is, so will
mine. And there won't be any disruption to let you know anything has
happened. On the other hand, suppose you have used CHLAUTH DNS rule to
*block* access. An attacker can add entire subnets to the DNS cache and
shut down your WMQ network.
So from a security perspective, this is awfully weak. With WMQ < v7.1 and
no MCAUSER, the attacker had to know a bit about the WMQ API in order to
present a connection request with a blank user ID. CHLAUTH based on DNS
raises the bar just a bit since the attacker now needs to know how to run
Nessus, Metasploit or other DNS cache poisoning tool. That's not much of
an increase in the level of difficulty. My question then is whether the
tradeoff in security is worth the added convenience. For almost no effort
you get almost no security.
My other concern is the run-time implementation of this. Your use cases
dictate that the host-name resolution must occur at connection time rather
than when the rule is run. That means that when a connection request
comes in, the MCA makes a blocking call to the OS to resolve the IP
address back to a host name. Here are a few possible issues:
If your /etc/resolv.conf is wrong then your channel won't start.
If your /etc/nsswitch.conf is wrong then your channel won't start.
If your Name Server(s) is(are) down then your channel won't start.
Factors totally outside your control (such as DHCP not registering the
host name or registering it less frequently than the DNS cache interval)
can prevent your channel from starting.
On a multi-homed server, you must now enter *all* *possible*
*outbound* IP addresses into the DNS (as opposed to just the inbound
ones).
Note that on a few of these, the blocking OS call may hang the channel for
as much as 2 hours (the default TCP timeout) before control is returned
and WMQ can write a diagnostic to AMQERR01.LOG. For that oddball case
where DHCP registers the name and the DNS cache expires before the name is
re-registered, connections that worked would suddenly stop working for no
apparent reason. How does the WMQ admin debug that? I think the answer
is that the network or DNS team end up getting called whenever a channel
won't start or an MCA hangs up. I can definitely see people using host
names in CHLAUTH rules when they are working as expected. I just can't
imagine them continuing to use them after the first attempt at diagnosing
issues.
Finally, consider the best-case scenario where the DNS lookup works as
expected, there's no cache poisoning and response is pretty quick. In
that event, reverse DNS returns a many-to-one result. Should the CHLAUTH
rule fire if the configured host name is the *only* name returned or
simply *among* the list of names returned? Does that answer differ for a
whitelist rule versus a blacklist rule? Would a fully-qualified domain
name be required, or do you envision using the short name?
Here's one that is particularly, interesting: Should WMQ cache the DNS
results so as not to have to perform the RARP lookup on each connect? With
IP-based CHLAUTH rules, the MCA has all the information it needs to
evaluate the rule based simply on the socket signature so it can be lean
and mean. However, if the lookups are cached, we now need to hit the
cache before we execute the RARP lookup - and that means all MCA threads
must now communicate with a QMgr-wide service that caches the lookups,
serialization on those updates, etc. Or else it means each MCA thread
builds its own cache (which has serious implications on scalability). Then
there's all the user-facing tunables to make sure the WMQ internal cache
policies match up to the actual DNS caching policies.
On the surface, this looks like a fairly simple request ("Let me use host
names instead of IP in a CHLAUTH rule") because we tend to think of host
names and IP addresses as equivalent symbols for the same thing. But
there's a Pandora's box of complexity once you drill down a bit. Does
anything above give you second thoughts about this request? I'm not
saying it shouldn't be done. I'm just trying to understand if the
inherent weaknesses in DNS, the difficulty in diagnosing problems and the
implications of what it would mean to the design of the MCA outweigh any
benefit that might obtain. Thoughts? |
|
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Mon Apr 30, 2012 7:59 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| mqjeff wrote: |
I am reposting some comments from T-Rob through the same message topic in the vienna listserv.
...
|
mqjeff,
I've seen the mail from T.Rob - and this was my answer:
| HubertKleinmanns wrote: |
Hi T.Rob,
thanks for the detailed explanation. I know about some of your arguments - some others are new to me. But, in the past I worked for a customer who used BlockIP2 with DNS names. The new CHLAUTH feature somehow works similar to BlockIP2. So it is just a wish to have the same functionality like using BlockIP2.
I know of all the issues using DNS and I know about discussions, using DNS or IP addresses. I also know, that such an implementation is quite complicated, but I hope, the IBM developers are cute enough to realize such a mechanism.
And of course DNS (or using a local "hosts" file) must be implemented properly.
Using DNS should only be an additional option.
Regards
Hubert
|
I did not say, that DNS usage is very simple, but - as you see in BlockIP2 - it is possible
_________________
Regards
Hubert |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Apr 30, 2012 8:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| HubertKleinmanns wrote: |
| I've seen the mail from T.Rob |
I know you've seen it, my concern was for the readers here who are not on the listserv.
Valuable, useful information. |
|
| Back to top |
|
|
| mvic |
| Posted: Mon Apr 30, 2012 8:28 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| rvicter2 wrote: |
| (and it was a fact not a compliment)... |
You appeared to say I did not read the second half of the post. That is not a fact - it was your opinion. But, come to think of it, maybe I do sound like your boss. I'll admit that that might be a fact. But I don't know your boss, so I can't say. 
| Quote: |
latter (and conclusive) part of message was
If IBM implements the feature everything would be as easy as "localhost" |
Thank you. I do not find that conclusive; it does not have anything to do with the first point, which was "Won't it require major code change?".
I was responding specifically to the first point, which was not (in my opinion) modified or clarified by the part you mention. Responding to one point in a post, but not another unrelated point, is common to see on forums / bulletin boards. |
|
| Back to top |
|
|
| rvicter2 |
| Posted: Mon Apr 30, 2012 6:17 pm Post subject: |
|
|
Novice
Joined: 14 Apr 2012
Posts: 17
|
| ...got it boss! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 30, 2012 6:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I read Jeff's post of TRob's info. I personally believe that all outside connections (outside of the firewall) should be SSL and SSL Peer secured.
So the DNS attack to be effective would have to happen inside your firewall. I hope your internal DNS servers are isolated from the general internet... If that type of attack happens behind the firewall, I dare say you have a whole slew of other problems...
Like the OP I don't mean to have the DNS replace the IP authentication, I just mean for the admin to be able to choose, when doing it inside the network (behind the firewall). It is something you want to consider as an admin if you use Nat (ip v4) and the natted value of the IP is not widely known. But the host name will resolve across the networks. (Mandatory when dealing with clusters and natting if you do not want to multiply your cluster receivers).
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Apr 30, 2012 11:30 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Of course DNS should be supported. It's only an additional call to resolve the name to IP number and then the code is the same.
Totally agree with requirement. After all we are writing this in readable English not in hex representation for much the same reasons.
It was something that I mentioned during the ESP (Beta) programme so they may already have it on the to-do list. But a RFE is good.
Of course it needs to be DNS names as well as IP addresses. Choice (and/or a mixture) should be possible. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Tue May 01, 2012 9:44 pm Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
mqjeff,
| mqjeff wrote: |
| HubertKleinmanns wrote: |
| I've seen the mail from T.Rob |
I know you've seen it, my concern was for the readers here who are not on the listserv.
Valuable, useful information. |
I know that you know that I've seen T.Robs mail .
My intent was only, to deliver my answer on the listserv - as a part of the discussion - to this forum too.
As you can see in the posts before there are lots of pro's and con's, so my suggestion ist:
Vote for the RFE for using DNS or not.
And let IBM consider if it is possible or not, easy or complicated or whatever . And then IBM should decide, whether DNS - as an additional option - will be implemented or not.
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
, if you are also interested in this feature.
