Custom Search

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.

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

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

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

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

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

The WLC polls the IDS for alarms.

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.

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

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.

Log in to the appliance: 

Connect a console port to the Sensor.

Connect a monitor and a keyboard to the Sensor.

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 http://www.cisco.com/go/license
to obtain a new license or install a license.

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# 

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..