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

Re: [dist-obj] Extranet security

Your solution seems overly complicated.  If you're going to protect the
link with SSL anyway, what's the objection to running the connection
over the Internet?  It's relatively straightforward to harden the server
against any non-SSL access, at both the firewall and host level.  I
think it's less likely that an attacker could breach such a hardened
host than you're other solution opening up some subtle vulnerability. 
What if I attack the DNS connection from party2 clients or the DNS
server at party1.

If this doesn't work, why involve DNS at all.  Provide a link from a
trusted internal server on the party2 network using an IP address in the
URL instead of a domain name (though you then have to worry about the DN
in the server certificate if you're using SSL).

Kevin


Peter van Eijk wrote:
> 
> 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 client could be
> a web browser, and the server a web server, but the principles also
> apply to other connections. Suppose that organisations are connected to
> the Internet but that it is not desirable to use the Internet for the
> connection between client and server.
> Let's assume that:
> - the server is called server.extranet.party1.com and the client resides
> in the party2.com network,
> - party1 and party2 have a private data link, as well as an Internet
> link.
> - the server has a public range IP address (as per RFC1918)
> 
> Traffic would be routed between parties over the private line on the
> basis of IP adresses. In particular, the server's IP address need not be
> routable from the Internet. The server (and client for that matter) is
> then protected from intrusion attempts originating outside of the
> networks of the parties. In other words: the server is at least as safe
> as the internal network. (Additionally, the servers are typically also
> protected by authenticated login and SSL).
> 
> The question now remains how domain names are resolved and how secure
> this is. It appears to be a principle of sound IP engineering to have
> server.extranet.party1.com resolved by one of the domain servers from
> party1, resulting in an IP adress out of an allocation to party1. If
> this is done on the public (Internet) side, the IP adress of the
> extranet server will be visible to the Internet. If this is done on the
> private (extranet) side, it will require tweaking of DNS resolvers, on a
> per-party basis.
> 
> It appears that the security risks of showing some server names on the
> outside are minimal, if the resulting IP adresses are not routable. The
> usefulness of security through obscurity has been rejected quite a while
> ago by most experts. Additionally, some domain servers might allow access
> control lists
> so that the address query for server.extranet.party1.com will only be
> resolved to named parties.
> 
> At any rate, from a risk management situation complicated network setups
> probably introduce more security risks than they resolve.
> 
> My current questions are: what are the real risks? and how would a
> security auditor judge a setup as outlined above?
> 
> Would there be any interest in a more detailed set of guidelines (or faq)
> here?
> 
> Peter van Eijk, Deloitte & Touche Bakkenist, Network Strategy &
> Architecture, tel: +31 6 53515927, www.van-eyk.net/pve, pmaill@van-eyk.net
> 
> ==========================================================================
> To manage your subscription, mailto:dist-obj-help@distributedcoalition.org
> Archives, FAQ, etc.     http://www.distributedcoalition.org/mailing_lists/

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