SBS and hosting (newbie at hosting)

[Ian]

I would like to host our company site in house, I have SBS2000 and would
like some advice on the setup. From what I am reading in this ng it is not
recomended to host the site on the SBS, so I would host it on a separate
box. At the firewall I would then point port 80 at the internal ip of the
box hosting the site, smtp would be directed to the SBS. Is this correct ?
Would this handle incoming and outgoing mail ? What if I wanted exchange to
handle multiple domains, would I just need to add a new smtp entry in the
recipient policies and set up the users for that domain.

[Jeff Middleton [SBS-MVP]]

All of your assumptions are essentially correct.

The only thing I would take exception to is the idea that you would be
pointing your Port 80 website to an "internal address", rather than a DMZ
isolated server.

The concern most of us have for using SBS to host a website is two fold.
First, hosting a website on your domain controller....the most important
machine in your network, this is something we try to avoid because a
compromise would mean a tremendous impact upon the entire network's
operation. However, by moving the website to a different server, you only
solve half the problem....albeit the bigger half. My point is that if you
can move the website to a different machine than the SBS, this is at least
50% of the concern addressed, but if you are going to port forward to
another machine that is also inside your LAN, you have left another entire
50% of the problem exposed. The concern that most of us have is that a
webserver is the most likely of all servers to be compromised from the
web....therefore you first want to minimize the value of the target (don't
make it the SBS), but you also don't want to make it a machine with internal
access to your LAN either.

You would normally want to dedicate a box to this webserver role for two
reasons. First, you can take the most basic approach that if this machine is
either taken down with denial of service attack, or corrupted, or
compromised, the worst that can happen (if properly configured) is that you
reformat the hard drive, and restore the web server from a trusted backup.
This usually would mean only a couple of hours of effort to resolve.
However, if this server is inside the LAN, trusted as a LAN member, then you
have the consideration that not only could this computer be penetrated, but
also any other computer in the LAN that trusts it. Therefore, you would
prefer to have the webserver in DMZ where it is almost entirely isolated
from the web, but is in fact entirely isolated from the internal LAN.

"Ian" <i...@4wits.com> wrote in message news:u9rt0hCPCHA.1008@tkmsftngp08...

[Ian]

Does putting the isolated server on a different subnet mask accomplish the
DMZ ? Also do I need to enable POP3 if the internal network users are not
going to be using any external POP3 mailboxes or do I need it for external
users to access mailboxes ?

"Jeff Middleton [SBS-MVP]" <je...@cfisolutions.com> wrote in message
news:#V#FBXDPCHA.2032@tkmsftngp13...

[James]

"Ian" <i...@4wits.com> wrote in message news:eDjND4DPCHA.1720@tkmsftngp09...

> Does putting the isolated server on a different subnet mask accomplish the
> DMZ ? Also do I need to enable POP3 if the internal network users are not
> going to be using any external POP3 mailboxes or do I need it for external
> users to access mailboxes ?

All your DMZ server(s) really ought to live on a separate ethernet segment
(think three network cards in your SBS2000 server) - the idea being that
when the bad guys(TM) take control of any of your DMZ machines (i.e.
mailserver / webserver / ...) and install a network sniffer, they *can't*
capture anything crucial (unencrypted login details, NTLM challenge/response
details, ...) because there's no internal traffic on that wire. The best
way to ensure this is by keeping the DMZ, external and internal networks
*physically* separate. If you cut corners and just stick your DMZ machine
on the internal network, but on a differnet subnet, then when the bad guys
'r00t' your box, they merely add an ip address on your internal network to
your "DMZ" server, fire up their sniffer, and off they go...

Keep the DMZ physically separate - you're only going to have to spend a few
$$ buying a third network card, and it should give you far more peace of
mind.

James

[Jeff Middleton [SBS-MVP]]

You do not normally need to install the POP3 Connector if you don't have
mailboxes to pick from, however, there are several KBs that tell you that as
part of a repair of an SBS or Exchange, you should reinstall SBS components
including the POP3 Connector even if you don't use it. This is because if
the POP3 Connector has any registry entries that are wrong, the ICW will
fail, so installing the POP3 Connector and disabling the service is a
perfectly simple thing to do.

In addition to the comments James made, you could alternatively to a 3rd NIC
use a low cost router/firewall to put the web server in a separate subnet
either between your server and the Internet, or off your LAN, and put the
web server in such a position that it is not only on a different subnet from
the SBS LAN, but it is one firewall away from it.

In the case of the Internet connected DMZ, you put the firewall in front of
your SBS, establish NAT for all ports forward to the SBS. The SBS no longer
has the public IP, the router does, the SBS is now using a private DMZ IP.
You put the web server in this DMZ with an IP in this same private DMZ
subnet. The most common way to make the web server visible is to split out
the port 80 at the router and direct it to the web server.

An acceptable alternative to the above is to configure physically the exact
same way, configure the router NAT port forwarding everything including port
80 to the SBS, then use ISA to redirect port 80 back at the web server. This
is more complicated to configure, but allows you to track the traffic using
ISA. I've never configured this approach, so I'm not sure if there's going
to be a special challenge in this manner....what I'm observing is that it's
possible to do this, but I'm not sure of the complexity and benefits one
would find in this.

The 3rd case is sort of the previous one of using ISA to publish an internal
server, but in a slightly different manner than the last time. The previous
two cases created the DMZ outside the SBS as the firewall, where the router
was the initial border router to the web.....that router had the public IP,
and the SBS was NAT separated from the web. This means that your SBS is a
slave to the features, functions and firewall characteristics of a cheap
router. Any ports you want open on the SBS, you have to open first on the
router. You may consider that a good idea, or a bad one. Regardless, you
have an option to get around this limitation.

Instead of putting the router as the first point of connection to the web,
you leave the SBS as the primary firewall, no NAT. You connect the router
to your LAN, just as if you were planning on making the router available to
LAN clients to go directly to the web through this router bypassing the SBS.
However, instead of connecting the router's "WAN" side to the web, you
create a new private IP subnet to attach your web server. What you have now
is a "courtyard" arrangement behind the primary firewall (the SBS)
protecting your LAN from the web, and again the web server is firewalled
from your LAN by the router.

To reach the web server from the web, either you provide the webserver a VPN
connection through the SBS, or you port forward from the SBS to this web
server using ISA, or you could even do a GRE route PPP from the SBS to the
web server, but that's not the most secure way to accomplish this for
various reasons. The preferred way is to publish the web server with ISA.

If you wanted you could even go a step further on this and use an additional
logical subnet on the SBS LAN interface to isolate your connection from the
router's subnet from the LAN.

If you want the best solution, you would probably combine the best of all of
this.....using James' suggestion for a 3rd NIC on the SBS, and then also put
a router from there......and do a private subnet that doesn't enter the LAN,
does forward through the SBS, but then the SBS is isolated from the web
server by the firewall as router. My thinking is that if you are concerned
about isolating the web server with a separate subnet, and you are expecting
it's possible to have them break into your web server.....the cost of the
additional router is trivial and would significantly improve you protection
by preventing anyone gaining control of the web server from having any ports
open back to the SBS other than the port 80 because this cheap firewall
would filter everything trying to reach back to the SBS from your hijacked
web server.

"James" <james...@reather.com> wrote in message
news:eNDALbFPCHA.1624@tkmsftngp10...

[Ian]

Thanks for the info, I will be working on this later in the week and will
see how it goes.