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.
Before you start building or configuring your network you will need some things. The most important of these are:
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.
You can always obtain the latest kernel source from: ftp.funet.fi.
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
Module-HOWTO.
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.
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.
Be sure to choose the version that is most appopriate 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:
# # cd /usr/src # tar xvfz net-tools-1.32-alpha.tar.gz # cd net-tools-1.32-alpha # make config # make # make install #
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.
To install and configure the version current at the time of the writing you need do the following:
# # cd /usr/src # tar xvfz ipfwadm-2.3.0.tar.gz # cd ipfwadm-2.3.0 # make # make install #
The network application programs are programs such as telnet and
ftp and their respective server programs. David Holland
<dholland@hcs.harvard.edu>
now manages a distribution of the most
common of these. You may obtain it from:
ftp.uk.linux.org.
To install and configure the version current at the time of the writing you need do the following:
# # cd /usr/src # tar xvfz /pub/net/NetKit-B-0.08.tar.gz # cd NetKit-B-0.08 # more README # vi MCONFIG # make # make install #
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 seperated 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 port 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
thhat 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:
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:
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.
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 and it is this variation that is the largest cause of
variation between distributions or machines.
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 Initialisation
-------------------------------------------------------------------------------
Debian |/etc/init.d/network |/etc/init.d/netbase
| |/etc/init.d/netstd_init
| |/etc/init.d/netstd_nfs
| |/etc/init.d/netstd_misc
-------------------------------------------------------------------------------
Slackware|/etc/rc.d/rc.inet1 |/etc/rc.d/rc.inet2
-------------------------------------------------------------------------------
RedHat |/etc/sysconfig/network-scripts/ifup-<ifname>|/etc/rc.d/init.d/network
-------------------------------------------------------------------------------
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 | /sbin/netcfg
Slackware | /sbin/netconfig
-----------------------------------------
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 thus do not require device files to be present.
In the majority of cases the network devices is automatically created by the
device driver while it is initialising 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.
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 paramaters 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:
# 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.
The kernel assumes certain defaults when configuring interfaces. For example,
you may specify the network address and broadcast address for an interface,
bit 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 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:
this option activates an interface.
this option deactivates an interface.
this option enables or disables use of the address resolution protocol on this interface
this option enables or disables the use of promiscuous mode on this interface. Promiscuous mode is where a device can be commanded to accept packets even if they are not destined for this device. This is very important for programs like tcpdump and other packet snoopers.
this parameter allows you to set the MTU of this device.
this parameter allows you to set the network mask of the network this device belongs to.
this parameter only works on certain types of hardware, but allows you to set the IRQ of the hardware of this device.
this parameter allows you to enable and set the accepting of datagrams destined to the broadcast address, or to disable reception of these datagrams.
this parameters 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.
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.
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
.
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 heirarchial 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:
Commercial Organisations
Educational Organisations
Government Organisations
Millitary Organisations
Other organisations
these are two letters codes that represent a particular country.
Each of these top level domains has subdomains. The top level domains based on
country name are used 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
organisations in Australia. For historical reasons most domains belonging to
one of the non-country based top level domains are for organisations within
the United States, although the United States also has its own country code
`.us
'.
The next level of division usually represents the name of the organisation. Further subdomains vary in nature, often the next level of subdomain is based on the departmental structure of the organisation but it may be based on any criterion considered reasonable and meaningful by the network adminstrators for the organisation.
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 my own email 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 my country, Australia and as my email address
belongs to a commercial organisation we have `.com
' as the next level
domain. The name of the company is (was) `telstra
' and our internal
naming structure is based on organisational structure, in my case, my machine
belongs to the Information Technology Group, Network Operations section.
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.
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:
this keyword specifies the local domain name.
this keyword specifies a list of alternate domain names to search for a hostname
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.
The /etc/host.conf
file is where you configure some items that
govern the behavious 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.
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.
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.
# ifconfig lo 127.0.0.1
# route add -host 127.0.0.1 lo
We'll talk more about the route command in the next section.
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 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 port 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 port.
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 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:
# cat /proc/net/route
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:
# 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:
# route add -net 192.168.0.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:
# 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:
# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
# route add -net 192.168.0.0 netmask 255.255.255.0 eth0
# 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:
# route add 192.168.1.0 netmask 255.255.255.0 eth0
# route add 192.168.2.0 netmask 255.255.255.0 eth1
# route add 192.168.3.0 netmask 255.255.255.0 eth2
# 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 seperately 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.
The routing configuration described above is best suited to simple network arrangements where there 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 appopriate 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:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
# 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:
# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
# /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:
Network servers and services are those programs that allow a remote user to make user of your Linux machine. The remote user establishes a network connection to your machine and the server program, or network daemon, 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:
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.
the inetd server is a special network daemon program that specialises 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 on a particular combination of tcp or udp and service port. The ports are described in another file that we will talk about soon.
/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 seperated by
any number of whitespace (tab or space) characters. The fields
are:
name port/protocol aliases # comment
a single word name that represents the service being described.
this field is split into two subfields.
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
.
this subfield may be set to either tcp
or udp
.
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.
other names that may be used to refer to this service entry.
#
' character is ignored and treated
as a comment.
/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 the
Debian distribution.
# /etc/services:
# $Id: services,v 1.3 1996/05/06 21:42:37 tobias Exp $
#
# 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 convienence 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
/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 seperated
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
is the service relevant to this configuration as taken
from the /etc/services
file.
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.
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
.
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.
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 minimised.
Typically this field is set to root
though, because many servers require
root priveledges in order to function correctly.
this field is pathname to the actual server program to execute for this entry.
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.
/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
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: protocols,v 1.1 1995/02/24 01:09:41 imurdock Exp $
#
# 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.
Let me start this section by warning you that securing your machine and 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.
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.
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
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
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 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 searches 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 appopriate man
pages (hosts_access(5)
is a good starting point).
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)
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.
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 maximise security, don't use this mechanism and
encourage your users not to use the .rhosts
file as well.
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.
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.
Here are some other, potentially religous suggestions for you to consider.
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.
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.