Tag: Internet Protocol

Cisco IOS Software NAT64 Denial of Service Vulnerability

Cisco Leave a comment

A vulnerability in the Network Address Translation 64 (NAT64) functions of Cisco IOS Software could allow an unauthenticated, remote attacker to cause either an interface queue wedge or a device reload.

The vulnerability is due to the incorrect handling of certain IPv4 packet streams that are sent through the device. An attacker could exploit this vulnerability by sending specific IPv4 packet streams through the device. An exploit could allow the attacker to either cause an interface queue wedge or a device reload, resulting in 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-20190327-nat64

This advisory is part of the March 27, 2019, release of the Cisco IOS and IOS XE Software Security Advisory Bundled Publication, which includes 17 Cisco Security Advisories that describe 19 vulnerabilities. For a complete list of the advisories and links to them, see Cisco Event Response: March 2019 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication.

Security Impact Rating: High

CVE: CVE-2019-1751

Related:

32 bit SNMP interface counter fetches an invalid response.

Citrix Leave a comment
32-bit SNMP interface counters (ifInOctets/ifOutOctets) are sourced by hardware statistics retrieved from interface registers.

These counters are valid for MPX/SDX, loopback interface and legacy-emulated(E1000) interfaces in ESX-VPX. But are not valid for VMXNet3 interfaces.

Since hardware statistics retrieval was not supported for PV drivers (VMXNet3), these counters will show Zero for PV interfaces (VMXNet3).

As per RFC2233, High capacity octet counters (expanded 64-bit counters) were adapted for high capacity interfaces operating at speeds higher than 20 million bits per second, in which 32-bit counters do not provide enough capacity and wrap too fast.

“For interfaces that operate at 20,000,000 (20 million) bits per

second or less, 32-bit byte and packet counters MUST be used. For

interfaces that operate faster than 20,000,000 bits/second, and

slower than 650,000,000 bits/second, 32-bit packet counters MUST

be used and 64-bit octet counters MUST be used. For interfaces

that operate at 650,000,000 bits/second or faster, 64-bit packet

counters AND 64-bit octet counters MUST be used.”

Related:

7023549: How to Configure Postgres to Allow Remote Connections

Novell Leave a comment

  • Determine and set allowed connection addresses.

    Modifying the pg_hba_conf file correctly requires that the IP addresses of the remaining Secure Messaging Gateway servers are known. The addresses may be specified individually or they may be specified in a range.

    For example, the above specified address setting of “10.1.29.0/24” will allow connections from any address of 10.1.29.x.

    If a subnet of addresses is desired, it may also be specified as such:

    10.0.0.0/8 Will allow any connection from addresses 10.x.x.x

    172.16.0.0/16 Will allow any connection from addresses 172.16.x.x

    192.168.1.0/24 Will allow any connection from addresses 192.168.1.x

    Or if a specific IP is to be specified: 192.168.1.20/32

    Once the file has been modified to allow connections from the desired addresses, save the file.

    • Related:

    How to align the IP version displayed on SEMP?

    Symantec Community Leave a comment
    I need a solution

    Good day everyone,

    The IP display method is not aligned and show IP V4 and V6, I would like to know how to make it align and show IPv4 info. only? 

    Thank you very much!

    0

    Related:

    Linux Kernel IP Fragment Reassembly Denial of Service Vulnerability Affecting Cisco Products: August 2018

    Cisco Leave a comment

    On August 14, 2018, the Vulnerability Coordination team of the National Cyber Security Centre of Finland (NCSC-FI) and the CERT Coordination Center (CERT/CC) disclosed a vulnerability in the IP stack that is used by the Linux Kernel. This vulnerability is publicly known as FragmentSmack.

    The vulnerability could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. An attack could be executed by an attacker who can submit a stream of fragmented IPv4 or IPv6 packets that are designed to trigger the issue on an affected device.

    The vulnerability is due to inefficient IPv4 and IPv6 fragment reassembly algorithms in the IP stack that is used by the affected kernel. Linux Kernel Versions 3.9 and later are known to be affected by this vulnerability.

    This advisory will be updated as additional information becomes available.

    This advisory is available at the following link:
    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180824-linux-ip-fragment

    Security Impact Rating: High

    CVE: CVE-2018-5391

    Related:

    ScaleIO: Error while running the script during ScaleIO Deployment “Could not complete network copy for file /vmfs/volume/”

    Dell Community Leave a comment

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



    ScaleIO 2.0.1.1,ScaleIO 2.0.1,ScaleIO 2.0.0.3,ScaleIO 2.0.0.2,ScaleIO 2.0.0.1,ScaleIO 2.0.0

    Customer trying to run the ps1 script from a windows host, selects option 3 to Create SVM Template, and provides the list of datastores on which the templates will be created.

    It successfully creates the template EMC ScaleIO SVM Template on one of the datastore but fails on the next with the following error:-

    Cannot create template EMC ScaleIO SVM Template <v2.0.11000.174> 2 from the temporary SVM

    Error

    The operation for the entity “EMC ScaleIO SVM Template <v2.0.11000.174> 1” failed with the following message: “Could not complete network copy for file /vmfs/volume/5849af5d-xxxxxxxx-xxxx-xxxxxxxxxxxx/EMC ScaleIO SVM Template <v2.0.11000.174> 1/EMC ScaleIO SVM Template <v2.0.11000.174> 1.vmdk”


    User-added image

    This issue can occur due to high network latency or packet loss in the environment.

    ESX Connectivity Check

    This article assumes two data networks, configured with 192.168.152.x and 192.168.154.x subnets.

    Find out which vmknic is on which subnet, as well as MTU: 

    [root@server1-101:~] esxcfg-vmknic -lInterface Port Group/DVPort/Opaque Network IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type NetStackvmk0 sys-mgmt-krnl IPv4 192.168.105.101 255.255.255.0 192.168.105.255 00:xx:xx:xx:xx:xx 9000 65535 true STATIC defaultTcpipStackvmk3 sys-vmotion IPv4 192.168.106.101 255.255.255.0 192.168.106.255 00:xx:xx:xx:xx:xx 9000 65535 true STATIC defaultTcpipStackvmk1 sio-data1-krnl IPv4 192.168.152.121 255.255.255.0 192.168.152.255 00:xx:xx:xx:xx:xx 9000 65535 true STATIC defaultTcpipStackvmk2 sio-data2-krnl IPv4 192.168.154.141 255.255.255.0 192.168.154.255 00:xx:xx:xx:xx:xx9000 65535 true STATIC defaultTcpipStack

    Ping each ESXi in the environment via each vmknic with packet size 8972:

    If jumbo frames are configured and this test fails, network connectivity is not 100%: 

    vmkping -d -s 8972 -I vmk1 192.168.152.101vmkping -d -s 8972 -I vmk2 192.168.154.101

    Try without jumbo frames:

    vmkping -d -s 1472 -I vmk1 192.168.152.101 vmkping -d -s 1472 -I vmk2 192.168.154.101

    or 

    vmkping -I vmk1 192.168.152.101vmkping -I vmk2 192.168.154.101

    Ping the subnet gateways:

    Jumbo: 

    vmkping -d -s 8972 -I vmk1 192.168.152.1vmkping -d -s 8972 -I vmk2 192.168.154.1

    Normal: 

    vmkping -I vmk1 192.168.152.1vmkping -I vmk2 192.168.154.1or vmkping -d -s 1472 -I vmk1 192.168.152.1 vmkping -d -s 1472 -I vmk2 192.168.154.1In case you are able to ping with packet size 1472 i.e. without Jumbo frames, that means somewhere in the network stack, MTU size of 9000 is missing. In case you want you can set the MTU size to 1500 everywhere and proceed with deoplyment. Once the deployment is done, you can investigate and set MTU size of 9000 on all the network equipment and also in the SVMs.Please note: all network equipment should support Jumbo Frames and should be enabled from end to end.

    Related:

    Re: VNX 5200 peer IP change

    Dell Community Leave a comment

    Hi,

    It is best way to open SR and ask help for remote support for this.

    There are 2 ways of doing this;

    1- from /setup (This cause SP reboot)

    2- from navicli commands (This cause just management service restart)

    Here are some examples for navicli commands;

    naviseccli -h 128.221.1.250 -user sysadmin -password sysadmin -scope 0 networkadmin -set -ipv4 -address 10.240.88.218 -subnetmask 255.255.255.192 -gateway 10.240.88.250

    naviseccli -h 128.221.1.251 -user sysadmin -password sysadmin -scope 0 networkadmin -set -ipv4 -address 10.255.254.75-subnetmask 255.255.255.0 -gateway10.255.254.1

    naviseccli -h 128.221.1.250 -user sysadmin -password sysadmin -scope 0 networkadmin -get -ipv4

    You may use these commands while you are connected to SP service ports.

    Related:

    RecoverPoint: Cannot configure SNMP targets with domain name strings

    Dell Community Leave a comment

    Article Number: 483424 Article Version: 4 Article Type: Break Fix



    RecoverPoint

    Impacts:

    When setting up SNMP configured targets through CLI, FAPI and GUI with DNS names rather than IP and attempt to configure SNMP, the SNMP is refused.


    Symptoms:

    In management process will find:

    “Error: Invalid snmp settings. ( Invalid IP address. )”


    Affects:

    4.0.*

    4.1.*

    4.4

    4.4.1

    4.3.*

    Cause:

    SNMP target addresses are validated to have IPv4 or IPv6 style strings and if they show otherwise, they are rejected.

    Workaround:

    Use the IPv4 or IPv6 explicit address instead.

    Resolved at:

    5.0

    Related:

    How to force DPA Agent to listen to IPv4?

    Dell Community Leave a comment

    The dafault installation of DPA Agent makes it listen to :::3741 (that is, all IPv6 addresses, port 3741), but I need 0.0.0.0:3741 (all IPv4 addresses, port 3741).

    The dpaagent_config.xml reads:

    <AGENTCONFIG> <VERSION>600</VERSION> <AGENTVERSION>6.4.0.102986</AGENTVERSION> <SERVERNAME>172.31.1.98</SERVERNAME> <SERVERPORT>9002</SERVERPORT> <SERVERSSL>true</SERVERSSL> <LOGFILE>/appl/dpa/agent/logs/dpaagent.log</LOGFILE> <LOGLEVEL>Info</LOGLEVEL> <JREDIR>/appl/dpa/services/_jre</JREDIR></AGENTCONFIG>

    How to modify this to achieve IPv4 listening?

    At this moment, I can’t reach my agent via IPv4.

    Thanks

    Related:

    • No Related Posts