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.
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.
# 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
|
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 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:
# ls -l /etc/init.d/ | less
|
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):
# /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.
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):
# update-rc.d -f $SERVICE_NAME remove
|
And Red Hat:
# chkconfig $SERVICE_NAME off
|
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.
#
# 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, <waltje@uwalt.nl.mugnet.org>
#
# Modified for Debian Linux by Ian A. Murdock <imurdock@shell.portal.com>
#
# 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/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. 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:
# 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/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): 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:
$ /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.
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.
|
|