prevent telnet access to root

[Daryl Much]

is there a way to prevent telnet access to root account?

problem- the security scans keep locking the root account.

we can't disable telnet - it's needed to support legacy clients.

/etc/securetty prevents root telnet logins. however it doesn't prevent bad password checks which when repeated often enough will lock the root account.

this problem does not happen w/ ssh ("PermitRootLogin no" in sshd.conf).

using modprpw I could set umaxlntr to a larger value but I'd prefer root logins be aborted before a bad password locks the account.

fortunately I have a script that will alert me if root is locked but I'd rather not have to unlock all the root accounts on servers after the scans.

Thanks,

Chuck Davis

[Sanjay_6]

Hi Chuck,

Even if the root account gets locked in this manner, you can still login as root from the console. Can't you ?.

Hope this helps.

Regds

[John Poff]

Hi,

One idea is that if you know when you are running your security scans and that it will lock the root account, you could plant an 'at' job to unlock the root account shortly after the security scan finishes.

JP

[Daryl Much]

Sanjay - yes I can login via console. However I usually permit ssh logins too and the telnet logfails breaks the ssh ability until I reset the account.

John - good thought. I get an email whenever it locks (checking the alock value from getprpw) and could easily modify to unlock. However, it would be nice if the login program would check the user and securetty before checking the password and locking.

[Steven E. Protter]

A console login will unlock the root account in the event that its been disabled by bad logins.

It is further possible to force root login from another user using the su - root command.

as root

echo "console" > /etc/securetty

You can disable telnet access from certain hosts such as your securty probe machine in /var/adm/inetd.sec

telnet deny 10.1.*

Then just inetd -c to apply he changes.


SEP

[Daryl Much]

SEP- thanks. I didn't realize console login would re-enable.

and yes it is good that su is not affected by alock value.

the securetty is already established.

the inetd.sec (as well as hosts.deny) trick, well the security folks are already wise to that one and will use an arbitrary ip address from which to conduct scans.

at this point I think I'll have to live w/ the annoyance of locked roots after scans. no big deal really but I didn't like to have to unlock just so my ssh logins would work. It seems that the login program should check for securetty >before< checking the password. this would prevent someone from sending the real password in cleartext if they acccidentally tried to telnet or ftp.

Thanks for the speedy input folks!