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:
It is perfectly possible to have a fully functional Internet connection with no servers running that are accessible to outside connections. Not only possible, but desirable in many cases. The principle here is that you will never be successfully broken into via a port that is not opened because no server is listening on it. No server == no port open == not vulnerable. At least to outside connections.
If you don't recognize a particular service, chances are good you don't really need it. We will assume that and so we'll turn it off. This may sound dangerous, but is a good rule of thumb to go by.
Some services are just not intended to be run over the Internet -- even if you decide it is something you really do need. We'll flag these as dangerous, and address these in later sections, should you decide you do really need them, and there is no good alternative.
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.
Which services get installed and started will vary greatly depending on which version of Red Hat, and which installation options were chosen. Earlier releases were very much prone to start many services and then let the user figure out which ones were needed, and which ones weren't. Recent versions are much more cautious. But this makes providing a ready made list of likely services impossible. Not to worry, as we shouldn't trust what is supposed to be running anyway. What we need to do is list for ourselves all running services.
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.
# netstat -tap |grep LISTEN *:exec *:* LISTEN 988/inetd *:login *:* LISTEN 988/inetd *:shell *:* LISTEN 988/inetd *:printer *:* LISTEN 988/inetd *:time *:* LISTEN 988/inetd *:x11 *:* LISTEN 1462/X *:http *:* LISTEN 1078/httpd bigcat:domain *:* LISTEN 956/named bigcat:domain *:* LISTEN 956/named *:ssh *:* LISTEN 972/sshd *:auth *:* LISTEN 388/in.identd *:telnet *:* LISTEN 988/inetd *:finger *:* LISTEN 988/inetd *:sunrpc *:* LISTEN 1290/portmap *:ftp *:* LISTEN 988/inetd *:smtp *:* LISTEN 1738/sendmail: accepting connections *:1694 *:* LISTEN 1319/rpc.mountd *:netbios-ssn *:* LISTEN 422/smbd |
Red Hat 7.x and Mandrake 8.x and later users will have xinetd in place of inetd. 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.
NFS (Network File System) and related services, including nfsd, lockd, mountd, statd, portmapper, etc. NFS is the standard Unix service for sharing file systems across a network. Great system for LAN usage, but dangerous over the Internet. And its completely unnecessary on a stand alone system.
rpc.* services, Remote Procedure Call.*, typically NFS and NIS related (see above).
Printer services (lpd).
The so-called r* (for "remote", i.e. Remote SHell) services: rsh, rlogin, rexec, rcp etc. Unnecessary, insecure and potentially dangerous, and better utilities are available if these capabilities are needed. ssh will do everything these command do, and in a much more sane way. See the man pages for each if curious. These will probably show in netstat output without the "r": rlogin will be just "login", etc.
telnet server. There is no reason for this anymore. Use sshd instead.
ftp server. There are better, safer ways for most systems to exchange files like scp or via http (see below). ftp is a proper protocol only for someone who is running a dedicated ftp server, and who has the time and skill to keep it buttoned down. For everyone else, it is potentially big trouble.
BIND (named), DNS server package. With some work, this can be done without great risk, but is not necessary in many situations, and requires special handling no matter how you do it. See the sections on Exceptions and special handling for individual applications.
Mail Transport Agent, aka "MTA" (sendmail, exim, postfix, qmail). Most installations on single computers will not really need this. If you are not going to be directly receiving mail from Internet hosts (as a designated MX box), but will rather use the POP server of your ISP, then it is not needed. You may however need this if you are receiving mail directly from other hosts on your LAN, but initially it's safer to disable this. Later, you can enable it over the local interface once your firewall and access policies have been implemented.
This is not necessarily a definitive list. Just some common services that are sometimes started on default Red Hat 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.
chkconfig is a very useful command for controlling services that are started via init scripts (see example below). Also, where xinetd is used, it can control those services as well. chkconfig can tell us what services the system is configured to run, but not necessarily all services that are indeed actually running. Or what services may be started by other means, e.g. from rc.local. It is a configuration tool, more than a real time system auditing too.
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.
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/ for older versions of Red Hat).
You can get a listing of these scripts:
# ls -l /etc/rc.d/init.d/ | less |
To stop a running service now, as root:
# /etc/init.d/<$SERVICE_NAME> stop |
Where "$SERVICE_NAME" is the name of the init script, which is often, but not always, the same as the service name itself. 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.
chkconfig can be used to see what services are started at each runlevel, and to turn off any unneeded services. To view all services under its control, type this command in an xterm:
# chkconfig --list | less |
To view only the ones that are "on":
# chkconfig --list | grep "\bon\b" | less |
The first column is the service name, and the remaining columns are the various runlevels. We need generally only worry about runlevels 3 (boot to text console login) and 5 (boot straight to X11 login). xinetd services won't have columns, since that aspect would be controlled by xinetd itself.
Examples of commands to turn services "off":
# chkconfig portmapper off # chkconfig nfs off # chkconfig telnet off # chkconfig rlogin off |
Note that the last two are xinetd services. A very easy and nifty tool to use! Red Hat also includes ntsysv and tksysv (GUI) for runlevel and service configuration. See the man pages for additional command line options.
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). RPM makes it very easy to re-install a package should you change your mind.
To uninstall packages with RPM:
# rpm -ev telnet-server rsh rsh-server |
The above command would uninstall the "telnet server" package (but not telnet client!), "rsh" client and "rsh server" packages in one command. Red Hat also includes gnorpm, a GUI RPM management utility which can do this as well.
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.
# # inetd.conf This file describes the services that will be available # through the INETD TCP/IP super server. To re-configure # the running INETD process, edit this file, then send the # INETD process a SIGHUP signal. # # Version: @(#)/etc/inetd.conf 3.10 05/27/93 # # Authors: Original taken from BSD UNIX 4.3/TAHOE. # Fred N. van Kempen, <[email protected]> # # Modified for Debian Linux by Ian A. Murdock <[email protected]> # # Echo, discard, daytime, and chargen are used primarily for testing. # # To re-read this file after changes, just do a 'killall -HUP inetd' # #echo stream tcp nowait root internal #echo dgram udp wait root internal #discard stream tcp nowait root internal #discard dgram udp wait root internal #daytime stream tcp nowait root internal #daytime dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal time stream tcp nowait root internal # # These are standard services. # #ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # # Shell, login, exec, comsat and talk are BSD protocols. # #shell stream tcp nowait root /usr/sbin/tcpd in.rshd #login stream tcp nowait root /usr/sbin/tcpd in.rlogind #exec stream tcp nowait root /usr/sbin/tcpd in.rexecd #comsat dgram udp wait root /usr/sbin/tcpd in.comsat #talk dgram udp wait root /usr/sbin/tcpd in.talkd #ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd #dtalk stream tcp wait nobody /usr/sbin/tcpd in.dtalkd # # Pop and imap mail services et al # #pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d #imap stream tcp nowait root /usr/sbin/tcpd imapd # # The Internet UUCP service. # #uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l # <snip> |
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):
# /etc/rc.d/init.d/inetd restart |
Check your logs for errors, and run netstat again to verify all went well.
A quicker way of getting the same information, using grep:
$ grep -v '^#' /etc/inetd.conf time stream tcp nowait root internal pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d |
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. Red Hat includes xinetd with 7.0 and later releases. 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/. Configuration of individual services will be in the individual files under /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. Or by using chkconfig. Then, xinetd will need to be restarted. See man xinetd and man xinetd.conf for syntax and configuration options. A sample xinetd configuration:
# default: on
# description: The wu-ftpd FTP server serves FTP connections. It uses \
# normal, unencrypted usernames and passwords for authentication.
service ftp
{
disable = no
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_success += DURATION USERID
log_on_failure += USERID
nice = 10
}
|
You can get a quick list of enabled services:
$ grep disable /etc/xinetd.d/* |grep no /etc/xinetd.d/finger: disable = no /etc/xinetd.d/rexec: disable = no /etc/xinetd.d/rlogin: disable = no /etc/xinetd.d/rsh: disable = no /etc/xinetd.d/telnet: disable = no /etc/xinetd.d/wu-ftpd: disable = no |
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:
# /etc/rc.d/init.d/xinetd restart |
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):
# kill 1163 |
Then run top or ps again to verify that the process is gone. If not, then:
# kill -KILL 1163 |
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:
$ /bin/ps ax|grep tcpgate 921 ? S 0:00 tcpgate |
# ls -l /proc/921/exe lrwxrwxrwx 1 root root 0 July 21 12:11 /proc/921/exe -> /usr/local/bin/tcpgate |
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).
identd - This is a protocol that has been around for ages, and is often installed and running by default. It is used to provide a minimal amount of information about who is connecting to a server. But, it is not necessary in many cases. Where might you need it? Most IRC servers require it. Many mail servers use it, but don't really require it. Try your mail setup without it. If identd is going to be a problem, it will be because there is a time out before before the server starts sending or receiving mail. So mail should work fine without it, but may be slower. A few ftp servers may require it. Most don't though. Older versions of Red Hat started identd via inetd. Recent versions start this via init scripts.
If identd is required, there are some configuration options that can greatly reduce the information that is revealed:
/usr/sbin/in.identd in.identd -l -e -o -n -N
|
The -o flag tells identd to not reveal the operating system type it is run on and to instead always return "OTHER". The -e flag tells identd to always return "UNKNOWN-ERROR" instead of the "NO-USER" or "INVALID-PORT" errors. The -n flag tells identd to always return user numbers instead of user names, if you wish to keep the user names a secret. The -N flag makes identd check for the file .noident in the user's home directory for which the daemon is about to return a user name. It that file exists then the daemon will give the error "HIDDEN-USER" instead of the normal "USERID" response.
Mail server (MTA's like sendmail, qmail, etc) - Often a fully functional mail server like sendmail is installed by default. The only time that this is actually required is if you are hosting a domain, and receiving incoming mail directly. Or possibly, for exchanging mail on a LAN, in which case it does not need Internet exposure and can be safely firewalled. For your ISP's POP mail access, you don't need it even though this is a common configuration. One alternative here is to use fetchmail for POP mail retrieval with the -m option to specify a local delivery agent: fetchmail -m procmail for instance works with no sendmail daemon running at all. Sendmail, can be handy to have running, but the point is, it is not required in many situations, and can be disabled, or firewalled safely.
BIND (named) - This often is installed by default, but is only really needed if you are an authoritative name server for a domain. If you are not sure what this means, then you definitely don't need it. BIND is probably the number one crack target on the Internet. BIND is often used though in a "caching" only mode. This can be quite useful, but does not require full exposure to the Internet. In other words, it should be restricted or firewalled. See special handling of individual applications 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.