Red Hat administration: Starting up network services from xinetd

278

Author: Terry Collings and Kurt Wall

xinetd is started on bootup, and listens on ports designated in /etc/xinetd.conf for incoming network connections. When a new connection is made, xinetd starts up the corresponding network service.

This article is excerpted from the recently published book Red Hat Linux Networking and System Administration, 2nd Edition.

You should disable any unnecessary services from being started from xinetd as part of securing your machine. The way to do this is to edit that service’s configuration file. xinetd‘s main configuration file is /etc/xinetd.conf. At the end of the xinetd.conf file is a line that indicates that all the files in the /etc/xinetd.d are also included in the configuration. This means that you need to go through the files in that directory as well in order to turn off any services you don’t want.

So, to disable telnet, you would look in /etc/xinetd.d for a file called telnet. The contents of the telnet file is shown in the listing below. Edit the line in the config file that says disable = no and change it to disable = yes, as it appears below. Once the line is set to disable = yes, the service is disabled and does not start up the next time you boot.

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

An automated tool called chkconfig manages what services are started from xinetd and the rc scripts. Network services that are not started out of xinetd are started out of the rc scripts at boot time. Network services started at the default boot level 3 (multiuser networked mode) are started out of the /etc/rc3.d directory. If you look in that directory, you should see a file with the name of the service you want to stop or start. The script to start the service starts with an S, and the kill script starts with a K.

So for example, ssh is started from /etc/rc3.d /S55sshd, and killed upon shutdown from /etc/rc6.d/K25sshd. Runlevel 6 is the shutdown level, so that’s why its kill script is located in the rc6.d directory.

Other important network configuration files in the /etc/sysconfig directory

You can use the files listed in this section to create routes to other hosts, either on your own network or on outside networks. You also can use these files to set up firewall rules for your network to either allow or disallow connections to your network.

Static routes

If you want to set up some static routes on your machine, you can do so in the static-routes file. This config file has lines that follow the format of:

network-interface net network netmask netmask gw gateway

iptables

iptables is the next-generation Linux firewall. It supersedes the ipchains firewall. It can use ipchains rules as a component of its firewall filtering, but iptables and ipchains cannot be run at the same time.

This is the file where the iptables rules are stored. iptables syntax is very similar to the ipchains syntax, which is briefly explained by the following example.

ipchains

ipchains is a Linux firewall that is now being superseded by iptables. The GUI interface that configures the ipchains firewall rules is firewall-config. The ipchains rules are stored in the ipchains file.

When you install Red Hat, it asks if you would like to set up a host-based firewall. If you select a medium or heavy security host-based firewall, a default set of iptables rules installs according to your preferences.

The following is a simplified configuration file. The gist of this configuration is that all incoming traffic to privileged ports (those below 1024) is dropped except for ssh traffic. The first line accepts all traffic from the loopback interface. The second line accepts all incoming TCP traffic to the ssh port. The third line drops all incoming TCP traffic to ports between 1 and 1024. The last line drops all incoming UDP traffic to ports between 1 and 1024.

-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 22 -p tcp -j ACCEPT
-A INPUT -p tcp -s ! 192.168.1.0/24 --dport 1:1024 -j DROP
-A INPUT -p udp -s ! 192.168.1.0/24 --dport 1:1024 -j DROP

Network configuration files in /etc/sysconfig/network-scripts

You can use the files in this directory to set the parameters for the hardware and software used for networking. The scripts contained here are used to enable network interfaces and set other network related parameters.

ifcfg-networkinterfacename

A few files fall into this specification. Red Hat specifies a separate configuration file for each network interface. In a typical Red Hat install you might have many different network interface config files that all follow the same basic syntax and format.

You could have ifcfg-eth0 for your first Ethernet interface, ifcfg-irlan0 for your infrared network port, ifcfg-lo for the network loop-back interface, and ifcfg-ppp0 for your PPP network interface.

ifup and ifdown

These files are symlinks to /sbin/ifup and /sbin/ifdown. In future releases, these symlinks might be phased out. But for now, these scripts are called when the network service is started or stopped. In turn, ifup and ifdown call any other necessary scripts from within the network-scripts directory. These should be the only scripts you call from this directory.

You call these scripts with the name of the interface that you want to bring up or down. If these scripts are called at boot time, then “boot” is used as the second argument. For instance, to bring your Ethernet interface down and then up again after boot, you would type:

ifup eth0
ifdown eth0

Managing the init scripts

Init scripts determine what programs start up at boot time. Red Hat and other Unix distributions have different runlevels, so a different set of programs is started at each runlevel.

Usually Red Hat Linux starts up in multiuser mode with networking turned on. These are some of the other runlevels available:

  1. Halt
  2. Single-user mode
  3. Multiuser mode, without networking
  4. Full multiuser mode
  5. Not used
  6. Full multiuser mode (with an X-based login screen)
  7. Reboot

The system boots into the default runlevel set in /etc/inittab (see listing below). In Red Hat Linux, the default boot level is 3. When booting into an X Windows login, the default boot level is 5.

#
# inittab       This file describes how the INIT process should set up
#               the system in a certain run-level.
#
# Author:       Miquel van Smoorenburg, 
#               Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

# Default runlevel. The runlevels used by RHS are:
#   0 - halt (Do NOT set initdefault to this)
#   1 - Single user mode
#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
#   3 - Full multiuser mode
#   4 - unused
#   5 - X11
#   6 - reboot (Do NOT set initdefault to this)
#
id:5:initdefault:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

# Things to run in every runlevel.
ud::once:/sbin/update

# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left.  Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon

Managing rc scripts by hand

If you want to configure what services are started at boot time, you need to edit the rc scripts for the appropriate runlevel. The default runlevel is 3, which is full multiuser mode. So to change what services are started in the default runlevel, you should edit the scripts found in /etc/rc3.d.

When you look at a directory listing of the rc directories, notice that the files start with either S or K. The files that start with S are startup files, and the files that start with K are kill files. The S scripts are run in the numerical order listed in their filenames. If a startup script is set to S15, the K script should be K85 (or in general, SN becomes SM with M = 100 – n; the idea being the last started service is the first killed).

Note that case is important. Scripts that do not start with a capital S do not run upon startup. So one good way to keep scripts from starting up at boot time without deleting them is to rename the file with a small s at the beginning instead of a capital S. This way you can always put the script back into the startup configuration by capitalizing the initial letter.

When the system starts up, it runs through the scripts in the rc directory of the runlevel it’s starting up in. So when the system starts up in runlevel 3, it runs the scripts in the /etc/rc3.d directory.

Looking at the directory listing below, you can see that the first few services start in this order: kudzu, reconfig, iptables, and network. That is because their scripts are named S05kudzu, S06reconfig, S08iptables, and S10network, respectively.

Kudzu is called first because it detects new hardware. Reconfig runs to put into effect any changes made with the chkconfig tool. Iptables then starts up the built-in firewall. Network then brings up the system’s network interfaces. As you can see, the order in which these services are started makes a lot of sense, and their order is enforced by the way their rc startup scripts are named. All of the files in rc#.d are symboliclinks to /etc/init.d scripts and the names are used here only to affect what services start or stop and the ordering of those services. Editing the rc3.d/httpd file will affect rc5.d/httpd.

[root@buffy rc3.d]# ls
K05innd        K20rwhod      K50xinetd   K74ypserv    K92ipvsadm     S60lpd
K08vmware      K25squid      K54pxe      K74ypxfrd    K92upsd        S83iscsi
K09junkbuster  K28amd        K55routed   K75gated     K96irda        S90crond
K10fonttastic  K30mcserv     K61ldap     K75netfs     S05kudzu       S90xfs
K12mysqld      K30sendmail   K65identd   K84bgpd      S06reconfig    S91atalk
K15gpm         K34yppasswdd  K65kadmin   K84ospf6d    S08iptables	S95anacron
K15httpd       K35smb        K65kprop    K84ospfd     S10network     S97rhnsd
K15postgresql  K35vncserver  K65krb524   K84ripd      S12syslog      S99linuxconf
K16rarpd       K40mars-nwe   K65krb5kdc  K84ripngd    S17keytable    S99local
K20bootparamd  K45arpwatch   K73ypbind   K85zebra     S20random      S99wine
K20nfs         K45named      K74apmd     K86nfslock   S28autofs
K20rstatd      K46radvd      K74nscd     K87portmap   S40atd
K20rusersd     K50snmpd      K74ntpd     K91isdn      S55sshd
K20rwalld      K50tux        K74ups      K92ipchains  S56rawdevices
[root@buffy rc3.d]#

The S scripts are started in this order until they have all been started. When the system shuts down, the corresponding K, or kill scripts are run to shut down the services started from the rc directory. In general, every S script should have a corresponding K script to kill the service at shutdown.

If you can’t find the corresponding K script in the startup directory, it is probably located in the shutdown directory. When the system is shut down, it enters runlevel 6, so most of the K scripts are in /etc/rc6.d. A typical /etc/rc6.d directory listing looks like:

 [root@buffy rc6.d]# ls
K00linuxconf   K16rarpd       K34yppasswdd   K55routed   K74nscd    K85zebra
K03rhnsd       K20bootparamd  K35atalk       K60atd      K74ntpd    K86nfslock
K05anacron     K20iscsi       K35smb         K60crond    K74ups     K87portmap
K05innd        K20nfs         K35vncserver   K60lpd      K74ypserv  K88syslog
K05keytable    K20rstatd      K40mars-nwe    K61ldap     K74ypxfrd  K90network
K08vmware      K20rusersd     K44rawdevices  K65identd   K75gated   K91isdn
K09junkbuster  K20rwalld      K45arpwatch    K65kadmin   K75netfs   K92ipchains
K10wine        K20rwhod       K45named       K65kprop    K80random  K92ipvsadm
K10xfs         K25squid       K46radvd       K65krb524   K84bgpd    K95kudzu
K12mysqld      K25sshd        K50snmpd       K65krb5kdc  K84ospf6d  K95reconfig
K15gpm         K28amd         K50tux         K72autofs   K84ospfd   K96irda
K15httpd       K30mcserv      K50xinetd      K73ypbind   K84ripd    S00killall
K15postgresql  K30sendmail    K54pxe         K74apmd     K84ripngd  S01reboot

If you ever need to restart a service that’s started from an rc directory, an easy way to do it properly is to run its startup script with the restart option. This procedure enables all the proper steps to be followed (configuration files read, lock files released, and so forth) when the service starts up again. So to restart syslog, for example, run the following command from the rc directory:

[root@buffy rc3.d]# ./S12syslog restart
Shutting down kernel logger:                               [  OK  ]
Shutting down system logger:                               [  OK  ]
Starting system logger:                                    [  OK  ]
Starting kernel logger:                                    [  OK  ]

Managing rc scripts using chkconfig

Red Hat comes with a useful tool called chkconfig that helps the system administrator manage rc scripts and xinetd configuration files without having to manipulate them directly. It is inspired by the chkconfig command included in the IRIX operating system.

Type chkconfig --list to see all the services chkconfig knows about, and whether they are stopped or started in each runlevel. An abridged example output is shown in the following listing. The chkconfig output can be a lot longer than that listed here, so be prepared to pipe it through less or more.

The first column is the name of the installed service. The next seven columns each represent a runlevel, and tell you whether that service is turned on or off in that runlevel.

Since xinetd is started on the system whose chkconfig output is excerpted, at the end of chkconfig’s report is a listing of what xinetd-started services are configured to begin at boot time. The listing is abridged, since a lot of services can be started from xinetd and there’s no need to show all of them.

The listing below shows how chkconfig can be an effective tool for handling all your network services and controlling which ones get started up at boot time. This is the output of chkconfig --list:

atd             0:off   1:off   2:off   3:on    4:on    5:on    6:off
rwhod           0:off   1:off   2:off   3:off   4:off   5:off   6:off
keytable        0:off   1:on    2:on    3:on    4:on    5:on    6:off
nscd            0:off   1:off   2:off   3:off   4:off   5:off   6:off
syslog          0:off   1:off   2:on    3:on    4:on    5:on    6:off
gpm             0:off   1:off   2:on    3:off   4:off   5:off   6:off
kudzu           0:off   1:off   2:off   3:on    4:on    5:on    6:off
kdcrotate       0:off   1:off   2:off   3:off   4:off   5:off   6:off
lpd             0:off   1:off   2:on    3:on    4:on    5:on    6:off
autofs          0:off   1:off   2:off   3:on    4:on    5:on    6:off
sendmail        0:off   1:off   2:on    3:off   4:off   5:off   6:off
rhnsd           0:off   1:off   2:off   3:on    4:on    5:on    6:off
netfs           0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off
random          0:off   1:off   2:on    3:on    4:on    5:on    6:off
rawdevices      0:off   1:off   2:off   3:on    4:on    5:on    6:off
apmd            0:off   1:off   2:on    3:off   4:off   5:off   6:off
ipchains        0:off   1:off   2:off   3:off   4:off   5:off   6:off

-- snip --

xinetd based services:
        rexec:  off
        rlogin: off
        rsh:    off
        chargen:        off
        chargen-udp:    off
        daytime:        off
        daytime-udp:    off
        echo:   off
        echo-udp:       off
        time:   off
        time-udp:       off
        finger: off
        ntalk:  off
        talk:   off
        telnet: off
        wu-ftpd:        on
        rsync:  off
        eklogin:        off
        gssftp: off
        klogin: off

To turn a service off or on using chkconfig, use this syntax:

chkconfig -level[0-6](you must choose the runlevel) servicename off|on|reset

So to turn off the FTP daemon turned on previously, type:

chkconfig wu-ftpd off

To turn on xinetd, type:

chkconfig xinetd on

Run chkconfig --list again to see if the service you changed has been set to the state you desire. Changes you make with chkconfig take place the next time you boot the system. You can always start, stop, or restart a service by running serviceservicename from a terminal prompt.