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 184.108.40.206/24. IP address of server 220.127.116.11
I have added the subnets into the exclusion. Policy Catalog > Rogue System Sensor > Created a policy > inputted Subnets that i want to exclude.
18.104.22.168/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?
Just got off the phone with Mcafee Helpdesk after an hour of investigation and testing.
Basically, it can't be done.
Tomcat (ePO) scans the network for subnet ranges. By inserting the IP subnet ranges within the RSD policy does not help. This only stops an already installed sensor from scanning the rest of the subnet.
Therefore... you will always have uncovered subnets within RSD unless you install a sensor on a machine in that range.
If you delete the uncovered subnet it will reappear after a machine in that range performs a agent wakeup call
Now i fully understand why mcafee have left RSD out of version 4!
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.
Can i run this scenario past you as i'm about to throw myself out the window!
I have this scenario all round the estate but i'll use the below as an example
I have 6 servers all with 2 Nics using 2 subnet ranges.
Example: Server Name: ECCSCCDEV IP Add1: 10.167.174.54 IP Add2: 192.168. 138.59
ECCSCCDEV on both IP addresses are being reported as rogue with RSD.
When i look at the properties of the server within the directory its showing 10.167.174.54.
When i check RSD, subnet 10.167.174.0/24 is uncovered and reporting the server as rogue When i check RSD, subnet 192.168.138.0/24 is covered but reporting the server as rogue aswell. (Sensor has been installed on ECCSCC07)
As a test, I've have successfully installed the sensor on ECCSCCDEV, the sensor details appears in the properties but has not made any difference to the rogue status and still showing the subnet uncovered.
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.
Checked the RSD install status - you are right, the status is 'in progress' and does not give a end time. 'Not available'
Within directory, MAC address is there (and unique) 00:11:xx.... All servers have unique GUID No duplicates in directory
When i search for the mac address within RSD, no results are returned.
When i search for host name within RSD, the server is found. but on the 192.168.138 range (192.168.138.59). Detect date 09/01/08 17:33. When i check the properties, its a different MAC address than the one listed in the directory. 00:02:xx
I did have MAC address only within configuration, so i have changed that like to you said to MAC address followed by hostname.
I have tried pushing the sensor again followed by several wakeup calls but still being detected as rogue and the install has not completed.
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.
From the looks of it, it seems te sensor is doing its job but can not report back to the AV server as it can;t resolve the name. What do you think? or am i barking..... (up the wrong tree)!
The DNS is setup for a different domain therefore i will have to create an entry within DNS to resolve the AV server name. Due to the importance of the application running on the server i can't just make the change incase i screw the server. ITIL procedures, blah blah, I will have to raise a 'request for change' which will take 2 weeks to implement :(
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...