Here's a poser:
We have a tunnel set up where one of our system's external support team accesses a number of different machines on several different internal subnets. We recently expanded and added some machines to a brand new subnet (192.168.39.x). Now, when support accesses these new machines, they get their connection severed whenever they attempt to escalate priveleges to root/super user. They do not experience this problem on any other subnet (including a 192.168.93.x subnet). I shut down the I-2700 sensor and had them attempt it and it worked just fine, so it appears that Intrushield is definitely the culprit. The strange thing is that we have absolutely no ACLs or anything else set up that would be causing this particular subnet to be treated any differently than the rest of our network.
Are there any alarms in your threat analyzer that correspond to these events? Create a display filter for attack names that start with telnet and see what shows up.
Yes, there certainly are. The attack is a Medium severity attack titled "Telnet: User Privilege Upgrade Attempt". It confirms the IPs of the systems that are having the issue and states the Result was "Blocked".
While it is great to find what is doing it, I still can't explain why it is blocking this attack only on machines on this subnet.
I've resolved the problem, but still don't know what was really causing the issue.
The resolution was to delete the current Policy and replace it with the Default IDS policy. I felt comfortable doing this since I could never find any differences between this "custom" policy and the "default ids" policy. (My predecessor created this custom policy, so I'm not quite sure what changes he made to it.) However, after reverting to the default ids policy, support was able to proceed normally. So, something in that custom policy was stopping it. It is still a mystery though since this problem only affected the one subnet and the custom policy was created several years before the subnet that was having issues was even created.
maybe in "custom" policy all the subnets were excluded in a particular signature/s . try to check some settings and add your new subnet to
that exclusion/s . also try to log all the traffic passing to that subnet and check what is blocking/denying them. keep us posted
It sounds as if the policy that was installed on the sensors had certain signatures configured to block traffic.
Changing the policy to a mere sensing policy has remedied the issue