all groups > iis security > june 2005 >
You're in the

iis security

group:

Ideas on deferring authentication?



Ideas on deferring authentication? rgutter NO[at]SPAM bctf.ca
6/21/2005 2:01:43 PM
iis security: We currently have a public IIS6 server in our DMZ. It's been made a
domain member to allow Basic Authentication against our AD for a
number of confidential documents - all within a single web - on the
server. (We don't want to maintain a separate user database.)

I can make this marginally more secure by moving the confidential
documents to an internal host and using UNC Passthrough authentication,
but I'd rather find a way to turn the public web server into a
standalone server. Is it sensible to think of moving the confidential
documents to an internal web server and performing authentication
there? I'm now allowing http into my protected network of course...
Re: Ideas on deferring authentication? David Wang [Msft]
6/22/2005 7:02:04 PM
Maybe I am mis-understanding how your configuration is set up. If so, please
do feel to elaborate details as appropriate.

I presume only certain users that Basic authenticate against your AD is able
to access the confidential documents.

In that case, why don't you just ACL the confidential documents to just
those users? This prevents anonymous or anyone else within the DMZ (without
sufficient privileges, of course) from reading the confidential documents.

WHERE you store them seems quite irrelevant from a security perspective.
ACLs will be enforced by Windows, whether it's the server in the DMZ or by
the internal host. Especially since you are going to poke a hole in the DMZ
to allow the web server to access this internal host anyways -- the internal
host might as well be in the DMZ as far as access is concerned, and I see no
security improvement between one or two machines in the same DMZ).

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
[quoted text, click to view]
We currently have a public IIS6 server in our DMZ. It's been made a
domain member to allow Basic Authentication against our AD for a
number of confidential documents - all within a single web - on the
server. (We don't want to maintain a separate user database.)

I can make this marginally more secure by moving the confidential
documents to an internal host and using UNC Passthrough authentication,
but I'd rather find a way to turn the public web server into a
standalone server. Is it sensible to think of moving the confidential
documents to an internal web server and performing authentication
there? I'm now allowing http into my protected network of course...

Re: Ideas on deferring authentication? rgutter NO[at]SPAM bctf.ca
6/23/2005 5:31:25 PM
Putting confidential data on the inside serves two purposes: one, since
a host on the DMZ is more likely to be compromised than one on the
internal network, it better protects the documents themselves; two, it
means that the domain itself can be contained within the internal
network, protecting against attempts to retrieve domain-based
information.

But since I have to give some external users (with domain accounts)
access to that data, I do have to drill a hole in the firewall. So the
question is whether the change above is worthwhile or wrong-headed.
Re: Ideas on deferring authentication? David Wang [Msft]
6/24/2005 6:38:51 PM
I do not think moving confidential documents into the internal network and
then drilling a hole through the firewall offers any additional protection
in your setup.

If the DMZ host is compromised, then the attacker can assume any identity
from that host, including the very identity that can pass through the hole
you drilled into your internal network. So, your document is not any better
"protected". Physical networking does not offer protection if you drill a
hole through it.

Furthermore, since you use Basic authentication, the user identity is
intrinsically delegated, so Windows cannot offer any protection to prevent
identity from a compromised server from hopping off the box onto your
network.

And since you drill a hole through the firewall, your internal network is
essentially exposed to the DMZ.

So, I simply do not see how moving documents into the internal network and
using pass-through UNC authentication to access the data helps to secure
that document nor remove information leakage. To me, opening that hole to
the internal network opens you up for information leakage and does not help
security one bit.


To me, you want to use built-in Windows technology like Kerberos,
constrained delegation, and NT ACLs to secure your resources such that even
by drilling a hole in the firewall, you can appropriately constrain the
identities and servers that one can access through the hole. I realize basic
and custom authentication are easier to implement and customize, but you
need to realize their weaknesses, assess your risk potential, and then
decide on an implementation.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
[quoted text, click to view]
Putting confidential data on the inside serves two purposes: one, since
a host on the DMZ is more likely to be compromised than one on the
internal network, it better protects the documents themselves; two, it
means that the domain itself can be contained within the internal
network, protecting against attempts to retrieve domain-based
information.

But since I have to give some external users (with domain accounts)
access to that data, I do have to drill a hole in the firewall. So the
question is whether the change above is worthwhile or wrong-headed.

AddThis Social Bookmark Button