|
|
The Cisco IPS Sensor OS Software runs on the Linux operating system. The underlying Linux OS has been secured and hardened by removing unnecessary packages from the OS, disabling unused services, restricting network access, and removing access to the shell.
Figure 20-6 illustrates the system design and architecture of the Cisco IPS Sensor Software system.
Figure 20-6, which shows the IPS system architecture, is taken from Cisco documentation on "Configuring the Cisco Intrusion Prevention System Sensor Using the Command Line Interface 6.0" at http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00807517f1.html.
Cisco IPS Sensor OS Software is made up of multiple application components as shown in Figure 20-6. These components are defined with their functions in the list that follows:
MainApp: The core engine of the sensor operating system. MainApp is responsible for all major functions, including managing the system processes, configuring the system, starting and stopping other applications, and performing routine maintenance. There are several subcomponents in the MainApp:
NotificationApp: Responsible for sending SNMP traps that are triggered by sensor alarms, system status, or errors. NotificationApp is also used to capture sensor health through SNMP GET.
AuthenticationApp: Responsible for validating user credentials that verify authorization status when a user is performing various configuration and management tasks.
Attack Response Controller (ARC): Provides the blocking and shunning capability to the sensor when a signature is triggered. ARC is responsible for managing network devices (routers, switches and firewalls) and can remotely log in to these network devices to dynamically apply access control lists (ACLs).
InterfaceApp: Manages sensor interface settings, such as inline pair, admin state, and bypass mechanism.
LogApp: Responsible for storing all the application logs to a log file on the sensor and all the error messages to the Event Store.
Web Server: The web-based server engine that enables the user to manage the sensor through a GUI interface. The web server engine also provides the communication interface to other IPS devices that use the RDEP2 protocol.
ctlTransSource (also known as Control Transaction server): Responsible for sending control transactions that are mainly used to enable ARC's master blocking sensor capability.
Event Store: The placeholder for storing all the sensor events, including system messages, alerts, and errors.
SensorApp (also known as Analysis Engine): Provides the packet capturing and analyzing capability when monitoring the traffic.
CLI: The command-line interface through which a user can manage and configure the sensor. CLI can be accessed by using various methods, including direct sensor console, Telnet, or SSH connections.
The sensor OS applications, illustrated in Figure 20-6, communicate with each other through a common API called IDAPI. External remote applications (such as other sensors, management applications, and third-party software) communicate with the sensor through RDEP2 and SDEE protocols. The following section describes the various communication protocols used by the Cisco IPS sensor software.
IDAPI: IPS applications discussed in Figure 20-6 use an interprocess communication API called IDAPI. IDAPI is used to handle internal communications within the software architecture. Each application registers to the IDAPI to send and receive events and control transactions. IDAPI is the binding interface through which all the applications communicate.
RDEP2: RDEP2 is another communication protocol used in the IPS sensor software, primarily for external communications. RDEP2 is an application-level communications protocol used to exchange IPS events, IP logs, configurations, and control messages between IPS clients and IPS servers. RDEP2 communications consist of request and response messages between RDEP2 clients and RDEP2 servers. RDEP2 uses the industry standards HTTP, Transparent Layer Security (TLS), Secure Sockets Layer (SSL), and Extensible Markup Language (XML) to provide a standardized interface between RDEP2 agents.
IDIOM: IDIOM is a data format standard that defines the event messages that are reported by the IPS, as well as the operational messages that are used to configure and control intrusion-detection systems. These messages consist of XML documents that conform to the IDIOM XML schema. IDIOM supports two types of interactions: the event and control transactions. Event interactions are used to exchange IPS events such as IPS alerts. Note that in the latest sensor software OS, IDIOM for the most part has been superseded by IDCONF, SDEE, and CIDEE.
IDCONF: Cisco IPS sensor software manages its configuration by using XML documents. IDCONF specifies the XML schema including IPS control transactions. The IDCONF schema does not specify the contents of the configuration documents, but rather the framework from which the configuration documents are developed. IDCONF messages are exchanged over RDEP2 and are wrapped inside IDIOM request and response messages.
SDEE: IPS produces various types of events, including intrusion alerts and status events. The IPS sensor communicates events to clients and management applications by using the proprietary RDEP2. Cisco has also developed an IPS industry leading protocol, the SDEE, which is a product-independent standard for communicating security device events. SDEE is an enhancement to the current version of RDEP2 that adds extensibility features that are needed for communicating events generated by various types of security devices.
CIDEE: CIDEE specifies the extensions to SDEE that are used by the Cisco IPS. The CIDEE standard specifies all possible extensions that are supported by IPS systems.
The CLI for the sensor software OS permits multiple users to connect to the sensor at the same time. Users can be created locally in the sensor configuration. Each user is associated with a specific role that controls the user privileges and an established boundary of what the user can and cannot do.
The CLI supports four user roles, described in the list that follows. Each user has a different privilege level; therefore, the menus and available commands vary for each role:
Administrator: This user role has the highest level of privileges. Administrators have unrestricted view access and can perform all functions on the sensor.
Operator: This user role has the second-highest level of privileges. Operators have unrestricted view access and can perform limited functions such as tuning signatures, modifying their own passwords, and assigning configuration to virtual sensors.
Viewer: This user role has the lowest level of privileges. Viewers can view configuration and event data and can modify their own passwords.
Service: This user role does not have direct access to the CLI. The service role is a special role that allows bypassing the CLI. Service account users are logged directly into the native operating system shell (underlying Linux OS bash shell). This account is mainly used for support and troubleshooting purposes only. Unauthorized modifications in the Linux OS are not supported and require the device to be reimaged to ensure proper operation. Only one user account can be associated with the service role privilege. Also note that only a user with Administrator privileges can edit the service account settings.
Note
The service account allows switching to the Linux OS root user account by executing the su- command. The root password is synchronized to the service account password.
The IPS sensor software has the following three partitions:
Application partition: The main partition, which holds the full IPS system image.
Maintenance partition: A special-purpose IPS image used to reimage the application partition of the IDSM-2 service module. Note that when the maintenance partition is reimaged, all configuration settings are lost.
Recovery partition: A special-purpose image used for the recovery of the sensor. Booting into the recovery partition enables you to completely reimage the application partition. Network settings are preserved, but all other configuration is lost.
Signatures and signature engines are the foundation of Cisco IPS solution architecture. The network-based IPS sensor monitors network traffic with a collection of predefined (built-in signatures) and user-defined signatures that can be grouped into various signature engines.
A signature is a description of a network traffic pattern that attackers use while conducting network-based attacks. The IPS sensor monitors network traffic and generates alerts when it detects malicious activity by matching the traffic to specific signatures. Cisco IPS Sensor Software is preloaded with a wide range of signatures for varying protocols. Cisco IPS Sensor Software Version 6.0 contains more than 1,000 built-in default signatures. The sensor software also supports the configuration of user-defined custom signatures.
A signature engine is a categorized group of a collection of like signatures, each of which inspects for a specific type of activity. The sensor software uses the signature engines to examine network traffic for intrusive activity with similar characteristics. For example, the TCP-based string engine handles signatures that search for specific textual strings in TCP traffic only. The signature engines are designed to perform a wide range of functions, such as pattern matching, stateful pattern matching, protocol decoding, deep-packet inspection, and other heuristic methods. Each signature engine has a specific set of parameters that have allowable ranges or sets of values.
Table 20-3 lists the Cisco IPS Signature Engines available in the IPS Sensor Software Version 6.0.
Note
The information in Table 20-3 is compiled from Cisco product documentation on "Installing and Using Cisco Intrusion Prevention System Device Manager 6.0" at http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a0080618a2e.html.
Similar to the antivirus software model, the network-based IPS sensor software must be kept up-to-date and signatures must be updated regularly. Cisco provides frequent signature updates.
Cisco has launched the Cisco Security Center, a portal that provides the latest signature updates, vendor-neutral security intelligence, exploit detection and mitigation strategies, security news, and Cisco product alerts.
The Cisco Security Center draws together the vast resources within Cisco to offer intelligence and security solutions in one location. Cisco Security Center provides around-the-clock threat and vulnerability information.
http://tools.cisco.com/security/center/home.x
Note
Use the following Cisco URL to download Cisco IPS software and signature updates: http://www.cisco.com/kobayashi/sw-center/ciscosecure/ids/crypto/.
Tip
Use the following Cisco URL to search for various types of signatures: http://tools.cisco.com/MySDN/Intelligence/searchSignatures.x.
Note
For more details on the signature engines and their detailed parameters, refer to the following Cisco documentation URL: http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a0080618a2e.html.
The Cisco IPS sensor software's system applications shown in Figure 20-6 generate various IPS events to report the occurrence of some stimulus. Every event is a data representation—for example, the alerts generated by SensorApp or errors generated by any application.
IPS events are generated on demand by the application instances within the sensor OS. There is no specific request from any other application instance to generate a particular event. They usually do not have a specific destination. They are stored locally and then retrieved by one or more application instances as needed.
The following seven types of data are communicated by the various functional units in the sensor software:
Intrusion events: Events produced by SensorApp. The sensor detects and reports the intrusion events.
Error events: Events caused by any hardware or software malfunctions.
Status events: Events reported when changes in the application's status occur; for example, the sensor configuration has been updated.
Control transaction log events: Results of a control transaction logged by the sensor.
Attack response events: An action for the Attack Response Controller (ARC); for example, a block request was triggered.
Debug events: Events used for troubleshooting and debugging that provide detailed status.
Control transaction data: Data associated with control transactions—for example, session logs and configuration data to or from an application.
These types of data are collectively referred to as IPS data.
These collections of IPS events can be categorized into five basic types:
evAlert: Alert event messages are generated to report a signature being triggered. SensorApp writes these events into the event store. Alert events can be viewed by using the CLI and IDM Event Viewer.
evStatus: Status event messages are generated to report the status and actions of the IPS applications.
evError: Error event messages are generated to report errors that occurred while attempting response actions.
evLogTransaction: Log transaction messages are generated to report the control transactions processed by each sensor application.
evShunRqst: Block request messages are generated to report when the Attack Response Controller (ARC) issues a block request.
Each IPS event is stored in the local sensor database known as the Event Store, as shown in Figure 20-6. Each event is stored with a time stamp and a unique, monotonic, ascending ID. SensorApp is the only application that writes "alert" events into the Event Store. All other applications write log, status, and error events into the Event Store.
An IPS event action is triggered when a signature is matched and an action is required to mitigate the situation.
Table 20-4 lists the basic IPS event actions available in the sensor software OS that can be configured per individual signatures. Most of the following event actions belong to each signature engine unless they are not supported or appropriate for that particular engine. For example, the ICMP signature engine cannot be configured for TCP Reset action.
Note
The information in Table 20-4 is compiled from Cisco product documentation on "Installing and Using Cisco Intrusion Prevention System Device Manager 6.0" at http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a0080618a2e.html.
The IPS sensor software offers a unique Risk Rating (RR) numerical integer that allows users to make informed decisions on the IPS inline drop actions and provides users with greater confidence by enhancing the reliability of the inline deployment. RR is primarily used internally and is a locally significant number (within the sensor) to determine the proper action to take on an event.
RR is a multidimensional formula that is applied on a per-signature basis. The RR is calculated from several components, some of which are configured, some collected, and some derived. RR has a value between 0 and 100; the higher the RR value, the greater the confidence that the event detected is an indication of malicious activity (and not a false positive).
RR represents a numerical quantification of the risk associated with a particular event on the network. The calculation takes into account the value of the network asset being attacked (for example, a server), so it is configured on a per-signature basis (Attack Severity Rating (ASR) and Signature Fidelity Rating (SFR)) and on a per-server basis Target Value Rating (TVR).
RR is a mechanism used to prioritize alerts that need user attention. These RR factors take into consideration the severity of the attack, whether it was successful, the fidelity of the signature, and the overall value of the target host. The RR is reported in the evIdsAlert.
The following values are used to calculate the RR for a particular event:
Signature Fidelity Rating (SFR): A weight associated with how well this signature might perform in the absence of specific knowledge of the target. The SFR is configured per signature and indicates how accurately the signature detects the event or condition it describes. It represents to what degree of confidence the detected behavior would produce the intended effect on the target platform if the packet under analysis were allowed to be delivered.
Attack Severity Rating (ASR): A weight associated with the severity of a successful exploit of the vulnerability. The ASR is derived from the alert severity parameter (informational, low, medium, or high) of a particular signature. The ASR is configured per signature and indicates how dangerous the event detected is.
Target Value Rating (TVR): A weight associated with the perceived value of the target. TVR is a user-configurable value (zero, low, medium, high, or mission critical) that identifies the importance of a network asset (through its IP address). For example, assign a higher TVR value to the web server than the TVR assigned to a desktop node. TVR is configured in the Event Action Rules policy.
Attack Relevancy Rating (ARR): A weight associated with the relevancy of the targeted OS. ARR is a derived value (relevant, unknown, or not relevant) is determined at alert time. The relevant OS is configured per signature.
Promiscuous Delta (PD): A weight associated with the PD is in the range of 0 to 30 and is configured per signature.
Watch List Rating (WLR): A weight associated with the CSA MC watch-list in the range of 0 to 100. (CSA MC only uses the range 0 to 35.) If the attacker for the alert is found on the watch list, the WLR for that attacker is added to the rating.
The formula to calculate the RR follows:
RR = ((ASR*TVR*SFR)/10000)+ARR-PD+WLR
Threat Rating (TR) is an RR value that has been lowered by event actions that have been taken. All event actions have a specific TR adjustment. The largest TR from all of the event actions taken is subtracted from the RR.
Table 20-5 lists the event actions with the corresponding TR values.
Cisco IPS sensor software supports the following two main types of interface roles:
Command and Control interface (also known as Management Interface): As the name implies, the Command and Control interface is used for managing and configuring the sensor. It has an IP address and is permanently enabled. It receives security and status events from the sensor and queries the sensor for statistics.
Command and Control interface is statically mapped to a specific physical interface depending on the sensor model. This mapping cannot be changed, and this interface cannot be used as a sensing interface. Table 20-6 lists the command and control interfaces for each sensor model.
Sensing Interface (also known as Sniffing interface): Sensing interfaces are purpose-built interfaces used by the sensor to monitor and analyze network traffic. Each sensor has one or more sensing interfaces depending on the sensor model. Table 20-7 lists the detailed interface support providing the number and type of sensing interfaces available for each sensor model.
Sensing interfaces can operate individually in promiscuous mode, or they can be paired to create inline interfaces for inline sensing mode.
Note
S indicates the slot number. IDS 4FE card can be installed in either slot 1 or 2.
Table 20-7 can be found at the following Cisco documentation URL: http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_installation_guide_chapter09186a0080757abc.html#wp522729.
The IPS Sensor software OS expands the sensing interface roles into various modes of implementation. There are four basic types of interface modes:
Promiscuous mode: Packets in promiscuous mode do not flow through the sensor. The sensor depends on a mirrored copy of the packet sent to the sensor. The sensor analyzes the copy of the packet rather than the actual packet on the wire. The packets are copied using network taps, the traffic mirroring SPAN feature, or selective mirroring using the VACL feature on the switch.
Note
Refer to the following Cisco documentation URL to configure Catalyst Switched Port Analyzer (SPAN) Configuration: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008015c612.shtml.
Monitoring traffic in promiscuous mode can be seen as an advantage because the sensor does not affect the packet flow with the forwarded traffic. However, the disadvantage is that the sensor cannot stop malicious traffic from reaching its intended target for certain types of attacks, such as atomic attacks (single-packet attacks).
The IPS event response actions implemented with the promiscuous sensor devices are post-event responses and rely on other devices in the network for enforcement (such as a firewall, a switch, or a router). Such response actions can be useful to prevent some types of attacks. However, in a situation similar to an atomic attack, a single packet carrying the attack vector has a good chance of reaching the target system before the promiscuous-based sensor can apply enforcement (TCP Reset or Shun ACL on a managed device).
Figure 20-7 illustrates the network-based IDS sensor in promiscuous mode. This is typically referred to as the IDS (out-of-band detection) solution.
Inline interface mode: This type of mode is the most effective method for detecting and preventing network intrusion. Inline interface mode puts the sensor directly in the middle of the traffic flow. Note that inline mode will affect packet-forwarding rates by making them slower and adding latency.
Inline mode gives the IPS sensor the capability to drop malicious traffic and stop attacks before they reach the intended target, thus providing a preventive protection service.
Inline mode analyzes traffic not only on Layer 3 and 4, but it also inspects upper layers within the payload of the packet for more sophisticated embedded attacks (Layers 3 to 7).
In inline interface pair mode, a packet comes in (ingress) through the first interface of the pair on the sensor and goes out (egress) the second interface of the pair. The packet is sent to the second interface of the pair unless that packet is being denied or modified by a signature.
Figure 20-8 illustrates the network-based IPS sensor in inline interface mode. This is typically referred to as the IPS (inline, within packet stream detection) solution. Note that a Layer 2 segmentation is required for inline mode to work; that is, the client and the first interface are on a separate VLAN, whereas the server and the second interface are on a separate VLAN, as shown in Figure 20-8. The Layer 3 network remains unchanged.
Note
Cisco IPS Sensor supports both inline interface pairs and inline VLAN pairs. IPS can also be deployed in an IDS mode that uses a single interface in promiscuous mode.
Caution
If the paired interfaces are connected to the same switch, be sure to configure them as access ports with a different access VLAN for the two ports. Otherwise, traffic will not flow through the inline interface.
Inline VLAN pair mode: Inline VLAN pair mode is also known as Inline-on-a-Stick. This mode is similar to the inline interface mode, with an extended enhanced capability to associate VLANs in pairs on a physical interface. Therefore, it is known as inline VLAN pair mode.
The sensing interface in the inline VLAN pair mode acts as an 802.1q trunk port, and the sensor performs VLAN bridging between pairs of VLANs on the trunk port.
Packets received on one of the paired VLANs are analyzed and then forwarded to the other VLAN in the pair. The sensor bridges VLANs together on the same physical interface by creating, in effect, subinterfaces that allow the sensor to bring packets incoming on VLAN X and outgoing on VLAN Y, as shown in Figure 20-9.
The sensor inspects the traffic it receives on each VLAN in each pair and can either forward the packets on the other VLAN in the pair or drop the packet if an intrusion attempt is detected. The IPS sensor can be configured to simultaneously bridge up to 255 VLAN pairs on each sensing interface.
The sensor rewrites the packet by replacing the VLAN ID field (VLAN tag) in the 802.1q header of each received packet with the ID of the egress VLAN on which the sensor forwards the packet. The sensor drops all packets received on any VLANs that are not assigned to inline VLAN pairs.
The advantage of inline VLAN pairing mode is that multiple VLAN pairs per physical interface reduce the need to have many physical interfaces per chassis.
Figure 20-9 illustrates the inline VLAN pair mode. This is typically referred to as the Inline-on-a-Stick solution.
VLAN Group mode: In VLAN Group mode, each physical interface or inline interface can be divided into VLAN group subinterfaces, each of which consists of a group of VLANs on that particular interface. With the introduction of multiple virtual sensors, the sensor can monitor one or more of these interfaces.
VLAN Group mode provides the capability of applying multiple policies to the same sensor. This allows the sensor to emulate multiple interfaces; with only a few interfaces, the sensor can seem to have many interfaces.
Cisco IPS Sensor software supports dynamic response action by blocking the offending traffic during an attack. The Attack Response Controller (ARC) function in the sensor software is responsible for managing network devices to respond to suspicious events by blocking (shunning) network access from attacking hosts and networks. The ARC is part of the MainApp application, as shown in Figure 20-6.
There are three basic types of blocking:
Connection block: Blocks all traffic from a specific source IP address to a given destination IP address and destination port.
Network block: Blocks all traffic from a given network subnet.
The ARC enforces the blocking on Cisco routers and Catalyst 6500 series switches by using ACL or VACL functions. Each ACL or VACL contains permit and deny conditions that apply to IP addresses. Other non-IOS devices and security appliances that do not support ACL or VACL use the shun function to enforce blocking instead.
The ARC controls the devices by using the IP address of the managed devices that are configured. It connects to all the managed devices in the list and sends the block (shun) instructions to every device. ARC will keep track of block time and undo the restrictions after the block time has expired.
The following parameters need to be configured on the sensor for ARC function to manage a device and issue block instructions:
Login user ID.
Login password.
Enable password.
Interfaces to be managed (for example, Ethernet0, Vlan5).
Pre-Block ACL or VACL and/or Post-Block ACL or VACL information (This is to inform the sensor of any existing ACL or VACL that is already applied to this device. The sensor will append pre or post if needed.)
Exclude address block (IP addresses or range of IP addresses that need to be excluded from blocking).
Block time.
Note
In the previous IPS Sensor software versions, ARC was formerly known as Network Access Controller. The new Cisco IPS Sensor software Version 6.0 has been updated; however, IDM and the CLI may contain references to Network Access Controller, nac, and network-access.
In addition to blocking, which was described earlier, the Cisco IPS Sensor software also supports dynamic response action by rate limiting traffic in protected networks for specified traffic classes on network devices. Similar to blocking, the Attack Response Controller (ARC) function in the sensor software is responsible for rate limiting.
The rate limiting feature provides the capability of reducing the effect of a denial of service (DoS) attack or network attack, instead of blocking it entirely. This is similar to the Committed Access Rate (CAR) function in Cisco IOS.
Rate-limit responses are supported for the Host Flood and Net Flood engines and the TCP half-open SYN signature.
The following parameters are required to implement rate limit:
Layer 3 information: Source or destination address for any rate limit
Layer 4 information: Source or destination port for rate limits with TCP or UDP protocol
Rate-limit parameters can be tuned on individual signatures. To implement rate limit, select the event action type Request Rate Limit (Table 20-4) to enforce rate limiting and set the percentage for these signatures.
Note
Cisco IOS Software Version 12.3 or later is required for ARC to successfully implement rate limit on Cisco routers.
As discussed previously, the IPS sensor software uses the Analysis Engine to perform packet analysis and alert detection. The sensor monitors traffic that flows through specified interfaces mentioned previously.
The IPS Sensor Software OS Version 6.0 introduces the concept of virtualization, whereby virtual sensors can be created in the Analysis Engine. Version 6.0 supports up to four virtual sensors.
Virtual sensors can be effectively used to monitor multiple data streams, apply different configurations to different sets of traffic, monitor two network segments with overlapping IP spaces with one sensor, or monitor concurrently both the inside and outside of a firewall with one sensor.
Multiple virtual sensors can be hosted on the same appliance, each configured with different signature behavior and traffic feeds. Each virtual sensor has its own set of unique settings and configurations, such as a unique name with a list of interfaces, inline interface pairs, inline VLAN pairs, and VLAN groups associated with it.
Each virtual sensor is associated with a specifically named signature definition, event action rules, and anomaly detection configuration.
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.
Note
For more information on the IPS Virtual Sensor feature and detailed configuration parameters, refer to the following Cisco documentation URL: http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00807517a5.html.
The IPS Sensor Software OS allows the creation of multiple security policies and the application of those multiple policies to the individual virtual sensors that were discussed previously.
A security policy configuration contains three components:
Signature definition policy
Event action rules policy
Anomaly detection policy
Cisco IPS sensor software OS version 6.0 contains a default signature definition policy called sig0, a default event action rules policy called rules0, and a default anomaly detection policy called ad0. These default policies or customized user-defined new policies can be associated with the newly defined virtual sensor (discussed earlier) as required.
Multiple security policies can be customized and created for multiple virtual sensors based on different requirements and can be applied per VLAN or physical interface.
Tip
Refer to the following Cisco documentation URL to configure signature definition policies: http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a0080618a2a.html.
Tip
Refer to the following Cisco documentation URL to configure event action rules policies: http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a0080618a28.html.
Tip
Refer to the following Cisco documentation URL to configure anomaly detection policies: http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a0080618916.html.
The IPS Sensor Software OS Version 6.0 introduces the revolutionary Anomaly Detection (AD) function built in to the sensor software architecture. The AD solution detects worm-infected hosts and worm-based attacks. AD detects the following two situations:
The network starts to become congested by worm traffic.
A single worm-infected source enters the network and starts scanning for other vulnerable hosts.
The AD works by subdividing the network into various zones, thereby enabling it to characterize the traffic patterns. This also helps reduce false negatives. A zone is a set of destination IP addresses. The following are the three zones, each with its own thresholds:
Internal zone: All the traffic that comes to your IP address range. Configure the internal zone with the IP address range of the internal network. By default, the internal zone contains no IP address range.
Illegal zone: The range of IP addresses that should never be seen in normal traffic—for example, unallocated IP addresses or part of your internal IP address range that is unused. Packets that do not match the set of IP addresses in the internal or illegal zone are handled by the external zone. By default, the illegal zone contains no IP address range.
External zone: All the traffic that goes to the Internet. The external zone is the default zone with the default range of 0.0.0.0–255.255.255.255.
The sensor does not depend on signatures. Instead, it learns primarily normal activity and establishes the network baseline for predictable behavior patterns.
Initially, the AD conducts a learning process when the most normal state of the network is reflected. Using this baseline, AD derives a set of policy thresholds that best fit the normal network.
After a normal network baseline is established, the sensor can detect any anomalies that deviated from the normal behavior pattern and take dynamic response actions accordingly.
Caution
AD assumes it gets traffic from both directions. If the sensor is configured to see only one direction of traffic, AD identifies all traffic as having incomplete connections—for example, scanners—and sends alerts for all such traffic flows.
The AD has the following three modes:
Learn mode: As mentioned earlier, AD is in the initial learning mode for the default period of 24 hours that is required to establish the normal baseline of the network. This is assuming that during this phase (learning), no attack is being carried out, or else the baseline will be misled. The initial baseline is known as the knowledge base (KB) of the network traffic.
Detect mode: This is the default mode for the AD, and for ongoing operation, the sensor should remain in detect mode 24 hours a day, 7 days a week. In this mode, the AD detects attacks based on the initial KB. AD will send alerts for any traffic flows that violate thresholds in the KB or that deviate from the normal behavior pattern. In addition, the AD records gradual changes to the KB that do not violate the thresholds and thus creates a new KB. The new KB is periodically saved and takes the place of the old KB, thus maintaining an up-to-date KB.
Inactive mode: This mode is used to disable AD monitoring by putting it in the inactive mode. Under certain circumstances, AD should be in inactive mode—for example, if the sensor is running in an asymmetric environment.
Note
Refer to the following Cisco documentation URL for IPS Anomaly Detection (AD) technique and configuration parameters: http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_configuration_guide_chapter09186a00807517a1.html.
|
|