1677 lines
74 KiB
HTML
1677 lines
74 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
|
|
<TITLE>Linux Networking-HOWTO (Previously the Net-3 Howto): Generic Network Configuration Information.</TITLE>
|
|
<LINK HREF="NET3-4-HOWTO-6.html" REL=next>
|
|
<LINK HREF="NET3-4-HOWTO-4.html" REL=previous>
|
|
<LINK HREF="NET3-4-HOWTO.html#toc5" REL=contents>
|
|
</HEAD>
|
|
<BODY>
|
|
<A HREF="NET3-4-HOWTO-6.html">Next</A>
|
|
<A HREF="NET3-4-HOWTO-4.html">Previous</A>
|
|
<A HREF="NET3-4-HOWTO.html#toc5">Contents</A>
|
|
<HR>
|
|
<H2><A NAME="s5">5. Generic Network Configuration Information.</A></H2>
|
|
|
|
<P>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.
|
|
<H2><A NAME="ss5.1">5.1 What do I need to start ?</A>
|
|
</H2>
|
|
|
|
<P>Before you start building or configuring your network you will need some
|
|
things. The most important of these are:
|
|
<H3>Current Kernel source(Optional).</H3>
|
|
|
|
<P>Please note:
|
|
<P>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.
|
|
<P>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.
|
|
<P>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.
|
|
<P>You can always obtain the latest kernel source from
|
|
<A HREF="ftp://ftp.cdrom.com/pub/linux/sunsite/kernel.org/pub/linux/kernel">ftp.cdrom.com</A>.
|
|
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.
|
|
<P>Normally the kernel source will be untarred into the
|
|
<CODE>/usr/src/linux</CODE> directory. For information on how to apply
|
|
patches and build the kernel you should read the
|
|
<A HREF="Kernel-HOWTO.html">Kernel-HOWTO</A>. For information on how
|
|
to configure kernel modules you should read the ``Modules
|
|
mini-HOWTO''. Also, the <CODE>README</CODE> file found in the kernel
|
|
sources and the <CODE>Documentation</CODE> directory are very informative
|
|
for the brave reader.
|
|
<P>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.
|
|
<P>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.
|
|
<H3>Current Network tools.</H3>
|
|
|
|
<P>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.
|
|
<P>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.
|
|
<P>If you haven't installed from a distribution then you will need to source and
|
|
compile the tools yourself. This isn't difficult.
|
|
<P>The network tools are now maintained by Bernd Eckenfels and are available at:
|
|
<A HREF="ftp://ftp.inka.de/pub/comp/Linux/networking/NetTools/">ftp.inka.de</A> and are mirrored at:
|
|
<A HREF="ftp://ftp.uk.linux.org/pub/linux/Networking/base/">ftp.uk.linux.org</A>.
|
|
<P>You can also get the latest RedHat packages from
|
|
<A HREF="ftp://ftp.cdrom.com/pub/linux/redhat/redhat-6.0/i386/base/">net-tools-1.51-3.i386.rpm</A><P>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.
|
|
<P>To install and configure the version current at the time of the writing you
|
|
need do the following:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
user% tar xvfz net-tools-1.33.tar.gz
|
|
user% cd net-tools-1.33
|
|
user% make config
|
|
user% make
|
|
root# make install
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>Or to use the Redhat packahges:
|
|
<P>
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root# rpm -U net-tools-1.51-3.i386.rpm
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>
|
|
Additionally, if you intend configuring a firewall or using the IP masquerade
|
|
feature you will require the <EM>ipfwadm</EM> command. The latest version of
|
|
it may be obtained from:
|
|
<A HREF="ftp:/ftp.xos.nl/pub/linux/ipfwadm">ftp.xos.nl</A>. 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 <EM>ipchains</EM>
|
|
in v2.2 of the kernel. <EM>ipfwadm</EM> 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.
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
Redhat 5.2 or below
|
|
Caldera pre version 2.2
|
|
Slackware pre version 4.x
|
|
Debian pre version 2.x
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>To install and configure the version current at the time of this writing you
|
|
need to read the IPChains howto located at
|
|
<A HREF="http://www.linuxdoc.org/">The Linux Documentation Project</A>
|
|
<P>Note that if you run version 2.2 (or late 2.1) of the kernel,
|
|
<EM>ipfwadm</EM> 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.
|
|
<H3>Network Application Programs.</H3>
|
|
|
|
<P> The network application programs are programs such as
|
|
<EM>telnet</EM> and <EM>ftp</EM> and their respective server
|
|
programs. David Holland has been managing a distribution of the most
|
|
common of these, which is now maintained by
|
|
<CODE>netbug@ftp.uk.linux.org</CODE>. You may obtain the distribution from:
|
|
<A HREF="ftp://ftp.uk.linux.org/pub/linux/Networking/base">ftp.uk.linux.org</A>.
|
|
<H3>IP Addresses, an Explanation.</H3>
|
|
|
|
<P>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.
|
|
<P>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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
----------------- ---------------
|
|
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
|
|
----------------- ---------------
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>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.
|
|
<P>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 <CODE>192.168.110.255</CODE>. 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.
|
|
<P>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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
----------------------------------------------------------
|
|
| 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 |
|
|
----------------------------------------------------------
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>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:
|
|
|
|
<DL>
|
|
<P>
|
|
<DT><B>Installing a linux machine on an existing IP network</B><DD><P>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:
|
|
|
|
<UL>
|
|
<LI>Host IP Address</LI>
|
|
<LI>IP network address</LI>
|
|
<LI>IP broadcast address</LI>
|
|
<LI>IP netmask</LI>
|
|
<LI>Router address</LI>
|
|
<LI>Domain Name Server Address</LI>
|
|
</UL>
|
|
|
|
|
|
You should then configure your linux network device with those
|
|
details. You can not make them up and expect your configuration to
|
|
work.
|
|
<P>
|
|
<DT><B>Building a brand new network that will never connect to the
|
|
Internet</B><DD><P>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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
-----------------------------------------------------------
|
|
| 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 |
|
|
-----------------------------------------------------------
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
|
|
You should first decide how large you want your network to be and then
|
|
choose as many of the addresses as you require.
|
|
</DL>
|
|
|
|
<H2><A NAME="ss5.2">5.2 Where should I put the configuration commands ?</A>
|
|
</H2>
|
|
|
|
<P>There are a few different approaches to Linux system boot
|
|
procedures. After the kernel boots, it always executes a program
|
|
called `<EM>init</EM>'. The <EM>init</EM> program then reads its configuration
|
|
file called <CODE>/etc/inittab</CODE> and commences the boot
|
|
process. There are a few different flavours of <EM>init</EM> around,
|
|
although everyone is now converging to the System V (Five) flavor,
|
|
developed by Miguel van Smoorenburg.
|
|
<P>Despite the fact that the <EM>init</EM> program is always the same, the
|
|
setup of system boot is organized in a different way by each
|
|
distribution.
|
|
<P>Usually the <CODE>/etc/inittab</CODE> file contains an entry looking something
|
|
like:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
si::sysinit:/etc/init.d/boot
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
<P>This line specifies the name of the shell script file that actually manages
|
|
the boot sequence. This file is somewhat equivalent to the <CODE>AUTOEXEC.BAT</CODE>
|
|
file in MS-DOS.
|
|
<P>There are usually other scripts that are called by the boot script and often
|
|
the network is configured within one of many of these.
|
|
<P>The following table may be used as a guide for your system:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
---------------------------------------------------------------------------
|
|
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/*
|
|
---------------------------------------------------------------------------
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>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 <CODE>/etc/sysconfig</CODE>, whence it is
|
|
retrieved by boot scripts). If you want to grasp the details of the
|
|
boot process, my suggestion is to check <EM>/etc/inittab</EM> and the
|
|
documentation that accompanies <EM>init</EM>. 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.
|
|
<P>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.
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
-----------------------------------------
|
|
Distrib | Network configuration program
|
|
-----------------------------------------
|
|
RedHat | /usr/bin/netcfg
|
|
Slackware | /sbin/netconfig
|
|
-----------------------------------------
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<H2><A NAME="ss5.3">5.3 Creating your network interfaces.</A>
|
|
</H2>
|
|
|
|
<P>In many Unix operating systems the network devices have appearances in the
|
|
<EM>/dev</EM> 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.
|
|
<P>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 <CODE>eth[0..n]</CODE> interfaces
|
|
sequentially as it locates your ethernet hardware. The first ethernet card
|
|
found becomes <CODE>eth0</CODE>, the second <CODE>eth1</CODE> etc.
|
|
<P>In some cases though, notably <EM>slip</EM> and <EM>ppp</EM>, 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 <EM>slip</EM> or <EM>ppp</EM> devices may vary during the uptime of the
|
|
machine. These cases will be covered in more detail in later sections.
|
|
<H2><A NAME="ss5.4">5.4 Configuring a network interface.</A>
|
|
</H2>
|
|
|
|
<P>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 <EM>ifconfig</EM> (interface configure) command.
|
|
<P>Typically you would use a command similar to the following:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>In this case I'm configuring an ethernet interface `<CODE>eth0</CODE>' with the
|
|
IP address `<CODE>192.168.0.1</CODE>' and a network mask of `<CODE>255.255.255.0</CODE>'.
|
|
The `<EM>up</EM>' 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 ``<CODE>ifconfig eth0 down</CODE>''.
|
|
<P>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
|
|
`<CODE>192.168.0.0</CODE>' and a broadcast address of `<CODE>192.168.0.255</CODE>' for the
|
|
interface.
|
|
<P>There are many other options to the <EM>ifconfig</EM> command. The most
|
|
important of these are:
|
|
|
|
<DL>
|
|
<DT><B>up</B><DD><P>this option activates an interface (and is the default).
|
|
<DT><B>down</B><DD><P>this option deactivates an interface.
|
|
<DT><B>[-]arp</B><DD><P>this option enables or disables use of the
|
|
address resolution protocol on this interface
|
|
<DT><B>[-]allmulti</B><DD><P>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.
|
|
<DT><B>mtu N</B><DD><P>this parameter allows you to set the <EM>MTU</EM> of
|
|
this device.
|
|
<DT><B>netmask <addr></B><DD><P>this parameter allows you to set the network
|
|
mask of the network this device belongs to.
|
|
<DT><B>irq <addr></B><DD><P>this parameter only works on certain types of
|
|
hardware and allows you to set the IRQ of the hardware
|
|
of this device.
|
|
<DT><B>[-]broadcast [addr]</B><DD><P>this parameter allows you
|
|
to enable and set the accepting of datagrams destined
|
|
to the broadcast address, or to disable reception of
|
|
these datagrams.
|
|
<DT><B>[-]pointopoint [addr]</B><DD><P>this parameter allows you
|
|
to set the address of the machine at the remote end of
|
|
a point to point link such as for <EM>slip</EM> or
|
|
<EM>ppp</EM>.
|
|
<DT><B>hw <type> <addr></B><DD><P>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.
|
|
</DL>
|
|
|
|
<P>You may use the <EM>ifconfig</EM> command on any network interface. Some user
|
|
programs such as <EM>pppd</EM> and <EM>dip</EM> automatically configure the network
|
|
devices as they create them, so manual use of <EM>ifconfig</EM> is unnecessary.
|
|
<H2><A NAME="ss5.5">5.5 Configuring your Name Resolver.</A>
|
|
</H2>
|
|
|
|
<P>The `<EM>Name Resolver</EM>' is a part of the linux standard library. Its prime
|
|
function is to provide a service to convert human-friendly hostnames like
|
|
`<CODE>ftp.funet.fi</CODE>' into machine friendly IP addresses such as
|
|
<CODE>128.214.248.6</CODE>.
|
|
<H3>What's in a name ?</H3>
|
|
|
|
<P>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 `<EM>domain</EM>' is a family, or
|
|
group of names. A `<EM>domain</EM>' may be broken down into
|
|
`<EM>subdomain</EM>'. A `<EM>toplevel domain</EM>' 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:
|
|
|
|
<DL>
|
|
<DT><B>COM</B><DD><P>Commercial Organizations
|
|
<DT><B>EDU</B><DD><P>Educational Organizations
|
|
<DT><B>GOV</B><DD><P>Government Organizations
|
|
<DT><B>MIL</B><DD><P>Military Organizations
|
|
<DT><B>ORG</B><DD><P>Other organizations
|
|
<DT><B>NET</B><DD><P>Internet-Related Organizations
|
|
<DT><B>Country Designator</B><DD><P>these are two letters codes that
|
|
represent a particular country.
|
|
</DL>
|
|
|
|
<P>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 `<CODE>.us</CODE>'. This is not true any more for <CODE>.com</CODE> and <CODE>.org</CODE>
|
|
domains, which are commonly used by non-us companies.
|
|
<P>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 <CODE>com</CODE>, <CODE>edu</CODE>, <CODE>gov</CODE>, <CODE>mil</CODE> and
|
|
<CODE>org</CODE> domains. So for example you end up with: <CODE>com.au</CODE> and
|
|
<CODE>gov.au</CODE> 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.
|
|
<P>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.
|
|
<P>The very left-most portion of the name is always the unique name
|
|
assigned to the host machine and is called the `<EM>hostname</EM>', the
|
|
portion of the name to the right of the hostname is called the
|
|
`<EM>domainname</EM>' and the complete name is called the `<EM>Fully
|
|
Qualified Domain Name</EM>'.
|
|
<P>To use Terry's host as an example, the fully qualified domain name
|
|
is `<CODE>perf.no.itg.telstra.com.au</CODE>'. This means that the host name is
|
|
`<CODE>perf</CODE>' and the domain name is `<CODE>no.itg.telstra.com.au</CODE>'. 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, `<CODE>.com</CODE>' is there as the next level domain. The name
|
|
of the company is (was) `<CODE>telstra</CODE>' and their internal naming
|
|
structure is based on organizational structure, in this case the
|
|
machine belongs to the Information Technology Group, Network
|
|
Operations section.
|
|
<P>Usually, the names are fairly shorter; for example, my ISP is
|
|
called ``<CODE>systemy.it</CODE>'' and my non-profit organization is called
|
|
``<CODE>linux.it</CODE>'', without any <CODE>com</CODE> and <CODE>org</CODE> subdomain, so
|
|
that my own host is just called ``<CODE>morgana.systemy.it</CODE>'' and
|
|
<CODE>rubini@linux.it</CODE> 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 <CODE>pluto.linux.it</CODE>,
|
|
because the owners of <CODE>linux.it</CODE> agreed to open a subdomain for the LUG.
|
|
<H3>What information you will need.</H3>
|
|
|
|
<P>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 `<EM>Domain Name Server</EM>', so you will need to know the IP
|
|
address of a local nameserver that you can use.
|
|
<P>There are three files you need to edit, I'll cover each of these in turn.
|
|
<H3>/etc/resolv.conf</H3>
|
|
|
|
<P>The <CODE>/etc/resolv.conf</CODE> 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:
|
|
|
|
<DL>
|
|
<DT><B>domain</B><DD><P>this keyword specifies the local domain name.
|
|
<DT><B>search</B><DD><P>this keyword specifies a list of alternate domain
|
|
names to search for a hostname
|
|
<DT><B>nameserver</B><DD><P>this keyword, which may be used many times,
|
|
specifies an IP address of a domain name server to
|
|
query when resolving names
|
|
</DL>
|
|
|
|
<P>An example <CODE>/etc/resolv.conf</CODE> might look something like:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
domain maths.wu.edu.au
|
|
search maths.wu.edu.au wu.edu.au
|
|
nameserver 192.168.10.1
|
|
nameserver 192.168.12.1
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>This example specifies that the default domain name to append to unqualified
|
|
names (ie hostnames supplied without a domain) is <CODE>maths.wu.edu.au</CODE> and
|
|
that if the host is not found in that domain to also try the <CODE>wu.edu.au</CODE>
|
|
domain directly. Two nameservers entry are supplied, each of which may be
|
|
called upon by the name resolver code to resolve the name.
|
|
<H3>/etc/host.conf</H3>
|
|
|
|
<P>The <CODE>/etc/host.conf</CODE> 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 `<CODE>resolv+</CODE>' man page. In nearly all
|
|
circumstances the following example will work for you:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
|
|
order hosts,bind
|
|
multi on
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>This configuration tells the name resolver to check the <CODE>/etc/hosts</CODE>
|
|
file before attempting to query a nameserver and to return all valid addresses
|
|
for a host found in the <CODE>/etc/hosts</CODE> file instead of just the first.
|
|
<H3>/etc/hosts</H3>
|
|
|
|
<P>The <CODE>/etc/hosts</CODE> 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.
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# /etc/hosts
|
|
127.0.0.1 localhost loopback
|
|
192.168.0.1 this.host.name
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>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.
|
|
<H3>Running a name server</H3>
|
|
|
|
<P>If you want to run a local nameserver, you can do it easily. Please
|
|
refer to the
|
|
<A HREF="DNS-HOWTO.html">DNS-HOWTO</A> and to any
|
|
documents included in your version of <EM>BIND</EM> (Berkeley Internet
|
|
Name Domain).
|
|
<H2><A NAME="ss5.6">5.6 Configuring your loopback interface.</A>
|
|
</H2>
|
|
|
|
<P>The `<CODE>loopback</CODE>' 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
|
|
`<CODE>127.0.0.1</CODE>' has been assigned specifically for loopback. So no matter
|
|
what machine you go to, if you open a telnet connection to <CODE>127.0.0.1</CODE>
|
|
you will always reach the local host.
|
|
<P>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).
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root# ifconfig lo 127.0.0.1
|
|
root# route add -host 127.0.0.1 lo
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>We'll talk more about the <EM>route</EM> command in the next section.
|
|
<H2><A NAME="ss5.7">5.7 Routing.</A>
|
|
</H2>
|
|
|
|
<P>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.
|
|
<P>Let's start with a definition. What is IP routing ? Here is one
|
|
that I'm using:
|
|
<P>
|
|
<BLOCKQUOTE>
|
|
IP Routing is the process by which a host with
|
|
multiple network connections decides where to deliver IP
|
|
datagrams it has received.
|
|
</BLOCKQUOTE>
|
|
|
|
<P>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.
|
|
<P>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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
user% cat /proc/net/route
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>or by using either of the following commands:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
user% /sbin/route -n
|
|
user% netstat -r
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>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.
|
|
<P>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 `<EM>route</EM>'.
|
|
<P>A simple example. Imagine you have an ethernet network. You've been told
|
|
it is a class-C network with an address of <CODE>192.168.1.0</CODE>. You've been
|
|
supplied with an IP address of <CODE>192.168.1.10</CODE> for your use and have
|
|
been told that <CODE>192.168.1.1</CODE> is a router connected to the Internet.
|
|
<P>The first step is to configure the interface as described earlier. You would
|
|
use a command like:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>You now need to add an entry into the routing table to tell the kernel that
|
|
datagrams for all hosts with addresses that match <CODE>192.168.1.*</CODE> should
|
|
be sent to the ethernet device. You would use a command similar to:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>Note the use of the `<CODE>-net</CODE>' argument to tell the route program that this
|
|
entry is a network route. Your other choice here is a `<CODE>-host</CODE>' route which
|
|
is a route that is specific to one IP address.
|
|
<P>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 ?
|
|
<P>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 `<CODE>default</CODE>' route. The <CODE>default</CODE> 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
|
|
<CODE>default</CODE> route. The idea of the <CODE>default</CODE> 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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root# route add default gw 192.168.1.1 eth0
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>The `<CODE>gw</CODE>' 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.
|
|
<P>So, your complete configuration would look like:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>If you take a close look at your network `<CODE>rc</CODE>' files you will find
|
|
that at least one of them looks very similar to this. This is a very common
|
|
configuration.
|
|
<P>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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>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 <CODE>default</CODE> 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 `<CODE>gw</CODE>'. 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.
|
|
<H3>So what does the <EM>routed</EM> program do ?</H3>
|
|
|
|
<P>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.
|
|
<P>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'.
|
|
<P>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: `<EM>routed</EM>' - RIP and `<EM>gated</EM>' - RIP, OSPF and others.
|
|
The `<EM>routed</EM>' program is normally supplied with your Linux distribution
|
|
or is included in the `NetKit' package detailed above.
|
|
<P>An example of where and how you might use a dynamic routing protocol might
|
|
look something like the following:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>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.
|
|
<P>It should be clear that the routing table at router A could look like:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
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
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>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.
|
|
<P>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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
|
|
root# /usr/sbin/routed
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>The `<EM>routed</EM>' 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.
|
|
<P>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.
|
|
<P>The important points relating to dynamic routing are:
|
|
|
|
<OL>
|
|
<LI>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.
|
|
</LI>
|
|
<LI>The dynamic routing daemon will automatically modify
|
|
your routing table to adjust to changes in your
|
|
network.
|
|
</LI>
|
|
<LI>RIP is suited to small to medium sized networks.</LI>
|
|
</OL>
|
|
|
|
<H2><A NAME="ss5.8">5.8 Configuring your network servers and services.</A>
|
|
</H2>
|
|
|
|
<P>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:
|
|
|
|
<DL>
|
|
<P>
|
|
<DT><B>standalone</B><DD><P>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.
|
|
<P>
|
|
<DT><B>slave to the <EM>inetd</EM> server</B><DD><P>the <EM>inetd</EM> 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.
|
|
</DL>
|
|
|
|
<P>There are two important files that we need to configure. They are the
|
|
<CODE>/etc/services</CODE> file which assigns names to port numbers and the
|
|
<CODE>/etc/inetd.conf</CODE> file which is the configuration file for the
|
|
<EM>inetd</EM> network daemon.
|
|
<H3><CODE>/etc/services</CODE></H3>
|
|
|
|
<P>The <CODE>/etc/services</CODE> 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:
|
|
|
|
<PRE>
|
|
name port/protocol aliases # comment
|
|
|
|
</PRE>
|
|
|
|
|
|
<DL>
|
|
<P>
|
|
<DT><B>name</B><DD><P>a single word name that represents the service
|
|
being described.
|
|
<P>
|
|
<DT><B>port/protocol</B><DD><P>this field is split into two subfields.
|
|
|
|
|
|
<P>
|
|
<DT><B>port</B><DD><P>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
|
|
<CODE>RFC-1340</CODE>.
|
|
<P>
|
|
<DT><B>protocol</B><DD><P>this subfield may be set to either
|
|
<CODE>tcp</CODE> or <CODE>udp</CODE>.
|
|
|
|
It is important to note that an entry of <CODE>18/tcp</CODE> is
|
|
very different from an entry of <CODE>18/udp</CODE> 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 <CODE>tcp</CODE> and
|
|
<CODE>udp</CODE> that you will see an entry for both.
|
|
<P>
|
|
<DT><B>aliases</B><DD><P>other names that may be used to refer to
|
|
this service entry.
|
|
</DL>
|
|
|
|
<P>Any text appearing in a line after a `<CODE>#</CODE>' character is ignored and treated
|
|
as a comment.
|
|
<H3>An example <CODE>/etc/services</CODE> file.</H3>
|
|
|
|
<P>All modern linux distributions provide a good <CODE>/etc/services</CODE> file.
|
|
Just in case you happen to be building a machine from the ground up, here is
|
|
a copy of the <CODE>/etc/services</CODE> file supplied with an old
|
|
<A HREF="http://www.debian.org/">Debian</A> distribution:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# /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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>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 <CODE>/etc/services</CODE> from a recent distribution.
|
|
<H3><CODE>/etc/inetd.conf</CODE></H3>
|
|
|
|
<P>The <CODE>/etc/inetd.conf</CODE> file is the configuration file for the
|
|
<EM>inetd</EM> server daemon. Its function is to tell <EM>inetd</EM> 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 <EM>inetd</EM>
|
|
what network server daemon to run and how to run it.
|
|
<P>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 `<CODE>#</CODE>'
|
|
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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
service socket_type proto flags user server_path server_args
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
|
|
<DL>
|
|
<P>
|
|
<DT><B>service</B><DD><P>is the service relevant to this
|
|
configuration as taken from the <CODE>/etc/services</CODE>
|
|
file.
|
|
<P>
|
|
<DT><B>socket_type</B><DD><P>this field describes the type of socket
|
|
that this entry will consider relevant, allowable
|
|
values are: <CODE>stream</CODE>, <CODE>dgram</CODE>, <CODE>raw</CODE>,
|
|
<CODE>rdm</CODE>, or <CODE>seqpacket</CODE>. This is a little
|
|
technical in nature, but as a rule of thumb nearly all
|
|
<CODE>tcp</CODE> based services use <CODE>stream</CODE> and nearly all
|
|
<CODE>udp</CODE> based services use <CODE>dgram</CODE>. It is only
|
|
very special types of server daemons that would use
|
|
any of the other values.
|
|
<P>
|
|
<DT><B>proto</B><DD><P>the protocol to considered valid for this
|
|
entry. This should match the appropriate entry in the
|
|
<CODE>/etc/services</CODE> file and will typically be
|
|
either <CODE>tcp</CODE> or <CODE>udp</CODE>. Sun RPC (Remote Procedure
|
|
Call) based servers will use <CODE>rpc/tcp</CODE> or
|
|
<CODE>rpc/udp</CODE>.
|
|
<P>
|
|
<DT><B>flags</B><DD><P>there are really only two possible settings
|
|
for this field. This field setting tells <EM>inetd</EM>
|
|
whether the network server program frees the socket
|
|
after it has been started and therefore whether
|
|
<EM>inetd</EM> can start another one on the next
|
|
connection request, or whether <EM>inetd</EM> 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
|
|
<CODE>tcp</CODE> servers should have this entry set to
|
|
<CODE>nowait</CODE> and most <CODE>udp</CODE> servers should have this
|
|
entry set to <CODE>wait</CODE>. Be warned there are some
|
|
notable exceptions to this, so let the example guide
|
|
you if you are not sure.
|
|
<P>
|
|
<DT><B>user</B><DD><P>this field describes which user account from
|
|
<CODE>/etc/passwd</CODE> 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
|
|
<CODE>nobody</CODE> user so that if the network server
|
|
security is breached the possible damage is minimized.
|
|
Typically this field is set to <CODE>root</CODE> though,
|
|
because many servers require root privileges in order
|
|
to function correctly.
|
|
<P>
|
|
<DT><B>server_path</B><DD><P>this field is pathname to the actual
|
|
server program to execute for this entry.
|
|
<P>
|
|
<DT><B>server_args</B><DD><P>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.
|
|
</DL>
|
|
|
|
<H3>An example <CODE>/etc/inetd.conf</CODE></H3>
|
|
|
|
<P>As for the <CODE>/etc/services</CODE> file all modern distributions will include
|
|
a good <CODE>/etc/inetd.conf</CODE> file for you to work with. Here, for
|
|
completeness is the <CODE>/etc/inetd.conf</CODE> file from the
|
|
<A HREF="http://www.debian.org/">Debian</A> distribution.
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# /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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<H2><A NAME="ss5.9">5.9 Other miscellaneous network related configuration files.</A>
|
|
</H2>
|
|
|
|
<P>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.
|
|
<H3><CODE>/etc/protocols</CODE></H3>
|
|
|
|
<P>The <CODE>/etc/protocols</CODE> 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 <EM>tcpdump</EM> to allow them to display names instead of numbers
|
|
in their output. The general syntax of the file is:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
protocolname number aliases
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>The <CODE>/etc/protocols</CODE> file supplied with the
|
|
<A HREF="http://www.debian.org/">Debian</A> distribution is as follows:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# /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
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
|
|
<H3><CODE>/etc/networks</CODE></H3>
|
|
|
|
<P>The <CODE>/etc/networks</CODE> file has a similar function to that of the
|
|
<CODE>/etc/hosts</CODE> 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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
networkname networkaddress
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
|
|
An example might look like:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
loopnet 127.0.0.0
|
|
localnet 192.168.0.0
|
|
amprnet 44.0.0.0
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>When you use commands like the <EM>route</EM> command, if a destination is
|
|
a network and that network has an entry in the <CODE>/etc/networks</CODE> file
|
|
then the route command will display that network name instead of its
|
|
address.
|
|
<H2><A NAME="ss5.10">5.10 Network Security and access control.</A>
|
|
</H2>
|
|
|
|
<P>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
|
|
<A HREF="Security-HOWTO.html">Security-HOWTO</A><P>An important rule of thumb is:
|
|
`<B>Don't run servers you don't intend to use</B>'.
|
|
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 <CODE>/etc/inetd.conf</CODE> file and comment out (<EM>place a `#' at
|
|
the start of the line</EM>) any entries for services you don't intend to use.
|
|
Good candidates are services such as: <CODE>shell</CODE>, <CODE>login</CODE>, <CODE>exec</CODE>,
|
|
<CODE>uucp</CODE>, <CODE>ftp</CODE> and informational services such as <CODE>finger</CODE>,
|
|
<CODE>netstat</CODE> and <CODE>systat</CODE>.
|
|
<P>There are all sorts of security and access control mechanisms, I'll describe
|
|
the most elementary of them.
|
|
<H3>/etc/ftpusers</H3>
|
|
|
|
<P>The <CODE>/etc/ftpusers</CODE> file is a simple mechanism that allows you to
|
|
deny certain users from logging into your machine via ftp. The
|
|
<CODE>/etc/ftpusers</CODE> file is read by the ftp daemon program (<EM>ftpd</EM>) 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:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# /etc/ftpusers - users not allowed to login via ftp
|
|
root
|
|
uucp
|
|
bin
|
|
mail
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<H3>/etc/securetty</H3>
|
|
|
|
<P>The <CODE>/etc/securetty</CODE> file allows you to specify which <CODE>tty</CODE> devices
|
|
<CODE>root</CODE> is allowed to login on. The <CODE>/etc/securetty</CODE> file is read
|
|
by the login program (usually <EM>/bin/login</EM>). Its format is a list of
|
|
the tty devices names allowed, on all others <CODE>root</CODE> login is disallowed:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# /etc/securetty - tty's on which root is allowed to login
|
|
tty1
|
|
tty2
|
|
tty3
|
|
tty4
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<H3>The <EM>tcpd</EM> hosts access control mechanism.</H3>
|
|
|
|
<P>The <EM>tcpd</EM> program you will have seen listed in the same
|
|
<CODE>/etc/inetd.conf</CODE> provides logging and access control mechanisms to
|
|
services it is configured to protect.
|
|
<P>When it is invoked by the <EM>inetd</EM> program it reads two files containing
|
|
access rules and either allows or denies access to the server it is protecting
|
|
accordingly.
|
|
<P>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: <CODE>/etc/hosts.allow</CODE>, <CODE>/etc/hosts.deny</CODE>.
|
|
I'll describe each of these in turn. For a complete description of this
|
|
facility you should refer to the appropriate <EM>man</EM> pages
|
|
(<CODE>hosts_access(5)</CODE> is a good starting point).
|
|
<H3>/etc/hosts.allow</H3>
|
|
|
|
<P>The <CODE>/etc/hosts.allow</CODE> file is a configuration file of the
|
|
<EM>/usr/sbin/tcpd</EM> program. The <CODE>hosts.allow</CODE> file contains
|
|
rules describing which hosts are <EM>allowed</EM> access to a service on
|
|
your machine.
|
|
<P>The file format is quite simple:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# /etc/hosts.allow
|
|
#
|
|
# <service list>: <host list> [: command]
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
|
|
<DL>
|
|
<P>
|
|
<DT><B><CODE>service list</CODE> </B><DD><P>is a comma delimited list of
|
|
server names that this rule applies to. Example
|
|
server names are: <CODE>ftpd</CODE>, <CODE>telnetd</CODE> and
|
|
<CODE>fingerd</CODE>.
|
|
<P>
|
|
<DT><B><CODE>host list</CODE> </B><DD><P>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: <CODE>gw.vk2ktj.ampr.org</CODE> to match a specific
|
|
host, <CODE>.uts.edu.au</CODE> to match any hostname
|
|
ending in that string, <CODE>44.</CODE> to match any IP
|
|
address commencing with those digits. There are some
|
|
special tokens to simplify configuration, some of
|
|
these are: <CODE>ALL</CODE> matches every host, <CODE>LOCAL</CODE>
|
|
matches any host whose name does not contain a
|
|
`<CODE>.</CODE>' ie is in the same domain as your machine and
|
|
<CODE>PARANOID</CODE> matches any host whose name does not
|
|
match its address (name spoofing). There is one last
|
|
token that is also useful. The <CODE>EXCEPT</CODE> token
|
|
allows you to provide a list with exceptions. This
|
|
will be covered in an example later.
|
|
<P>
|
|
<DT><B><CODE>command</CODE> </B><DD><P>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: <CODE>%h</CODE> expands to
|
|
the name of the connecting host or address if it
|
|
doesn't have a name, <CODE>%d</CODE> the daemon name being
|
|
called.
|
|
</DL>
|
|
|
|
<P>An example:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# /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)
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<H3>/etc/hosts.deny</H3>
|
|
|
|
<P>The <CODE>/etc/hosts.deny</CODE> file is a configuration file of the
|
|
<EM>/usr/sbin/tcpd</EM> program. The <CODE>hosts.deny</CODE> file contains
|
|
rules describing which hosts are <EM>disallowed</EM> access to a service on
|
|
your machine.
|
|
<P>A simple sample would look something like this:
|
|
|
|
<BLOCKQUOTE><CODE>
|
|
<PRE>
|
|
# /etc/hosts.deny
|
|
#
|
|
# Disallow all hosts with suspect hostnames
|
|
ALL: PARANOID
|
|
#
|
|
# Disallow all hosts.
|
|
ALL: ALL
|
|
|
|
</PRE>
|
|
</CODE></BLOCKQUOTE>
|
|
|
|
<P>The <CODE>PARANOID</CODE> 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.
|
|
<P>Having an <CODE>ALL: ALL</CODE> default in the <CODE>/etc/hosts.deny</CODE> and then
|
|
specifically enabling on those services and hosts that you want in the
|
|
<CODE>/etc/hosts.allow</CODE> file is the safest configuration.
|
|
<H3>/etc/hosts.equiv</H3>
|
|
|
|
<P>The <CODE>hosts.equiv</CODE> 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 <CODE>.rhosts</CODE> file as well.
|
|
<H3>Configure your <EM>ftp</EM> daemon properly.</H3>
|
|
|
|
<P>Many sites will be interested in running an anonymous <EM>ftp</EM> 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
|
|
<EM>ftp</EM> daemon properly for anonymous access. Most <EM>man</EM> pages for
|
|
<CODE>ftpd(8)</CODE> 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 <CODE>/etc/passwd</CODE> file in the anonymous account
|
|
<CODE>/etc</CODE> 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.
|
|
<H3>Network Firewalling.</H3>
|
|
|
|
<P>Not allowing datagrams to even reach your machine or servers is an
|
|
excellent means of security. This is covered in depth in the
|
|
<A HREF="Firewall-HOWTO.html">Firewall-HOWTO</A>, and (more concisely)
|
|
in a later section of this document.
|
|
<H3>Other suggestions.</H3>
|
|
|
|
<P>Here are some other, potentially religious suggestions for you to consider.
|
|
|
|
<DL>
|
|
<P>
|
|
<DT><B>sendmail</B><DD><P>despite its popularity the <EM>sendmail</EM>
|
|
daemon appears with frightening regularity on security
|
|
warning announcements. Its up to you, but I choose not
|
|
to run it.
|
|
<P>
|
|
<DT><B>NFS and other Sun RPC services</B><DD><P>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.
|
|
</DL>
|
|
|
|
<HR>
|
|
<A HREF="NET3-4-HOWTO-6.html">Next</A>
|
|
<A HREF="NET3-4-HOWTO-4.html">Previous</A>
|
|
<A HREF="NET3-4-HOWTO.html#toc5">Contents</A>
|
|
</BODY>
|
|
</HTML>
|