How to Set Programs to Run at Each runlevel
As stated earlier, the chkconfig command can be used to adjust which applications start at each runlevel. You can use this command with the --list switch to get a full listing of packages listed in /etc/init.d and the runlevels at which they will be on or off:
[root@bigboy tmp]# chkconfig --list
keyFigure:off 1:on 2:on 3:on 4:on 5:on 6:off
atd 0:off 1:off 2:off 3:on 4:on 5:on 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:on 4:on 5:on 6:off
kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off
wlan 0:off 1:off 2:on 3:on 4:on 5:on 6:off
sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off
netfs 0:off 1:off 2:off 3:on 4:on 5:on 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
...
...
chkconfig Examples
You can use chkconfig to change runlevels for particular packages. Here we see that sendmail starts with a regular startup at runlevel 3 or 5. Let's change it so that sendmail doesn't start up at boot.
Use chkconfig to Get a Listing of sendmail's Current Startup Options
The chkconfig command can be used with grep to determine the runlevels in which sendmail will run. Here we see it will run at levels 3 and 5:
[root@bigboy tmp]# chkconfig --list | grep mail
sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off
[root@bigboy tmp]#
Switch Off sendmail Starting Up in Levels 3 and 5
The chkconfig command with the --level switch indicates that some action needs to be done at the runlevels entered as its values. The first argument in the command is the package you want to affect, and the second defines whether you want it on or off. In this case we want sendmail not to be started when entering runlevels 3 and 5:
[root@bigboy tmp]# chkconfig --level 35 sendmail off
[root@bigboy tmp]#
By not specifying the runlevels with the --level switch, chckconfig makes the changes for runlevels 3 and 5 automatically:
[root@bigboy tmp]# chkconfig sendmail off
Because the intention is to shut down sendmail permanently, we might also have to stop it from running now:
[root@bigboy tmp]# service sendmail stop
Shutting down sendmail: [ OK ]
Shutting down sm-client: [ OK ]
[root@bigboy tmp]#
Double-check that sendmail Will Not Start Up
We can then use chkconfig to double-check our work:
[root@bigboy tmp]# chkconfig --list | grep mail
sendmail 0:off 1:off 2:off 3:off 4:off 5:off 6:off
[root@bigboy tmp]#
Turn On sendmail Again
To reactivate sendmail, we can use chkconfig once more, but with the on argument. Start sendmail again to get it running immediately, not just after the next reboot.
[root@bigboy tmp]# chkconfig sendmail on
[root@bigboy tmp]# chkconfig --list | grep mail
sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off
[root@bigboy tmp]# service sendmail start
Starting sendmail: [ OK ]
Starting sm-client: [ OK ]
[root@bigboy tmp]#
Using chkconfig to Improve Security
A default Fedora installation automatically starts a number of daemons that you may not necessarily need for a Web server. This usually results in your system listening on a variety of unexpected TCP/IP ports that could be used as doors into your system by hackers.
The screen output of the netstat -an command shows a typical case. Some ports are relatively easy to recognize. TCP ports 25 and 22 are for mail and SSH, respectively, but some others are less obvious. Should you use the chkconfig command and the scripts in the /etc/init.d directory to shut these down permanently?
[root@bigboy tmp]# netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address
State
tcp 0 0 0.0.0.0:32768 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:32769 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 :::22 :::* LISTEN
udp 0 0 0.0.0.0:32768 0.0.0.0:*
udp 0 0 0.0.0.0:930 0.0.0.0:*
udp 0 0 0.0.0.0:68 0.0.0.0:*
udp 0 0 0.0.0.0:111 0.0.0.0:*
udp 0 0 0.0.0.0:631 0.0.0.0:*
...
...
[root@bigboy tmp]#
For example, how do you know which startup script is responsible for TCP port 111? The answer is to use the lsof command, which lists all open or actively used files and can be given additional options to extend its scope to include the TCP/IP protocol stack.
In the next examples, we see that TCP ports 111 and 32769, and UDP port 123 are being used by the portmap, xinetd, and ntp daemons, respectively. The portmap daemon is required for the operation of NFS and NIS, topics that are covered in Chapters 29, "Remote Disk Access with NFS," and 30, "Configuring NIS." portmap also has many known security flaws that makes it advisable to be run on a secured network. If you don't need any of these three applications, it's best to shut down portmap permanently. ntp, which is covered in Chapter 24, "The NTP Server," is required for synchronizing your time with a reliable time source and may be necessary. A number of network applications are reliant on xinetd, as explained in Chapter 16, "Telnet, TFTP, and XINETD," and it might be required for their operation:
[root@ bigboy tmp]# lsof -i tcp:111
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
portmap 1165 rpc 4u IPv4 2979 TCP *:sunrpc (LISTEN)
[root@ bigboy tmp #
[root@bigboy tmp]# lsof -i tcp:32769
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
xinetd 1522 root 5u IPv4 2764 TCP probe-001:32769
(LISTEN)
[root@bigboy tmp]#
[root@bigboy root]# lsof -i udp:123
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
ntpd 1321 ntp 4u IPv4 3390 UDP *:ntp
...
...
[root@bigboy root]#
In some cases it's tricky to determine the application based on the results of the lsof command. In the example below, we've discovered that TCP port 32768 is being used by rpc.statd, but there is no rpc.statd file in the /etc/init.d directory. The simple solution is to use the grep command to search all the files for the string rpc.statd to determine which one is responsible for its operation. We soon discover that the nfslock daemon uses it. If you don't need nfslock, then shut it down permanently:
[root@bigboy tmp]# lsof -i tcp:32768
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
rpc.statd 1178 rpcuser 6u IPv4 2400 TCP *:32768 (LISTEN)
[root@bigboy tmp]# ls /etc/init.d/rpc.statd
ls: /etc/init.d/rpc.statd: No such file or directory
[root@bigboy tmp]# grep -i statd /etc/init.d/*
/etc/init.d/nfslock:[ -x /sbin/rpc.statd ] || exit 0
...
...
[root@bigboy tmp]#
As a rule of thumb, applications listening only on the loopback interface (IP address 127.0.0.1) are usually the least susceptible to network attack and probably don't need to be stopped for network security reasons. Those listening on all interfaces, depicted as IP address 0.0.0.0, are naturally more vulnerable and their continued operation should be dependent on your server's needs. I usually shut down nfs, nfslock, netfs, portmap, and cups printing as standard practice on Internet servers. I keep sendmail running as it is always needed to send and receive mail (see Chapter 21, "Configuring Linux Mail Servers," for details). Your needs may be different.
Remember to research your options thoroughly before choosing to shut down an application. Use the Linux man pages, reference books, and the Internet for information. Unpredictable results are always undesirable.
Shutting down applications is only a part of server security. Firewalls, physical access restrictions, password policies, and patch updates need to be considered. Full coverage of server and network security is beyond the scope of this book, but you should always have a security reference guide on hand to guide your final decisions.
Final Tips on chkconfig
Remember the following:
In most cases, you want to modify runlevels 3 and 5 simultaneously and with the same values. Don't add/remove anything to other runlevels unless you absolutely know what you are doing. Don't experiment, unless in a test environment. chkconfig doesn't start the programs in the /etc/init.d directory, it just configures them to be started or ignored when the system boots up. The commands for starting and stopping the programs covered in this book are covered in each respective chapter.
 | 