Project 9-1 Enabling/Disabling the Telnet Service - Administration

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

1. Edit the file /etc/xinetd.d/telnet and change the parameter disable to yes:
   
   # default: on
   # description: The telnet server serves telnet sessions; it uses \
   #       unencrypted username/password pairs for authentication.
   service telnet
   {
           flags        = REUSE
           socket_type  = stream
           wait         = no
           user         = root
           server   = /usr/sbin/in.telnetd
           log_on_failure += USERID  
           disable      = yes
   }
   
2.  Restart the xinetd server. 
   
3. Telnet to the box and see if the Telnet service is indeed down.

Project Summary

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.

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 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.

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.

NOTE

The priority levels are in the order of severity according to syslogd. Thus debug is not considered severe at all, and emerg is the most crucial. For example, the combination facility-and-priority string mail.crit indicates there is a critical error in the mail subsystem (for example, it has run out of disk space). syslogd considers this message more important than mail.info, which may simply note the arrival of another message.

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.

Here is the format of each line in the configuration file:

facility/priority combinations separated by commas   file/process/host to log to

For example:

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:

• If the location begins with a slash (/), the message is going to a file.
  
• If the location begins with a pipe ( | ), the message is going to a FIFO.
  
• If the location begins with an @, the message is going to a host.

Table 9-6 shows examples of location entries according to these rules.

Table 9-6  Examples of Location Entries

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
# machine.
*.emerg      @loghost,sshah,hdc,root

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/messages

Following is a complete syslog.conf file:

# Log all kernel messages to the console.
# Logging much else clutters up the screen. #kern.*                     /dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages! *.info;mail.none;authpriv.none /var/log/messages # The authpriv file has restricted access. authpriv.*                  /var/log/secure
# Log all the mail messages in one place. mail.*                      /var/log/maillog
# Everybody gets emergency messages, plus log them on another
# machine.
*.emerg                     *
# Save mail and news errors of level err and higher in a
# special file. uucp,news.crit             /var/log/spooler
# Save boot messages also to boot.log local7.*                   /var/log/boot.log