The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Поиск:  Каталог документации

3. Step 1: Which services do we really need?

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:

3.1. System Audit

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.

3.2. The Danger Zone (or r00t m3 pl34s3)

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.

3.3. Stopping Services

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.)

3.3.1. Stopping Init Services

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.

3.3.2. Inetd

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/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.

3.3.3. Xinetd

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  
 

 

3.3.4. When All Else Fails

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

 

3.4. Exceptions

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).

3.5. Summary and Conclusions for Step 1

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.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру