I hope this post finds you all in good health and better spirits.
I'm currently managing a worldwide company with approximately 8,000 end nodes all under a single ePO 4.0 environment. Our environment is very dynamic and it's very difficult to continuously manage rogue sensors.
My question is what would be the impact of adding the rogue system sensor to every workstation (no laptops; approximately 4,500 workstations) within our network subnet? From speaking with McAfee, I get a response to the tune of "Don't cross the streams, it would be bad." with no documentation to give details on why this is bad.
To my understanding, there is only one sensor per subnet that is active within it's time window. The sensors basically work it out on who is the primary sensor for that period of time. So applying the sensor to the most static end nodes in the environment with the most coverage (workstations) would get me the biggest bang for my buck. Attempting to do one or two workstations in each subnet is time consuming and a management nightmare. I've applied up to 10 sensors in a subnet with no apparent ill effects.
I'm just looking for any other expertise out there that may have experienced something similar.
Thanks for taking the time to read this.
I would suggest using the DHCP monitoring feature with RSD, this will most likely solve your issue. You can just install the sensors on your DHCP servers, enable DHCP monitoring in the RS Sensor policy, and be done with it.
The sensor has 2 methods for finding "rogue" machines, via sensing layer 2 traffic or DHCP. Even though you can make the setting to have one or two active sensors per subnet, all of the sensors have to check into ePO so the ePO server know's they exist, this can put a lot of work on ePO and would be bad.
Hope this makes sense.
Thanks for the reply. Your ideas were perfectly explained.
However, I wasn't more explanitory with my issue, and for that I apologize. Our infrastructure/network team does not use Windows DHCP and to my knowledge I can't load a sensor on the DHCP appliances that they use (Cisco I believe although I don't have much visibility into their hardware).
I can see your point regarding sensor communication back to the server. Do you or anyone else in the community have any documentation at the bandwidth/resource/database load that each sensor takes up? I've been through all the standard documentation and courseware I've taken and I'm not able to locate the specifications. I'll check with my McAfee rep as well to see if this documentation is available. If I can crunch the math around it I'll be able to tell if this is plausible within my environment. My main ePO server and database is sized for about 20,000 nodes so the server isn't really taxed at this time. In the next few months, we're going to ePO 4.5 and employing agent handlers to offload even more agent traffic off of the main server which may allow for more resources to be allocated to this endeavour.
I appreciate any additional information that the community can give.
Unfortunately, we don't have any documentation that goes into those specific detail for the sensor, That's data that would have to be determined via testing.
You don't have to have the sensor *ON* the DHCP server, the sensor can be installed on anther machine that is, perhaps, on the same hub as the DHCP server so it can read all the tracffic going back and forth.
Thanks for the great information!! I had no idea that putting the sensor on a device in the same hub was a plausible solution. I'll be working with our infrastructure and server teams to see if I can wiggle a device into the same hub as the DHCP applicances and get an RSD sensor on it.
If this works, I'll be building a small statue out of legos and tofu on my desk in honor of you for being the hero of RSD.
BTW, Martin Tripp says, "Hi".
Thanks a billion,