Core System Services - Project 9-1 Enabling/Disabling the Telnet Service
(Page 4 of 5 )

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.

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.

 

Parameter	Description
-d	Debug mode. Normally, at startup, syslogd detaches itself from the current terminal and starts running in the background. With the -d option, syslogd retains control of the terminal and prints debugging information as messages are logged. It’s extremely unlikely that you’ll need this option.
-f config	Specifies a configuration file as an alternative to the default /etc/syslog.conf.
-h	By default, syslogd does not forward messages sent to it that were really destined for another host. Caution: If you use this parameter, you run the risk of being used as part of a denial-of-service attack.
-l hostlist	This option lets you list the hosts for which you are willing to perform logging. Each host name should be its simple name, not its fully qualified domain name (FQDN). You can list multiple hosts, as long as they are separated by a colon; for example, -l toybox:ford:oid.
-m interval	By default, syslogd generates a log entry every 20 minutes as a "just so you know, I’m running" message. This is for systems that may not be busy. (If you’re watching the system log and don’t see a single message in over 20 minutes, you’ll know for a fact that something has gone wrong.) By specifying a numeric value for interval, you can indicate the number of minutes syslogd should wait before generating another message.
-r	By default, as a security precaution, the syslogd daemon refuses messages sent to it from the network. This command-line parameter enables this feature.
-s domainlist	If you are receiving syslogd entries that show the entire FQDN, you can have syslogd strip off the domain name and leave just the host name. Simply list the domain names to remove in a colon-separated list as the parameter to the -s option. For example: -s x-files.com:conspiracy.com:wealthy.com

 

 

Table 9-3  syslogd Command-Line Parameters

Facility String Equivalent	Description
auth	Authentication messages.
authpriv	Essentially the same as auth.
cron	Messages generated by the cron Program," later in this module).	subsystem (see "Learn How to Use the cron

Table 9-4  Facility Values for syslogd

Facility String Equivalent		Description
daemon		Generic classification for service daemons.
kern		Kernel messages.
lpr		Printer subsystem messages.
mail		Mail subsystem messages (including per mail logs).
mark		Obsolete, but you may find some books that discuss it; syslogd simply ignores it.
news		Messages through the NNTP subsystem.
security		Same thing as auth; should not be used.
syslog		Internal messages from syslog itself.
user		Generic messages from user programs.
uucp		Messages from the UUCP (UNIX to UNIX copy) subsystem.
local0 -	local9	Generic facility levels whose importance can be decided based on your needs.

Table 9-4  Facility Values for syslogd (continued)

Priority String Equivalent	Description
debug	Debugging statements.
info	Miscellaneous information.
notice	Important statements, but not necessarily bad news.
warning	Potentially dangerous situation.
warn	Same as warning; should not be used.
err	An error condition.
error	Same as err; should not be used.
crit	Critical situation.
alert	A message indicating an important occurrence.
emerg	An emergency situation.

Table 9-5  Priority Values for syslogd

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.

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

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.

Location Style	Description
/var/log/logfile	A file.
	Note: If you prefix the filename with a dash, syslogd will not synchronize
	the file system after the write. This means you run the risk of losing some data
	if there is a crash before the system gets a chance to flush its buffers. On the
	other hand, if an application is being overly verbose about its logging, you’ll
	gain performance using this option.
	Remember: If you want messages sent to the console, you need to specify
	/dev/console.

Table 9-6  Examples of Location Entries

Location Style	Description
|/tmp/mypipe	A pipe. This type of file is created with the mknod command. With syslogd
	feeding one side of the pipe, you can have another program running that reads
	the other side of the pipe. This is an effective way to have programs parsing log
	output, looking for critical situations, so that you can be paged if necessary.
@loghost	A host name. This example will send the message to loghost. The syslogd
	daemon on loghost will then record the message.

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

Sample /etc/syslog.conf File

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

Next: CRITICAL SKILL 9.4 Learn How to Use the cron Program >>
 

More Administration Articles
More By McGraw-Hill/Osborne

Comments On: Core System Services

· This article is an excerpt from the book "Linux Administration A Beginner's Guide,...   >>> Post your comment now!

Buy this book...

This article is excerpted from chapter nine of Linux Administration A Beginner's Guide, Third Edition, written by Steven Graham and Steven Shah (McGraw-Hill/Osborne, 2004; ISBN: 0072225629). Check it out at your favorite bookstore. Buy this book now.