Troubleshooting Cisco Intrusion Prevention System
Cisco Secure Intrusion Prevention System (IPS) comprises three main components: first, the IPS Sensor, which is the sniffing or inline component of Cisco Intrusion Prevention System; second, a management section of IPS (IPS MC, for example), which will be discussed in Chapter 18, "Troubleshooting IDM and IDS/IPS Management Console (IDS/IPS MC);" and third, a reporting tool (for example, a Security Monitor, which is discussed in Chapter 22, "Troubleshooting IEV and Security Monitors"). This chapter focuses on how to troubleshoot issues with IPS software on the sensor. As IPS software implementation is the same on all platforms (Sensor Appliance, IDSM-2 blade (IDSM stands for intrusion detection system module), NM (Network Module)-CIDS blade, and ASA-SSM (Security Services Module)), troubleshooting software issues on IPS software are the same across these platforms.
First, the chapter discusses the building blocks of IPS and some high-level details of IPS operation, and then it discusses troubleshooting tools and techniques. Once you understand the level of detail required to use the tools and apply techniques, you will see the main problem area categories and how to troubleshoot them efficiently and quickly. The chapter finishes with a detailed case study on different capturing techniques on various switches that are needed for IPS to function correctly, and concludes with a section on Best Practices.
Overview of IPS Sensor Software
Troubleshooting IPS issues demands that you understand the underlying architecture of IPS Software. This not only helps you feel comfortable with the product, but helps you to be a very efficient and confident troubleshooter, qualities that can distinguish you from others. To begin becoming an effective troubleshooter, you need to start with the software building blocks, which are the foundation of IPS software. Sections that follow discuss the following Sensor software topics:
- IPS deployment architecture
- IPS sensor software building blocks
- Communication protocols
- Hardware and interfaces supported
IPS Deployment Architecture
As mentioned before, there are primarily three components of an IPS deployment for a single sensor as depicted in Figure 14-1.
Figure 14-1. A Typical IPS Deployment in the Network
[View full size image]
Typically more than one sensor is managed by a single IPS MC and by the Security Monitor. The three main components of an IPS deployment are as follows:
- Sensor A sensor can be an Appliance (IDS 42xx series), IDSM-2 blade, NM-CIDS module, or ASA-SSM module. You can deploy the sensor in Inline mode or Promiscuous mode. In Inline mode, the traffic is redirected through the sensor, and in Promiscuous mode, the traffic is sniffed to the sensor. The sensor will be discussed thoroughly in this chapter.
- Management Console A management console for the sensor is used to configure and deploy the sensor software to the sensor. IPS Device Manager (IDM), an integral part of the sensor software, can be used to configure and upgrade the software on the sensor. If you want to manage more than one sensor, you can use the IPS MC, which is discussed thoroughly in Chapter 18. IPS MC communicates with sensor using SSH and SSL. More details on the communication protocol used between IPS MC (or IDM) and the sensor are discussed in the "Communication Protocol" section.
- Monitoring Device A monitoring device is used to pull the events from the sensor, which then displays the events in real time. You can also correlate events, and generate static reports as you need. Several monitoring devices support pulling events from the sensor. Security Monitor is one such monitoring device, which is discussed in detail in Chapter 22, "Troubleshooting IEV and Security Monitors."
Although it's extremely important to understand all three components of the IPS Architecture, the sensor is the core of everything. To understand the sensor in depth, you need to comprehend the IPS Software building blocks.
IPS Software Building Blocks
There are several interoperating applicationsprocesses that go into making IPS software on the Linux platform. These applications and processes are described as follows:
The applications that make up the sensor can be verified by using the show version output.
MainApp
This application initializes the sensor, starts and stops other applications, and performs upgrades. Following are some of the components of the MainApp application:
- ctlTransSource (Control Transaction server) This allows sensors to communicate control transactions with each other. Sensor currently provides Network Access Controller master blocking sensor capability with this application.
- Event Store This is an indexed store used to store IPS events (error, status, and alert system messages) that is accessible through the CLI, IDM, Adaptive Security Device Manager (ASDM), or Remote Data Exchange Protocol (RDEP).
- InterfaceApp This handles bypass and physical settings and defines paired interfaces. Physical settings are speed, duplex, and administrative state.
- LogApp This component writes all the application's log messages to the log file and the application's error messages to the Event Store.
- Network Access Controller (NAC) This manages remote network devices (firewalls, routers, and switches) to provide blocking capabilities when an alert event has occurred. Network Access Controller creates and applies access control lists (ACLs) on the controlled network device or uses the shun command on the firewalls (PIX and FWSM).
- Web Server This application is the sensor's web server, which is capable of both HTTP and HTTPS communications. The web server uses several servlets (idm, event-server, transaction-server and iplog-server) to perform their respected tasks as follows:
- - idm (Intrusion Detection Device Manager) servlet provides the IDM web-based management interface.
- - event-server servlet is used to serve events to external management applications such as Security Monitor.
- - transaction-server allows external management applications such as the IDS MC to initiate control transactions with the sensor. Control transactions are used to configure and control sensors.
- - iplog-server is used to serve IP logs to external systems such as Security Monitor.
- AuthenticationApp This application configures and manages authentication on the sensor. It verifies that users are authorized to perform Command Line Interface (CLI), IDM, ASDM, or RDEP actions.
AnalysisEngine
This application is the actual sensing engine. The AnalysisEngine performs packet capture, processes the signature and alarm channel configurations, and generates alert events based on its configuration and the IP traffic. The AnalysisEngine stores its events in the Event Store.
CLI
This application is the calling line ID (CLI) shell application that is started when you log in to the sensor through Telnet or SSH. All accounts created through the CLI will use the CLI as their shell (except the service accountonly one service account is allowed). Which CLI commands are allowed depends on the privilege of the user.
Communication Protocols
There are several communication protocols used on the sensor. These protocols enable Sensor's processes to communicate with each other and external management devices to communicate with sensors. Following are three types of communication methods:
- Inter-process Communication Within Sensor, all applications use an interprocess communication application programming interface (API) called IDAPI to handle internal communications and to interact with each otherfor example, after AnalysisEngine captures and analyzes the network traffic on its interfaces. When a signature is matched, AnalysisEngine generates an alert, which is stored in the Event Store. The communication between the AnalysisEngine and the Event Store uses IDAPI.
- External Communication with Management Console Management Console, such as IPS MC, communicates with Sensor using SSH protocol when it initially pulls the sensor's configuration. Configuration and Sensor software upgrade is pushed by IPS MC using the RDEP2 or Cisco Intrusion Detection Event Exchange (CIDEE), which uses HTTP over SSL. RDEP2 is discussed in detail in this section. IDM, which is an integral part of the IPS software, uses HTTPS (HTTP over SSL).
- External communication with Reporting devices An IPS Reporting tool such as Security Monitor communicates with sensors using a protocol called RDEP2 or CIDEE. RDEP2 uses the industry standards HTTP, Transaction Layer Security (TLS) and Secure Sockets Layer (SSL) and Extensible Markup Language (XML) to provide a standardized interface between RDEP2 agents (between the Security Monitor as client and the sensor as Server). CIDEE specifies the extensions to Security Device Event Exchange (SDEE) that are used by the Cisco IPS. SDEE 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. RDEP2, SDEE, and CIDEE are discussed next.
- RDEP2 RDEP2 is a communication protocol used to exchange IPS event, IP log, configuration, and control messages between IPS clients (for example, Security Monitor) and IPS servers (for example, Sensor). RDEP2 communications consist of request and response messages. RDEP2 clients initiate request messages to RDEP2 servers. RDEP2 servers respond to request messages with response messages.RDEP2 defines three classes of request/response messages: event, IP log, and transaction messages. Event messages include IPS alert, status, and error messages. Clients use IP log requests to retrieve IP log data from servers. Transaction messages are used to configure and control IPS servers.RDEP2 uses HTTP, TLS and SSL and XML to provide a standardized interface between RDEP2 monitoring tool (Security Monitor) and the IPS sensor. RDEP2 uses HTTP message formats and message exchange protocol to exchange messages between the monitoring device and the sensor.IPS sensors can accept connections from one to ten RDEP2 clients (Security Monitor) simultaneously. Clients selectively retrieve data by time range, type of event (alert, error, or status message), and level (alert = high, medium, low, or informational; error = high, medium, or low). Events are retrieved by a query (a single bulk get), a subscription (a real-time persistent connection), or both. Communications are secured by TLS or SSL. The monitoring application sends an RDEP2 event request to the sensor's web server, which passes it to the event server. The event server queries the event store through Intrusion Detection Application Programming Interface (IDAPI), and then returns the result. For retrieving events, the sensor is backward-compatible to RDEP, even though the new standard for retrieval is RDEP2. It is strongly recommended to use RDEP2 to retrieve events and send configuration changes for IPS 5.0.IPS MC also sends configuration changes to the sensor through RDEP2. The IPS MC sends an RDEP2 control transaction to the sensor's web server, which passes it to the control transaction server. The control transaction server passes the control transaction through IDAPI to the appropriate application, waits for the application's response, and then returns the result.
- SDEE SDEE, developed by Cisco Systems, Inc., 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.Systems that use SDEE to communicate events to clients are referred to as SDEE providers. SDEE specifies that events can be transported using the HTTP or HTTP over SSL and TLS protocols. When HTTP or HTTPS is used, SDEE providers act as HTTP servers, whereas SDEE clients are the initiators of HTTP requests.
- 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. Specific systems may implement a subset of CIDEE extensions. However, any extension that is designated as being required must be supported by all systems. CIDEE supports the following events:
- -
This is used for error events. Error events are generated by the CIDEE provider when the provider detects an error or warning condition. The event contains an error code and textual description of the error. - -
This is used for status message events. Status message events are generated by CIDEE providers to indicate that something of potential interest occurred on the host. Different types of status messages can be reported in the status eventone message per event. Each type of status message contains a set of data elements that are specific to the type of occurrence that the status message is describing. The information in many of the status messages might be useful for audit purposes. Errors and warnings are not considered status information and are reported using rather than . - -
This is used for a block request event. It is generated to indicate that a block action is to be initiated by the service that handles network blocking.
- -
- IDCONF IPS 5.0 manages its configuration using XML documents. IDCONF specifies the XML schema including IPS 5.0 control transactions. The IDCONF schema does not specify the contents of the configuration documents, but rather the framework and building blocks from which the configuration documents are developed. It provides mechanisms that let the IPS managers and CLI ignore features that are not configurable by certain platforms or functions through the use of the feature-supported attribute. IDCONF messages are exchanged over RDEP2 and are wrapped inside IDIOM request and response messages. IDIOM, for the most part, has been superseded by IDCONF, SDEE, and CIDEE.
Modes of Sensor Operation
Starting from IPS version 5.0, Sensor can function in one of the following modes:
- Inline bypass
- Promiscuous
- Combined
Modes are described in the sections that follow.
Inline Mode
Running Inline mode puts the IPS sensor directly into the traffic flow. Because an inline IPS sensor sits in the path of traffic flow, it stops attacks by dropping malicious traffic before it reaches the intended target, thus providing a protective service. Not only is the inline device processing information on Layers 3 and 4, but it is also analyzing the contents and payload of the packets for more sophisticated embedded attacks (Layers 3 to 7). This deeper analysis lets the system identify and stop or block attacks that normally would pass through a traditional firewall device.
In Inline mode, a packet comes in through the first interface of the pair of the sensor and out 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. You can configure ASA-SSM to operate inline even though it has only one sensing interface.
In Inline mode, in addition to Blocking, and TCP reset, which are available in Promiscuous mode, additional action types include the following:
- request-block-connection Request SHUN of connection
- deny-attacker-inline Do not transmit packets with source address of attacker
- deny-packet-inline Do not transmit the single packet causing alert
- deny-connection-inline Do not transmit packets on this TCP connection
- log-attacker-packets Activate packet logging for attacker address
- log-victim-packets Activate packet logging for victim address
- log-pair-packets Activate packet logging for attacker/victim address pair
- reset-tcp-connection Send TCP RST packets to terminate connection
- produce-alert Write evIdsAlert to EventStore
- produce-verbose-alert Write evIdsAlert to EventStore with triggerPacket
- request-snmp-trap Write evIdsAlert to EventStore with SNMP request in AlarmTraits
Note
Even though you can run IPS 5.0 software on IDS-4210, and Cisco IDS Network Module (NM-CIDS), these two sensors do not operate in Inline mode.
Inline Bypass Mode
Because the traffic is passing through the sensor in Inline mode, it is a point of failure for the network behind it. To mitigate this risk, a software driver-level Bypass mode option is available. The Bypass mode will unconditionally copy packets from one interface to the other. The Bypass has an Automatic mode that will activate it during sensorApp configuration operations, or if sensorApp is unresponsive. Automatic bypass mode is turned on by default, which is the recommended configuration. However, if you want to turn Bypass on permanently, there is a serious security consequence, as all the packets will bypass IPS processing subsystems.
Note
Bypass mode functions only when the operating system is running. If the sensor is powered off or shut down, Bypass mode does not worktraffic is not passed to the sensor.
Promiscuous Mode
Packets do not flow through the IPS in Promiscuous mode. The sensor analyzes a copy of the monitored traffic rather than the actual redirected packet. The advantage of operating in Promiscuous mode is that the IPS does not affect the packet flow. The disadvantage of operating in Promiscuous mode, however, is that the IPS cannot stop malicious traffic from reaching its intended target for certain types of attacks, such as atomic attacks (single-packet attacks). The response actions implemented by promiscuous IPS devices are post-event responses and often require assistance from other networking devices, for example, the Blocking feature. TCP reset is another action type in Promiscuous mode, but not a guaranteed mechanism to stop attacks. Although such response actions can prevent some classes of attacks, for atomic attacks, the single packet has the chance of reaching the target system before the promiscuous-based sensor can apply an ACL modification on a managed device (such as a firewall, switch, or router) or perform TCP reset on the connection.
Combined Modes
Sensor platforms with three or more interfaces can combine both Inline and Promiscuous traffic input, or with four or more interfaces, you can have two separate inline feeds. The combinations are flexible; the only rule is that Inline mode takes two interfaces. Note that if you have the same traffic coming in on multiple interfaces, irregular results will ensue. You might see duplicate non-TCP alarms, or with TCP you might get many 13xx alarms or TCP stream collisions resulting in no alarm.
Hardware and Interfaces Supported
It is important to know which sensors support IPS version 5.0. Table 14-1 summarizes all the sensors that support IPS 5.0. This information is taken from the following link, so refer to this link for additional details:
Model Name | Part Number | Optional Interfaces |
|---|---|---|
IDS-4210 | IDS-4210 IDS-4210-K9 IDS-4210-NFR | |
IDS-4215 | IDS-4215-K9 IDS-4215-4FE-K9 | IDS-4FE-INT= |
IDS-4235 | IDS-4235-K9 | IDS-4FE-INT= |
IDS-4250 | IDS-4250-TX-K9 IDS-4250-SX-K9 IDS-4250-XL-K9 | IDS-4FE-INT=, IDS-4250-SX-INT=, IDS-XL-INT= IDS-XL-INT= |
IPS-4240 | IPS-4240-K9 | |
IPS-4255 | IPS-4255-K9 | |
ASA-SSM-10 | ASA-SSM-AIP-10-K9 | |
ASA-SSM-20 | ASA-SSM-AIP-20-K9 | |
IDSM-2 | WS-SVC-IDSM2-K9 | |
NM-CIDS | NM-CIDS-K9 |
Many times, knowing and using the proper interfaces for different purposes is a challenge, and the source of many problems with IPS operation. Table 14-2 summarizes all the available interfaces that are supported on sensors. This information is taken from the following location:
http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids11/hwguide/hwintro.htm#wp490986
Base Chassis | Added PCI Cards | Interfaces Supporting Inline | Possible Port Combinations | Interfaces Not Supporting Inline |
|---|---|---|---|---|
IDS-4210 | None | N/A | All | |
IDS-4215 | None | N/A | All | |
IDS-4215 | 4FE | FastEthernet0/1 4FE FastEthernet1/0 FastEthernet1/1 FastEthernet1/2 FastEthernet1/3 | 1/0<->1/1 1/0<->1/2 1/0<->1/3 1/1<->1/2 1/1<->1/3 1/2<->1/3 0/1<->1/0 0/1<->1/1 0/1<->1/2 0/1<->1/3 | FastEthernet0/0 |
IDS-4235 | None | N/A | All | |
IDS-4235 | 4FE | 4FE FastEthernet1/0 FastEthernet1/1 FastEthernet1/2 FastEthernet1/3 | 1/0<->1/1 1/0<->1/2 1/0<->1/3 1/1<->1/2 1/1<->1/3 1/2<->1/3 | GigabitEthernet0/0 GigabitEthernet0/1 |
IDS-4250 | None | N/A | All | |
IDS-4250 | 4FE | 4FE FastEthernet1/0 FastEthernet1/1 FastEthernet1/2 FastEthernet1/3 | 1/0<->1/1 1/0<->1/2 1/0<->1/3 1/1<->1/2 1/1<->1/3 1/2<->1/3 | GigabitEthernet0/0 GigabitEthernet0/1 |
IDS-4250 | SX | None | N/A | All |
IDS-4250 | XL | 2 SX of the XL GigabitEthernet2/0 GigabitEthernet2/1 | 2/0<->2/1 | GigabitEthernet0/0 GigabitEthernet0/1 |
IDSM-2 | port 7 and 8 GigabitEthernet0/7 GigabitEthernet0/8 | 0/7<->0/8 | GigabitEthernet0/2 | |
IPS-4240 | 4 onboard GE GigabitEthernet0/0 GigabitEthernet0/1 GigabitEthernet0/2 GigabitEthernet0/3 | 0/0<->0/1 0/0<->0/2 0/0<->0/3 0/1<->0/2 0/1<->0/3 0/2<->0/3 | Management0/0 | |
IPS-4255 | 4 onboard GE GigabitEthernet0/0 GigabitEthernet0/1 GigabitEthernet0/2 GigabitEthernet0/3 | 0/0<->0/1 0/0<->0/2 0/0<->0/3 0/1<->0/2 0/1<->0/3 0/2<->0/3 | Management0/0 | |
NM-CIDS | None | N/A | All | |
ASA-SSM-10 | GigabitEthernet0/1 | By security context | GigabitEthernet0/0 | |
ASA-SSM-20 | GigabitEthernet0/1 | By security context | GigabitEthernet0/0 |
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
