This content has been marked as final. Show 11 replies
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.
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.
Any ideas as i'm losing the plot.
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.
What do you reckon, (call to mcafee helpdesk)?
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
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..
Many thanks for your reply, i really appricate you taking the time out to help me.
Checked the server, the x3 .PEM are in the install directory.
Checked the last detect time, 10/01/08 10:19, therefore it is being detected every hour
I think your on the right line regarding the DNS. I logged onto ECCSCCDEV and tried pinging the AV server - unknown host.
When i checked the RSSensor_out.log the following is being reported:
01-10-08 11:14:10,  INFO RSSensor <> - Found IP address: 10.167.174.54 on interface HP NC7781 Gigabit Server Adapter with MAC address 00:11:85:b8:42:99.
01-10-08 11:14:10,  INFO RSSensor <> - Found IP address: 192.168.138.59 on interface HP NC7170 Dual Gigabit Server Adapter with MAC address 00:02:a5:4f:7e:4a.
01-10-08 11:14:10,  INFO RSSensor <> - The network 10.167.174.0 already has a virtual sensor running on this machine.
As a result, no new virtual sensor will be created.
01-10-08 11:14:10,  INFO RSSensor <> - The network 192.168.138.0 already has a virtual sensor running on this machine.
As a result, no new virtual sensor will be created.
01-10-08 11:14:10,  INFO RSSensor <> - Adjusting server URL for virtual sensor 1044
01-10-08 11:14:10,  INFO RSSensor <> - Adjusting server URL for virtual sensor 4384
01-10-08 11:20:59,  WARN RSSensor.NetListener <> - The Network Listener has gone for over 60 seconds without receiving any data from the network.
01-10-08 11:22:38,  WARN RSSensor.NetListener <> - The Network Listener has gone for over 60 seconds without receiving any data from the network.
01-10-08 11:25:03,  WARN RSSensor.ServerCom <> - SocketException: Failed to resolve remote hostname (*my AV Server name*)
11001: No such host is known.
HTTP POST failed, adding the request to the retry queue.
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 :(
Again many many thanks for helping me out.
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,
Just like you said, i changed the RSD policy ensuring the sensors communicate to the IP address rather than the server name.
Enforced the new policy, performed agent wakeup, RSD status changed from 'in progress' to 'Successfully Completed'
Subnet is now covered!
Bloody Happy Days, Boohbah you've made me a very happy man, I owe you a beer fella.
Thanks ever so much