Operating System - OpenVMS
1748245 Members
3531 Online
108760 Solutions
New Discussion

Re: Intrusions after Upgrade

 
Bushytea
Occasional Advisor

Intrusions after Upgrade

We are currently using OpenVMS V8.3.

 

Recently, we upgraded our openvms from 7.3 to 8.3 and before the VMS upgrade we would never have any issues with the intrusions. Now, every failed login attempt by any user on our system gets logged and after so many it locks the entire system so that no user is able to login. It does not matter which user is failing to login as it logs all failed attempts into one count. We do know these attempts are not due to a hacker but just due to users who are attempting to login.

 

I have gone to:

 

MC SYSGEN

SHO /LGI

 

and I see nothing different from how we had this setup before. We also have a second system that still runs OpenVMS 7.3 and the settings are the same there as well. However, our second system never locks up completely due to a certain number of failed login attempts like our upgraded system does.

 

 

 

 

 

4 REPLIES 4
Steven Schweda
Honored Contributor

Re: Intrusions after Upgrade

 
John Gillings
Honored Contributor

Re: Intrusions after Upgrade

What you're describing sounds like all your users are perceived as coming from the same source, so login failures are accumulated across all users, rather than from a single physical source.

 

There have been changes in the default way the source string is derived and used for intrusion detection between versions of OpenVMS from time to time, I can only assume you've moved across such a change.

 

Look at (or post) one of the intrusion records to determine the source field. Test it to confirm that it doesn't change for different users.

 

What you do about it depends on your circumstances.

 

One option is to increase LGI_BRK_LIM high enough to deal with your "natural" level of login failures. The default of 5 across a reasonable population of users is way too low. Given that it's really protecting you against brute force dictionary attacks, 5 is probably a bit too aggressive anyway. 20 or even 50 should be more than sufficient to protect against a real dictionary attack, while reducing the chances of false alarms significantly.

 

The parameter which may have changed is LGI_BRK_TERM (dynamic), which I suspect is set to 0 on your system. Change it to 1 and each login will be its own source. This should eliminate your current problem, BUT it will mean that a real brute force attack may not trigger an intrusion.

 

To test:

 

SYSGEN> USE ACTIVE

SYSGEN> SET LGI_BRK_TERM 1

SYSGEN> WRITE ACTIVE

 

Make sure you simulate a real attack to see if you're happy with the way it's detected and the system reaction.

 

Once you're happy with the LGI settings, add them to MODPARAMS.DAT and run AUTOGEN to make them permanent.

A crucible of informative mistakes
Bushytea
Occasional Advisor

Re: Intrusions after Upgrade

Thanks for the replies.

 

I guess I shouldn't say we never had any issues with intrusions before. We just never had the system lock all of the users out. So honestly I could not say if the count is lower or higher now than it was before.

 

Our users are loggin in using a telnet connection.

 

Below are the results from the tcpip show version:

 
  HP TCP/IP Services for OpenVMS Alpha Version V5.6
  on an hp AlphaServer ES80 7/1150 running OpenVMS V8.3

 

 

John, I do agree that it does seem all of the users failed attempts are being logged into one lump count. So something must have changed between versions. The second box we have running v7.3 has 51300+ intrusions and never locks all users out. Yet, the setting are the same as the ones below. Also there is a screen shot of what we see when we get the intrusions.

 

SHO INTRUSIONS

Intrusion       Type       Count        Expiration         Source
---------       ----       -----        ----------         ------
   NETWORK      INTRUDER     24   27-JUN-2012 09:23:55.14  TELNET::::32.57.251.122:

 

 

The LGI_BRK_TERM is set to 1 already. Below is a screen shot of our settings.

 

Parameters in use: Active
Parameter Name            Current    Default     Min.       Max.   Unit  Dynamic
--------------            -------    -------   -------    -------  ----  -------
LGI_CALLOUTS                    0          0         0        255 Count      D
LGI_BRK_TERM                    1          1         0          1 Boolean    D
LGI_BRK_DISUSER                 0          0         0          1 Boolean    D
LGI_PWD_TMO                    30         30         0        255 Seconds    D
LGI_RETRY_LIM                   3          3         0        255 Tries      D
LGI_RETRY_TMO                  20         20         2        255 Seconds    D
LGI_BRK_LIM                     5          5         1        255 Failures   D
LGI_BRK_TMO                   300        300         0    5184000 Seconds    D
LGI_HID_TIM                   300        300         0 1261440000 Seconds    D
SYSGEN>

 

 

Thank You

John Gillings
Honored Contributor

Re: Intrusions after Upgrade

That source field looks very odd! Four colons in a row? I'm running similar versions

 

HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 5
  on an AlphaServer DS25 running OpenVMS V8.3

 

We have LGI_BRK_TERM set to 0

 

Intrusions look like this:

 

Intrusion       Type       Count        Expiration         Source
---------       ----       -----        ----------         ------
   NETWORK      SUSPECT       1   29-JUN-2012 07:26:40.56  NODENAME::TELNET_C0A8C0FE
   NETWORK      SUSPECT       1   29-JUN-2012 07:25:34.62  LOCALHOST::TELNET_7F000001

 

Now, with this setup, we'd get the same issues as you if all users were connecting from the same node, but we're not seeing the odd source you have.

 

I'd suggest you install the latest TCPIP ECO (please check what's available, ECO 5 may not be the latest). Also make sure all the source nodes are defined somewhere, and maybe boost LGI_BRK_LIM. I've always thought that the default of 5 is way too low. If someone is guessing, and they don't get it in 5 tries, they're not going to get it in 20 either. Boosting it to (say) 40 may get around the problem you're having, if only in the short term while you work out an alternative resolution.

A crucible of informative mistakes