CTS 2311 (Unix/Linux Security) Project #4
Preventing Access (Locking Out Users)

 

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

Description:

Locking out user accounts is not simple.  You need to consider what access each account has been granted and how to prevent each.  Examples of access include:

  1. Console logins (using passwords)
  2. Remote logins with SSH (using passwords)
  3. Remote logins with SSH (using keys)
  4. Using su to switch to that user
  5. FTP access
  6. sFTP and scp access
  7. Running remote commands (using SSH), for example ssh user@host /bin/uname -a
  8. Running key-specific commands via SSH
  9. Protected Web content access (including running CGI scripts from user directories (e.g., ~/public_html)
  10. Source code access (via CVS for example)
  11. Database access (both local and remote)
  12. Creating new crontab and/or at jobs
  13. Running existing crontab and/or at jobs
  14. Running commands via email ~/.forward and ~/.procmailrc configuration files
  15. Sending or receiving email
  16. Accessing file shares via NFS and Samba (CIFS)

The problem is the obvious way to lock user accounts by running the command passwd -l user doesn't prevent most access!  Indeed, if using LDAP or some other authentication system, locking accounts this way may not prevent any access!  Finally, preventing access with one method may work on some operating systems but may work differently (or not at all) on others.  You need to learn how to prevent various types of access (to implement that part of your security policy), and how to determine how to do so on any given system.

There are many ways to lock out a user, including:

  1. Editing /etc/passwd and changing the password (the second) field, by (say) using a *
  2. Editing /etc/passwd and changing the password (the second) field to empty
  3. Editing /etc/passwd and changing the shell field to empty
  4. Editing /etc/passwd and changing the shell field to some non-valid shell (one not listed in /etc/shells)
  5. Editing /etc/shadow by editing the password field, by adding ! or !! to the front
  6. Editing /etc/shadow and changing the password field to empty
  7. Editing /etc/shadow by editing the password field, by adding *LK* to the front
  8. Editing PAM configuration files for various services including sshd, login, cvs, crond and atd, system-auth (this is the main one on Red Hat systems), etc.
  9. Service specific configuration, including editing/creating /etc/ftpusers, /etc/ssh/*, /etc/mail/* (and /etc/procmail*), /etc/httpd/*, and others for database and other services

To prevent some set of access you may (and probably will) need to use some combination of lock-out methods.

Requirements:

In this project you will experiment with a few different account locking methods, to determine which access is allowed or denied for each of several types of access.  Even for a single operating system (Fedora Linux in our case) this can be a time consuming project.  This is therefore a group project. On the class wiki page you will find a table listing different access attempts (rows) and different locking mechanisms (columns).  You will need to fill in your share of this table, indicating if the access was permitted or denied in each cell of the table.

You should decide early which experiements you plan to run by putting your name in the cells you plan to fill in.  This will reserve those experiments.

For each experiment you run you must take careful notes on how you tested the access.  A poorly run experiment is worse than useless, since it could mislead you when you need to secure a system in the real world.

To prevent all access a combination of locking methods may need to be employed.  For example, after examining the filled-in table, how would you prevent all access to a remote user on a Fedora Linux system?  How would you prevent most access but still allow existing cron jobs to run?

To Be Turned In:

In addition to filling in the table, you will submit a list of the experiments you performed, with details for each one including:

Include a copy of your journal pages shown any (final) changes made to your system, and the answers to the questions asked above.  Don't forget to complete your portion of the table on the wiki.  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.

Hints:

The best way to complete this assignment is to create a large number of new user accounts, one for each locking method.  That is, create one set of accounts that use password protection and another set that uses SSH keys for access.  Then for each set, have one unlocked account and one account locked using each method and combination of methods you plan on testing.  This will be a lot of accounts, but once set up it will make the rest of the lab much simpler.  Be sure to give your accounts descriptive names (you can use the GECOS field to provide details.  For example you might have accounts like this:

unlockedpw:x:500:500:unlocked account using shadow password:/home/unlockedpw:/bin/bash
unlockedkey:x:500:500:unlocked account using SSH keys:/home/unlockedssh:/bin/bash
shadowstar:x:500:500:locked account using "*" in shadow file:/home/shadowstar:/bin/bash
...

Once all the accounts are set up, you can start running experiments.  For example, to test if crontab jobs can run, for each account create a crontab (and possibly an at) job that writes a message to the screen (using wall) or does some other simple action you can easily test.  Or to test mail access, create a ~/.forward file with the contents of |/home/username/some-shell-script.  (This setup is known as a test fixture.)

First you should run the experiments that don't require SSH or other fancy setups, including console and SSH login with passwords, running cron jobs, creating new crontab or at jobs, or running a shell script via the email's .forward file.  Attempt to upload or download a file using FTP.  (Note you may have to install and then turn on some FTP server for this.  Make sure it is working before you attempt this with the locked out account(s)!)

Now create some SSH keys on your second host, and add the new public key to ~/.ssh/authorized_keys file on the first host.  Repeat the experiments, this time using remote ssh, scp or sftp access from a second host.