Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
This discussion is archived
3121 Views 11 Replies Latest reply: Jan 10, 2008 10:40 AM by PBateman RSS 1 2 Previous Next
PBateman Newcomer 75 posts since
Jul 19, 2007
Currently Being Moderated

Jan 7, 2008 4:43 AM

Rogue System Detection - Excluding Subnets not working

Morning

For the last 4 days I have been setting up RSD and now find myself trying to exclude specific subnets. Subnets that are reserved for servers.

About 50 subnets keep popping up even though I have excluded them.

An example: subnet is popping up 151.176.48.0/24. IP address of server 151.176.48.10

I have added the subnets into the exclusion. Policy Catalog > Rogue System Sensor > Created a policy > inputted Subnets that i want to exclude.

151.176.48.0/24. Error: Network Mask Value dosn't match the network class B.

Add the Policy to the Server Group.

Delete the subnet from with RSD.

Perform agent Wakeup on Server, the subnet reappears in RSD.

This problem is happening on approx 50 subnets, am i doing something worng, has anyone else had this problem? Does the Error message 'Network Mask Value dosn't match the network class B' have something to do with it?

Any help would be great. Thanks in advance
  • boohbah Senior Member 111 posts since
    Feb 3, 2005
    sorry, i can provide a little supplimentary info on this,

    the list of subnets visible under the RSD gui is populated from 2 sources , one is a list of every distinct subnet, sourced from the properties of the ePO agents. ie if you have an agent in a subnet, you will have it listed here.

    the other way is if you have a sensor spanning 2 subnets ( ie 2 NICs ), the sensor will report on both subnets

    as McAfee have no doubt said, there is no way of stopping the first method from reporting on subnets.

    there is a way of preventing the second method - excluding the network from detection via the sensor policy

    the error you are seeing is because your subnetting is not adhering to the class boundaries, but im not sure if it is adding the policy anyway.

    the fact that the subnets you are concerned about keep coming back, suggests that the subnets are being reported back to ePO via the first method... or that the policy you are defining doesnt work because you are not adhering to the class boundaries perhaps..

    i can appreciate the rationale as to why RSD works in this way - it is giving you total visibility of your network, so that you can then make decisions on whether to cover it or not. if it didnt report it, you may never know that the subnet existed, and therefore couldnt protect it.
  • boohbah Senior Member 111 posts since
    Feb 3, 2005
    hmm,

    this is kind of hard to visualise, without seeing the network, but lets have a go,

    couple of things - the sensor install task ( within RSD GUI) does it report that it has successfully installed the sensor onto SCCDEV ? - ie, the task has a completion time ( this verifies that the sensor is working correctly, and that it has the correct certs needed to communicate over SSL)

    within the ePO directory, find the entry for ..SCCDEV - what is the MAC address ( listed in the properties as NETaddress) for the NIC with the IP 10.167.174.54 ?

    this will be the MAC address that is being queried first, to see if ePO knows about this computer.

    check for duplicates of this computer in the directory.

    check that these 6 "problem" machines do not share the same agent GUID - ie, they werent built from the same OS image

    within RSD, find the machine ...SCCDEV , and look at its properties - what MAC address is listed ? what about IP Address and hostname, DNS - these will be the values that will be being searched for in the ePO dir.

    also, what is the last detect time for ..SCCDEV is it recent ?

    what configuration do you have set under the RSD configuration tab for the search criteria - search by MAC only, or search for MAC first then hostname - if not, set it to the middle option- MAC first, then hostname.

    HTH,
  • boohbah Senior Member 111 posts since
    Feb 3, 2005
    ok, if it has been "in progress" for more than a couple of hrs, somethings gone wrong. i suspect if you look in the rogue sensor install dir on that server it will be missing 3 files with the extension .PEM - these are required for comms.

    we will come back to that later,

    let me ask - since you changed the search mode, from MAC address to MAC Address then Hostname, has the last detected time of ECCSCCDEV been incremented - ie, do you have a detection after you made the change ?

    this is whats going to happen,

    the RSD servlet will take the data supplied by the sensor :

    MAC = 00:02:........
    IP = 192.168.138.59
    Hostname = ECCSCCDEV
    etc etc

    first, it will search for the MAC address - does MAC address 00:02:.... exist in the epo directory ? - answer is no ePO has this server listed as MAC address 00:11:.....

    so the first check will fail.

    check number 2 ( search for hostname if MAC address check fails)

    does the netbios name reported by the sensor match the computername of any of the computers in the directory? - if not, then this check will fail, and the computer will be declared ROGUE

    so it is worth asking at this stage, is the netbios name reported in the RSD rogue computer properties *Exactly* the same as the netbios name of the computer as listed in its computer properties - NOT the directory name of the computer, since this can be different to the actual netbios name of the computer.

    its worth reiterating here that the quality of the RSD performance is only as good as the quality of the data that RSD collects.

    the sensor tries to gather information about the detected machine remotely using windows mgmt APIs , but if the computer is firewalled, etc this will fail.

    it will try and use the collected IP address to resolve to a hostname and FQDN for the detected machine, but this will only be as succesful as the quality of the DNS server - if the computer doesnt have a DNS record, or its wrong/stale it will report rubbish back to ePO/RSD and RSD will make bum decisions based on bad data


    its also worth saying that all of this Rogue/Not Rogue calculation is only done when the RSD sensor re-reports the computer back to the server. by default, computers are only re-reported back to ePO once every 60 mins, therefore they will only change "state" every 60 mins. hence my question, was the last detect time for computer ECCSCCDEV after the change you made to the search radio button.

    phew ! i'd better get some work done..
  • boohbah Senior Member 111 posts since
    Feb 3, 2005
    no worries - you can turn around a Change Request in 2 weeks ???? - im impressed !

    DNS is certainly hindering you here, in the short term, you can solve it by changing the hostname for the ePO Server that is listed in the rogue sensor policy from a hostname to an IP address for the ePO Server.

    apply changes, wake up the agent and bingo.

    this will allow the sensor to work, and the sensor installation will then be listed as complete.

    in the long term, itll be a good idea to have DNS for this subnet ( and perhaps others in a similar situation) fixed, so they can reliably resolve hosts,

    you should find that changing the search method fixes the scenario that is affecting this server tho...

    Hope this helps,
1 2 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (0)