Understanding the Virtual Sensor
The sensor can receive data inputs from one or many monitored data streams. These monitored data streams can either be physical interface ports or virtual interface ports. For example, a single sensor can monitor traffic from in front of the firewall, from behind the firewall, or from in front of and behind the firewall concurrently. A single sensor can monitor one or more data streams. In this situation a single sensor policy or configuration is applied to all monitored data streams.
With virtual sensors, you can create separate policies to apply to specific traffic feeds. For example, if you want to create a policy for a data center and a second much different policy for the campus network, yet run both policies on the same hardware device, you can configure separate virtual sensors to implement these policies.
You configure the following policies and settings separately for a virtual sensor:
-
Signature and signature settings (policies in the IPS > Signatures folder).
-
Event action policies (policies in the IPS > Event Actions folder).
-
Anomaly detection policies (the IPS > Anomaly Detection policy) and the anomaly detection mode (in the Virtual Sensors policy).
-
The promiscuous interfaces, inline interface pairs, inline VLAN pairs, inline VLAN groups, or promiscuous VLAN groups that the virtual sensor monitors.
Note |
No packet is processed by more than one virtual sensor; you cannot assign the same physical or logical interface to more than one sensor. Packets from interfaces, inline interface pairs, inline VLAN pairs, and VLAN groups that are not assigned to any virtual sensor are disposed of according to the inline bypass configuration that you define in the Interfaces policy. |
-
The inline TCP session tracking and Normalizer modes (in the Virtual Sensors policy).
Note |
If you create a policy instance on an IPS device for signatures, event actions, or anomaly detection but do not assign it to any of the virtual sensors on that device (that is, you do not use that policy instance), then that policy instance is deleted by Security Manager during deployment. |
All other policies and settings are configured on the parent device that hosts the virtual sensor. For example, if you want to use global correlation, you configure it on the parent device and the virtual sensors share that configuration.
You can configure up to four virtual sensors on one appliance, but you can add only three user-defined virtual sensors. The first virtual sensor, vs0, is the base sensor and you cannot delete it. In Security Manager, virtual sensors are presented as follows:
-
The device selector in Device view contains the parent device, which doubles as the base virtual sensor, vs0. Select this device to configure all device-level policies and to create virtual sensors in the Virtual Sensors policy.
-
Any user-defined virtual sensors are also shown in the device selector in Device view. The display name of the real device is prepended to the beginning of the name of the virtual sensor. In most cases, the result is that the virtual sensors appear next to the parent (real) device that the virtual sensor is on. For example, on the host (real device) named “bob,” the virtual sensor with the name “vs1” will appear in the device list as “bob_vs1.”
To configure the signature, anomaly detection, and event action policies for a virtual sensor, you must select it in the device selector. You cannot configure these policies by selecting the parent device; those policies on the parent device are for the vs0 base sensor.
The following topics explain more about virtual sensors:
Advantages and Restrictions of Virtualization
An advantage of using virtual sensors is that you can operate more than one virtual sensor on one appliance while configuring each virtual sensor differently with regard to signature behavior and traffic feed. For example, if you want to create a policy for a data center and a second much different policy for the campus network, yet run both policies on the same hardware device, you can configure separate virtual sensors to implement these policies.
Virtualization has the following advantages:
-
You can apply different configurations to different sets of traffic.
-
You can monitor two networks with overlapping IP spaces with one sensor.
-
You can monitor both inside and outside a firewall or NAT device.
Virtualization has the following restrictions:
-
You must assign both sides of asymmetric traffic to the same virtual sensor.
-
Using VACL capture or SPAN (promiscuous monitoring) is inconsistent with regard to VLAN tagging, which causes problems with VLAN groups.
-
When using Cisco IOS software, a VACL capture port or a SPAN target does not always receive tagged packets even if it is configured for trunking.
-
When using the MSFC, fast path switching of learned routes changes the behavior of VACL captures and SPAN.
-
-
Persistent store is limited.
-
Not all IPS sensors support multiple virtual sensors. The Virtual Sensors policy appears for all IPS appliances and service modules, because you must use it to assign interfaces to the base vs0 sensor. If the Add button in the policy is disabled for a device, and you have not configured user-defined virtual sensors, then the device does not support virtualization. Examples of devices that do not support virtualization include the Cisco IPS 4215, NM-CIDS, AIM-IPS, NME-IPS, and AIP-SSC. IDSM2 supports virtualization, but it does not support VLAN groups or inline interface pairs.
-
You must use IPS 6.0+ software. Older software versions do not support virtualization.
-
Cisco IOS IPS devices do not support virtualization. Use the IPS > Interface Rules policy to specify the interfaces that IPS should monitor.
Virtualization has the following traffic capture requirements:
-
The virtual sensor must receive traffic that has 802.1q headers (other than traffic on the native VLAN of the capture port).
-
The sensor must see both directions of traffic in the same VLAN group in the same virtual sensor for any given sensor.
Related Topics
Inline TCP Session Tracking Mode
When you choose to modify packets inline, if the packets from a stream are seen twice by the Normalizer engine, it cannot properly track the stream state and often the stream is dropped. This situation occurs most often when a stream is routed through multiple VLANs or interfaces that are being monitored by the IPS. A further complication in this situation is the necessity of allowing asymmetric traffic to merge for proper tracking of streams when the traffic for either direction is received from different VLANs or interfaces.
To deal with this situation, you can set the mode so that streams are perceived as unique if they are received on separate interfaces or VLANs (or the subinterface for VLAN pairs).
The following inline TCP session tracking modes apply:
-
Interface and VLAN—All packets with the same session key (AaBb) in the same VLAN (or inline VLAN pair) and on the same interface belong to the same session. Packets with the same key but on different VLANs are tracked separately.
-
VLAN Only—All packets with the same session key (AaBb) in the same VLAN (or inline VLAN pair) regardless of the interface belong to the same session. Packets with the same key but on different VLANs are tracked separately.
-
Virtual Sensor—All packets with the same session key (AaBb) within a virtual sensor belong to the same session. This is the default and almost always the best option to choose.
You configure the inline TCP session tracking mode as a property of the virtual sensor as described in Defining A Virtual Sensor.
Understanding Normalizer Mode
Normalizer mode applies only when the sensor is operating in inline mode. The default is strict evasion protection, which is full enforcement of TCP state and sequence tracking. The Normalizer enforces duplicate packets, changed packets, out-of-order packets, and so forth, which helps prevent attackers from evading the IPS.
Asymmetric mode disables most of the Normalizer checks. Use Asymmetric mode only when the entire stream cannot be inspected, because in this situation, attackers can now evade the IPS.
You configure the Normalizer mode as a property of the virtual sensor as described in Defining A Virtual Sensor.
Assigning Interfaces to Virtual Sensors
An IPS sensor monitors traffic that traverses interfaces, interface pairs, or VLAN pairs assigned to a virtual sensor.
You can assign one or more of the following types of interfaces to a virtual sensor:
-
Promiscuous interface—A physical interface that does not have VLAN groups and which is not part of an inline interface pair.
-
Inline interface pair—A logical interface composed of two physical interfaces.
-
Inline VLAN pair—A logical interface composed of two VLANs.
-
Promiscuous VLAN group—A VLAN group that is assigned to a subinterface on a physical interface.
The physical interface cannot already be used for an inline interface or VLAN pair. There can be many promiscuous VLAN groups on the same promiscuous interface, but the VLANs assigned cannot overlap. Once a VLAN group is assigned to a promiscuous interface, it is no longer a plain promiscuous interface and can only be used for promiscuous VLAN groups.
-
Inline VLAN group—A VLAN group that is assigned to a subinterface of an inline interface pair.
There can be many inline VLAN groups on the same inline interface pair, but the VLANs assigned cannot overlap. Once a VLAN group is assigned to an inline interface pair it is no longer a plain inline interface pair and can only be used for inline VLAN groups.
VLAN groups cannot be assigned to inline VLAN pairs.
You must configure the interfaces before you can assign them to virtual sensors. For more information about configuring all of these types of interfaces, see Configuring Interfaces. For information on assigning interfaces to virtual sensors, see Defining A Virtual Sensor.
Identifying the Virtual Sensors for a Device
If you configure user-defined virtual sensors on an IPS appliance or service module, the virtual sensor appears in the device selector in Device view.
Normally, the display name of a virtual sensor is in the form device-name_virtual-sensor-name , where device-name is the name of the parent device, and virtual-sensor-name is the name of the virtual sensor. For example, the virtual sensor vs1 on device 10.100.10.10 would be 10.100.10.10_vs1.
Thus, under normal conditions, the virtual sensors for a device should appear immediately after the parent device in the device selector. However, you can change the virtual sensor’s display name by editing the device properties. If you alter the default name, the virtual sensors might not appear anywhere near the parent device in the device selector.
You can use the following techniques to identify the virtual sensors defined on a device, or to identify the parent device of a virtual sensor:
-
To see a list of virtual sensors defined on an IPS device, select the Virtual Sensors policy on the device. The table shows all virtual sensors, including the base vs0 sensor. Note that the vs0 sensor does not appear separately in the device selector; it is represented by the parent device itself.
Unless you radically alter the display names of virtual sensors, the virtual sensor name, along with the parent device’s display name, should help you find the virtual sensor in the device selector.
-
To determine which IPS device is the host of a virtual sensor, right-click the virtual sensor in the device selector and select Device Properties. The Hostname display-only field on the General tab shows the host device display name plus the virtual sensor name as defined on the device.