Operating System - OpenVMS
1748108 Members
4887 Online
108758 Solutions
New Discussion

Re: SCAN_INTRUSION failing to disable users

 
SOLVED
Go to solution
John McL
Trusted Contributor

SCAN_INTRUSION failing to disable users

I've created a test program to check user logins and I'm doing the usual password check and then calling sys$scan_intrusion.  After 5 incorrect passwords, 5 being what SYSGEN parameter LGI_BRK_LIM is set to, the returned status switches from SECSRV$_SUSPECT to SECSRV$_INTRUDER but despite SYSGEN parameter LGI_BRK_DISUSER being set to 1 (it's a boolean value), the username in question - which is a valid username - doesn't get disabled in SYSUAF.

 

As I read it, the documentation for $SCAN_INTRUSION says that the user should be disabled (pg SYS2-349 of Sys Services v8.3 manual).

 

What am I missing here ?

 

(PS.  What an awful sysstem this new forum is.  It took me more than 5 minutes to find out how to post a message.)

11 REPLIES 11
Dennis Handly
Acclaimed Contributor

Re: SCAN_INTRUSION failing to disable users

>It took me more than 5 minutes to find out how to post a message.

 

Did you check the FAQ:

http://h30499.www3.hp.com/t5/help/faqpage/faq-category-id/posting#posting

Hoff
Honored Contributor

Re: SCAN_INTRUSION failing to disable users

Um, if a sufficient number of the members of the intended audience have to find and read a FAQ to learn how to perform core functions of web forum software, then the designers of that forum software have failed at their task.

Hoff
Honored Contributor

Re: SCAN_INTRUSION failing to disable users

Is this server also running V8.3, or some other version?  Patches?   Is ACME external authentication enabled?

 

What access path for the (failing) users are you testing here?  (Some of the older VMS and tools versions had issues with how ssh verified its in-bound users, for instance.  DECnet SET HOST or telnet are likely the most reliable checks, FWIW.)

 

Same source address for the attacks?  (I'd expect so, based on your description, but it's worth confirming.)

 

What are the LGI* settings?

 

I'd also try a reboot to ensure the parameters are registered.  Yes, LGI_BRK_DISUSER is dynamic, but I don't know off-hand if that value is re-read each time a login is performed.  Some of the server software only reads dynamic parameters at launch.

 

I'd usually suggest enabling password filters and certificate-based logins before resorting to LGI_BRK_DISUSER.  (There are certainly cases where LGI_BRK_DISUSER is appropriate, but that also enables a trivial DoS attack against those servers.)

 

And the usual recommendations for current patches apply here, of course.

 

John McL
Trusted Contributor

Re: SCAN_INTRUSION failing to disable users

Hoff,

> Is this server also running V8.3, or some other version?  Patches?   Is ACME external authentication enabled?

This is being developed on one system but the target is another and I know it's on v8.3 but I don't know what patches and would need to ask someone because I don't have access to it.  (To be honest I had hoped that someone would see my message and recognise a problem that they'd previously seen and fixed!)

We had ACME but dropped it.  Something about its reliability.
 

> What access path for the (failing) users are you testing here?  (Some of the older VMS and tools versions had issues with how ssh verified its in-bound users, for instance.  DECnet SET HOST or telnet are likely the most reliable checks, FWIW.)

see next comment

> Same source address for the attacks?  (I'd expect so, based on your description, but it's worth confirming.)

Access path is from Windows PCs.  The intent, directed by auditors, is to prevent people being able to fail several times on one PC, then move to another PC and try again. These auditors don't seem to realise that what they are asking for goes beyond normal VMS access security for direct VMS logins.


> What are the LGI* settings?

On the development machine where $SCAN_INTRUSION isn't disabling the user account

LGI_CALLOUTS = 0
LGI_BRK_TERM = 0
LGI_BRK_DISUSER = 1
LGI_PWD_TMO = 30
LGI_RETRY_LIM = 3
LGI_RETRY_TMO = 20
LGI_BRK_LIM = 5
LGI_BRK_TMO = 300
LGI_HID_TIM = 120
 

> I'd also try a reboot to ensure the parameters are registered.  Yes, LGI_BRK_DISUSER is dynamic, but I don't know off-hand if that value is re-read each time a login is performed.  Some of the server software only reads dynamic parameters at launch.

Rebooting is not an easy option with a heap of other developers working on the same system.  I've created a workaround.  It just wasn't helpful to not have VMS systems services operate as documented.

> I'd usually suggest enabling password filters and certificate-based logins before resorting to LGI_BRK_DISUSER.  (There are certainly cases where LGI_BRK_DISUSER is appropriate, but that also enables a trivial DoS attack against those servers.)

I wish ... but there's an urgency to this job.  Yes, the auditors don't seem to know or aren't concerned that the SYSTEM account could be attacked the same way and a DISUSER on that account is a bad thing.

 

> And the usual recommendations for current patches apply here, of course.

I've ended up creating my own version of what I expected $SCAN_INTRUSIOn to do.  Depending on whether the entered password is correct, the status return from $SCAN_INTRUSION and the login fails in SYSUAF, I might increment the login fail count, disuser the account if fail count exceeds LGI_BRK_DISUSER, or reset the fails to 0 and clear intrusion records if the password is correct.

I would rather $SCAN_INTRUSION did all this - and VMS engineers supported it - but...

 

PS.  As for this forum, the most important action is to post messages but when the method should be front and center it's not simple and obvious and is a few steps down in Help and an FAQ.  This makes no sense to me. 

Hoff
Honored Contributor

Re: SCAN_INTRUSION failing to disable users

I'd likely ensure that the ACME pieces and settings were backed out correctly, as it's possible that hasn't happened here.

 

If you're patched to current and if ACME has been backed out correctly and if you've tried the reboot as a test, then ring up HP support for a look.

 

John Gillings
Honored Contributor

Re: SCAN_INTRUSION failing to disable users

John,

   Some dumb questions...

 

 If you generate failed logins directly does the username get DISUSERed?

There are several optional parameters for $SCAN_INTRUSION. Are you taking defaults or populating them?

What (if any) audit alarms are generated?

What does the output of SHOW INTRUSION show at each transition?

 

If you must set LGI_BRK_DISUSER, I'd be recommending increasing LGI_BRK_LIM to something well above "fat finger" threshold. Maybe 20?

 

 

A crucible of informative mistakes
John McL
Trusted Contributor

Re: SCAN_INTRUSION failing to disable users

John,

 

It's a bit academic now because we have a workaround, but my comments might help someone else trying to work with $SCAN_INTRUSION or maybe some HP person making corrections !

 

I've just tested DISUSERing directly via SET HOST 0 and found that I had to exceed LGI_BRK_DISUSER before the flag was set in SYSUAF.  The documentation for $SCAN_INTRUSION says "Disables user accounts if the LGI_BRK_DISUSER flag is set and the number of login attempts on a real user has reached LGI_BRK_LIM"  (Note! "has reached").  Sure enough, when I exceeded LGI_BRK_DISUSER the account was disuser'ed as we'd expect.

 

I also found that the AUDIT journal did not contain the node name that I passed as a parameter to $SCAN_INTRUSION but recorded the terminal on which I was running the software that passed a dummy node name.

 

The first situation above shows that the documentation is not precise.  The second bothers me a bit because it means that $SCAN_INTRUSION data appears to not be passed to the AUDIT systsem, which means we won't have a permanent audit of where breakin attempts are coming from.

 

John McL
Trusted Contributor

Re: SCAN_INTRUSION failing to disable users

What's more, $SCAN_INTRUSION documentation says that the routine performs the function "Audits login failures or break-in attempts on behalf of the caller".

 

Tests show that the source_node is NOT written to the Audit journal, only the username and the terminal where I was running the test harness.  (In fact the test harness used my own username so I can't be sure whether $SCAN_INTRUSION used auditing the username given in its call or the one for the current process.)

John McL
Trusted Contributor
Solution

Re: SCAN_INTRUSION failing to disable users

I'm closing this thread.

 

We have a workaround(as described above).  An even better solution would be to examine all the SUSPECT and INTRUSION records in the intrusion database and treat them "in total".  This would prevent potential hackers just switching to another terminal or access point (e.g. in a large office with many staff) and improve account access security without resorting to LGI_BRK_DISUSER.