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
keytable 0: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 sendmail will start with a regular startup at runlevel 3 or 5.
Let's change it so that sendmail doesn't startup 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 run
levels 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
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 run levels 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
By not specifying the runlevels with the --level switch,
chckconfig will make the changes for runlevels 3 and 5 automatically:
[root@bigboy tmp]# chkconfig sendmail off
Because the intention is to permanently shutdown 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 ]
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
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 ]
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 below 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:*
...
...
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
[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]# 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 root]# lsof -i udp:123
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
ntpd 1321 ntp 4u IPv4 3390 UDP *:ntp
...
...
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
...
...
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 shutdown nfs, nfslock, netfs, portmap, and cups
printing as standard practice on Internet servers.
Remember to thoroughly 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 post.
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.
0 comments:
Post a Comment