Application files Security files Log files

31 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, dont be too disappointed when you cant 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 etcrc.d directory. Others, such as Debian, follow the System V approach. 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 etchosts is actually a link to etcinethosts. There are other important network configuration files that are really in etcinet, not etc. Similarly, some of the startup scripts are really links to files in etcinit.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.

2.2.5 Other Files

There are several other categories of files that are worth mentioning briefly. If you have been following the steps just described, you will already have found most of these, but it may be worth mentioning them separately just in case you have overlooked something.

2.2.5.1 Application files

TE AM FL Y Team-Fly ® 32 Once you have your list of applications that are started automatically, investigate how each application is configured. When it comes to configuration files, each application will follow its own conventions. The files may be grouped together, reside in a couple of directories, or have some distributed structure that spans a number of directories. For example, sendmail usually keeps configuration files together, usually in etc or in etcmail. DNS may have a couple of files in etc to get things started, with the database files grouped together somewhere else. A web server like apache may have an extensive set of files distributed across a number of directories, particularly if you consider content. But beware, your particular implementation may vary from the norm—in that case, all bets are off. You will need to look for these on an application-by-application and a system-by-system basis.

2.2.5.2 Security files

It is likely you will have already discovered relevant security files at this point, but if you are having problems, this is something worth revisiting. There are several different categories to consider: Trust relationships Some files such as etchosts.equiv set up trust relationships with other computers. You will definitely want to review these. Keep in mind that users can establish their own trust relationships, so dont forget the .rhost file in home directories if you are having problems tied to specific users. Traffic control A number of files may be tied to general access or the control of traffic. These include configuration files for applications like tcpwrappers or firewall configuration files. Application specific Dont forget that individual applications may have security files as well. For example, the file etcftpusers may be used by ftp to restrict access. These are very easy to overlook.

2.2.5.3 Log files

One last category of files you might want to consider is log files. Strictly speaking, these are not configuration files. Apart from an occasional startup message, these may not tell you very much about your systems configuration. But occasionally, these will provide the missing puzzle piece for resolving a problem. Log files are described in much greater detail in Chapter 11 .

2.3 Microsoft Windows