51 Displaying Which Services Are Enabled
#51 Displaying Which Services Are Enabled
The first generation of Unix systems had a variety of system daemons, each of which listened to a specific port and responded to queries for a specific protocol. If you had a half-dozen services, you'd have a half- dozen daemons running. As Unix capabilities expanded, however, this wasn't a sustainable model, and an ¼berdaemon called inetd was developed. The inetd service can listen to a wide range of different channels simultaneously , launching the appropriate daemon to handle each request as needed. Instead of having dozens of daemons running, it has only one, which spawns service-specific daemons as needed. In more recent years , a new, more sophisticated successor of inetd has become popular, called xinetd .
While the original inetd service has a single configuration file ( /etc/ inetd.conf ) that a sysadmin can easily scan to discover which services are on and which are off, xinetd works with a directory of configuration files, one per service. This makes it quite difficult to ascertain which services are on and which are off, unless a script is utilized. A typical xinetd configuration file looks like this:
$ cat /etc/xinetd.d/ftp service ftp { disable = yes socket_type = stream wait = no user = root server = /usr/libexec/ftpd server_args = -l groups = yes flags = REUSE } The most important line in this configuration file contains the value of disable . If it's set to yes , the service is not enabled on the system, and if it's set to no , the service is available and configured as indicated in the file.
This particular script checks for the configuration files of both inetd and xinetd and then displays all of the services that are enabled for the daemon that exists. This script also uses the ps command to check whether one of the daemons is in fact running.
The Code
#!/bin/sh # enabled - Checks whether inetd and xinetd are available on the system, # and shows which of their services are enabled. iconf="/etc/inetd.conf" xconf="/etc/xinetd.conf" xdir="/etc/xinetd.d" if [ -r $iconf ] ; then echo "Services enabled in $iconf are:" grep -v '^#' $iconf awk '{print " " }' echo "" if [ "$(ps -aux grep inetd egrep -vE '(xinetgrep)')" = "" ] ; then echo "** warning: inetd does not appear to be running" fi fi if [ -r $xconf ] ; then # Don't need to look in xinietd.conf, just know it exists echo "Services enabled in $xdir are:" for service in $xdir/* do if ! $(grep disable $service grep 'yes' > /dev/null) ; then echo -n " " basename $service fi done if ! $(ps -aux grep xinetd grep -v 'grep' > /dev/null) ; then echo "** warning: xinetd does not appear to be running" fi fi exit 0 How It Works
Examination of the script will show that the for loop in the second section makes it easy to step through xinetd configuration files to see which have disable set to no . Any of those must therefore be enabled and are worth reporting to the user.
Running the Code
This script has no arguments and should be run as root to ensure that permission is available to examine the administrative directories within /etc .
The Results
$ enabled Services enabled in /etc/xinetd.d are: echo rsync sgi_fam time
Hacking the Script
Most systems have the /etc/xinetd.d files as world-readable, but you don't want these files writable by anyone other than their owner ( otherwise , a malicious user could redefine the server binary to one that offered a back door into the system). The following logic to ensure that the configuration files are not world-writable would be a useful addition to the script:
if ! $(ls -l $service cut -c4-9 grep 'w' > /dev/null) ; then echo "Warning: Service configuration file $service is world-writable." fi
To sidestep security problems and other errors, you could also refine the script by having it check the permissions and existence of all server binaries.
