Table Of Contents. Detecting Rogue Systems. Rogue Sensor Blacklist. The Rogue Sensor Blacklist is the list of managed systems where you do not want sensors. These can include systems that would be adversely affected if a sensor were installed. For example,. Also, systems that might spend significant. Rogue System Detection policy settings allow you to configure and manage the instances of.
Settings can be applied to individual. A system whose interface has not been detected for a very long time might have been disconnected from the network. Click the system row to display the Detected Systems Details page and see all the interfaces associated with this system. Select a system and click Actions to add the system interface to exceptions, to system tree, deploy agents, and more. Subnet status Subnet status displays how many detected subnets on your network are covered, or have a Rogue System Sensor monitoring the subnet.
Coverage is determined by the ratio of covered subnets to uncovered subnets on your network. Subnet states are categorized into these groups: Contains Rogues Covered Uncovered To fall into one of these categories, subnets must be known by the McAfee epo server or be seen by a sensor. Once a subnet has been detected, you can mark it Ignore to prevent receiving further reporting about its status.
Contains Rogues Subnets that contain rogue systems are listed in the Contains Rogues category to make it easier to take action on them.
Covered Covered subnets have installed sensors that actively report information about detected systems to the McAfee epo server. This category also includes the systems listed in the Contains Rogues category. For example, the Covered subnets category contains subnets A, B, and C.
Subnet B contains rogues, while A and C don't. All three are listed in the Covered category; only subnet B is listed in the Contains Rogues category. Uncovered Uncovered subnets don t have any active sensors on them. Subnets that are uncovered do not report information about detected systems to the McAfee epo server. However, there might be managed systems on this subnet that are being reported on through other means, such as agent server communication.
Systems' states are separated into these categories: Exceptions Inactive Managed Rogue The percentage of compliant systems is the ratio of systems in the Managed and Exceptions categories to those in the Rogue and Inactive categories. Exceptions Exceptions are systems that don t need a McAfee Agent, such as routers, printers, or systems from which you no longer want to receive detection information. Identify these systems and mark them as exceptions to prevent them from being categorized as rogue systems.
Mark a system as an exception only when it doesn't represent a vulnerability in your environment. Inactive Inactive systems are listed in the McAfee epo database, but have not been detected by a detection source in a specified time, which exceeds the period specified in the Rogue category. Most likely these are systems that are shut down or disconnected from the network, for example, a laptop or retired system. The default time period for marking systems as inactive is 45 days.
Managed Managed systems have an active McAfee Agent that has communicated with the McAfee epo server in a specified time. To ensure security, the majority of detected systems on your network should be managed. Systems on your network with an installed active agent are displayed in this list, even before you deploy sensors to the subnets that contain these systems.
When the agent reports to the McAfee epo database, the system is automatically listed in the Managed category. Rogue Rogue systems are systems that are not managed by your McAfee epo server. There are three rogue states: Alien agent These systems have a McAfee Agent that is not in the local McAfee epo database, or any database associated with additional McAfee epo servers you have registered with the local server.
Inactive agent These systems have a McAfee Agent in the McAfee epo database that has not communicated in a specified time. Rogue These systems don t have a McAfee Agent. Systems in any of these three rogue states are categorized as Rogue systems. See Rogue System Sensor status for monitor details. Top 25 Subnets The Top 25 Subnets list provides the subnet list, by name or IP address, for the 25 subnets that contain the most rogue system interfaces on your network.
When a top 25 subnet is selected, the 4. How rogue systems are detected To configure and manage Rogue System Detection, it is important to understand which components are used and how the rogue systems are detected. Using the McAfee Agent, those systems actively communicate their status back to the McAfee epo server on a regular basis.
By deploying to specific systems By using a System Tree action or a client task to deploy the sensor to selected systems Using all systems in a subnet and configuring the Rogue System Sensor election feature to determine which sensors are active and which are passive Rogue System Detection active sensors are configured on subnets depending on, for example: 5.
If the DHCP server can't support the sensor, you can install sensors on all the systems and configure the systems to elect which system or systems are active during a specific time, or install the sensors on specific systems and let the McAfee epo server determine which are active. The size of the managed network If the managed network is small, you can configure the McAfee epo server to determine which sensors are active.
The type of systems on the subnet If the subnet is a server farm with mission critical systems, you can install the sensor on a system with the least traffic and the least down time. Mission critical systems can also be blacklisted to ensure they are not used as active sensors. Types of Rogue System Detections It is important to understand that Rogue System Detection server and sensor configuration varies depending on the type of systems and subnets being listened to and how they appear in the Detected Systems page.
Here is a look at the four most common types of rogue systems that appear on the Detected Systems page. Figure 2 Rogue System Detection examples The four most common rogue system detections are: 6. These are the most common rogue systems. B Rogue systems whose operating systems don't support McAfee Agent installation For example, printers and mainframe computers.
C Static IP address rogue systems' detections These are mission critical servers connected to a subnet with a static IP address. You can install the McAfee Agent automatically on the rogue system or install the agent manually as a System Tree action. This process will probably account for the majority of the rogue systems detected on your epolicy Orchestrator managed subnets. Here is a look at a simple broadcast network subnet and the steps that occur when a rogue system connects to the subnet.
If the DHCP server can't support the sensor, you can install sensors on all the systems and configure them to elect which sensors are active during a specific time, or install the sensors on specific systems and let the McAfee epo server determine which are active. The administrator can move the system to its correct System Tree folder later.
If the McAfee Agent installation fails, the system is left as a rogue system. An automatic response can be configured to send a notification to the administrator to manually disconnect the system from the network, or add it as an exception and allow it to remain connected to the network. See Rogue System Detection configuration initial tasks for the detailed steps needed to configure broadcast network rogue system detection.
Detecting systems that can't host the agent Some rogue systems on your managed network are systems whose operating systems don't support installation of the McAfee Agent. These systems can be added to the network as exceptions because their operating systems aren't likely to pose a security threat to the managed network.
Examples of unmanageable systems are printers and mainframe computers. In this example a printer, connects to the managed subnet. Figure 4 Rogue System Detection exception example When the rogue system that can't support McAfee Agent installation connects to a managed broadcast network: 1 The printer with a static IP address connects to the network and sends a broadcast to all systems on the local subnet. If the DHCP server can't support the sensor you can install sensors on all the systems and configure the systems to elect which system or systems are active during a specific time, or install the sensors on specific systems and let the McAfee epo server determine which are active.
See Add systems to the Exceptions list for the detailed steps needed to configure system detections that can't host the agent. To find these rogue systems you must install a Rogue System Sensor on one or more systems on the subnet.
Here's what happens when a rogue system with a static IP address connects to the subnet. If the McAfee Agent is installed successfully on the rogue system, it is listed as a managed system and left in the Rogue systems folder of the System Tree.
This allows the administrator to move the system into its correct System Tree folder later. If the McAfee Agent installation fails, the system is left as a rogue system and if, configured to do so, an automatic response is sent to the administrator to manually disconnect the system from the network, or add it as an exception and allow it to remain connected to the network.
Detecting a subnet of systems that can t host agents Some subnets and individual systems on your managed network don't allow you to install the McAfee Agent. The individual systems could have proprietary operating systems, such as printers, mainframe computers, or VoIP telephones.
Also the subnets these individual systems connect to will appear as uncovered subnets with multiple rogue systems in the Subnet Status monitor in the Detected Systems page of the McAfee epo server. Figure 6 Subnet with special VoIP phone systems When a subnet of VoIP phones connects to the epolicy Orchestrator managed network: 1 The uncovered subnet with rogue systems connects to the epolicy Orchestrator managed network and many broadcasts are sent to the Rogue System Sensor and forwarded to the McAfee epo server.
The administrator can configure either: The sensor to not scan a specific list of system MAC addresses or the Organizationally Unique Identifiers OUIs of the VoIP phones, in this example A policy to not listen on interfaces whose IP addresses are included in a specific range See Manage subnets for the detailed steps needed to configure rogue system subnet detection.
A sensor reports on systems in the broadcast segment where it is installed. To maintain coverage in networks or broadcast segments that don t use DHCP servers, you must install at least one sensor on each broadcast segment using static IP addresses. DHCP deployment can be used with segment specific deployment of the Rogue System Sensor for the most comprehensive coverage. The epolicy Orchestrator 4. To protect the system from failing due to a lack of memory, the Rogue System Sensor 4.
If it drops below five percent, the sensor shuts down. Once the available memory increases, the sensor restarts. Passive listening to layer-2 traffic To detect systems on the network, the sensor uses WinPCap, a packet capture library. It captures layer 2 broadcast packets sent by systems that are connected to the same network broadcast segment.
It does this by listening to the broadcast traffic of all devices in its broadcast segment, and by using NetBIOS calls, actively probing the network to gather additional information about the devices connected to it, such as the operating system of a detected system.
The sensor doesn't determine whether the system is a rogue system. It detects systems connected to the network and reports these detections back to the McAfee epo server, which determines whether the system is rogue based on user configured settings. Intelligent filtering of network traffic The sensor filters network traffic "intelligently" it ignores unnecessary messages and captures only what it needs, which is Ethernet and IP broadcast traffic.
By filtering out unicast traffic, which might contain non local IP addresses, the sensor focuses only on devices that are part of the local network. To optimize performance and minimize network traffic, the sensor limits its communication to the server by relaying only new system detections, and by ignoring any re detected systems for a user configured time.
For example, the sensor detects itself among the list of detected systems. If the sensor sent a message every time it detected a packet from itself, the result would be a network overloaded with sensor detection messages.
For each detected system, the sensor adds the MAC address to the packet filter, so that it is not detected again, until the user configured time elapses.
The sensor implements aging on the MAC filter. After a specified time, MAC addresses for systems already detected are removed from the filter, causing those systems to be re detected and reported to the server. This process ensures that you receive accurate and current information about detected systems. Data gathering and communications to the server When the sensor detects a local network system, that is not already in the cache or blocked by a policy, it gathers information about that system by actively listening to NetBIOS calls and OS fingerprinting.
The Rogue System Sensor listens on the ports shown in the following table. This is a list of all ports, for example OS fingerprints and more. The server then uses the epolicy Orchestrator data to determine whether the system is a rogue system. You can configure the agent to cache detection events for a given time period, such as one hour, then to send a single message containing all the events from that time period.
For more information, see Configuring Rogue System Detection policy settings. Systems that host sensors Install sensors on systems that are likely to remain on and connected to the network at all times, such as servers.
If you don t have a server running in a given broadcast segment, install sensors on several workstations to ensure that at least one sensor is connected to the network at all times. To guarantee that your Rogue System Detection coverage is complete, you must install at least one sensor on each broadcast segment of your network.
Installing more than one sensor on a broadcast segment doesn't create issues around duplicate messages because the server filters any duplicates. However, additional active sensors on each subnet result in traffic sent from each sensor to the server. While maintaining as many as five or ten sensors in a broadcast segment should not cause any bandwidth issues, you should not maintain more sensors on a broadcast segment than is necessary to guarantee coverage.
Using sensors on DHCP servers reduces the number of sensors you need to install and manage on your network to ensure coverage, but it doesn't eliminate the need to install sensors to network segments that use static IP address.
Installing sensors on DHCP servers can improve coverage of your network. However, it is still necessary to install sensors in broadcast segments that use static IP address, or that have a mixed environment. A sensor installed on a DHCP server doesn't report on systems covered by that server if the system uses a static IP address. Rogue System Sensor status Rogue System Sensor status is the measure of how many of the sensors installed on your network are actively reporting to the McAfee epo server, and is displayed in terms of health.
Health is determined by the ratio of active sensors to missing sensors on your network. Sensor states are categorized into these groups: Active Active sensors report information about their broadcast segment to the McAfee epo server at regular intervals, over a fixed time.
Both the reporting period and the active period are user configured. All of the sensors on a subnet use a voting algorithm to determine which sensor is active and which change to passive. The next sensor voted active on the subnet takes over communicating with the McAfee epo server. You can use the epolicy Orchestrator Sever Settings to configure multiple active sensors on a subnet.
These missing sensors could be on a system that has been turned off or removed from the network. Passive Passive sensors check in with the McAfee epo server, but don't report information about detected systems. They wait until they are voted active by the voting algorithm to communicate the state of the broadcast segment to the McAfee epo server.
Rogue System Sensor election You can determine the active Rogue System Sensors on a subnet using either the McAfee epo server or allowing the sensors in the subnets themselves to elect which sensors are active or passive. Using the McAfee epo server to set active sensors You can use the McAfee epo server to deploy Rogue System Sensors on a subnet from the System Tree and configure the sensor numbers and communication using the sever settings.
For example, you can use: A manual process of installing sensors on specific systems Client tasks to install sensors The drawbacks to these methods include: Deploying the sensors individually from the McAfee epo server can be time consuming.
You need to determine before hand which systems to configure as Rogue System Sensors and manage them to insure they are always online or have redundant sensors. Systems added to the subnets after the initial configuration are not eligible to be active sensors. These methods don't scale well for large managed networks. Allowing Rogue System Sensor elections to set active sensors Configuring Rogue System Detection to use the local sensor election feature allows Rogue System Sensors in the local subnets to elect the active sensors in the group and reduce sensor traffic back to the McAfee epo server.
This also allows you to automatically deploy a Rogue System Sensor to all nodes on your subnets. Allowing the Rogue System Sensors that are on a subnet themselves to elect which sensors are active or passive has these advantages: You can install the Rogue System Sensor on every system and not worry about selecting individual active sensors.
If a system running as the active Rogue System Sensor is shut down or removed from the network, another system takes over after a configured time. If you install Rogue System Sensors on a large number of nodes on many subnets and configure the policy to Use Local Sensor Election, then later change the policy to Use epo server to determine active sensors, all of those previously installed sensors could overwhelm the McAfee epo server when they ask if they should become active.
The local sensor election feature works like this: If it is, it sends out a message telling the other sensors it is now an active sensor. If not, it becomes passive and waits for the next election cycle. Rogue Sensor Blacklist The Rogue Sensor Blacklist is the list of managed systems where you don't want sensors installed.
These can include systems that would be adversely affected if a sensor were installed on them, or systems you have otherwise determined should not host sensors. For example: Mission critical servers where peak performance of core services is essential, such as database servers or servers in the DMZ demilitarized zone Systems that might spend significant time outside your network, such as laptops The Rogue Sensor Blacklist is different than the Exceptions list.
In the Policy Catalog page, policies are. When you open an existing policy or create a new policy , the policy. T o see all of the policies that hav e been created per policy category , click Menu Policy Policy Catalog ,. On the P olicy Catalog page, users can see. T o see which policies, per product, are applied to a specific group of the S ystem T ree, click Menu. Systems System T ree Assigned Policies page, select a group , then select a Product from the drop-down list.
It provides a quick reference of graphical information such as the top 10 systems with infections. It provides an interface to create multi-site administration privileges and feature-based permissions for ePO. Master b. Source c. Fallback d. Evaluation How many Master repositories reside on an ePO server? One b. One for each site in the ePO directory tree c.
One for each group in the ePo directory tree d. In order for replication to succeed, credentials need to be specified to authenticate to the Source Repository.
The Replication task uses the Source Repository to copy the contents to the Distributed Repositories. Crystal reports, Tomcat b. Crystal reports, Apache c. SuperAgent b. Evaluation c. Source d. Fallback Which ePO core component enforces the policies on the systems?
McAfee Agent d. Tomcat service Framework service b. Tomcat service c. Apache service d. Event Parser service The sensor does not report machines with an ePO agent when they are first detected on the network, b. To prevent the detection of previously detected systems, the sensor adds those IP addresses to the IP filter.
The sensor will implement aging by quarantining unmanaged systems after a given length of time. The sensor packages the information that is gathered about the detected machine into an XML message and sends it to the ePO server. What is the size limit of the MSDE database? I00 MB b.
0コメント