VMS Login prompt disconnects after 20 seconds?

[johnslayton1]

Hi,

What security benefit does OpenVMS systems have when the login prompt dissapears after idle after 20 seconds??

IS this because to avoid sessions that tend to be hogging most CPU time?? Or, is this an advanced security feature?

Thanks.

[Robert Gezelter]

John,

It is not a question of CPU time. LOGINOUT is hardly a CPU intensive process.

The "benefit" of terminating an otherwise idle "Login:" prompt is the LOGINOUT process that is running on that terminal and the network connection if it is a network login of some sort.

I have not timed the default recently, so I will admit that I do not remember offhand what the default value is.

Before we go further, perhaps you could be so kind as to identify the OpenVMS version?

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel]

>> What security benefit does OpenVMS systems have when the login prompt dissapears after idle after 20 seconds??

None.
It's 99% there to annoy folks.
It's 1% there to avoid wasting memory resources.

That 1% surely is the original reason of this 'feature'. Actually, the feature is fine, the 20 seconds annoys me immensly as you can tell. It's too short! Make it 10 minutes and I'm cool with it.

>> IS this because to avoid sessions that tend to be hogging most CPU time??

What CPU time? It is just sitting there for a terminal/network QIO to complete. ZERO cpu.

The cost of the wait is a process slot, and a QIO, and maybe (in days gone by) a line from a modem pool.

Way back when, folks tuned systems with limited memory to have just enough process slots. I have not seen a system with restricted process slots in the last 20 years.

The price for this timeout to fire pre-maturely is 100 times larger than for it not happening (IMHO!). I don't connect to a system 'accidently' and if I do I'll control-Z out. So if the timeout fires on me, then dollars to donuts I will re-start the login, costing a wind-down + accounting record for the old process, a new prcoess create, and a slightly ticked-off customer.

>> Or, is this an advanced security feature?

No, just a poorly chosen, or dated, default.

Thanks!
Hein.

[0 points for this reply please.
Oh, you don't do points anyway do you?]

[johnslayton1]

Its an DEC/Alpha server running OpenVMS 7.1-2

So what type of security benefit does this have as its really kind of annoying??

[Robert Gezelter]

John,

I admittedly do not have time to check, but on one of my systems the default value is 30 seconds. If I am correct, the parameter is LGI_PWD_TMO and is documented, among other places, in the HELP text for SYSGEN.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Your immediate and chief concern here is that you can't successfully log into an OpenVMS system within the window of approximately thirty seconds, and are encountering the prompt timeout, correct?

That this isn't a question of security, prompts, or system performance, or such.

As for your wish to avoid the prompt timeout, consider the use of ssh and certificates, or enable and use single sign-on, or enable and use the ALF (automatic login facility), and avoid the password prompt. And the timeout.

Or consider disabling passwords entirely, either on your username, or on all usernames.

Any of which will avoid the login-related timeout.

These suggestions can or do introduce various degrees of insecurity. But they do avoid the timeout.

[Volker Halle]

John,

this timeout value seems to be controlled by the LGI_RETRY_TMO system parameter.

Just increase LGI_RETRY_TMO (it's a dynamic parameter) and your Username: prompt will stay around much longer (tested on V7.3-1).

If the timeout would have been infinite, you could be wasting some resources (network connections, process slots, some memory and pool). So you could effectively consume lots of resources without even having logged in to the system. The implementation of the timeout value prevents this.

Volker.

[David Jones_21]

The SYSGEN help desciption for LGI_RETRY_TMO implies that the motivation was to ensure that dialup connections would be resolved in a timely manner (carrier is dropped after LGI_RETRY_LIM failures). Phone lines are still a scarce resource, but few people connect that way anymore.

[John Gillings]

>It is not a question of CPU time. LOGINOUT is hardly a CPU intensive process

Don't be so sure! Some history for your amusement...

Back around 1990 I had a call from a customer complaining that he'd found a LOGINFAILURE in accounting that had consumed 2 days of CPU time. He couldn't understand why.

Later he called back to say he'd worked out that an operator had knocked over a TK50 cartridge onto the ENTER key of a terminal. This had resulted in the "Username:" prompt rolling over for the whole weekend.

We experimented with the most powerful system we had at the time, an 8200, and discovered that with only FOUR terminals and TK50 cartridges ;-), we could bring the system to it's knees, saturating the CPU with Username prompting. This was escalated as a potential denial of service attack.

Possibly as a result (or maybe it was already on the drawing board), the LGI parameters give more control over how logins and failures are handled. You no longer get a continuous stream of prompts. The process fails after LGI_RETRY_LIM attempts, which is enough to prevent CPU saturation, and certainly prevents LOGINFAILURE processes with prodigious CPU consumption.

[Robert Gezelter]

John (Gillings),

Mea Culpa! Indeed, lOGINOUT (and its equivalent functions on other systems) can indeed bring the system to its knees if confronted with a stream of never ending input.

While I did not do this with a TK50 cartridge, it was easily accomplished using the loopback switch on modems in a modem bank, and the first broadcast to all terminals could bring the system down.

- Bob Gezelter, http://www.rlgsc.com

[Wim Van den Wyngaert]

BTW on a 400 Mhz AS 500.

CPU used by decw processes

1) holding enter : 15% cpu
2) displaying the output of dir : 95% cpu + 5% taken by the fta process.
3) idem 2 but in a remote session : 99% cpu + 1 for the fta session

I have a few alarms per years for users doing a dir/fu and going for a coffee. Or running a program displaying (a lot of) debug info.

fwiw

Wim

[Wim Van den Wyngaert]

Just found out that the return on username also results in intruder alarm. Every 15 returns it says "user authorization failure". And this builds up to intrusion.

Fwiw

Wim

[Wim Van den Wyngaert]

While trying all ways to login I found that ftp logs intruders based upon their IP address. So 1 user can block all ftp requests coming from a node. Nice.

fwiw

Wim

[Richard W Hunt]

For those who say that this login timeout is not a security feature, I beg to differ.

(Only part of this post is tongue-in-cheek.)

Government directives such as Dept. of Navy's CTO 2006-04 and CTO 2006-07 mandate that a session that gets started by a remote connect source must complete the connection within a time limit or be forcibly ejected. They say it is a security issue. I, being a puny little contractor, have no chance in Hell of convincing anyone that it isn't so much of a problem.

Therefore, by direction of the US Navy, that timeout is there for your security. And because it is there, my system can comply with Navy rules.

Now, having said what I said, there is this to consider: It might or might not help security, but it IS a resource issue if you are in a network address translation environment. It is just that the resource being conserved isn't on the Alpha, it is on your NAT'ing firewall appliance. Ditto for proxy services.

Now, if this becomes a resource issue, then it IS a security issue, too, because of the concept of Denial Of Service. If I can do something that denies service to a machine - by consuming all the resources used to get to it - then there really IS a security factor to consider.

You must remember that security doesn't stop at the shell of the server's enclosure. The paths leading to it are important, too. And if you can drop the silent session, you are helping to conserve resources used to access your system.

[Robert Brooks_1]

Later he called back to say he'd worked out that an operator had knocked over a TK50 cartridge onto the ENTER key of a terminal. This had resulted in the "Username:" prompt rolling over for the whole weekend.

--

Thanks for giving me another reason to dislike
TK50's :-). Then again, I'd take a TK50 any day over a TU58 . . .

Side note -- a TK50 with a TQK70 controller was not a bad combination!

-- Rob