28
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 dont
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 cant 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 .
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.2 Configuration Programs
Over the years, Unix has been heavily criticized because of its terse command-line interface. As a result, many GUI applications have been developed. System administration has not escaped this trend.
These utilities can be used to display as well as change system configurations.
Once again, every flavor of Unix will be different. With Solaris, admintool was the torchbearer for years. In recent years, this has been superseded with Solstice AdminSuite. With FreeBSD, select the
configure item from the menu presented when you run standsysinstall. With Linux you can use linuxconf. Both the menu and GUI versions of this program are common. The list goes on.
2.2.3 Kernel
Its natural to assume that examining the kernels 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 kernels configuration wont 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 doesnt 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.
29
To recompile a kernel, youll 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.
[4]
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.
[4]
You can also use make xconfig or make menuconfig. These are more interactive, allowing you to go back and change parameters once you have moved on. make config is unforgiving in this respect.
As an example, on BSD-derived systems, the kernel configuration files are usually found in the directory sys
arch
conf
kernel
where
arch
corresponds to the architecture of the system and
kernel
is the name of the kernel. With FreeBSD, the file might be sysi386confGENERIC if the kernel has not been recompiled. In Linux, the configuration file is .config in whatever directory the
kernel was unpacked in, usually usrsrclinux. As you might expect, lines beginning with a
are comments. What youll 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 etcsystem to hold some directives, although there is little of interest in this file for our purposes. IRIX keeps its files in the varsysgensystem directory. For Linux, take a
look at etcconf.modules. The list goes on.
[5] [5]
While general configuration parameters should be in a single file, a huge number of files are actually involved. If you have access to FreeBSD, you might look at sysconffiles to get some idea of this. This
is a list of the files FreeBSD uses.
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., devarp, devicmp, devip, devtcp,
and devudp with the ? option will return the parameters available for that driver. Here is an example:
sol1 ndd devarp ? ? read only
arp_cache_report read only arp_debug read and write
arp_cleanup_interval read and write
30
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 devarp 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 whats returned. This output is for the same ARP table that we looked at with the arp command. Sometimes, whats returned can be quite cryptic.
This example returns the value of the IP forwarding parameter:
ndd devip ip_forwarding
It is far from obvious how to interpret this result. In fact, means never forward,
1
means always forward, and
2
means forward only when two or more interfaces are up. Ive 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 TCPIP 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 whats 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 doesnt require opening the box.
2.2.4 Startup Files and Scripts
