UP | HOME
../../ | NoSlides

Configuring a System Properly

Table of Contents

1 Overview

1.1 Abstract

  1. As many as a billion 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.
  2. This lecture and the associated lab experiment are intended to help configure personal systems running Linux.
  3. 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.
  4. There are two other lectures related to the current lecture: Fortification and Hardening.

1.2 Abstract #2

  1. Systems as distributed and installed "out-of-the-box" are often loosely configured. This may be due to sloppiness of the distributor. More commonly it is because the distributor has tried to configure a generic appeal-to-all setup. Proper configuration involves the examination of configuration settings of all installed software. This is a prerequisite to fortifying and/or hardening.
  2. 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.
  3. The Internet Domain Survey ( https://www.isc.org/network/survey/) reports the number of hosts advertised in the DNS. As of Jul 2017 it is 1 billion. Perhaps as many as 95% 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 10 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.

1.3 Educational Objectives

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

2 Booting Sequence

  1. 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.
  2. Reviewing inittab and Boot Scripts
  3. Disabling Unneeded Services: See below.
  4. Configuring Services
  5. Closing Network Ports and Disabling Runlevel System Services
  6. Closing Network Ports and Disabling Xinetd Services

3 Files and Installed Software

  1. 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.
  2. 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.
  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 </var/tmp> 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, Sendmail, … . Do we need these?
  6. Securing NFS and samba.
  7. Securing SSH. Copying Files Using SSH Without Providing Login Prompts

4 User Accounts and Passwords

4.1 Strong Password Policy

  1. 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.
  2. Linux: Force Users To Change Their Passwords Upon First Login
  3. Linux turn On / Off password expiration / aging
  4. Search for all account without password and lock them
  5. Use Linux groups to enhance security
  6. 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.
  7. Only root account have UID 0 with full permissions to access the system.
  8. Enable Password Aging. Restrict Use of Previous Passwords. Lock User Accounts After Too Many Login Failures.
  9. Restricting Direct Login Access for System and Shared Accounts
  10. Restricting su Access to System and Shared Accounts

5 Shutdown Sequence

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

6 Lab Experiment

./config-lab.html

7 References

  1. https://wiki.ubuntu.com/BasicSecurity Required Reading.
  2. http://bastille-linux.sourceforge.net/ Bastille "… 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 &quot;proper configuration&quot; instead of &quot;hardening&quot;. 201x. Not actively being developed. Good choice for CEG6420 extra lab work. Highly Recommended Reading.
  3. http://cisecurity.org/ 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.
  4. http://www.debian.org/doc/manuals/securing-debian-howto/ 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.
  5. NIST, http://usgcb.nist.gov/ 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.
  6. NIST, http://nvd.nist.gov/ National Vulnerability Database, 2017. "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.
  7. Ubuntu, https://wiki.ubuntu.com/Security/Features. Even though Ubuntu specific, there is much to learn here. Required Reading.
  8. https://resources.sei.cmu.edu/asset_files/WhitePaper/2006_019_001_496737.pdf UNIX Configuration Guidelines 2017

8 End

Copyright © 2018 www.wright.edu/~pmateti • 2018-09-10