[unisog] Password auditing

PaulFM paulfm at me.umn.edu
Fri Jul 1 13:40:23 GMT 2005


The best defense is to make sure that the users that can come in through the 
network are controlled (so new default users can't log in through the 
network).  An added security measure is to change su so it is not suid (in 
other words it is only useful to root) or at least limit who may use the 
program (FreeBSD does this by default).   while you are at it, look at the 
way you mount exported partitions on your servers (they should be mounted 
nosuid, noexec, nodev) - note that those mount options do not affect the 
mount options of clients.

ssh can be configured to allow only users in a group (or list of groups) to 
log in at all (don't forget to include root if you want root to log in with ssh).

Last - instead of copying the shadow file, take an MD5 hash of the password 
and shadow file (after you first check them).  And raise an alert if either 
changes.

I think it is a bad idea to act as Uber-admin on a machine you don't manage 
(it will actually cost you more time then just taking over full 
administration of the machine).
Segregate those machines so they can't damage the managed machines, and do 
what you can to make the network secure (maybe block incoming connections to 
unmanaged machines, and force people to come into your network through a 
managed machine).

User's will always find a way to create a bad password, the only way to get 
them to create good ones is to tell them why a good password is important. 
Tell them the truth, that criminal gangs are working feverishly - not just to 
get their data - but to get access to their machine so they can set up a 
spam-bot and monitor keystrokes so they can get passwords to other machines. 
  That there are several nuts out there whose goal in life is to break into 
as many machines and networks as possible, and they will stop at nothing to 
achieve their goal.  And that there may be a few jokers in-house who break 
into other peoples accounts (to place the blame on someone else), so they can 
download music (or do other things) without being caught.


Russell Fulton wrote:

> 
> 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.
> 
> Cheers, Russell.
> _______________________________________________
> unisog mailing list
> unisog at lists.sans.org
> http://www.dshield.org/mailman/listinfo/unisog

-- 
---------------------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
---------------------------------------------------------------------
Paul F. Markfort   Info/Web: http://www.menet.umn.edu/~paulfm
---------------------------------------------------------------------


More information about the unisog mailing list