Wireless LAN Controller and IPS Integration Guide

Introduction

The Cisco Unified Intrusion Detection System (IDS)/Intrusion Prevention System (IPS) is part of the Cisco Self-Defending Network and is the first integrated wired and wireless security solution in the industry. The Cisco Unified IDS/IPS takes a comprehensive approach to security—at the wireless edge, wired edge, WAN edge, and through the data center. When an associated client sends malicious traffic through the Cisco Unified Wireless Network, a Cisco wired IDS device detects the attack and sends shun requests to Cisco Wireless LAN Controllers (WLCs), which then disassociate the client device.

The Cisco IPS is an inline, network-based solution, designed to accurately identify, classify, and stop malicious traffic, including worms, spyware / adware, network viruses, and application abuse, before they affect business continuity.

With the utilization of Cisco IPS Sensor software version 5, the Cisco IPS solution combines inline prevention services with innovative technologies to improve accuracy. The result is total confidence in the provided protection of your IPS solution, without the fear of legitimate traffic being dropped. The Cisco IPS solution also offers comprehensive protection of your network through its unique ability to collaborate with other network security resources and provides a proactive approach to the protection of your network.

The Cisco IPS solution helps users stop more threats with greater confidence through the use of these features:

• Accurate inline prevention technologies—Provides unparalleled confidence to take preventive action against a broader range of threats without the risk of dropping legitimate traffic. These unique technologies offer intelligent, automated, contextual analysis of your data and help ensure that you receive the most out of your intrusion prevention solution.

• Multi-vector threat identification—Protects your network from policy violations, vulnerability exploitations, and anomalous activity through detailed inspection of traffic in Layers 2 through 7.

• Unique network collaboration—Enhances scalability and resiliency through network collaboration, including efficient traffic capture techniques, load-balancing capabilities, and visibility into encrypted traffic.

• Comprehensive deployment solutions—Provides solutions for all environments, from small and medium-sized businesses (SMBs) and branch office locations to large enterprise and service provider installations.

• Powerful management, event correlation, and support services—Enables a complete solution, including configuration, management, data correlation, and advanced support services. In particular the Cisco Security Monitoring, Analysis, and Response System (MARS) identifies, isolates, and recommends precision removal of offending elements, for a network wide intrusion prevention solution. And the Cisco Incident Control System prevents new worm and virus outbreaks by enabling the network to rapidly adapt and provide a distributed response.

When combined, these elements provide a comprehensive inline prevention solution and give you the confidence to detect and stop the broadest range of malicious traffic before it affects business continuity. The Cisco Self-Defending Network initiative calls for integrated and built-in security for network solutions. Current Lightweight Access Point Protocol (LWAPP)-based WLAN systems only supports basic IDS features due to the fact that it is essentially a Layer 2 system and it has limited line-processing power. Cisco releases new code in a timely manner to include new enhanced features into the new codes. Release 4.0 has the latest features that include the integration of an LWAPP-based WLAN system with the Cisco IDS/IPS product line. In this release, the goal is to allow the Cisco IDS/IPS system to instruct the WLCs to block certain clients from access to wireless networks when an attack is detected anywhere from Layer 3 through Layer 7 that involves the client in consideration.

Prerequisites

Requirements

Ensure that you meet these minimum requirements:

• WLC firmware version 4.x and later

• Knowledge on how to configure Cisco IPS and the Cisco WLC is desirable.

Components Used

Cisco WLC

These controllers are included with software release 4.0 for IDS modifications:

• Cisco 2000 Series WLC

• Cisco 2100 Series WLC

• Cisco 4400 Series WLC

• Cisco Wireless Services Module (WiSM)

• Cisco Catalyst 3750G Series Unified Access Switch

• Cisco Wireless LAN Controller Module (WLCM)

Access Points

• Cisco Aironet 1100 AG Series Lightweight Access Points

• Cisco Aironet 1200 AG Series Lightweight Access Points

• Cisco Aironet 1300 Series Lightweight Access Points

• Cisco Aironet 1000 Series Lightweight Access Points

Management

• Cisco Wireless Control System (WCS)

• Cisco 4200 Series Sensor

• Cisco IDS Management - Cisco IDS Device Manager (IDM)

Cisco Unified IDS/IPS Platforms

• Cisco IPS 4200 Series Sensors with Cisco IPS Sensor Software 5.x or later.

• SSM10 and SSM20 for the Cisco ASA 5500 Series Adaptive Security Appliances with Cisco IPS Sensor Software 5.x

• Cisco ASA 5500 Series Adaptive Security Appliances with Cisco IPS Sensor Software 5.x

• Cisco IDS Network Module (NM-CIDS) with Cisco IPS Sensor Software 5.x

• Cisco Catalyst 6500 Series Intrusion Detection System Module 2 (IDSM-2) with Cisco IPS Sensor Software 5.x

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Cisco IDS Overview

The major components of the Cisco IDS (Version 5.0) are:

• Sensor App—Performs packet capture and analysis.

• Event Storage Management and Actions Module—Provides storage of policy violations.

• Imaging, Install and Startup Module—Loads, initializes, and starts all the system software.

• User Interfaces and UI Support Module—Provides an embedded CLI and the IDM.

• Sensor OS—Host operating system (based on Linux).

The Sensor Application (IPS software) consists of:

• Main App—Initializes the system, starts and stops other applications, configures the OS and is responsible for upgrades. It contains these components:

  • Control Transaction Server—Allows the Sensors to send control transactions which are used to enable the Attack Response Controller (formerly known as Network Access Controller) Master Blocking Sensor capability.

  • Event Store—An indexed store used to store IPS events (errors, status and alert system messages) that is accessible through the CLI, IDM, Adaptive Security Device Manager (ASDM), or Remote Data Exchange Protocol (RDEP).

• Interface App—Handles bypass and physical settings and defines paired interfaces. Physical settings consist of speed, duplex, and administrative states.

• Log App—Writes the log messages of the application to the log file and the error messages to the Event Store.

• Attack Response Controller (ARC) (formerly known as Network Access Controller)—Manages remote network devices (firewalls, routers, and switches) to provide blocking capabilities when an alert event has occurred. ARC creates and applies access control lists (ACLs) on the controlled network device or uses the shun command (firewalls).

• Notification App—Sends SNMP traps when triggered by an alert, status, and error events. The Notification App uses a public domain SNMP agent in order to this. The SNMP GETs provide information about the health of a Sensor.

  • Web Server (HTTP RDEP2 server)—Provides a web user interface. It also provides a means to communicate with other IPS devices through RDEP2 using several servlets to provide IPS services.

  • Authentication App—Verifies that users are authorized to perform CLI, IDM, ASDM, or RDEP actions.

• Sensor App (Analysis Engine)—Performs packet capture and analysis.

• CLI—The interface that is run when users successfully log in to the Sensor through Telnet or SSH. All accounts created through the CLI use the CLI as their shell (except the service account - only one service account is allowed). Allowed CLI commands depend on the privilege of the user.

All IPS applications communicate with each other through a common Application Program Interface (API) called IDAPI. Remote applications (other Sensors, management applications, and third-party software) communicate with Sensors through RDEP2 and Security Device Event Exchange (SDEE) protocols.

It must be noted that the Sensor has these disk partitions:

• Application Partition—Contains the full IPS system image.

• Maintenance Partition—A special purpose IPS image used to re-image the application partition of the IDSM-2. A re-image of the maintenance partition results in lost configuration settings.

• Recovery Partition—A special purpose image used for recovery of the Sensor. Booting into the recovery partition enables users to completely re-image the application partition. Network settings are preserved, but all other configurations are lost.

Cisco IDS and WLC – Integration Overview

Version 5.0 of the Cisco IDS introduces the ability to configure deny actions when policy violations (signatures) are detected. Based on user configuration at the IDS/IPS system, a shun request can be sent to a firewall, router, or WLC in order to block the packets from a particular IP address.

With the Cisco Unified Wireless Network Software Release 4.0 for Cisco Wireless Controllers, a shun request needs to be sent to a WLC in order to trigger the client blacklisting or exclusion behavior available on a controller. The interface the controller uses to get the shun request is the command and control interface on the Cisco IDS.

• The controller allows up to five IDS Sensors to be configured on a given controller.

• Each configured IDS Sensor is identified by its IP address or qualified network name and authorization credentials.

• Each IDS Sensor can be configured on a controller with a unique query rate in seconds.

IDS Shunning

The controller queries the Sensor at the configured query rate in order to retrieve all the shun events. A given shun request is distributed throughout the entire mobility group of the controller that retrieves the request from the IDS Sensor. Each shun request for a client IP address is in effect for the specified timeout seconds value. If the timeout value indicates an infinite time, then the shun event ends only if the shun entry is removed on the IDS. The shunned client status is maintained on each controller in the mobility group even if any or all of the controllers are reset.

Note: The decision to shun a client is always made by the IDS Sensor. The controller does not detect Layer 3 attacks. It is a far more complicated process to determine that the client is launching a malicious attack at Layer 3. The client is authenticated at Layer 2 which is good enough for the controller to grant Layer 2 access.

Note: For example, if a client gets a previous offending (shunned) IP address assigned, it is up to the Sensor timeout to unblock the Layer 2 access for this new client. Even if the controller gives access at Layer 2, the client traffic might be blocked at routers in Layer 3 anyway, because the Sensor also informs routers of the shun event.

Assume that a client has IP address A. Now, when the controller polls the IDS for shun events, the IDS sends the shun request to the controller with IP address A as the target IP address. Now, the controller black lists this client A. On the controller, clients are disabled based on a MAC address.

Now, assume that the client changes its IP address from A to B. During the next poll, the controller gets a list of shunned clients based on IP address. This time again, IP address A is still in the shunned list. But since the client has changed its IP address from A to B (which is not in the shunned list of IP addresses), this client with a new IP address of B is released once the timeout of black listed clients is reached on the controller. Now, the controller starts to allow this client with new the IP address of B (but the client MAC address remains the same).

Therefore, although a client remains disabled for the duration of the controller exclusion time and is re-excluded if it re-acquires its previous DHCP address, that client is no longer disabled if the IP address of the client that is shunned changes. For example, if the client connects to the same network and the DHCP lease timeout is not expired.

Controllers only support connection to the IDS for client shunning requests that use the management port on the controller. The controller connects to the IDS for packet inspection via the applicable VLAN interfaces that carry wireless client traffic.

On the controller, the Disable Clients page shows each client that has been disabled via an IDS Sensor request. The CLI show command also displays a list of blacklisted clients.

On the WCS, the excluded clients are displayed under the Security sub tab.

Here are the steps to follow in order to complete the integration of Cisco IPS Sensors and Cisco WLCs.

1. Install and connect the IDS appliance on the same switch where the wireless controller resides.

2. Mirror (SPAN) the WLC ports that carry the wireless client traffic to the IDS appliance.

3. The IDS appliance receives a copy of every packet and inspects traffic at Layer 3 through 7.

4. The IDS appliance offers a downloadable signature file, which can also be customized.

5. The IDS appliance generates the alarm with an event action of shun when an attack signature is detected.

6. The WLC polls the IDS for alarms.

7. When an alarm with the IP address of a wireless client, which is associated to the WLC, is detected, it puts the client into the exclusion list.

8. A trap is generated by the WLC and WCS is notified.

9. The user is removed from the exclusion list after the specified time period.

Network Architecture Design

The Cisco WLC is connected to the gigabit interfaces on the Catalyst 6500. Create a port-channel for the gigabit interfaces and enable Link Aggregation (LAG) on the WLC.

(Cisco Controller) >show interface summary 

Interface Name                    Port  Vlan Id   IP Address       Type     Ap Mgr
--------------------------------  ----  --------  ---------------  -------  ------
ap-manager                        LAG   untagged  10.10.99.3       Static   Yes   
management                        LAG   untagged  10.10.99.2       Static   No    
service-port                      N/A   N/A       192.168.1.1      Static   No    
virtual                           N/A   N/A       1.1.1.1          Static   No    
vlan101                           LAG   101       10.10.101.5      Dynamic  No    

The controller is connected to interface gigabit 5/1 and gigabit 5/2 on the Catalyst 6500.

cat6506#show run interface gigabit 5/1
Building configuration...

Current configuration : 183 bytes
!
interface GigabitEthernet5/1
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 99
 switchport mode trunk
 no ip address
 channel-group 99 mode on
end

cat6506#show run interface gigabit 5/2
Building configuration...

Current configuration : 183 bytes
!
interface GigabitEthernet5/2
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 99
 switchport mode trunk
 no ip address
 channel-group 99 mode on
end

cat6506#show run interface port-channel 99
Building configuration...

Current configuration : 153 bytes
!
interface Port-channel99
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk native vlan 99
 switchport mode trunk
 no ip address
end

The sensing interfaces of the IPS Sensor can operate individually in Promiscuous mode or you can pair them to create inline interfaces for Inline Sensing mode.

In Promiscuous mode, packets do not flow through the Sensor. The Sensor analyzes a copy of the monitored traffic rather than the actual forwarded packet. The advantage of operating in Promiscuous mode is that the Sensor does not affect the packet flow with the forwarded traffic.

Note: The architecture diagram is just an example setup of WLC and IPS integrated architecture. The example configuration shown here explains the IDS sensing interface acting in Promiscuous mode. The architecture diagram shows the sensing interfaces being paired together to act in Inline Pair mode. Refer to Inline Mode for more information about Inline Interface mode.

In this configuration, it is assumed that the sensing interface acts in Promiscuous mode. The monitoring interface of the Cisco IDS Sensor is connected to the gigabit interface 5/3 on the Catalyst 6500. Create a monitor session on the Catalyst 6500 where the port-channel interface is the source of the packets and the destination is the gigabit interface where the monitoring interface of the Cisco IPS Sensor is connected. This replicates all ingress and egress traffic from the controller wired interfaces to the IDS for Layer 3 through Layer 7 inspection.

cat6506#show run | inc monitor
monitor session 5 source interface Po99
monitor session 5 destination interface Gi5/3

cat6506#show monitor session 5  
Session 5
---------
Type                   : Local Session
Source Ports           : 
    Both               : Po99
Destination Ports      : Gi5/3
cat6506#

Configure the Cisco IDS Sensor

The initial configuration of the Cisco IDS Sensor is done from the console port or by connecting a monitor and keyboard to the Sensor.

1. Log in to the appliance:

   1. Connect a console port to the Sensor.

   2. Connect a monitor and a keyboard to the Sensor.

2. Type your username and password at the login prompt.

   Note: The default username and password are both cisco. You are prompted to change them the first time you log in to the appliance. You must first enter the UNIX password, which is cisco. Then you must enter the new password twice.

   login: cisco
   Password: 
   ***NOTICE***
   This product contains cryptographic features and is subject to 
   United States and local country laws governing import, export, 
   transfer and use. Delivery of Cisco cryptographic products does 
   not imply third-party authority to import, export, distribute or 
   use encryption. importers, exporters, distributors and users are 
   responsible for compliance with U.S. and local country laws. 
   By using this product you agree to comply with applicable laws 
   and regulations. If you are unable to comply with U.S. and local laws, 
   return this product immediately.
   
   A summary of U.S. laws governing Cisco cryptographic products may 
   be found at:
   
   http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
   
   If you require further assistance please contact us by sending 
   email to export@cisco.com.
   ***LICENSE NOTICE***
   There is no license key installed on the system.
   Please go to https://tools.cisco.com/SWIFT/Licensing/PrivateRegistrationServlet
              (registered customers only)
           
   to obtain a new license or install a license.

3. Configure the IP address, subnet mask and access list on the Sensor.

   Note: This is the command and control interface on the IDS used to communicate with the controller. This address should be routable to the controller management interface. The sensing interfaces do not require addressing. The access list should include the controller(s) management interface address, as well as allowable addresses for management of the IDS.

   sensor#configure terminal
   sensor(config)#service host 
   sensor(config-hos)#network-settings 
   sensor(config-hos-net)#host-ip 192.168.5.2/24,192.168.5.1
   sensor(config-hos-net)#access-list 10.0.0.0/8
   sensor(config-hos-net)#access-list 40.0.0.0/8
   sensor(config-hos-net)#telnet-option enabled 
   sensor(config-hos-net)#exit
   sensor(config-hos)#exit
   Apply Changes:?[yes]: yes
   sensor(config)#exit
   sensor# 
   sensor#ping 192.168.5.1
   PING 192.168.5.1 (192.168.5.1): 56 data bytes
   64 bytes from 192.168.5.1: icmp_seq=0 ttl=255 time=0.3 ms
   64 bytes from 192.168.5.1: icmp_seq=1 ttl=255 time=0.9 ms
   64 bytes from 192.168.5.1: icmp_seq=2 ttl=255 time=0.3 ms
   64 bytes from 192.168.5.1: icmp_seq=3 ttl=255 time=1.0 ms
   --- 192.168.5.1 ping statistics ---
   4 packets transmitted, 4 packets received, 0% packet loss
   round-trip min/avg/max = 0.3/0.6/1.0 ms
   sensor# 

4. You can now configure the IPS Sensor from the GUI. Point the browser to the management IP address of the Sensor. This image displays a sample where the Sensor is configured with 192.168.5.2..

   

5. Add a user that the WLC uses to access the IPS Sensor events.

   

6. Enable the monitoring interfaces.

   

   The monitoring interfaces must be added to the Analysis Engine, as this window shows:

   

7. Select the 2004 signature (ICMP Echo Request) in order to perform a quick setup verification.

   

   The signature should be enabled, Alert Severity set to High and Event Action set to Produce Alert and Request Block Host for this verification step to be completed.

   

Configure the WLC

Complete these steps in order to configure the WLC:

1. Once the IPS appliance is configured and ready to be added in the controller, choose Security > CIDS > Sensors > New.

2. Add the IP address, TCP port number, username and password you previously created.

   In order to obtain the fingerprint from the IPS Sensor, execute this command in the IPS Sensor and add the SHA1 fingerprint on the WLC (without the colon). This is used to secure the controller-to-IDS polling communication.

   sensor#show tls fingerprint 
   MD5: 1A:C4:FE:84:15:78:B7:17:48:74:97:EE:7E:E4:2F:19
   SHA1: 16:62:E9:96:36:2A:9A:1E:F0:8B:99:A7:C1:64:5F:5C:B5:6A:88:42

   

3. Check the status of the connection between the IPS Sensor and the WLC.

   

4. Once you establish the connectivity with the Cisco IPS Sensor, make sure the WLAN configuration is correct and that you enable Client Exclusion.

   The default client exclusion timeout value is 60 seconds. Also note that regardless of the client exclusion timer, the client exclusion persists as long as the client block invoked by the IDS remains active. The default block time in the IDS is 30 minutes.

   

5. You can trigger an event in the Cisco IPS system either when you do an NMAP Scan to certain devices in the network or when you do a ping to some hosts monitored by the Cisco IPS Sensor. Once an alarm is triggered in the Cisco IPS, go to Monitoring and Active Host Blocks in order to check the details about the host.

   

   The Shunned Clients list in the controller is now populated with the IP and MAC address of the host.

   

   The user is added to the Client Exclusion list.

   

   A trap log is generated as a client is added to the shun list.

   

   A message log is also generated for the event.

   

   Some additional events are generated in the Cisco IPS Sensor when an NMAP scan is done on a device it monitors.

   

   This window shows events generated in the Cisco IPS Sensor.

   

Cisco IDS Sensor Sample Configuration

This is the output from the setup script from the installation:

sensor#show config
! ------------------------------  
! Version 5.0(2)
! Current configuration last modified Mon Apr 03 15:32:07 2006
! ------------------------------
service host
network-settings
host-ip 192.168.5.2/25,192.168.5.1
host-name sensor
telnet-option enabled
access-list 10.0.0.0/8 
access-list 40.0.0.0/8
exit
time-zone-settings
offset 0
standard-time-zone-name UTC
exit
exit
! ------------------------------
service notification
exit
! ------------------------------
service signature-definition sig0
signatures 2000 0 
alert-severity high
status  
enabled true
exit
exit
signatures 2001 0 
alert-severity high
status
enabled true
exit
exit
signatures 2002 0 
alert-severity high
status
enabled true
exit
exit
signatures 2003 0 
alert-severity high
status
enabled true
exit
exit
signatures 2004 0 
alert-severity high
engine atomic-ip
event-action produce-alert|request-block-host
exit
status
enabled true
exit
exit
exit
! ------------------------------
service event-action-rules rules0
exit
! ------------------------------
service logger
exit
! ------------------------------
service network-access
exit
! ------------------------------
service authentication
exit
! ------------------------------
service web-server
exit
! ------------------------------
service ssh-known-hosts
exit
! ------------------------------
service analysis-engine
virtual-sensor vs0 
description default virtual sensor
physical-interface GigabitEthernet0/0 
exit
exit
! ------------------------------
service interface
physical-interfaces GigabitEthernet0/0 
admin-state enabled
exit
exit
! ------------------------------
service trusted-certificates
exit
sensor#  

Configure an ASA for IDS

Unlike a traditional Intrusion Detection Sensor, an ASA must always be in the data path. In other words, instead of spanning traffic from a switch port over to a passive sniffing port on the Sensor, the ASA must receive data on one interface, process it internally, and then forward it out another port. For IDS, use the modular policy framework (MPF) in order to copy traffic the ASA receives over to the internal Advanced Inspection and Prevention Security Services Module (AIP-SSM) for inspection.

In this example, the ASA used is already setup and passes traffic. These steps demonstrate how to create a policy that sends data to the AIP-SSM.

1. Log into the ASA using ASDM. Upon successful login, the ASA Main System window appears.

   

2. Click Configuration at the top of the page. The window switches to a view of the ASA interfaces.

   

3. Click Security Policy on the left-hand side of the window. On the resultant window, choose the Service Policy Rules tab.

   

4. Click Add in order to create a new policy. The Add Service Policy Rule Wizard launches in a new window.

   1. Click Interface and then choose the correct interface from the drop-down list in order to create a new policy which is bound to one of the interfaces that passes traffic.

   2. Give the policy a name and a description of what the policy does using the two text boxes.

   3. Click Next in order to move to the next step.

      

5. Build a new traffic class to apply to the policy.

   It is reasonable to build specific classes in order to inspect specific data types, but in this example, Any Traffic is selected for simplicity. Click Next in order to proceed.

   

6. Complete these steps in order to

   instruct the ASA to direct the traffic over to its AIP-SSM.

   1. Check Enable IPS for this traffic flow in order to enable intrusion detection.

   2. Set the mode to Promiscuous so that a copy of the traffic is sent to the module out-of-band instead of placing the module inline with the data flow.

   3. Click Permit traffic in order to ensure that the ASA switches to a fail-open state in the event that the AIP-SSM fails.

   4. Click Finish in order to commit the change.

      

7. The ASA is now configured to send traffic to the IPS module. Click Save on the top row in order to write the changes to the ASA.

   

Configure the AIP-SSM for Traffic Inspection

While the ASA sends data to the IPS module, associate the AIP-SSM interface to its virtual Sensor engine.

1. Login to the AIP-SSM using IDM.

   

2. Add a user with at least viewer privileges.

   

3. Enable the interface.

   

4. Check the Virtual Sensor configuration.

   

Configure a WLC to Poll the AIP-SSM for Client Blocks

Complete these steps once the Sensor is configured and ready to be added in the controller:

1. Choose Security > CIDS > Sensors > New in the WLC.

2. Add the IP address, TCP port number, username and password you created in the previous section.

3. In order to obtain the fingerprint from the Sensor, execute this command in the Sensor and add the SHA1 fingerprint on the WLC (without the colon). This is used to secure the controller-to-IDS polling communication.

   sensor#show tls fingerprint 
   MD5: 07:7F:E7:91:00:46:7F:BF:11:E2:63:68:E5:74:31:0E
   SHA1: 98:C9:96:9B:4E:FA:74:F8:52:80:92:BB:BC:48:3C:45:B4:87:6C:55

   

4. Check the status of the connection between the AIP-SSM and the WLC.

   

Add a Blocking Signature to the AIP-SSM

Add an inspection signature to block traffic. Although there are many signatures that can do the job based on the tools available, this example creates a signature that blocks ping packets.

1. Select the 2004 signature (ICMP Echo Request) in order to perform a quick setup verification.

   

2. Enable the signature, set the Alert Severity to High and set Event Action to Produce Alert and Request Block Host in order to complete this verification step. Note that the Request Block Host action is the key to signaling the WLC to create client exceptions.

   

   

3. Click OK in order to save the signature.

4. Verify that the signature is active and that it is set to perform a blocking action.

5. Click Apply in order to commit the signature to the module.

Monitor Blocking and Events with IDM

Complete these steps:

1. When the signature fires successfully, there are two places within IDM to note this.

   The first method shows the active blocks that the AIP-SSM has installed. Click Monitoring along the top row of actions. Within the list of items that appears on the left-hand side, select Active Host Blocks. Whenever the ping signature triggers, the Active Host Blocks window shows the IP address of the offender, the address of the device under attack, and the time that remains for which the block is in effect. The default blocking time is 30 minutes and is tunable. However, changing this value is not discussed in this document. Consult the ASA configuration documentation as necessary for information on how to change this parameter. Remove the block immediately, select it from the list and then click Delete.

   

   The second method to view triggered signatures uses the AIP-SSM event buffer. From the IDM Monitoring page, select Events in the items list on the left-hand side. The Events search utility appears. Set appropriate search criteria and click View....

   

2. The Event Viewer then appears with a list of events that match the criteria given. Scroll through the list and find the ICMP Echo Request signature modified in the previous configuration steps.

   Look in the Events column for the name of the signature, or else search for the identification number of the signature under the Sig ID column.

   

3. After you locate the signature, double-click the entry in order to open a new window. The new window contains detailed information on the event that triggered the signature.

   

Monitor Client Exclusion in a Wireless Controller

The Shunned Clients list in the controller is populated at this point of time with the IP and MAC address of the host.

The user is added to the Client Exclusion list.

Monitor Events in WCS

Security events that trigger a block within the AIP-SSM cause the controller to add the address of the offender to the client exclusion list. An event is also generated within WCS.

1. Use the Monitor > Alarms utility from the WCS main menu in order to view the exclusion event. WCS initially displays all uncleared alarms and also presents a searching function on the left-hand side of the window.

2. Modify the search criteria to find the client block. Under Severity, choose Minor, and also set the Alarm Category to Security.

3. Click Search.

   

4. The Alarm window then lists only security alarms with minor severity. Point the mouse at the event that triggered the block within the AIP-SSM.

   In particular, WCS shows the MAC address of the client station that caused the alarm. By pointing at the appropriate address, WCS pops-up a small window with the event details. Click the link in order to view these same details on another window.

   

Cisco ASA Sample Configuration

ciscoasa#show run
: Saved
:
ASA Version 7.1(2) 
!
hostname ciscoasa
domain-name cisco.com
enable password 2KFQnbNIdI.2KYOU encrypted
names
!
interface Ethernet0/0
 nameif outside
 security-level 0
 ip address 10.10.102.2 255.255.255.0 
!
interface Ethernet0/1
 nameif inside
 security-level 100
 ip address 172.16.26.2 255.255.255.0 
!
interface Ethernet0/2
 shutdown
 no nameif
 no security-level
 no ip address
!
interface Management0/0
 nameif management
 security-level 100
 ip address 192.168.1.1 255.255.255.0 
 management-only
!
passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
dns server-group DefaultDNS
 domain-name cisco.com
pager lines 24
logging asdm informational
mtu inside 1500
mtu management 1500
mtu outside 1500
asdm image disk0:/asdm512-k8.bin
no asdm history enable
arp timeout 14400
nat-control
global (outside) 102 interface
nat (inside) 102 172.16.26.0 255.255.255.0
nat (inside) 102 0.0.0.0 0.0.0.0
route inside 0.0.0.0 0.0.0.0 172.16.26.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
http server enable
http 10.1.1.12 255.255.255.255 inside
http 0.0.0.0 0.0.0.0 inside
http 192.168.1.0 255.255.255.0 management
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
telnet 0.0.0.0 0.0.0.0 inside
telnet timeout 5
ssh timeout 5
console timeout 0
dhcpd address 192.168.1.2-192.168.1.254 management
dhcpd lease 3600
dhcpd ping_timeout 50
dhcpd enable management
!
class-map inside-class
 match any
!
!
policy-map inside-policy
 description IDS-inside-policy
 class inside-class
  ips promiscuous fail-open
!
service-policy inside-policy interface inside
Cryptochecksum:699d110f988e006f6c5c907473939b29
: end
ciscoasa#

Cisco Intrusion Prevention System Sensor Sample Configuration

sensor#show config
! ------------------------------       
! Version 5.0(2)
! Current configuration last modified Tue Jul 25 12:15:19 2006
! ------------------------------
service host
network-settings
host-ip 172.16.26.10/24,172.16.26.1
telnet-option enabled
access-list 10.0.0.0/8 
access-list 40.0.0.0/8 
exit
exit
! ------------------------------
service notification
exit
! ------------------------------
service signature-definition sig0
signatures 2004 0 
engine atomic-ip
event-action produce-alert|request-block-host
exit
status
enabled true
exit
exit    
exit
! ------------------------------
service event-action-rules rules0
exit
! ------------------------------
service logger
exit
! ------------------------------
service network-access
exit
! ------------------------------
service authentication
exit
! ------------------------------
service web-server
exit
! ------------------------------
service ssh-known-hosts
exit
! ------------------------------
service analysis-engine
virtual-sensor vs0 
description default virtual sensor
physical-interface GigabitEthernet0/1 
exit
exit
! ------------------------------
service interface
exit
! ------------------------------
service trusted-certificates
exit
sensor#

Verify

There is currently no verification procedure available for this configuration.

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.

Related Information

• Installing and Using Cisco Intrusion Prevention System Device Manager 5.1
• Cisco ASA 5500 Series Adaptive Security Appliances - Configuration Guides
• Configuring the Cisco Intrusion Prevention System Sensor Using the Command Line Interface 5.0 - Configuring Interfaces
• WLC Configuration Guide 4.0
• Wireless Technical Support
• Wireless LAN Controller (WLC) FAQ
• Wireless LAN Controller and Lightweight Access Point Basic Configuration Example
• Configuring Security Solutions
• Technical Support & Documentation - Cisco Systems