This project walks you through the process of disabling services that are run through the inetd/xinetd daemon. If you want a secure system, chances are you will run with very few servicesóI know some people who donít even run xinetd at all! I typically will enable a service so I can do some quick maintenance, like compile SSH, then disable the insecure service. It takes three steps to disable a service: disable the service in the inetd/xinetd configuration file, restart the inetd/xinetd service, and finally test to make sure the service is indeed down. To enable a service is just the opposite procedure.
Step by Step
This project walked you through disabling a service with the xinetd configuration files. If you need to create another service to run under xinetd, just copy an existing one to a new filename and modify it for your needs. The process is simple to enable or disable a service. It is just a matter of testing and making sure that the services is either disabled or enabled. You donít want to think that you have disabled Telnet and have it still be running.
CRITICAL SKILL 9.3 Gain Knowledge of the syslogd Daemon
With so much going on at any one time, especially with services that are disconnected from a terminal window, itís necessary to provide a standard mechanism by which special events and messages can be logged. Linux uses the syslogd daemon to provide this service.
The syslogd daemon provides a standardized means of performing logging. Many other UNIXs employ a compatible daemon, thus providing a means for cross-platform logging over the network. This is especially valuable in a large heterogeneous environment where itís necessary to centralize the collection of log entries to gain an accurate picture of whatís going on. You could equate this system of logging facilities to the Windows NT System Logger.
The log files that syslogd stores to are straight text files, usually stored in the /var/log directory. Each log entry consists of a single line containing the date, time, host name, process name, PID, and the message from that process. A system-wide function in the standard C library provides an easy mechanism for generating log messages. If you donít feel like writing code but want to generate entries in the logs, you have the option of using the logger command.
As you can imagine, a tool with syslogdís importance is something that gets started as part of the boot scripts. Every Linux distribution you would use in a server environment will already do this for you.Invoke syslogd
If you do find a need to either start syslogd manually or modify the script that starts it up at boot, youíll need to be aware of syslogdís command-line parameters, shown in Table 9-3.The / etc/syslog.conf File
The /etc/syslog.conf file contains the configuration information that syslogd needs to run. This fileís format is a little unusual, but the default configuration file you have will probably suffice unless you begin needing to seek out specific information in specific files or sent to remote logging machines.Log Message Classifications
Before you can understand the /etc/syslog.conf file format itself, you have to understand how log messages get classified. Each message has a facility and a priority. The facility tells you from which subsystem the message originated, and the priority tells you how important the message is. These two values are separated by a period.
Both values have string equivalents, making them easier to remember. The string equivalents for facility and priority are listed in Tables 9-4 and 9-5, respectively.
Table 9-3 syslogd Command-Line Parameters
Table 9-4 Facility Values for syslogd
Table 9-4 Facility Values for syslogd (continued)
Table 9-5 Priority Values for syslogd
In addition to the following table of priority levels, syslogd also understands wildcards. Thus, you can define a whole class of messages; for instance, mail.* refers to all messages related to the mail subsystem.Format of /etc/syslog.conf
Here is the format of each line in the configuration file:
facility/priority combinations separated by commas file/process/host to log to
kern.info, kern.emerg /var/log/kerneld
The location to which syslogd can send log messages is also quite flexible. It can save messages to files and send messages to FIFOs, to a list of users, or (in the case of centralized logging for a large site) to a master log host. To differentiate these location elements, the following rules are applied to the location entry:
Table 9-6 Examples of Location Entries
Table 9-6 Examples of Location Entries (continued)
If you enter no special character before the location entry, syslogd assumes that the location is a comma-separated list of users who will have the message written to their screen.
If you use an asterisk (*), syslogd will send the message to all of the users who are logged in. As usual, any line that begins with a number symbol (#) is a comment.
Now letís look at some examples of configuration file entries:
# Log all the mail messages in one place. mail.* /var/log/maillog
This example shows that all priorities in the mail facility should have their messages placed in the /var/log/maillog file.
Consider the next example:
# Everybody gets emergency messages, plus log them on another
In this example, you see that any facility with a log level of emerg is sent to another system running syslogd called loghost. Also, if the user hdc, sshah, or root is logged in, the message being logged is written to the userís console.
You can also specify multiple selectors on a single line for a single event. For example:
*.info;mail.none;authpriv.none /var/log/messagesSample /etc/syslog.conf File
Following is a complete syslog.conf file:
# Log all kernel messages to the console.
blog comments powered by Disqus