Stop Root account being disabled by failed direct login attempts?

[Mike755]

HPUX 11.31 looking for ways to stop the root account (direct login not allowed) from being disabled when attempts to login  (example would be a security trace scan) are done.   Looking for options on how to prevent it being disable but yet still keep unauthorized users/processes from accessing the root account.

With Linux I know you can use "denyhosts" set with something like 2 attempts until ip-ban.  We have Ipfilter and HIDS so maybe something in there or a combination of other tools would work on HPUX similar to this?

i.e..  See the attempt to login directly as root, deny them after 2 attempts and report it to us that it occurred?

Any ideas, thoughts or direction would be awesome.   Kind of a cool project hoping one of you expert level folks might already be doing something like this on the HPUX 11.31 servers.

[Mike755]

Is there nobody out here concerned the root account becomes disabled on failed attempts (like running security scans or maybe an actual security breach) where we would rather terminate the request prior to the root account being disabled?

To me makes more sense to not allow some outside source to disable your root account and report the attempt to login unsucessfully. 

HP folks you out here?  Does IPfilter maybe have some whitelist/blacklist feature to terminate the session after two attempts prior to the root account being disabled?

[Mike755]

We have HP support so I'm going to open a case with them on this since not getting too much input.  I'll post back what I discover working directly with HP on this.

Thanks

[VK2COT]

Hello Mike755,

Very interesting question and worthwhile!

a) Firstly, privileged account can always log in via console, even if

it gets disabled. So, the risk of "locking out" this account is

not an issue in any decent company.

b) HIDS certainly can alert when events such as failed logins.

For example, a Failed Login detection template checks the number of failed logins

within a given time interval on a host system. Both the number of failed attempts

and the time interval are configurable. If a user fails to correctly login and the

triggering criteria are met, an alert is issued.

Then, as long as HIDS is recent version, "Halting Further Attacks" is possible.

Automated response can halt further attacks by changing an attribute of the system,

including IPfilter config. Some examples of scripts to change attributes of

the system (disable account, disable inetd) are in the HIDS Admin Guide.

Depending on where my next job takes me (I just left HP after 14 years of

employment), I might be able to create a cookbook for your problem.

I would just need access to HP-UX servers :)

By the way, some other security and general HP-UX (also other Unix and Linux)

tasks and cookbooks are on my home pages:

http://www.circlingcycle.com.au/Unix-sources

http://www.circlingcycle.com.au/Unix-and-Linux-presentations

Cheers and best wishes,

VK2COT - Dusan Baljevic

[Mike755]

Thanks Dusan I will check out your links. Good luck with you new endeavors and should be lots of opportunities out there right now with a 14 year backgrond with HP. 

We have other open cases with HP WTEC (Senior level) support who is struggling with the HIDS product for us at this time. It's a piece of garbage for the most part with support at HP having to find the "old dinosaurs" still working there that know in depth knowledge of how HIDS functions.  It's a kluge product that out of the gate doesn't function properly enough for a high volume production environment.  We are in the process of a complete wipe and re-load and then trying to create just a basic "schedule" that will function without too many false positives yet still give us some protection.  HP's default schedule overloads our server (brand new rx2800ix4 in this case) and attempts to "tune" the control files are doing large wipes rather than fine detailed exclusions....anyways whole big hog wash of fun.

With this question on root.  We are hoping something simple with IPfitler can be set to terminate a session after two attempts (like DenyHosts).  If not another tool that could maybe do this (even DenyHosts for HPUX).  The entire console root arguement is a given and that is always a failsafe method to gain access.  Having the account disabled though due to failed login attempts via SSH is not acceptable for our environment.  We should never be in a situation the root account is disabled without some sort of preventive measures to stop it from happening and reporting it's condition.

I can write my own scripts/cronjobs and all that but hoping HP would have something within these suite of products we've paid for that will do the job.

[VK2COT]

Hi Mike,

Firstly, thank you for the kind wishes for my future job.

We will see what happens :)

I am sorry to hear of your issues and understand your pain.

Your points make sense.

I am afraid that there is no automated process to

do what you want on HP-UX without extra work.

I would think that DenyHosts should be relatively easy to

implement on HP-UX. It is based on Python.

Python depot is available on the HP-UX Intrenet Express

media, and at HP-UX Porting and Archiving Centre.

But, as you rightfully said, some homework is required...

Similar alternative, also based on Pythin, is fail2ban.

I used and managed both of them extensively on Linux platforms

in the past.

If my new job takes me to another company which has

HP-UX servers, I will take your inquiry as a challenge for me

to create cookbooks :)

Best wishes,

VK2COT Dusan Baljevic

[Mike755]

That is awesome Dusan congratulation on new job!  I know it's a hot market right now for Sys Admins in general and happy it didn't take you long to get picked up by someone.  You come up with a cookbook I'd take a copy anytime.  =)

Yep....was thinking about maybe downloading a HPUX version of Denyhosts (maybe fail2ban) but still hanging on that HP might have something else to offer.  Check this out what can be done on Linux with DenyHosts....

THERE MUST BE PEOPLE WANTING THIS ON HPUX????

Very cool:

LINUX (DENYHOSTS)

For example I have the following lines in my iptables config:

iptables -N SSH_CHECK
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_CHECK
iptables -A SSH_CHECK -m state --state NEW -m recent --set --name SSH
iptables -A SSH_CHECK -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --name SSH
iptables -A SSH_CHECK -m state --state NEW -m recent --rcheck --seconds 60 --hitcount 4 --name SSH -j DROP

which basically kick-bans the source IP for 60 seconds if more than 3 connections are attempted in a 60 second limit.

I've found this to be 100% effective.

This will watch and if there are more than 3 ssh connections within a 60
second span, new ssh connections will be rate limited. Existing connections
are unaffected, and anything in your white list is unaffected. You can still
make new SSH connections, though it takes a lot longer for the session to come
up.

iptables -N ALLOWED
# accept already establed and related connections
iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
# don't rate limit ssh from the following
iptables -A INPUT -s $WHITE_LIST_IP_ADDRESS -p tcp -m tcp --dport 22 -j ACCEPT
# rate limit on excessive ssh connections
iptables -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ALLOWED
# rate limiting
iptables -A ALLOWED -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A ALLOWED -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A ALLOWED -p tcp -j LOG --log-tcp-options --log-ip-options --log-prefix " DROP RATE_LIMIT "
iptables -A ALLOWED -p tcp -j REJECT --reject-with icmp-port-unreachable


Obviously you would need to integrate this into your existing iptables config.
I personally use iptables-save / iptables-restore to keep and edit my
configuration.

[RJHall · Accepted solution]

Not sure if this is applicable in your situation, but something you could do is run a cron job every X minutes that automatically unlocks the account. (Where X is, say a random amount between 5-30 minutes, depending on your tolerance.) The login failure looks the same whether the account is locked out or not, so you are not suffering much risk from a brute force attack by doing this. The attacker will be unable to determine if their login failed because their guess was incorrect or because the account was locked out. Just make sure you don't give away the timing of the unlock.

[nltebo1]

Hi RJHall,

That sounds like a great idea for the HP UX side. That's what I'm using. I will consider using this.