lgi_brk_disuser and SSH not working

[Aaron Sakovich]

Hi.

OpenVMS 7.3-2, TCPIP 5.4 ECO 6.

I've got lgi_brk_disuser set to 1, and lgi_brk_term set to 0; lgi_brk_tmo is set to 5 minutes (300 seconds), and lgi_brk_lim is 5.

A user yesterday attempted to login using SSH. She tried 18 times(!), failing each time per the audit logs, for about 25 minutes. As expected, after the 5th attempt, her attempts were logged as breakin attempts by the auditing subsystem. However, she should have been disusered once this started happening. She wasn't.

She should have been prevented from logging in for 90 minutes (18 failed attempts * 5 minutes per). She wasn't.

She logged in about 25 minutes later after her SSH session (using Reflection v14 client on her end) prompted for a password change and she changed it.

(First person to say "HP recommends against setting lgi_brk_disuser to 1" gets a big fat 0 points. 8^) (BTW, HP does NOT recommend against it, they say it should be set "only under extreme security watch conditions", which I qualify for. I understand the ramifications of this setting, and I've been running this way for over 5 years WITHOUT a single problem. Discussion over.)

Why are none of these security settings working? Why was a user who flagrantly violated their password policy allowed to login?

[Ian Miller.]

was the source that the user appeared to be loggin in from the same for each login attempt?

[Aaron Sakovich]

Hi Ian,

Good question. Yes, as indicated by the audits and the fact that the intrusion was flagged as a breakin attempt. I should have also mentioned that I have lgi_brk_term set to 0.

Aaron

[EdgarZamora]

From my experience here in my site, when we get failed attempts from SSH users, the username is usually shown as TCPIP$SSH. I would say that's why the system is unable to disuser the user (because it doesn't know what username to disuser at that point).

[Aaron Sakovich]

But that wouldn't take into account the fact that this:

Security alarm (SECURITY) and security audit (SECURITY) on WOODY, system id: 7178
Auditable event: Network login failure
Event time: 22-JAN-2007 07:26:56.27
PID: 2051EC4B
Process name: TCPIP$SS_BG5780
Username: TCPIP$SSH
Remote node fullname: SSH_PASSWORD:1.2.3.4
Remote username: WEBER(LOCAL)
Status: %LOGIN-F-NOTVALID, user authorization failure


gets turned into this:

Security alarm (SECURITY) and security audit (SECURITY) on WOODY, system id: 7178
Auditable event: Network breakin detection
Event time: 22-JAN-2007 07:42:49.46
PID: 205271C4
Process name: TCPIP$SS_BG7054
Username: WEBER
Password:
Remote node fullname: SSH_PASSWORD:1.2.3.4
Remote username: WEBER(LOCAL)
Status: %LOGIN-F-NOTVALID, user authorization failure

[EdgarZamora]

Hmm... you get better info in your messages. Mine comes out like this:

%%%%%%%%%%% OPCOM 23-JAN-2007 10:35:15.20 %%%%%%%%%%%
Message from user AUDIT$SERVER on CLCC
Security alarm (SECURITY) and security audit (SECURITY) on CLCC, system id: 2131
Auditable event: Network breakin detection
Event time: 23-JAN-2007 10:35:15.20
PID: 0017EA95
Process name: TCPIP$SS_BG3042
Username: TCPIP$SSH
Remote nodename: SSH_PASSWORD:MLE
Remote username: SSH_808AF214
Status: %LOGIN-F-NOTVALID, user authorization failure

Maybe because my SSH remote sources are not VMS? Sorry I wasnt of help.

[Aaron Sakovich]

Then permit me to help you: the output I got was from the audit facility, not Operator.log, which appears to be where you got yours.

$ Analyze /audit /full /since=yesterday /before=today sys$manager:security.audit$journal /event=breakin

I've got a job that runs daily and extracts separate reports for login, logfail, breakin, sysuaf, rightsdb, file access, and much more; it prints one copy of each to a hardcopy printer for our audit logs, then a second copy to a web page for me to examine.

[John Gillings]

Aaron,

I think the clue is in the audit messages. Note that they're classified as "Network login failure" and "Network breakin detection". The help for LGI_BRK_DISUSER doesn't qualify what constitutes an attempted breakin, but I'm betting that it only applies to Interactive breakins.

For some reason SSH logins aren't treated the same as other kinds of interactive connection. You may have seen discussion about things like forced password changes, and other stuff associated with interactive logins not happening for SSH connections.

There are fairly good arguments for treating "true" network connections differently from interactive connections in terms of password handling. The trouble here is the way SSH is implemented blurs the distinction (or, is arguably just plain wrong!).

Log another case with HP Customer Support?

[Hoff]

Who knows what evil lurks within the heart of the TCP/IP Services SSH server implementation of user authentication and management? (The Shadow knows...)

But seriously, I'd encourage direct contact with the good folks at the HP support center, particularly given that this does appear to be a security-relevant problem.

Stephen Hoffman
HoffmanLabs

[Aaron Sakovich]

"The Shadow knows..."

Hoff, I thought you WERE the Shadow!?! Oh, wait, no, that's Wizard. Gotcha. 8^)

Thanks for the feedback folks -- based on this sanity check, I'm going forward with logging a call on this one. Even if it is just the subtle distinction between a network vs. interactive login, something really does appear to be wrong.