Server deployment and access security principles

Aside from the method that you use to audit the machines on your network, there is really only one other major security decision that you have to make, which is where you want to install your Enterprise Server or, to put it another way, how you want to provide access to your Enterprise Server (and to whom).

In the simplest case (security wise) if you are a one man band and you're running Enterprise Server Desktop Edition, then you don't actually need to install a separate server component for Enterprise Server. Instead, using the Desktop Edition of the software, ENT Server simply runs as a DLL that is loaded dynamically by the desktop editions of ENT NetCenter and ENT Report Forge. Whilst the Desktop Edition dispenses entirely with the problem of securing access to your Enterprise Server, it wasn't really designed as a multi-user solution (in terms of functionality and performance) and may present a number of other security problems.

Since the Desktop Edition of ENT NetCenter connects directly to your MSSQL Server, you have to deal with providing secure access to your MSSQL Server, for anyone running ENT NetCenter - which is far from ideal in anything but a closed LAN environment.

If multiple members of your IT staff will be accessing the modules of your Enterprise Server or if you want to be able to access to your ENT Server from outside your local network then the Corporate Edition of Enterprise Server is probably a more appropriate and solution.

Using the Corporate Edition of the software, your ENT Server runs as a web site under IIS (Internet Information Services) and can be accessed using either ENT NetCenter or a web browser, via the HTTP protocol:

When using the Corporate Edition of Enterprise Server, IT Staff using ENT NetCenter don't need a direct connection to your MS SQL Server databases. This means that technicians and network auditing agents on external networks can access the information in your central IT Repository and perform tasks such as posting audit snapshots, without requiring access to your SQL Server.

As already discussed in section 8.1.3, this offers considerable performance benefits since quite a bit of information goes back and forth between Enterprise Server and your databases when doing something like posting an audit snapshot. However, this is also advantageous with respect to security, since the Corporate Edition of the software allows us to keep our MSSQL database server private. Our IT Staff can access and update the information in the IT Asset Repository via a web site that we configure under IIS – they do not need access to our database server.

IIS was designed to run on computers that are publicly accessible. So if you install Enterprise Server Corporate Edition on a web server which is only available within your organization (on an Intranet) then you're probably pretty much bullet proof – providing you keep that server up to date with the most recent patches and hot fixes.

Even if you want to make your Enterprise Server available outside your local network (on the public Internet for example), IIS is certainly going to hold its own security wise. IIS is used to host over 50% of all the Fortune 1000 web sites that are publicly available on the Internet (Redmond Magazine April 2005).

Now this doesn't mean that you should install Enterprise Server on Windows 2000, with no service packs, and link every page on your company's public internet site to your ENT Server login page for the world at large to see. If you are going to run ENT Server on a machine which is accessible from outside your local network or VPN then you will still want to err on the side of paranoia in order to protect this as well as possible.

So what can we do to make sure this IIS web site (and thus your Enterprise Server) is as secure as possible? Well this is a pretty big topic and the main purpose of this document is to make you aware of any security issues that you should consider when deploying Enterprise Server – not to provide a complete tutorial on IIS Security. However, since our application runs under IIS we may as well cover a few basics here.

IIS web site will typically respond to requests on port 80. This is configurable, but a serious delinquent will know how to use a port scanner to see which ports a remote machine responds to and so mucking with the default port configuration, without doing anything else, will probably not do much to secure your server.

First of all, if a would be intruder using a port scanner does discover that the machine www.foo.net is responding to HTTP requests on port 80 (or some other port), we probably want to give him as little additional information about the nature of that web site as possible. If the web site isn't used to host anything but your ENT Server, then don't put anything else on it. Do not configure a default document for the web site and don't put any documents in the wwwroot directory of the web site. Install ENT Server in a virtual directory on the web site (e.g. http://www.foo.net/foo_ent_server/). That way, anyone that didn't know that your ENT Server was running in the foo_ent_server virtual directory wouldn't be able to access it (even if they did determine that www.foo.net was responding to HTTP requests).

Secondly, if there are parts of your ENT Server that you want to make public (such as the knowledge base) you don't have to make these available on the same server. You could, for example, host your knowledge base on a separate apache server and make use of Apache rewrites to present the information from the IIS web site where your Enterprise Server is installed. If you look at the Microforge.net knowledge base, for example, you'll see this appears to be served up by www.microforge.net (an Apache web server) – even though we've never written a version of ENT Server that can technically be run on Apache.

Thirdly, by default IIS is configured to run ISAPI DLLs (such as Enterprise Server) in the context of a local user (not a network user). If you have a domain called "foo.net" and you installed Enterprise Server as a web site under IIS on the machine NICKELS then this would typically be running in the context of the user IUSR_NICKELS which is a user that only exists on the machine nickels.foo.net. This is not a domain user and most likely does not have access to any of the other machines on your network. This is good – leave it this way.

Fourthly, and this is maybe getting extravagantly paranoid, if someone ever did manage to compromise security on the nickels box and they managed to install a worm or virus or one of those other things that regularly feature in an IT Administrator's worst nightmares, it might actually be an advantage if nickels wasn't connected to the other machines on your main network at all. Since IIS runs ISAPI DLLs as a local user, Enterprise Server will not be connecting to your database server using integrated (Windows) authentication in any case – so there's no need for nickels to be a member of the foo.net domain. You could, for example, set up a separate subnet with its own switch and firewall to connect it to the network where your database server resided. You could use that firewall to block all requests from the nickels network to the main network except those required by MSSQL Server (typically 1433). As such, the only interaction that NICKELS could have with your main network would be requests to MSSQL Server. Since any security compromise of NICKELS (a worm for example) would most likely exploit some weaknesses in IIS, which is an HTTP server not an MSSQL server, it's unlikely that this worm or other potential threat would be able to spread anywhere outside the NICKELS network – so this separate network could be used to limit potential damage or loss of service on the broader network.

Finally, as a variation on number 4 above, if you don't have the expertise to secure an IIS Server to the point where you feel comfortable making it available (even secretly) on the Internet, you could outsource this task to a web host.