Originally Published: Monday, 27 September 1999 Author: Brad Marshall
Published to: enchance_articles_security/Advanced Security Articles Page: 1/1 - [Std View]

Setting up an Intranet Router - The Beginning... - by Brad Marshall

This week's article gives an introduction to the concept of a Linux based Intranet router, valid IP address space, potential services to run, naming conventions...

Setting up an Intranet Router

This article is the first in a series, covering how to set up an intranet router which will allow anyone on the intranet (be it an office or a home) to dial up to the internet, allow web access, and receiving of mail. It assumes the intranet consists of various clients running assorted operating systems, from Windows to Linux, and knowledge of the fundamentals of TCP/IP.

The first decision to be made is that of what IP addresses to use. There is a RFC - internet ``standard'' which defines a range of IP addresses which are non-routed - that is, aren't directly connected or routed onto the internet.

The ranges defined by RFC 1597 are as follows:

A good choice for a LAN is 192.168.x.y, where x is a number chosen at random. The router then should be 192.168.x.1, as this is easy to remember.

Client machines will then use the following settings:

IPaddress: 192.168.x.y # where 1 > y < 254 Broadcast: 192.168.x.255 Network: 192.168.x.0 Netmask:

It is also necessary to select a domain name for your intranet - you can either choose a subdomain of your ISP / company, or use an obviously fake one, such as .intranet, or .homenet. The advantages of using a subdomain is that if any hostnames do leak out, it is easy to track back to a valid address and notify a responsible person. Choosing a fake domain, however, means that if somehow there is a security breach, it is harder for someone to track it back to the original host, which means other people can't take advantage of it.

Choosing hostnames for all of the machines in the intranet is also important - it makes it easier to specify which machine you are talking about, and also means less confusion when looking at logs, or when specifying what host is allowed to do what. Thinking of names for all your hosts is sometimes not easy, however - it is helpful to pick a naming scheme, and stick to it. Examples of this is planets, colours, or other similar schemes - see RFC 1178 for more examples.

Now it is time to decide what type of access the clients will have. Whether the intranet is in a home environment, or an office environment, it is important to specify, even informally, what access is allowed. It may be as simple as ``all access is allowed'', or as restrictive as only allowing access to certain hosts on certain ports.

Assuming you have some form of connection to an ISP, which provides you with only one IP address, there are a few ways of providing access to the internet. One is to get your ISP to route some IP addresses to your router - this is only necessary if you have some requirements for direct internet access to each host, and is sometimes expensive.

A possibly better approach is either to provide access by application level proxies - ie, no actual connectivity to the internet from the hosts and the clients use proxies on the router to access the resources they require. The other is to use network address translation (NAT) - the most common way of providing this under linux is ip masquerading - this hides the addresses of the clients, and makes any connections appear to be coming from the router - hence you only need one ip address.

Addtionally, it is also necessary to think of what services the intranet will be providing. Possibly useful services to provide are a dns server - Bind, a dhcp server, a web proxy - Squid, and a mail server - Sendmail, Exim or any of the many other mailservers.

Other useful services, while not strictly necessary for internet connectivity, are Apache, to provide web content, Samba, to provide file services for Windows machines, NTP for time sycronisation.

As you can see, there is more to providing access to the internet for an intranet than simply giving access - there is much to be gained from thinking about what access is required, and what extra services you provide. With a little bit of thought, it is possible to provide the desired access securely.

Brad Marshall is a Systems Administrator at Plugged In Software in Brisbane, Australia. He has a BSc. majoring in Computer Science, and has been using Linux for several years.