Terminal Server rather than user is in Intruder Lockout

[Charles Goff]

Running VMS 7.3-2

When a user's # of failed logins exceed the LGI_BRK_LIM, the Terminal Server device itself is locked out so no one else can login from any other terminals attached to the same Terminal Server.

Source is: ::TELNET_0ADD94DA

On our older system running VMS 6.1-2,
Source is: ::Username

We are not running DECnet on the new server.

The Terminal Servers are Xyplex boxes with 40 ports.

LGI_BRK_TERM has been tried at both 0 & 1 with no difference.

We want the individual User Account to be locked out, not the entire Terminal Server.

Any ideas?

[David B Sneddon]

Charles,

What is the output of "SHOW INTRUSION" when you
have the problem?
This will show the "source" of the intrusion and
possibly explain what you are seeing.

Dave

[Charles Goff]

show intrusions shows this:

Intrusion Type Count Expiration
-------- --- ----- -----------
Network Intruder 10 25-jul-2005 08:5:27

Source
-------
caxyplex.ca.us.pri.wyeth.com::TELNET_0ADD94DA

[David B Sneddon]

Charles,

I assume the IP address of the terminal server is
10.221.148.218.
What protocol were you using to connect to the old
system running 6.1-2?
The intrusion is being identified as the above IP
address and since IP has no notion of username (as
DECnet does) then the intruder is considered to the
IP address i.e. any connection from that address.

Dave

[Charles Goff]

You are correct on the IP address.

We always use Telnet (TCP/IP) to connect, but there are observable differences in the Intrusion and Source fields.

If I Telnet to the VMS6.1 system, and fail logins, the significant aspects of Show Intruder looks like this:

Intrusion
--------
TERM_USER

Source
--------
caxyplex.ca.us.pri.wyeth.com::TRAIN1

[David B Sneddon]

Charles,

When connecting to the 6.1-2 system, how does the
username correlate to the user/port?
Is it the username they are trying to login to or
the "name" assigned to the port?
One suggestion would be to track down the user
trying multiple times and "educate" them not to
keep trying if they fail three times... at that
point they should stop and seek assistance (or go
and have a coffee)

Dave

[Charles Goff]

On the VMS 6.1 system , the Username and the Port (as seen Source field) are one and the same.

The only thing I can figure is maybe there is some LAT traffic going back to the Terminal Server to query and obtain username.

We are going to run some tests and look at network traffic.

[Charles Goff]

It simply looks like the old system sees all telnet sessions as TERM_USER types of intrusion class, while the new system sees all telnet sessions as NETWORK types.

The old system sees the source as DNS Name::Username, while the new sees it as DNS name::TCIPIP_

This is true, regardless of source of telnet session, and there is no LAT traffic going back to source.

[David B Sneddon]

Sounds like it is time to educate the users about
how VMS handles login failures...

Dave

[Volker Halle]

Charles,

please read about the TCPIP$TELNET_NO_REM_ID logical - it may help.

Use SHOW USER/FULL to find out on both systems, how TT_ACCPORNAM is set up (depending on the protocol used to login, e.g. LAT, DECnet, TCPIP).

Volker.

[Jan van den Ende]

Charles,

we faced the same problem.

After some discussion with the Security Officer, we could agree that any user logging in from that source is NOT an external intruder.

So, we created a batchjob that runs every 10 minutes to execute the command:
$ DELETE/INTRUSION ::TELNET_0ADD94DA.
Any intrusions FROM THIS IP are regularly deleted, any others are untouched.

In the spirit of translated Dutch proverb:
"If it cannot be done the way it should, it should be done the way it can".

hth,

Proost.

Have one on me.

jpe

[John Gillings · Accepted solution]

Charles,

This is a clash of assumptions.

Intrusion detection depends on being able to identify the precise source of an intrusion suspect. For DECnet and LAT that's easy as both the node and user or port can be positively identified at fine granularity, it's part of the protocol.

For TELNET it's a problem, as TELNET protocol doesn't send a username or other unique identifier, just an IP address.

One mechanism is to use the TTY_ACCPORNAM string as the source. This includes both the address and the remote port number. Since the port number often varies per connection, this effectively defeats intrusion detection from telnet sources, as each new connection attempt will be seen as a new source.

Recent versions of TCPIP reverted to using the TELNET_ format, which means all connections from the same IP address (host, terminal server, whatever) will be seen as the same source. So if one user drives the system into intrusion detection, all others from the same address are affected (this is also a Denial of Service risk).

As suggested by Volker, defining the /SYSTEM/EXEC logical name TCPIP$TELNET_NO_REM_ID will revert to the older mechanism (TTY_ACCPORNAM), but at the cost of reducing the effectivness of intrusion detection of real attacks (and let's be realistic here, most real attacks will be from IP sources, rather than DECnet or LAT).

It's all a tradeoff between security and potential inconvenience. Some of your options are:

1) Revert to LAT for the terminal server.
Pro: does exactly what you want
Con(?): need to run LAT protocol

2) Use TCPIP$TELNET_NO_REM_ID
Pro: "fixes" your problem
Con: Significantly reduced security from IP based attacks

3) As Jan suggests, run a job to periodically clear intrusions for that source
Pro: none! sorry Jan, I think it's an ugly kludge, which I don't recommend.
Con: even more significantly reduced security from that source, additional management to maintain lists of "blessed" sources and make sure the job keeps running.

4) Monitor intrusions more carefully - perhaps sending a page or SMS when one is detected, so it can be checked, and if found to be a false alarm, the intrusion can be cleared quickly.
Pro: Means you'll also know immediately if you're under a real attack
Con: Midnight pages for fumble fingered users?

5) Raise LGI_BRK_LIM to a more reasonable number to reduce the chances that normal accidental login errors will trigger an intrusion. IMHO, the default of 5 is somewhat over paranoid. I don't believe system security would be seriously impaired with a threshold of (say) 50?
Pro: Easy to do
Con: Slightly reduced security


Realisitically, an attacker will either know a valid password, or they will try a brute force dictionary attack. From that perspective the practical difference between an intruder thresholds of 5 or 50, or even 500 is negligible. So my usual recommendation for this situation is to increase the threshold.

You may want to take a more "scientific" approach to choosing a number. For example, you have 40 users, allow half of them 3 attempts within LGI_BRK_TMO, gives an LGI_BRK_LIM of 60.

Monitor intrusion suspects over time to find the "high water mark". Depending on how inaccurate your users are, you may be able to adjust the threshold downwards, without risking false intrusions.

The only issue you then have to deal with is a deliberate denial of service, but someone has to make 60 failed attempts to create one.

[Jan van den Ende]

@John

combine:

3) As Jan suggests, run a job to periodically clear intrusions for that source
Pro: none!

and

Con: Midnight pages for fumble fingered users?


with a 5000 user, 365 * 24 environment; 98 + % of users coming in via named Citrix servers
, a daily count of cleared intrusions from those Citrixes varying between 20 and 60.
And yes, LGI_BRK_LIM is 25!

Now YOU carry the pager for one night, (ehh, one tour of pager duty is a WEEK, rotating with 3 people) and I challenge you to repeat that "Pro: none!"

The only SENSIBLE solution would be to clean up that sorry excuse for a network protocol that is forced upon us, and add a decent source identification to it.

But this would introduce too much potential security, and in a predominantly M$ & *NIX world that is "not needed", if not a downright "breach of privacy".

Sorry for blowing some vent, but I just had to.

Nevertheless:

Proost.

Have some on me.

jpe

[John Gillings]

Jan,

>Now YOU carry the pager for one night,
>(ehh, one tour of pager duty is a WEEK,
>rotating with 3 people) and I challenge
>you to repeat that "Pro: none!"

You want to swap pager stories? Ha! Last week mine fired more than 80 times.

>a daily count of cleared intrusions
>from those Citrixes varying between 20
>and 60. And yes, LGI_BRK_LIM is 25!

For those stats I'd recommend LGI_BRK_LIM be set much higher. Say 100? If your high water mark for normal activity is 60, then 100 should give you plenty of headroom to avoid false alarms, but more than sufficient to thwart any real dictionary attack.

The problem with a regular job to clear your intrusions is that it effectively increases LGI_BRK_LIM to infinite, with no way to detect a real attack. So, I repeat my assertion, "pro: none".

[Antoniov.]

John,
real trouble is vms can't distinguish internal sessions on terminal server from external telnet sessions. So any solution can't solve completely.
I understand, Jan, deletes intrusion records of terminal server addresses, not all records. This is different by set LGI_BRK_LIM to infinite.
What is the best value of this parameter? We know standard value is 5; now if applied to a terminal server with 8 ports, I guess 50% of user can wrong their password, so 5*8/2=20. With 40 ports terminal server may be 5*40/2=100.
Obviusly each system administrator can decide keep more or then security level, so can apply 40% or 60% or any other value.
For me, Jan batch solution is not wrong and is not unsafe.

Antonio Vigliotti