Should I used virtual named hosts for intranet?

Question

I look after the intranet in our office, running Mac OS X Server 10.5.8. We have several applications running on the intranet - Bugzilla, TWiki, a few home grown apps and some static pages. (Don't use the OS X collaboration tools - we were using TWiki before they were available.)

There is one host set up, and all the apps run under that - http://intranet/bugzilla, http://intranet/twiki, etc.

I've just read the chapter in Apache docs on virtual named hosts and I'm keen to try them. If I'm right, I'll end up with URLs like http://bugzilla/, http://twiki/, etc.? I know I also have to manage the DNS zone as well to add these names as aliases.

The advantages I can see are that it would make it easier to relocate an app to a different physical host should the need ever arise. We do have a dev set up for our public website, so having a virtual named host there makes it easier to test.

On the down side, I do have to manage DNS settings as well, whereas with a single host there is only one name to worry about.

What's the perceived wisdom here? Is this a good way to proceed?

Are there other advantages and disadvantages anyone would like to share before I make the leap. Or not.

Cheers.

Answer 1

For an Intranet with sensitive data, you not only want to enable virtual named hosts, you also want to make sure that the default site points to a dummy which says who to contact to report a misconfiguration.

Here's part of the text I serve up on my default page:

Why is this happening, instead of letting me see a default site?

To defend against a very nasty type of targetted attack. Suppose that there exists someone trying to probe their way into our system? Even if not particularly likely for some of us, it's good practice to assume that there might be someone and to get into the habit of defending against it.

Key points for this are:

It's easy to get web-hosting allowing use of any domains which you register. This applies to everyone, including attackers. DNS hosting is available with point-and-click interfaces. Any attacker worth worrying about is going to take the minimal amount of time to at least learn about hostname to IP address mappings. JavaScript is common. So are Frames. So are XSS bugs in browsers. The attacker uses frames. The top frame is loaded from www.evil.example.net. One of the child frames is loaded from victim.evil.example.net. For some browsers, the parent frame will be able to use JavaScript to control the child frame, because both are in the same domain, right? Well, so what? The attacker controls DNS for evil.example.net, so they can make “victim” point at any IP address they want. Including one of our IP addresses, even if an address in RFC 1918 space.

Net result: if the server responds with content when given unknown hostnames then an attacker can do anything to any web-pages with JavaScript; all they need is web-hosting and DNS control, and for someone to be nudged into visiting their site with a frames-capable brower which has JavaScript enabled (which is every major browser and most of the minor ones too).

In theory, these days browsers have learnt to protect against this with careful application of same-origin policies. In practice, there is no end in sight to the stream of browser security holes, for every web-browser implementing a scripting engine, which allow these browser-side cross-site scripting (XSS) bugs. So fairly often and without prior warning, the “some” browsers mentioned before suddenly become “many” or even “most”.

Because the entire attack can be neutralised on the webservers which hold the content to be protected, without having to worry about the patch status of every client browser or the presence of bugs not publicly disclosed, and because the fix is normally easy and lightweight, all webservers should ideally be careful to only respond to hostnames which they explicitly know about. This ideal might not always be practicable, but for typical webservers it is.

Answer 2

First of all I don't think is a choice you have to worry to much about. If you later find out that you decided "wrong" it shouldn't be to much trouble change the structure and put a few automatic http redirects in place.

Myself I would definitely go with separate VirtualHosts. If nothing else because of the extra options it gives me when it comes to configuration, logs, etc.

Yet, I guess it comes down to a cost-benefit analysis. How much work is it for you to also manage the DNS? Is that "cost" worth the extra freedom VirtualHost gives you? That part of the equation is hard for an outsider to give you the answer to.

Answer 3

I think that it's often a matter of aesthetics.

Personally, I would segregate things by virtual host: http://bugzilla.intranet, http://twiki.intranet, etc.. It does give you options for more easily relocating things to other hosts in the future, but you can always accomplish that after the fact by using redirects in Apache. Virtual hosts also let you partition off directory structures more tightly, which adds a little more security to a web server (which may not be as big a concern for you in an intranet setting).

Vhosts are also easier to restrict access to during testing than a simple sub directory under the main site's directory. Again, this can be done the other way using simple .htaccess rules, but I prefer to have things logically (if not physically) separated as often as possible.

Answer 4

Once you've got it set up, VHosts are definitely easier to manage, particularly in terms of configuration. You can tweak the config for one vhost and not worrying about it affecting your other sites.

If you set up a wildcard DNS entry, e.g. *.intranet, you won't have to worry about maintaining multiple DNS names.

If you use SSL (if you're transmitting passwords via webforms for any reason, I certainly hope you are), you will need to deploy multiple SSL certificates, one for each virtual host. However this can be minimised if you use a wildcard certificate, which you can either purchase, or generate yourself.