Web hosting

I am looking to set up a web hosting service first in small scale to serve
different coorporate domains, further on to supply partners and customers the
same service.
I want to plan from the beginning for a solution that will not become
dependant on our internal domain and namespace. Is it best to build a stand
alone webserver or connect it to a corresponding AD-domain? Is there a "best
practice" available somewhere?

Obviously our internal domain will lack integration benefits from a stand
alone solution but instead gain security.

Thanks

I don't know if there is a best practices guide, but I would probably not

I don't know if there is a best practices guide, but I would probably not
deploy a standalone webserver... though I suppose it depends on your budget,
how quickly you think you might grow, and your threshold for downtime.

In our situation with multiple servers, there is no question that active
directory is the way to go. It's a single location to store all user login
information. Each server on the domain uses AD to authenticate a user, so
they don't need one password to access the streaming server and another
password to upload to their webspace and another password to view their
account. When the user changes their password, you don't have to worry about
synchronizing the passwords, you change it in active directory and you're
done.

AD replicates account information between domain controllers so you don't
have to worry about losing changes if your standalone box goes down.

You will undoubtedly be deploying a SQL server now or in the near future,
using active directory with Windows authentication on the SQL box lets you
store the SQL logins in active directory as well.

You could certainly get away with a workgroup at first but I think you're
just asking for a scaling problem in the long run.

Hello and thanks.

Hello and thanks.

Would this be a good solution even if we want to host sites for external
partners and customers as well?

Sure, it's even more important to have layers of redundancy if your customers

Sure, it's even more important to have layers of redundancy if your
customers and partners are trying to access the information.

I'm not sure I was completely clear here - I don't advocate connecting this
public webserver to your EXISTING domain, I would definitely create a new
domain. That way even if the public server is compromised, they're on your
separate web hosting domain and not your internal one. Segmenting the
network is also worth exploring if budget permits. Ideally you'd have a
firewall between the public webserver and the rest of your internal network,
so even if the public server is compromised they can't also launch attacks
on each machine in your local network. Many commercial firewalls have what's
known as a "DMZ" interface, a separate interface on the firewall for
public-facing servers such as what you're proposing. Doing it this way gives
you advantages such as directly mapping to a Windows share on the webserver
from your internal LAN.

[Public Internet]-----[Firewall]--[Switch]--[Public Web Server (DMZ)]
|                   |----[Public SQL
Server (DMZ)]
|
[Switch]
|
[Internal Servers]


This is a simple example, you can do all kinds of other things, some
firewalls have multiple DMZs so you might put the web server in one, the SQL
server in another, and only allow traffic on the SQL server ports
(1433-1434)to pass between the Web and SQL server. Doing this prevents the
attacker from going anywhere except the web server itself. You could also
accomplish the same thing with VLANS if your switch supports them, put the
web server and SQL server on separate Vlans, then configure your firewall to
only allow traffic from Web to SQL on 1433-1434.

Hello and thanks again.I think I got the answer I was looking for.

Hello and thanks again.
I think I got the answer I was looking for. We already have the "standard"
solution that you describe. What I wanted to know was if we should set up a
devoted hosting Dc together with the web server or just have a stand alone
web server so now I now.

So in conclusion we should set up a seperate hosting domain with at least
one dc (and db-servers etc in the future) on a seperate internal network and
a webserver in the dmz that connects to the dc. What would be the appropriate
way to connect the web server to the internal network? So far we have
utilized 2 nic´s on the web servers, on for the internal net and the other
for the dmz. Does that seem ok or should we simply connect one nic to the dmz
and set up access to the internal network via the firewall rules? If so, wich
ports in the firewall need to be open in order for the dc and web server to
communicate correctly.

Thanks!

Using the dual-nic scenario bypasses the protection of the DMZ...

Using the dual-nic scenario bypasses the protection of the DMZ... if the web
server is compromised, they have an open door to your internal network.

This document will help with the firewall config.
http://www.microsoft.com/downloads/details.aspx?FamilyID=c2ef3846-43f0-4caf-9767-a9166368434e&DisplayLang=en

Don't forget you probably want to have a secondary DC. It can be a little
desktop machine, it won't do much work but it will keep your AD information
synchronized.

Ok, the document seems to mainly deal with ipsec and security between domains

Ok, the document seems to mainly deal with ipsec and security between domains
and dc´s. Good to have a list of all ports involved though.

Since we have a hardware vpn for all the traffic between dc´s in our
differerent sites that should be adequate, right? In our firewall rules all
ports are allowed for all hosts within the vpn. As I see it the only real
security threat with that is if malicious users from the inside want to
attack servers due to client traffic allowed in the vpn.

So we should connect the web server in the dmz with only one nic to the dmz
switch. The internal users can then simply access web pages by a rule that
allows the from "the outside" as would an external visitor to th web place.
The question is what traffic needs to take place between a dc and a web
server that belongs to the domain. Which part of the "Operational Building
Blocks" in the document apply to this set up?

Also, should the web servers dns client be configured to point to the
internal or external dns namespace?

I did not completely understand if in your sceanario and sql server was
placed in the dmz or internal zone?

Thanks!

I didn't realize the document was 80 pages, it is quite verbose and most of it

I didn't realize the document was 80 pages, it is quite verbose and most of
it doesn't apply to your situation. All I intended it for was the proper
open ports.

I'm not sure what you're asking about the hardware VPN. Are the DCs for the
hosting service going to be spread out across the VPN? It's probably not
necessary to do that unless you're planning on putting redundant hosting
servers elsewhere too. Otherwise, if the connectivity where the webserver is
located goes down,  you've got an offsite domain controller with your
replicated data but that does you no good because the web server is down.

You are correct about internal/external browsing.

Building blocks: I would follow the Login and Authentication section, both
computer and user are the same.

The web server will be in a domain, so it should be pointing to the domain
controller for DNS. The domain controller can point wherever you want for
DNS helper resolution.

SQL server could be in either place. Inside the internal segment protects
the SQL server from attack if the web server is compromised, but it also
gives the attacker a valid SQL password and an open port to your internal
network. Leaving it in the DMZ makes it vulnerable to direct attack if your
web server is compromised.

I don't really think you gain too much by pushing the SQL Server into the
internal network. If somebody gains control over the web server, they have
all of the usernames & passwords in every connection string on the server
and could use that to do pretty much whatever they wanted to do with the SQL
Server data.

However, if your application was developed with strict security in mind and
compromise of the connection string username & password doesn't mean that
all of the data you're trying to protect is vulnerable, it might be worth
the extra protection to bring the SQL server inside.

I think I got a bit confused when I read the document.

I think I got a bit confused when I read the document. I was referring to our
current setup with our own domain over different sites, not the future
hosting domain. Since the document discussed security between dc´s  I menat
that our setup with vpn between different sites would be enough. The hosting
domain will reside in a single location.

So both the websevrer and sql server should be placed in the dmz. Login and
authentication for both users and computer should be applied in the firewall
rules and be sufficient for both sql and the web server. Does a public dns
server in the dmz require the same rules as above?

In this setup all servers but the dc should be in the dmz, right?

As for using WebDav instead of ftp for updating web sites nothing but port
80 is required, right?

When setting up permissions for different customers web sites, is it best to
use local groups, domain groups or domain local groups? Is there a best
practice guide for this?

Thanks a lot!

Hehe... OK hang on again...

Hehe... OK hang on again...

The only ports the world needs to see for hosting are TCP 80/HTTP and TCP
443/HTTPS. For DNS, the world needs to see UDP 53/DNS. So regardless of
where you put the public DNS server, the world needs to see UDP port 53.

These other port openings are what the servers would need to send
communications between themselves. If they're all in the same DMZ segment,
they can all talk to each other. So if you put everything in the DMZ, they
can all talk amongst themselves and you don't have to play around with
opening up Netlogon ports. I had understood your original request to mean
that you wanted some of the hosting services to reside in the Internal zone.

I'd actually never heard about WebDav, but their site says it only uses port
80.

I would always create a domain group for your permissions.