Attack on root password

[YLTan]

I have a prod. server with HP Trusted System and with n number of retries before root is locked. I also have disable remote telnet for root account. Specific User group are use to to "su" to root to gain access. If I disable the retries on root, I am subjected to Brute Force attack.

I would like to enquire what if an attack on root password by making several unsuccessfull login to root just to disable it.

And also another point I note for the number of retries on password could prompt hacker to keep a list of known password that doesn't work. Over time he may be able to make intelligent guess on the root password that works.

How does HP Trusted System address such attack?

Our process to recover/restore root passwd after the account is disable is very complex.

I heard about "Password Evading" mechanism in VMS system where the a/c is not lock but evading mechanism activated after n tries. During this evading period, even with correct password it still can't login. It have to wait either the evading period expired or sysAdmin have to deactivate the mechanism.

Does HP Trusted System have such similar capabilities??

[Patrick Wallek · Accepted solution]

No, HP-UX does not have any "password evading" mechanism, though that is an interesting concept.

The basic principle that HP-UX uses, you already know. After XX number of incorrect login attempts, the account will be disabled.

If the root account gets disabled, it is not difficult to reactivate it. Even if the account is disabled you can ALWAYS log in to the console and then do a modprpw to reactivate root.

[Steve Steel]

Hi


If your root account is disabled you can always login as root on the console and re-enable the account.

If a password is mixed alphanumric and reasonably long it is hard to crack and advice is to change regularly.


Another simple one is to add a check to /etc/profile something like


if [ `who am i | awk '{ print $1 }'` = root -a `tty` != "/dev/console" ]
then
echo "Error: root logins are only allowed on the console. "
exit 1
fi


Then any root login not on the console will log back out.


steve Steel

[John Dvorchak]

In my humble opinion, the best thing to do is to change the root password periodically, never longer than every 60 days. Don't reuse passwords, and don't give the password to anyone that you wouldn't let date your daughter. Keep the passwords a combination of upper and lower case letters, numbers and punctuation. Don't use an @ sign in the password, it messes up the console.

[John Bolene]

we use root and another security user as root

passwords have to be at least 7 chars and one char has to be alpha, one numeric, and one special char

they are aged at 30 days, which we have griped about, make it 32 so it at least is on a monthly cycle

if root gets disabled, the security user can reenable it

[Darren Prior]

Hi,

There's certainly some interesting points in your posting.

With regard to the concept of a hacker keeping a password list and attempting to retry; on a trusted system you should keep the number of retries on this account low. You should also choose your passwords wisely (perhaps using some of the restriction methods - ie number of alpha chars, number of numerics, etc) and change them regularly. This should reduce the chance of an attack where someone is recording passwords and retrying.

If you increase the number of retries, it is less likely than someone will get the account disabled through excessive retries, but they're more likely to be able to find the password - this is where the complexity of the password will help.

It is a matter of balancing the requirements of password ageing and retries with the likelyhood of someone attempting to hack the system.

regards,

Darren

[Steven E. Protter]

You've taken some good steps already.

I personally would think about a firewall even the HP firewall to protect your system.

You should be able to figure out what the source IP address of the hacker is and set up /var/adm/inetd.sec to block that IP address from any access to your machine.

Further, I recommend the steps below:


security_patch_check: Checks your system and makes sure its up to date with security patches from HP
http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B6834AA


Required Perl install

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=PERL

Bastille: Security Hardening Tool

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B6849AA

TCP Wrappers

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=TCPWRAP

Secure Shell: a replacement for rcp ftp and telnet that encrypts passwords

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=T1471AA

IDS/9000 Intrusion Detection System which can track security breaches and attempted security breaches.

Attached is Chris Vale's paper on how to set up passwordless services by exchanging public keys.

SEP

[Steven E. Protter]

You've taken some good steps already.

I personally would think about a firewall even the HP firewall to protect your system.

You should be able to figure out what the source IP address of the hacker is and set up /var/adm/inetd.sec to block that IP address from any access to your machine.

Further, I recommend the steps below:


security_patch_check: Checks your system and makes sure its up to date with security patches from HP
http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B6834AA


Required Perl install

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=PERL

Bastille: Security Hardening Tool

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B6849AA

TCP Wrappers

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=TCPWRAP

Secure Shell: a replacement for rcp ftp and telnet that encrypts passwords

http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=T1471AA

IDS/9000 Intrusion Detection System which can track security breaches and attempted security breaches.

Attached is Chris Vale's paper on how to set up passwordless services by exchanging public keys.

SEP

[Chris Vail]

You can limit direct root logins to the console, with /etc/securetty. This is what we've done here. Attached is the document we use here to harden HPUX 11.0 systems.

Like the others mention, you can set the number of tries before disabling the root account. However, be careful with this.

Our root password had an @ in it. Our facilities people insisted that we use a Dell LCD rack-mountable keyboard/screen as the main console to the service processors for our 2 V-class machines. The V-class doesn't have a console: they have these processors (a B180L workstation) connected with thin-net, of all things. The Dell keyboard doesn't send the @ symbol for some reason. So we locked out the root account last weekend when we were scheduling maintenance on the system. Without a console, the only thing we could do was to reboot to single user mode. Fortunately, we had taken Oracle down by going in with secure shell, and also detached the system logically from the SAN. So the only complaint was from HPUX itself. But we changed the password instantly.

Following the hardening document will make your system a lot more secure. If you want total security, lock your CPU in a bank vault and unplug it. Anything short of that, and you'll have to have some compromises in your security plan. However, the compromises mentioned here are not too bad.


Chris