|
UNIX Hints & Hacks |
 |
||||||||||||||||||||||||||||||||||||
|
Chapter 1: Topics in Administration |
|
||||||||||||||||||||||||||||||||||||
|
Tune your system more by disabling all unwanted and unused daemons from running on the system. This can be done by editing the /etc/inetd.conf file and the rc files or directories.
Flavors: AT&T, BSD
Modify the /etc/inetd.conf file and disable unnecessary daemons running on the system.
# vi /etc/inetd.conf
# # Configuration file for inetd(1M). See inetd.conf(4). # # To re-configure the running inetd process, edit this file, then # send the inetd process a SIGHUP. kill -HUP [PID] # #ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd -l #telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd #talk dgram udp wait root /usr/sbin/in.talkd in.talkd #ntalk dgram udp wait root /usr/sbin/in.ntalkd in.ntalkd #uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd # #finger stream tcp nowait nobody /usr/sbin/in.fingerd in.fingerd #tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd #bootps dgram udp wait root /usr/sbin/in.bootpd in.bootpd #talk dgram udp wait root /usr/sbin/tcpd in.talkd
After the /etc/inetd.conf file has been modified and daemons have been disabled, find the process ID (PID) of the inetd daemon that is running and restart it with the kill -HUP command.
Flavor: AT&T
# ps -ef | grep inetd root 124 1 ? S 30:57 /usr/sbin/inetd -s ugu 10377 10378 pts/4 S 0:00 grep inetd # kill -HUP 124
Flavor: BSD
# ps -ax | grep inetd 124 ? S 30:57 /usr/sbin/inetd -s 10377 pts/4 S 0:00 grep inetd # kill -HUP 124
If accounting is turned on you can check the system log files (/var/adm/messages or /var/adm/SYSLOG) to verify the inetd daemon had restarted. If you check the process table again, you'll see that the PID never changed. It isn't suppose to. A kill -HUP does not kill the process, it actually sends a hang-up signal. Many daemons, such as the inetd daemon, will catch the signal and reread its configuration file and continue running.
If the process didn't restart and you can still connect to the daemons, it is not advisable but it is possible to kill the inetd daemon and restart it manually. It should be done in one single command line, if possible:
# kill 124; /usr/etc/inetd
Then check the process table ( ps -ef or ps -ax ) to verify that the daemon is running. This time it will have a new PID.
Flavors: BSD
Another area that starts daemons controlled by the system or applications is the rc files and directories. Depending on the flavor, the startup area can be in the form of rc files, or a series of files in an rc.# directory. The rc files or files within the rc.# directories are scripts that perform filesystem housekeeping and startup system daemons that together bring up the UNIX operating system.
This is a very dangerous area. It is wise to know exactly what you are attempting to disable before you actually do. If a daemon or process is kept from executing from this area, you can inadvertently hang at boot time or keep the system from coming up. If this happened and you couldn't even boot to an init state of single user, you would be forced to boot miniroot off of disks or CD-ROM. It is highly recommended that a backup is made of any rc files before they are modified.
After changes are made to the necessary rc files, a reboot is necessary to verify that the changes will take affect. Some administrators will kill the processes associated with the daemons in the rc files, wait a few hours, and reboot when the user takes a lunch or goes home at the end of the day. This is okay, as long as you don't forget!
Many times have I seen a case where an administrator gets caught up in another issue and forgets about the modifications he made to the rc files and directories. What happens next? You can see it coming. A few days or a week later, for some reason or another, the system reboots or crashes. Now when the system begins its boot-up process, by some dumb luck your untested changes from before don't let the system come up. You created a new problem to add to your list of open issues. What's worse is that you're not around and your backup administrator has to deal with the problem not knowing the changes you made.
When computers arrive from the manufacturer, in most cases, they are fully loaded and turned on with everything they can give you. If you rebuild the system from scratch, the default installation will, in most cases, install more software than you actually need on your system. Because there are more systems than administrators in the world, the manufacturers want to make it as easy for the user as possible. So they give the user almost everything.
The two main reasons you want to make these changes are security and performance. Disabling the unwanted daemons locks down any possible holes, provides one fewer system function for you to administer, and allows more space in memory and less CPU time to eat up unnecessary processes.
If you have no plans on using the services, disable them. Each system will have to be judged on an individual basis. High-risk, secure, stand-alone systems do not need to accept requests from tftp, talkd, or fingerd, and they might never need to accept ftp or even telnet. Disable them. Users on standalone systems that are not even on a network or isolated should disable bind, YP/NIS, bootpd, sendmail, routed, and other networking services; they are not necessary.
In a perfect world programmers and engineers will not try to compile locally on file servers and suck up all the CPU time. Disabling telnetd, rshd, and rlogind is the only way to prevent them from doing this. The disadvantage is that administration of the system could only be done locally. But you all make sacrifices. Similar things have been done for security reasons on firewall systems. You will find that much more then these are disabled on a firewall system.
Man pages
inetd, inetd.conf, rc
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||||||||||||
|
Chapter 1: Topics in Administration |
|
||||||||||||||||||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.