topic Re: VMS intruder from telnet session in Operating System - OpenVMS

VMS intruder from telnet session

dvanwingen — Wed, 17 Nov 2004 11:46:50 GMT

VMS V7.3-x recognize a telnet session with remote TCP/IP adress, and the login is not allowed after LGI_BRK_LIM.

Sourcee > Node::TELNET_AC103B05
----------------------------------
VMS V7.1 the port number change after login failure, and the intrusion mechanism don't detect an intruder from an incoming telnet session.

Host: 172.16.10.10 Port: 1440:USER
-----------------------------------
We can't upgrade VMS......
Is a way to use the intrusion mechanism with VMS 7.1 ?

Thanks

Re: VMS intruder from telnet session

Bojan Nemec — Wed, 17 Nov 2004 12:52:19 GMT

Hi,

Welcome to the VMS forum.

This is an TCPIP issue. Can you tell us the version of TCPIP? Symply do:
$ UCX SHOW VERSION

Bojan

Re: VMS intruder from telnet session

Bojan Nemec — Wed, 17 Nov 2004 13:16:03 GMT

If you run TCP/IP Services for OpenVMS V5.0A, there is a patch for this. Please see the description in: http://ftp.support.compaq.com.au/pub/ecoinfo/ecoinfo/387.htm

Bojan

Re: VMS intruder from telnet session

Ian Miller. — Wed, 17 Nov 2004 13:17:48 GMT

You may wish to look at setting system parameter LGI_BRK_TERM to 0. From the HELP on VMS V7.1
Parameters

LGI_BRK_TERM

LGI_BRK_TERM causes the terminal name to be part of the
association string for the terminal mode of break-in detection.
When off (0), association is done on user name only. LGI_BRK_
TERM is set by default (1). It should be cleared if physical
terminal names are created dynamically (that is, if LAT is
installed) and effective break-in detection is desired.

LGI_BRK_TERM is a DYNAMIC parameter.

Re: VMS intruder from telnet session

John Gillings — Wed, 17 Nov 2004 15:50:10 GMT

You're correct, the changing port number means intrusions from the same real source aren't always recognised as such.

Although you can change the behaviour by clearing LGI_BRK_TERM, the source is then listed as you've shown "Node::TELNET_AC103B05". The hex string is an encoded IP address. Unfortunately TELNET protocol does not include the source username, so the intrusion looks the same for all attempts from the same NODE, regardless of the source user.

This means a single user can drive the node into INTRUDER status, and block connections from ALL users coming from that node. This might not be a problem, for example, if all your incoming telnet sessions are from PCs. But it WILL be a problem in some environments.

If you're going to clear LGI_BRK_TERM, it may be worth thinking about increasing LGI_BRK_LIM (ie: the threshold for a suspect becoming an intruder). Setting it up from the default of 5 to (say) 25, will reduce the chances of a single user with a bad memory blocking access from the whole node (5 retries is "reasonable", but I'd question the sanity of anyone who retries a password 25 times!). Sure this slightly reduces your protection against brute force attacks on your system, but then with half decent password policies, there's not much different between a dictionary attack of 5 and one with 25.

Re: VMS intruder from telnet session

Bojan Nemec — Thu, 18 Nov 2004 05:53:10 GMT

When the source is composed with the IP address and you use DHCP, there is also one more (small) reduction.
An intruder can reboot (or simply restart the TCPIP services). So his IP address changes. Doing so he obtain more retries and he can drive many IP addresses into intruder status.

Bojan

Re: VMS intruder from telnet session

dvanwingen — Mon, 22 Nov 2004 10:59:49 GMT

Thanks for help

With LGI_BRK_TERM to 0 we have a response to our need.

Re: VMS intruder from telnet session

dvanwingen — Mon, 22 Nov 2004 11:09:28 GMT

Thanks for help

With LGI_BRK_TERM to 0 we have a response to our need