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

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?
3. Correctly configure the used services (or turn them off until you are prepared to configure them).
4. Configure /etc/hosts.allow and /etc/hosts.deny to allow only used services, and only from the correct sources.
5. Configure the kernel security parameters (See Kernel Parameters for help on this.)  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.  List your partitioning scheme and state what quotas you would set for (a) a junior administrator, (b) a web developer, and (c) a student.  (See quota administration for a refresher on setting up quotas.)
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.conf.  What limits would you impose for (a) all users, (b) software developers, (c) multi-media developers, (d) students, and (e) 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, before running su):

   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'
   

   (Which should consume all available CPU cycles.)

   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 necessary).  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.  From a text console, log in and comment out the limit for nproc.  (Or you can try to determine a working value fron 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 seperate login session in a different 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. 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. Run any or all of the following security auditing tools:
    • Bastille Unix/Linux
    • Fedora sectool
    • Lynis

    to finish hardening your system.  Personally I've used and been impressed by Bastille.  But I'm not sure it has been updated to support Fedora 9 or newer systems.  To use it, follow the directions at the Running Bastille On link.)  If you have trouble or don't trust it fully, use Fedora's sectool instead.  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 wise to have Bastille (or any vulnerability scanner) automatically update your system.  It would then be difficult to know what was done or how to undo it!  Instead run the tool in a report-only mode and manually fix any problems it reports.  (Carefully updating your journal for each change.)  When done, run the report again to make sure you 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?

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.