CEG 499/699: Internet Security College of Engineering & CS Wright State University Dayton, Ohio 45435-0001

Configuring a System Properly   Prabhaker Mateti   Abstract: Perhaps as many as 60 million nodes connected  to the Internet are personal machines running Windows 95/98/NT/2000 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 Unix or NT.   This work is supported in part by NSF DUE-9951380.

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

Perhaps as many as 90% of the 72 million nodes connected (as of Jan 2000) to the Internet 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/98/NT/2000 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 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 NT 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 NT can be installed by non-computer specialist by booting from a supplied CD and answering certain questions.  This activity is not the focus of the 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.

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.  Compare the MD5 sums.

SUID executables

Examine every suid root file.  Verify that it needs to be set-user-id-ed.

File Permissions

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

Disabling Unneeded Services

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 common to most Unix distributions.

bootp, bootps : used for bootp services. We recommend disabling it unless you are running a bootp server.

comsat : used for incoming mail notification via biff. We recommend disabling it unless you rely heavily on biff.

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

exec : allow remote users to execute commands on a host without needing to log in. Exposes remote user passwords on the network, thus 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 trasmitted over the wire in cleartext), 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. 

FTP "filez" transfers

If you allow files to both be written to and read from by anonymous 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). Considered highly insecure. We recommend disabling the service and using 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. Considered a potential security hazard. We recommend disabling the service.

shell : allows remote users to run arbitrary commands on a host via the Berkeley rsh utility (via the trusted hosts mechanism using the .rhosts file). Considered highly insecure. We recommend disabling the service and using SSH instead. If rsh access is a must, the service should be TCP-wrapped.

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. Considered a potential security hazard. We recommend disabling the service.

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. Since user passwords are trasmitted over the wire in plain text and can therefore be easily sniffed, we recommend disabling the service and using instead a secure terminal access mechanism which encrypts the entire session (such as kerberized telnetd or sshd). 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. Considered a security hazard. We recommend disabling the service.

tftp : allows remote users to transfer files from a host without requiring login. Used primarily by X-terminals and routers. Considered insecure. We recommend disabling the service. If tftp access is desired, we recommend that the "-s" option be used and that 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 such as NFS and NIS are considered 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+
• 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, 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.   Use any of the PCs numbered 19 to 30.  No other WSU facilities are allowed. 

Objective:  Configure a new deliberately mis-configured install of Linux on a lab PC properly.  Find and fix at least six (6) mis-configured items among the categories listed below.  For every additional problem you found and fixed, you will earn bonus points. Any number > 0 of changes in a single file will count as one item of change. 

1. Weak Passwords,
2. Accounts without passwords or default passwords
3. Reusable passwords
4. Use of TFTP (Trivial File Transfer Protocol) to obtain password files
5. Vulnerabilities in sendmail
6. Mis-configured anonymous FTP
7. Inappropriate network configuration file entries
8. Inappropriate 'secure' settings in /etc/ttys and /etc/ttytab
9. Inappropriate entries in /etc/aliases (or /usr/lib/aliases)
10. Inappropriate file and directory protections
11. Old versions of system software
12. Use of setuid.
13. Inappropriate export settings
14. Vulnerable protocols and services
15. Disabling Unneeded Services

Because this is only a lab experiment and because you may not be conversant with the needed background, you may exclude TFTP, and sendmail related issues.

This lab deals with only the Linux OS, but similar configuration details apply to NT.  You will be configuring a system that whose partition shares the hard disk that contains other OS.  You will login as root.  The root password will be announced in class.  Do not reveal this password to anyone.

Check.pl is a Perl script that looks through your entire file system, (or just the directory you tell it to) for suid, sgid, sticky, and writeable files.  [Download check.pl]

Procedure

1. Read the Required Reading items from the list below.  This experiment is not doable without these Readings.
2. Choose Linux OS at the OS boot prompt.  This is a loosely configured Linux OS.  Download check.pl.  Use any of the PCs numbered 19 to 30.
3. Login as root.
4. Configure the newly invoked Linux system by checking for improper settings in the categories described above.  Not all are poorly set. 
5. Make careful notes of the changes you make.  Write the changes you would make as executable shell scripts so that they can be applied.  Set the script so that it is runnable from the  OS.  Remember to do not make any changes to the OS image that is currently installed.

Turn in a Lab Report.  It should include one shell script 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 configuration you made.  No witness report is needed.

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 Become familiar with it.
5. Kurt Seifried, Linux Administrator's Security Guide, http://www.linuxdoc.org/LDP/ lasg/lasg-www/ 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/Courses/499/Fortification/  Required Reading.
7. Prabhaker Mateti, Hardening a System, June 2000.  A lecture from a course on Internet Security. www.cs.wright.edu/~pmateti/Courses/499/HardenOS/   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.