|
Posted by =?Utf-8?B?RGVyZWsgTmV3dG9u?= on August 16, 2005, 9:25 am
If you were Registered and logged in, you could reply and use other advanced thread options
network) and have found that most DMZ based implementations provide no
additional security over utilizing reverse-proxying to internally placed
front-end servers. Generally most companies who go the DMZ route still place
the backend SharePoint server(s) (SQL, etc) on their internal network and due
to SharePoint's tight AD integration, they generally choose to open an
additional hole from their DMZ into their internal network to allow the
front-end SharePoint servers to talk to a DC - I've seen this implemented a
variety of ways (including an IPSEC tunnel into the internal network, or
simply a rule allowing the front-end server to talk to the appropriate
servers within the internal network). Given the above considerations, if an
intruder gains access to the SharePoint server that is located in the DMZ,
they could theoretically gain access to internally placed servers - and from
there they have access to the internal network; this task is by no means
trivial, however it is a possible scenario.
Therefore, from a security perspective, locating the SharePoint front-end
servers in the DMZ would seem to have the same risk as locating the front-end
servers within the internal network. In addition, having the reverse-proxy
in place puts another layer of security between the "outside world" and your
internal network. You'll also most likely run into fewer issues with
SharePoint and maybe see some speed increases (less packet
inspection/encryption work between the front-end servers and the back-end).
I do agree with Karl that a benefit of placing the server within the DMZ is
that there could be less "noise" on the network segment thus making it easier
to detect intrusions. However, you could easily accomplish this within your
internal network by subnetting and creating another network segment within
your internal network which would reduce network "chatter" - you could then
place an IDS on that new segment to watch for intrusions.
In my opinion, a DMZ is best used for "stand-alone" servers which do not
utilize services within the internal network; DMZs can be useful when
implementing these stand-alone services while still providing a reasonably
protected environment (even those these services are exposed to the world, a
firewall protecting the DMZ would control access).
Hope this helps...
Derek
"Marlon Brown" wrote:
> I need to publish a Sharepoint server that is on our "internal" network. I
> have ISA 2004 configued on the "Perimeter" network.
> Anyone here can tell me the *real* implications of pusblishing such
> Sharepoint server that is on the internal network ?
> Some folks at my organization persist that I should place the Sharepoint
> server in the perimeter network as well. Of course it would be more work
> move such server and open all relevant ports for Sharepoint in the firewall.
> I read Steve Riley book "Protecting your Windows Network from Perimeter to
> Data" and I understand the most recent advice is to keep "application"
> servers in the corporate network and use a reverse-proxy (such as ISA 2004)
> to publish them.
>
> Anyone here has ever seen statistics or have you tried to hack such servers
> and tell me how relevant would be put such Sharepoint (or another server
> such as OWA) on the Perimeter instead of keeping it in the internal network
> ? People talk a lot about this, but actually I would like to see in
> practical terms how more protected will be left the server in the internal
> network as is.
>
>
>
| 
XML site map