Identifying and Classifying Network Security Threats

Telemetry and Anomaly Detection

Anomaly detection systems passively monitor network traffic, looking for any deviation from "normal" or "baseline" behavior that may indicate a security threat or a misconfiguration. You can use several commercial tools and even open source tools to successfully identify security threats within your network. These tools include the following:

• Cisco NetFlow
• Cisco Security Monitoring, Analysis and Response System (CS-MARS)
• Cisco Traffic Anomaly Detectors and Cisco Guard DDoS Mitigation Appliances
• Cisco IPS sensors (Version 6.x and later)
• Cisco Network Analysis Module (NAM)
• Open Source Monitoring tools

The following are other technologies and tools you can use to achieve complete visibility of what is happening within your network:

• Syslog
• SNMP

NetFlow

Cisco NetFlow was initially introduced as a packet accounting system for network administration and, in some cases, for billing. However, today you can use NetFlow to listen to the network itself, thereby gaining valuable insight into the overall security state of the network. This is why it is classified as a form of telemetry that provides information about traffic passing through or directly to each router or switch.

NetFlow is supported in the following Cisco platforms:

• Cisco 1700
• Cisco 1800
• Cisco 2800
• Cisco 3800
• Cisco 4500
• Cisco 7200
• Cisco 7300
• Cisco 7500
• Cisco 7600/6500 (hybrid and native configurations)
• Cisco 10000
• Cisco 12000

The word netflow is a combination of net (or network) and flow. What is a flow? An individual flow comprises, at a minimum, the following elements:

• Source IP address.
• Destination IP address.
• Protocol.
• Source port number. (With certain protocols, this can be a type/code or any other construct—for example, ICMP.)
• Destination port number. (With certain protocols, this can be a type/code or any other construct—for example, ICMP.)

NetFlow also can give you information about network traffic. This information varies somewhat depending on what version of NetFlow Data Export (NDE) you run. The most commonly deployed versions are Versions 5 and 9. Following is some of the additional information you can obtain from a flow in NetFlow Version 5:

• Start time of the flow.
• End time of the flow.
• Number of packets in the flow.
• Amount of data transferred in the flow.
• Type of Service (ToS) bits present in the flow or Differentiated Services Code Point (DSCP) type.
• Logical OR of all TCP flags present in TCP-based flows (platform-specific caveats apply).
• Input interface ifIndex.
• Output interface ifIndex.
• Origin-AS or destination-AS information, if Border Gateway Protocol (BGP) is enabled on the routers/Layer 3 switches in question. (The selection of origin- or destination-AS reporting is made during the configuration of NetFlow on each device.)
• BGP next-hop information, if BGP is enabled on the routers/Layer 3 switches in question.
• Fragmentation information (known as fragmentation bit).

All this information can be exported to monitoring systems for further analysis. NetFlow Version 9 supports the same reporting capabilities as NetFlow Version 5 with some additional information. One of the biggest advantages of NetFlow Version 9 is its ability to be configured by the use of templates to use various features to export additional or different information to external systems. In NetFlow Version 5 and earlier, you can export the flow data over UDP. NetFlow Version 9 supports NDE via TCP and SCTP, as well as the classic UDP mode.

In NetFlow Version 9, you can use a template describing the NDE fields within the flow information. This template information is contained in the first NetFlow Version 9 NDE packets sent to the NDE destination (monitoring system) after NDE is enabled on the router or switch. This information is also periodically retransmitted. When the configuration of NDE fields is changed on the router or switch, the updated template is immediately transmitted.

The IETF Internet Protocol Flow Information eXport (IPFIX) working group (WG) has been tasked with developing a common standard for IP-based flow export. This working group has selected Cisco NetFlow Version 9 as the technology of choice.

It is recommended that you use an isolated out-of-band (OOB) management network to allow you to access and control NetFlow-enabled devices over the network, even when you are under attack or during any security incident or network malfunction. When you transmit network telemetry over the OOB network, you reduce the chance for disruption of the information that provides insightful network visibility.

Enabling NetFlow

Typically, enabling NetFlow on software-based platforms consists of one or two steps:

• Enabling NetFlow on the relevant physical and logical interfaces
• (Optional) Enabling the device (NDE) to export the flow information from the device to an external monitoring system

When you configure NetFlow, you must decide between ingress or egress NetFlow for each device. This decision depends on the use and the topology. You can also enable NetFlow for both ingress and egress.

The following example shows how you can enable ingress NetFlow on a particular interface (GigabitEthernet0/0 in this case):

myrouter#configure terminal
myrouter(config)#interface GigabitEthernet0/0
myrouter(config-if)#ip flow ingress

To enable egress NetFlow, use the ip flow egress interface subcommand as follows:

myrouter(config)#interface GigabitEthernet0/0
myrouter(config-if)#ip flow egress

The following example shows how to configure the NetFlow-enabled device to export the flow data to a monitoring system:

myrouter(config)#ip flow-export version 5
myrouter(config)#ip flow-export source loopback 0
myrouter(config)#ip flow-export destination 172.18.85.190 2055

In this example, NDE Version 5 is used. All NetFlow export packets are sourced from a loopback interface configured in the router (loopback 0). The destination is a Cisco Secure Monitoring and Response System (CS-MARS) box with the IP address 172.18.85.190 and the destination UDP port 2055.

It is recommended that you alter the setting of the active flow timeout parameter from its default of 30 minutes to the minimum value of one minute. This helps you achieve an environment that is closer to real time. You can do this with the ip flow-cache timeout active command, as shown here:

myrouter(config)#ip flow-cache timeout active 1

Collecting NetFlow Statistics from the CLI

To view the basic NetFlow information from the CLI, you can use the show ip cache flow command, as shown in Example 3-1:

Example 3-1. Output of the show ip cache flow Command

 myrouter#show ip cache flow
 IP packet size distribution (9257M total packets):
    1-32   64   96  128  160  192  224  256  288 320  352  384  416  448  480
    .088 .314 .011 .011 .027 .001 .007 .001 .013 .016 .002 .002 .000 .001 .000

     512  544  576 1024 1536 2048 2560 3072 3584 4096 4608
    .000 .001 .002 .043 .452 .000 .000 .000 .000 .000 .000

 IP Flow Switching Cache, 4456704 bytes
   43 active, 65493 inactive, 884110623 added
   3341579080 ager polls, 0 flow alloc failures
   Active flows timeout in 30 minutes
   Inactive flows timeout in 15 seconds
   last clearing of statistics never
 Protocol         Total    Flows   Packets Bytes  Packets Active(Sec) Idle(Sec)
 --------         Flows     /Sec     /Flow  /Pkt     /Sec     /Flow     /Flow
 TCP-Telnet     1072696      0.2        17   578      4.4       9.8      15.3
 TCP-FTP          33386      0.0      2392    57     18.6     697.2       7.6
 TCP-FTPD          2967      0.0      2869  1049      1.9       4.3      15.2
 TCP-WWW        9091735      2.1       222   904    470.3       6.0       5.6
 TCP-SMTP        538619      0.1         1    59      0.2       6.9      15.9
 TCP-X             3246      0.0        44   909      0.0       0.1      13.4
 TCP-BGP         280550      0.0         2    44      0.1       7.2      15.8
 TCP-NNTP          2306      0.0         1    46      0.0       0.0      18.1
 TCP-Frag             7      0.0        19   152      0.0       8.8      15.4
 TCP-other     48037166     11.1       115   887   1289.2       4.5       6.2
 UDP-DNS        1043579      0.2         2    74      0.4       3.9      15.9
 UDP-NTP         891663      0.2         1    79      0.2       0.0      15.5
 UDP-TFTP        138376      0.0         7    55      0.2      21.2      15.5
 UDP-Frag          9736      0.0       182  1366      0.4      22.1      15.4
 UDP-other    816395802    190.0         1   109    316.9       0.1      18.8
 ICMP           6533952      1.5        13    95     20.5       8.3      15.5
 GRE                239      0.0        41    97      0.0      66.9      15.2
 IP-other         34558      0.0      3907   156     31.4      66.1      15.0
 Total:       884110583    205.8        10   750   2155.4       0.5      17.9
 SrcIf         SrcIPaddress    DstIf         DstIPaddress    Pr SrcP DstP  Pkts
 Fa1/1         14.38.1.9       Null          255.255.255.255 11 0044 0043     1
 Fa1/1         0.0.0.0         Null          255.255.255.255 11 0044 0043   209
 Fa0/0         172.18.173.68   Fa1/0         14.36.1.208     06 05BC 01BB   452
 Fa0/0         172.18.173.68   Fa1/0         14.36.1.186     06 0631 01BB   388
 Fa1/0         14.36.1.120     Null          14.36.255.255   11 008A 008A     3
 Fa0/0         14.36.1.120     Null          14.36.255.255   11 008A 008A     3
 Fa0/0         172.18.124.223  Fa1/0         14.36.197.213   06 8107 2323  1547
 Fa0/0         172.18.124.66   Null          14.36.1.184     06 EC83 01BB     1
 Fa1/0         14.36.8.48      Fa0/0         172.18.124.154  06 15FE 0FA5     1
 Fa1/0         14.36.8.48      Fa0/0         172.18.124.154  06 15FF 0FA5     1
 Fa1/0         14.36.8.48      Fa0/0         172.18.124.154  06 15FD 0FA5     1
 Fa1/0         14.36.1.3       Fa0/0         172.18.123.69   01 0000 0303     3
 Fa1/0         14.36.8.36      Fa0/0         172.18.124.66   11 0202 0202     4
 Fa1/0         14.36.99.77     Fa0/0         172.18.124.225  06 01BB 137C    85
 Fa1/0         14.36.197.213   Fa0/0         172.18.124.223  06 2323 8107   780
 Fa0/0         172.18.124.223  Fa1/0         14.36.1.203     06 8105 2323  19992167
 Fa0/0         172.18.85.169   Local         14.36.1.1       06 8E5E 0017    97
 Fa0/0         172.18.124.225  Fa1/0         14.36.99.77     06 137C 01BB    85
 Fa0/0         172.18.124.128  Fa1/0         14.36.1.128     06 916E 2323   138
 Fa0/0         172.18.124.128  Fa1/0         14.36.1.128     06 916D 2323    54
 Fa1/0         14.36.1.208     Fa0/0         172.18.173.68   06 01BB 05BC   678

In the highlighted line, you can see that a host (172.18.124.223 is sending 19,992,167 packets to 14.36.1.203. This may be abnormal behavior or an infected machine. The protocol is 06 (TCP), the source port is 33029 (Hex 8105), and the destination port is 8995 (Hex 2323).

You can also obtain export flow information using the show ip flow export command, as shown in Example 3-2:

Example 3-2. Output of the show ip flow export Command

 myrouter#show ip flow export
 Flow export v5 is enabled for main cache
   Exporting flows to 172.18.85.190 (2055)
   Exporting using source IP address 172.18.124.47
   Version 5 flow records
   884111088 flows exported in 31352026 udp datagrams
   0 flows failed due to lack of export packet
   4 export packets were sent up to process level
   0 export packets were dropped due to no fib
   0 export packets were dropped due to adjacency issues
   0 export packets were dropped due to fragmentation failures
   0 export packets were dropped due to encapsulation fixup failures

In Example 3-2, you can see that the router is exporting the NetFlow information to the 172.18.85.190 device (a CS-MARS in this case) over UDP port 2055. The source IP address is 172.18.124.47. A total of 884,111,088 flows have been exported in 31,352,026 UDP datagrams. Please note that all protocol numbers, source ports, and TCP/UDP destination ports are shown in hexadecimal. ICMP packets are represented with the source port field set to 0000, the first two bytes of the destination field set to the ICMP type, and the second two bytes to the ICMP code. If you are using features such as policy-based routing (PBR), Web Cache Communications Protocol (WCCP), Network Address Translation (NAT), or Unicast Reverse Path Forwarding (uRPF) ACLs, you will see a (DstIf) value of Null. To see packet drops caused by ACLs, uRPF, PBR, or null routes, use the show ip cache flow with the include Null option, as shown in Example 3-3:

Example 3-3. Output of the show ip cache flow | include Null Command

 myrouter#show ip cache flow | include Null
 Fa1/0         14.36.1.8        Null         255.255.255.255 11 0044 0043    1
 Fa1/1         0.0.0.0          Null         255.255.255.255 11 0044 0043  891
 Fa0/0         172.18.124.66    Null         14.36.1.184     06 80AC 01BB    3
 Fa0/0         14.1.17.111      Null         14.38.201.1     06 51CD 00B3    2
 Fa1/0         172.18.124.11    Null         172.18.124.255  11 0089 0089   18
 Fa1/0         172.18.124.153   Null         172.18.124.255  11 008A 008A    3

To see flows that contain thousands or millions of packets, you can use show ip cache flow | include K or show ip cache flow | include M commands, respectively.

The Cisco Catalyst 6500 switches and Cisco 7600 router obtain NetFlow information via the Multilayer Switching (MLS) cache. In addition, the amount and type of data recorded in the table must be selected. The mls flow ip interface-full command provides the most useful information and can be configured as follows:

CAT6k(config)# mls flow ip interface-full
CAT6k(config)# mls nde interface

SYSLOG

System logs or SYSLOG provide you with information for monitoring and troubleshooting devices within your infrastructure. In addition, they give you excellent visibility into what is happening within your network. You can enable SYSLOG on network devices such as routers, switches, firewalls, VPN devices, and others. This section covers how to enable SYSLOG on routers, switches, the Cisco ASA, and Cisco PIX security appliances.

Enabling Logging (SYSLOG) on Cisco IOS Routers and Switches

The logging facility on Cisco IOS routers and switches allows you to save SYSLOG messages locally or to a remote host. By default, routers send logging messages to a logging process. The logging process controls the delivery of logging messages to various destinations, such as the logging buffer, terminal lines, a SYSLOG server, or a monitoring event correlation system such as CS-MARS. You can set the severity level of the messages to control the type of messages displayed, in addition to a time stamp to successfully track the reported information.

The following example shows the commands necessary to configure SYSLOG on Cisco IOS devices:

myrouter#configure terminal
myrouter(config)#logging on
myrouter(config)#logging host 172.18.85.190

In this example, the router is configured to send the SYSLOG messages to a host with IP address 172.18.85.190. (This is the CS-MARS used in the examples of the previous sections.)

On Cisco IOS routers, the log messages are not time-stamped by default. To enable time stamping of log messages, use the service timestamps log datetime command. The following example shows the different options of this command:

myrouter(config)#service timestamps log datetime ?
  localtime      Use local time zone for timestamps
  msec           Include milliseconds in timestamp
  show-timezone  Add time zone information to timestamp
  year           Include year in timestamp

You can specify the severity level of the SYSLOG messages. The following are the different levels you can configure:

• Level 0: Emergencies
• Level 1: Alerts
• Level 2: Critical
• Level 3: Errors
• Level 4: Warnings
• Level 5: Notifications
• Level 6: Informational
• Level 7: Debugging

To set the severity level of log messages sent to a SYSLOG server, use the logging trap command. The following example shows the options of this command:

 myrouter(config)#logging trap ?
   <0-7>          Logging severity level
   alerts         Immediate action needed           (severity=1)
   critical       Critical conditions               (severity=2)
   debugging      Debugging messages                (severity=7)
   emergencies    System is unusable                (severity=0)
   errors         Error conditions                  (severity=3)
   informational  Informational messages            (severity=6)
   notifications  Normal but significant conditions (severity=5)
   warnings       Warning conditions                (severity=4)

It is recommended that you send SYSLOG messages over a separate management segment, just as you learned to do earlier in this chapter in the "NetFlow" section.

Enabling Logging Cisco Catalyst Switches Running CATOS

To enable the logging of system messages to a SYSLOG server on Cisco Catalyst switches running Catalyst Operating System (CATOS), use the following commands:

   set logging server enable
   set logging server syslog server 172.18.85.190
   set logging timestamp enable
   set logging server severity 4

In this example, the switch is configured to send the SYSLOG messages to the host with IP address 172.18.85.190. Time stamp is enabled, and the severity level of the messages sent to the external server is set to 4 or warnings. Setting logging to the debugging level can cause performance problems. A good rule of thumb is to set the logging severity to 4 or warnings.

Enabling Logging on Cisco ASA and Cisco PIX Security Appliances

The commands used to enable logging and to send SYSLOG messages to a SYSLOG server are the same on the Cisco ASA and the Cisco PIX security appliances. To enable logging, use the logging on command. To configure the ASA or PIX to send logs to a SYSLOG server, use the logging host command, and to change the log severity level, use the logging trap command. The following example demonstrates the use of these commands.

ciscoasa(config)# logging on
ciscoasa(config)# logging host inside 172.18.85.190
ciscoasa(config)# logging trap informational

In this example, the Cisco ASA is configured to send its logs to the host with IP address 172.18.85.190, and the severity level is set to informational.

On the Cisco ASA and Cisco PIX security appliances, all SYSLOG messages begin with a percent sign (%) and are designed as follows:

%PIX|ASA  Level Message_number: Message_text

The following is an example of a SYSLOG message.

Apr 09 2007 07:35:56: %ASA-6-302021: Teardown ICMP connection for faddr
192.168.202.22/0 gaddr 192.168.202.40/0 laddr 192.168.202.40/0

• PIX|ASA: A static value indicating that the log message is generated by a Cisco ASA or Cisco PIX.
• Level: The severity level (1–7). For most environments, it is recommended that you set the severity level to 4 to avoid performance issues. You may want to temporally increase it to a higher value when troubleshooting a specific problem.
• Message number: A unique 6-digit number that identifies the SYSLOG message.
• Message text: The description of the log message. It sometimes includes IP addresses, port numbers, or usernames.

You can filter SYSLOG messages on the Cisco ASA, Cisco PIX, and Cisco FWSM to send only specific events to a particular output destination. In other words, you can configure the device to send all SYSLOG messages to one output destination and also to send a subset of those SYSLOG messages to a different output destination. You can also configure the Cisco ASA, Cisco PIX, and Cisco FWSM to send SYSLOG messages based on specific criteria, such as the following:

• Message ID number (range of 104024 to 105999)
• Severity level
• Message class

For example, you can use the logging class <message_class> command to specify the specific class.

SNMP

SNMP is one of the most basic forms of getting information from your network. It is a Layer 7 protocol designed to obtain information from network devices. This information includes but is not limited to the following:

• Device health statistics (CPU, memory, and so on)
• Device errors
• Network traffic statistics
• Packet rates
• Packet errors

The SNMP solution has three components:

• An SNMP manager: The system used to control and monitor the activities of network hosts using SNMP.
• An SNMP agent: The software component within the managed device that maintains the data for the device and reports this data, as needed, to managing systems.
• A Management Information Base (MIB): An information storage medium that contains a collection of managed objects (MIB modules) within each device. MIB modules are written in the SNMP MIB module language, as defined in STD 58, RFC 2578, RFC 2579, and RFC 2580.

In Chapter 2, you learned about the three versions of SNMP and the security implications of each version. That chapter also showed you how to protect SNMP environments. This section covers the basic commands on how to enable SNMP on Cisco IOS and the Cisco ASA and Cisco PIX security appliances.

Enabling SNMP on Cisco IOS Devices

As a best practice, you should set the system contact, location, and serial number of the SNMP agent so that your management servers can obtain these descriptions. This information is useful when responding to incidents. The following example shows how to enter the contact information on the Cisco IOS device:

myrouter#configure terminal
myrouter(config)#snmp-server contact John Route
myrouter(config)#snmp-server location 1st Floor NY Office
myrouter(config)#snmp-server chassis-id ABC12345

In the previous example, the name of the administrator is John Route, the device is located on the 1^st floor of an office in New York, and the chassis identification number is ABC12345.

The following example shows how you can configure SNMP Version 3 on a Cisco IOS device:

myrouter(config)#snmp-server group mygroup v3 auth

SNMP Version 3 supports authentication. In the previous example, an SNMP group named mygroup is configured for SNMP Version 3. Authentication is also enabled with the auth keyword. When you configure the snmp-server group command, there are no default values for authentication. To specify authentication user parameters, use the snmp-server user command, as shown in the following example:

myrouter(config)#snmp-server user admin1 mygroup v3 auth md5 zxasqw12
*Feb 8 15:45:04.902: Configuring snmpv3 USM user, persisting snmpEngineBoots.
Please Wait...

In the previous example, a user (admin1) is configured and mapped to the SNMP group mygroup. Authentication is done with MD5, and the password is zxasqw12. After you invoke this command, the preceding warning message is displayed. You should match all this information in your SNMP management server.

To verify the configuration, you can invoke the show snmp user command as follows:

myrouter#show snmp user
User name: admin1
Engine ID: 8000000903000013C4EC5528
storage-type: nonvolatile        active
Authentication Protocol: MD5
Privacy Protocol: DES
Group-name: mygroup

To view SNMP group information, invoke the show snmp group command, as shown in Example 3-4.

Example 3-4. Output of the show snmp group Command

 myrouter#show snmp group
 groupname: ILMI                             security model:v1
 readview : *ilmi                            writeview: *ilmi
 notifyview: <no notifyview specified>
 row status: active
 groupname: ILMI                             security model:v2c
 readview : *ilmi                            writeview: *ilmi
 notifyview: <no notifyview specified>
 row status: active
 groupname: mygroup                          security model:v3 auth
 readview : v1default                        writeview: <no writeview specified>
 notifyview: <no notifyview specified>
 row status: active

The configured group (mygroup) is shown in the highlighted line.

Enabling SNMP on Cisco ASA and Cisco PIX Security Appliances

The Cisco ASA and the Cisco PIX security appliances support only SNMP Versions 1 and 2c. They both support traps and SNMP read access; however, SNMP write access is not supported. The following example shows how to configure an ASA to receive SNMP Version 2c requests from host 172.18.85.190 on the inside interface:

ciscoasa(config)# snmp-server host inside 172.18.85.190 Version 2c
ciscoasa(config)# snmp-server location Raleigh NC Branch
ciscoasa(config)# snmp-server contact Jeff Firewall
ciscoasa(config)# snmp-server community th1s1sacommstrng

The ASA in this example is located in a branch office in Raleigh, North Carolina. The point of contact is Jeff Firewall, and the community string is <th1s1sacommstrng>. You can use the snmp deny version command to deny SNMP packets from other SNMP versions. The following example shows the available options:

ciscoasa(config)# snmp deny version ?
configure mode commands/options:
  1   SNMP version 1
  2   SNMP version 2 (party based)
  2c  SNMP version 2c (community based)
  3   SNMP version 3

Cisco Security Monitoring, Analysis and Response System (CS-MARS)

CS-MARS enables you to identify, classify, validate, and mitigate security threats. In the previous sections in this chapter, you learned different mechanisms that give you visibility of the network and its devices, such as NetFlow, SYSLOGs, and SNMP. The analysis and manipulation of the data provided by these features can be a time-consuming process and, in some environments, may even be impossible because of the staff requirements.

CS-MARS supports the correlation of events from numerous networking devices from different vendors. The supported devices include:

• Cisco IOS routers and switches
• Cisco ASA
• Cisco PIX
• NetFlow
• Cisco Security Agent
• Cisco Secure ACS
• Cisco IDS/IPS
• Third-party firewalls such as Checkpoint and Netscreen
• Third-party antivirus software
• Third-party IDS/IPS systems such as snort
• Operating system (Windows and UNIX/Linux) events
• Application-specific events

CS-MARS provides a powerful and interactive dashboard with several key items. It includes a topology map that comprises real-time hotspots, incidents, attack paths, and detailed investigation with full incident disclosure, allowing immediate verification of valid threats. Figure 3-7 shows the CS-MARS main dashboard.

Figure 3-7 CS-MARS Main Dashboard

Note that the system has processed more than 22,000,000 NetFlow events (or flows) over a period of 24 hours, and more than 44,000,000 security and network events. This automated process is accomplished by analyzing device logs such as firewalls and by using intrusion prevention applications, third-party vulnerability assessment data, and Cisco Security MARS endpoint scans to eliminate false positives. Users can quickly fine-tune the system to further reduce false positives. This will be impossible to successfully analyze without the use of a system such as CS-MARS.

Figure 3-8 shows the bottom part of the CS-MARS main dashboard. There you can see a topology map of devices within the network, an attack diagram, and event statistics and graphs.

Figure 3-8 CS-MARS Topology Map, Attack Diagram, and Event Statistics

You can view the topology map and attack diagram in full view, as shown in Figure 3-9. Obtaining information about the security incident is simple. If you click on any of the arrows representing the traffic flow, a new window displays with information about the specific incident or session.

Figure 3-9 CS-MARS Attack Diagram Full View

The hosts are color-coded:

• Brown means that the host is the attacker.
• Red means that the host is being attacked.
• Purple means that the host is being attacked and is attacking other hosts in the network.

CS-MARS can do a reverse DNS lookup to give you exact information on the specific hosts and devices. You can run numerous reports in CS-MARS. Figure 3-10 shows an example of reports and graphics you can obtain in CS-MARS.

Figure 3-10 CS-MARS Detailed Graphics and Reports

In Figure 3-10, you can see a summary of the most used ports and protocols within a given period. These graphics are based on NetFlow information. The graphic on the right shows the traffic trend. Notice that the traffic starts increasing during normal business hours of 8:00 a.m. to around 5:00 p.m. (0800 to 1700). These types of graphics can help you to create a baseline of what is normal within your network. Then you can identify anomalies and possible security incidents.

Cisco Network Analysis Module (NAM)

The Cisco Network Analysis Module (NAM) is designed to analyze and monitor traffic in the Catalyst 6500 series switches and Cisco 7600 series Internet routers. It uses remote monitoring (RMON), RMON extensions for switched networks (SMON), and SNMP MIBs to obtain information from the device. The NAM can also collect and analyze NetFlow information on remote devices.

To use the NAM to collect NetFlow data from a remote device, you must configure the remote device to export NDE packets to UDP port 3000 on the NAM. By default, the local supervisor engine of the switch is always available as an NDE device. Optionally, SNMP community strings are used to upload convenient textual strings for interfaces on the remote devices that are monitored in NetFlow records.

Open Source Monitoring Tools

You can use several open source monitoring tools in conjunction with NetFlow. If your organization is small, or if you do not have the budget for more sophisticated monitoring tools, you can take advantage of any of these open source tools that are freely available. Table 3-1 includes the most commonly used open source monitoring tools.

Table 3-1. Open Source Monitoring Tools

Most of these tools are designed to run in common *NIX-type operating systems, including Linux, FreeBSD, Mac OS/X, and Solaris. Some of these tools support the storage of data in databases such as MySQL and Oracle. Despite the fact that these open source tools are free, they are extremely useful for collecting NetFlow from routers and storing the raw flows for auditing and forensic purposes. The most commonly used tool is the OSU flow-tool, which is typically used in conjunction with other packages that provide detailed graphs, charts, and on-demand queries. Visit each of the websites listed in Table 3-1 to learn more about which tool is most suitable for your environment.

Cisco Traffic Anomaly Detectors and Cisco Guard DDoS Mitigation Appliances

The Cisco traffic anomaly detectors and DDoS mitigation appliances provide a new approach that not only detects increasingly complex and unrepresentative denial of service attacks but also mitigates their effect to ensure business continuity and resource availability. The Cisco DDos solution has two distinct appliances:

• Cisco Traffic Anomaly Detector (TAD) XT
• Cisco Guard XT

This solution is also available in the form of two individual modules for the Catalyst 6500 series switches and the Cisco 7600 Internet routers:

• Catalyst 6500/Cisco 7600 Router Anomaly Guard Module
• Catalyst 6500/Cisco 7600 Router Traffic Anomaly Detector Module

The detectors (whether the appliances or the modules) are designed to promiscuously monitor network traffic while looking for any variation from what is "normal," which may indicate a DDoS attack or a worm outbreak. The Cisco TAD XT alerts the Cisco Guard XT when it detects an anomaly by providing detailed reports and specific alerts.

This solution uses a Multiverification Process (MVP) architecture integrating different verification, analysis, and enforcement techniques. The MVP has five components:

• Static and dynamic DDoS filters
• Active verification (anti-spoofing) implementing source-authentication mechanisms that help ensure proper identification of legitimate traffic
• Anomaly recognition
• Protocol analysis designed to identify Layer 7 attacks, such as HTTP error attacks
• Rate limiting that prevents flows from overwhelming the target while more detailed monitoring is taking place

Figure 3-11 illustrates how the Cisco TAD XT and the Cisco Guard XT work.

Figure 3-11 Cisco TAD XT Detects an Anomaly and Updates the Guard XT

In Figure 3-11, two zones are protected by the Cisco TAD XT: a web server farm and an email server farm. The Cisco Guard is placed at the Internet edge, and the Cisco TAD XT resides a couple of hops in the inside of the corporate network. The following are the steps illustrated in Figure 3-11.

• Step 1 An attacker starts a DDoS from the Internet, and the Cisco TAD XT detects the anomaly (spike of traffic).
• Step 2 The Cisco TAD XT updates the Cisco Guard XT. The Cisco Guard XT can be triggered in several ways:
  • - Through direct use of the web-based device manager
  • - Via the CLI
  • - Through automatic use of the "protect by packet" feature (illustrated in this example)
• Step 3 After the Cisco Guard XT is activated, the Cisco Guard XT performs additional screening, and then the traffic destined to the zone under attack is diverted to the Cisco Guard XT in any of the following ways:
  • - The Cisco Guard XT can issue a BGP route update telling the router to divert the traffic to the Cisco Guard TX.
  • - If you are using the Catalyst 6500/7600 modules, the Route Health Injection (RHI) feature can trigger the packet diversion.
  • - A route is injected externally into the network.
• Step 4 The attack traffic is redirected to the Cisco Guard XT, and legitimate traffic is allowed to the protected zone, as illustrated in Figure 3-12.

Figure 3-12 Attack Traffic Redirected

The Cisco Guard can also be deployed with other anomaly detection systems. Examples of this include Arbor's Peakflow SP and Peakflow X. Arbor's Peakflow SP is designed for service providers, and Peakflow X is designed for enterprises. Typically, enterprises deploy the Cisco Guard XT at their Internet edge, or they co-locate it at their Internet service provider network to avoid the unnecessary traffic consuming their bandwidth. Because of this, numerous service providers offer managed network DDoS protection, hosting DDoS protection, peering point DDoS protection, and infrastructure protection services. This is based on a solution that Cisco makes available to service providers called "clean pipes."

Figure 3-13 illustrates the protection cycle that the Cisco Guard XT follows to analyze, filter, and rate-limit the traffic.

Figure 3-13 Cisco Guard XT Protection Cycle

When the traffic is redirected to the Cisco Guard XT, it first filters the traffic using several filtering techniques. If the Cisco Guard XT determines that the packets are malicious, it drops them at this stage. If the packets are not malicious, the packets are sent to different protection levels using several types of authentication methods. Subsequently, the Cisco Guard XT analyzes the traffic flow, drops the traffic that exceeds the defined rate that the zone can handle, and then injects the legitimate traffic back to the zone. A closed-loop feedback cycle dynamically adjusts its protection policies.