All telnet sessions tagged as intruder

[Sloan Essman]

I'm looking at in issue on my new BL860c running 8.3-1H1 and Multinet 5.2. OS and Multinet are at current patch levels. As shown below on a SHOW INTRUSION, the SOURCE is showing that records are from a telnet source, but the HEX IP address/port into is missing. Therefore EVERY failed telnet session appears to be from the same source and when classified as in Intruder, nobody can start in inbound telnet session from ANY terminal.


CYRUS> sho intru
Intrusion Type Count Expiration Source
--------- ---- ----- ---------- ------
NETWORK SUSPECT 32 29-MAY-2009 12:31:05.20 TELNET::

I'm expecting something more like this:
Intrusion Type Count Expiration Source
--------- ---- ----- ---------- ------
NETWORK SUSPECT 5 29-MAY-2009 12:36:44.78 TELNET::7F000001

I'm just looking to see if anybody else has run across this particular behavior before opening support tickets. I'm reviewing all of my Multinet information to see if the problem is on that portion. Just to keep people working, I've reduced the LGI_HID_TIM parameter to zero so nobody gets locked out, but I of course don't want to leave that setting as-is for too long even on this non-internet facing system.

[Mike Smith_33]

You said this is your new BL860c, which makes me ask:
1: Has this ever worked?
2: If the first answer is yes, what have you changed lately?

[Sloan Essman]

Has never worked properly on this system (nor my other 3 bl860c's) All have the same OS and Multinet. It's worked on every other system I've had, including my main production system, an ES40 with 7.3-2 and Multinet 4.4.

[Hoff · Accepted solution]

Check for the available MultiNet ECO and apply; most any support call is going to ask you to get current, regardless. Here, the MASTER_SERVER-053_A052 kit:

http://www.multinet.process.com/scripts/eco/eco_tlb.com?MASTER_SERVER-053_A052

Has a fix for something that looks very similar to this reported case.

"- Handle mapped IPv4 addresses correctly when doing accounting so that VMS intrusion handling continues to work as it did in prior versions of MultiNet. Note that this does not address the issue for IPv6 addresses that are not IPv4 mapped addresses; support for that will require a MultiNet Kernel patch. (DE 10517 ECO MASTER_SERVER-020_A052 ECO Rank 3."

[Richard Whalen]

Hoff's answer should be the fix. TELNET was moved to IPv6 with MultiNet 5.2 and there were some errors in processing how addresses are handled in a few places.

If you are up to date on the patches, then try changing the socket-family for telnet to AF_INET:

$ multinet configure/server
SERVER-CONFIG>select telnet
SERVER-CONFIG>set socket-family AF_INET
SERVER-CONFIG>write
SERVER-CONFIG>exit
$ @multinet:start_Server restart

[Sloan Essman]

I think that patch will be it too. I'm downloading it now. When I patched Multinet, I just grabbed everything off their "recommended" list. I didn't think to go read through the rest.

I have a system that's still in staging so I can tweak it at will. I'll post an update after applying the patch to that system and testing (along with the other 15 things going on today)!

[Sloan Essman]

That was it Hoff. Intrusion records are displaying properly now on the system that I updated. I'll update my other systems and get intrusion protection working properly.

Thanks for the 2nd set of eyes. I REALLY suspected it was a behavior change in Multinet but just hadn't tracked it down yet. You saved me some time.

Thanks to everybody for the input!