Well stated, Al. To re-emphasize a general principle you appear to be making: If one is not going to choose the most secure path possible, then at least try to keep it simple. Adding complexity without increasing security (as in options 2 or 3), is more of a drawback for those who have to maintain the environment.
-ASB FAST, CHEAP, SECURE: Pick Any TWO http://www.ultratech-llc.com/KB/ On 9/8/05, Al Mulnick <[EMAIL PROTECTED]> wrote: > Option #1 > Procure and deploy ISA as an application publishing device. Note: > investigate the appliance versions - Way cool. > Pros: recommended method for publishing trusted network resources to > non-trusted or semi-trusted networks; only requires one easily monitored > network port to allow communications (TCP 80); can bridge SSL conversations > for additional protection options; etc > Cons: additional hardware/software to deploy and support > > Option #2 > Procure and deploy a second Sharepoint server in the DMZ. Allow two-way > communication between DMZ host to domain controllers, DNS, and SQL as if it > were a trusted resource. > Pros: easily done with current software and hardware expertise > Cons: Solution provides high risk of being hacked; Solution provides high > impact if hacked because the hacker has full run of the trusted servers from > the semi-trusted servers. DMZ servers tend to not be watched as well as > trusted hosts. Complex solution that requires a lot of moving parts causing > higher impact to problem resolution should the need arise. Also impacts > upgrade process should it be needed. In the final analysis, this would also > likely not be in line with the company security policy. If it is in line > with it, you may want to fish around for a new CSO as there may soon be a > vacancy :) > > Option #3 > Procure and deploy a second SP server in the dmz and connect it back via > IPSec tunnel to trusted network. > Pros: easier to set up with fewer network ports to allow > Cons: See Option #2 cons. Add to that the inability to monitor any of the > conversation between the DMZ sp host and the trusted network hosts thereby > allowing an attacker the ability to freely move around the network without > being detected by IDSes. The list goes on... > > Option #4 > Allow external semi-trusted traffic to penetrate the hard candy shell of your > network to access SP resources on the trusted network via SSL or TCP80 > traffic. > Pros: easily allowed without any further modification to internal systems; > increased reliability due to simplicity could be realized. > Cons: See cons for #3, #2 and add: The potential impact of a breach would be > severly critical because in addition to the specified trusted hosts that > solution #2 would allow, the attacker would have unrestricted (even trusted) > access to any system left out on your trusted network without having to hack > another machine to do so. (Keep in mind that an attacker could gain control > of the DMZ host, then the DC, then have the same access, but we're talking > about risk management; security is never perfect.) > > > > If you can't persuade them to go with option #1, then perhaps it would make > more sense for them to go ahead and just go with option #4 as it would at > least be more reliable. > > My $0.04 anyway. I'm sure there's something that can be added/modified but > this would be my first pass (rather, it has been a first pass in the past for > other applications :) > > Keep in mind that it all comes back to your seucurity policy and I highly > encourage you to find out what that is and how this fits vs. listening to the > network administrator. Unless that's the same person in which case you may > want to just go with whatever is easier to support for you in the long run > (just kidding). > > Al > > > > > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of Jason B > Sent: Thu 9/8/2005 4:37 PM > To: [email protected] > Subject: Re: [ActiveDir] Which ports to open in the DMZ to communicate with > AD & SQL... > > > > This has been a GREAT discussion and I have received a lot of useful info. > I really appreciate the replies, suggestions, slams and help. I think I am > going to revisit trying to have the sharepoint server moved to the LAN and > see if I can't convince the powers that be to apportion an ISA license and > hardware appropriate for running ISA to put on the DMZ. We already have a > sharepoint server on the LAN... I am not too familiar with sharepoint, but > I wonder if the existing sharepoint server can handle both the internal and > external users... That's a question for another group, I guess. > > Anyway, I gathered quite a bit from the posts and discussion, but what are > the main specific and concrete points that I am going to want to bring up to > dissuade them from having the sharepoint server on the DMZ? My expertiese > isn't in the hardware/networking aspect of configuration, but I know enough > that I am not comfortable opening all the ports for AD auth from the DMZ to > the LAN. Our network admin didn't think that it was a big deal to open the > ports since it was "only on the DMZ" and he could control the traffic that > was allowed to the DMZ. > > > ----- Original Message ----- > From: "Al Mulnick" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Wednesday, September 07, 2005 5:04 PM > Subject: RE: [ActiveDir] Which ports to open in the DMZ to communicate with > AD & SQL... > > > Looks like we have plenty of ideas and opinions ;) > > ISA is a great way to deal with this, but I believe the decision was made to > put the SP machine in the DMZ regardless of the technical merit or > viability. And whether or not it is a good idea. That said, ISA doesn't > offer much if you put it AND this machine in a semi-trusted network (for > whatever that means these days.) > > Shame there's no leeway though. The downside to using IPSec is that as > others have pointed out, it won't work on member server <->DC for W2K > servers (limitation of the OS) but will for 2K3 member servers but that > still leaves you with a secure channel from the DMZ host to your internal > network. That means you can't monitor the traffic from the DMZ to your > internal network because it's encrypted (sounds like a broken record, I > know.) > > Too bad you can't sway the decision makers to do this differently. But > hopefully you've received a lot of ideas to pick from. > > Best of luck, > Al > > > > ________________________________ > > From: [EMAIL PROTECTED] on behalf of Bernard, Aric > Sent: Wed 9/7/2005 7:40 PM > To: [email protected] > Subject: RE: [ActiveDir] Which ports to open in the DMZ to communicate with > AD & SQL... > > > > I agree with Phil - I think using an ISA (or other reverse proxy solution) > is the best way to go given your constraints. > > > > Using a reverse proxy solution allows you the following: > > 1. Keep you Sharepoint server behind the firewall, yet make it accessible to > external clients as if it was in the DMZ. > 2. Restrict your [additional] holes through the firewall to only that needed > by the reverse proxy solution to interact with the Sharepoint server (port > 80). > > > > BTW - this scenario is becoming extremely common. The next common addition > you will see to this will likely be the use of ADFS to provide an identity > trust bridge between the internal forest and a partner forest (or other > identity system). > > > > Regards, > > > > Aric Bernard > > > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Phil Renouf > Sent: Wednesday, September 07, 2005 9:20 AM > To: [email protected] > Subject: Re: [ActiveDir] Which ports to open in the DMZ to communicate with > AD & SQL... > > > > I would look at putting the Sharepoint server on the internal network and > deploy an ISA server in the DMZ and use Web Publishing or Server Publishing > to get your external clients access to the site. If you want to open access > from the DMZ to your AD Forest your firewall will be swiss cheese from all > the ports than need to be open. > > > > If you absolutely HAVE to then I would prefer to look at using IPSec for > communication between the Sharepoint box and your DC's. That leaves you only > needing the IPSec port open and not the very large number of ports to > support AD communication. > > > > http://support.microsoft.com/kb/q179442/ > > > Phil > > > On 9/7/05, Jason B <[EMAIL PROTECTED]> wrote: > > Because this will be a sharepoint server for clients. Regardless, that > decision has already been made and I don't have any input into it. > Any info on the ports I'd need open? > > ----- Original Message ----- > From: "ASB" <[EMAIL PROTECTED]> > To: < [email protected] <mailto:[email protected]> > > Sent: Wednesday, September 07, 2005 8:45 AM > Subject: Re: [ActiveDir] Which ports to open in the DMZ to communicate with > AD & SQL... > > > Why did you decide to put it in the DMZ? > > -ASB > > On 9/7/05, Jason B <[EMAIL PROTECTED]> wrote: > > We are putting a MS sharepoint server in the DMZ and need to have it on > > the > > domain and communicating with a SQL server on the domain. Because of > > these > > needs, we only want to open the minimum number of ports to get > > functionality. We have LDAP (389) opened and SQL (1433) opened. What > > other > > ports will we need to open to be able to log in on the sharepoint server > > with a domain account? Currently, with only these two ports opened, a > > domain account can't log on to the sharepoint server in the DMZ. List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
