Detecting user account being disabled in real time on a trusted system. (IDS9000 won't do it)

[Kurt Renner]

Like most organizations, security is becoming increasingly more important to ours. Although detecting the fact that your systems are under attack is multi-faceted, and no single method will capture all attempts to hack your system, it is widely accepted that password cracking is one of the most popular methods a hacker will use to gain access to your systems.

One of many mechanisms we want to deploy to ensure we are aware of hacking attempts is to recognize real-time when a user account gets disabled for whatever the reason. We have converted all our systems to "trusted systems", and are deploying IDS9000 in our environment to provide an audit trail. Unfortunately, Although IDS9000 tracks many system events (logins, logouts, failed logins, among many other conditions) it does not trap account lockouts.

We currently monitor locked accounts by using the getprpw command to filter out those accounts with a lock on them. The problem with this method is that it will only capture those accounts that are locked at that specific point in time. An account can be locked out numerous times throughout the day, but if it is not locked when the getprpw command runs, no one knows any lockouts occurred.

Does anyone have any suggestions on how we might capture all account lockouts in real time? A getprpw command run at frequent regular intervals would be more likely to capture MORE of these occurrences, but still would not capture ALL of them.

Any suggestions would be appreciated.

Thanks,
Kurt

[Darren Prior]

Hi Kurt,

A few thoughts/opinions I had on this topic:

If you're running getprpw from cron to check at some fixed interval it should only miss accounts that were locked, but have been unlocked by root. If you make the assumption that the root account hasn't been compromised, then any unlocking should be visible either in samlog or in root's history. Your handling of the root account should be such that there are a minimum number of people and they are accountable - additionally you could have something like sudo in place. If root has been compromised then it's possible that any traces will have been swept away.

Along the same lines you could monitor the mod dates on the files in /tcb/files/auth - and then run getprpw only on those that have changed since the last iteration. It's potentially less work than running getprpw on every user on each iteration.

Another possibility is to create a PAM module that logs lockouts to some suitable logfile. I don't know PAM in much detail so this could be a red herring!

regards,

Darren.

[Kurt Renner]

Thanks for taking the time to respond Darren. I appreciate the feedback.

Valid points in the first paragraph. However, I tend to assume the worst will happen if we come under attack, and the root account will be compromised by someone who is likely to be able to cover their tracks. It would also be quite complicated to automate gathering the information for reporting purposes, and would not be a real-time type capture which is what I would prefer.

As for the times on the /tcb/files/auth... files, if I have to revert to capturing the locked account information on a regularly scheduled basis, I will consider doing that.

I like the PAM module idea. However, I haven't a clue on where I would go to find information in implementing this sort of solution. Any pointers to some documentation I could use to get there would be appreciated.

Finally, I obviously would like to have the solution built into IDS9000. This seems like an obvious event that should be captured. I will submit an enhancement request to HP to get that event trapped.

Thanks,
Kurt

[Bill Hassell]

Once an account is locked out, it takes root to unlock it so I'm not sure how an account would be locked then unlocked several times a day unless there is a cron job that unlocks every account on a regular interval (bad idea). There are a couple of resources to track attempts at password guessing: one is the list of locked accounts due to password misses, and the other is lastb which reads the /var/adm/btmp file. lastb should always be run with the -R option to show the hostname/IP_addr of the attempt.

I would treat each account lockout as a potential security problem and using getprpw, decode the reason and the time/date, then determine (from the user) what the problem was. Interview the user and if the user did not actually try to login, leave the account locked and create a new login for the user (of course reminding the user never to share login and passwords) and move their $HOME files to the new directory. Then monitor lastb to see where the attempts are located.

If the system is a high risk machine (ie, data and/or applications are critical) then look at SSH for all remote access and don't allow Xwindows applications to run on the box. Use Bastille as an automated checklist to harden the system.

[Wouter Jagers]

As Bill said: it's time for you to implement ssh !

When you want to implement some kind of security, the first thing to do is to get rid of telnet: you're publishing all your root passwords (the correct ones !) onto the network in clear text.

Also, ssh will log every unsuccessful logon attempt in the syslog like this:

"Feb 9 15:29:13 machine01 sshd[997]: Failed password for username from 192.168.0.100 port 55235 ssh2"

Many, many other great features of ssh can be described (secure copy, x-forwarding, keypairs, ..) but will be yours to explore.

Regards
Wout

[Steven E. Protter]

If you are really interested in Security(i believe you are) you want to make a few long range decisions:

1) Eliminate telnet ssh replaces it.
2) Eliminate ftp sftp/scp replaces it.

Both these two items do their user authentication in clear text which makes them insecure.

3) Stop using the r- protocols, remesh,rexec etc.

To the actual issue at hand.

If its really important to know when accounts lock up you might want to purchase tripwire from http://www.tripwire.com. This can pick up changes to the configuration files and might pick up the tampering or bad logins you are trying to detect.

Careful reveiw of btmp output helped me catch a hacker who was dutifully trying to set up a second root account on one of my webhosting business Linux servers.

The first step to security is software. The second more important step is attitude. Thats where I find many organizations are not up to snuff. They want to be secure but don't want to pay for software to replace telnet with ssh on the desktop.

SEP

[Kurt Renner]

Thanks for the response Bill.

Under normal circumstances (all circumstances as far as we know), it is an authorized root user unlocking accounts. I'm wanting to catch the event _anytime_ an account is locked out. We have procedures in place when an account is unlocked by an authorized root user, so if it is a regular occurence, followup with the end-user will be performed, and some additional monitoring will be done.

Until recently, we only knew an account was locked in the first place when a user could not access the account, and called to have his/her account unlocked. I have an automated process in place to report those accounts that are locked out on a daily basis now. When asked by our security department "If an account was locked/unlocked before the script reports all the locked user accounts runs, will those user accounts show up in the report?", my answer was "No.". I've been "challenged" to collect all occurences of locked HP-UX accounts.... for auditing purposes if no other.

We feel our machines are secure, and have taken many steps toward that in the past year. This is more for reassurance than a fear that we do not have an effective security policy in place.

[Paula J Frazer-Campbell]

Kurt

I do not run trusted systems but where is the account locked flag set? I would place a monitor on this and fire a warning off when a new account is flagged, also carrinh with lastb info.

Paula

[Paula J Frazer-Campbell]

that shold be :_

I do not run trusted systems but where is the account locked flag set? I would place a monitor on this and fire a warning off when a new account is flagged, also carring with this warning lastb info.


Paula

[Paula J Frazer-Campbell]

Kurt

HERE:-

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=114928

Paula

[Paula J Frazer-Campbell]

Kurt
based on somthing like this:-

/usr/lbin/getprpw | grep alock=YES

if a positive return then push > alock.txt

and lastb -R | grep >> alock.txt



HTH

Paula

[Bill Hassell]

Since SAM uses /usr/lbin/modprpw, you can create a wrapper script to replace modprpw which will log the time/date it was run in syslog.log. Just rename the executable to modprpw.orig and put the attached script in it's plcae (make sure it is executable). Then look in syslog.log for the results. You can also modify the script to email you (or a pager) whenever modprpw is run.

[Kurt Renner]

That's a good idea Bill. It's after-the-fact though. I wish there were a similar solution to capture the act of the account being disabled rather than when it is re-enabled. That's what I'm really after.

I might be able to use this idea in some fashion though.

The main drawback (IMHO) to putting a wrapper in place though is it will break when patches are applied for modprpw.... generating more system administration tasks to keep track of.

Keep thinking... maybe you'll come up with the answer! ;-) There's 10 points in it for you! :-)

I appreciate the feedback!!!

[Sridhar Bhaskarla · Accepted solution]

Hi Kurt,

Enabling PAM module with debug option and then configuring syslog to receive messages can show you account disabled messages instantaneously. However, it will be difficult for scripting as the 'disabled' messages do not carry the account name.

For ex., on a 11i system, entry for login in /etc/pam.conf

login auth required /usr/lib/security/libpam_unix.1 debug

Entry in /etc/syslog.conf

*.debug /var/adm/syslog/syslog.log

Restart syslogd.

Try to login unsuccessfully for a test account and see if the login disabled message displayed in your syslog.log.

Feb 9 14:04:05 mysystem login: pam_acct_mgmt: error Account is disabled - see Account Administrator


-Sri

[Kurt Renner]

Thank you Sridhar. Now we're getting much closer to what I'm after.

If I can just find a way to monitor syslog for this message continuously (I'll probably writa a Perl script) and match up the "Account is disabled" message with a user account, I'll have what I'm after.

[Kurt Renner]

I have since come up with a way to get what I want (almost), and wanted to update this posting so others could benefit if interested.

My original posting said "IDS9000 won't do it". That's still a true statement, but it can enable a solution.

IDS9000 provides the administrator access to each and every tracked system event via a "response" script. I have developed a response script that identifies when an alert is generated dealing with logins. If the login is not successful, my perl script attempts to identify whether or not the user account has been disabled. Unfortunately, the IDS9000 subsystem runs as user account "ids", and the getprpw executable requires "root".

I have a call open to HP to help resolve the permissions restriction. The IDS9000 manual specifically warns against setting the setuid root for programs requiring root permission. It says instead to use "fork/exec" to run programs requiring more privileges. I have yet to determine how to do that from within a perl script. Hopefully HP can help there. Any suggestions welcome!

Thanks,
Kurt

[Steven Sim Kok Leong]

Hi,

What about using sudo to elevate the execute permissions? Don't recall any recent security issues with sudo.

Hope this helps. Regards.

Steven Sim Kok Leong

[Kurt Renner]

Steven,
That might actually work, but we do not currently have sudo in place. I may investigate that as a possible solution.

Thanks for the response.