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:
su
to switch to that user ssh user@host /bin/uname -a
CGI
scripts from user directories
(e.g., ~/public_html
) crontab
and/or at
jobs crontab
and/or at
jobs ~/.forward
and
~/.procmailrc
configuration files
The problem is the obvious
way to lock user accounts by
running the command
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.
passwd -l user
There are many ways to lock out a user, including:
/etc/passwd
and changing the
password (the second) field, by (say) using a
*
/etc/passwd
and changing the
password (the second) field to empty /etc/passwd
and changing the
shell field to empty /etc/passwd
and changing the
shell field to some non-valid shell
(one not listed in /etc/shells
) /etc/shadow
by editing the
password field, by adding !
or !!
to the front /etc/shadow
and changing the
password field to empty /etc/shadow
by editing the
password field, by adding *LK*
to the front sshd
, login
, cvs
,
crond
and atd
,
system-auth
(this is the main one on Red Hat
systems), etc. /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.
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?
In addition to filling in the table, you will submit a list of the experiments you performed, with details for each one including:
diff
listings for any modified configuration
files.) 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.
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
.
(This setup is known as a test fixture.)
|/home/username/some-shell-script
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.