Cisco FXOS and NX-OS Software Authenticated Simple Network Management Protocol Denial of Service Vulnerability

A vulnerability in the Simple Network Management Protocol (SNMP) input packet processor of Cisco FXOS Software and Cisco NX-OS Software could allow an authenticated, remote attacker to cause the SNMP application on an affected device to restart unexpectedly.

The vulnerability is due to improper validation of Abstract Syntax Notation One (ASN.1)-encoded variables in SNMP packets. An attacker could exploit this vulnerability by sending a crafted SNMP packet to the SNMP daemon on the affected device. A successful exploit could allow the attacker to cause the SNMP application to restart multiple times, leading to a system-level restart and a denial of service (DoS) condition.

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-20190828-fxnxos-snmp-dos

This advisory is part of the August 2019 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication, which includes five Cisco Security Advisories that describe five vulnerabilities. For a complete list of the advisories and links to them, see Cisco Event Response: August 2019 Cisco FXOS and NX-OS Software Security Advisory Bundled Publication.

Security Impact Rating: High

CVE: CVE-2019-1963

Related:

  • No Related Posts

Cisco NX-OS Software SNMP Access Control List Configuration Name Bypass Vulnerability

A vulnerability in the implementation of the Simple Network Management Protocol (SNMP) Access Control List (ACL) feature of Cisco NX-OS Software could allow an unauthenticated, remote attacker to perform SNMP polling of an affected device, even if it is configured to deny SNMP traffic.

The vulnerability is due to an incorrect length check when the configured ACL name is the maximum length, which is 32 ASCII characters. An attacker could exploit this vulnerability by performing SNMP polling of an affected device. A successful exploit could allow the attacker to perform SNMP polling that should have been denied. The attacker has no control of the configuration of the SNMP ACL name.

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

This advisory is available at the following link:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190828-nxos-snmp-bypass

Security Impact Rating: Medium

CVE: CVE-2019-1969

Related:

  • No Related Posts

Cisco FXOS and NX-OS Software Simple Network Management Protocol Denial of Service Vulnerability

A vulnerability in the Simple Network Management Protocol (SNMP) input packet processor of Cisco FXOS Software and Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause the SNMP application to leak system memory, which could cause an affected device to restart unexpectedly.

The vulnerability is due to improper error handling when processing inbound SNMP packets. An attacker could exploit this vulnerability by sending multiple crafted SNMP packets to an affected device. A successful exploit could allow the attacker to cause the SNMP application to leak system memory because of an improperly handled error condition during packet processing. Over time, this memory leak could cause the SNMP application to restart multiple times, leading to a system-level restart and a denial of service (DoS) condition.

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-20190515-nxos-snmp-dos

Security Impact Rating: High

CVE: CVE-2019-1858

Related:

  • No Related Posts

Cisco Small Business Series Switches Simple Network Management Protocol Denial of Service Vulnerability

A vulnerability in the Simple Network Management Protocol (SNMP) input packet processor of Cisco Small Business Sx200, Sx300, Sx500, ESW2 Series Managed Switches and Small Business Sx250, Sx350, Sx550 Series Switches could allow an authenticated, remote attacker to cause the SNMP application of an affected device to cease processing traffic, resulting in the CPU utilization reaching one hundred percent. Manual intervention may be required before a device resumes normal operations.

The vulnerability is due to improper validation of SNMP protocol data units (PDUs) in SNMP packets. An attacker could exploit this vulnerability by sending a malicious SNMP packet to an affected device. A successful exploit could allow the attacker to cause the device to cease forwarding traffic, which could result in a denial of service (DoS) condition.

Cisco has released firmware 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-20190515-sb-snmpdos

Security Impact Rating: High

CVE: CVE-2019-1806

Related:

  • No Related Posts

SNMP Remote Code Execution Vulnerabilities in Cisco IOS and IOS XE Software

The Simple Network Management Protocol (SNMP) subsystem of Cisco IOS and IOS XE Software contains multiple vulnerabilities that could allow an authenticated, remote attacker to remotely execute code on an affected system or cause an affected system to reload. An attacker could exploit these vulnerabilities by sending a crafted SNMP packet to an affected system via IPv4 or IPv6. Only traffic directed to an affected system can be used to exploit these vulnerabilities.

The vulnerabilities are due to a buffer overflow condition in the SNMP subsystem of the affected software. The vulnerabilities affect all versions of SNMP – Versions 1, 2c, and 3. To exploit these vulnerabilities via SNMP Version 2c or earlier, the attacker must know the SNMP read-only community string for the affected system. To exploit these vulnerabilities via SNMP Version 3, the attacker must have user credentials for the affected system. A successful exploit could allow the attacker to execute arbitrary code and obtain full control of the affected system or cause the affected system to reload.

Customers are advised to apply the workaround as contained in the Workarounds section below. Fixed software information is available via the Cisco IOS Software Checker. All devices that have enabled SNMP and have not explicitly excluded the affected MIBs or OIDs should be considered vulnerable.

Cisco has released software updates that address these vulnerabilities. There are workarounds that address these vulnerabilities.

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

Security Impact Rating: High

CVE: CVE-2017-6736,CVE-2017-6737,CVE-2017-6738,CVE-2017-6739,CVE-2017-6740,CVE-2017-6741,CVE-2017-6742,CVE-2017-6743,CVE-2017-6744

Related:

  • No Related Posts

Query Amount of Login Failures

I need a solution

Hi there,

the daily status email of my Symantec Encryption Server informs me about the amount of Login Failures (for Administration and Web Email Protection).

Can I ask for this information via SNMP as well??? In the custom MIB I only found all the statistic values. I would like to skip reading the daily status mail…..

Thanks for your help!

0

Related:

  • No Related Posts

ViPR SRM: After the upgrade of SRM to 4.1.1 SNMP Device Discovery and compliance frontend not working

Article Number: 504610 Article Version: 3 Article Type: Break Fix



ViPR Family,ViPR SRM 4.1

SNMP Device Discovery and Compliance Frontend URL’s doesn’t work, they just return blank page after the upgrade to 4.1.1

Errors seen on Catalina logs;

Sep 21, 2017 10:35:37 AM org.apache.catalina.core.StandardContext startInternal

SEVERE: One or more listeners failed to start. Full details will be found in the appropriate container log file

Sep 21, 2017 10:35:37 AM org.apache.catalina.core.StandardContext startInternal

SEVERE: Context [/device-discovery] startup failed due to previous errors

Sep 21, 2017 10:36:19 AM org.apache.catalina.core.StandardContext startInternal

SEVERE: One or more listeners failed to start. Full details will be found in the appropriate container log file

Sep 21, 2017 10:36:19 AM org.apache.catalina.core.StandardContext startInternal

SEVERE: Context [/compliance-frontend] startup failed due to previous errors


Errors seen on Localhost logs;

21-Sep-2017 10:35:37.739 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class com.watch4net.apg.gui.servlet.ApplicationListener

java.lang.IllegalStateException: Can’t create master accessor.

Caused by: javax.naming.NameNotFoundException: Name [jdbc/master] is not bound in this Context. Unable to find [jdbc].

21-Sep-2017 10:36:19.211 SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class com.watch4net.apg.gui.servlet.ApplicationContextListener

java.lang.IllegalStateException: An error occurred notifying listeners !

Caused by: java.lang.IllegalStateException: An error occurred creating the datasource.

Caused by: javax.naming.NameNotFoundException: Name [jdbc/master] is not bound in this Context. Unable to find [jdbc].

Login to Frontend server via putty.

Navigate to the location:

/opt/APG/Web-Servers/Tomcat/Default/conf/Catalina/localhost

Edit the device-discovery.xml and compliance-frontend.xml files as below:


The device-discovery.xml file had the incorrect entry to the database entries;

<ResourceLink name=”jdbc/master” global=”jdbc/master” type=”javax.sql.DataSource”/>

Changed it to

<ResourceLink name=”dba/master” global=”dba/master” type=”com.watch4net.apg.gui.datasource.DatasourceConfiguration”/>

Compliance-frontend.xml file had incorrect master db configuration

<ResourceLink name=”jdbc/master” global=”jdbc/master” type=”javax.sql.DataSource”/>

Changed it to

<ResourceLink name=”dba/master” global=”dba/master” type=”com.watch4net.apg.gui.datasource.DatasourceConfiguration”/>

Restarted the tomcat and resolved the issue


Also, verify if the resource link entries are same as above in context.xml for both the modules under location:

context.xml for device-discovery:

/opt/APG/Web-Servers/Tomcat/Default/webapps/device-discovery/META-INF

context.xml for compliance-frontend:

/opt/APG/Web-Servers/Tomcat/Default/webapps/compliance-frontend/META-INF

Related:

  • No Related Posts

Recommended Settings and Best Practices for Generic Implementation of a NetScaler Appliance

Recommended Settings for a Generic Implementation of a NetScaler Appliance

The following sections contain the recommended settings for a generic implementation of some features of a NetScaler appliance:

Modes

To configure the modes on an appliance, complete the following procedure:

  1. Expand the System node of the Navigation pane on the appliance.

  2. Select the Settings node.
  3. In the details pane, under Modes and Features, click Configure modes.

  4. Select the Fast Ramp option.

    Note: With Fast-Ramp enabled the NetScaler starts with the congestion window of the freshest server connection. For more information refer to Citrix Blog.

  5. Clear the Layer 2 Mode option.

    Note: Select this mode if servers are connected directly to the appliance or if the appliance is used as a transparent bridge.

  6. Select the Use Source IP option.

    Note: Select this mode only if an application requires the source IP address.

  7. Clear the Client Keep-Alive option.

    Note: Applications can stop working due to optimization. Select this option only when there are performance issues.

  8. Clear the TCP Buffering option.

    Note: If the network does not support Window Scaling and there are performance issues, select this option.

  9. Clear the MAC Based Forwarding option.

    Note: If you are using one-arm configuration, then select this option.

  10. Select the Use Subnet IP option.

    Note: Always select this option unless specific requirements of the network set up do not require it.

  11. Select the Layer 3 Mode (IP Forwarding) option.

    Note: If there are security issues and you want to use the appliance as a firewall, then clear this option.

  12. Select the Path MTU Discovery option. This mode helps avoid fragmentation of packets.

  13. Clear the Static Route Advertisement option.

    Note: If you are using the dynamic routing feature, select this option.

  14. Clear the Direct Route Advertisement option.

  15. Clear the Intranet Route Advertisement option.

  16. Clear the Ipv6 Static Route Advertisement option.

  17. Clear the Ipv6 Direct Route Advertisement option.

  18. Clear the Bridge BPDUs option.

Features

For information on the features available and how to enable them on NetScaler, refer to CTX122942 – How to Activate Various Features and Modes of a NetScaler Appliance.

Note: Enabling features impacts the performance of the NetScaler appliance. Enable only the features that you want to use.

Global System Settings

To configure the global system settings on an appliance, complete the following procedure:

  1. Expand the System node of the Navigation pane on the appliance.

  2. Select the Settings node.

  3. Click the Change global systemsettings link on the Settings page.

  4. Select the Window Scaling option.

    Note: Clear the Window Scaling option only if it is not supported by the network.

    In NetScaler 10.5, 11.0 and 11.1 builds the “Window Scaling” option is under System > Settings > Change TCP Parameters.

  5. Select the Selective Acknowledgment option.

    Note: Clear this option only if the Window Scaling option is clear.

    In NetScaler 10.5, 11.0 and 11.1 builds the “Selective Acknowledgment” option is under System > Settings > Change TCP Parameters.

  6. Select the Use Nagle’s algorithm option. In NetScaler 10.5, 11.0 and 11.1 builds the “Nagle’s algorithm” option is under System > Settings > Change TCP Parameters.

    Points to Note:

    – Select this option for heavy flow of small packets. Not recommended for ICA traffic.

    – Nagle’s algorithm is disabled in default TCP profile. However, in a custom TCP profile it is enabled currently and this will be fixed in an upcoming release . Custom profiles have to be explicitly bound for the settings to be honored.

  7. Select the Enable RNAT TCP Proxy option.

HTTP Parameters

To configure the HTTP parameters of an appliance, complete the following procedure:

  1. Expand the System node of the Navigation pane on the appliance.

  2. Select the Settings node.

  3. Click the Change HTTP parameters link on the Settings page.

  4. Select the Version 1 option.

    Note: Select the Version 0 option only if the environment has earlier releases of web browser that do not support Cookie Version 1.

  5. Select the Drop invalid HTTP requests option.

    Ensure that you always select this option. It helps in detecting the invalid HTTP headers.

    NOTE: This can cause some resources not to load through a Vserver, so be sure to thoroughly test after enabling. If you have subsequent issues accessing resources, disable this setting and test.

SNMP Alarms

To configure the recommended settings for Simple Network Management Protocol (SNMP) Alarms on an appliance, complete the following procedure:

  1. Expand the System node of the Navigation pane on the appliance.

  2. Expand the SNMP node.

  3. Select the Alarms node.

  4. Select the CPU-USAGE alarm in the SNMP Alarms page.

  5. Configure the following options in the Configure SNMP Alarm dialog box:

    • Type 95 in the Alarm Threshold field.

    • Type 35 in the Normal Threshold field.

    • Select Informational from the Severity list.

    • Select the Enable option.

  6. Click OK.

  7. Select the MEMORY alarm and click Open.

  8. Configure the following options in the Configure SNMP Alarm dialog box:

    • Type 95 in the Alarm Threshold field.

      Note: If this threshold is reached, then force failover the appliance. If it happens again, then contact Citrix Technical Support.

    • Type 35 in the Normal Threshold field.

    • Select Critical from the Severity list.

    • Select Enabled from the Logging list.

    • Select the Enable option.

Network Interfaces

To configure the network interfaces on an appliance, complete the following procedure:

  1. Expand the Network node of the Navigation pane on the appliance.

  2. Select the Interfaces node.

  3. Select the interface not in use and click Disable.

    Repeat this step for each interface that is not in use.

  4. Disable High Availability Monitoring on all disabled interfaces and on the enabled interface that does not require High Availability Monitoring. To disable High Availability Monitoring on an interface, complete the following procedure:

    1. Select the interface.

    2. Select the OFF option for HA Monitoring.

    3. Click OK.

General Best Practices

The following is a list of best practices for a generic implementation of an appliance:

Additional Resources

For command reference, refer to Citrix Documentation – Command Reference.

Related:

  • No Related Posts