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
Cisco NX-OS Software can provide effective means of exploit identification using the following:
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.
The following are examples of an access control list (ACL) used to block TELNET on TCP port 23, TFTP 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:
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:
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 ICMP, TFTP on UDP port 69, and Telnet on TCP port 23.
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#
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 23, TFTP 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 Telnet, TFTP, 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#
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 23, TFTP 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 ......
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.
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.
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.