So You Want to Set Up a Domain

Home

Software
FReT
MCPat

Server
Site Information
Domain HowTo

Blogs
Fours and Fives
4lisp
Intelligen5e
5nances
After5

This document is intended to guide you through the process of setting up your own internet domain. Doing this right can take some time and reasearch, and security tends to be enough of a concern that doing it wrong is a really bad idea. Hopefully this document will give you a few good starting points.

Here are the objectives I had in setting up my network:

The setup described here might be fine for a small domain (mine just includes my server and a couple of laptops), but if you want to set up a work environment that includes multiple workstations and dedicated DNS and WWW services, I would suggest looking elsewhere and doing a lot more reading.

Prepare Your Home Setup

You will probably want a static IP. There are ways of doing things with a dynamic IP, but you will have to rely on a service such as dyndns.org to register your IP. There are other reasons to use dyndns.org, which I'll get to later. If your ISP won't give you a static IP, try mine: speakeasy.net. They have been absolutely wonderful, and their tech support is better than I could have hoped for.

Once you have an IP address you need a setup where multiple computers on your network can share the single IP address. This is done through a technique called IP Masquerading. There is a related approach, called NAT (Network Address Translation) that will give you a similar effect. But my reading has led me to believe that the two approaches are frequently confused, and IP Masquerading is often called NAT. But anyway, the details are not that important. The main point is that your setup will include one dedicated device that will produce the following effect: the world shall refer to your entire network through a single IP address. Your network will however use a different set of addresses from what the world sees. For example, my external IP address might be 66.92.218.2, which is how the world will access my machines. However, inside my own network the machines will be refered as 192.168.1.1, 192.168.1.35, etc.

There are two ways of achieving this effect. The hard (but more flexible) approach is to configure a machine with two network ports. One of the network ports connects to the outside world. It listens to traffic on 66.92.218.2. The second network interface listens to your internal network. This might have the IP address 192.168.1.1. The address .1 is conventionally used for gateways, though this is not a requirement. Linux, Mac and PC's all will allow you to set up your translations very easily. This is a relatively expensive solution that will require considerably more care, and it is not the one I have used myself.

To set up IP Masquerading, I went out and bought myself a router, a device specifically wired for this type of service. In my case it was the Netgear RP614. Some of these routers also come with a wireless access point. If you want wireless, use one of them instead. Whatever router you pick, make sure you visit the manufacturer's website and get any software updates! And be careful configuring the router. If you do something seriously wrong with it, you might just lock yourself out completely, and turn the router into a paperweight.

This particular router (and in general most such routers) comes with a built in DHCP server. You can use it for the time being, but when we get further along into the configuration you will need to set up your own DHCP server. The router configuration includes choosing an internal network IP address, setting up the external IP address, and if you have a dynamic IP address then also sending any changes in the IP address to your DNS service. By this point, you have achieved two important goals: allowing all your computers to access the larger net using a single IP address, and buying yourself a significant measure of security. But we are far from done.

Setting Up your WWW Server

We now proceed with the setup of the HTTP server. For my server I started with the Fedora linux distribution. In fact, the rest of this document assumes the server is a linux machine. You should be able to create a similar configuration using windows or mac, but I will not be covering that here.

Nor will I conver here the configuration of the actual HTTP server. After you have set up and started your server, you will have to set up IP Tunneling on the router. HTTP requests by default arrive at port 80 on your IP address. These requests arrive at the router, and must be forwarded to your server's port 80 transparently. This can be done in the router configuration. You will have to consult the router manual to set this up. Once done, you should be able to access your new web server from anywhere on the net as http://66.92.218.2/

Getting a Domain Name

To get a domain name, you have to register your name with an authority allowed to register domain names. An example of such an authority is dyndns.org. Domain name registration is one of their many services. The purpose of a registration authority is to ensure that any given domain name refers to a unique server, the one that the owner of the domain had specified. The server in question has to have a publically accessible IP address. The IP address your ISP assigns, 66.92.218.2, can serve this purpose if it is running a DNS server. Your internal IP address, such as 192.168.1.1, will not do.

In my case, the domain name is mono-picante.org. This is just the domain name, by default it does not refer to any particular IP address. Usually when you want to refer to a machine, you attach a host name to the domain name. You would for example get www.mono-picante.org by attaching the host name www to the domain name mono-picante.org. For any request destined to the domain mono-picante.org, the registrar will know the IP address of the DNS server (your DNS server) that stores IP addresses of individual hosts in the domain. Taking it again from the top, suppose the registrar receives a request for www.mono-picante.org. The registrar will know that the domain mono-picante.org is serviced by a DNS server running at 66.92.218.2. So it will forward the request to your DNS server. Your DNS server will note that the request is for the host www in your domain, and will thus map it to a particular server in your domain.

To run your own primary DNS server is a hassle. Each registered domain must run two DNS servers, a primary server that holds the master configuration, and a secondary server that acts as backup in case the primary server fails. Given that our operation involves configuring only a single HTTP server, such a requirement is indeed a heavy burden. I in fact used a simpler solution.

One of the facilities many ISP's offer is hosting DNS servers. Such registries cost money, and in fact are an overkill for our needs. A good alternative turned out to be the the domain name servers provided by dyndns.org. We are allowed to store information of up to five hosts per domain free of charge on their DNS servers. Given that I have only one, www.mono-picante.org, this turned out to be a great solution.

If you were just setting up a domain name, you'd be done by now. At this point you should be able to use your HTTP server's hostname anywhere on the net and get to your web site. However, we must still configure our internal network. We shall turn to setting up our internal DNS server next.

Internal DNS & DHCP Servers

OK, fine, you can access the rest of the net using your ISP's DNS servers. And the rest of the net can access your HTTP server. But how do you get your computers to access each other by name? My Netgear RP614 provides a DHCP server. But it does not do DNS. Nor does it set up an internal domain. Given that you have multiple computers that need to talk to each other, there are two ways of doing this:

Wanting to learn how to do things the right way, I opted for the second approach. This meant temporarily disrupting my internal network and shutting off the DHCP server in my Netgear router. Proceed with this task only when you have lots of spare time, like a whole day. This can take some time to complete.

There are a few documentation resources I should reference right now. The Linux Documentation Project has a number of How-To's and longer guides on a variety of linux administration tasks. I relied on one in particular quite heavily while configuring my server: Securing & Optimizing Linux: The Ultimate Solution. This book presents a good overview of what it takes to set up a secure linux, and run servers in a secure environment. (This is in fact the kind of book you would want handy if you were setting up a larger domain.) Using all the advice there without radically modifying the Fedora distribution structure would have been difficult. So I tried to follow it as best I could while staying within the structure laid out by Fedora. I think this has worked quite well.

DNS Configuration

The first thing I tackled was the DNS server configuration. Initially I had thought that this was all I had to set up to configure my domain, so this is where I started. It turns out to be a relatively difficult and drawn out task. So you might want to start with the DHCP server first. I shall present tasks in the order in which they were tackled.

One of the tricker aspects of configuring IP masquerading is that the internal name server is different from the external. This is necessary for a number of reasons. First of all, the IP addresses used in the internal network must be chosen from among those intended for use within firewalls. This keeps the internal network packets from being routed around the rest of the net. The external IP address however must be a publically routable address. So the internal and external network operate in independent IP address spaces, which means that each space doesn't see the other's DNS servers.

Second, the external DNS server must only provide names of all the machines that the rest of the world should see, while the internal DNS server must provide names for the rest of the machines. Using a single domain name for both the internal and external network can be unsafe, as it might allow an attacker to guess the name of your private internal machines.

Things get a little complicated when you install software that needs to know the full hostname of your server. I wanted to use one such piece of software, which meant that to access it from both the internal and the external network I needed to give the server the same name in both spaces. The trick turned out to have the internal DNS server lie and claim that it was the authoratative server for both my internal domain, and my external domain, mono-picante.org. Effectively, if someone outside my private network tried to access www.mono-picante.org, they would have the illusion of a web server at 66.92.218.186, thanks to the magic of IP masquerading. And if I, from the internal network, tried to access www.mono-picante.org I would see the same machine, but responding to an address in the 192.168.1 subnet. Since the software works only on the domain name and not the IP address, the change in the IP address does not come up.

DHCP Configuration

In particular, I set up the DNS and DHCP server following their advice. The DHCP server is set up almost exactly as they have suggested. This was quite easy following the book, and I have little to add.

Dynamic DNS Configuration

We still are not at the point where a laptop obtaining a DHCP address can supply its own name for the DNS server to give to others. This ability is called Dynamic DNS (abbreviated as DDNS). Without setting up DDNS, I would not be able to refer to the laptop I have just connected to my internal network via DHCP using its name. Unfortunatley, Securing Linux does not cover DDNS configuration. My guess is that if you were to go out and buy the third edition you would find it there. But I was doing things on the cheap, and decided instead google for this bit of information.

It took me a while to find this tip on DHCP and Dynamic DNS server on Red Hat. Although the discussion is for RedHat 9, the correspondences with Fedora are quite straightforward. But I was not yet done. Although the DNS and DHCP servers were up and running, I still seemed unable to have a laptop get a name from the DHCP server and be able to use that name from other machines. The problem turned out to be with the firewall configuration. It was blocking the DNS server port, and I couldn't figure out how to modify the firewall to allow only internal access to the DNS server. So now I had to figure out how to configure the firewall.

Firewall Configuration

With all this in place, I was almost there in finishing my network configuration. The last task was locating and updating the firewall configuration. RedHat's firewall configuration tool that ships with Fedora is not flexible enough. So I had to once again go out and google for a while.

iptablesrocks.org saved the day. Some random information I gathered on the net indicated that the IP Tables (the network interface configuration software, firewall is just one of the many things it can do) configuration lives in Fedora at /etc/sysconfig/iptables. Putting the two together, I was able to figure out how to configure the firewall.

One of the key realizations in doing this was that the default Fedora firewall only regulates incoming traffic. It does nothing for outgoing network traffic. In general, you don't need to monitor outgoing network traffic. However, a server that exposes services to the rest of the net is vulnerable to attack. So on such a server controlling both incoming and outgoing network traffic is important. A hacked server (assuming root has not been compromised) will do far less damage if it is unable to arbitrarily affect other computers around it.

When blocking outgoing traffic as well as incoming, some rather annoying things start happening. Like your IM clients stop working. And your mail client stops working right. And passive FTP stops working. For the last of these, there is little to be done, since passive FTP appears to pick an outgoing port at random. (If anyone reading this can tell me more about this matter, I would much appreciate it.) For services that work over a fixed port though the solution is quite straightforward: look at your logs. On Fedora the administrative logs are written to /var/log/messages. Observe the messages being written out to this file using tail -f, run your application that has suddenly stopped functioning, and if the log reports a dropped packet look at the destination port of the service you are attempting to connect. Then add an appropriate entry to your log file. If you got your firewall configuration from iptablesrocks.org you should just be able to copy and edit existing entries to create custom entries for the services you need.

Server Monitoring

The typical Fedora installation automatically sets up SMTP for your machine. (If it doesn't, make sure to set it up.) But the SMTP setup is restricted to transferring mail within your local machine. It cannot by default be used to send mail anywhere else. This is a good thing. Your default configuration will not make your machine a target for sending out spam or some such.

Mail also happens to be the mechanism by which the root user is kept up to date on events recorded in various logs, results from the execution of cron jobs, and the like. It will also tell you if someone is trying to do something dubious to your machine. For instance, I've been getting various HTTP scans on my machine over the past few weeks. And I've had a cracker try logging into various standard accounts over ssh. For ssh, I changed the default login port. For httpd, there isn't much to be done except have faith in the security of your server.

To monitor root mail, you can choose to run your favorite mail program capable of reading the unix spool as root. Programs such as mutt or elm or even the very basic mail do this quite nicely. Alternatively, you can have your root mail routed to your user account's mailbox. This can be done by editing the file /etc/aliases, setting root as an alias to your user account.

Wrapping Up

Well, that's it. If you have a machine to dedicate to being a server, all the better. It means you can keep your home network even more secure. But at present I feel quite comfortable with the setup I have, quite certain that my machine is going to take a fair bit of effort to hack. A little bit of care and effort goes a very long way.

Copyright © 2004-2006 Sunil Mishra