-
Cisco IOS Security Configuration Guide: Securing the Data Plane, Release 12.4T
-
Automatic Signature Extraction
-
Cisco IOS Firewall Overview
-
Access Control Lists (ACLs)
-
IP Access List Features Roadmap
-
IP Access List Overview
-
Creating an IP Access List and Applying It to an Interface
-
Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports, or TTL Values
-
ACL Syslog Correlation
-
Refining an IP Access List
-
Object Groups for ACLs
-
Displaying and Clearing IP Access List Data Using ACL Manageability
-
Controlling Access to a Virtual Terminal Line
-
Access List-Based RBSCP
-
ACL IP Options Selective Drop
-
ACL Authentication of Incoming rsh and rcp Requests
-
-
Configuring IP Session Filtering (Reflexive Access Lists)
-
Configuring Lock-and-Key Security (Dynamic Access Lists)
-
Context-Based Access Control
-
Configuring Context-based Access Control
-
Application Firewall - Instant Message Traffic Enforcement
-
Cisco IOS Firewall MIB
-
Cisco IOS Firewall Performance Improvements
-
Cisco IOS Firewall Stateful Failover
-
Cisco IOS Firewall Support for TRP
-
Email Inspection Engine
-
ESMTP Support for Cisco IOS Firewall
-
Firewall ACL Bypass
-
Firewall N2H2 Support
-
Firewall Stateful Inspection of ICMP
-
Firewall Support for SIP
-
Firewall Support of Skinny Client Control Protocol (SCCP)
-
Firewall Websense URL Filtering
-
Granular Protocol Inspection
-
HTTP Inspection Engine
-
Inspection of Router-Generated Traffic
-
TCP Out-of-Order Packet Support for Cisco IOS Firewall and Cisco IOS IPS
-
Transparent Cisco IOS Firewall
-
Virtual Fragmentation Reassembly
-
VRF Aware Cisco IOS Firewall
-
-
Zone-Based Policy Firewall
-
Zone-Based Policy Firewall
-
Cisco IOS Firewall H.323 Support
-
H.323 RAS Support in Cisco IOS Firewall
-
Cisco IOS Firewall: SIP Enhancements: ALG and AIC
-
Application Inspection and Control for SMTP
-
Subscription-based Cisco IOS Content Filtering
-
Cisco IOS Firewall Support for Skinny Local Traffic and CME
-
User Based Firewall Support
-
- Cisco IOS Intrusion Prevention System (IPS)
- Flexible Packet Matching
-
Configuring IP Security Options
-
Configuring Port to Application Mapping
-
Configuring TCP Intercept (Preventing Denial-of-Service Attacks)
- Unicast Reverse Path Forwarding (uRPF)
- Threat Information Distribution Protocol (TIDP) and TMS
-
Table Of Contents
TIDP Based Mitigation Services
Threat Information Distribution Protocol
TIDP Based Mitigation Services
Mitigation Enforcement Actions
TMS Rules Engine Configuration
Configuring the TMS Type Parameter Map on a Controller
Configuring a TMS Type Parameter Map on a Consumer
Configuring the TMS Type Class Map on a Controller or Consumer
Configuring the TMS Type Policy Map on a Controller or Consumer
Attaching the Service Policy to a Global TMS Controller Process
Configuring the TMS Controller Identifier
Attaching the Service Policy to a Global TMS Consumer Process
Registering and Deregistering a TMS Consumer
Configuring an XML Threat Definition File
Threat Definition File Syntax Guidelines
XML Threat Definition File Configuration Steps
Loading a Threat Definition File on a TMS Controller
Updating or Replacing a Loaded Threat
Sending Threat Information Messages from the Controller to a TMS Consumer
Synchronizing the Threat Status of a Consumer with the TMS Group
Managing Threat Information Messages on a Consumer from the Controller
Updating or Replacing a Loaded Threat
Sending a Status Request Message to Consumers from the TMS Controller
Unloading a Threat Information Messages from the Loaded Database
Configuring the TMS Rules Engine on a Consumer
Mitigation Type Service Policy
Configuring Local Device Exceptions on a Consumer
Clearing Threat Information Messages on a Consumer
Verifying TMS Configuration and Threat Status on a Controller or Consumer
Enabling TMS Debug Messages on a Controller or Consumer
Configuration Examples for TMS
Controller: TMS Configuration Example
Consumer: TMS Configuration Example
Consumer: TMS Rules Engine Configuration Example
TIDP Based Mitigation Services
First Published: February 27, 2006Last Updated: March 20, 2006Threat Information Distribution Protocol (TIDP) is the distribution layer protocol for TIDP Based Mitigation Services (TMS). TMS provides the framework to rapidly and efficiently distribute threat information to devices across the network. The TMS framework transports messages that contain specific threat information about suspect traffic and associated mitigation enforcement actions to all devices in the network. Threat Information Messages (TIMs) are distributed throughout the network in near real time. TIMs are distributed from a central device, the TMS controller. TMS consumers are devices configured to receive TIMs. Each consumer can be configured with a unique rule set to locally enforce mitigation actions based on local requirements. Local rule sets can be customized on demand.
Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for TMS" section
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Configuration Examples for TMS
Prerequisites for TMS
•
•
Restrictions for TMS
The following restrictions apply to TMS in Cisco IOS Release 12.4(6)T:
•
•
Information About TMS
You should understand the following concepts, before configuring TMS:
•
•
•
•
Threat Information Distribution Protocol
TIDP Based Mitigation Services (TMS) run over Threat Information Distribution Protocol (TIDP). TIDP is the distribution layer protocol that runs over of TCP (transport layer protocol). TIDP distributes Threat Information Messages (TIMs), for TMS, across the network in near real time.
Figure 1 shows TIDP distribution and transport.
Figure 1 TMS Service Run over TIDP
TIDP is designed to be a scalable and secure. TIDP supports point-to-point and point-to-multipoint communication. TIDP provides secure communication and message distribution. Message authentication is configured for all TIDP peering sessions. The message payload can be optionally encrypted to protect the contents. Authentication and encryption are configured using AES-128, HMAC-SHA1-160, or RSA key generation. TIDP is designed with replay protection (an attack that reuses old TCP sequence numbers to flood packets).
TIDP Based Mitigation Services
TMS provides the framework to rapidly and efficiently distribute Threat Information Messages (TIMs) to devices across the network. The network administrator distributes one or more TIMs from a central location, such as the network operations center (NOC). The TMS framework transports TIMs that contain specific threat information about suspect traffic and an associated mitigation enforcement actions to all devices in the network. Figure 2 shows TMS message distribution.
Figure 2 Threat Information Messages are Distributed over the TMS Framework
TMS provides a scalable point-to-point or point-to-multipoint framework. A TIM can be sent from the TMS controller to a single device (TMS consumer) or all devices in the network. Each TIM message is structured to identify suspect traffic and to enforce a mitigation action.
TMS is configured on a per group basis. A single device is configured as the TMS controller. The controller the is the central point in the network for TMS message distribution. The controller packages and distributes TIMs to TMS consumers. All other devices in the group are configured as consumers. A controller can support 250 TMS consumers in one or more TMS groups. Up to 64 TMS groups can be configured in a network.
The consumer is any device that is configured to receive and process TIMs and send status to the controller. The mitigation enforcement action is applied based on rules in the TIM. Each consumer can be optionally configured with a individual rule set (TMS Rules Engine) customized to fit local requirements.
Threat Information Messages
Each Threat Information Message (TIM) is identified by a threat ID, owner ID, and version number. The TIM is configured to identify suspect traffic. This traffic can be a single host IP address or entire major network range. The TIM is configured with a mitigation enforcement action that is associated with suspect traffic.
Each TIM is created in a threat definition file. The threat definition file is authored in a text or XML editor. The threat definition file must comply with Extensible Markup Language (XML) version 1.0 syntax. Each threat definition file can be up to 64 kb in size. A typical TIM is between 800 and a 1000 bytes. Each TMS group can support up to 256 active TIMs.
Figure 3 TIMs are Distributed from the TMS Controller
The threat definition file is loaded to the TMS controller from a local storage device, such as ATA or linear flash memory. The file can also be loaded from a reachable host (using FTP, HTTPS, RCP, or TFTP protocols). This action places the TIMs contained within the threat definition file into the "loaded" database. The TIMs are then distributed (sent) from the controller to TMS consumers by the network administrator. Sending a TIM activates and places the TIM in the active database.
TMS Protocol Configuration
TMS protocol operation, on the controller or consumer, is configured in a TMS type service policy using the Modular QoS CLI (MQC). The TMS type service policy is configured with TMS type class, parameter, and policy maps.
•
•
–
–
–
•
Tip
Mitigation Enforcement Actions
The mitigation enforcement action is defined globally in the TIM. It is associated with suspect traffic and conditionally enforced depending on the configuration of the TIM or the configuration rule on the TMS consumer (Custom rules are configured on TMS consumers in a mitigation type parameter map).
In a TIM, the enforcement action is configured as a block or redirect. The redirect rule can be configured to route null0 (blackhole) or route to a specific host IP address for collection and analysis or to host IP address configured as a sinkhole. The TIM can be also configured to use a mitigation enforcement action defined in a mitigation type parameter map on a TMS consumer.
Block Rule
The block mitigation enforcement action drops suspect traffic when suspect traffic meets all conditions of the rule. The behavior of this action is similar to a deny access list.
Redirect Rule
The redirect enforcement action is configured to route to null0 or to route to a specific host. Cisco IOS Optimized Edge Routing (OER) dynamically controls and implements redirect mitigation enforcement rules. Support for OER is automatically provided in Cisco IOS software images that support TMS. No explicit OER configuration is required. OER will function as if an OER master controller and border router processes has been configured on the TMS consumer.
Cisco IOS OER can also be explicitly configured on TMS consumers. However, the following caveats have been observed:
•
•
Figure 4 shows a typical example where sinkhole routing is used.
Figure 4 Typical OER Route to Sinkhole Example
The OER master controller process advertises the sinkhole router as the next hop for the 192.168.1.1 host, which is under attack.
TMS Rules Engine Configuration
The TMS Rules Engine is a flexible mechanism that allows you to apply custom rules on individual consumers. A TIM can be configured to take the next-hop variable from a rules engine configuration, or a custom rule can be configured to override a mitigation enforcement action sent in a TIM from the TMS controller.
Using the TMS Rules Engine, you can configure a local rule to route traffic to a null0, route traffic to a specific interface for collection and analysis, configure a nonstandard primitive, or configure the local device to ignore an enforcement action sent by the controller.
Note
The TMS Rules Engine is configured with a mitigation type service policy. The mitigation type service policy is created by configuring and linking mitigation type parameter and class maps to a mitigation type policy map.
•
•
•
•
The mitigation type service policy is activated by attaching the mitigation type policy-map to the TMS type policy map in policy-map class configuration mode. The TMS type policy map is then attached to the global consumer configuration by configuring the service-policy command in TMS Consumer configuration mode.
Local Device Exceptions
Local device exceptions are configured only on TMS consumers. A local device exception is an override configured for a specific host IP address or network. The TMS consumer negates a mitigation enforcement action sent from the controller or from a mitigation type service policy configured on the consumer.
For example, traffic from the 192.168.1.0/24 network is considered to be suspect. So, an ACL drop enforcement action is configured for all traffic sourced from this network. However, a device with a host address in this range (192.168.1.55) has to transit over a specific consumer. A local device exception is configured on the consumer to override ACL drop enforcement action.
TMS System Logging
TMS system logging is enabled in the TMS type parameter map configuration. It is disabled by default.
Controller System Logging Messages
This feature introduces the following system logging messages on the controller.
•
12:58:02: %TMS-6-GROUP: CONTROLLER| Group=1| Host=10.3.3.1| Status=CONFIGURED•
11:56:44: %TMS-6-DEVICE: CONTROLLER| Group=1| Host=10.3.3.2| Status=REGISTERED•
12:52:55: %TMS-6-DEVICE: CONTROLLER| Group=1| Host=10.3.3.2| Status=DEREGISTERED•
12:30:47: %TMS-6-RESET: CONTROLLER| Group=1| Device=10.3.3.2| Action=Delete| Start TID=1| End TID=112:30:47: %TMS-6-THREATSTATUS: CONTROLLER| Group=1| Device=10.3.3.2| Threat=1| Status=Threat deletedConsumer System Logging Messages
This feature introduces the following system logging messages on the consumer.
•
Feb 27 02:53:02.620: %TMS-6-GROUP: CONSUMER| Group=2| Host=10.3.3.2| Status=CONFIGURED•
*Feb 27 02:00:42.213: %TMS-6-DEVICE: CONSUMER| Group=1| Host=10.3.3.1| Status=REG Requested*Feb 27 02:00:42.241: %TMS-6-DEVICE: CONSUMER| Group=1| Host=10.3.3.1| Status=REGISTERED•
*Feb 27 02:34:40.417: %TMS-6-RESET: CONSUMER| Group=1| Device=10.3.3.1| Action=Delete| Start TID=1| End TID=1*Feb 27 02:34:40.425: %TMS-6-THREATSTATUS: CONSUMER| Group=1| Device=10.3.3.1| Threat=1| Status=Threat deleted•
*Feb 27 02:48:06.224: %TMS-6-THREAT: CONSUMER| Group=1| Device=10.3.3.1| TID=1*Feb 27 02:48:06.232: %TMS-6-THREATSTATUS: CONSUMER| Group=1| Device=10.3.3.1| Threat=1| Status=Redirect 192.168.2.1TMS syslog messages are processed by Cisco IOS software based on global logging configuration. To modify system, terminal, destination, and other system global logging parameters, use the logging commands in global configuration mode. For more information about global system logging configuration, see the chapter "Troubleshooting and Fault Management" section of the Cisco IOS Network Management Configuration Guide.
How to Configure TMS
This section contains the following tasks:
Configuring a TMS Type Service Policy
•
•
•
•
Attaching the TMS Type Service Policy to a Global TMS Process
•
•
Registering and Deregistering a TMS Consumer
•
Managing Threat Information Messages on a TMS Controller
•
•
•
•
•
•
•
Managing Threat Information Messages on a TMS Consumer
•
•
•
Verifying and Debugging TMS Configuration
•
•
Configuring the TMS Type Parameter Map on a Controller
The steps in this task show how to configure a TMS type parameter map on a controller. The TMS type parameter map is a container for TMS protocol-specific configuration parameters. A TMS type parameter map is configured on the controller and on each consumer. On the controller, the heartbeat (keepalive) and threat message timers are configured. Entering the parameter-map type tms command places the router in parameter-map configuration mode.
TMS Event Logging
The logging tms events command is entered in a TMS type parameter map on the consumer and/or controller. TMS system logging is disabled by default. TMS syslog messages are processed by Cisco IOS software based on global logging configuration. To modify system, terminal, destination, and other system global logging parameters, use the logging commands in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPS
Examples
The following example, starting in global configuration mode, configures a TMS type parameter map on a controller:
Router(config)# parameter-map type tms TMS_PAR_1Router(config-profile)# logging tms eventsRouter(config-profile)# heartbeat retry interval 60Router(config-profile)# heartbeat retry count 3Router(config-profile)# message retry interval 15Router(config-profile)# message retry count 5Router(config-profile)# exitWhat to Do Next
A TMS type parameter map must also be configured on each consumer. Proceed to the next section to see more information.
Configuring a TMS Type Parameter Map on a Consumer
The steps in this task show how to configure a TMS type parameter map on a consumer. A TMS type parameter map is configured on the controller and on each consumer. On the consumer, it is configured to identify the controller to and to set registration timers. Entering the parameter-map type tms command places the router in parameter-map configuration mode.
TMS Event Logging
The logging tms events command is entered in a TMS type parameter map on the consumer and/or controller. TMS system logging is disabled by default. TMS syslog messages are processed by Cisco IOS software based on global logging configuration. To modify system, terminal, destination, and other system global logging parameters, use the logging commands in global configuration mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Examples
The following example, starting in global configuration mode, configures a TMS type parameter map on a consumer:
Router(config)# parameter-map type tms TMS_PAR_2Router(config-profile)# controller ipv4 10.1.1.1Router(config-profile)# logging tms eventsRouter(config-profile)# registration retry count 5Router(config-profile)# registration retry interval 60Router(config-profile)# exitWhat to Do Next
The next step is to identify the TIDP group, over which TMS services are to be configured. Proceed to the next section to see more information.
Configuring the TMS Type Class Map on a Controller or Consumer
The steps in this task show how to configure a TMS type class map to define a TMS group as a class of traffic. A single TMS group or range of groups are configured with the match tidp-group command. This task is performed on the controller and on each consumer.
Prerequisites
TIDP is operational on the controller and all consumers.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Examples
The following example, starting in global configuration mode, configures groups 10 through 20 and group 30 as match criteria in the TMS_CLASS_1 class map:
Router(config)# class-map type tms TMS_CLASS_1Router(config-cmap)# match tidp group 10 - 20Router(config-cmap)# match tidp group 30Router(config-cmap)# exitWhat to Do Next
The next step is to attach the TMS type class and parameter maps to a TMS type policy map. Proceed to the next section to see more information.
Configuring the TMS Type Policy Map on a Controller or Consumer
The steps in this task show how to configure a TMS type policy map. The TMS policy map is configured to bind (attach) TMS type class and parameter maps. Any number of class maps, with different parameter maps, can be attached to the policy map. This task is performed on the controller and on each consumer.
Prerequisites
A TMS type class and parameter map is configured.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Examples
The following example, starting in global configuration mode, attaches TMS type class and parameter maps to a TMS type policy map:
Router(config)# parameter-map type tms TMS_PAR_1Router(config-profile)# logging tms eventsRouter(config-profile)# exitRouter(config)# class-map type tms TMS_CLASS_1Router(config-cmap)# match tidp-group 10Router(config-cmap)# exitRouter(config)# policy-map type control tms TMS_POL_1Router(config-pmap)# class TMS_CLASS_1Router(config-pmap-c)# mitigation TMS_PAR_1Router(config-pmap-c)# endWhat to Do Next
The next step is to attach the policy map to the global TMS controller or consumer process. Proceed to the next section to see more information.
Attaching the Service Policy to a Global TMS Controller Process
The TMS type service policy that was configured in the first three configuration tasks is attached to a global TMS controller process in this task.
Configuring the TMS Controller Identifier
The identifier command is configured to assign a unique ID number to a TMS controller. In Cisco IOS Release 12.4(6)T, only a single controller can be configured in each group. Identifier configuration is required only when multiple controllers are configured in a single TMS group.
Prerequisites
•
•
Restrictions
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Examples
The following example, starting in global configuration mode, configures a global TMS controller process, attaches a TMS type policy map:
Router(config)# tms controllerRouter(cfg-tms-ctrl)# service-policy type tms TMS_POL_1Router(cfg-tms-ctrl)# endTroubleshooting Tips
If the controller is unable to send threat messages to the consumer, perform the following steps:
1.
2.
3.
4.
What to Do Next
A TMS type policy map must also be attached to a global TMS consumer process. Proceed to the next section to see more information.
Attaching the Service Policy to a Global TMS Consumer Process
The TMS type service policy that was configured in the first three configuration tasks is attached to a global TMS consumer process in this task. Attaching the service policy activates a TMS consumer.
Consumer Registration
The TMS consumer must register with the TMS controller before the controller can send Threat Information Messages (TIMs). Implicit registration requests are automatically sent to the controller when a TMS type service policy is activated on the consumer.
By default, a TMS consumer sends a registration request message to the TMS controller once every 3 minutes for up to 3 times or until successfully registered. If the consumer is a member of multiple groups, it will send a separate registration request messages to the controller of each group.
Tip
Configuring Device Exceptions
The exception access-group command is configured to attach a local device exception to a TMS consumer process. A local device exception is an override configured on the TMS consumer that negates a enforcement action sent from the TMS controller or from a TMS Rules Engine configuration (mitigation type service policy) configured on the TMS consumer.
For example, traffic from the 192.168.1.0/24 network is considered to be suspect. So, an ACL drop mitigation enforcement action is configured for all traffic sourced from this network. However, a device with a host address in this range (192.168.1.55) needs to transit over a specific consumer. A local device exception is configured on the consumer to override ACL drop enforcement action.
The device exception is configured locally. A host IP address (or any other subset of the network) is defined in an extended access list and then referenced by the exception access-group command. The tms-class command is configured to associate an interface with the device exception. The enforcement action configured on the controller is not applied to traffic that is permitted by the access list.
Prerequisites
•
•
Restrictions
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Examples
The following example, starting in global configuration mode, configures a global TMS consumer process, attaches a TMS type policy map, and configures a device exception:
Router(config)# ip access-list extended NAMED_ACLRouter(config-ext-nacl)# permit tcp host 192.168.1.55 anyRouter(config-ext-nacl)# exitRouter(config)# interface Ethernet 0/0Router(config-if)# ip access-group NAMED_ACL inRouter(config-if)# tms-classRouter(config-if)# exitRouter(config)# tms consumerRouter(cfg-tms-cons)# exception access-group NAMED_ACLRouter(cfg-tms-cons)# service-policy type tms TMS_POL_1Router(cfg-tms-cons)# endTroubleshooting Tips
If the consumer does not receive threat messages from the controller, perform the following steps:
1.
2.
3.
4.
What to Do Next
A consumer must be registered with the controller to receive TIMs. Implicit registration occurs automatically when this task is completed. A consumer can be explicitly registered or deregistered at any time. Proceed to the next section to see more information.
Registering and Deregistering a TMS Consumer
This task is optional. The steps in this task shows how to register or deregister a consumer with a controller. All commands described in this section are entered in privileged EXEC mode.
Implicit Synchronization
Implicit synchronization (resync) messages are sent between the controller and consumer when the tms consumer register command is entered. Implicit synchronization ensures that the consumer has received all threats that have been configured its TMS group. Threats remain active until they are removed by the controller or until the consumer is deregistered.
Prerequisites
•
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Examples
The following example registers a TMS consumer with a TMS controller:
Router# tms consumer register group 10 controller ipv4 10.1.1.1The following example deregisters the 10.1.1.2 consumer from the controller:
Router# tms controller deregister group 10 consumer ipv4 10.1.1.2Troubleshooting Tips
If the consumer is unable to register with the controller, perform the following steps:
1.
2.
3.
What to Do Next
At completion of this task, the framework and services for distributing threat messages is complete and operational. Proceed to the next section to see information on configuring a threat definition file.
Configuring an XML Threat Definition File
The steps in this task show how to configure an XML threat definition file. The threat definition file is a container for Threat Information Messages (TIMs). The threat definition file first is configured in a text or XML editor. The threat definition file loaded to the TMS controller. TIMs are then distributed to TMS consumers.
XML Version 1.0 Syntax
The syntax of the threat definition file must comply with Extensible Markup Language (XML) version 1.0 syntax. For information about version 1.0 XML syntax, refer to the following document:
•
Threat Definition File Syntax Guidelines
The following list describes required and optional syntax for the threat definition file:
•
•
•
<?xml version="1.0" encoding="utf-8"?>
•
•
•
•
•
threat, threat_info, primitive and tcdf
•
condition and parameter
Threat File Tag Descriptions
This section describes required and optional XML tags.
threat (required)
The threat tag must follow the XML version tag. This tag has the following three required attributes:
threat_info (required)
The threat_info tag contains the Event Risk Rating (ERR) attribute. The ASR field in this tag is used to set the priority of the threat. The priority is configured with a number from 1 to 5. The priority implies no preference or hierarchy. It simply provides 5 levels of independent classification for threat messages.
Tip
Note
primitive (required)
The primitive tag contains the primitive attribute. The primitive attribute defines the mitigation enforcement action: block, redirect, or a nonstandard (user-defined) primitive. The nonstandard primitive is configured with any string value. Block and redirect are standard primitives. Any other value is interpreted as a nonstandard.
Tip
parameter (optional)
The parameter tag is a container for the next-hop variable of the mitigation enforcement action. The next-hop variable is defined in a nested redirect tag. The next hop is configured to route to a specific IPv4 host address or to the null0 interface (black hole).
The profile attribute is defined to configure the threat to take the next hop from a mitigation type parameter map configured on the consumer.
Tip
condition (optional)
The condition tag is used to define a conditional enforcement rule on an interface for a mitigation action. The mitigation action is enforced on the interface when any condition (first match) or all conditions (strict match) are met.
•
•
•
The device_class tag is configured with an attribute name that identifies the router or networking device.
Note
The sub_device_class tag is configured with an attribute name that identifies an interface. This tag is used to associate one or more threats with one or more interfaces.
Tip
The host_locate tag is configured with the ipv4_address attribute. This attribute is entered with a valid IP version 4 (IPv4) address to identify a specific host. This tag is used to associate a specific host with a threat.
Tip
tcdf (required)
The tcdf tag defines the traffic class for which the mitigation action that is enforced. This includes the classification match rule (strict or first) and the network (IP) and the transport (TCP or UDP) layer protocols that carry the traffic.
•
•
•
•
Note
•
•
ip.src_addr
ip.dst_addr
ip.proocol
tcp.src_port
tcp.dst_port
udp.src_port
udp.dst_port
•
•
Tip
XML Threat Definition File Configuration Steps
Steps 5, 6, and 7 contain branching tasks. Each branching task shows an alternate configuration that can be applied for the given step.
Step 1
<?xml version="1.0" encoding="utf-8"?>Step 2
<threat tid="1" owner="1000" version = "10"></threat>Step 3
<threat_info threat_name="NAME"threat_text="THREATTEXT"mitigation_text="mitigaationtext" ><err ASR="3" SFR="20" ARR="30" TFR="40" PD="50"></err><threat_class name="tc1"> </threat_class><threat_class name="tc2"> </threat_class></threat_info>Step 4
<primitive name="redirect"> </primitive>Step 5
<parameter><redirect nexthop="172.16.1.1"> </redirect></parameter>Or
(Optional) The next-hop variable is set to the null0 interface (0.0.0.0).
<parameter><redirect nexthop="0.0.0.0"> </redirect></parameter>Or
(Optional) The next-hop variable is determined by the configuration of the mitigation type parameter map configured on the TMS consumer (MIT_PAR_2).
<parameter profile="MIT_PAR_2"> </parameter>Step 6
<condition><match type="any"><match type="any"><host_locate ipv4_addr="10.2.2.2" > </host_locate><device_class name="Router" > </device_class></match><match type="any"><device_class name="Router" > </device_class><sub_dev_class name="Ingress_Ethernet" > </sub_dev_class></match></match></condition>Or
(Optional) A strict match conditional enforcement rule is configured. In this sample step, the mitigation action is enforced only when suspect traffic travels over an interface that is reachable from the 10.2.2.2 host and is tagged with the sub_device_class name (Ingress_Ethernet).
<condition><match type="all"><host_locate ipv4_addr="10.2.2.2" > </host_locate><device_class name="Router" > </device_class><sub_dev_class name="Ingress_Ethernet" > </sub_dev_class></match></condition>Step 7
<tcdf><class name="match-critera" type="access-control" match="all"><match><eq field="ip.src_addr" value="192.168.7.66" mask="255.255.255.255"> </eq><eq field="ip.dst_addr" value="10.3.3.3" mask="255.255.255.255"> </eq><eq field="ip.protocol" value="6"> </eq><range field=field="tcp.src_port" from="10" to="200"> </range><range field="tcp.dst_port" from="50"> </range></match></class></tcdf>Or
(Required) In this sample step, UDP is identified as the transport layer protocol.
<tcdf><class name="match-critera" type="access-control" match="all"><match><eq field="ip.src_addr" value="192.168.7.66" mask="255.255.255.255"> </eq><eq field="ip.dst_addr" value="10.3.3.3" mask="255.255.255.255"> </eq><eq field="ip.protocol" value="17"> </eq><range field=field="udp.src_port" from="1000" to="2000"> </range><range field="udp.dst_port" from="5000"> </range></match></class></tcdf>Or
(Required) In this sample step, no transport layer protocol is defined. Only source and destination IP addresses are configured to identify suspect traffic.
<tcdf><class name="match-critera" type="access-control" match="all"><match><eq field="ip.src_addr" value="192.168.7.66" mask="255.255.255.255"> </eq><eq field="ip.dst_addr" value="10.3.3.3" mask="255.255.255.255"> </eq></match></class></tcdf>
Tip
What to Do Next
The threat definition file must be loaded to the controller before threats contained in the threat definition file can be sent to consumers. Proceed to the next section to see information on loading and unloading threats.
Loading a Threat Definition File on a TMS Controller
This task shows how to load a threat definition file on a TMS controller. The tms controller load threat command is entered in privileged EXEC mode to load an XML threat definition file to the TMS controller from a local storage device, such as ATA or linear flash memory. The file can also be loaded from a reachable host (using FTP, HTTPS, RCP, or TFTP protocols).
Loaded and Active Databases
Two databases are maintained on the controller: the "loaded" database and the "active" database. The tms controller load threat command is used to upload a threat definition file on the controller. Once the threat definition file has been loaded, individual threats contained within the threat definition file are placed in the "loaded" database for distribution to consumers. Threats are removed from the loaded database by entering the tms controller unload command. Entering this command does not remove the threat from the active database if the threat is active on at least one consumer.
A threat is placed in the "active" database when the tms controller send command is used to send one or more threats to one or more consumers. A threat remains in the active database as long as it is active on at least one consumer. An active threat can be removed from consumers by entering the tms controller reset command on the controller. Active threats can be removed on the consumer by entering clear tms consumer or by reloading the consumer.
Updating or Replacing a Loaded Threat
Each threat that is contained within a threat definition file is uniquely identified by the threat ID, owner ID, and version number. The controller uses the version field to ensure that the most recent threat is sent to consumers. A higher version number indicates a more current or newer threat.
To replace or update an existing threat in the loaded database, a modified threat definition file must be loaded to the controller. The threat contained within this file must have a higher number in the version field. If the version field is the same or contains a lower number, the updated threat will not be loaded.
To distribute the updated threat to TMS consumers, the older version of the threat must be removed from the active database. The tms controller reset command can be entered with the delete keyword to remove the threat from all consumers.
Prerequisites
•
•
•
Restrictions
•
SUMMARY STEPS
1.
2.
DETAILED STEPS
Examples
The following example loads a threat definition file from local flash memory:
Router# tms controller load threat disk0: THREAT_FILEThe following example loads a threat definition file from a TFTP server:
Router# tms controller load threat tftp://172.16.1.1/THREAT_DEFINITION_FILETroubleshooting Tips
If there is a problem loading or unloading an XML threat definition file, the debug tms controller xml error command can be enabled to configure the router to print related error messages.
What to Do Next
The threat message is not activated until it is sent to TMS consumers. Proceed to the next section to see more information.
Sending Threat Information Messages from the Controller to a TMS Consumer
This task shows how to send a TIM to TMS consumers. A single threat, a range of threats, or all threats can be sent. The threat can be sent to a single group or all groups. The start time when the threat is activated and the duration of the threat are configurable. The tms controller send command is entered in privileged EXEC mode.
Prerequisites
•
•
SUMMARY STEPS
1.
2.
DETAILED STEPS
Examples
The following example sends threat ID 100 to all consumers in TIDP group 10. The threat will remain active for 1 hour.
Router# tms controller send group 10 owner 1000 tid 100 consumer all duration 3600Troubleshooting Tips
If the controller is unable to send threat messages to the consumer, perform the following steps:
1.
2.
3.
4.
What to Do Next
Proceed to the next section to see information about synchronizing the threat status on a consumer with other consumers in a TMS group.
Synchronizing the Threat Status of a Consumer with the TMS Group
This task is optional. This task shows how to synchronize the threat status on a consumer with the threat status on other consumers. This command is entered to ensure that the consumer has received all messages that have been sent to the TMS group. The tms consumer resync command is entered in privileged EXEC mode.
Implicit Synchronization
Implicit synchronization (resync) messages are sent between the controller and consumer when the tms consumer register command is entered. Implicit synchronization ensures that the consumer has received all threats that have been configured its TMS group. Threats remain active until they are removed by the controller or until the consumer is deregistered.
Prerequisites
•
•
SUMMARY STEPS
1.
2.
DETAILED STEPS
Examples
The following example synchronizes all threats from any owner that were sent to TIDP group 10.
Router# tms consumer resync group 10 owner any tid all controller ipv4 10.1.1.1Troubleshooting Tips
If you are unable to synchronize the consumer with the TMS group, perform the following steps:
1.
2.
3.
–
–
–
Tip
What to Do Next
Proceed to the next section to see information about updating and removing threats on a consumer.
Managing Threat Information Messages on a Consumer from the Controller
This task is optional. This task shows how to activate, deactivate and delete threat messages on one or all consumers. The tms controller reset command is entered in privileged EXEC mode.
Updating or Replacing a Loaded Threat
Each threat that is contained within a threat definition file is uniquely identified by the threat ID, owner ID, and version number. The controller uses the version field to ensure that the most recent threat is sent to consumers. A higher version number indicates a more current or newer threat.
To replace or update an existing threat in the loaded database, a modified threat definition file must be loaded to the controller. The threat contained within this file must have a higher number in the version field. If the version field is the same or contains a lower number, the updated threat will not be loaded.
To distribute the updated threat to TMS consumers, the older version of the threat must be removed from the active database. The tms controller reset command can be entered with the delete keyword to remove the threat from all consumers.
Prerequisites
•
•
SUMMARY STEPS
1.
2.
DETAILED STEPS
Examples
Threat Activation Example
The following example activates all threats on all consumers in all groups that belong to owner number 1000:
Router# tms controller reset activate group all owner 1000 tid all consumer allThreat Removal Example
The following example removes threats, 1 through 10, from the active database for all consumers in group 10:
Router# tms controller reset delete group 10 owner 1000 tid 1 - 10 consumer allThreat Deactivation Example
The following example deactivates threats, 1 through 10, from the active database for all consumers in group 10:
Router# tms controller reset inactivate group 10 owner 1000 tid 1 - 10 consumer allTroubleshooting Tips
If you are unable to manage threats on a consumer, perform the following steps:
1.
2.
3.
–
–
–
Tip
What to Do Next
Proceed to the next section to see information about sending a status request message to a consumer.
Sending a Status Request Message to Consumers from the TMS Controller
This task is optional. This task shows how to send a status request message from a controller to a consumer or group of consumers. The consumer must be registered to receive this message. In response, the consumer sends information about one or all threats to the controller. The tms controller status command is entered in privileged EXEC mode.
Prerequisites
•
•
SUMMARY STEPS
1.
2.
DETAILED STEPS
Examples
The following example sends a status request message for information about all threats from owner 1000:
Router# tms controller status group all owner 1000 tid all consumer allThe following example sends a status request message to the 10.1.1.2 consumer in group 10 for information threats, 1 through 10:
Router# tms controller status group 10 owner 1000 tid 1 - 10 consumer ipv4 10.1.1.2Troubleshooting Tips
If you are unable to send a status request message to a consumer, perform the following steps:
1.
2.
3.
–
–
–
Tip
What to Do Next
Proceed to the next section to see information about unloading threat messages from the loaded database.
Unloading a Threat Information Messages from the Loaded Database
This task is optional. This task shows how to unload a TIM from the "loaded" database. The tms controller unload command is entered on a TMS controller in privileged EXEC mode.
Loaded and Active Databases
Two databases are maintained on the controller: the "loaded" database and the "active" database. The tms controller load threat command is used to upload a threat definition file on the controller. Once the threat definition file has been loaded, individual threats contained within the threat definition file are placed in the "loaded" database for distribution to consumers. Threats are removed from the loaded database by entering the tms controller unload command. Entering this command does not remove the threat from the active database if the threat is active on at least one consumer.
A threat is placed in the "active" database when the tms controller send command is used to send one or more threats to one or more consumers. A threat remains in the active database as long as it is active on at least one consumer. An active threat can be removed from consumers by entering the tms controller reset command on the controller. Active threats can be removed on the consumer by entering clear tms consumer or by reloading the consumer.
Prerequisites
•
•
SUMMARY STEPS
1.
2.
DETAILED STEPS
Examples
The following example unloads threats, 1 through 10, from the loaded database on a TMS controller:
Router#_tms controller unload owner 1000 tid 1 - 10 threatTroubleshooting Tips
If there is a problem loading or unloading an XML threat definition file, enabling the debug tms controller xml error command will configured the router to print related error messages.
What to Do Next
At completion of this procedure, all configuration tasks that are performed on a controller are complete. The remain configuration tasks are performed on a consumer. Proceed to the next see information about configuring the TMS Rules Engine on a consumer.
Configuring the TMS Rules Engine on a Consumer
This task is optional. The steps in this task show how to configure the TMS Rules Engine. The TMS Rules Engine is configured using a mitigation type service policy.
The TMS Rules Engine is used to configure a mitigation enforcement action directly on a consumer to override an enforcement action sent from the controller. The following tasks are performed in this section:
•
•
•
•
Mitigation Type Service Policy
The mitigation type service policy is configured only on the consumer. It is used to customize or override mitigation enforcement actions sent by the controller. The TMS Rules Engine is used to configure an ACL drop, an ignore, or a redirect enforcement action. Only one action can configured for each mitigation type traffic class.
This type of service policy is created by configuring and linking mitigation type parameter and class maps to a mitigation type policy map. The class map is configured to define threat primitive and priority traffic matching conditions (as a class of traffic). The parameter map is configured to apply a next-hop variable to the class of traffic. The class and parameter maps are attached to a mitigation type policy map. The mitigation type service policy is activated by attaching the mitigation type policy map to a TMS type policy map, which is attached to the global TMS consumer process.
ACL Drop Rule
The ACL drop rule is configured to drop packets that are permitted by a predefined extended access-list. The ip access-group command is configured to attach the access list to the interface. The tms-class command is configured to associate the interface with the ACL drop enforcement action.
Ignore Rule
The ignore rule configures the TMS Rules Engine to ignore (not carry out any action for) a mitigation enforcement action defined for the matching traffic class. The traffic class is defined by the primitive and/or priority configured in a mitigation type class map.
Redirect Rule
The redirect rule is configured to redirect traffic to an explicitly defined IPv4 host, to a null interface or to an IPv4 host defined in a variable. The variable is initialized under the mitigation parameter-map using the variable command. If no destination is configured, the TMS Rules Engine will first check the threat information message (associated with the mitigation class map). If a destination cannot be derived from the threat information message, then the mitigation type parameter map is checked (if one is configured and attached to the mitigation type service policy).
If a next-hop IP address, null interface, or user-defined variable is not configured, the next hop variable must be defined in a mitigation type parameter map and then associated under the policy map with the source parameter command, or the parameter-map name must be specified in the profile attribute entered under the parameter tag in the threat definition file.
Prerequisites
•
•
Restrictions
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
DETAILED STEPS
Examples
ACL Drop Rule Example
The following example, starting in global configuration mode, configures an ACL drop enforcement action. Traffic that matches the extended access list (172.16.1/24) is dropped.
Router(config)# ip access-list extended 100Router(config-ipacl)# permit ip 172.16.1.0 0.0.0.255 anyRouter(config-ipacl)# exitRouter(config)# interface Ethernet 0/0Router(config-if)# ip access-group 100 inRouter(config-if)# tms-classRouter(config-if)# exitRouter(config)# class-map type mitigation match-all MIT_CLASS_1Router(config-cmap)# match priority 3Router(config-cmap)# match primitive blockRouter(config-cmap)# exitRouter(config)# policy-map type control mitigation MIT_POL_1Router(config-pmap)# class MIT_CLASS_1Router(config-pmap-c)# acl dropRouter(config-pmap-c)# endBlackhole (Redirect) Rule Example
The following example, starting in global configuration mode, configures the TMS Rules Engine to send priority 5 redirect threat mitigation traffic to a null interface (black hole):
Router(config)# parameter-map type mitigation MIT_PAR_2Router(config-profile)# variable RTBH NULL0Router(config-profile)# exitRouter(config)# class-map type mitigation match-all MIT_CLASS_2Router(config-cmap)# match priority 5Router(config-cmap)# match primitive redirectRouter(config-cmap)# exitRouter(config)# policy-map type control mitigation MIT_POL_2Router(config-pmap)# class MIT_CLASS_2Router(config-pmap-c)# source parameter MIT_PAR_2Router(config-pmap-c)# redirect route $RTBHRouter(config-pmap-c)# endCollection (Redirect) Rule Example
The following example, starting in global configuration mode, configures the TMS Rules Engine to set the next hop variable to 192.168.1.1 for traffic that matches the mitigation class (priority 1 traffic and any primitive):
Router(config)# class-map type mitigation MIT_CLASS_3Router(config-cmap)# match primitive anyRouter(config-cmap)# match priority 1Router(config-cmap)# exitRouter(config)# parameter-map type mitigation MIT_PAR_3Router(config-profile)# variable COLLECTION ipv4 192.168.1.1Router(config-profile)# exitRouter(config)# policy-map type control mitigation MIT_POL_3Router(config-pmap)# class MIT_CLASS_3Router(config-pmap-c)# source parameter MIT_PAR_3Router(config-pmap-c)# endIgnore Example
The following example, starting in global configuration mode, configures a TMS consumer to ignore a priority 5 redirect primitive:
Router(config)# parameter-map type mitigation MIT_PAR_4Router(config-profile)# variable RTBH NULL0Router(config-profile)# exitRouter(config)# class-map type mitigation match-all MIT_CLASS_4Router(config-cmap)# match priority 5Router(config-cmap)# match primitive redirectRouter(config-cmap)# exitRouter(config)# policy-map type control mitigation MIT_POL_4Router(config-pmap)# class MIT_CLASS_4Router(config-pmap-c)# source parameter MIT_PAR_4Router(config-pmap-c)# ignoreRouter(config-pmap-c)# endActivating the TMS Rules Engine Example (Complete Configuration)
The following example, starting in global configuration mode, creates a Rules Engine configuration and activates it under the global TMS consumer process:
Router(config)# class-map type mitigation MIT_CLASS_3Router(config-cmap)# match primitive blockRouter(config-cmap)# match priority 1Router(config-cmap)# exitRouter(config)# parameter-map type mitigation MIT_PAR_3Router(config-profile)# variable COLLECTION ipv4 192.168.1.1Router(config-profile)# exitRouter(config)# policy-map type control mitigation MIT_POL_3Router(config-pmap)# class MIT_CLASS_3Router(config-pmap-c)# redirect routeRouter(config-pmap-c)# source parameter MIT_PAR_3Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# policy-map type control tms TMS_POL_1Router(config-pmap)# class TMS_CLASS_1Router(config-pmap-c)# mitigation TMS_PAR_1Router(config-pmap-c)# service-policy MIT_POL_3Router(config-pmap-c)# exitRouter(config-pmap)# exitRouter(config)# tms consumerRouter(config-cons)# service-policy type tms TMS_POL_1Router(config-cons)# endTroubleshooting Tips
Troubleshooting Strict Match Mitigation Policies
The TMS Rules Engine provides a flexible mechanism to match TIMs on the TMS consumer. A match policy can be configured to match any (first) threat priority or primitive or to match all (strict).
Match all is the default when a mitigation type class map is configured without entering either optional keyword. This, as the name implies, is a strict match that requires all elements to match in order for the rule to be processed. Therefore, it is possible to configure a strict match that cannot function because it is impossible to match all elements. The following example illustrates this point:
class-map type mitigation MIT_CLASSmatch primitive blockmatch primitive redirectmatch priority 2match priority 3The above configuration uses a default match-all rule because no keyword is entered. The match-all rule invalidates the above configuration because no threat can satisfy all match criteria (block and redirect).
This configuration can be corrected by configuring the class map with the match-any keyword, as shown in the following configuration:
class-map type mitigation match-any MIT_CLASSmatch primitive blockmatch primitive redirectmatch priority 2match priority 3The above configuration could be configured with a match-all rule if either the block or redirect primitive is removed.
General TMS Rules Engine Troubleshooting
The Rules Engine configuration can be verified by entering the show tms consumer and show tms controller commands. If the enforcement action is not applied, you can enable the debug tms consumer feature-interface command to print error messages to help determine if the correct feature interface is called (ACL or OER).
What to Do Next
In this task, the TMS Rules Engine was configured to override a threat enforcement action on the consumer. Proceed to the next section to see information on excluding a device from TMS control.
Configuring Local Device Exceptions on a Consumer
This task is optional. The steps in this task show how to configure local device exceptions. Local device exceptions are configured on TMS consumers only. A local device exception is an override configured for a specific host IP address or network. The TMS consumer negates a mitigation enforcement action sent from the controller or from a mitigation type service policy configured on the consumer.
For example, traffic from the 192.168.1.0/24 network is considered to be suspect. So, an ACL drop enforcement action is configured for all traffic sourced from this network. However, a device with a host address in this range (192.168.1.55) needs to transit over a specific consumer. A local device exception is configured on the consumer to override ACL drop enforcement action.
A host IP address (or any other subset of the network) is defined in an extended access list and then referenced by the exception access-group command. The tms-class command is configured to associate an interface with the device exception. The enforcement action configured on the controller is not applied to traffic that is permitted by the access list.
Prerequisites
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DETAILED STEPS
Examples
The following example, starting in global configuration mode, configures an device exception for the 192.168.1.55 host address:
Router(config)# ip access-list extended NAMED_ACLRouter(config-ext-nacl)# permit tcp host 192.168.1.55 anyRouter(config-ext-nacl)# exitRouter(config)# interface Ethernet 0/0Router(config-if)# ip access-group NAMED_ACL inRouter(config-if)# tms-classRouter(config-if)# exitRouter(config)# tms consumerRouter(cfg-tms-cons)# exception access-group NAMED_ACLRouter(cfg-tms-cons)# service-policy type tms TMS_POL_1Router(cfg-tms-cons)# endTroubleshooting Tips
If the interface is operational and the device exception is properly configured, you can enable the debug tms consumer feature-interface command to print error messages to help determine if the correct feature interface is called (ACL or OER).
What to Do Next
At completion of this task, all procedures related to TMS configuration and management have been completed. Proceed to the following sections to see information about using TMS clear, show, and debug commands.
Clearing Threat Information Messages on a Consumer
This task is optional. This task shows how to clear threat information messages on a TMS consumer. The clear tms consumer group command is entered in privileged EXEC mode. Entering this command on a consumer has an effect similar to entering the tms controller reset command from the TMS controller.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Examples
The following example clears all threat information messages:
Router# clear tms consumer group all owner any tid allTroubleshooting Tips
The show tms controller and show tms consumer commands can be entered to verify that the clear command was successful.
What to Do Next
Proceed to the next section to see information on verifying TMS configuration.
Verifying TMS Configuration and Threat Status on a Controller or Consumer
This task is optional. This task shows how to verify TMS configuration on a controller or consumer using TMS show commands. All commands described in this section are entered in privileged EXEC mode.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Examples
show tms consumer example
The following example is sample output from the show tms consumer command:
Router# show tms consumerTMS Interface detailsInterface Edge SubDeviceClass--------- ---- --------------Fa0/0Fa0/1 EdgeTIDP-Group TMS-Controller-IP Status---------- ----------------- ------10 10.11.11.55 Registered Successfully20 10.11.11.55 Registered Successfullyshow tms consumer group examples
The following is sample output from the show tms consumer group command.
Router# show tms consumer group all owner any tid all verboseOwnerID TID Ver Group Controller Status ActionTaken------- --- --- ------ ----------- ------ ------------1 1 1 10 10.1.1.1 Active Redirect 172.16.1.11 2 1 10 10.1.1.1 Active Redirect NULL1 3 1 10 10.1.1.1 Inactive Threat Inactive2 10 1 10 10.1.1.1 Active ACL-Drop2 20 1 10 10.1.1.1 Active ACL-DropThe following example is sample output from the show tms consumer group command entered with the threats keyword:
Router# show tms consumer group 10 threatsTIDP Group 10Number of Threats : 13#sh tms controller group 10 threatsTIDP Group 10 ptr 656C4848Number of Threats : 1OwnerID TID Ver State------- --- --- -----1 10 1 Activeshow tms controller example
The following is sample output from the show tms controller command:
Router# show tms controllerTIDP-Group TMS-Consumer-IP Status---------- ----------------- ------10 10.3.3.2 Registered Successfully10 10.1.1.2 Registered Successfully20 10.3.3.2 Registered Successfully20 10.1.1.2 Registered Successfullyshow tms controller group example
The following is sample output from the show tms controller group command:
Router# show tms controller group 10TMS-Controller# show tms controller group all owner any tid all verboseOwnerID TID Ver Group Consumer Status ActionTaken-------- ---- ---- ------ --------- -------- --------------1 1 1 Load Active1 1 1 10 10.1.1.2 Active Redirect 172.16.1.11 2 1 Load Active1 2 1 10 10.1.1.2 Active Redirect NULL1 3 1 Load Active1 3 1 10 10.1.1.2 Inactive Threat Inactive2 10 1 Load Active2 10 1 10 10.1.1.2 Active ACL-Drop2 20 1 Load Active2 20 1 10 10.1.1.2 Active ACL-DropWhat to Do Next
Proceed to the next section to see information on enabling TMS debug messages.
Enabling TMS Debug Messages on a Controller or Consumer
This task shows how to enable TMS debugging on a controller or consumer. All commands described in this section are entered in privileged EXEC mode.
Restrictions
These commands should be used with caution on a production router or networking device. We recommend that debugging is enabled for only individual components as necessary. This restriction is intended to prevent the console session from be overwhelmed by large numbers of messages.
SUMMARY STEPS
1.
2.
3.
DETAILED STEPS
Examples
Consumer Event Debugging Example
The following is sample output from the debug tms consumer command entered with the events keyword:
Router# debug tms consumer eventsTMS consumer event debugging is on*Feb 27 21:27:18: TMS_EVE_CO:start timer Controller=10.1.1.1 period=180*Feb 27 21:27:18: TMS_EVE:Posting a message for the service layer*Feb 27 21:27:18: TMS_EVE_CO:Processing Reg messsage from ctrl=10.1.1.1 group=10*Feb 27 21:27:18: TMS_EVE_CO:Processing Reg response from ctrl=10.1.1.1 group=10*Feb 27 21:27:18: TMS_EVE_CO:start timer Controller=10.1.1.1 period=120Consumer Feature-Interface Debugging Example
The following is sample output from the debug tms consumer command entered with the feature-interface keyword:
Router# debug tms consumer feature-interfaceTMS consumer feature-interface debugging is on*Feb 27 21:28:12: TMS_FI_CO:OER:Policy Add client 2 pol id 12 tag 5000 nxthop 172.16.1.1*Feb 27 21:28:12: TMS_FI_CO:OERCB:ctx C type 2 values 0*Feb 27 21:28:12: TMS_FI_CO:OERCB:return code rcvd rc 1*Feb 27 21:28:12: TMS_FI_CO:OERCB:Threat (1, 1, 1) grpid 10 ctrlip 10.1.1.1 statflags 0 pol state 1*Feb 27 21:28:12: TMS_FI_CO:OERCB:Prefix create client 2 id 12 src 0.0.0.0 0.0.0.0 dst 192.168.8.0 255.255.255.0 proto 6 0 - 0, 10 - 2000 grant TRUE exact TRUE*Feb 27 21:28:12: TMS_FI_CO:OERCB:ctx C type 2 values 0*Feb 27 21:28:12: TMS_FI_CO:OERCB:return code rcvd rc 1*Feb 27 21:28:12: TMS_FI_CO:OERCB:Threat (1, 1, 1) grpid 10 ctrlip 10.1.1.1 statflags 0 pol state 3*Feb 27 21:28:12: TMS_FI_CO:OERCB:Prefix create success with rc = 1*Feb 27 21:28:13: TMS_FI_CO:ACL:CB3: acl 66886028 item 669C9F98 type 3 ADD*Feb 27 21:28:13: TMS_FI_CO:ACL:CB1: acl 66886028 modified.*Feb 27 21:28:13: TMS_FI_CO:ACL:CB3: acl 66886098 item 669CA0E0 type 3 ADD*Feb 27 21:28:13: TMS_FI_CO:ACL:CB1: acl 66886098 modified.Consumer Packet Debugging Example
The following is sample output from the debug tms consumer command entered with the packet keyword:
Router# debug tms consumer packetTMS consumer packets debugging is on*Feb 27 00:00:38: TMSCONS:out:Type(6)HeartBeat Req trans-id 15698 len 16*Feb 27 00:00:38: tms_flags 8 msg_flags 0 reason 0*Feb 27 00:00:38: TLVs:*Feb 27 00:00:38: TMSCONS:in:Type(6)HeartBeat Req trans-id 158 len 16*Feb 27 00:00:38: tms_flags 0 msg_flags 0 reason 0*Feb 27 00:00:38: TLVs:Consumer Protocol Debugging Example
The following is sample output from the debug tms consumer command entered with the protocol keyword:
Router# debug tms consumer protocolTMS consumer protocol debugging is on*Feb 27 21:27:18: TMS_PRO_CO:Sending RegReq ctrl=10.1.1.1 group=10*Feb 27 21:27:18: TMS_PRO_CO:RegResp recvd controller 10.1.1.1 group 10*Feb 27 21:27:18: TMS_PRO_CO:Sending Resync request for ctrl=10.1.1.1 group=10*Feb 27 21:27:18: TMS_PRO_CO:Resync response recvd controller 10.1.1.1, group 10*Feb 27 21:27:18: TMS_PRO_CO:Processing Resync response from Controller=10.1.1.1on Group=10*Feb 27 21:28:12: TMS_PRO_CO:Threat msg recvd controller 10.1.1.1, Group 10*Feb 27 21:28:12: TMS_PRO_CO:Processing Threat request from Controller=10.1.1.1on Group=10*Feb 27 21:28:12: TMS_PRO_CO:msg:NewThreat (1,1,1) in grp 10 ctrl 10.1.1.1*Feb 27 21:28:58: TMS_PRO_CO:Heartbeat msg recvd controller 10.1.1.1, Group 10Controller Event Debugging Example
The following is sample output from the debug tms controller command entered with the events keyword:
Router# debug tms controller eventsTMS controller events debugging is on*Feb 27 10:12:42: TMS_EVE_CN:Timer expired group=10*Feb 27 10:12:42: TMS_EVE_CN:Start timer: Group=10, period=120*Feb 27 10:12:42: TMS_EVE:Posting a message for the service layer*Feb 27 10:12:42: TMS_EVE_CN:Data packet recvd from DL layer*Feb 27 10:13:34: TMS_EVE:Posting a message for the service layer*Feb 27 10:13:34: TMS_EVE_CN:Data packet recvd from DL layer*Feb 27 10:13:34: TMS_EVE_CN:Start timer: Group=10, period=120*Feb 27 10:13:34: TMS_EVE:Posting a message for the service layer*Feb 27 10:13:34: TMS_EVE_CN:Data packet recvd from DL layerController Packet Debugging Example
The following is sample output from the debug tms controller command entered with the packet keyword:
Router# debug tms controller packetTMS controller packets debugging is onTMS controller packets debugging is on*Feb 27 10:13:34: TMSCTRL:in:Type(1)Registration Req trans-id 15685 len 16*Feb 27 10:13:34: tms_flags 8 msg_flags 1 reason 0*Feb 27 10:13:34: TLVs:*Feb 27 10:13:34: TMSCTRL:out:Type(1)Registration Resp trans-id 15685 len 16*Feb 27 10:13:34: tms_flags 1 msg_flags 1 reason 1*Feb 27 10:13:34: TLVs:*Feb 27 10:13:34: TMSCTRL:in:Type(4)Resync/Audit Req trans-id 15686 len 16*Feb 27 10:13:34: tms_flags 8 msg_flags 1 reason 0*Feb 27 10:13:34: TLVs:*Feb 27 10:13:34: TMSCTRL:out:Type(4)Resync/Audit Resp trans-id 15686 len 24*Feb 27 10:13:34: tms_flags 1 msg_flags 0 reason 0*Feb 27 10:13:34: TLVs: Summary(514,8)Controller Protocol Debugging Example
The following is sample output from the debug tms controller command entered with the protocol keyword:
Router# debug tms controller protocolTMS controller protocol debugging is on*Feb 27 10:13:34: TMS_PRO_CN:Registration request recvd consumer 10.1.1.2, group 10*Feb 27 10:13:34: TMS_PRO_CN:Sending Reg resp to cons=10.1.1.2 group=10*Feb 27 10:13:34: TMS_PRO_CN:Resync request recvd consumer 10.1.1.2, group 10*Feb 27 10:13:34: TMS_PRO_CN:Received Resync Req Group=10*Feb 27 10:13:34: TMS_PRO_CN:Sending Resync resp for cons=10.1.1.2 group=10 ntids=0XML Debugging Example
The following is sample output from the debug tms controller command entered with the xml keyword:
Router# debug tms controller xmlTMS controller xml debugs debugging is on*Feb 27 10:13:45: TMS_XML_CN:Found tag threat in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag threat_info in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag primitive in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag parameter in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag tcdf in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag threat in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag threat_info in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag parameter in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag primitive in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag tcdf in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag threat in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag threat_info in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag parameter in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag primitive in threat file*Feb 27 10:13:45: TMS_XML_CN:Found tag tcdf in threat file*Feb 27 10:13:45: TMS_XML_EVE:Decoding threat tag*Feb 27 10:13:45: TMS_XML_EVE:Found threat*Feb 27 10:13:45: TMS_XML_EVE:Decoded threat TLV - threat id : 1, owner id : 1, version : 1*Feb 27 10:13:45: TMS_XML_EVE:Decoding threat info*Feb 27 10:13:45: TMS_XML_EVE:Found threat info*Feb 27 10:13:45: TMS_XML_EVE:Found ERR*Feb 27 10:13:45: TMS_XML_EVE:name is name, value is tc2*Feb 27 10:13:45: Decoded Threat desc TLV:*Feb 27 10:13:45: Threat name = NAME:*Feb 27 10:13:45: Threat text = THREATTEXT:*Feb 27 10:13:45: Mitigation text = mitigationtext:*Feb 27 10:13:45: Threat classes : [ tc2 ]*Feb 27 10:13:45: ERR:*Feb 27 10:13:45: ASR = 5, SFR = 20, TFR = 40, ARR = 30 PD = 50*Feb 27 10:13:45: TMS_XML_EVE:Decoding primtive*Feb 27 10:13:45: TMS_XML_EVE:Found primtive*Feb 27 10:13:45: TMS-XML: Decoded primitive TLV*Feb 27 10:13:45: Prim type = 2*Feb 27 10:13:45: Primitive = redirect*Feb 27 10:13:45: TMS_XML_EVE:Decoding parameter*Feb 27 10:13:45: TMS_XML_EVE:CNS PARSER : Node is 129 tag = parameter*Feb 27 10:13:45: TMS_XML_EVE:Found parameter*Feb 27 10:13:45: TMS_XML_EVE:CNS PARSER : Node is 130 tag = redirect*Feb 27 10:13:45: TMS_XML_EVE:parameter : Found redirect*Feb 27 10:13:45: TMS_XML_EVE:Found nexthop in redirect*Feb 27 10:13:45: TMS_XML:Decoded Parameter TLV*Feb 27 10:13:45: Parameter type = 1*Feb 27 10:13:45: Redirect addr = 172.16.1.1*Feb 27 10:13:45: TMS_XML_EVE:Decoding match criteria*Feb 27 10:13:45: TMS-XML: Decoded match crt TLV :*Feb 27 10:13:45: Src addr : 0.0.0.0 , Src mask : 0.0.0.0*Feb 27 10:13:45: Dest addr : 192.168.8.0 , Dest mask : 255.255.255.0*Feb 27 10:13:45: Protocol : 6*Feb 27 10:13:45: Src port - Start : 0, End : 0*Feb 27 10:13:45: Dest port - Start : 10, End : 2000*Feb 27 10:13:45: TMS_EVE_CN:Threat (1,1,1) allocated.*Feb 27 10:13:45: TMS_EVE_CN:Threat (1,1,1) added to LoadDB.*Feb 27 10:13:45: TMS_XML_CN:Threat (1,1,1) Loaded into LoadDB*Feb 27 10:13:45: TMS_XML_EVE:Decoding threat tag*Feb 27 10:13:45: TMS_XML_EVE:Found threat*Feb 27 10:13:45: TMS_XML_EVE:Decoded threat TLV - threat id : 2, owner id : 1, version : 1What to Do Next
Proceed to the next section to see complete TMS configuration examples.
Configuration Examples for TMS
This section provides the following configuration examples:
•
•
•
Controller: TMS Configuration Example
The following example, starting in global configuration mode, configures a TMS type parameter map:
Router(config)# parameter-map type tms TMS_PAR_1Router(config-profile)# logging tms eventsRouter(config-profile)# heartbeat retry interval 60Router(config-profile)# heartbeat retry count 3Router(config-profile)# message retry interval 15Router(config-profile)# message retry count 5Router(config-profile)# exitTMS groups 10 through 20 and group 30 are configured as a TMS traffic class:
Router(config)# class-map type tms TMS_CLASS_1Router(config-cmap)# match tidp group 10 - 20Router(config-cmap)# match tidp group 30Router(config-cmap)# exitTMS type class and parameter maps are attached to a TMS type policy map:
Router(config)# policy-map type control tms TMS_POL_1Router(config-pmap)# class TMS_CLASS_1Router(config-pmap-c)# mitigation TMS_PAR_1Router(config-pmap-c)# endA global TMS controller process is created and a policy map (TMS type service policy) is attached:
Router(config)# tms controllerRouter(cfg-tms-ctrl)# service-policy type tms TMS_POL_1Router(cfg-tms-ctrl)# endConsumer: TMS Configuration Example
The following example, starting in global configuration mode, configures a TMS type parameter map:
Router(config)# parameter-map type tms TMS_PAR_2Router(config-profile)# controller ipv4 10.1.1.1Router(config-profile)# logging tms eventsRouter(config-profile)# registration retry count 5Router(config-profile)# registration retry interval 60Router(config-profile)# exitTMS groups 10 through 20 and group 30 are configured as a TMS traffic class:
Router(config)# class-map type tms TMS_CLASS_2Router(config-cmap)# match tidp group 10 - 20Router(config-cmap)# match tidp group 30Router(config-cmap)# exitTMS type class and parameter maps are attached to a TMS type policy map:
Router(config)# policy-map type control tms TMS_POL_2Router(config-pmap)# class TMS_CLASS_2Router(config-pmap-c)# mitigation TMS_PAR_2Router(config-pmap-c)# endA global TMS consumer process is created and a policy map (TMS type service policy) is attached. A local device exception is configured for the 192.168.1.55 host.
Router(config)# ip access-list extended NAMED_ACLRouter(config-ext-nacl)# permit tcp host 192.168.1.55 anyRouter(config-ext-nacl)# exitRouter(config)# interface Ethernet 0/0Router(config-if)# ip access-group NAMED_ACL inRouter(config-if)# tms-classRouter(config-if)# exitRouter(config)# tms consumerRouter(cfg-tms-cons)# exception access-group NAMED_ACLRouter(cfg-tms-cons)# service-policy type tms TMS_POL_2Router(cfg-tms-cons)# endConsumer: TMS Rules Engine Configuration Example
The following example, starting in global configuration mode, creates a TMS Rules Engine configuration and activates it under the global TMS consumer process.
The priority 1 block traffic is defined as a traffic class:
Router(config)# class-map type mitigation MIT_CLASS_3Router(config-cmap)# match primitive blockRouter(config-cmap)# match priority 1Router(config-cmap)# exitThe next-hop variable is defined in a mitigation type parameter map:
Router(config)# parameter-map type mitigation MIT_PAR_3Router(config-profile)# variable COLLECTION ipv4 192.168.1.1Router(config-profile)# exitThe mitigation type policy map is configured to bind the class and parameter maps. A redirect mitigation action is also configured in this policy map:
Router(config)# policy-map type control mitigation MIT_POL_3Router(config-pmap)# class MIT_CLASS_3Router(config-pmap-c)# redirect routeRouter(config-pmap-c)# source parameter MIT_PAR_3Router(config-pmap-c)# exitRouter(config-pmap)# exitThe mitigation service policy (TMS Rules Engine configuration) is attached to a TMS type policy map:
Router(config)# policy-map type control tms TMS_POL_2Router(config-pmap)# class TMS_CLASS_1Router(config-pmap-c)# mitigation TMS_PAR_2Router(config-pmap-c)# service-policy MIT_POL_3Router(config-pmap-c)# exitRouter(config-pmap)# exitThe TMS type policy map is attached to a global consumer process, activating the mitigation type service policy:
Router(config)# tms consumerRouter(config-cons)# service-policy type tms TMS_POL_2Router(config-cons)# endAdditional References
The following sections provide references related to TMS.
Related Documents
Standards
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
RFCs
No new or modified RFCs are supported by this feature, and support for existing standards has not been modified by this feature.
—
Technical Assistance
Command Reference
The following commands are introduced or modified in the feature or features
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
For information about these commands, see the Cisco IOS Security Command Reference at
http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_book.html.For information about all Cisco IOS commands, see the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or the Master Command List.
Feature Information for TMS
Table 1 lists the release history for this feature.
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Cisco IOS software images are specific to a Cisco IOS software release, a feature set, and a platform. Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Note
Table 1
Feature Information for TMS
CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0812R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2009 Cisco Systems, Inc. All rights reserved.
