Who is disabling root ?

[S.Rider]

I have a root account on a server that's constantly gtting disabled due to "excessing unsucessfull login attempts". Nothing exciting in sulog, nothing exciting in lastb either, nothing in syslog.log either.
It was happening every 10 minutes, so I checked cron.log on this server, nothing there either. So I guess it's another server trying to connect to this guy.
I use getprpw and can see culogin steadily climb.
It could be any one of 100 unix servers using rsh or ssh to try connecting to this server. I'm going to hit up the network guys to check out traffic on the ssh port (hoping that's the issue), but what else can I try on the unix end to track it down ?

[Steven E. Protter · Accepted solution]

Shalom,

lastb

parses the file /var/adm/syslog/btmp

Bad logins.

There is a command line parameter -R (check the man brain is fuzzy) that will let you see the source of bad logins. It will display ip or hostname of the offending server.

lastb | grep root

If you are exposed to the internet, even via port forwarding you may be the victim of script kiddies. In that case, stop direct ssh login.

The network guys aren't really going to be of much use unless you need help tracing the ip address from lastb. You have all the tools on your system to figure this out.

SEP

[S.Rider]

Thanks for the thoughts.

The information shown by "lastb -R" doesn't show anywhere near enough invalid-logins to match up with the unsucessfull-login-count increase shown by getprpw. For example, the count shown by getprpw got as high as 892 before I "sudo su -" to reset it, but lastb only showed 58 lines. (I have a script that displays getprpw info every 30 seconds so I can watch the unsucessfull login count increase. So I'm guessing the unsucessfull-login-count increase is NOT being cause by someone actually trying to login to the server, or by someone trying to su on that server.
I'm guessing it's someone on another server doing a "ssh cmd" that's causing the issue.

[Steven E. Protter]

Failed su - logins are logged by lastb

58 bad logins is enough to disable your root account several times a day depending on what the settngs are.

Standard settings for a trusted system are three bad logins and the account is locked.

60 bad logins an hour is enough to lock the root password every 10 minutes.

a script that uses getprpw might be helpful if its providing more useful info.

SEP

[S.Rider]

lastb is missing something.
lastb shows the last entry at 13:15 today.
yet looking at the output of my script that shows getprpw every 30 seconds shows the culogin increasing by 1 every 10 minutes. So someting is causing the unsucessfull-login-count to increase, without showing up as an invalid login. I would have thought they would match.

[Denver Osborn]

What's your /etc/pam.conf look like? Also, if pam is configured for anything other than unix, are there any root entries in the pam_user.conf?

-denver

[Denver Osborn]

...and if you suspect failed attempts from ssh, they should be logged in the syslog (or whatever SyslogFacility is set to).

Have you looked at the syslog to determine which host the attempts might be from since lastb isn't returning what you'd expect?

-denver

[spex]

S.Rider,

'tcpdump' may be useful in determining the source of the login attempts.

PCS

[A. Clay Stephenson]

I would also enable logging on inetd. This is actually one of the easiest attacks because root is a known login.

[Josiah Henline]

A good suggestion is to set PermitRootLogin to no. Also editing /etc/securetty to contain the word console will keep the root account from being locked out. This will make su or sudo the only ways to access the root account. If this is not an option you can set up a cron job to run "modprpw -k root" every 5 minutes or so.

[Steven E. Protter]

I like the suggest after A. Clay's.

inetd -l

to temporarily implement A. Clay's suggestion.

inetd.conf can be modified to make it permanent.

I'd say your /var/adm/btmp file is being hammered. That could be a cron job, it could also be the work of a malicous attacker trying to cover his/her tracks.

I recommend taking the system of the network for a few moments.

remove the btmp and wtmp files and put them back with standard permissions as in root can only write to them.

Also check last and see if there are unexplained successful logins.

It is possible your system has already been hacked. I doubt it, but can not discount it. When I was new and did not know what btmp and wtmp were for I once wrote a cron job to reguarly remove them.

Later I changed that to copy, archive and then zero them out.

> /var/adm/syslog/wtmp

> /var/adm/syslog/btmp

SEP

[Josiah Henline]

If you enable logging for inetd, ftpd, sshd telnetd, etc., you can impliment the use of an /etc/hosts.deny file. This will help but not solve your issue.

[S.Rider]

Thanks for all the ideas, here's what I've found so far.

/etc/pam.conf only authorize unix stuff in there.
sshd_config/SyslogFacility set to the default of AUTH
No errors n syslog.log - I can see "normal" ssh messages there and if I purposely do an invalid ssh, it shows up.
/etc/securetty exsists wth console
I can always get back into root thru the console to unlock it, so even easier (sudo su -) but the problem is "ssh to this server will NOT work when root is disabled". Unless someone knows of an option to permit ssh-to-root even if root-is-disabled.
I have to leave "PermitRootLogin" set in sshd_config. We have too many features ssh'ing between the servers.
We know we could get around the issue by doing a "sudo" or a "modprpw -k root" periodically but we want to fix the issue. Besides we want to know who's doing it.

I'm pretty sure the problem is related to some monitor or SIM job. I'll tackle the increased logging next but around here, "the pope has to approve stuff like that".

[A. Clay Stephenson]

In most environments the Pope has to approve decreases in logging but increases are ok. In any event an "inetd -l" command (or the equivalent "kill -3 inetd_PID") will toggle logging on and off with each use. I suspect that if you will leave the logging on for 20 minutes or so, syslog.log should have captured your errant host.