|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Ideas on deferring authentication?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... 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. // <rgut***@bctf.ca> wrote in message news:1119387703.351226.62690@z14g2000cwz.googlegroups.com... We currently have a public IIS6 server in our DMZ. It's been made adomain 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... 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. 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. // <rgut***@bctf.ca> wrote in message news:1119573085.795811.271720@g43g2000cwa.googlegroups.com... Putting confidential data on the inside serves two purposes: one, sincea 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. |
|||||||||||||||||||||||