Are all terminals connected to Terminal Server locked out

[TMcB]

Hi everyone

we have recently merged 3 clusters into one big cluster (albeit with separate sysuafs). Users are complaining more about being locked out. I understand that when a user is locked out of SERVER 1, he is locked out from all servers in the cluster for 10 minutes.

But is this the case?? :
We have 5 terminals connected via one terminal server. When a user locks out of one terminal, it appears all 5 terminals are locked??

Thanks

[Steven Schweda]

> [...] being locked out [...]

What, exactly, does that mean?

Is "SERVER 1" a terminal server, or a
computer, or what?

It might help if you showed actual commends
with their actual output, so that we could
see what's happening, instead of trying to
interpret what's happening for us.

> Users are complaining more [...]

So, this phenomenon, whatever it is, is not
new, but only worse?

[TMcB]

sorry for any confusion.

Locked out - They are showing in the VMS break-in database and have to be removed by "dele/intru"
eg :
Intrusion Type Count Expiration Source
--------- ---- ----- ---------- ------
NETWORK SUSPECT 1 22-FEB-2010 14:59:03.50 belflsh-shop-ts01::TELNET_AC19A31B

When one user is locked out, all other 5 terminals which run off the same terminal server are locked out.

Is there a way to stop this - ie - only the one terminal is locked and not all 5.
Thanks

[Hoff]

Assuming this is a fairly recent version of OpenVMS and assuming these terminal server devices are using IP and assuming that you've looked at and found the entries in SHOW INTRUSION and assuming then DELETE /INTRUSION (possibly quoting the target specification for non-alphanumeric characters that might be there), then have a look at the particular IP stack around for how to tailor the evasion processing to your particular requirements; that some terminal servers can present as and can be audited as the same source is the usual trigger for this, and that can usually be customized via LGI_BRK_TERM to zero to evade just on username, but this assumes you're not using the same username for everybody.

As for another approach that might be assumed feasible here, http://openvms.hobby-site.com/pivot/entry.php?id=55

I'll assume you know that multiple UAFs and the rest of the shared files within a cluster must be synchronized, or things can and variously do get seriously wacky. The files are listed in SYLOGICALS.TEMPLATE in V7.2 and later.

[Jan van den Ende]

TMcB,

This is a well known side-effect of an intended reaction.
It is NOT the user that is locked out, it is the Terminal Server.
Look at the locked out username: TELNET_AC19A31B
Convert AC.19.A3.1B, each 2 hex digets, to decimal, and you get 172.25.171.27.
And that would be your terminal server, I bet.

I do not know of a way to get around this, but I would LOVE to read how it can be done.

Proost.

Have one on me.

jpe

[Steven Schweda]

> [...] but I would LOVE to read how it can
> be done.

Use LAT? I know nothing, but I gather that:

LAT is tracked back to the originating
port based on the contents of the
TT_ACCPORNAM field.

http://h71000.www7.hp.com/doc/732final/aa-q2hlg-te/00/00/69-con.html

If true, then this might be a little more
selective than using the IP address.


I can't help but wonder why legitimate users
are getting flagged as intruders so
frequently as to cause a problem. Bad
password policy?

[TMcB]

thanks - I'm going to look into the lgi_brk_term parameter.

Will test changing this to see if there is any difference.
We dont use LAT anymore - most users have access via PCs, but there are a few terminals knocking about, connected to the one Terminal Server, and as mentioned earlier, when one terminal has an intrusion record, all other terminals are locked out.

Will let you know if this works,

thanks

[Hoff]

The easiest way to resolve this is to shut off the DoS that is break-in evasion; it's a once-nice and sounds-nice solution that is increasingly ill-suited to distributed networks. Evasion (still) works fairly well in (some) isolated networks, but it's a real problem with larger networks and the open Internet.

There are approaches that are based on site-local heuristics that tend to do rather better in this area than brute-force mechanisms, but even these are far from a panacea. You'd have to port some of this stuff, but there's Python around if you wanted to have a look at something similar to DenyHosts.

http://labs.hoffmanlabs.com/node/1138
http://labs.hoffmanlabs.com/node/689

Best to punt on this and look at your authentication model; to not try digging a comparatively bad hole deeper.

[Volker Halle · Accepted solution]

TMcB,

if you are running a recent version of TCPIP, you may also want to look at the

TCPIP$TELNET_TRUST_LOCATION

logical.

Volker.

[TMcB]

Thanks Volker

that definately looks like something - will test this tomorrow.

[John Gillings]

The basic issue is that telnet only knows the address from which a login is attempted, not the source username.

So, all login attempts from the same terminal server appear to be the same source (same IP address). With many users logging in, it's easy to exceed the default intrusion limits and assume the system is under attack. Remember, these are DEFAULTS. There's nothing magic about them. They can, and should, be adjusted to suit local requirements. See MCR SYSGEN HELP/LGI to see all the parameters you can adjust to control how the system behaves.

As Hoff has suggested, changing LGI_BRK_TERM might help. It causes the terminal name to included in the source string. BUT the downside is it means a true breakin won't necessarily be detected, as each new connection from an IP address will generate a new terminal name, hence multiple attempts won't be associated and the attempts added together to detect an intrusion. A dictionary attacker can just keep feeding in attempts. They'll generate lots of suspects, but, if they know what they're doing, will never push the system into intrusion.

An alternative is to increase LGI_BRK_LIM from the default of 5. With the default setting, five failed login attempts in a 5 minute period will lock out the whole server. Depending on your pattern of logins, and the level of users, this could easily be exceeded at start of day, just from fumble fingered users.

Increasing the value to (say) 3x the number of users on the terminal server may raise the limit high enough that you don't ever lock out the server. For a 16 port terminal, that means LGI_BRK_LIM=48. So, we should reduce, or eliminate the instances of server lockout, but you still have protection against brute force dictionary attacks, which is what intrusion detection is really about. What are the chances of a dictionary attack succeeding in under 50 attempts against an OpenVMS account with even the most lax password rules?

Long term, keep an eye on the output of SHOW INTRUSION, especially at peak login times, to see the real "highwater" marks for suspects. You may be able to reduce LGI_BRK_LIM to find the best balance between keeping your system secure, and not blocking legitimate logins.

(and I concur with Hoff about SYSUAFs and other cluster environment files. Take the time to merge them together into a single set of files, physically shared across the cluster - this will avoid MANY problems down the track).