HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Hours:
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

tcpip$telnet_trust_location

 
Robert Youngquist
Occasional Visitor

tcpip$telnet_trust_location

I am experiencing the problem described in the release notes related to TELNET and references a fix using tcpip$telnet_trust_location but doesn't specify how to define it. Any help would be appreciated.
4 REPLIES
John Gillings
Honored Contributor

Re: tcpip$telnet_trust_location

Robert,

TCPIP$TELNET_TRUST_LOCATION is an existence logical name. The value doesn't matter, just if it's defined or not. By convention you would define it to "TRUE":

$ DEFINE/SYSTEM/EXEC TCPIP$TELNET_TRUST_LOCATION TRUE

This tells TELNET to "trust" the location information sent from the remote host in identifying the source of the incoming connection. This means password failures from incoming telnet sessions can be more accurately logged for audit & intrusion detection.

The intention is to get around the issue of an intrusion detection on a single port on a terminal server blocking accesses from other ports. Instead of the intrusion source being based solely on the IP address of the server, it will be qualified by the port name.

Of course, it requires the remote host to actually SEND location information. I think it's only DECservers and other OpenVMS hosts that do so. It also means that a hacker could potentially defeat intrusion detection by sending bogus location information when attempting a dictionary attack against your node.
A crucible of informative mistakes
John Gillings
Honored Contributor

Re: tcpip$telnet_trust_location

Robert,

BTW, if you're having the problem of multiple users from a remote host being blocked by one user reaching intrusion threshold for failed login attempts, I believe a more secure solution is to raise the threshold.

The default LGI_BRK_LIM is 5, which, in my opinion is WAY too low. It means that most intrusion detections are false alarms. Just ordinary users persistently typing the (acidental) wrong password too many times.

Suppose you have a 16 port terminal server. Raising GLI_BRK_LIM to (say) 50 will allow each of your users 3 failed login attempts within the LGI_BRK_TMO window before the terminal server is blocked.

In terms of security, the difference between 5 and 50 attempts really doesn't matter in terms of detecting a true brute force or dictionary attack against your system. Even the most lax password policies should survive 50 random probes. On the other hand if you ever do see an intrusion detection, it's more than likely real (even the dumbest of dumb users isn't persistent enough to retry their incorrect password 50 times!). I would therefore argue that the higher value is MORE secure, because a real attack is less likely to get lost amongst the false alarms.

If you have especially paranoid auditors, you may be able to find a smaller number that is high enough that your users don't hit it (or at least very rarely) but low enough to keep the auditor happy.

Note that this solution eliminates the potential hole of crackers sending bogus location information to hide their attack, and it works for ALL host types, not just the ones that know about the OpenVMS extensions to telnet protocol.
A crucible of informative mistakes
Robert Youngquist
Occasional Visitor

Re: tcpip$telnet_trust_location

Thanks, I was missing the /exec. It works as advertised and what we want. Thanks for the quick and accurate response.

rob.
Robert Youngquist
Occasional Visitor

Re: tcpip$telnet_trust_location

define/sys/exec tcpip$telnet_trust_location true

worked, thanks.