Identifying the Effectiveness of Security Mitigations Using Cisco NX-OS


Contents

Introduction
Cisco NX-OS Routers and Switches
      Identifying the Effectiveness of Access Control Lists
      Identifying the Effectiveness of Access Control List Logging
      Identifying the Effectiveness of Unicast Reverse Path Forwarding
      Identifying the Effectiveness of IPv4 Traffic Flow Identification Using Cisco NX-OS NetFlow
      Identifying the Effectiveness of IPv6 Traffic Flow Identification Using Cisco NX-OS NetFlow
Conclusion
Additional Information
      Risk Management
      Resources




Introduction

Cisco NX-OS Software can provide effective means of exploit identification using the following:

  • Access Control List identification
  • Access Control List logging
  • Spoofing protection using Unicast Reverse Path Forwarding (uRPF)
  • Cisco NX-OS NetFlow

This document provides identification techniques administrators can deploy on Cisco NX-OS routers and switches to determine whether the mitigation methods described in an Applied Mitigation Bulletin (AMB) are having the desired effect. Readers of this document should note that the specific commands used in this document might differ from the commands they deploy on production devices.

Caution: The effectiveness of any mitigation technique depends on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. As with any configuration change, evaluate the impact of this configuration prior to applying the change.

Cisco NX-OS Routers and Switches

Identifying the Effectiveness of Access Control Lists

The following are examples of an access control list (ACL) used to block TELNET on TCP port 23TFTP on UDP port 69, and ICMP for both IPv4 and IPv6. This identification method should be used for both transit access-control lists (tACL) and infrastructure access-control lists (iACL)

After the administrator applies the ACL to an interface, the show ip access-lists and show ipv6 access-list commands will identify the number of IPv4 and IPv6 packets that have been filtered on interfaces on which the iACL is applied. Configure the statistics per-entry command so that access-list entry hit counts will be displayed. The user must change this ACL configuration to match the examples shown in the mitigation sections of the appropriate Applied Mitigation Bulletin. Administrators should investigate filtered packets to determine if they are attempts to exploit security vulnerabilities. Example output for show ip access-lists NX-OS-ACL-Policy and show ipv6 access-lists NX-OS-IPv6-ACL-Policy follows:

Nexus#show ip access-lists NX-OS-ACL-Policy
   statistics per-entry
   10 permit icmp 192.168.100.1/32  192.168.60.0/24 [match=101]
   20 permit tcp 192.168.100.1/32  192.168.60.0/24 eq telnet [match=65]
   30 permit udp 192.168.100.1/32  192.168.60.0/24 eq tftp [match=21]
   40 deny icmp any 192.168.60.0/24 [match=301]
   50 deny tcp any 192.168.60.0/24 eq telnet [match=256]
   60 deny udp any 192.168.60.0/24 eq tftp [match=200]
Nexus#

In the preceding example, access list NX-OS-ACL-Policy has dropped the following packets received from an untrusted host or network:

  • 301 ICMP packets for ACE line 40
  • 256 Telnet packets on TCP port 23 for ACE line 50
  • 200 TFTP packets on UDP port 69 for ACE line 60

router#show ipv6 access-lists NX-OS-IPv6-ACL-Policy 
IPv6 access list NX-OS-IPv6-ACL-Policy
   statistics per-entry
   10 permit icmp 2001:db8::100:1/128  2001:db8:1:60::/64 [match=47]
   20 permit tcp 2001:db8::100:1/128  2001:db8:1:60::/64 eq telnet [match=21]
   30 permit udp 2001:db8::100:1/128  2001:db8:1:60::/64 eq tftp [match=88]
   40 permit icmp any any nd-ns [match=98]
   50 permit icmp any any nd-na  [match=77]    
   60 deny icmp any 2001:db8:1:60::/64 [match=76]
   70 deny tcp any 2001:db8:1:60::/64 eq  telnet [match=61]
   80 deny udp any 2001:db8:1:60::/64 eq tftp [match=101]
   90 deny ipv6 any 2001:db8:1:60::/64 [match=45]

In the preceding example, access list NX-OS-IPv6-Policy has dropped the following packets received from an untrusted host or network:

  • 76 ICMP packets on ACE line 60
  • 61 Telnet packets on TCP port 23 for ACE line 70
  • 101 TFTP packets on UDP port 69 for ACE line 80

Identifying the Effectiveness of Access Control List Logging

The log keyword at the end of the access list entry will log packets that match a specific access control entry (ACE).

Required non-default changes for logging:

switch(config)# logging level acllog 3
switch(config)# acllog match-log-level 3
switch(config)# logging logfile [name] 3

In the preceding examples, the logging level for the acllog facility must be configured to be greater than or equal to the acllog match-log-level setting, and the "logging logfile" severity must be equal to or greater than that setting as well. Otherwise, the log messages do not appear in the logs. The value of 3 was chosen, but it is not a required setting. Use the show logging logfile command to view the access list entries in the log.

The Optimized ACL logging feature provides hardware-processing support for ACL logging to minimize the impact to the supervisor CPU. For additional information about the configuration and use of ACL logging, see Configuring IP ACLs.

Use the show logging command to inspect the log file. To display the last few lines, use the show logging last command. For additional information see, Cisco NX-OS show logging last command.

Nexus# show logging last 100
2014 Jan 23 17:52:36 Nexus %ACLLOG-3-ACLLOG_FLOW_INTERVAL: Source IP:  192.168.100.2, Destination IP: 192.168.60.2, 
Source Port: 0, Destination Port:  0, Source Interface: Ethernet5/47, Protocol: "ICMP"(1), Hit-count = 5
2014 Jan 23 17:53:06 Nexus  %ACLLOG-3-ACLLOG_FLOW_INTERVAL: Source IP: 192.168.100.2, Destination IP:  192.168.60.2, 
Source Port: 54300, Destination Port: 69, Source Interface:  Ethernet5/47, Protocol: "UDP"(17), Hit-count = 7
2014 Jan 23 17:53:36 Nexus  %ACLLOG-3-ACLLOG_FLOW_INTERVAL: Source IP: 192.168.100.2, Destination IP:  192.168.60.2, 
Source Port: 62966, Destination Port: 69, Source Interface: Ethernet5/47,  Protocol: "UDP"(17), Hit-count = 7
2014 Jan 23 17:54:06 Nexus  %ACLLOG-3-ACLLOG_FLOW_INTERVAL: Source IP: 192.168.100.2, Destination IP:  192.168.60.2, 
Source Port: 50765, Destination Port: 69, Source Interface:  Ethernet5/47, Protocol: "UDP"(17), Hit-count = 7
2014 Jan 23 17:54:36 Nexus  %ACLLOG-3-ACLLOG_FLOW_INTERVAL: Source IP: 192.168.100.2, Destination IP:  192.168.60.2, 
Source Port: 58465, Destination Port: 23, Source Interface: Ethernet5/47, Protocol: "TCP"(6), Hit-count = 4  

In the preceding example, traffic is denied for ICMPTFTP on UDP port 69, and Telnet on TCP port 23.

Identifying the Effectiveness of Unicast Reverse Path Forwarding

Some security vulnerabilities can be exploited by spoofed IP packets. Administrators can deploy and configure Unicast Reverse Path Forwarding (uRPF) as a protection mechanism against spoofing.

uRPF is configured at the interface level and can detect and drop packets that lack a verifiable source IP address. Administrators should not rely on uRPF to provide complete spoofing protection because spoofed packets may enter the network through a uRPF-enabled interface if an appropriate return route to the source IP address exists. Administrators are advised to take care to ensure that the appropriate uRPF mode (loose or strict) is configured during the deployment of this feature because it can drop legitimate traffic that is transiting the network. In an enterprise environment, uRPF may be enabled at the Internet edge and the internal access layer on the user-supporting Layer 3 interfaces.

For additional information about the configuration and use of uRPF, see the Understanding Unicast Reverse Path Forwarding white paper.

With uRPF properly deployed and configured throughout the network infrastructure, administrators can use the show hardware internal statistics module-all device l3lu errors command to show RPF drops per module. While the show ip traffic | include rpf command will identify the total number of packets that uRPF has dropped.

Note: The show command | include regex modifiers are used in the following examples to minimize the output administrators will need to parse to view the desired information. Additional information about command modifiers is in the Cisco NX-OS System Management Command Reference.

In the following example, uRPF has dropped 25 packets.

Nexus#show hardware internal statistics module-all device l3lu errors
   Hardware statistics on module 01:
   Hardware statistics on module 05:
    |------------------------------------------------------------------------|
    | Device:Lamira          Role:L3                      Mod: 5    |
    | Last cleared @ Thu Jan 23 20:37:51 2014 
    | Device Statistics Category :: PASS
    |------------------------------------------------------------------------|
   Instance:0
    ID    Name                                           Value              Ports
    --    ----                                           -----              -----
    95    CL2 RPF check Fail Pkt count                  0000000000000025   1-48 I1
    453   Exception cause: TWO MCAST RPF (Unicast)      0000000000000025   1-48 I1
Nexus#show ip traffic | include rpf
Bad  context id: 0, rpf drops: 25
Nexus#

Identifying the Effectiveness of IPv4 Traffic Flow Identification Using Cisco NX-OS NetFlow

Administrators can configure Cisco IOS NetFlow on Cisco NX-OS routers and switches to aid in the identification of IPv4 traffic flows that may be attempts to exploit security vulnerabilities. Administrators are advised to investigate flows to determine if they are attempts to exploit these vulnerabilities or whether they are legitimate traffic flows. The following output shows identification examples using NetFlow for several different TCP/UDP ports and protocols. For additional information, see NetFlow on Cisco Nexus 7000 Series Switches using NX-OS.

The default flow record contains many useful fields; however, custom flow records can be configured. The following is an example of the default flow record.

Nexus# show flow record netflow-original
   Flow record netflow-original:
   Description: Traditional IPv4 input NetFlow with origin ASs
   No. of users: 1
   Template ID: 256
   Fields:
   match ipv4 source address
   match ipv4 destination address
   match ip protocol
   match ip tos
   match transport source-port
   match transport destination-port
   match interface input
   match interface output
   match flow direction
   collect routing source as
   collect routing destination as
   collect routing next-hop address ipv4
   collect transport tcp flags
   collect counter bytes
   collect counter packets
   collect timestamp sys-uptime first
   collect timestamp sys-uptime last
Nexus#

Use the show hardware flow ip command to see flows:

Nexus# show hardware flow ip 
      IF  - Interface: ()ethernet, (S)vi, (V)lan, (P)ortchannel, (T)unnel
      D  IF         SrcAddr          DstAddr         L4 Info         PktCnt     TCPFlags
      I  S4         192.168.101.010  192.168.100.002 017:00080:60750 0000003841 ......
      I  S4         192.168.060.107  192.168.100.002 017:65840:00069 0000003841 ......
      I  S4         192.168.060.009  192.168.100.002 006:11000:00023 0000000010 A.P.S.
      I  S4         10.168.060.002   192.168.100.002 001:00000:02048 0000001567 ......
      I  S4         192.168.012.002  192.168.100.002 017:60750:00069 0000003841 ......
      I  S4         192.168.061.003  192.168.100.042 017:00022:10157 0000003841 ......
      I  S4         192.168.060.002  192.168.100.066 017:30123:00069 0000003841 ......
      I  S4         192.168.052.007  192.168.101.003 001:00000:02048 0000001567 ......
      I  S4         192.168.051.005  192.168.101.002 001:00000:02048 0000001567 ......
Nexus#

In the preceding example, there are multiple flows for Telnet on TCP port 23TFTP on UDP port 69, and ICMP.

Note: ICMP flows are represented in the output using the L4 info (001:00000:02048). The protcol number 1 field is the assigned by Internet Assigned Numbers Authority (IANA). The source and destination field represents the type of ICMP captured by NetFlow. In order to get the ICMP code type convert the decimal to hexidecimal. In this example, 2048 = 0800 which is type_8 code_0 (ICMP echo).

Administrators are advised to compare these flows to baseline utilization for TelnetTFTP, and ICMP and also investigate the flows to determine if they are sourced from untrusted hosts or networks. The following examples show how to view a specific type of traffic flow in NetFlow records. To view only Telnet flows on TCP port 23 use the show hardware flow ip | include IF|06.*(23) command. To view only UDP packets for TFTP on UDP port 69 use show hardware flow ip | include IF|06.*(23)|17.*(69). To view only ICMP flows use show hardware flow ip | include IF|001:00000:

TCP Flows

Nexus#show hardware flow ip |  include IF|06.*(23)
   IF  - Interface: ()ethernet, (S)vi, (V)lan, (P)ortchannel, (T)unnel
   D  IF         SrcAddr          DstAddr         L4 Info         PktCnt     TCPFlags
   I  S4         192.168.060.002  192.168.100.002 006:00023:60750 0000003841 ......
   I  S4         192.168.060.003  192.168.100.002 006:00023:60750 0000003841 ......
Nexus#

UDP Flows

Nexus#show hardware flow ip | include IF|17.*(69)
   IF  - Interface: ()ethernet, (S)vi, (V)lan, (P)ortchannel, (T)unnel
   D  IF         SrcAddr          DstAddr         L4 Info         PktCnt     TCPFlags
   I  S4         192.168.071.001  192.168.100.002 017:00069:60750 0000003841 ......
   I  S4         192.168.047.003  192.168.100.057 017:00069:50982 0000003841 ......
Nexus#

ICMP Flows

Nexus#show hardware flow ip | include IF|001:00000:
   IF  - Interface: ()ethernet, (S)vi, (V)lan, (P)ortchannel, (T)unnel
   D  IF         SrcAddr         DstAddr         L4 Info         PktCnt     TCPFlags
   I  S4         192.168.120.025 192.168.100.002 001:00000:02048 0000686495 ...... 
   I  S2         192.168.100.009 192.168.060.002 001:00000:00000 0000686494 ...... 
   I  S4         192.168.070.002 192.168.100.002 001:00000:02048 0000686495 ...... 
   I  S2         192.168.080.002 192.168.060.002 001:00000:00000 0000686494 ......
Nexus#

Identifying the Effectiveness of IPv6 Traffic Flow Identification Using Cisco NX-OS NetFlow

Administrators can configure Cisco NX-OS NetFlow on Cisco NX-OS routers and switches to aid in the identification of IPv6 traffic flows that may be attempts to exploit Security vulnerabilities. Administrators are advised to investigate flows to determine if they are attempts to exploit security vulnerabilities or whether they are legitimate traffic flows.

The following output is from a Cisco NX-OS device running the Cisco NX-OS Software 6.1 train. The command syntax will vary for different Cisco NX-OS Software trains.

Nexus# show hardware flow ip 
   IF  - Interface: ()ethernet, (S)vi, (V)lan, (P)ortchannel, (T)unnel
   D  IF         SrcAddr          DstAddr         L4 Info         PktCnt     TCPFlags
   I  S4         192.168.101.010  192.168.100.002 017:00080:60750 0000003841 ......
   I  S4         192.168.060.107  192.168.100.002 017:65840:00069 0000003841 ......
   I  S4         192.168.060.009  192.168.100.002 006:11000:00023 0000000010 A.P.S.
   I  S4         10.168.060.002   192.168.100.002 001:00000:02048 0000001567 ......
   I  S4         192.168.012.002  192.168.100.002 017:60750:00069 0000003841 ......
   I  S4         192.168.061.003  192.168.100.042 017:00022:10157 0000003841 ......
   I  S4         192.168.060.002  192.168.100.066 017:30123:00069 0000003841 ......
   I  S4         192.168.050.002  192.168.101.002 001:00000:02048 0000001567 ......
   I  S4         10.168.060.003   192.168.101.004 001:00000:02048 0000001567 ......

In the preceding example, there are multiple IPv6 flows for Telnet on TCP port 23TFTP on UDP port 69, and ICMP.

Note: ICMP flows are represented in the output using the L4 info (001:00000:02048). The protcol number 1 field is the assigned by Internet Assigned Numbers Authority (IANA). The source and destination field represents the type of ICMP captured by NetFlow. To get the ICMP code type, convert the decimal to hexidecimal. In this example, 2048 = 0800 which is type_8 code_0 (ICMP echo).

Administrators are advised to compare these flows to baseline utilization (such as Telnet in the above example) and also investigate the flows to determine whether they are sourced from untrusted hosts or networks.

If administrators are interested only in a specific type of traffic flow, the following examples show how to view specific NetFlow records. To view only Telnet flows on TCP port 23 use the show hardware flow ipv6 | include IF|06.*(23) command. To view only TFTP flows on UDP port 69 use show hardware flow ip | include IF|17.*(69). To view only ICMP flows use show hardware flow ip | include IF|001:00000:

TCP Flows

Nexus#show hardware flow ipv6 |  include IF|06.*(23)
   IF  - Interface: ()ethernet, (S)vi, (V)lan, (P)ortchannel, (T)unnel
   D  IF         SrcAddr            DstAddr          L4 Info         PktCnt     TCPFlags
   I  S4         2001:DB...06::201  2001:DB...28::20 006:60750:00023 0000003841 ...... 
   I  S4         2001:DB...6A:5BA6  2001:DB...28::21 006:65840:00023 0000003841 ...... 
   I  S4         2001:DB...6A:5BA6  2001:DB...28::03 006:56329:00023 0000000010 ......

As shown in the following example, to view only the TFTP packets on UDP port 69, use show hardware flow ip | include IF|17.*(69)

UDP Flows

Nexus#show hardware flow ip | include IF|17.*(69)
   IF  - Interface: ()ethernet, (S)vi, (V)lan, (P)ortchannel, (T)unnel
   D  IF         SrcAddr            DstAddr          L4   Info        PktCnt     TCPFlags
   I  S4         2001:DB...06::201  2001:DB...28::20 017:60750:00069  0000003841 ...... 
   I  S4         2001:DB...6A:5BA6  2001:DB...28::21 017:98563:00069  0000003841 ...... 
   I  S4         2001:DB...6A:5BA6  2001:DB...134::3 017:45832:00069  0000000010 ......

ICMP Flows

Nexus#show hardware flow ip |  include IF|001:00000:
   IF  - Interface: ()ethernet, (S)vi, (V)lan, (P)ortchannel, (T)unnel
   D  IF         SrcAddr            DstAddr          L4   Info            PktCnt     TCPFlags
   I  S4         2001:DB...06::201  2001:DB...28::20 001:001:00000:02048  0000003841 ...... 
   I  S4         2001:DB...6A:5BA6  2001:DB...28::21 017:001:00000:02048  0000003841 ...... 
   I  S4         2001:DB...6A:5BA6  2001:DB...134::3 017:001:00000:02048  0000000010 ......

Conclusion

In summary, this document presented mitigation identification techniques for Cisco NX-OS ACLs, ACL logging, spoofing protection using uRPF, and Cisco NX-OS NetFlow. It explained how to display attempts to bypass protections and exploit vulnerabilities. It is at the administrator's discretion to modify the show commands used in this document for their own specific needs to identify if security policies deployed to mitigate certain vulnerabilities or threats have been successful.

Additional Information

Risk Management

Organizations are advised to follow their standard risk evaluation and mitigation processes to determine the potential impact of vulnerabilities. Triage refers to sorting projects and prioritizing efforts that are most likely to be successful. Cisco has provided documents that can help organizations develop a risk-based triage capability for their information security teams. Risk Triage for Security Vulnerability Announcements and Risk Triage and Prototyping in Information Security Engagements can help organizations develop repeatable security evaluation and response processes.

Resources

 


This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.


Back to Top