Network Server Testing

This document describes a few useful techniques for testing network servers. I don't think I invented anything below, but I did come up with these things independently, to the best of my knowledge. Anyway, if you aren't aware of these things, you might find the information useful.

/etc/hosts Munging

The Problem

The DNS is pretty great, but sometimes you need to work around it. When I need to test a server prior to its public release, I like to test my configuration on a "staging" server. But this always begs the question of how to direct my test traffic to the staging server, if it's important that the client believe it's talking to a server with a particular hostname. Testing web servers with real web clients often gets caught in this predicament. The tests aren't valid without using the real hostname, but the DNS ensures that the tests are hitting the production server.

The Solution

I like tinkering with /etc/hosts to work around this. Test client systems can be spoofed with the test server IP address, allowing the browser to think that http://www.example.com/ is at an alternate address. This lets you perform real tests without disturbing your production environment at all.

On traditional Unix-based systems, the file is in /etc/hosts. However, all Win32 systems can also use a static host definition table. On Win95 and Win98, the file lives in %systemdir%, which is typically C:\windows. You should see a HOSTS.SAM sample. On NT and Win2000, look in c:\winnt\system32\drivers\etc. Remember not to allow some stupid editing tool to "helpfully" append a file extension. It's "HOSTS". No .TXT or anything. Just HOSTS.

A hosts file is a simple text file with a left-hand side and a right-hand side. The left-hand side contains an IP address and the right-hand side (separated by whitespace from the left) contains a list of one or more hostnames that are found at that IP address. So an example entry might be:

192.168.1.2 www.example.com www.example.net www

At one point, I was tinkering with the idea of a very complete web QA environment that used a private DNS server, providing even more powerful control over where things can be found. Such an approach might be overkill.

Caveats

As far as I know, MacOS has no equivalent to /etc/hosts. Web clients that utilize a proxy (such as the AOL client) ignore /etc/hosts, because the proxy server looks up and retrieves the page, not the client.

Don't forget to undo your changes!

Notes

/etc/hosts munging is also a useful technique for blackholing websites you don't wish to visit. For example, to never visit doubleclick for ads, you could simply route their hostnames to a blackhole like 127.0.0.254.

netcat

Netcat is a useful little network tool, available from here. You can pipe data into and out of it to perform network transactions. There are a thousand and one uses for netcat, but here's one I thought up.

At one point I needed to test a new application on a website that detected a user's preferred language and attempted to provide a localized version of the page in the highest-preference language supported by the site. Browsers transmit language preference data as part of the HTTP request header, in the Accept-Language field. It's a simple comma-separated list of language identification codes, such as "Accept-Language: en, es".

Now, testing the permutations of the four or five supported languages was really quite a bore, especially trying to use a browser like Netscape or IE for the purpose, where configuring this parameter is really a nuisance. Instead, I threw together a little file that contained a test request:

GET / HTTP/1.1 Host: www.example.com Accept-Language: en-us, fr

By permuting the request line and continuously feeding the file through netcat, as in "cat test-http-header | netcat www.example.com 80", I was able to test the application quickly and painlessly.

Loopback Aliases

I'm not sure if there's a useful application for this technique, but I thought it was interesting so I'll mention it. You can configure IP addresses on a host's loopback interface, which most TCP/IP implementations provide. As long as the address is not on the same subnet as any of your real IP addresses, things should be fine. I have seen IP addresses on the loopback "leak" out into the wild via an interface on the same subnet, so make certain to avoid that possibility.

Anyway, as long as your OS supports aliased interfaces, you should be fine. Other hosts on the same subnet as your host with the loopback alias may be able to reach the address simply by adding a static route via the public address. Even without packet forwarding enabled on the aliasing host.

Maybe this might come in handy if you're testing Apache virtual hosting based on real IPs. Or if you have software that's specially licensed to a specific IP address and you want to test configurations.

Apparently this functionality is considered a security vulnerability. It just came up in a thread on bugtraq, eliciting a small flurry of messages. See here for details.

sysadmin:mikehan.com