Rogue Sensor Behaviour Very Odd

[Former Member]

epo 4.02/agent 4.0/rsd 2.0

Folks,

I did call support on this one and they said the behaviour could not happen. But here is what I'm seeing relating to the installation of the rogue system sensor.

I rolled out the 2.0 Senor to approximately 20 computers through-out the network. A few day later my network group sent a message saying they are seeing a significant number of traps from network equipment that are detecting access attempts. They listed the primary IP addresses that were doing this. They had no knowledge of the rogue deployment.

I checked the IPs and they correlate to workstations running rogue sensors. I deleted the rogues and the traps stopped. It appears that 95% of the IPs identified also run the rogue agent.

I know that the rogue sensor is a simple wire sniffer but this coincidence is very odd. Plus, now I have to prove it is not the sensor. So I'm running the sensor on my workstation w/wireshark trying to capture this activity.

So while this is very wierd post in the sense of "this cannot be happening", it's odd the IP's match the rogue sensor during the time frame it was initially installed and stopped during the time frame the sensor was removed.

[Former Member]

...further...

currently sniffing my subnet. Seeing telnet activity from my computer and other computers on my segement. The computers telnetting are all running RSD 2.0.
Will delete rsd off one of computers and see if the activity stops.

This is so wierd --- there is no reason these computers should be telnetting but I can see it happening and they all are running rsd 2.0. I also realize this should not be an activity RSD 2.0 is capable of? So if I have some other infection taking machines over then why isn't McAfee alerting.

[tonyb99]

Are you sure its not this function of RSD 2.0 thats the issue:
(page 190 of the epo 4.02 manual)

The sensor also performs NetBIOS calls and OS fingerprinting on systems already detected to
obtain additional information. It does this by listening to the broadcast traffic of all devices in
its broadcast segment and by using NetBIOS calls to actively probe the network to gather
additional information about the devices connected to it, such as detected system operating

system.

I'm sure I saw a post on this being an issue when it was in Beta and they advised to create exceptions for all the network devices or switch off the detail function in policy, hmm but now the beta board is no more so I can't check this.

[Former Member]

I have a similar problem with it. The OS Fingerprinting performs all kinds of weird connection attempts.

In my case it's port 5800 and UltraVNC Client. The sensors try to connect on port 5800 which is the standard port for the UltraVNC java viewer, which generated requests for VNC sessions on our clients. I did post on the RSD Beta board and a McAfee technician told me that there's no possibility, yet, to configure what exactly the OS-Fingerprinting does and what not.

If you disable the OS fingerprinting in the RSD policy the telnet access attempts should stop. I hope that McAfee will allow us to edit the OS fingerprinting behaviour in the future, as I cannot use it the way it is now.

[tonyb99]

yes I think thats the post I was referring to 🙂

was that the same one where you asked where all the options were to manage RSD at a high level and they went... um you dont need any of that in RSD 2.0 as we have OS fingerprinting now (which PS seems to work like **** in my environment)

[Former Member]

No that wasn't the post. To me the tech hinted at the possibility, that it may (someday) be possible to change the fingerprinting settings. I hope rather sooner than later.

[Former Member]

Last night I deleted a sensor and the telnetting stopped. I also added a new sensor to another computer and that computer started telnetting.

SO... on the RSD Policy, Device details detection I am unchecking "enabled".

Will monitor to see if that fixes thing.

Thanks for your replies. As McAfee support informed me this behaviour could not happen I was at a loss at what was causing it

[Former Member]

Yeah, so far we've had a sensor trigger an unauthorized login attempt on our main data center UPS. That caused a stir... :eek:

[Former Member]

yup that fixed things. More fodder for those who want to trash McAfee and blame it for all their workstaton and server woes