Make sure you close the door all the way when a user takes their leave
I am personally of the opinion that if one doesn't trust one's users from the beginning, then they will one day prove themselves untrustworthy. (Of course, I've never had to admin an open shell server at an ISP, either.) At any rate, building trust with your users from the beginning will go a long way toward being able to sleep at night later on.
When you do have to lock old accounts up, it's best to proceed strategically. Don't assume that just because you ran a passwd -l that the user in question can't regain access to your machine. Let's assume that we're locking up after an account called luser. Here are some obvious (and some not so obvious) things to check on in the course of cleaning up:
passwd -l luser
Obviously, locking the user's password is a good first step.
chsh -s /bin/true luser
This is another popular step, changing the user's login shell to something that exits immediately. This generally prevents a user from gaining shell access to the server. But be warned, if sshd is running on this box, and you allow remote RSA or DSA key authentication, then luser can still forward ports to any machine that your server can reach! With a command like this:
luser@evil:~$ ssh -f -N -L8000:private.intranet.server.com:80 old.server.com
luser has just forwarded his local port 8000 to your internal intranet server's http port. This is allowed since luser isn't using a password (he is using an RSA key) and isn't attempting to execute a program on old.server.com (since he specified the -N switch).
Obviously, you should remove ~luser/.ssh/authorized_keys* and prevent luser from using his ssh key in the first place. Likewise, look for either of these files:
This usually isn't a problem unless you're running rsh, or have enabled this functionality in ssh. But you never know if a future admin will decide to enable .shosts or .rhosts functionality, so it's better to remove them now, if they exist.
Did luser have any sudo privileges? Check visudo to be sure.
How about cron jobs or at jobs?
crontab -u luser -e atq
For that matter, is luser running any jobs right now?
ps awux |grep -i ^luser
or as in [Hack #17], you can use:
skill -KILL luser
Could luser execute cgi programs from his home directory (or somewhere else)?
find ~luser/public_html/ -perm +111
What about PHP or other embedded scripting languages?
find ~luser ~public_html/ -name '*.php*'
Does luser have any email forwarding set up? Forwarders can frequently be made to execute arbitrary programs.
less ~luser/.forward grep -C luser /etc/mail/aliases
Finally, does luser own any files in strange places?
find / -user luser > ~root/luser-files.report
One safe (and quick) way of ensuring that all of
luser's personal configuration
files are invalidated is to
/home/luser.removed. This will keep the contents of
luser's home directory intact,
without worrying about having missed other possible points of entry.
Note that this will break a legitimate .forward
file (and also ~luser/public_html and any other
publicly accessible data that luser might have
kept in his home directory), so if you go this route be sure to take
that into account (say, by adding an appropriate entry to the system
aliases file, and moving a cleaned version of
public_html/ back to
Look at configuration files for any system software to which luser had access, particularly services that run as privileged users. Even something as innocuous as a user-supplied Apache configuration file could be used to provide shell access later.
This list is by no means exhaustive but is meant to demonstrate that there is a lot more to revoking access than simply locking a user's password. If this user ever had root access, all bets are off. Access could later be granted by anything from a Trojan system binary to an invisible kernel module to having simply changed the root password.