CEG 429/629:
Internet Security

College of Engineering & CS
Wright State University
Dayton, Ohio 45435-0001

Configuring a System Properly

Prabhaker Mateti
Abstract: Perhaps as many as 150 million nodes connected  to the Internet are personal machines running Windows 95/../XP and Linux with little supervision from system administrators. These have become targets of script kiddies. This lecture and the associated lab experiment are intended to help configure personal systems running Linux/ Unix or Windows.
This work is supported in part by NSF DUE-9951380.
  03/17/00

Table of Contents

  1. Educational Objectives
  2. Proper Configuration of Security for Personal Machines
    1. Booting Sequence
    2. SUID executables
    3. File Permissions
    4. Disabling Unneeded Services
    5. Protecting the root Account
    6. Common UNIX System Configuration Problems That Are Exploited
  3. Lab Experiment
  4. Acknowledgements
  5. References

Educational Objectives

  1. Recognize that out of the box installations of OS are insecure.
  2. Know the typical problem spots.
  3. Identify unneeded services

Proper Configuration of Security for Personal Machines

The Internet Domain Survey (http://www.isc.org/ds/) reports that the number of hosts advertised in the DNS, as of Jan 2003 is 171+ million. Perhaps as many as 90% of these are personal machines, the rest being various servers. Perhaps 80% of these personal machines, and nearly 100% of those behind firewalls in private LANs, are running Windows 95/.../XP and Linux with little supervision from system administrators, the remaining systems being other variants of Unix and Macintoshes. The 72 million count does not include home-based machines that connect via PPP, even though once PPP-connected they are no less vulnerable than the nodes permanently connected to a LAN.  These have become targets of script kiddies.

There are two other lectures related to the current lecture:  Fortification and Hardening.  It is too pedantic to try to rigorously distinguish between proper configuration from these two topics.  Suffice it to say, for our immediate purposes, that proper configuration of the system as given is a prerequisite to either fortifying or hardening.

Systems as distributed are often loosely configured.  Occasionally this is due to sloppiness of the distributor.  More commonly it is because the distributor has tried to configure a generic appeal-to-all setup.  So, it is important that we examine the configuration at length and determine what if any changes must be made.

The proper configuration documents from CERT referred below are to be followed.  In some cases, they do not explain the reasoning behind their suggestions.  The rest of this document aims to fill that gap.

We focus  on Unix systems.  Should you be interested in configuring Windows properly, consult the References section.

Installing a New Image of OS

Installing a new OS image has become a straightforward activity.  Nearly all well-known Linux distributions and Windows can be installed by non-computer specialist by booting from a supplied CD and answering a few questions.  This activity is not the focus of this lecture.  In the lab experiment, we have simplified the install problem further.  The rest of the lecture is about checks you should make after this initial phase of installing a new OS image, and associated applications.

Depending on the distribution, the (full path) names cited below may be different.

Booting Sequence

Booting time is an excellent point where an attacker can install Trojans.  Examine the booting sequence to verify that the kernel and other executables are what they claim to be.  The minimum log files that should be examined are: /var/log/messages, /var/log/syslog. 

Also, compare the MD5 sums of the executables after each boot with those you saved immediately after fresh install.

SUID executables

Examine every suid root file.  Verify that every such binary or script needs to be set-user-id-ed.  Setuid scripts are very vulnerable.

File Permissions

Examine all the files in the standard directories: /, /bin, /boot, /dev, /etc, /root, /sbin, /usr, /usr/bin, and /usr/sbin.

Disabling Unneeded Services

Most, but  not all, Linux systems now (2003) use xinetd instead of inetd.  The configuration files for xinetd are "distributed" into /etc/xinetd.conf and into  files located in the subdirectory /etc/xinetd.d/   All references below to /etc/inetd.conf should be understood as including these if xinetd is in use.

Services are started in exactly three ways:

  1. During boot time via a script.  This is traceable from /etc/inittab.
  2. As a result of network connection.  This is traceable from /etc/inetd.conf.
  3. Explicitly as a command.

In all cases, only install the absolutely necessary services. If you are not sure what it is, disable it.  These services (listed alphabetically) are commonly left running in improperly configured Unix/ Linux distributions.  In the following, "wrapping" a service refers to initiating the service through a wrapper program that does extra checking and logging before invoking the original program that provides the service.  Two well known wrappers are tcpwrapper and tcpd.

bootp, bootps : Used for bootp services.

echo, daytime, discard, chargen: These services are used largely for testing and are largely unnecessary.

exec : Allow remote users to execute commands on a host without needing to log in. It exposes remote user passwords on the network, thus is highly insecure. We recommend disabling the service.

finger : allows remote users to use the finger utility to obtain information about arbitrary users on a host. Considered highly insecure. We recommend disabling the service or using a more secure version such as cfinger.

ftp : allows remote users to transfer files to/from a host using ftp. Since user passwords are easily sniffable (they are transmitted over the wire in clear text), we recommend disabling the service and using instead a secure file transfer mechanism which encrypts the entire session (such as Kerberized ftpd or SSH). If ftp access is a must, the service should be wrapped. 

"filez" transfers: If you allow files to both be written to and read from by anonymous FTP users, attackers will find those accounts and use them to transfer "warez", MP3 files, and porn.

login : Allows remote users to use the Berkeley rlogin utility to log in to a host without supplying a password (via the .rhosts mechanism). Use SSH instead. If rlogin access is a must, the service should be wrapped.

netstat : Designed to provide network status information about a host to remote hosts.

shell :   See login above.

smtp If you allow the "relay" feature on SMTP servers, spammers will find your server and use it to forward spam through (to hide themselves and also take advantage of your higher-speed connection).

systat : designed to provide status information about a host.

smurf amplifiers If you do not adjust your subnet masks and visible services, attackers will attempt to use your site as a "smurf" or "fraggle" amplifier to flood other victims on the net.

website defaults If you put a web server on the Internet, you must carefully remove all "defaults", "samples", and "CGI scripts" or attackers will at minimum deface web pages or compromise the machine.

telnet : Allows remote users to connect to a host via telnet. which transmits user passwords over the wire in plain text and can therefore be easily sniffed.  Use ssh instead. If telnet access is a must, the service should be wrapped.

talk, ntalk : allows remote users to use talk to have a real time conversation with a user on a host.

tftp : allows remote users to transfer files from a host without requiring login. Used primarily by X-terminals and routers.  If tftp access is desired,  the service be wrapped.

time: Used for clock synchronization. We recommend disabling the service and using xntp to synchronize your system clock to WWV.

uucp : allows remote users to transfer files to/from a host using the UUCP protocol. Unless you use UUCP, we recommend disabling the service.

RPC based services

RPC based services such as NFS and NIS are a  major security hazards unless you are using secure RPC. Our general recommendation is therefore against the use of NIS or NFS unless the physical network segments are protected either physically or via the use of switched hubs. All RPC based services should be disabled in inetd.conf  (unless NFS/NIS must be used).

Alternatives to NIS are: the use of Sun Microsystem's NIS+, and the use of rsync along with SSH to distribute /etc/passwd, /etc/group, etc. to clients from a central server.

Common RPC based services defined in inetd.conf are:

rexd : allows remote users to run RPC programs on a host. Can be used to run an arbitrary shell on the host, thus highly insecure. We recommend disabling the service.

rquotad : returns quotas for a user of a local file system which is mounted by a remote machine over the NFS. We recommend disabling it.

rstatd : extracts performance statistics from the kernel for use by programs such as perfmeter. We recommend disabling it.

ruserd : is used to return a list of users on a network. We recommend disabling it.

sprayd : records the packets sent by spray, and sends a response to the originator of the packets. We recommend disabling it.

walld : used for handling rwall and shutdown requests. We recommend disabling it.

ypupdated : used for updating NIS information. Since we recommend against the use of NIS in general, this service should be disabled.

Protecting the root Account

Even on a personal machine, normal daily use of the system should be through a non-root account.  The root must have a non-trivial password.  Run a password audit tool to verify that the password is not weak.

Lab Experiment

All work should be carried out in Operating Systems and Internet Security (OSIS) Lab, 429 Russ.   No other WSU facilities are allowed. 

  1. Read the Required Reading items from the References below.  This experiment is not doable without reading these.
  2. Browse the web and learn the functionality of  myconfig=scan in the context of Knoppix LiveCD.


Objective:  Configure a new  installation of Linux
on a lab PC properly.  Find and fix at least four (4) misconfigured items. All changes 
of "one kind" (e.g., weak passwords) will count as one item of change. This lab deals with only the Linux OS, but similar configuration details
apply to Windows NT and above.  
Procedure
    
  
  1. You will be examining the Knoppix CD image already copied as a single large file on to the hard disk.  Boot into this image as usual from the Grub menu.  Here is the Grub boot entry. Make no changes to this.  
	The "kernel" stanza is actually one line but split on this web page for 
	readability.
    title Only-for-CEG429: Linux-Debian-Knoppix-CD-Image-nodhcp
root (hd0,6)
kernel /Knoppix/boot/isolinux/linux knoppix_dir=/Knoppix/KNOPPIX 
    ramdisk_size=100000 myconfig=scan lang=us acpi=on dma nodhcp screen=1280x1024
initrd /Knoppix/boot/isolinux/minirt.gz


  2. Login as root from the K/Knoppix/RootShell menu.
    3. 

  3. 
If
  you are returning from a previous (incomplete) session, now is the time to
re-apply the changes you gathered so far.  Browse the web and learn the 
functionality of  myconfig=scan for this purpose.
  4. Configure the newly invoked Linux system by checking for improper settings.  Not all are poorly set. Make 
	whatever changes you consider necessary.  
  5. Make careful notes of the changes you make.  Write the changes you
    made as an executable bash script named changes.sh so that they 
	can be re-applied.  Save this script on a removable media.
    6. 
  
Turn in a Lab Report.  It should include one shell script 
changes.sh containing all
the commands that accomplish the changes you made.  Accompany this script
with a changes.txt file explaining the changes (what and why) in 
the configuration
you made.




Acknowledgements


References
    
  
  1. CERT, Securing Desktop Workstations, http://www.cert.org/security-improvement/
    modules/m04.html.  Required Reading.
  2. CERT, UNIX Configuration Guidelines, http://www.cert.org/tech_tips/unix_configuration_
    guidelines.html  [WSU copy] Required
    Reading.
  3. CERT, Windows NT Configuration Guidelines, http://www.cert.org/tech_tips/win_
    configuration_guidelines.html  Recommended Reading.
  4. Dave Wreski, Linux Security Administrator's Guide, http://www.nic.com/~dave/
    SecurityAdminGuide/SecurityAdminGuide.html 1998. Become familiar with it.
  5. Kurt Seifried, Linux Administrator's Security Guide,
  http://www.seifried.org/lasg/ 
  2001. New version of Wreski's document. Become familiar with
    it.
  6. Prabhaker Mateti, Security Fortification, June 2000.  A lecture from
    a course on Internet Security.
  www.cs.wright.edu/~pmateti/InternetSecurity  
    Required Reading.
  7. Prabhaker Mateti, Hardening a System, June 2000.  A lecture from a
    course on Internet Security.
  www.cs.wright.edu/~pmateti/InternetSecurity 
    Required Reading.
  8. Microsoft Security, http://www.microsoft.com/security/default.asp
    Reference.
  9. Michael Espinala, "The Hardening of Microsoft Windows NT Operating
    System Version 4.0", March 1998.  Even though the title has
    "hardening" in it, this excellent paper is about proper
    configuration.  Reference.
  10. Tom  Sheldon, Windows NT Security Handbook,  ISBN:
    0078822408,  Nov 1996.  Reference.

  

    
      

        
        05/31/05 14:35:48 -0400

  
    

      Open Content Copyright © 2005 pmateti@cs.wright.edu