Whole document tree
In this section we will see which services are running on our freshly installed system, decide which we really need, and do away with the rest. If you are not familiar with how servers and TCP connections work, you may want to read the section on servers and ports in the Appendix first. If not familiar with the netstat utility, you may want to read a quick overview of it beforehand. There is also a section in the Appendix on ports, and corresponding services. You may want to look that over too.
Our goal is to turn off as many services as possible. If we can turn them all off, or at least off to outside connections, so much the better. Some rules of thumb we will use to guide us:
So what is really running on our system anyway? Let's not take anything for granted about what "should" be running, or what we "think" is running.
Unfortunately, there is no such things as a standard Linux installation. The wide variety of servers available, coupled with each particular distribution's installation options, make providing a ready made list impossible. The best that can be done is show you how to list all running services, and point you in the right general direction.
Now open an xterm, and su to root. You'll need to widen the window wide so the lines do not wrap. Use this command: netstat -tap |grep LISTEN. This will give us a list of all currently running servers as indicated by the keyword LISTEN, along with the "PID" and "Program Name" that started each particular service.
Note the first three columns are cropped above for readability. If your list is as long as the example, you have some work ahead of you! It is highly unlikely that you really need anywhere near this number of servers running.
Please be aware that the example above is just one of many, many possible system configurations. Yours probably does look very different.
You don't understand what any of this is telling you? Hopefully then, you've read the netstat tutorial in the Appendix, and understand how it works. Understanding exactly what each server is in the above example, and what it does, is beyond the scope of this document. You will have to check your system's documentation (e.g. Installation Guide, man pages, etc) if that service is important to you. For example, does "exec", "login", and "shell" sound important? Yes, but these are not what they may sound like. They are actually rexec, rlogin, and rsh, the "r" (for remote) commands. These are antiquated, unnecessary, and in fact, are very dangerous if exposed to the Internet.
Let's make a few quick assumptions about what is necessary and unnecessary, and therefore what goes and what stays on bigcat. Since we are running a desktop on bigcat, X11 of course needs to stay. If bigcat were a dedicated server of some kind, then X11 would be unnecessary. If there is a printer physically attached, the printer (lp) daemon should stay. Otherwise, it goes. Print servers may sound harmless, but are potential targets too since they can hold ports open. If we plan on logging in to bigcat from other hosts, sshd (Secure SHell Daemon) would be necessary. If we have Microsoft hosts on our LAN, we probably want Samba, so smbd should stay. Otherwise, it is completely unnecessary. Everything else in this example is optional and not required for a normally functioning system, and should probably go. See anything that you don't recognize? Not sure about? It goes!
To sum up: since bigcat is a desktop with a printer attached, we will need "x11", "printer". bigcat is on a LAN with MS hosts, and shares files and printing with them, so "netbios-ssn" (smbd) is desired. We will also need "ssh" so we can login from other machines. Everything else is unnecessary for this particular case.
Nervous about this? If you want, you can make notes of any changes you make or save the list of servers you got from netstat, with this command: netstat -tap |grep LISTEN > ~/services.lst. That will save it your home directory with the name of "services.lst" for future reference.
This is to not say that the ones we have decided to keep are inherently safe. Just that we probably need these. So we will have to deal with these via firewalling or other means (addressed below).
It is worth noting that the telnet and ftp daemons in the above example are servers, aka "listeners". These accept incoming connections to you. You do not need, or want, these just to use ftp or telnet clients. For instance, you can download files from an FTP site with just an ftp client. Running an ftp server on your end is not required at all, and has serious security implications.
There may be individual situations where it is desirable to make exceptions to the conclusions reached above. See below.
The following is a list of services that should not be run over the Internet. Either disable these (see below), uninstall, or if you really do need these services running locally, make sure they are the current, patched versions and that they are effectively firewalled. And if you don't have a firewall in place now, turn them off until it is up and verified to be working properly. These are potentially insecure by their very nature, and as such are prime cracker targets.
This is not necessarily a definitive list. Just some common services that are sometimes started on default Linux installations. And conversely, this does not imply that other services are inherently safe.
The next step is to find where each server on our kill list is being started. If it is not obvious from the netstat output, use ps, find, grep or locate to find more information from the "Program name" or "PID" info in the last column. There is examples of this in the Process Owner section in the netstat Tutorial of the Appendix. If the service name or port number do not look familiar to you, you might get a real brief explanation in your /etc/services file.
Skeptical that we are going to break your system, and the pieces won't go back together again? If so, take this approach: turn off everything listed above in "The Danger Zone", and run your system for a while. OK? Try stopping one of the ones we found to be "unnecessary" above. Then, run the system for a while. Keep repeating this process, until you get to the bare minimum. If this works, then make the changes permanent (see below).
The ultimate objective is not just to stop the service now, but to make sure it is stopped permanently! So whatever steps you take here, be sure to check after your next reboot.
There are various places and ways to start system services. Let's look at the most common ways this is done, and is probably how your system works. System services are typically either started by "init" scripts, or by inetd (or its replacement xinetd) on most distributions. (The location of the init scripts may vary from distribution to distribution.)
Init services are typically started automatically during the boot process, or during a runlevel change. There is a naming scheme that uses symlinks to determine which services are to be started, or stopped, at any given runlevel. The scripts themselves should be in /etc/init.d/ (or possibly /etc/rc.d/init.d/ ). This init style is used by Red Hat, SuSE, Mandrake, Debian, Conectiva, and most Linuxes. Slackware is one notable exception (though recent versions have an option for this)! Typically on Slackware system services are all configured in one file: /etc/rc.d/rc.inet2.
You can get a listing of these scripts:
Or use whichever tools your distribution provides for this.
To stop a running service now, as root (on SysVinit style systems, which is pretty much everybody):
Where "$SERVICE_NAME" is the name of the init script, which is often, but not always, the same as the service name itself. This should do the trick on most distributions. Older Red Hat versions may use the path /etc/rc.d/init.d/ instead.
This only stops this particular service now. It will restart again on the next reboot, or runlevel change, unless additional steps are taken. So this is really a two step process for init type services.
Your distribution will have utilities available for controlling which services are started at various runlevels. Debian based systems have update-rc.d for this, and Red Hat based systems have chkconfig. If you are familiar with these tools, do it now, and then check again after the next reboot. If you are not familiar with these tools, see the man pages and learn it now! This is something that you need to know. For Debian (where $SERVICE_NAME is the init script name):
And Red Hat:
Another option here is to uninstall a package if you know you do not need it. This is a pretty sure-fire, permanent fix. This also alleviates the potential problem of keeping all installed packages updated and current (Step 2). And, package management systems like RPM or DEB make it very easy to re-install a package should you change your mind.
Inetd is called a "super-daemon" because it is used to spawn sub-daemons. inetd itself will generally be started via init scripts, and will "listen" on the various ports as determined by which services are enable in its configuration file, /etc/inetd.conf. Any service listed here will be under the control of inetd. Likewise, any of the listening servers in netstat output that list "inetd" in the last column under "Program Name", will have been started by inetd. You will have to adjust the inetd configuration to stop these services. xinetd is an enhanced inetd replacement, and is configured differently (see next section below).
Below is a partial snippet from a typical inetd.conf. Any service with a "#" at the beginning of the line is "commented out", and thus ignored by inetd, and consequently disabled.
The above example has two services enabled: time and pop3. To disable these, all we need is to open the file with a text editor, comment out the two services with a "#", save the file, and then restart inetd (as root):
Check your logs for errors, and run netstat again to verify all went well.
A quicker way of getting the same information, using grep:
Again, do you see anything there that you don't know what it is? Then in all likelihood you are not using it, and it should be disabled.
Unlike the init services configuration, this is a lasting change so only the one step is required.
Let's expose one myth that gets tossed around: you shouldn't disable a service by commenting out, or removing, entries from /etc/services. This may have the desired effect in some cases, but is not the right way to do it, and may interfere with the normal operation of other system utilities.
xinetd is an inetd replacement with enhancements. It essentially serves the same purpose as inetd, but the configuration is different. The configuration can be in the file /etc/xinetd.conf, or individual files in the directory /etc/xinetd.d/. Turning off xinetd services is done by either deleting the corresponding configuration section, or file. Or by using your text editor and simply setting disable = yes for the appropriate service. Then, xinetd will need to be restarted. See man xinetd and man xinetd.conf for syntax and configuration options. A sample xinetd configuration:
You can get a quick list of enabled services:
At this point, the above output should raise some red flags. In the overwhelming majority of systems, all the above can be disabled without any adverse impact. Not sure? Try it without that service. After disabling unnecessary services, then restart xinetd:
OK, if you can't find the "right" way to stop a service, or maybe a service is being started and you can't find how or where, you can "kill" the process. To do this, you will need to know the PID (Process I.D.). This can be found with ps, top, fuser or other system utilities. For top and ps, this will be the number in the first column. See the Port and Process Owner section in the Appendix for examples.
Example (as root):
Then run top or ps again to verify that the process is gone. If not, then:
Note the second "KILL" in there. This must be done either by the user who owns the process, or root. Now go find where and how this process got started ;-)
The /proc filesystem can also be used to find out more information about each process. Armed with the PID, we can find the path to a mysterious process:
Above we used the criteria of turning off all unnecessary services. Sometimes that is not so obvious. And sometimes what may be required for one person's configuration is not the same for another's. Let's look at a few common services that fall in this category.
Again, our rule of thumb is if we don't need it, we won't run it. It's that simple. If we do need any of these, they are prime candidates for some kind of restrictive policies via firewall rules or other mechanisms (see below).
In this section we learned how to identify which services are running on our system, and were given some tips on how to determine which services may be necessary. Then we learned how to find where the services were being started, and how to stop them. If this has not made sense, now is a good time to re-read the above.
Hopefully you've already taken the above steps. Be sure to test your results with netstat again, just to verify the desired end has been achieved, and only the services that are really required are running.
It would also be wise to do this after the next reboot, anytime you upgrade a package (to make sure a new configuration does not sneak in), and after every system upgrade or new install.