|
I say tomato… Is there really such a
thing as a trusted network? We should all probably be thinking no since
such a large number of malicious attacks come from within. Regardless, the more layers you have in
place the harder it is – err- should be to penetrate the internal
network. Your point is well taken, yet there is a
trade off between security, cost, and usability. The balance is different
for each organization. In Jason’s case it sounds like he
has got enough work ahead of him just getting funding for an ISA server let
alone a secondary or tertiary DMZ/semi-trusted network/extranet/callitwhatyouwill
layered network. Aric From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Roger Seielstad Again to clarify, the ISA server often
(but not always) resides in the semi-trusted network while the SharePoint
server should always reside on a fully-trusted network. Actually - you really should look at that
differently. It should read: ISA server should reside in the
semi-trusted network while the SharePoint server should reside on a more
trusted network. Many people seem to think they should
only have 3 classes of networks - Untrusted (i.e. the big I), Semi-trusted
(DMZ) and fully trusted (internal). I think its fairly trivial and
significantly safer to layer services like this, mail relays, and other servers
which make outbound calls to the 'Net into what I would describe as an internal
DMZ. Yes, its more trusted, but you can still ACL off and obscure the internal
workings of your network. -------- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernard, Aric I should make sure I was clear – in
no way did I encourage the placement of ISA AND the SharePoint server onto the
semi-trusted (DMZ) network. Again to clarify, the ISA server often (but not
always) resides in the semi-trusted network while the SharePoint server should
always reside on a fully-trusted network. The key benefit here is that the
only required configuration through the firewall to the internal network is the
web ports (i.e. 80, 443) necessary to allow proper communication between the
ISA server and the SharePoint server. If the ISA server were compromised,
however unlikely, the only path through the firewall to the internal network
would be via the web ports to the SharePoint server. Another problem with the IPSec solution is
that if your SharePoint server in the DMZ is compromised (it is running IIS ;-)
the IPSec path it has through to the internal network will be compromised as
well. Of course this will then allow a potential hacker to ride the IPSec
tunnel straight to all of the systems/ports (i.e. 88, 123, 389, 3268, 3269, and
[god forbid] 135 and 445) you have configured the SharePoint server to
communicate with on the internal LAN. BTW I think you can configure IPSec
to work between clients/member servers and DCs so long as the correct
exceptions are in place or as long as you use certificates (which would be the
best approach if using it in the DMZ). BTW, Jason, never say never. With
enough good arguments and still meeting the stated requirements you can
certainly change people’s opinions…
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick 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 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:
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 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 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. Phil On 9/7/05, Jason B
<[EMAIL PROTECTED]>
wrote: Because this will be a sharepoint server for
clients. Regardless, that |
- RE: [ActiveDir] Which ports to open in the DMZ to communicat... Bernard, Aric
