Cisco IOS XR and Cisco NX-OS Software IPv6 Access Control List Bypass Vulnerability

A vulnerability in the IPv6 traffic processing of Cisco IOS XR Software and Cisco NX-OS Software for certain Cisco devices could allow an unauthenticated, remote attacker to bypass an IPv6 access control list (ACL) that is configured for an interface of an affected device.

The vulnerability is due to improper processing of IPv6 traffic that is sent through an affected device. An attacker could exploit this vulnerability by sending crafted IPv6 packets that traverse the affected device. A successful exploit could allow the attacker to access resources that would typically be protected by the interface ACL.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ipv6-acl-CHgdYk8j

Security Impact Rating: Medium

CVE: CVE-2021-1389

Related:

  • No Related Posts

Cisco IOS XE Software for Catalyst 9800 Series and Cisco AireOS Software for Cisco WLC Flexible NetFlow Version 9 Denial of Service Vulnerability

A vulnerability in the Flexible NetFlow Version 9 packet processor of Cisco IOS XE Software for Cisco Catalyst 9800 Series Wireless Controllers and Cisco AireOS Software for Cisco Wireless LAN Controllers (WLC) could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

The vulnerability is due to insufficient validation of certain parameters in a Flexible NetFlow Version 9 record. An attacker could exploit this vulnerability by spoofing the address of an existing Access Point on the network and sending a Control and Provisioning of Wireless Access Points (CAPWAP) packet that includes a crafted Flexible NetFlow Version 9 record to an affected device. A successful exploit could allow the attacker to cause a process crash that would lead to a reload of the device.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-wlc-fnfv9-EvrAQpNX

This advisory is part of the September 24, 2020, release of the Cisco IOS and IOS XE Software Security Advisory Bundled Publication, which includes 25 Cisco Security Advisories that describe 34 vulnerabilities. For a complete list of the advisories and links to them, see Cisco Event Response: September 2020 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication.

Security Impact Rating: High

CVE: CVE-2020-3492

Related:

Cisco IOS XE Software Flexible NetFlow Version 9 Denial of Service Vulnerability

A vulnerability in the Flexible NetFlow Version 9 packet processor of Cisco IOS XE Software for Cisco Catalyst 9800 Series Wireless Controllers could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

The vulnerability is due to improper validation of parameters in a Flexible NetFlow Version 9 record. An attacker could exploit this vulnerability by sending a malformed Flexible NetFlow Version 9 packet to the Control and Provisioning of Wireless Access Points (CAPWAP) data port of an affected device. An exploit could allow the attacker to trigger an infinite loop, resulting in a process crash that would cause a reload of the device.

Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-fnfv9-dos-HND6Fc9u

This advisory is part of the June 3, 2020, release of the Cisco IOS and IOS XE Software Security Advisory Bundled Publication, which includes 23 Cisco Security Advisories that describe 25 vulnerabilities. For a complete list of the advisories and links to them, see Cisco Event Response: June 2020 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication.

Security Impact Rating: High

CVE: CVE-2020-3221

Related:

Securing the Cisco IOS and IOS XE Software Layer 2 Traceroute Server

The Layer 2 (L2) traceroute utility identifies the L2 path that a packet takes from a source device to a destination device. Cisco IOS Software and Cisco IOS XE Software for Cisco Catalyst switches have inherited the L2 traceroute feature from Cisco CatOS Software. As such, this feature has been supported since Cisco IOS and IOS XE Software were first released. Cisco has confirmed that the L2 traceroute feature is not supported in Cisco IOS XR Software or Cisco NX-OS Software.

The L2 traceroute feature is enabled by default in Cisco IOS and IOS XE Software for Cisco Catalyst switches. Enabling the feature starts the L2 traceroute server, which is reachable through IPv4, listening on UDP port 2228. The following example shows the output of the show ip sockets command on a device that has the L2 traceroute feature enabled:

Switch#show ip sockets
Proto        Remote      Port      Local       Port  In Out  Stat TTY OutputIF
 17     0.0.0.0             0 10.10.10.1       2228   0   0   211   0 

By design, the L2 traceroute server does not require authentication, and it allows certain information about an affected device to be read, including the following:

  • Hostname
  • Hardware model
  • Configured interfaces
  • Configured IP addresses
  • VLAN database
  • MAC address table
  • Layer 2 filtering table
  • Cisco Discovery Protocol (CDP) neighbor information

Reading this information from multiple switches in the network could allow an attacker to build a complete L2 topology map of that network.

Customers are advised to secure the L2 traceroute server as described in the Recommendations section of this advisory.

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190925-l2-traceroute

Security Impact Rating: Informational

Related:

Citrix ADC UDP Counters

This article contains information about the newnslog User Datagram Protocol (UDP) counters and its brief description.

Using the Counters

Log on to the ADC using an SSH client, change to SHELL, navigate to the /var/nslog directory, and then use the ‘nsconmsg’ command to see comprehensive statistics using the different counters available. For the detailed procedure refer to Citrix Blog – NetScaler ‘Counters’ Grab-Bag!.

The newnslog UDP Counters

The following table lists the newnslog UDP counters with a simple description of the counter.

newnslog Counter

Description

udp_err_unknown_services

UDP packets received (but dropped) on a NetScaler port number that is not assigned to any service.

udp_err_threshold

Number of times the UDP rate threshold is exceeded. If this counter continuously increases, first ensure that the UDP packets received are genuine. If they are, then increase the current rate threshold.

udp_err_badchecksums

Packets received with a UDP checksum error

udp_tot_rxpkts

UDP packets received

udp_tot_rxbytes

Bytes of UDP data received

udp_tot_txpkts

UDP packets transmitted

udp_tot_txbytes

Bytes of UDP data transmitted

udp_cur_ratethreshold

Limit for UDP packets handled every 10 milliseconds. Default value, 0, applies no limit. This is a configurable value using the set rateControl command.

Related:

Re: Separate physical network for backup?

In our environment, we have never used split networks for production and backup traffic. The sheer overhead of additional network connectivity provides very little benefit. In our case, we’ve had servers with single network NICs and servers with dual, redundant NICs. Adding yet-another NIC, just for backup traffic, would only serve to add more confusion and physical congestion.

In other environments I’ve been engaged in, we used dual physical NIC in redundant configurations, but used VLAN tagging to logically isolate backup traffic and production traffic. This required significantly less network cabling, and it still provided a bit of performance improvement, as our Cisco switches let us mix MTU sizes and leverage Netflow and other features for performance benefit.

Let us know if that helps!

Karl

Related:

In-Band Network Telemetry: Next Frontier in Network Visualization with Analytics and Why Enterprise

In-Band Network Telemetry: Next Frontier in Network Visualization with Analytics and Why Enterprise Customer Care

By: Gautam Chanda, Global Product Line Manager DC Networking Analytics, HPE

Let’s first answer the important question: Why do we need Network Visualization and Analytics?

Data Center networks have become cloud scale and deployment of hyper-converged networks is increasing. Telecom networks will enable faster connectivity everywhere with higher bandwidth delivering 5G wireless services. All of these next-generation networks not only require much higher bandwidth, but they also require real-time telemetry to deliver services with good Quality of Experience (QoE).

A network with detailed real-time visibility enables better reliability and real-time control. Here are key reasons customers need Network Visualization and Analytics now even more than before:

  • Ability to Pinpoint Traffic Patterns for Dynamic Applications: Data centers now have increasingly complex network deployments with Network Virtualization & Overlay / Tunnel technologies; SDN/NFV; Silicon Programmability; Multi-tenancy; increased Applications volume; mobility; Hybrid cloud; Bare metal & Virtualized servers (VMs/Containers); Vswitch; NIC virtualization; Orchestration and the list goes on. This gives rise to increasingly complicated traffic patterns in the data center in which network operators would like to have greater visibility into those complex patterns to understand if their DC network infrastructure is performing optimally.
  • Security Challenges: More security concerns can arise in complicated IT scenarios, more strict regulatory compliances, and more cybersecurity attacks from both inside and outside data center are threats. Defense against Security Attacks and complex traffic patterns from both inside and outside of the data center are critical.
  • Intent-Based Network
  • Network Analytics (Visibility, Validation, Optimization & Upgrade, Troubleshooting, Policy Enforcement) is increasingly important for modern DC and Cloud deployments.

Old Network Management Tools such as SNMP is not up to the task in this very high speed networks as we move from 10G to 25G to 100G and beyond in a short order.

The figure below demonstrates very well the need for Network Visualization and Analytics:

INTBlogPhoto1.png

This bring us to In-Band Network Telemetry (INT).

Let’s pause for a minute:

  • Let’s assume you’re interested in the behaviour of your live user-data traffic.
    • What is the best source of information?
  • Well… probably the live user-data traffic itself.
    • Let’s add meta-data to all interesting live user-data traffic.

This is the essence of In-Band Network Telemetry.

The figure below contrasts traditional ways where in traditional network monitoring, an application polls the host CPU to gather aggregated telemetry every few seconds or minutes, which doesn’t scale well in next generation networks. In-Band Network Telemetry, however, enables packet level telemetry by having key details related to packet processing added to the data plane packets without consuming any host CPU resources:

Figure 2: Traditional vs New Way

INTBlogPhoto2.png

In-Band Network Telemetry (INT) is a sophisticated and flexible telemetry feature supported usually within the Network devices in HW. As explained above INT allows for the collection and reporting by the data plane on detailed latency, congestion, and network state information, without requiring intervention or work by the control plane. The INT enabled devices inserts this valuable metadata, which can then be extracted and interpreted later by a collector/Sink/Network Management SW such as HPE IMC, in-band without affecting network performance.

The INT will enable a number of very useful Customer Use Cases such as:

  • Network troubleshooting
    • When packets enter/exit networks
    • Which path was taken by individual flows associated with Specific Applications
    • How long packets spend at each hop
    • How long packets spend on each link
    • Which switches are seeing congestion?
    • Microburst detection
  • Real-time control or feedback loops:
    • Collector might use the INT data plane information to feed back control information to traffic sources, which could in turn use this information to make changes to traffic engineering or packet forwarding. (Explicit congestion notification schemes are an example of these types of feedback loops).
  • Network Event Detection:
    • If the collected path state indicates a condition that requires immediate attention or resolution (such as severe congestion or violation of certain dataplane invariances), the Collector could generate immediate actions to respond to the network events, forming a feedback control loop either in a centralized or a fully decentralized fashion (a la TCP).
  • List Goes On…..

The Figure below shows end to end INT Customer Use Case in a Data Center:

Figure 3: End To End INT

INTBlogPhoto3.png

In Figure 3 above shows how In-Band Network Telemetry is used to “Track in Real Time Path and Latency of Packets and Flows Associated with Specific Applications”:

  • Collect the physical path and hop latencies hop-by-hop for every packet.
  • Can be initiated /Transited / terminated by either a switch or a NIC (Network Interface Card) in a Host such as a Server.
  • INT metadata is encapsulated and exported to the collector (e.g. HPE IMC).

Use Cases

  • Case 1a: Real-time fault detection and isolation or alert: Congested/oversubscribed links and devices, imbalanced links (LAG, ECMP), loop.
  • Case 1b: Interactive analysis & troubleshooting: On-demand path visualization; Traffic matrix generation; Triage incidents of congestion.
  • Case 1c: Path Verification of bridging/routing, SLA, and configuration effects.
  • Enhanced visibility for all your Network traffic
  • Network provided telemetry data gathered and added to live data
    • Complement out-of-band OAM tools like SNMP, ping, and traceroute
    • Path / Service chain verification
  • Record the packet’s trip as meta-data within the packet
    • Record path and node (i/f, time, app-data) specific data hop-by-hop and end to end
    • Export telemetry data via Netflow/IPFIX/Kafka to Controller/Apps
  • In-band Network Telemetry can be implemented without forwarding performance degradation
  • Network ASIC vendors have started to add INT as a built in functions within their newest ASICs

HPE FlexFabric Network Analytics solution is leading the way towards this next frontier in Network Visualization and Analytics.

Related: