Configuring a System Properly

Prabhaker Mateti

Abstract: Perhaps as many as 900 million nodes connected to the Internet are personal machines running Windows 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.

Table of Contents

  1. Educational Objectives
  2. Proper Configuration of Security for Personal Machines
  3. Files and Installed Software
    1. Removing Unnecessary Software Packages
    2. Patching Linux Systems
    3. SUID executables
    4. Checking File Permissions and Ownership
    5. Securing Postfix
    6. Securing Sendmail
    7. Securing NFS
    8. Securing SSH
    9. Copying Files Using SSH Without Providing Login Prompts
    10. Checking Accounts, Strong Passwords.
    11. Restricting Direct Login Access for System and Shared Accounts
    12. Restricting su Access to System and Shared Accounts
  4. Booting Sequence
    1. Reviewing inittab and Boot Scripts
    2. Disabling Unneeded Services
    3. Configuring Services
    4. Closing Network Ports and Disabling Runlevel System Services
    5. Closing Network Ports and Disabling Xinetd Services
  5. Monitoring a Running System
    1. Protecting the root account
    2. Detecting Listening Network Ports
    3. Restricting System Access from Servers and Networks
    4. Kernel Tunable Security Parameters
    5. /etc/sysctl.conf
    6. Preventing Accidental Denial of Service
    7. Displaying Login Banners
    8. Watch the log files.
  6. Shutdown Sequence
  7. Lab Experiment
  8. Acknowledgements
  9. 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

Configuring a System Properly

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. Proper configuration involves the examination of configuration settings of all installed software. 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 changes must be made. Proper configuration of a system is a prerequisite to fortifying and/or hardening.

Proper configuration should happen immediately after a fresh install of the OS, and then after making changes to the system including adding or deleting services and user accounts. It should be done on the host machine without network connections. We ignore here the considerable amount of configuration tuning done to improve performance, reduce resource usage, and in general for cleanup.

We focus on the security of Linux systems. We only highlight what needs to be done leaving out the recipe-level descriptions to the references. Should you be interested in configuring Windows properly, consult the References section.

Proper Configuration of Security for Personal Machines

The Internet Domain Survey ( https:// www.isc.org/ solutions/survey ) reports that the number of hosts advertised in the DNS, as of Jan 2012 is 9000 million (in 2003 it was 171+ million, and as of Jan 2009 is 625+ 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 7/XP/... and Linux with little supervision from trained system administrators, the remaining systems being other variants of Unix and Macintoshes. These have become targets of script kiddies.

Files and Installed Software

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 DVD 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. There is a so-called "frugal install" which leaves most of a Linux distribution installed as a single large (in the GB) file that is an image of a compressed file system. There is some performance loss as a result, but there is also greater assurance that the files within remain intact.

The rest of the lecture highlights checks you should make after this initial phase of installing a new OS image, and associated applications. Depending on the distribution, the path names cited below may be different.

  1. Removing Unnecessary Software Packages
  2. Patching Linux Systems
  3. Checking File Permissions and Ownership. Examine all the files in the standard directories: /, /bin, /boot, /dev, /etc, /root, /sbin, /usr, /usr/bin, and /usr/sbin. These should all be owned by root and not writeable to others. The /tmp and are world-writeable. The file /etc/passwd is world-readable for legacy reasons, but /etc/shadow should be world-unreadable.
  4. SUID executables: Examine every suid root file. find / -type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \; will list all the SUID/SGID files. Verify that every such binary or script needs to be set-user-id-ed. Setuid scripts are very vulnerable. If POSIX capabilities are enabled, suid root permission can be removed.
  5. Securing Postfix
  6. Securing Sendmail
  7. Securing NFS
  8. Securing SSH
  9. Copying Files Using SSH Without Providing Login Prompts
  10. Checking Accounts. Strong Password Policy. Use tools such as "John the ripper" to find out weak users passwords on your server. Configure pam_cracklib.so to enforce the password policy. Linux: Force Users To Change Their Passwords Upon First Login Linux turn On / Off password expiration / aging Lock the user password Search for all account without password and lock them Use Linux groups to enhance security Under Linux you can use the faillog command to display faillog records or to set login failure limits. faillog formats the contents of the failure log from /var/log/faillog database / log file. It also can be used for maintains failure counters and limits. Only root account have UID 0 with full permissions to access the system. Enable Password Aging. Restrict Use of Previous Passwords. Lock User Accounts After Too Many Login Failures.
  11. Restricting Direct Login Access for System and Shared Accounts
  12. Restricting su Access to System and Shared Accounts

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. Also, compare the MD5 sums of the executables after each boot with those you saved immediately after fresh install.

  1. Reviewing inittab and Boot Scripts
  2. Disabling Unneeded Services: See below.
  3. Configuring Services
  4. Closing Network Ports and Disabling Runlevel System Services
  5. Closing Network Ports and Disabling Xinetd Services

Disabling Unneeded Services

Services are started in exactly three ways:

  1. During boot time via a script. This is traceable from /etc/inittab and /etc/init.d/*.
  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.

Most, but not all, Linux systems now 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.

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 "TCP-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.

Monitoring a Running System

  1. 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.
  2. Detecting Listening Network Ports
  3. Restricting System Access from Servers and Networks
  4. Kernel Tunable Security Parameters
  5. /etc/sysctl.conf controls the system.
  6. Preventing Accidental Denial of Service
  7. Displaying Login Banners
  8. Watch the log files. Minimally, files that should be examined are: /var/log/messages, /var/log/syslog.

Shutdown Sequence

Shutdown time also is an excellent point where an attacker can install Trojans. A clever attacker would have downloaded the needed files during the normal running, but would not have installed them until most of the system was shut down.

Lab Experiment

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

This lab asks for a certain number of fixes in each of the categories: properly configured, fortified and hardened. Should you be unable to find that many fixes, report on what you discovered, and stake a claim that the Linux distribution you chose was "so perfect" that only that many problems exist. If we discover otherwise, you will earn corresponding negative points.

Write the fixes you suggest as a bash script that can be applied by root. Include these scripts as appendices to the lab report. All changes of "one kind" (e.g., weak passwords) will count as one item of change. These scripts can include commands such as wget URL or apt-get install/remove package. You are welcome to use a language other than bash; change the file name extension accordingly.

This lab is not net-centric; so there is no need for the NetUtils setup. But discovering network related problems is within its scope.

Objective: Examine a Linux installation for what needs to be properly configured, fortified and hardened. This lab deals with only the Linux OS, but similar details apply to Windows and other OS.

Procedure

  1. You will need a USB drive of 4GB or higher capacity. Install a Linux distribution of your choice onto the USB drive. (See References below for examples and instructions; Ubuntu Precise 12.04 LTS, BackTrack 5 and Knoppix 6.7.1 are excellent choices.) We will refer to this installation as LXU. Boot the PC into LXU. Login as needed, as an ordinary user or as root.
  2. Find and fix at least four misconfigured items. Write the changes you suggest as a script named configProperly.sh. (See Securing Debian Howto.)
  3. Make at least two specific fortification improvements to LXUs . Write these as a script named fortify.sh. (Read Fortification article.)
  4. Make at least two specific hardening improvements to LXU. Write these as a script named harden.sh. (Read Hardening article.)
  5. The Lab Report should include a section that describes the chosen LXU briefly, and a detailed section explaining the rationale behind the changes (what and why) you suggest.
  6. Bonus Points: Compile the Linux kernel omitting all features unnecessary for CEG 429. Do keep the kernel module structure intact. Verify that LXU works properly when its original kernel is replaced by this one. ( https:// help.ubuntu.com/ community/ Kernel/ Compile is a howto on Linux kernel compilation. A simpler description is in the Hardening article.)
  7. Bonus Points: Recompile the Linux kernel omitting all features unnecessary for CEG 429. Merge all needed drivers etc into the kernel. That is, no loadable modules, no initrd are needed any more. Verify that LXU works properly when its original kernel is replaced by this one.
  8. Bonus Points: Recompile the Linux kernel, but using a compiler other than gcc, omitting all features unnecessary for CEG 429. Do keep the kernel module structure intact. Verify that LXU works properly when its original kernel is replaced by this one

Link to Grading Sheet

Acknowledgements

References

  1. Bastille-Unix.org. "... "locks down" an operating system, proactively configuring the system for increased security and decreasing its susceptibility to compromise. ... Bastille currently supports the Red Hat, ..., Debian ... distributions, .... It also supports Mac OS X. ... In its assessment mode, it builds a report intended to teach the user about available security settings ... ." Bastille should use the term "proper configuration" instead of "hardening". Highly Recommended Reading.
  2. Center for Internet Security, Security Configuration Benchmarks: Microsoft Windows 7 Benchmarks, 2012. "The CIS Benchmarks are the only consensus-based, best-practice security configuration guides both developed and accepted by government, business, industry, and academia." Highly Recommended Reading.
  3. Debian, securing-debian-howto. "... Starting with the process of securing and hardening the default Debian GNU/Linux ... installation, ... gives additional information on the security tools available ...". Required visit.
  4. NIST, United States Government Configuration Baseline, 2012. "The purpose of the United States Government Configuration Baseline (USGCB) initiative is to create security configuration baselines for Information Technology products widely deployed across the federal agencies. Formal definitions of these baseline settings, ... supporting reference material for implementing and verifying USGCB settings on target systems. ... available for Windows 7, ..., Windows XP, Internet Explorer ..." Highly Recommended Reading.
  5. NIST, National Vulnerability Database, 2012. "NVD contains content (and pointers to tools) for performing configuration checking of systems implementing the Federal Desktop Core Configuration (FDCC) using the Security Content Automation Protocol (SCAP)." Highly Recommended Reading.
  6. Prabhaker Mateti, Security Fortification, www.cs.wright.edu/ ~pmateti/ InternetSecurity Required Reading.
  7. Prabhaker Mateti, Hardening a System, www.cs.wright.edu/ ~pmateti/ InternetSecurity Required Reading.
  8. Prabhaker Mateti, Installing Linux on a USB Drive, Mar 2012. Required Reading.
  9. Microsoft, http://www.microsoft.com/ security/default.asp. Even though often very Windows specific, there is enough on security in general. Reference.
  10. Pendrive Linux. This site has many recipes for installing different Linux distributions to a USB drive. Required visit.
  11. Ubuntu, https://wiki.ubuntu.com/Security/Features. Even though Ubuntu specific, there is much to learn here. Required Reading.

Copyright © 2012 pmateti@wright.edu