CTS 2311 (Unix/Linux Security) Project #2
Harden a Linux System

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


In the project, you will begin to harden your freshly installed systems.  System hardening requires many steps including the correct configuration of services and firewalls, in order to meet the goals of the applicable security policies.  The steps involved depend on the use of the server, its location (behind a firewall, in the DMZ, etc.), and the industry the server is used for (financial, health, public company, ...).

We will defer the more involved steps for now (such as DNS, Web server, and mail server).  For this project you should perform the following list of basic system hardening tasks, that apply generally to all hosts and servers.  For each step, be sure to record any changes made to your system in your journal:

  1. Review various post-install setup tasks.  (A partial list can be found at PostInstall.htm.)  What steps were taken (list in sufficient detail so someone else could reproduce them)?
  2. Turn off all unused services.  If in doubt, turn it off!  You can always turn the service back on later.  What services did you turn off that were on by default?  What services did you leave enabled (or were off by default and you decided to enable)?
  3. Correctly configure the used services (or turn them off until you are prepared to configure them).  What configuration did you change, and/or which services did you temporarily disable?
  4. Configure /etc/hosts.allow and /etc/hosts.deny (TCP Wrappers) to allow only used services, and only from the correct sources.  What changes did you make?
  5. Configure the kernel security parameters (See Kernel Parameters for help on this.)  this is done by using the /proc interface, or the sysctl command (and config file), if available.  At this time you only need to make certain your system is not acting as a router, by not forwarding IP packets.  What parameter must you set for this?
  6. Configure user quotas.  (Since your computer likely has only one user, this is just for practice.)  List your partitioning scheme and state for each storage volume, what quotas you would set for
    1. a junior administrator,
    2. a web developer, and
    3. a student.
    (See quota administration for a refresher on setting up quotas.)  If you wouldn't set any quote for some storage volume in some situation, you should say “no quota needed”.
  7. Configure user account restrictions and resource limits.  This can be done in a couple of ways, such as setting ulimit limits in the global shell profile, or with PAM by editing /etc/security/limits.confWhat limits would you impose for
    1. all users,
    2. software developers,
    3. multi-media developers,
    4. students, and
    5. administrators?
  8. Try the following experiment:

    Edit /etc/security/limits.conf and add lines for yourself (here I'm using “auser” but use the user ID that you logged in as, not root of course):

    auser        hard    nproc   20
    auser        hard    cpu     1
    auser        soft    core    0 

    Next become yourself, “auser” in the example above (just exit from the su shell), and run:

        perl -e 'do {} while 1'

    (This should consume all available CPU cycles until it is stopped.)

    Login using one of your other virtual consoles and watch your system with the “w” and/or the “top” commands.  What happens after the perl process uses more than 1 minute of CPU time?

    Next, switch back to the first console and stop the Perl process (if it is still running).  Now log out and log in again.  If you used the GUI console, you may not be able to fully log in!  This is because gnome starts more than 20 processes when you log in, and we set a limit of 20 processes max.  From a text console, log in and comment out the limit for nproc.  (Or you can try to determine a working value from Gnome and KDE.)  Now you should be successful when you log in using the GUI console.

    Finally re-run the Perl program (from the console you just logged in from), and monitor it as before from a separate login session in a different virtual console.  What happens this time after 1 minute of CPU time?  What happens if you re-start the Perl script a second time from that same session?

    Undo the changes made to limits.conf for your login.

  9. Configure logging and log rotation, if needed.  Note that a post-install step is to verify all log files get rotated.  Which log file(s) on your system (if any) were not rotated by default?
  10. Configure security policies using PAM and other available mechanisms (e.g., SE Linux).  Describe any changes made, as well as the security policies you are trying to implement.
  11. Install and then run at least one of the following security auditing (also called vulnerability scanning) tools:

    to finish hardening your system.  (Note that not all tools are current, or work at all for your version of Linux.)  Please keep in mind that such scanners and auditing tools generate some false positives, so you shouldn't just blindly follow any “fixes” these tools suggest!  If in doubt, try to research the item on the Internet.

    If uncertain which tool(s) to use, try Lynis to generate a security audit report on your system.  Carefully read the available help (on any of these tools) before using!

    Which scanner(s) did you use?  What was the exact command(s) used?

    It is not always wise to have any vulnerability scanner automatically update (make changes to) your system.  It would then be difficult to know what was done or how to undo it!  Instead, run the tools in a report-only mode, and manually fix any problems they report.  (Carefully update your journal for each change.)

    When done, run the tool(s) again to verify you have fixed all problems you need to address.  What changes did you make as a result of running host vulnerability scanner(s)?  What problems were reported that you did not address?

  12. Security Compliance Auditing

    The final part of this project will be to conduct an enterprise security compliance audit, using modern, U.S. government-approved SCAP (Security Content Automation Protocol) tools.  You can use the OpenSCAP tool oscap, or the Red Hat tool secstate, both available for Fedora, to conduct an audit.  Personally, I prefer using the GUI SCAP tool scap-workbench.  Several methods will be described below, but you need only do one of them.

    SCAP was created to provide a standardized approach to maintaining the security of enterprise systems, such as automatically verifying the presence of patches, checking system security configuration settings, and examining systems for signs of compromise.  It can then report problems, or use a configuration management system (OpenSCAP uses Puppet) to effect changes.  The items to be checked (called content) are in a standard XCCDF format, or OVAL format (used internally with XCCDF).  (Most tools can import either XCCDF or OVAL content.)  Such a scanner is simple; the clever part is using different content to check for issues and/or compliance with various security standards and best practices.

    The easiest way on a modern Fedora system is by using the scap-workbench GUI tool and the content available in the Fedora yum repos.  You need to install the tool and content with:

       dnf install scap-workbench scap-security-guide

    Then just run the tool, use that content, and examine the report.  Easy-peasy!

    Some other tools and content sources are described next, but if the scap-workbench and scap-security-guide content work for you, you do not need to try these alternatives.  Don't forget to answer the question at the end of this section.

    Alternative SCAP Tools and Content Sources

    To use OpenSCAP's oscap utility, you need to import “content” for your particular system.  You can find XCCDF content for Fedora from fedorahosted.org (this content is apparently for RHEL 6, but that is probably close enough), from rpm.pbone.net, or from rpmfind.net, but it is easier to get content (and the tools) from the system's standard yum repositories.  (The yum repos may not have the most updated content for your system, however, it is probably good enough.)  SCAP content can also be downloaded from nvd.nist.gov, both for specific products and for some whole systems, such as Red Hat Enterprise Linux (but not Fedora).  Remember, it is possible to use content for a similar system, so you can probably use content for RHEL 7 for a Fedora 20 system, for example.  (Just be careful about false positives!)

    Once the content (an XML file) has been imported into the tool's database, you then enable which checks to use.  (Should be all of them.)  Finally, you run the audit and generate a report.  Note, each step can take many minutes to complete!

    You one (or both) of the following methods to conduct your SCAP audit (steps shown are for Fedora 14 SCAP content; use appropriate content for your system):

    1. dnf install openscap openscap-utils openscap-content
    2. oscap xccdf eval --profile common \
           --results ~/xccdf-results.xml \
           --report ~/xccdf-results.html \
           --cpe /usr/share/xml/scap/ssg/fedora/ssg-fedora-cpe-dictionary.xml \
    3. oscap xccdf generate --profile common fix \
           --output ~/xccdf-fix.sh /usr/share/openscap/scap-xccdf.xml

    Here's alternative steps using the content from fedorahosted.org:

    1. wget -O /etc/yum.repos.d/epel-6-scap-security-guide.repo \
      dnf install scap-security-guide
    2. oscap xccdf eval --profile stig-rhel6-server \
      --results /tmp/$(hostname)-ssg-results.xml \
      --report /tmp/$(hostname)-ssg-results.html \
      --cpe /usr/share/xml/scap/ssg/content/ssg-rhel6-cpe-dictionary.xml \
    3. firefox /tmp/$(hostname)-ssg-results.html 

    What errors were found by the security audit(s)?  What changes did you (or should you) make as a result?

To be turned in:

A copy of your journal pages, describing each task you performed to harden your server, and the answers to the questions asked.  You can send as email to (preferred).  If email is a problem for some reason, you may turn in a hard-copy.  In this case the pages should be readable, dated, and stapled together.  Your name should appear on the first page. 

Don't turn in your whole journal, just a copy of the relevant sections.  It is common in fact to keep the journal as a text file on the system (with a paper backup of course).

Please see your syllabus for more information about submitting projects.