root account becoming locked

[Drew Roberts]

The root account on one of my servers keeps becoming deactivated because of too many incorrect logins.

The root password was changed 2 days ago - and it seems something out there is still trying to use the old password.

Monitoring of getprpw shows the logins incrementing every 10 minutes, 5 unsuccessful logins at a time. For example:
ulogint=Wed Mar 15 13:15:28 2006
culogin=5

ulogint=Wed Mar 15 13:25:28 2006
culogin=10

ulogint=Wed Mar 15 13:35:28 2006
culogin=15

lastb -R and syslog don't have any matching entries. ???

Any suggestions would be greatly appreciated.

Andy

[A. Clay Stephenson]

Look at uloginy, this may give you a clue where these requests are coming from. I would also enable logging on inetd. This has the appearance of a cron on another host.

[Drew Roberts]

Thanks for the quick response.

uloginy = -1

I have inetd -l running. But I still don't see anything at the associated time in syslog.

I've checked the cron jobs on my other servers and there aren't any running every 10 minutes. Searching past similar issues that sure seems like the likely culprit, but the timing doesn't add up.

[A. Clay Stephenson]

My next cut at this would be to only allow root logins at the console by setting up an /etc/securetty file. This will still allow you to login as a regular user and su - root. Are you allowing rlogins or ftp logins that might be using .netrc files? You at least need to get a handle on where these logins are coming from. I would shutdown rlogind, ftpd, and telnetd -- in that order until the culogin count stops increasing. It's also time to ask are there any applications which use the telnet, rexec, or rlogin protocols to make connections from clients?

[Kent Ostby]

Andy -- check for scripts that get kicked off one time, but may sleep for 10 minutes.

Also, what about EMS or other monitoring tools?

[Kent Ostby]

Another thought is to change the password back and capture where the logins are coming from and then work backwards from there.

[Bill Hassell]

Be sure to also start logging ftp connections (add the -l option to inetd.conf) and if you have sshd running, make sure it is logging in detail. Also check /var/adm/sulog -- someone might be using some remote shell connection that performs an automated su. The suggestion for /etc/securetty will likely stop the direct logins but things like ftp and su may be the cause.

[Drew Roberts]

Thanks to everyone for your suggestions so far. I'll be doing more looking into this in the next week and will let you know what the solutions turns out to be.

Andy