Blocking Intrusion Detection against a Specific IP in VMS7.3

[Learn_1]

Hi All,
Its really a great helpful forum for me to resolve the issues.one more question for you guys.
Question:"How can we block intrusion detection against a specific IP in OpenVMS 7.3"
Let me elaborate the problem
"we have alpha server GS80 in cluster environment running OpenVms7.3 at one site.on tne other site we have thinclients t5700 running windows XPe.These thinclient connect to a proliant server dl580g2 running windows 2003 enterprise edition by using XP remote desktop connection and from there these logged in client connect to AS GS80 by using terminal emulation software Smarterm and by utilizing dl580g2 server IP.As the only IP that connects to Alpaha server GS80 is of Dl580g2 server(say 10.140.0.2),if any thinclient user enter wrong password repeatedly,the Alpha GS80 detects an intrusion against the IP (i.e 10.140.0.2) and block further login connection to GS80."

Now i want to ignore/block Intrusion detection against this specific IP so that if clients even enter repeated wrong password the IP is not blocked so that other user may not suffer.
Your suggestion in this regard is much valuable.Please do let me know if further explaination is required.

[Scott Belviso]

The LGI_BRK_TERM sysgen paramater is the one to change. Set it to 0 (zero) and it should ignore the source of the intrusion and only focus on the username being used. It is a dynamic paramater so it can be tested without rebooting.

$ mc sysgen
sysgen> set lgi_brk_term 0
sysgen> exit


Scott

[Antoniov.]

...and you could write a little cake-pie firewall inserting in SYLOGIN.COM follows statements:
$ session_telnet = (f$locate("TNA",tt_devname) .ne. f$len(tt_devname))
...
$ If session_telnet
$ Then
$ CLIP = f$elem(1," ",f$getdvi -("TT","TT_ACCPORNAM"))
$ HOIP = f$trnlnm("UCX$INET_HOSTADDR")
$ session_inet = 0
$ If f$elem(0,".",CLIP).nes.f$elem -(0,".",HOIP) then session_inet = 1
$ If f$elem(1,".",CLIP).nes.f$elem -(1,".",HOIP) then session_inet = 1
$ If f$elem(2,".",CLIP).nes.f$elem -(2,".",HOIP) then session_inet = 1
$ If session_inet
$ Then
$ write sys$command "Bye!"
$ LOGOUT
$ Endif
$ EndIf

Bye
Antoniov

[Learn_1]

thanks Scott
please clarify me a bit more.
as suggested by ur procedure in the source menu of the sh intrusion instead of IP the user name is diaplayed and we can delete that specific user.but as the IP used by this user will be the same as of other users as there is only one server that is providing connectivity with the GS80.so if this ip is detected in the intrusion detection mechanism,other users may also be the affectees and login denial will also problem for other thinclient users.
So can we specify exactly the IP that is providing connectivity to all users to be excluded from Intrusion detection mechanism.

Correct me if i am wrong.
one more thing if we reduce the lgi_brk_tmo value to 0 then the intrusion expiration will be reduced to nearly 0 although this is not advisable.

Please suggest the changes.

Thanks once again.

[Scott Belviso]

Hi,
I have a couple questions:
!
Can you post the actual intrusion display here so I can see what the source looks like?
!
Do all of the people connect to dl580g2 as the same user?
!
Would it be possible to have each user connect directly from their thinclient?
!
!
You are correct about lgi_brk_tmo.
!
Scott

[John Gillings]

?? I replied to this message yesterday - lost in the web?

First of all Scott is correct about changing the system parameter, but it needs a WRITE command. I also advise always using an explicit USE command before changing anything, just to make sure you know what you're changing:

$ MCR SYSGEN
SYSGEN> USE ACTIVE
SYSGEN> SET LGI_BRK_TERM 0
SYSGEN> WRITE ACTIVE
SYSGEN> EXIT

An alternative is to define the system logical name:

$ DEFINE/SYSTEM/EXEC TCPIP$TELNET_NO_REM_ID TRUE

Note that this will effectively disable intrusion detection for ALL telnet connections. Please make sure you understand the full security implications.

Another possibility is to raise the intrusion threshold high enough so users aren't affected. Increase LGI_BRK_LIM to set the number of attempts before a suspect becomes an intruder. The default of 5 is probably a bit low for the real world anyway. How many people's passwords are so obvious that someone could guess it in less than 5 attempts?

For a small number of nodes, or a "trusted" subnet, you can have a periodic job to clear intrusion records. Remember that DELETE/INTRUSION works with wildcards. So:

GOODGUYS.COM
$ SET NOON
$ Loop: DELETE/INTRUSION "10.140.0.*"
$ WAIT 00:02:00.00 ! 2 minutes
$ GOTO Loop

Run this in batch from the SYSTEM during startup.

This will regularly clear your intrusion data base of any records from your immediate subnet, but leave anything else. I'd recommend reviewing your audit journal on a regular basis, to make sure this doesn't mask any real intrusion attempts.

Adjust the source string and delay time to suit your requirements. Consider that you need several attempts before becoming an intruder. By adjusting the time delay and LGI_BRK_LIM you should be able to strike a good balance between security and preventing the unintended denial of service.

Again, before doing any of these things, make sure you understand your realistic security risks and how any changes will affect them.

[Learn_1]

Thanks Scott and sorry John forgot to mention your name.
Scott in reply to your questions
1.Attached is the output from sh intrusion command both before and after applying set lgi_brk_term 0 command.
2.No.users connect with the DL580 server with their specific usernames.
3.No.as the applications that needs to be run can not be installed on the thinclients.so the applications are installed on the dl580 server and users connect to this server and from this server all users are connected to the GS80.

I have reduced the lgi_brk_tmo to 0 as a temporary solution to this problem.

[Scott Belviso]

Sorry for the delay...It looks like VMS considers the source user ANWAR in all cases - regardless of the actual user. Is that true? If so, then something has to be done from dl580g2 to have the telnet session run in the context of each user instead of ANWAR. I'm not sure how you can do that.
!
From the VMS perspective you would have to loosen the lgi paramaters as you have if you can't change dl580g2.

Scott

[Willem Grooters]

I learned (from this forum) this is "by design" is certain cases - a customer had the same problem.
If, in your case, the DL580G2 server is a Citrix server (or likewise...) from where TELNET is used, VMS has no means telling which user causes the failure on login, and therefore the only way intrusions can be prevented is by IP address. Result: if several users miss their password (or username) within a given period, ANY access from that IP address is marked "INTRUSION" so ANY login from that IP-address will fail.
Swithing off intrusion detection is IMHO a bad idea if this GS80 is accesable from 'untrusted' networks. My guess is that you will need to regularly remove the intrusions from that specific machine, like John suggested, although you _may_ loose monitoring genuine breakin-attempts from that machine as well.
(Off the record but it _might_ be a solution: Use DECNEt...)

[Jan van den Ende]

Well, WE were having similar problems, but at a somewhat bigger scale: we have got over 50 Citrix servers, so we DO have the problem regularly.
What I DIDDN'T was the wildcard in DELETE/INTRUSION, but it sounds really promising.
Our site is more complex in other respects too: only about 90% of our sessions is Citrix.telnet; each of them preceeded be a (very small) FTP-copy. AND we have rather strict security wishes, especially for the non-Citrix connections. By the way: OUR connections are NOT reported by IP address, but by name. (needs reverse name resolution by local HOST table or by available DNS lookups, and on TCP/IP V5.1 at least ECO-2)

Since all our terminal servers have a rather specific part of the name in common, we ARE able to clear intrusion records from just only those servers in two wildcard commands (1 for TELNET & 1 for FTP).
Ou self-repeating batchjob will be in operation before the day is over!

So, Anwar, since this is your stream, and I cannot award points, could you award 10 point to John on me behalf?


Jan van den Ende

[Richard W Hunt]

I am at a U.S. Dept. of Navy site. We have a similar problem. Details are different, but it depends on the fact that the common connection source is doing network address translation so ALL USERS come from the same address. The problem with turning off the address sensitivity is that you cannot trust the LOGIN NAME if the user has flubbed it. Also, in my case I cannot turn off the breakin detection. (Regulations involved)

So I had to build a monitoring program to go look for the intrusions from the specific sources and drop those records from the intrusion list.