[unisog] Password auditing
r.fulton at auckland.ac.nz
Fri Jul 1 09:54:18 GMT 2005
Peter Van Epp wrote:
> We tend to attack this problem from the other end (but may be more
> centralized than you can be). We have a home grown account management system
> that pushes the passwords to both LDAP and AD. Password changes take place in
> the master database (after being run through cracklib, which I don't think
> is set tough enough and our user support folks think is facist, overly paranoid.
> unneccessary and a variety of less printable things). I've been told that
> somewhere around 6 tries is the average to get an acceptable password which
> common wisdom is then gets written on a yellow sticky.
we do this too for our central authentication system (and yes we get the same complaints), however there are a fairly large number of systems on campus that don't use this for authentication. Even if they do use the central system for authentication there are often still a few local accounts (root for one). The main aim of this is to check any changes that happen to the local system accounts and to alert the admin.
This activity was prompted by crackers getting in to a linux server on campus earlier in the week. The machine was fairly well administered but had some (fairly specialised) third party software installed on it which apparently had installed an account with a default password. The attackers got in via ssh brute force which had these credentials in the list (we got the attack script from the machine. The machine was fully patched and (so far as we could tell) the attackers failed to get root although they did try some local exploits. Don't worry ;) we wiped the system anyway.
So yesterday we were sitting around wondering what we could do to defeat this sort of problem. Yes we all know admins should regularly review the password file -- how many actually do?
Both Steve and Dave make good points about dictionary based auditing but I worry that that would not have helped in our case earlier in the week. Dictionary based attacks and defences are only as good as the dictionaries you have access to and unless you can add in what the latest attack tools are using you are going to miss things.
Hmmm... Dave do you know if anyone collects these lists and colates them? I've go one hot from the forensics ;)
"My' way would give you both dictionary based defense and a selectable level of brute force protection as well as alerting the admin to additions and deletions to the user list but at the cost of fairly intrusive mechanisms (for want of a better term).
It may turn out that the best way of doing this is to use a standard integrity checking system to detect changes in the password file and prompt admins the check it.
More information about the unisog