A major problem with
configuration files under Unix is that there are so many of them in
so many places. On a multiuser system that provides a variety of
services, there may be scores of configuration files scattered among
dozens of directories. Even worse, it seems that every implementation
of Unix is different. Even different releases of the same flavor of
Unix may vary. Add to this the complications that multiple
applications contribute and you have a major undertaking. If you are
running a number of different platforms, you have your work cut out
for you.
For these reasons, it is unrealistic to attempt to give an exhaustive
list of configuration files. It is possible, however, to discuss
configuration files by categories. The categories can then serve as a
guide or reminder when you construct your own lists so that you
don't overlook an important group of files. Just keep in mind
that what follows is only a starting point. You will have to discover
your particular implementations of Unix one file at a time.
2.2.1. Basic Configuration Files
There are a number of fairly standard
configuration files that seem to show up on most systems. These are
usually, but not always, located in the
/etc
directory. (For customization, you may see a number of files in the
/usr/local or
/usr/opt
directories or their subdirectories.) When looking at files, this is
clearly the first place to start. Your system will probably include
many of the following:
defaultdomain,
defaultroute,
ethers,
gateways,
host.conf,
hostname,
hosts,
hosts.allow,
hosts.equiv,
inetd.conf,
localhosts,
localnetworks,
named.boot,
netmasks,
networks,
nodename,
nsswitch.conf,
protocols,
rc,
rc.conf, rc.local,
resolv.conf, and
services.
You won't find all of these on a single system. Each version
and release will have its own conventions. For example, Solaris puts
the host's name in
nodename.
[7]
With BSD, it is set in
rc.conf. Customizations
may change these as well. Thus, the locations and names of files will
vary from system to system.
One starting point might be to scan all the files in
/etc and its subdirectories, trying to identify
which ones are relevant. In the long run, you may want to know the
role of all the files in
/etc, but you
don't need to do this all at once.
There are a few files or groups of files
that will be of particular interest. One of the most important is
inetd.conf. While we can piece together what is
probably being handled by
inetd by using
ps in combination with
netstat, an examination of
inetd.conf is usually much quicker and safer. On
an unfamiliar system, this is one of the first places you will want
to look. Be sure to compare this to the output provided by
netstat. Services that you can't match to
running processes or
inetd are a cause for
concern.
You will also want to examine files like
host.conf,
resolv.conf, and
nsswitch.conf to discover how name resolution is
done. Be sure to examine files that establish trust relationships
like
hosts.allow. This is absolutely essential
if you are having, or want to avoid, security problems. (There is
more on some of these files in the discussion of
tcpwrappers in
Chapter 11, "Miscellaneous Tools".)
Finally, there is one group of these files, the
rc files, that deserve particular attention.
These are discussed separately in the later section on startup files
and scripts.
2.2.3. Kernel
It's natural to assume
that examining the kernel's configuration might be an important
first step. But while it may, in fact, be essential in resolving some
key issues, in general, it is usually not the most productive place
to look. You may want to postpone this until it seems absolutely
necessary or you have lots of free time.
As you know, the first step in starting a system is loading and
initializing the kernel. Network services rely on the kernel being
configured correctly. Some services will be available only if first
enabled in the kernel. While examining the kernel's
configuration won't tell you which services are actually being
used, it can give some insight into what is not available. For
example, if the kernel is not configured to forward IP packets, then
clearly the system is not being used as a router, even if it has
multiple interfaces. On the other hand, it doesn't immediately
follow that a system is configured as a firewall just because the
kernel has been compiled to support filtering.
Changes to the kernel will
usually be required only when building a new system, installing a new
service or new hardware, or tuning system performance. Changing the
kernel will not normally be needed to simply discover how a system is
configured. However, changes may be required to use some of the tools
described later in this book. For example, some versions of FreeBSD
have not, by default, enabled the Berkeley packet filter
pseudodriver. Thus, it is necessary to recompile the kernel to enable
this before some packet capture software, such as
tcpdump, can be run on these systems.
To recompile a kernel, you'll
need to consult the documentation for your operating system for the
specifics. Usually, recompiling a kernel first requires editing
configuration files. This may be done manually or with the aid of a
utility created for this task. For example, with Linux, the command
make config runs an interactive program that
sets appropriate parameters.
[8]
BSD uses a program called
config. If you can
locate the configuration files used, you can see how the kernel was
configured. But, if the kernel has been rebuilt a number of times
without following a consistent naming scheme, this can be
surprisingly difficult.
As an example, on BSD-derived systems,
the kernel configuration files are usually found in the directory
/sys/arch/conf/kernelwhere
arch corresponds to the
architecture of the system and
kernel is
the name of the kernel. With FreeBSD, the file might be
/sys/i386/conf/GENERIC if the kernel has not
been recompiled. In Linux, the configuration file is
.config in whatever directory the kernel was
unpacked in, usually
/usr/src/linux/.
As you might expect, lines beginning with a
# are
comments. What you'll probably want to look for are lines
specifying unusual options. For example, it is not difficult to guess
that the following lines from a FreeBSD system indicate that the
machine may be used as a firewall:
...
# Firewall options
options IPFIREWALL
options IPFIREWALL_VERBOSE_LIMIT=25
...
Some entries can be pretty cryptic, but hopefully there are some
comments. The Unix manpages for a system may describe some options.
Unfortunately, there is very little
consistency from one version of Unix to the next on how such files
are named, where they are located, what information they may contain,
or how they are used. For example, Solaris uses the file
/etc/system to hold some directives, although
there is little of interest in this file for our purposes. IRIX keeps
its files in the
/var/sysgen/system directory.
For Linux, take a look at
/etc/conf.modules. The
list goes on.
[9]
It is usually possible to
examine or change selected system parameters for an existing kernel.
For example, Solaris has the utilities
sysdef,
prtconf, and
ndd. For our
purposes,
ndd is the most interesting and should
provide the flavor of how such utilities work.
Specifically,
ndd allows you to get or set driver
configuration parameters. You will probably want to begin by listing
configurable options. Specifying the driver (i.e.,
/dev/arp,
/dev/icmp,
/dev/ip,
/dev/tcp, and
/dev/udp) with the
? option
will return the parameters available for that driver. Here is an
example:
sol1# ndd /dev/arp ?
? (read only)
arp_cache_report (read only)
arp_debug (read and write)
arp_cleanup_interval (read and write)
This shows three parameters that can
be examined, although only two can be changed. We can examine an
individual parameter by using its name as an argument. For example,
we can retrieve the ARP table as shown here:
sol1# ndd /dev/arp arp_cache_report
ifname proto addr proto mask hardware addr flags
elxl0 205.153.060.053 255.255.255.255 00:e0:29:21:3c:0b
elxl0 205.153.060.055 255.255.255.255 00:90:27:43:72:70
elxl0 205.153.060.001 255.255.255.255 00:00:a2:c6:0e:42
elxl0 205.153.060.005 255.255.255.255 00:90:27:9c:2d:c6
elxl0 205.153.060.248 255.255.255.255 00:60:97:58:71:b7 PERM PUBLISH MYADDR
elxl0 205.153.060.150 255.255.255.255 00:c0:05:04:2d:78
elxl0 224.000.000.000 240.000.000.000 01:00:5e:00:00:00 PERM MAPPING
In this instance, it is
fairly easy to guess the meaning of what's returned. (This
output is for the same ARP table that we looked at with the
arp command.) Sometimes, what's returned
can be quite cryptic. This example returns the value of the IP
forwarding parameter:
# ndd /dev/ip ip_forwarding
0
It is far from obvious how to interpret this result. In fact,
0 means never forward,
1 means
always forward, and
2 means forward only when two
or more interfaces are up. I've never been able to locate a
definitive source for this sort of information, although a number of
the options are described in an appendix to W. Richard Stevens'
TCP/IP Illustrated, vol. 1. If you want to
change parameters, you can invoke the program interactively.
Other versions of Unix will have
their own files and utilities. For example, BSD has the
sysctl command. This example shows that IP
forwarding is disabled:
bsd1# sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0
The manpages
provide additional guidance, but to know what to change, you may have
to delve into the source code. With AIX, there is the
no utility. As I have said before, the list goes
on.
This brief description should give you a general idea of what's
involved in gleaning information about the kernel, but you will want
to go to the appropriate documentation for your system. It should be
clear that it takes a fair degree of experience to extract this kind
of information. Occasionally, there is a bit of information that can
be obtained only this way, but, in general, this is not the most
profitable place to start.
One last comment -- if you are intent
on examining the behavior of the kernel, you will almost certainly
want to look at the messages it produces when booting. On most
systems, these can be retrieved with the
dmesg
command. These can be helpful in determining what network hardware
your system has and what drivers it uses. For hardware, however, I
generally prefer opening the case and looking inside. Accessing the
CMOS is another approach for discovering the hardware that
doesn't require opening the box.
2.2.4. Startup Files and Scripts
Once the kernel is loaded, the swapper
or scheduler is started and then the
init
process runs. This process will, in turn, run a number of startup
scripts that will start the various services and do additional
configuration chores.
After the standard configuration files, these are the next group of
files you might want to examine. These will primarily be scripts, but
may include configuration files read by the scripts. In general, it
is a bad idea to bury configuration parameters within these scripts,
but this is still done at times. You should also be prepared to read
fairly cryptic shell code. It is hoped that most of these will be
either in their pristine state, heavily commented, or both.
Look for three things when examining these
files. First, some networking parameters may be buried in these
files. You will not want to miss these. Next, there may be calls to
network configuration utilities such as
route or
ifconfig. These are frequently customizations,
so read these with a critical eye. Finally, networking applications
such as
sendmail may be started from these
files. I strongly urge that you create a list of all applications
that are run automatically at startup.
For
systems derived from BSD, you should look for files in
/etc beginning with
rc. Be
sure to look at
rc.conf and any
rc files with extensions indicating a networking
function of interest, e.g.,
rc.firewall. Realize
that many of these will be templates for services that you may not be
using. For example, if you see the file
rc.atm,
don't be too disappointed when you can't find your ATM
connection.
Unix systems can typically be booted in
one of several different states or run levels that determine which
services are started. For example, run level 1 is single-user mode
and is used for system maintenance. The services started by the
different run levels vary somewhat among the different flavors of
Unix. If your system is derived from System V, then the files will be
in a half dozen or so directories in
/etc. These
are named
rc1.d,
rc2.d, and
so forth. The digit indicates the run level of the system when
booted. Networking scripts are usually in
rc2.d.
In each directory, there will be scripts starting with an
S
or a
K and a two-digit number. The
rest of the name should give some indication of the function of the
file. Files with names beginning with an
S are
started in numerical order when the system is rebooted. When the
system shuts down, the files with
K are run.
(Some versions of Linux, such as Red Hat, follow this basic approach
but group these directories together in the
/etc/rc.d directory. Others, such as Debian,
follow the System V approach.)
WARNING:
There is one serious catch with all
this. When versions of operating systems change, sometimes the
locations of files change. For backward compatibility, links may be
created to old locations. For example, on recent versions of Solaris,
the network configuration file /etc/hosts is
actually a link to /etc/inet/hosts. There are
other important network configuration files that are really in
/etc/inet, not /etc.
Similarly, some of the startup scripts are really links to files in
/etc/init.d. If the link is somehow broken, you
may find yourself editing the wrong version of a file and wondering
why the system is ignoring your changes.
