Linux Networking-HOWTO (Previously the Net-3 Howto): Generic Network Configuration Information.

Next Previous Contents

## 5. Generic Network Configuration Information.

The following subsections you will pretty much need to know and understand before you actually try to configure your network. They are fundamental principles that apply regardless of the exact nature of the network you wish to deploy.

## 5.1 What do I need to start ?

Before you start building or configuring your network you will need some things. The most important of these are:

### Current Kernel source(Optional).

Please note:

The majority of current distributions come with networking enabled, therefore it may not be required to recompile the kernel. If you are running well known hardware you should be just fine. For example: 3COM NIC, NE2000 NIC, or a Intel NIC. However if you find yourself in the position that you do need to update the kernel, the following information is provided.

Because the kernel you are running now might not yet have support for the network types or cards that you wish to use you will probably need the kernel source so that you can recompile the kernel with the appropriate options.

For users of the major distributions such as Redhat, Caldera, Debian, or Suse this no longer holds true. As long as you stay within the mainstream of hardware there should be no need to recompile your kernel unless there is a very specific feature that you need.

You can always obtain the latest kernel source from ftp.cdrom.com. This is not the official site but they have LOTS of bandwidth and ALOT of users allowed. The official site is kernel.org but please use the above if you can. Please remember that ftp.kernel.org is seriously overloaded. Use a mirror.

Normally the kernel source will be untarred into the `/usr/src/linux` directory. For information on how to apply patches and build the kernel you should read the Kernel-HOWTO. For information on how to configure kernel modules you should read the ``Modules mini-HOWTO''. Also, the `README` file found in the kernel sources and the `Documentation` directory are very informative for the brave reader.

Unless specifically stated otherwise, I recommend you stick with the standard kernel release (the one with the even number as the second digit in the version number). Development release kernels (the ones with the odd second digit) may have structural or other changes that may cause problems working with the other software on your system. If you are uncertain that you could resolve those sorts of problems in addition to the potential for there being other software errors, then don't use them.

On the other hand, some of the features described here have been introduced during the development of 2.1 kernels, so you must take your choice: you can stick to 2.0 while wait for 2.2 and an updated distribution with every new tool, or you can get 2.1 and look around for the various support programs needed to exploit the new features. As I write this paragraph, in August 1998, 2.1.115 is current and 2.2 is expected to appear pretty soon.

### Current Network tools.

The network tools are the programs that you use to configure linux network devices. These tools allow you to assign addresses to devices and configure routes for example.

Most modern linux distributions are supplied with the network tools, so if you have installed from a distribution and haven't yet installed the network tools then you should do so.

If you haven't installed from a distribution then you will need to source and compile the tools yourself. This isn't difficult.

The network tools are now maintained by Bernd Eckenfels and are available at: ftp.inka.de and are mirrored at: ftp.uk.linux.org.

You can also get the latest RedHat packages from net-tools-1.51-3.i386.rpm

Be sure to choose the version that is most appropriate for the kernel you wish to use and follow the instructions in the package to install.

To install and configure the version current at the time of the writing you need do the following:

> `

>             user% tar xvfz net-tools-1.33.tar.gz
>             user% cd net-tools-1.33
>             user% make config
>             user% make
>             root# make install

> `

Or to use the Redhat packahges:

> `

>             root# rpm -U net-tools-1.51-3.i386.rpm

> `

Additionally, if you intend configuring a firewall or using the IP masquerade feature you will require the ipfwadm command. The latest version of it may be obtained from: ftp.xos.nl. Again there are a number of versions available. Be sure to pick the version that most closely matches your kernel. Note that the firewalling features of Linux changed during 2.1 development and has been superceded by ipchains in v2.2 of the kernel. ipfwadm only applies to version 2.0 of the kernel. The following are known to be distributions with version 2.0 or below of the kernel.

> `

>             Redhat 5.2 or below
>             Caldera pre version 2.2
>             Slackware pre version 4.x
>             Debian pre version 2.x

> `

To install and configure the version current at the time of this writing you need to read the IPChains howto located at The Linux Documentation Project

Note that if you run version 2.2 (or late 2.1) of the kernel, ipfwadm is not the right tool to configure firewalling. This version of the NET-3-HOWTO currently doesn't deal with the new firewalling setup. If you need more detailed information on ipchains please refer to the above.

### Network Application Programs.

The network application programs are programs such as telnet and ftp and their respective server programs. David Holland has been managing a distribution of the most common of these, which is now maintained by `netbug@ftp.uk.linux.org`. You may obtain the distribution from: ftp.uk.linux.org.

### IP Addresses, an Explanation.

Internet Protocol Addresses are composed of four bytes. The convention is to write addresses in what is called `dotted decimal notation'. In this form each byte is converted to a decimal number (0-255) dropping any leading zero's unless the number is zero and written with each byte separated by a `.' character. By convention each interface of a host or router has an IP address. It is legal for the same IP address to be used on each interface of a single machine in some circumstances but usually each interface will have its own address.

Internet Protocol Networks are contiguous sequences of IP addresses. All addresses within a network have a number of digits within the address in common. The portion of the address that is common amongst all addresses within the network is called the `network portion' of the address. The remaining digits are called the `host portion'. The number of bits that are shared by all addresses within a network is called the netmask and it is role of the netmask to determine which addresses belong to the network it is applied to and which don't. For example, consider the following:

> `

>             -----------------  ---------------
>             Host Address       192.168.110.23
>             Network Mask       255.255.255.0
>             Network Portion    192.168.110.
>             Host portion                  .23
>             -----------------  ---------------
>             Network Address    192.168.110.0
>             Broadcast Address  192.168.110.255
>             -----------------  ---------------

> `

Any address that is 'bitwise anded' with its netmask will reveal the address of the network it belongs to. The network address is therefore always the lowest numbered address within the range of addresses on the network and always has the host portion of the address coded all zeroes.

The broadcast address is a special address that every host on the network listens to in addition to its own unique address. This address is the one that datagrams are sent to if every host on the network is meant to receive it. Certain types of data like routing information and warning messages are transmitted to the broadcast address so that every host on the network can receive it simultaneously. There are two commonly used standards for what the broadcast address should be. The most widely accepted one is to use the highest possible address on the network as the broadcast address. In the example above this would be `192.168.110.255`. For some reason other sites have adopted the convention of using the network address as the broadcast address. In practice it doesn't matter very much which you use but you must make sure that every host on the network is configured with the same broadcast address.

For administrative reasons some time early in the development of the IP protocol some arbitrary groups of addresses were formed into networks and these networks were grouped into what are called classes. These classes provide a number of standard size networks that could be allocated. The ranges allocated are:

> `

>             ----------------------------------------------------------
>             | Network | Netmask       | Network Addresses            |
>             | Class   |               |                              |
>             ----------------------------------------------------------
>             |    A    | 255.0.0.0     | 0.0.0.0    - 127.255.255.255 |
>             |    B    | 255.255.0.0   | 128.0.0.0  - 191.255.255.255 |
>             |    C    | 255.255.255.0 | 192.0.0.0  - 223.255.255.255 |
>             |Multicast| 240.0.0.0     | 224.0.0.0  - 239.255.255.255 |
>             ----------------------------------------------------------

> `

What addresses you should use depends on exactly what it is that you are doing. You may have to use a combination of the following activities to get all the addresses you need:

Installing a linux machine on an existing IP network

  If you wish to install a linux machine onto an existing IP network then you should contact whoever administers the network and ask them for the following information:

  - Host IP Address
  - IP network address
  - IP broadcast address
  - IP netmask
  - Router address
  - Domain Name Server Address
  You should then configure your linux network device with those details. You can not make them up and expect your configuration to work.

Building a brand new network that will never connect to the Internet

  If you are building a private network and you never intend that network to be connected to the Internet then you can choose whatever addresses you like. However, for safety and consistency reasons there have been some IP network addresses that have been reserved specifically for this purpose. These are specified in RFC1597 and are as follows:

  > `

  >             -----------------------------------------------------------
  >             |         RESERVED PRIVATE NETWORK ALLOCATIONS            |
  >             -----------------------------------------------------------
  >             | Network | Netmask       | Network Addresses             |
  >             | Class   |               |                               |
  >             -----------------------------------------------------------
  >             |    A    | 255.0.0.0     | 10.0.0.0    - 10.255.255.255  |
  >             |    B    | 255.255.0.0   | 172.16.0.0  - 172.31.255.255  |
  >             |    C    | 255.255.255.0 | 192.168.0.0 - 192.168.255.255 |
  >             -----------------------------------------------------------

  > `

  You should first decide how large you want your network to be and then choose as many of the addresses as you require.

## 5.2 Where should I put the configuration commands ?

There are a few different approaches to Linux system boot procedures. After the kernel boots, it always executes a program called `init'. The init program then reads its configuration file called `/etc/inittab` and commences the boot process. There are a few different flavours of init around, although everyone is now converging to the System V (Five) flavor, developed by Miguel van Smoorenburg.

Despite the fact that the init program is always the same, the setup of system boot is organized in a different way by each distribution.

Usually the `/etc/inittab` file contains an entry looking something like:

> `

>             si::sysinit:/etc/init.d/boot

> `

This line specifies the name of the shell script file that actually manages the boot sequence. This file is somewhat equivalent to the `AUTOEXEC.BAT` file in MS-DOS.

There are usually other scripts that are called by the boot script and often the network is configured within one of many of these.

The following table may be used as a guide for your system:

> `

>     ---------------------------------------------------------------------------
>     Distrib. | Interface Config/Routing          | Server Initialization
>     ---------------------------------------------------------------------------
>     Debian   | /etc/init.d/network               | /etc/rc2.d/*
>     ---------------------------------------------------------------------------
>     Slackware| /etc/rc.d/rc.inet1                | /etc/rc.d/rc.inet2
>     ---------------------------------------------------------------------------
>     RedHat   | /etc/rc.d/init.d/network          | /etc/rc.d/rc3.d/*
>     ---------------------------------------------------------------------------

> `

Note that Debian and Red Hat use a whole directory to host scripts that fire up system services (and usually information does not lie within these files, for example Red Hat systems store all of system configuration in files under `/etc/sysconfig`, whence it is retrieved by boot scripts). If you want to grasp the details of the boot process, my suggestion is to check /etc/inittab and the documentation that accompanies init. Linux Journal is also going to publish an article about system initialization, and this document will point to it as soon as it is available on the web.

Most modern distributions include a program that will allow you to configure many of the common sorts of network interfaces. If you have one of these then you should see if it will do what you want before attempting a manual configuration.

> `

>             -----------------------------------------
>             Distrib   | Network configuration program
>             -----------------------------------------
>             RedHat    | /usr/bin/netcfg
>             Slackware | /sbin/netconfig
>             -----------------------------------------

> `

## 5.3 Creating your network interfaces.

In many Unix operating systems the network devices have appearances in the /dev directory. This is not so in Linux. In Linux the network devices are created dynamically in software and do not require device files to be present.

In the majority of cases the network device is automatically created by the device driver while it is initializing and has located your hardware. For example, the ethernet device driver creates `eth[0..n]` interfaces sequentially as it locates your ethernet hardware. The first ethernet card found becomes `eth0`, the second `eth1` etc.

In some cases though, notably slip and ppp, the network devices are created through the action of some user program. The same sequential device numbering applies, but the devices are not created automatically at boot time. The reason for this is that unlike ethernet devices, the number of active slip or ppp devices may vary during the uptime of the machine. These cases will be covered in more detail in later sections.

## 5.4 Configuring a network interface.

When you have all of the programs you need and your address and network information you can configure your network interfaces. When we talk about configuring a network interface we are talking about the process of assigning appropriate addresses to a network device and to setting appropriate values for other configurable parameters of a network device. The program most commonly used to do this is the ifconfig (interface configure) command.

Typically you would use a command similar to the following:

> `

>             root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up

> `

In this case I'm configuring an ethernet interface ``eth0`' with the IP address ``192.168.0.1`' and a network mask of ``255.255.255.0`'. The `up' that trails the command tells the interface that it should become active, but can usually be omitted, as it is the default. To shutdown an interface, you can just call ```ifconfig eth0 down`''.

The kernel assumes certain defaults when configuring interfaces. For example, you may specify the network address and broadcast address for an interface, but if you don't, as in my example above, then the kernel will make reasonable guesses as to what they should be based on the netmask you supply and if you don't supply a netmask then on the network class of the IP address configured. In my example the kernel would assume that it is a class-C network being configured on the interface and configure a network address of ``192.168.0.0`' and a broadcast address of ``192.168.0.255`' for the interface.

There are many other options to the ifconfig command. The most important of these are:

up

  this option activates an interface (and is the default).

down

  this option deactivates an interface.

[-]arp

  this option enables or disables use of the address resolution protocol on this interface

[-]allmulti

  this option enables or disables the reception of all hardware multicast packets. Hardware multicast enables groups of hosts to receive packets addressed to special destinations. This may be of importance if you are using applications like desktop videoconferencing but is normally not used.

mtu N

  this parameter allows you to set the MTU of this device.

netmask <addr>

  this parameter allows you to set the network mask of the network this device belongs to.

irq <addr>

  this parameter only works on certain types of hardware and allows you to set the IRQ of the hardware of this device.

[-]broadcast [addr]

  this parameter allows you to enable and set the accepting of datagrams destined to the broadcast address, or to disable reception of these datagrams.

[-]pointopoint [addr]

  this parameter allows you to set the address of the machine at the remote end of a point to point link such as for slip or ppp.

hw <type> <addr>

  this parameter allows you to set the hardware address of certain types of network devices. This is not often useful for ethernet, but is useful for other network types such as AX.25.

You may use the ifconfig command on any network interface. Some user programs such as pppd and dip automatically configure the network devices as they create them, so manual use of ifconfig is unnecessary.

## 5.5 Configuring your Name Resolver.

The `Name Resolver' is a part of the linux standard library. Its prime function is to provide a service to convert human-friendly hostnames like ``ftp.funet.fi`' into machine friendly IP addresses such as `128.214.248.6`.

### What's in a name ?

You will probably be familiar with the appearance of Internet host names, but may not understand how they are constructed, or deconstructed. Internet domain names are hierarchical in nature, that is, they have a tree-like structure. A `domain' is a family, or group of names. A `domain' may be broken down into `subdomain'. A `toplevel domain' is a domain that is not a subdomain. The Top Level Domains are specified in RFC-920. Some examples of the most common top level domains are:

COM

  Commercial Organizations

EDU

  Educational Organizations

GOV

  Government Organizations

MIL

  Military Organizations

ORG

  Other organizations

NET

  Internet-Related Organizations

Country Designator

  these are two letters codes that represent a particular country.

For historical reasons most domains belonging to one of the non-country based top level domains were used by organizations within the United States, although the United States also has its own country code ``.us`'. This is not true any more for `.com` and `.org` domains, which are commonly used by non-us companies.

Each of these top level domains has subdomains. The top level domains based on country name are often next broken down into subdomains based on the `com`, `edu`, `gov`, `mil` and `org` domains. So for example you end up with: `com.au` and `gov.au` for commercial and government organizations in Australia; note that this is not a general rule, as actual policies depend on the naming authority for each domain.

The next level of division usually represents the name of the organization. Further subdomains vary in nature, often the next level of subdomain is based on the departmental structure of the organization but it may be based on any criterion considered reasonable and meaningful by the network administrators for the organization.

The very left-most portion of the name is always the unique name assigned to the host machine and is called the `hostname', the portion of the name to the right of the hostname is called the `domainname' and the complete name is called the `Fully Qualified Domain Name'.

To use Terry's host as an example, the fully qualified domain name is ``perf.no.itg.telstra.com.au`'. This means that the host name is ``perf`' and the domain name is ``no.itg.telstra.com.au`'. The domain name is based on a top level domain based on his country, Australia and as his email address belongs to a commercial organization, ``.com`' is there as the next level domain. The name of the company is (was) ``telstra`' and their internal naming structure is based on organizational structure, in this case the machine belongs to the Information Technology Group, Network Operations section.

Usually, the names are fairly shorter; for example, my ISP is called ```systemy.it`'' and my non-profit organization is called ```linux.it`'', without any `com` and `org` subdomain, so that my own host is just called ```morgana.systemy.it`'' and `rubini@linux.it` is a valid email address. Note that the owner of a domain has the rights to register hostnames as well as subdomains; for example, the LUG I belong to uses the domain `pluto.linux.it`, because the owners of `linux.it` agreed to open a subdomain for the LUG.

### What information you will need.

You will need to know what domain your hosts name will belong to. The name resolver software provides this name translation service by making requests to a `Domain Name Server', so you will need to know the IP address of a local nameserver that you can use.

There are three files you need to edit, I'll cover each of these in turn.

### /etc/resolv.conf

The `/etc/resolv.conf` is the main configuration file for the name resolver code. Its format is quite simple. It is a text file with one keyword per line. There are three keywords typically used, they are:

domain

  this keyword specifies the local domain name.

search

  this keyword specifies a list of alternate domain names to search for a hostname

nameserver

  this keyword, which may be used many times, specifies an IP address of a domain name server to query when resolving names

An example `/etc/resolv.conf` might look something like:

> `

>             domain maths.wu.edu.au
>             search maths.wu.edu.au wu.edu.au
>             nameserver 192.168.10.1
>             nameserver 192.168.12.1

> `

This example specifies that the default domain name to append to unqualified names (ie hostnames supplied without a domain) is `maths.wu.edu.au` and that if the host is not found in that domain to also try the `wu.edu.au` domain directly. Two nameservers entry are supplied, each of which may be called upon by the name resolver code to resolve the name.

### /etc/host.conf

The `/etc/host.conf` file is where you configure some items that govern the behaviour of the name resolver code. The format of this file is described in detail in the ``resolv+`' man page. In nearly all circumstances the following example will work for you:

> `

>             order hosts,bind
>             multi on

> `

This configuration tells the name resolver to check the `/etc/hosts` file before attempting to query a nameserver and to return all valid addresses for a host found in the `/etc/hosts` file instead of just the first.

### /etc/hosts

The `/etc/hosts` file is where you put the name and IP address of local hosts. If you place a host in this file then you do not need to query the domain name server to get its IP Address. The disadvantage of doing this is that you must keep this file up to date yourself if the IP address for that host changes. In a well managed system the only hostnames that usually appear in this file are an entry for the loopback interface and the local hosts name.

> `

>             # /etc/hosts
>             127.0.0.1      localhost loopback
>             192.168.0.1    this.host.name

> `

You may specify more than one host name per line as demonstrated by the first entry, which is a standard entry for the loopback interface.

### Running a name server

If you want to run a local nameserver, you can do it easily. Please refer to the DNS-HOWTO and to any documents included in your version of BIND (Berkeley Internet Name Domain).

## 5.6 Configuring your loopback interface.

The ``loopback`' interface is a special type of interface that allows you to make connections to yourself. There are various reasons why you might want to do this, for example, you may wish to test some network software without interfering with anybody else on your network. By convention the IP address ``127.0.0.1`' has been assigned specifically for loopback. So no matter what machine you go to, if you open a telnet connection to `127.0.0.1` you will always reach the local host.

Configuring the loopback interface is simple and you should ensure you do (but note that this task is usually performed by the standard initialization scripts).

> `

>             root# ifconfig lo 127.0.0.1
>             root# route add -host 127.0.0.1 lo

> `

We'll talk more about the route command in the next section.

## 5.7 Routing.

Routing is a big topic. It is easily possible to write large volumes of text about it. Most of you will have fairly simple routing requirements, some of you will not. I will cover some basic fundamentals of routing only. If you are interested in more detailed information then I suggest you refer to the references provided at the start of the document.

Let's start with a definition. What is IP routing ? Here is one that I'm using:

> IP Routing is the process by which a host with multiple network connections decides where to deliver IP datagrams it has received.

It might be useful to illustrate this with an example. Imagine a typical office router, it might have a PPP link off the Internet, a number of ethernet segments feeding the workstations and another PPP link off to another office. When the router receives a datagram on any of its network connections, routing is the mechanism that it uses to determine which interface it should send the datagram to next. Simple hosts also need to route, all Internet hosts have two network devices, one is the loopback interface described above and the other is the one it uses to talk to the rest of the network, perhaps an ethernet, perhaps a PPP or SLIP serial interface.

Ok, so how does routing work ? Each host keeps a special list of routing rules, called a routing table. This table contains rows which typically contain at least three fields, the first is a destination address, the second is the name of the interface to which the datagram is to be routed and the third is optionally the IP address of another machine which will carry the datagram on its next step through the network. In linux you can see this table by using the following command:

> `

>             user% cat /proc/net/route

> `

or by using either of the following commands:

> `

>             user% /sbin/route -n
>             user% netstat -r

> `

The routing process is fairly simple: an incoming datagram is received, the destination address (who it is for) is examined and compared with each entry in the table. The entry that best matches that address is selected and the datagram is forwarded to the specified interface. If the gateway field is filled then the datagram is forwarded to that host via the specified interface, otherwise the destination address is assumed to be on the network supported by the interface.

To manipulate this table a special command is used. This command takes command line arguments and converts them into kernel system calls that request the kernel to add, delete or modify entries in the routing table. The command is called `route'.

A simple example. Imagine you have an ethernet network. You've been told it is a class-C network with an address of `192.168.1.0`. You've been supplied with an IP address of `192.168.1.10` for your use and have been told that `192.168.1.1` is a router connected to the Internet.

The first step is to configure the interface as described earlier. You would use a command like:

> `

>             root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up

> `

You now need to add an entry into the routing table to tell the kernel that datagrams for all hosts with addresses that match `192.168.1.*` should be sent to the ethernet device. You would use a command similar to:

> `

>             root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0

> `

Note the use of the ``-net`' argument to tell the route program that this entry is a network route. Your other choice here is a ``-host`' route which is a route that is specific to one IP address.

This route will enable you to establish IP connections with all of the hosts on your ethernet segment. But what about all of the IP hosts that aren't on your ethernet segment ?

It would be a very difficult job to have to add routes to every possible destination network, so there is a special trick that is used to simplify this task. The trick is called the ``default`' route. The `default` route matches every possible destination, but poorly, so that if any other entry exists that matches the required address it will be used instead of the `default` route. The idea of the `default` route is simply to enable you to say "and everything else should go here". In the example I've contrived you would use an entry like:

> `

>             root# route add default gw 192.168.1.1 eth0

> `

The ``gw`' argument tells the route command that the next argument is the IP address, or name, of a gateway or router machine which all datagrams matching this entry should be directed to for further routing.

So, your complete configuration would look like:

> `

>             root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
>             root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
>             root# route add default gw 192.168.1.1 eth0

> `

If you take a close look at your network ``rc`' files you will find that at least one of them looks very similar to this. This is a very common configuration.

Let's now look at a slightly more complicated routing configuration. Let's imagine we are configuring the router we looked at earlier, the one supporting the PPP link to the Internet and the lan segments feeding the workstations in the office. Lets imagine the router has three ethernet segments and one PPP link. Our routing configuration would look something like:

> `

>             root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
>             root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
>             root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
>             root# route add default ppp0

> `

Each of the workstations would use the simpler form presented above, only the router needs to specify each of the network routes separately because for the workstations the `default` route mechanism will capture all of them letting the router worry about splitting them up appropriately. You may be wondering why the default route presented doesn't specify a ``gw`'. The reason for this is simple, serial link protocols such as PPP and slip only ever have two hosts on their network, one at each end. To specify the host at the other end of the link as the gateway is pointless and redundant as there is no other choice, so you do not need to specify a gateway for these types of network connections. Other network types such as ethernet, arcnet or token ring do require the gateway to be specified as these networks support large numbers of hosts on them.

### So what does the routed program do ?

The routing configuration described above is best suited to simple network arrangements where there are only ever single possible paths to destinations. When you have a more complex network arrangement things get a little more complicated. Fortunately for most of you this won't be an issue.

The big problem with `manual routing' or `static routing' as described, is that if a machine or link fails in your network then the only way you can direct your datagrams another way, if another way exists, is by manually intervening and executing the appropriate commands. Naturally this is clumsy, slow, impractical and hazard prone. Various techniques have been developed to automatically adjust routing tables in the event of network failures where there are alternate routes, all of these techniques are loosely grouped by the term `dynamic routing protocols'.

You may have heard of some of the more common dynamic routing protocols. The most common are probably RIP (Routing Information Protocol) and OSPF (Open Shortest Path First Protocol). The Routing Information Protocol is very common on small networks such as small-medium sized corporate networks or building networks. OSPF is more modern and more capable at handling large network configurations and better suited to environments where there is a large number of possible paths through the network. Common implementations of these protocols are: `routed' - RIP and `gated' - RIP, OSPF and others. The `routed' program is normally supplied with your Linux distribution or is included in the `NetKit' package detailed above.

An example of where and how you might use a dynamic routing protocol might look something like the following:

> `

>         192.168.1.0 /                         192.168.2.0 /
>            255.255.255.0                         255.255.255.0
>          -                                     -
>          |                                     |
>          |   /-----\                 /-----\   |
>          |   |     |ppp0   //    ppp0|     |   |
>     eth0 |---|  A  |------//---------|  B  |---| eth0
>          |   |     |     //          |     |   |
>          |   \-----/                 \-----/   |
>          |      \ ppp1             ppp1 /      |
>          -       \                     /       -
>                   \                   /
>                    \                 /
>                     \               /
>                      \             /
>                       \           /
>                        \         /
>                         \       /
>                          \     /
>                       ppp0\   /ppp1
>                          /-----\
>                          |     |
>                          |  C  |
>                          |     |
>                          \-----/
>                             |eth0
>                             |
>                        |---------|
>                        192.168.3.0 /
>                           255.255.255.0

> `

We have three routers A, B and C. Each supports one ethernet segment with a Class C IP network (netmask 255.255.255.0). Each router also has a PPP link to each of the other routers. The network forms a triangle.

It should be clear that the routing table at router A could look like:

> `

>             root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
>             root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
>             root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1

> `

This would work just fine until the link between router A and B should fail. If that link failed then with the routing entry shown above hosts on the ethernet segment of A could not reach hosts on the ethernet segment on B because their datagram would be directed to router A's ppp0 link which is broken. They could still continue to talk to hosts on the ethernet segment of C and hosts on the C's ethernet segment could still talk to hosts on B's ethernet segment because the link between B and C is still intact.

But wait, if A can talk to C and C can still talk to B, why shouldn't A route its datagrams for B via C and let C send them to B ? This is exactly the sort of problem that dynamic routing protocols like RIP were designed to solve. If each of the routers A, B and C were running a routing daemon then their routing tables would be automatically adjusted to reflect the new state of the network should any one of the links in the network fail. To configure such a network is simple, at each router you need only do two things. In this case for Router A:

> `

>             root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
>             root# /usr/sbin/routed

> `

The `routed' routing daemon automatically finds all active network ports when it starts and sends and listens for messages on each of the network devices to allow it to determine and update the routing table on the host.

This has been a very brief explanation of dynamic routing and where you would use it. If you want more information then you should refer to the suggested references listed at the top of the document.

The important points relating to dynamic routing are:

1. You only need to run a dynamic routing protocol daemon when your Linux machine has the possibility of selecting multiple possible routes to a destination. An example of this would be if you plan to use IP Masquerading.
2. The dynamic routing daemon will automatically modify your routing table to adjust to changes in your network.
3. RIP is suited to small to medium sized networks.

## 5.8 Configuring your network servers and services.

Network servers and services are those programs that allow a remote user to make user of your Linux machine. Server programs listen on network ports. Network ports are a means of addressing a particular service on any particular host and are how a server knows the difference between an incoming telnet connection and an incoming ftp connection. The remote user establishes a network connection to your machine and the server program, the network daemon program, listening on that port accepts the connection and executes. There are two ways that network daemons may operate. Both are commonly employed in practice. The two ways are:

standalone

  the network daemon program listens on the designated network port and when an incoming connection is made it manages the network connection itself to provide the service.

slave to the inetd server

  the inetd server is a special network daemon program that specializes in managing incoming network connections. It has a configuration file which tells it what program needs to be run when an incoming connection is received. Any service port may be configured for either of the tcp or udp protcols. The ports are described in another file that we will talk about soon.

There are two important files that we need to configure. They are the `/etc/services` file which assigns names to port numbers and the `/etc/inetd.conf` file which is the configuration file for the inetd network daemon.

### `/etc/services`

The `/etc/services` file is a simple database that associates a human friendly name to a machine friendly service port. Its format is quite simple. The file is a text file with each line representing and entry in the database. Each entry is comprised of three fields separated by any number of whitespace (tab or space) characters. The fields are:

      name      port/protocol        aliases     # comment

name

  a single word name that represents the service being described.

port/protocol

  this field is split into two subfields.

port

  a number that specifies the port number the named service will be available on. Most of the common services have assigned service numbers. These are described in `RFC-1340`.

protocol

  this subfield may be set to either `tcp` or `udp`. It is important to note that an entry of `18/tcp` is very different from an entry of `18/udp` and that there is no technical reason why the same service needs to exist on both. Normally common sense prevails and it is only if a particular service is available via both `tcp` and `udp` that you will see an entry for both.

aliases

  other names that may be used to refer to this service entry.

Any text appearing in a line after a ``#`' character is ignored and treated as a comment.

### An example `/etc/services` file.

All modern linux distributions provide a good `/etc/services` file. Just in case you happen to be building a machine from the ground up, here is a copy of the `/etc/services` file supplied with an old Debian distribution:

> `

>     # /etc/services:
>     # $Id: NET3-4-HOWTO.sgml,v 1.2 2000/07/19 15:33:03 gferg dead $
>     #
>     # Network services, Internet style
>     #
>     # Note that it is presently the policy of IANA to assign a single well-known
>     # port number for both TCP and UDP; hence, most entries here have two entries
>     # even if the protocol doesn't support UDP operations.
>     # Updated from RFC 1340, ``Assigned Numbers'' (July 1992).  Not all ports
>     # are included, only the more common ones.

>     tcpmux          1/tcp                           # TCP port service multiplexer
>     echo            7/tcp
>     echo            7/udp
>     discard         9/tcp           sink null
>     discard         9/udp           sink null
>     systat          11/tcp          users
>     daytime         13/tcp
>     daytime         13/udp
>     netstat         15/tcp
>     qotd            17/tcp          quote
>     msp             18/tcp                          # message send protocol
>     msp             18/udp                          # message send protocol
>     chargen         19/tcp          ttytst source
>     chargen         19/udp          ttytst source
>     ftp-data        20/tcp
>     ftp             21/tcp
>     ssh             22/tcp                          # SSH Remote Login Protocol
>     ssh             22/udp                          # SSH Remote Login Protocol
>     telnet          23/tcp
>     # 24 - private
>     smtp            25/tcp          mail
>     # 26 - unassigned
>     time            37/tcp          timserver
>     time            37/udp          timserver
>     rlp             39/udp          resource        # resource location
>     nameserver      42/tcp          name            # IEN 116
>     whois           43/tcp          nicname
>     re-mail-ck      50/tcp                          # Remote Mail Checking Protocol
>     re-mail-ck      50/udp                          # Remote Mail Checking Protocol
>     domain          53/tcp          nameserver      # name-domain server
>     domain          53/udp          nameserver
>     mtp             57/tcp                          # deprecated
>     bootps          67/tcp                          # BOOTP server
>     bootps          67/udp
>     bootpc          68/tcp                          # BOOTP client
>     bootpc          68/udp
>     tftp            69/udp
>     gopher          70/tcp                          # Internet Gopher
>     gopher          70/udp
>     rje             77/tcp          netrjs
>     finger          79/tcp
>     www             80/tcp          http            # WorldWideWeb HTTP
>     www             80/udp                          # HyperText Transfer Protocol
>     link            87/tcp          ttylink
>     kerberos        88/tcp          kerberos5 krb5  # Kerberos v5
>     kerberos        88/udp          kerberos5 krb5  # Kerberos v5
>     supdup          95/tcp
>     # 100 - reserved
>     hostnames       101/tcp         hostname        # usually from sri-nic
>     iso-tsap        102/tcp         tsap            # part of ISODE.
>     csnet-ns        105/tcp         cso-ns          # also used by CSO name server
>     csnet-ns        105/udp         cso-ns
>     rtelnet         107/tcp                         # Remote Telnet
>     rtelnet         107/udp
>     pop-2           109/tcp         postoffice      # POP version 2
>     pop-2           109/udp
>     pop-3           110/tcp                         # POP version 3
>     pop-3           110/udp
>     sunrpc          111/tcp         portmapper      # RPC 4.0 portmapper TCP
>     sunrpc          111/udp         portmapper      # RPC 4.0 portmapper UDP
>     auth            113/tcp         authentication tap ident
>     sftp            115/tcp
>     uucp-path       117/tcp
>     nntp            119/tcp         readnews untp   # USENET News Transfer Protocol
>     ntp             123/tcp
>     ntp             123/udp                         # Network Time Protocol
>     netbios-ns      137/tcp                         # NETBIOS Name Service
>     netbios-ns      137/udp
>     netbios-dgm     138/tcp                         # NETBIOS Datagram Service
>     netbios-dgm     138/udp
>     netbios-ssn     139/tcp                         # NETBIOS session service
>     netbios-ssn     139/udp
>     imap2           143/tcp                         # Interim Mail Access Proto v2
>     imap2           143/udp
>     snmp            161/udp                         # Simple Net Mgmt Proto
>     snmp-trap       162/udp         snmptrap        # Traps for SNMP
>     cmip-man        163/tcp                         # ISO mgmt over IP (CMOT)
>     cmip-man        163/udp
>     cmip-agent      164/tcp
>     cmip-agent      164/udp
>     xdmcp           177/tcp                         # X Display Mgr. Control Proto
>     xdmcp           177/udp
>     nextstep        178/tcp         NeXTStep NextStep       # NeXTStep window
>     nextstep        178/udp         NeXTStep NextStep       # server
>     bgp             179/tcp                         # Border Gateway Proto.
>     bgp             179/udp
>     prospero        191/tcp                         # Cliff Neuman's Prospero
>     prospero        191/udp
>     irc             194/tcp                         # Internet Relay Chat
>     irc             194/udp
>     smux            199/tcp                         # SNMP Unix Multiplexer
>     smux            199/udp
>     at-rtmp         201/tcp                         # AppleTalk routing
>     at-rtmp         201/udp
>     at-nbp          202/tcp                         # AppleTalk name binding
>     at-nbp          202/udp
>     at-echo         204/tcp                         # AppleTalk echo
>     at-echo         204/udp
>     at-zis          206/tcp                         # AppleTalk zone information
>     at-zis          206/udp
>     z3950           210/tcp         wais            # NISO Z39.50 database
>     z3950           210/udp         wais
>     ipx             213/tcp                         # IPX
>     ipx             213/udp
>     imap3           220/tcp                         # Interactive Mail Access
>     imap3           220/udp                         # Protocol v3
>     ulistserv       372/tcp                         # UNIX Listserv
>     ulistserv       372/udp
>     #
>     # UNIX specific services
>     #
>     exec            512/tcp
>     biff            512/udp         comsat
>     login           513/tcp
>     who             513/udp         whod
>     shell           514/tcp         cmd             # no passwords used
>     syslog          514/udp
>     printer         515/tcp         spooler         # line printer spooler
>     talk            517/udp
>     ntalk           518/udp
>     route           520/udp         router routed   # RIP
>     timed           525/udp         timeserver
>     tempo           526/tcp         newdate
>     courier         530/tcp         rpc
>     conference      531/tcp         chat
>     netnews         532/tcp         readnews
>     netwall         533/udp                         # -for emergency broadcasts
>     uucp            540/tcp         uucpd           # uucp daemon
>     remotefs        556/tcp         rfs_server rfs  # Brunhoff remote filesystem
>     klogin          543/tcp                         # Kerberized `rlogin' (v5)
>     kshell          544/tcp         krcmd           # Kerberized `rsh' (v5)
>     kerberos-adm    749/tcp                         # Kerberos `kadmin' (v5)
>     #
>     webster         765/tcp                         # Network dictionary
>     webster         765/udp
>     #
>     # From ``Assigned Numbers'':
>     #
>     #> The Registered Ports are not controlled by the IANA and on most systems
>     #> can be used by ordinary user processes or programs executed by ordinary
>     #> users.
>     #
>     #> Ports are used in the TCP [45,106] to name the ends of logical
>     #> connections which carry long term conversations.  For the purpose of
>     #> providing services to unknown callers, a service contact port is
>     #> defined.  This list specifies the port used by the server process as its
>     #> contact port.  While the IANA can not control uses of these ports it
>     #> does register or list uses of these ports as a convenience to the
>     #> community.
>     #
>     ingreslock      1524/tcp
>     ingreslock      1524/udp
>     prospero-np     1525/tcp                # Prospero non-privileged
>     prospero-np     1525/udp
>     rfe             5002/tcp                # Radio Free Ethernet
>     rfe             5002/udp                # Actually uses UDP only
>     bbs             7000/tcp                # BBS service
>     #
>     #
>     # Kerberos (Project Athena/MIT) services
>     # Note that these are for Kerberos v4 and are unofficial.  Sites running
>     # v4 should uncomment these and comment out the v5 entries above.
>     #
>     kerberos4       750/udp         kdc     # Kerberos (server) udp
>     kerberos4       750/tcp         kdc     # Kerberos (server) tcp
>     kerberos_master 751/udp                 # Kerberos authentication
>     kerberos_master 751/tcp                 # Kerberos authentication
>     passwd_server   752/udp                 # Kerberos passwd server
>     krb_prop        754/tcp                 # Kerberos slave propagation
>     krbupdate       760/tcp         kreg    # Kerberos registration
>     kpasswd         761/tcp         kpwd    # Kerberos "passwd"
>     kpop            1109/tcp                # Pop with Kerberos
>     knetd           2053/tcp                # Kerberos de-multiplexor
>     zephyr-srv      2102/udp                # Zephyr server
>     zephyr-clt      2103/udp                # Zephyr serv-hm connection
>     zephyr-hm       2104/udp                # Zephyr hostmanager
>     eklogin         2105/tcp                # Kerberos encrypted rlogin
>     #
>     # Unofficial but necessary (for NetBSD) services
>     #
>     supfilesrv      871/tcp                 # SUP server
>     supfiledbg      1127/tcp                # SUP debugging
>     #
>     # Datagram Delivery Protocol services
>     #
>     rtmp            1/ddp                   # Routing Table Maintenance Protocol
>     nbp             2/ddp                   # Name Binding Protocol
>     echo            4/ddp                   # AppleTalk Echo Protocol
>     zip             6/ddp                   # Zone Information Protocol
>     #
>     # Debian GNU/Linux services
>     rmtcfg          1236/tcp                # Gracilis Packeten remote config server
>     xtel            1313/tcp                # french minitel
>     cfinger         2003/tcp                # GNU Finger
>     postgres        4321/tcp                # POSTGRES
>     mandelspawn     9359/udp        mandelbrot      # network mandelbrot

>     # Local services

> `

In the real world, the actual file is always growing as new services are being created. If you fear your own copy is incomplete, I'd suggest to copy a new `/etc/services` from a recent distribution.

### `/etc/inetd.conf`

The `/etc/inetd.conf` file is the configuration file for the inetd server daemon. Its function is to tell inetd what to do when it receives a connection request for a particular service. For each service that you wish to accept connections for you must tell inetd what network server daemon to run and how to run it.

Its format is also fairly simple. It is a text file with each line describing a service that you wish to provide. Any text in a line following a ``#`' is ignored and considered a comment. Each line contains seven fields separated by any number of whitespace (tab or space) characters. The general format is as follows:

> `

>       service  socket_type  proto  flags  user  server_path  server_args

> `

service

  is the service relevant to this configuration as taken from the `/etc/services` file.

socket_type

  this field describes the type of socket that this entry will consider relevant, allowable values are: `stream`, `dgram`, `raw`, `rdm`, or `seqpacket`. This is a little technical in nature, but as a rule of thumb nearly all `tcp` based services use `stream` and nearly all `udp` based services use `dgram`. It is only very special types of server daemons that would use any of the other values.

proto

  the protocol to considered valid for this entry. This should match the appropriate entry in the `/etc/services` file and will typically be either `tcp` or `udp`. Sun RPC (Remote Procedure Call) based servers will use `rpc/tcp` or `rpc/udp`.

flags

  there are really only two possible settings for this field. This field setting tells inetd whether the network server program frees the socket after it has been started and therefore whether inetd can start another one on the next connection request, or whether inetd should wait and assume that any server daemon already running will handle the new connection request. Again this is a little tricky to work out, but as a rule of thumb all `tcp` servers should have this entry set to `nowait` and most `udp` servers should have this entry set to `wait`. Be warned there are some notable exceptions to this, so let the example guide you if you are not sure.

user

  this field describes which user account from `/etc/passwd` will be set as the owner of the network daemon when it is started. This is often useful if you want to safeguard against security risks. You can set the user of an entry to the `nobody` user so that if the network server security is breached the possible damage is minimized. Typically this field is set to `root` though, because many servers require root privileges in order to function correctly.

server_path

  this field is pathname to the actual server program to execute for this entry.

server_args

  this field comprises the rest of the line and is optional. This field is where you place any command line arguments that you wish to pass to the server daemon program when it is launched.

### An example `/etc/inetd.conf`

As for the `/etc/services` file all modern distributions will include a good `/etc/inetd.conf` file for you to work with. Here, for completeness is the `/etc/inetd.conf` file from the Debian distribution.

> `

>     # /etc/inetd.conf:  see inetd(8) for further informations.
>     #
>     # Internet server configuration database
>     #
>     #
>     # Modified for Debian by Peter Tobias <tobias@et-inf.fho-emden.de>
>     #
>     # <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
>     #
>     # Internal services
>     #
>     #echo           stream  tcp     nowait  root    internal
>     #echo           dgram   udp     wait    root    internal
>     discard         stream  tcp     nowait  root    internal
>     discard         dgram   udp     wait    root    internal
>     daytime         stream  tcp     nowait  root    internal
>     daytime         dgram   udp     wait    root    internal
>     #chargen        stream  tcp     nowait  root    internal
>     #chargen        dgram   udp     wait    root    internal
>     time            stream  tcp     nowait  root    internal
>     time            dgram   udp     wait    root    internal
>     #
>     # These are standard services.
>     #
>     telnet  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.telnetd
>     ftp     stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.ftpd
>     #fsp    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.fspd
>     #
>     # Shell, login, exec and talk are BSD protocols.
>     #
>     shell   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd
>     login   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind
>     #exec   stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rexecd
>     talk    dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.talkd
>     ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.ntalkd
>     #
>     # Mail, news and uucp services.
>     #
>     smtp    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.smtpd
>     #nntp   stream  tcp     nowait  news    /usr/sbin/tcpd  /usr/sbin/in.nntpd
>     #uucp   stream  tcp     nowait  uucp    /usr/sbin/tcpd  /usr/lib/uucp/uucico
>     #comsat dgram   udp     wait    root    /usr/sbin/tcpd  /usr/sbin/in.comsat
>     #
>     # Pop et al
>     #
>     #pop-2  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop2d
>     #pop-3  stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.pop3d
>     #
>     # `cfinger' is for the GNU finger server available for Debian.  (NOTE: The
>     # current implementation of the `finger' daemon allows it to be run as `root'.)
>     #
>     #cfinger stream tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.cfingerd
>     #finger stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.fingerd
>     #netstat        stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/netstat
>     #systat stream  tcp     nowait  nobody  /usr/sbin/tcpd  /bin/ps -auwwx
>     #
>     # Tftp service is provided primarily for booting.  Most sites
>     # run this only on machines acting as "boot servers."
>     #
>     #tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd
>     #tftp   dgram   udp     wait    nobody  /usr/sbin/tcpd  /usr/sbin/in.tftpd /boot
>     #bootps dgram   udp     wait    root    /usr/sbin/bootpd        bootpd -i -t 120
>     #
>     # Kerberos authenticated services (these probably need to be corrected)
>     #
>     #klogin         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k
>     #eklogin        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rlogind -k -x
>     #kshell         stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/in.rshd -k
>     #
>     # Services run ONLY on the Kerberos server (these probably need to be corrected)
>     #
>     #krbupdate      stream tcp      nowait  root    /usr/sbin/tcpd  /usr/sbin/registerd
>     #kpasswd        stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/kpasswdd
>     #
>     # RPC based services
>     #
>     #mountd/1       dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.mountd
>     #rstatd/1-3     dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rstatd
>     #rusersd/2-3    dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rusersd
>     #walld/1        dgram   rpc/udp wait    root    /usr/sbin/tcpd  /usr/sbin/rpc.rwalld
>     #
>     # End of inetd.conf.
>     ident           stream  tcp     nowait  nobody  /usr/sbin/identd        identd -i

> `

## 5.9 Other miscellaneous network related configuration files.

There are a number of miscellaneous files relating to network configuration under linux that you might be interested in. You may never have to modify these files, but it is worth describing them so you know what they contain and what they are for.

### `/etc/protocols`

The `/etc/protocols` file is a database that maps protocol id numbers against protocol names. This is used by programmers to allow them to specify protocols by name in their programs and also by some programs such as tcpdump to allow them to display names instead of numbers in their output. The general syntax of the file is:

> `

>       protocolname  number  aliases

> `

The `/etc/protocols` file supplied with the Debian distribution is as follows:

> `

>     # /etc/protocols:
>     # $Id: NET3-4-HOWTO.sgml,v 1.2 2000/07/19 15:33:03 gferg dead $
>     #
>     # Internet (IP) protocols
>     #
>     #       from: @(#)protocols     5.1 (Berkeley) 4/17/89
>     #
>     # Updated for NetBSD based on RFC 1340, Assigned Numbers (July 1992).

>     ip      0       IP              # internet protocol, pseudo protocol number
>     icmp    1       ICMP            # internet control message protocol
>     igmp    2       IGMP            # Internet Group Management
>     ggp     3       GGP             # gateway-gateway protocol
>     ipencap 4       IP-ENCAP        # IP encapsulated in IP (officially ``IP'')
>     st      5       ST              # ST datagram mode
>     tcp     6       TCP             # transmission control protocol
>     egp     8       EGP             # exterior gateway protocol
>     pup     12      PUP             # PARC universal packet protocol
>     udp     17      UDP             # user datagram protocol
>     hmp     20      HMP             # host monitoring protocol
>     xns-idp 22      XNS-IDP         # Xerox NS IDP
>     rdp     27      RDP             # "reliable datagram" protocol
>     iso-tp4 29      ISO-TP4         # ISO Transport Protocol class 4
>     xtp     36      XTP             # Xpress Tranfer Protocol
>     ddp     37      DDP             # Datagram Delivery Protocol
>     idpr-cmtp       39      IDPR-CMTP       # IDPR Control Message Transport
>     rspf    73      RSPF            # Radio Shortest Path First.
>     vmtp    81      VMTP            # Versatile Message Transport
>     ospf    89      OSPFIGP         # Open Shortest Path First IGP
>     ipip    94      IPIP            # Yet Another IP encapsulation
>     encap   98      ENCAP           # Yet Another IP encapsulation

> `

### `/etc/networks`

The `/etc/networks` file has a similar function to that of the `/etc/hosts` file. It provides a simple database of network names against network addresses. Its format differs in that there may be only two fields per line and that the fields are coded as:

> `

>       networkname networkaddress

> `

An example might look like:

> `

>             loopnet    127.0.0.0
>             localnet   192.168.0.0
>             amprnet    44.0.0.0

> `

When you use commands like the route command, if a destination is a network and that network has an entry in the `/etc/networks` file then the route command will display that network name instead of its address.

## 5.10 Network Security and access control.

Let me start this section by warning you that securing your machine and network against malicious attack is a complex art. I do not consider myself an expert in this field at all and while the following mechanisms I describe will help, if you are serious about security then I recommend you do some research of your own into the subject. There are many good references on the Internet relating to the subject, including the Security-HOWTO

An important rule of thumb is: `Don't run servers you don't intend to use'. Many distributions come configured with all sorts of services configured and automatically started. To ensure even a minimum level of safety you should go through your `/etc/inetd.conf` file and comment out (place a `#' at the start of the line) any entries for services you don't intend to use. Good candidates are services such as: `shell`, `login`, `exec`, `uucp`, `ftp` and informational services such as `finger`, `netstat` and `systat`.

There are all sorts of security and access control mechanisms, I'll describe the most elementary of them.

### /etc/ftpusers

The `/etc/ftpusers` file is a simple mechanism that allows you to deny certain users from logging into your machine via ftp. The `/etc/ftpusers` file is read by the ftp daemon program (ftpd) when an incoming ftp connection is received. The file is a simple list of those users who are disallowed from logging in. It might looks something like:

> `

>             # /etc/ftpusers - users not allowed to login via ftp
>             root
>             uucp
>             bin
>             mail

> `

### /etc/securetty

The `/etc/securetty` file allows you to specify which `tty` devices `root` is allowed to login on. The `/etc/securetty` file is read by the login program (usually /bin/login). Its format is a list of the tty devices names allowed, on all others `root` login is disallowed:

> `

>             # /etc/securetty - tty's on which root is allowed to login
>             tty1
>             tty2
>             tty3
>             tty4

> `

### The tcpd hosts access control mechanism.

The tcpd program you will have seen listed in the same `/etc/inetd.conf` provides logging and access control mechanisms to services it is configured to protect.

When it is invoked by the inetd program it reads two files containing access rules and either allows or denies access to the server it is protecting accordingly.

It will search the rules files until the first match is found. If no match is found then it assumes that access should be allowed to anyone. The files it searches in sequence are: `/etc/hosts.allow`, `/etc/hosts.deny`. I'll describe each of these in turn. For a complete description of this facility you should refer to the appropriate man pages (`hosts_access(5)` is a good starting point).

### /etc/hosts.allow

The `/etc/hosts.allow` file is a configuration file of the /usr/sbin/tcpd program. The `hosts.allow` file contains rules describing which hosts are allowed access to a service on your machine.

The file format is quite simple:

> `

>             # /etc/hosts.allow
>             #
>             # <service list>: <host list> [: command]

> `

`service list`

  is a comma delimited list of server names that this rule applies to. Example server names are: `ftpd`, `telnetd` and `fingerd`.

`host list`

  is a comma delimited list of host names. You may also use IP addresses here. You may additionally specify hostnames or addresses using wildcard characters to match groups of hosts. Examples include: `gw.vk2ktj.ampr.org` to match a specific host, `.uts.edu.au` to match any hostname ending in that string, `44.` to match any IP address commencing with those digits. There are some special tokens to simplify configuration, some of these are: `ALL` matches every host, `LOCAL` matches any host whose name does not contain a ``.`' ie is in the same domain as your machine and `PARANOID` matches any host whose name does not match its address (name spoofing). There is one last token that is also useful. The `EXCEPT` token allows you to provide a list with exceptions. This will be covered in an example later.

`command`

  is an optional parameter. This parameter is the full pathname of a command that would be executed everytime this rule is matched. It could for example run a command that would attempt to identify who is logged onto the connecting host, or to generate a mail message or some other warning to a system administrator that someone is attempting to connect. There are a number of expansions that may be included, some common examples are: `%h` expands to the name of the connecting host or address if it doesn't have a name, `%d` the daemon name being called.

An example:

> `

>       # /etc/hosts.allow
>       #
>       # Allow mail to anyone
>       in.smtpd: ALL
>       # All telnet and ftp to only hosts within my domain and my host at home.
>       telnetd, ftpd: LOCAL, myhost.athome.org.au
>       # Allow finger to anyone but keep a record of who they are.
>       fingerd: ALL: (finger @%h | mail -s "finger from %h" root)

> `

### /etc/hosts.deny

The `/etc/hosts.deny` file is a configuration file of the /usr/sbin/tcpd program. The `hosts.deny` file contains rules describing which hosts are disallowed access to a service on your machine.

A simple sample would look something like this:

> `

>       # /etc/hosts.deny
>       #
>       # Disallow all hosts with suspect hostnames
>       ALL: PARANOID
>       #
>       # Disallow all hosts.
>       ALL: ALL

> `

The `PARANOID` entry is really redundant because the other entry traps everything in any case. Either of these entry would make a reasonable default depending on your particular requirement.

Having an `ALL: ALL` default in the `/etc/hosts.deny` and then specifically enabling on those services and hosts that you want in the `/etc/hosts.allow` file is the safest configuration.

### /etc/hosts.equiv

The `hosts.equiv` file is used to grant certain hosts and users access rights to accounts on your machine without having to supply a password. This is useful in a secure environment where you control all machines, but is a security hazard otherwise. Your machine is only as secure as the least secure of the trusted hosts. To maximize security, don't use this mechanism and encourage your users not to use the `.rhosts` file as well.

### Configure your ftp daemon properly.

Many sites will be interested in running an anonymous ftp server to allow other people to upload and download files without requiring a specific userid. If you decide to offer this facility make sure you configure the ftp daemon properly for anonymous access. Most man pages for `ftpd(8)` describe in some length how to go about this. You should always ensure that you follow these instructions. An important tip is to not use a copy of your `/etc/passwd` file in the anonymous account `/etc` directory, make sure you strip out all account details except those that you must have, otherwise you will be vulnerable to brute force password cracking techniques.

### Network Firewalling.

Not allowing datagrams to even reach your machine or servers is an excellent means of security. This is covered in depth in the Firewall-HOWTO, and (more concisely) in a later section of this document.

### Other suggestions.

Here are some other, potentially religious suggestions for you to consider.

sendmail

  despite its popularity the sendmail daemon appears with frightening regularity on security warning announcements. Its up to you, but I choose not to run it.

NFS and other Sun RPC services

  be wary of these. There are all sorts of possible exploits for these services. It is difficult finding an option to services like NFS, but if you configure them, make sure you are careful with who you allow mount rights to.

Next Previous Contents