CTS-2301 (Unix/Linux Administration I) Project #6
Enabling Services

 

Due: by the start of class on the date shown on the syllabus

Description:

Services (file, print, remote access, database, etc.) are provided by server programs on your host.  Modern servers make a copy of themselves for each request to that service.  So at any given moment you may see several instances of a server running, or none at all, depending on how many requests for that service are currently being handled by that server.  Running servers you don't need waste memory and CPU cycles, enough to have a user-noticeable effect on system performance.

For this project you are to disable some services (enabled by default during the installation) and to enable the following services on your classroom computer:

There are two types of servers, stand-alone servers such as web, database, and mail servers, and on-demand servers such as telnet.  The difference between these two types of services is that a stand-alone server is always on once enabled.  This makes for much faster responses to web page or database requests, since it takes these servers several seconds to start up each time.  A program (client or server) that is always on is called a daemon (pronounced either as DAY-mən or DEE-mən), after the Greek term for a person's attendant spirit.  (A demon would be an evil spirit.)

Always-on servers historically are enabled or disabled in sets called run-levels which are identified by a number.  Changing run-levels will turn off some servers and turn on others.  Your system has a default run-level entered when you boot up; for Fedora this is run-level 5.

On the other hand once services such as telnet are enabled, a server is started on-demand for each request received.  Services such as telnet and FTP can start up quickly so there is no need to have them running all the time.  Such services are managed by a single (always on) super server called xinetd (or inetd on older systems).  Note that on-demand servers can't be manually started and stopped like stand-alone servers.  All you can do is enable/disable them, so they are ready to start or not when the next request arrives.  This is done by configuring the super server.

Make sure you keep an accurate system journal of any and all changes you make to your system!  You will need to turn this in, along with the answers to the questions asked below.

It should be noted that some students may have firewalls running on their systems that would prevent access to some services.  However the default firewall will still allow access from localhost to any service running on that host, so you can ignore any firewall issues (for now).  Also the default file and directory permissions should be fine.

However other security sub-systems may block access that you will need to manage or turn off.  These include TCP Wrappers, SELinux, and possibly PAM.

Requirements:

Answer the following questions and perform the following tasks:

  1. Identify and disable all unused services:
    1. Run the following command as root: chkconfig --list > ~/service-report.txt Examine this report.  Which services are running in your default run-level (usually 5)?
    2. Use the command ps -ef and compare this output to the service-report.txt output created in the previous step.  Determine which services that are enabled for the current run-level are actually running.  Why are there services which are enabled that don't appear to be running now?
    3. Update your system so that all available services will show up in the chkconfig service report without errors.  Hint:  Run the following commands as root:
         cd /etc/init.d
         for i in *
         do
            chkconfig --list $i
         done
      

      If some service reports an error, it means that although the service is present and available, chkconfig can't control it.  (Note functions and some other files in that directory don't actually represent services, so an error message on those files is normal.)  To fix this is usually just a matter of running the command:

         chkconfig --add name-of-service
      

      If that doesn't work you may need to add the special init script comments, containing the chkconfig tagsWhat changes (if any) did you need to make?

    4. Use the GUI tool system-config-services.  This should give a brief description of each service when you click on its name.  Stop each service you don't think you are using.  Which services did you stop?

      (Note that on non-Red Hat systems you may not have these commands available.  However there will always be some equivalent command.  ntsysv may be found instead on many systems.)

    5. Stopping the service now won't prevent the system from restarting it at the next boot.  For each service you turned off, disable the service from the current run-level, so that it won't start at the next boot.
    6. What is the command to stop the bluetooth server from the command line?
    7. What is the exact command you would use to disable the bluetooth server from run-level 3, using the Linux command line tool chkconfig?
    8. How could you disable the isdn service from run-level 3, using standard Unix/Linux command line utilities such as cp, mv, rm, ln, etc., and not using any GUI tools or command-line tools such as chkconfig?
    9. What is the command used to disable and stop some service foo on Solaris 10?
    10. Generate a new service report, saving the result in a different file.  Now use the diff command to compare these two reports.  Whenever you make changes to services, you can generate a new report, and compare it to the previous one.  The diff output is useful to include in your system journal.  What changes are shown by diff?
  2. Enable Apache (httpd) web service:
    1. Manually start the web server and verify it started successfully.  How did you do this?  You must check the Apache log files in /etc/httpd/logs/error_log and the system central log file in /var/log/messages, and examine the output of a ps -ef listing.  What Apache related message(s) did you see in the logs?  What Apache related processes are now running?
    2. Fire up a web browser such as Mozilla and point to the URL http://localhost/What do you see from this URL?  (Make sure you have the correct URL including the trailing slash!)
    3. Using the GUI tool of your choice make sure the web server will run in run-level 3What file(s) changed as a result?  (Hint:  See the find command tip.)
    4. Using either a command line tool or ln, enable Apache in run-level 5 as well.  Exactly what command did you use?
  3. Enable telnet network service:
    1. See if you have installed a telnet server.  You can check with rpm -q telnet-server.  If not, install it (the quick and easy way: yum install telnet-server).  Note that updating this will likely install xinetd as well.
    2. On Fedora, no on-demand services are installed by default.  Neither is the super-server xinetd (even though some files exist in the directory /etc/xinetd.d).  Re-run chkconfig --list and system-config-servicesWhat has changed now that there are on-demand services installed?
    3. If you examine the files in the directory /etc/init.d you won't find any script to control the telnet service.  Why not?  Where will you find the configuration file for telnet?
    4. Using vi edit the appropriate file(s) in /etc/xinetd.d to enable this service.  What file(s) did you edit and what change(s) did you make?  (Hint: see man xinetd and man xinetd.conf.)
    5. In order to have your changes take effect, restart the xinetd service.  Exactly what command(s) did you use?
    6. Run the command ps -ef and examine the output.  What do you see related to telnet?  Compare this answer with your answer from question in part A.2 above.  Does the output agree with what you expected to see?
    7. Verify telnet now works.  How did you do this?
    8. The modern xinetd server uses TCP Wrappers to control access policies.  Edit (or create) the file /etc/hosts.deny to contain this line:
              ALL: ALL

      Verify telnet is no longer working.  Then examine the system log file.  What error message(s) was produced by the telnet attempt?

    9. Edit (or create) /etc/hosts.allow to only permit telnet access from the 10.142.80.0/24 network (that is, IP address 10.142.80.0 with a mask of 255.255.255.0) and from localhost (or 127.0.0.1).  Verify telnet is working again.  What changes did you make?  (Hints:  In the hosts.allow file you need to use the filename (or pathname) of the telnet daemon.  The actual name of the telnet server (daemon) can be seen by examining the /etc/xinetd.d/telnet file.  Also see the man page for the hosts.allow file.)
    10. Having changed the configuration of TCP Wrappers, other services may no longer be working (email, web access, etc.).  Verify all your desired services are still working.  If any have stopped working, you can assume it is due to your changes to TCP Wrappers.  (Or you can examine the system log files to be certain!)  If necessary, re-configure TCP Wrappers /etc/hosts.allow file to allow ALL services from localhost.  What changes (if any) did you have to make?
  4. Enable anonymous FTP service:

    At one time FTP was a very vital service on the Internet.  Today a lot of files can be found and downloaded using HTTP from a web page.  But FTP hasn't gone away.

    FTP has low security, as everything is send across the network in plain text (unencrypted) form.  For upload configurations, web sites, and work documents, the secure variant sFTP (secure FTP) is preferred.  However anonymous FTP is still useful and used.

    For this part we will enable vsftpd (the very secure FTP daemon).  This server can be configured to either run stand-alone or on-demand.  For this project we will enable vsftpd to run as a stand-alone service (which is the default).

    1. If necessary, install the vsftpd server on your system.
    2. Change the FTP user home from /var/ftp to /var/ftp/pub.  Verify that directory exists (and has appropriate permissions).  This user's home directory is (by default) the location of the anonymous FTP site.
    3. Add some simple text file to /var/ftp/pub (so you can test your anonymous FTP site):
         echo 'it works' > /var/ftp/pub/foo.txt
         chmod a+r /var/ftp/pub/foo.txt
      

      (Make sure the file is readable by everyone.)

    4. If desired you can edit /etc/vsftpd/vsftpd.conf to change the default behavior of the FTP server.  For example you can add:
         ftpd_banner=Welcome to the Kaos.coop FTP service!
      
      See the comments in that file, and man page for vsftpd.conf to see what can be changed.  Make a backup copy of the original first!  What changes did you make?  (Use diff command to show.)
    5. Start the vsftpd service.  Check logs for any errors.  What log messages were generated (and in which log files)?
    6. From your non-root account, and from your home directory, try to connect to the anonymous FTP server:
          [auser@localhost ~]$ ftp localhost
      

      Use username anonymous or ftp for the anonymous user.  By default any password you enter will be accepted, but you must enter one.

      If this fails to work, what could be blocking access?  (Hint:  Maybe something you did earlier in part C blocks access to services?)  What did you do (the exact steps) to allow access to this service (if blocked)?  (You can show a diff listing to indicate the changes you made.)

    7. Once you get connected, try various FTP commands: help, dir, ls, pwd, get foo.txt, and to exit, bye  What directory does pwd show as the current directory?  What files can you see?
    8. Exit FTP and try it again, this time logging in using your normal user account with that account's password.  (Don't try to log in as root!)
      Did the login succeed?  If not, one likely cause is that SELinux is running in enforcing mode.  If you have difficulty logging in as a normal user (rather than the anonymous user), check if SELinux is running in enforcing mode with getenforce command.  If so, then run (as root) the setenforce 0 command to switch to permissive mode.  Now try to log in again.  (In the security course you will learn how to configure SELinux for this, but for our class it is better to switch it to permissive mode.  To make the change permanent edit the file /etc/selinux/config and set the mode from:
          SELINUX=enforcing
      to:
          SELINUX=permissive

      Note!  For security reasons modern systems won't allow you to connect as root, only as a regular user (or sometimes as an anonymous user such as for FTP).

    9. Once you are successfully logged in as a regular user, run some FTP commands again.  What is the result of the commands pwd and ls this time?
    10. To enable local users, to block others, to set up chroot protection for (some) users, you may need to edit the vsftpd.conf file.  You should start by reading the comments in that file.  If that doesn't help try reading the man page.  Remember that to access services from other hosts have security issues and may involve configuring the firewall, TCP wrappers (hosts.allow/deny), or PAM.  (None of this should be necessary for this project.) what changes, if any, did you make?
  5. Creating and installing your own service:
    1. Create a shell script named /usr/local/bin/hellod with the following contents:
      #!/bin/sh -
      echo 'Hello, World!'
    2. Make sure the script is readable and executable by everyone.  Run it (as non-root user) to test it.
    3. Now create a file /etc/xinetd.d/hello so your new hello service can be started on demand.  Our new service should listen on port number TCP/9333.  (This is a currently unassigned port, according to the master list of port number assignments by the IANA.)  The file should have the following contents:
      # default: off
      # description: Demo service that runs a shell script to say hello, world!
      
      service hello
      {
        disable      = no
        socket_type  = stream
        type         = UNLISTED
        port         = 9333
        wait         = no
        user         = nobody
        server       = /usr/local/bin/hellod
      }
    4. Now reload the xinetd service to make it read the new configuration.  Check the log file for any messages from xinetdWhat messages resulted from reloading xinetd?  If any errors were noted, fix them and repeat.  What errors (if any) were found and what did you do to resolve them?
    5. Once there are no errors, you new service should be available.  Test it out by running this command (not as root):
      nc localhost 9333

      If you don't have nc installed, you can install the nc package with yumnc is the Linux name of the netcat utility.  (Or you can use telnet instead of nc.)

      What was the result (output) of running this command?

      If this fails to work, what could be blocking access?  (Hint:  Maybe something you did earlier in part C blocks access to services?)  What did you do (the exact steps) to allow access to this service (if blocked)?  (You can show a diff listing to indicate the changes you made.)  Once fixed retry the command.

  6. Listing available services:
    1. List all the services now available on your host.  There are a number of tools you can use for this purpose, including lsof -i and netstat -lA inet.  But lsof lists each process listening, so ports such as TCP/80 will be listed multiple times, and netstat won't list on-demand services (just the super-server xinetd).  Perhaps the simplest way is to run (as root) the command nmap -sSU -p 0-65535 localhost.

      How many ports are open?  What are the meanings of the options to the nmap command used?

    2. What is the purpose of the /etc/services file?  What would happen if you commented out (or removed) the line(s) for some service, such as Telnet?  (You can always try it and see what happens.)

To be turned in:

The answers to the questions above and the portion of your system journal describing the steps you have taken to enable these services.

You can submit your project as email to .  Please see your syllabus for more information about submitting projects.