[unisog] Password auditing
hhoffman at ip-solutions.net
Fri Jul 1 03:18:57 GMT 2005
There is something around that claims to do this already...
For the life of me I can't remeber but I think it's Inspector Javert (or
something similar). Google doesn't reveal anything immediately but it's
probably just the search terms.
I favor the idea of semi-priv accounts using ldap where you can brute
force those entries (but also lock access to many different systems with
Having local accts is a very good thing... and you can use something like
cfengine to keep master shadow files and distribute them to each server
over a encrypted channel.
By keeping things in ldap and having master shadow password files you can
determine (and implement) expiry. Same thing with AD, I suppose.
Also, if you are a sudo fan it's supports the use of LDAP as well. :-)
there are of course problems with ldap... like the whole single password
for many accounts... but you could solve that with different OU=s (this
gets messy tho).
You would probably also want to just keep a report as to the amount of bad
passwords and perhaps the people but remove the password files as soon as
they are cracked. Encrypting these reports would also be a good idea.
On Fri, 1 Jul 2005, Russell Fulton wrote:
> First off, thanks to those who responded to my post on ssl and mysql. I'm now investigating the native support in 4.0x
> This time I have an idea for automated auditing of UNIX password (it may be extended to windows, I don't know). Firstly I'd like to know if any of you can shoot holes in the proposal before I spend time implementing it and secondly I'd love to know of someone has already done this or someting that achieves the same end.
> The idea is that the service would reside on a well secured ;) 'server', let's call it cracker. Clients who want to use the service create an account on their system and set up permissions so that the account can see /etc/shadow (or perhaps we have a suid root program that cats /etc/shadow - probably safer - opinions?). This account also has the ssh key for cracker in its authroized_keys file. We would also use ssh configuration to limit the scope for abuse of the account.
> First visit to the client we suck up the password file and beat the *** out of it with John, this may take a little while. Once this is complete the client is added to one of two pools depending on whether any weak passwords were found.
> The first pool contains machines with weak passwords, for machines in this pool we regularly send admins email warning them of the weak password. If they don't get changed we can either escalate the problem to the security team or perhaps disable the accounts (another suid program?).
> Machines in the second pool are visited regularly (daily?) we look for changes to the password file and try and break any new ones. If we succeed the machine goes into the first pool
> Any holes in this theory?
> The biggest problem I can see is that the 'server' will hold copies of all the password file, these should be encrypted while not actually being compared. I don't see this as being much different to an AD or Kerberos server.
> The second weakness is the account on the client with access to /etc/shadow, tips on securing this would be helpful.
> Am I out of my tree?
> Cheers, Russell
More information about the unisog