[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [dist-obj] Extranet security

Per my original post, having a public DNS server is something of a
security risk.  DNS does not provide authentication or message
integrity.  Therefore, an attacker can either hijack the DNS connection
or simply replace the returned IP address in flight.  The purpose of
course would be to direct clients to a hostile server.  Now, if you use
SSL for the Web connection, the browser will compare the name in the
server certificate to the domain name in the https URL, helping blunt
this attack.  But the argument that this is "good enough" is precisely
the same argument I would make that going over the Internet using SSL is
"good enough".  If going over the Internet is really a _security_ risk,
then a public DNS server has similar risk, using the end-to-end
argument.

So it seems that your political and systems management requirements are
at odds with the highest levels of security.  This is a very typical
state of affairs.  As long as everyone is made aware of the tradeoff,
you've done your job.

Kevin


> "van Eijk, Peter (NL - Diemen)" wrote:
> 
> Thanks for your comments.
> I'l give you a little more background info.
> 
> We are talking about 5 to 8 organisations, each with 2000 to 10.000
> client stations, all behind firewall.
> Using the Internet for links between organisations is politically
> unacceptable.
> DNS is a must because of the network management issues. Nobody wants
> to
> have hardcoded IP adresses in their clients and servers, and
> especially
> not if they are somebody else's IP adresses.
> You might isolate things into a proxy, but the proxy may well have to
> interface to a number of these extranets, that only overlap a little.
> It'll be a complicated proxy setting, if you ever get it debugged.
> 
> The principle that seems to be relevant here is that it is to be
> avoided
> very much that a configuration change involves coordinated action
> between two (let alone more) parties. Case in point: on some link
> between these organisations illegal IP adresses are being used that
> are
> a historic legacy. Both organisations have manually edited router
> tables, and one of them actually needs a NAT box for this address
> range.
> Yet, they find it too complicated to coordinate the change.
> 
> Actually, my question was more limited: what about the risk of a
> public
> DNS domain server that discloses an internal IP address (which is not
> routable from the Internet)?
> 
> Who has ran into similar situations?
> >
> > Hi
> > This forum may or may not be the place to ask this question,
> > but it appears
> > to me that you might be in a position to point me to
> > additional resources.
> > My question is outlined below.
> >
> > In extranet situations it is desirable to access servers from one
> > organisation with clients from another organisation. The
> []
> >
> > My current questions are: what are the real risks? and how would a
> > security auditor judge a setup as outlined above?
> >
> 
> This e-mail message and its attachments are subject to the disclaimer
> published at the following website of Deloitte & Touche :
> http://www.deloitte.nl/index.asp?Pageid=010109135051734

==========================================================================
To manage your subscription, mailto:dist-obj-help@distributedcoalition.org 
Archives, FAQ, etc.     http://www.distributedcoalition.org/mailing_lists/