Troubleshooting Cisco Secure PIX Firewalls

Troubleshooting Cisco Secure PIX Firewalls

A PIX firewall falls into the category of stateful firewall. It provides security to the perimeter network by creating and maintaining the state information of connections. PIX boosts performance because its OS is embedded and runs directly from RAM for packet processing. Cisco Adaptive Security Appliance (ASA 5500 Series), is the next-generation security appliance, which runs the same OS as the PIX, but provides more security services (for example, an SSM blade for IPS, SSL VPN, and so on) than PIX Firewall. Beginning with Version 7.0, the ASA 5500 (minimum version requirement on the ASA is 7.0), and PIX platforms (running Version 7.0), provide the same firewall features. As the primary focus of this chapter is to discuss firewall features, additional services provided by the ASA 5500 (IPS, SSL, VPN, and so on) will not be discussed. The troubleshooting discussion in this chapter is based on the PIX platform, which also can be used for ASA 5500.

PIX Firewall has a very flexible and robust command-line interface (CLI) parser that is very similar to a router (in particular on PIX Version 7.0). In addition, a GUI such as Adaptive Security Device Manager or ASDM (formally known as PIX Device Manager or PDM) and a firewall management console (MC) can be used to manage the PIX firewall. Most troubleshooting, however, is performed using the CLI; hence the primary focus on the chapter is using the CLI on the new version of PIX, which is 7.0.

Overview of PIX Firewall

The architecture of PIX Firewall is based on the Adaptive Security Algorithm (ASA), which maintains the state information and provides security to your connection. ASA is a set of rules and policies that the packet has to conform to while traversing the firewall. As mentioned before, PIX is a stateful firewall, which means it works based on connections, not on a per-packet basis. It remembers every connection through the firewall.

ASA

ASA has the following characteristics:

• ASA provides a stateful connection.
• ASA allows return packets for established connections.
• ASA tracks source and destination ports and addresses, Transmission Control Protocol (TCP) sequences, and additional TCP flags.
• TCP sequence numbers are randomized.
• The inside interface has a security level of 100.
• The outside interface has a security level of 0.
• Demilitarized zone (DMZ) interfaces have user-settable security levels from 1 through 99.
• Starting with PIX OS 5.2, users are allowed to change the default security levels of both the outside and inside interfaces, but it is not recommended.
• By default, the PIX allows traffic to pass from higher security interfaces to lower security interfaces, and in the case of TCP and User Datagram Protocol (UDP) connections, it allows the return traffic back through. The same does not hold for Internet Control Message Protocol (ICMP).

PIX Packet Processing

Packet flow across the PIX firewall is depicted in Figure 3-1. Work through the following steps to understand the packet flow:

1.	Packets are received on the ingress interface Packets arrive on the ingress interface, which is indicated by input counters of the interface.
2.	Existing connection checks Packets go through the existing connection check. If the connection exists, the ACL check is bypassed. If there is no existing connection, TCP non-SYN packets will be dropped and logged. If PIX receives a TCP SYN or UDP request packet, packets are passed to ACL checks.
3.	Interface ACL check The initial packet in the flow of packet is processed through interface ACLs. Packets that are denied by interface ACLs are dropped and logged.
4.	NAT check The initial packet in the flow must match a translation rule. To perform NAT, it is important to know the egress interface. Hence a quick route lookup is performed. If the translation is turned off, the translation is skipped. If the NAT is configured and the translation rule is matched, the connection is created on the PIX firewall. If an overlapping NAT is configured, the following order of NAT operations is performed: a. nat 0 access-list (nat-exempt). b. Match existing xlates. c. Match static commands (first match). Static NAT with and without access-list is checked before Static PAT with and without an access-list. d. Match nat commands. nat access-list is matched first. Then nat is checked. If the ID is 0, create an identity xlate. Use a global pool for dynamic NAT. Use a global pool for dynamic PAT.
5.	Inspection check Inspections are applied to NAT embedded IPs in the payload. Commands in control channels are inspected for compliance and secondary data channels. Additional security checks are also applied to the packet with inspection.
6.	Perform NAT Perform IP address or the port translation.
7.	Packets forwarded to egress interface Packets are forwarded to the egress interface. The egress interface is determined by the translation rules first. If translation rules do not specify the egress interface, the global route lookup is performed to determine the egress interface.
8.	Interface route lookup Once the packet is on the egress interface, an interface route lookup is performed. Only routes pointing out the egress interface are used to forward the packet. Remember that the translation rule can forward the packet to the egress interface, even though the routing table may point to a different interface.
9.	Layer 2 address lookup for the next-hop address After the interface route lookup is performed, the next-hop address is identified. At this stage, ARP resolution is performed. Then the packets are put in the wire, and the interface counters are incremented. File System Overview When upgraded to PIX 7.0, PIX Flash memory is reformatted. The contents of the files are different than in the older versions. Table 3-1 shows the different files that go into Flash on PIX Firewall Version 6.3 and earlier, and on PIX Firewall Version 7.0 and later. Table 3-1. Different Files Go Into Flash On Different Versions Release 6.3 and Earlier Release 7.0 and Later SW Image SW Image Config File Config File Private Data File Private Data PDM Image ASDM Image Crash Information Backup Image (If disk and flash space are available) Backup config file (if disk and flash space are available) Virtual Firewall Config File Crash Info (Internal Only) 1M/ASA, 128K/PIX The Flash file system can be viewed with either the dir or show flash command as shown in Example 3-1. Example 3-1. Flash File System on PIX 7.0 PIX# dir Directory of flash:/ 3 -rw- 4902912 13:37:33 Nov 24 2004 cdisk.7.0.0.89 4 -rw- 6748932 13:21:13 Nov 24 2004 ASDM 16128000 bytes total (4472832 bytes free) PIX(config)# ! Boot [system | config} is the command that needs to be used to define the file ! using which the system should boot. It is possible to store more than one system ! image and config file. Designate which system image and start-up config file to boot. PIX(config)# boot system flash:/cdisk.7.0.0.89 ! Verify the start-up System Image. Display the system boot image. PIX# show bootvar BOOT variable = flash:/cdisk.7.0.0.89 Current BOOT variable = flash:/cdisk.7.0.0.89 CONFIG_FILE variable = Current CONFIG_FILE variable = PIX# Table 3-2 shows the commands available to work with the Flash File System CLI. Table 3-2. Commands Available for PIX Flash File System Command Meaning cd Change the current working directory to the one specified. delete Deletes a file. If a path is not specified, the file would be deleted from the current working directory. When deleting files the user would be prompted with the filename and asked to confirm the delete. The /recursive option would delete files recursively. dir Displays the content of the current directory. format Formats the disk using File Allocation Table (FAT). mkdir Creates a new directory. more Displays the contents of a specified file. more [/ascii] [/binary][disk:][] rename Renames a specified file. rmdir Removes a specified directory. Use will be prompted. pwd Shows the present working directory. copy Copies a file from flash: ftp, http, https, running and startup config tftp, system. Example 3-2 shows the debug command available for troubleshooting the Flash file system. Example 3-2. debug Command For Troubleshooting File System PIX# debug disk ? file file-verbose filesystem PIX# debug disk You might receive the following warnings and errors related to file system misbehavior: Out of space, run fsck, filename too long, no such file. The solution for these is self evident. Access-List The implementation of access-list is same as before on the PIX firewall, with some additional features that are discussed in the sections that follow. time-range Keyword The time-range keyword provides a way for the Network Security Manager to specify a time interval when connectivity to the specified destinations is permitted or denied. Multiple time ranges can be defined. The command allows easy and routine control of traffic connectivity through the firewall device. The time-range keyword is used to control the execution of various features in the PIX/ASA. The time-range feature is available in access control and VPN access hours (an attribute of group policy). First, define a period of timestart/stop, certain days, and so on, that can be evaluated to a true/false condition when compared to the current appliance time. Then, place the keyword qualifier Time-Range with the name as one of the last parameters on an access-list statement that describes the connectivity path. The Time-Range keyword, when applied on an access-list statement, identifies a statement that is applied only when the current time of the security appliance clock is in the time period specified by the command (a true condition). Example 3-3 shows how to configure the time-range option. Example 3-3. Using the time-range Command ! Choose a time-range name: PIX(config)# time-range ? WORD < 64 char Time range name PIX(config)# time-range sevt PIX(config-time-range)# ? ! More than one periodic entry can be defined. Decide how to specify the time period: PIX(config-time-range)# ? Time range configuration commands: absolute absolute time and date (one per time-range) exit Exit from time-range configuration mode help Help for time-range configuration commands no Negate a command or set its defaults periodic periodic time and date (multiple are permitted) ! More than one TIME-RANGE entry can be made Absolute Time Start and End, or just start ! with no end, . . . or end with no start (immediate start) PIX(config-time-range)# absolute ? end ending time and date start starting time and date PIX(config-time-range)# periodic ? Friday Friday Monday Monday Saturday Saturday Sunday Sunday Thursday Thursday Tuesday Tuesday Wednesday Wednesday daily Every day of the week weekdays Monday thru Friday weekend Saturday and Sunday ! And finally a configuration . . . time-range BusinessHours absolute start 10 periodic weekdays 7 . . . access-list outside_mpc_in remark Only WWW traffic goes to DMZ access-list outside_mpc_in extended permit tcp any 1.1.1.0 255.255.255.0 eq www time-range BusinessHours . . . ! "show time-range", "show clock" and "show access-list" are useful debugging commands ! when trying to determine if a time-range or ACE is active at the current time. e.g ! (note the inactive label in the ace below): PIX# show access-list access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096) alert-interval 300 access-list ACL1; 2 elements access-list ACL1 line 1 extended permit ip any any time-range TR1 (hitcnt=0) (inactive) access-list ACL1 line 2 extended deny ip any any (hitcnt=0) PIX# Enable/Disable Access Control Lists (ACLs) are common traffic control commands. PIX OS 7.0 provides more control, especially in troubleshooting, by providing an easy way to "turn on" or "turn off" the processing of a specific access policy (access-list entry). This aids greatly in troubleshooting. The keyword INACTIVE is applied at the end of an access-list entry to remove it from processing. The command syntax for applying the access-list is as follows: [View full width] access-list outside_access_in extended permit tcp any object-group mail-servers eq smtp inactive There are no debug commands, output, logging outputs, caveats, or limitations specifically related to this keyword. Debug information comes from the access-list command features. Outbound ACL PIX OS 7.0 provides more granular access control by allowing both "incoming at interface" and "outgoing at interface" access policies to be configured. The OUT keyword is applied on the access-group command. It identifies an access policy (access-list) that applies to outgoing traffic at the specified interface. The OUT keyword can reduce the number of commands in a configuration and make its logical interpretation easier. To bind an access-list to an interface, use the access-group command in global configuration mode. To unbind an access-list from the interface, use the "no" form of this command. access-group access-list {in | out} interface interface_name [per-user-override] no access-group access-list {in | out} interface interface_name Example 3-4 shows how to use the access-list and apply that as outbound. Example 3-4. Using an Outbound ACL PIX# configure terminal PIX(config)# PIX(config)# names PIX(config)# name user_net 10.1.1.0 PIX(config)# name dev_net 20.1.1.0 PIX(config)# name 24mask 255.255.255.0 . . . PIX(config)# access-list acl_outbound permit tcp user_net 24mask any eq 80 PIX(config)# access-list acl_outbound deny tcp dev_net 24mask any . . . PIX(config)# access-group acl_outbound out interface outside . . . Note The per-user-override option allows downloaded access-lists to override the access-list applied to the interface. If the per-user-override optional argument is not present, PIX preserves the existing filtering behavior. The per-user access list is governed by the timeout value specified by the uauth option of the timeout command, but it can be overridden by the AAA per-user session timeout value. nat-control The PIX always has been a device supporting, even requiring, Network Address Translation (NAT) for maximum flexibility and security. NAT is introduced as an option in PIX OS 7.0. Configuring nat-control on the PIX forces the PIX firewall to require NAT for a source address (for outbound traffic) and for a destination address for inbound traffic. If you upgrade PIX firewall from 6.x to Version 7.x, nat-control is enabled on the PIX. For new configurations, nat-control is disabled by default. If no nat-control is specified, only hosts that require NAT need to have a NAT rule configured. The nat-control statement is valid in routed firewall mode and in single and multiple security context modes. No new NAT functionality is provided with this feature. All existing NAT functionality remains the same. If you have no nat-control configured, and if there is a nat matching, it will go through the NAT engine. Otherwise, the packet will go through without NATing. In PIX 6.3 and earlier, the packet is dropped if there is no NAT match. Table 3-3 shows the comparison between nat-control and no nat-control. Table 3-3. Comparison Between nat-control and no nat-control nat-control no nat-control No inside nat rule No outside nat rule Deny Continue No inside nat rule outside nat rule Continue Continue No inside nat rule No outside nat rule Deny Continue The difference between the no nat-control command and the nat 0 (identity NAT) command is that identity NAT requires that traffic be initiated from the more secure interface. The no nat-control command does not have this requirement, nor does it require a static command to allow communication to inside hosts. It relies on access-policies. Modular Policy Framework (MPF) Objective There is a growing need to provide greater granularity and flexibility in configuring network policies. For example, it is extremely important to have the ability to include a destination IP address as one of the criteria to identify traffic for Network Address Translation, or the ability to create a timeout configuration that is specific to a particular TCP application, as opposed to the current timeout scheme, which applies a timeout value to all TCP applications, and so on. MPF provides the tools to meet these and other needs. MPF features are derived from quality of service (QoS) as implemented in IOS. Not all features have been carried across. MPF is built on three related CLI commands: class-map This command identifies the traffic that needs a specific type of control. Class-maps have specific names, which tie them into the policy-map. This just selects the traffic. policy-map This command describes the actions to be taken on the traffic described in the class-map. Class-maps are listed by name under the appropriate policy-map. Policy-maps have specific names too, which tie them into the service-policy. They specify what action needs to be taken. service-policy This command describes where the traffic should be intercepted for control. Only one service-policy can exist per interface. An additional service-policy, global-service-policy, is defined for traffic and general policy application. This policy applies to traffic on all interfaces. The command applies the policy. You can have only one service policy per interface. PIX 7.0 has the following restrictions for match/policy and class statements. Number of Policy-map: 64. Number of Class-map: 255. Number of Classes in a policy-map: 63. Number of match statements in a class-map: 1. For match tunnel-group and default-inspect, allow two statements. Transparent Firewall Transparent Firewall works based on Layer 2 information. This provides the ability to deploy a PIX firewall in a secure bridging mode. It provides rich Layer 2 through 7 security services as a Layer 2 device. Remember these points while implementing a Transparent Firewall on the PIX Firewall: One inside and outside interface is supported for the transparent firewall. Each directly connected network must be on the same subnet. A management IP address must be configured and should be on the same subnet as the connected network. This management IP address cannot be a default gateway for connected devices, so you should point to the other router's IP address as your default gateway. The PIX uses this IP address as the source address for packets that originate on the outside interface. You can pass non-IP traffic such as Internetwork Pack Exchange (IPX) traffic using an EtherType ACL to allow non-IP traffic through. Dynamic routing protocols will run on the device and will pass through the PIX. NAT is not supported. NAT is performed on the upstream router. You must use an extended ACL to allow Layer 3 traffic, such as IP traffic, through the PIX. If you configure multiple contexts with Transparent Firewall, you must note the following points: A management IP address is required for each context, even if you do not intend to use Telnet to the context. For multiple context modes, each context must use different VLANs; you cannot share a virtual LAN (VLAN) across contexts. For multiple context mode, each context can use the same (overlapping) subnet or different subnets under different VLANs. Be sure that the upstream router performs NAT if you use overlapping subnets. You might encounter several limitations with Transparent Firewall and VPN implementations: VPN tunnels are allowed only when configured for single (Routed) context mode. To-the-box IPsec traffic is supported. Through-the-box IPsec data, or data carried through a tunnel destined for the secure side of the transparent firewall, is not supported. Only static crypto maps are supported. The IP address configured for the management access is the VPN peer address. WebVPN is not supported while the device is operating in transparent mode. Only L2L tunnels are supported, and only one tunnel at a time. X-Auth and mode config attributes should not be used during tunnel negotiation, but are configurable. VPN tunnel cannot be initiated from the firewall (answer only). VPN Load Balancing and VPN Stateful Failover are not supported. QoS of VPN data is not supported. NAT over the tunnel is not supported.

Troubleshooting Cisco Intrusion Prevention System

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
• Modes of sensor operation
• 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:

• MainApp
• AnalysisEngine
• Command Line Interface (CLI)

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).
• NotificationApp Sends Simple Network Management Protocol (SNMP) traps when triggered by alert, status, and error events. NotificationApp uses the public domain SNMP agent. SNMP GETs provide information about the general health of the sensor.
• 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.





• IDIOM IDIOM is a data format standard that defines the event messages that are reported by the IPS, in addition to 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.




• 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
• 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
• request-block-host Request SHUN of attacker host
• 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:

Table 14-1. Supported Sensors for Version IPS 5.0

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

Table 14-2. Interface Support for Appliances and Modules Running IPS 5.0

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