Rogue sensor confusion

[Sunwardsquash 1]

Hello,

Does anyone know specifically what the rogue detection sensor is using to trigger what's a rogue versus what isn't? Right now it shows half the devices in my network as rogue but when you drill into the lists it's mostly the same host names in the "rogue" section as the "non-rogue" section. I don't have agents deployed to lots of these, but everything in AD is showing up in both reports regardless. Any ideas?

Lots of the rogue devices have multiple duplicate hostnames with MAC addresses that aren't actually adapters on the machines in question. Maybe it picks up access points or something else? Everything listed is on a flat subnet.

 

 

[j-gray 37]

My basic understanding is that it reports anything that ARP's, and reports it as rogue if it is unknown/unmanaged. This would include printers, AP's, etc. that do not have the ESET agent installed.

Because the RD Sensor uses ARP traffic, detection is limited to the subnet where the RD Sensor is installed and running.

HTH.

[MartinK 383]

As already noted, detection of rogue/managed computers is based on MAC addresses. They are collected by RogueDetectionSensor and compared with list of MAC addresses reported by managed clients.There are unfortunately few drawbacks (and bugs) that may have triggered your issue, for example:

• when comparing list of "managed" MAC addresses, only active interfaces are used. This may be problem in case devices are changing MAC address in your network. For example RogueDetectionSensor might have detected your device when connected using standard network card, but in case device is connected using WiFi, it will have different MAC address -> MAC address of Ethernet card will be considered as rogue.
• devices might generate virtual connections with different MAC addresses, which are detected by RogueDetectionSensor but never actually reported to ERA, which results of reporting such devices as rogue. There are multiple examples of how to do so. As an example, running virtual machine on client machine  with specific network configuration may be detected wrongly. The same applies for virtual interfaces spawned by docker ... they both generated traffic with different MAC address, but they are hidden behind host machine.

Is it possible your issue is triggered by one of mentioned scenarios?