Home arrow Site Administration arrow Page 4 - Core System Services

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

Every Linux system has five core services which perform fundamental functions. This article discusses each of these services. It 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).

  1. Core System Services
  2. CRITICAL SKILL 9.2 Learn the inetd and xinetd Processes
  3. Variables and Their Meanings
  4. Project 9-1 Enabling/Disabling the Telnet Service
  5. CRITICAL SKILL 9.4 Learn How to Use the cron Program
By: McGraw-Hill/Osborne
Rating: starstarstarstarstar / 10
October 13, 2005

print this article



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.





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.


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.


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



Authentication messages.


Essentially the same as auth.


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



Generic classification for service daemons.


Kernel messages.


Printer subsystem messages.


Mail subsystem messages (including per mail logs).


Obsolete, but you may find some books that discuss it; syslogd simply ignores it.


Messages through the NNTP subsystem.


Same thing as auth; should not be used.


Internal messages from syslog itself.


Generic messages from user programs.


Messages from the UUCP (UNIX to UNIX copy) subsystem.

local0 -


Generic facility levels whose importance can be decided based on your needs.

Table 9-4  Facility Values for syslogd (continued)

Priority String Equivalent



Debugging statements.


Miscellaneous information.


Important statements, but not necessarily bad news.


Potentially dangerous situation.


Same as warning; should not be used.


An error condition.


Same as err; should not be used.


Critical situation.


A message indicating an important occurrence.


An emergency situation.

Table 9-5  Priority Values for syslogd


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



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



Table 9-6  Examples of Location Entries

Location Style



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.


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

>>> More Site Administration Articles          >>> More By McGraw-Hill/Osborne

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Coding: Not Just for Developers
- To Support or Not Support IE?
- Administration: Networking OSX and Win 7
- DotNetNuke Gets Social
- Integrating MailChimp with Joomla: Creating ...
- Integrating MailChimp with Joomla: List Mana...
- Integrating MailChimp with Joomla: Building ...
- Integrating MailChimp with Joomla
- More Top WordPress Plugins for Social Media
- Optimizing Security: SSH Public Key Authenti...
- Patches and Rejects in Software Configuratio...
- Configuring a CVS Server
- Managing Code and Teams for Cross-Platform S...
- Software Configuration Management
- Back Up a Joomla Site with Akeeba Backup

Developer Shed Affiliates


Dev Shed Tutorial Topics: