It's not a major issue. Here's Red Hat's stance on it: https://access.redhat.com/security/cve/cve-2004-0230 And this is a good read: https://lwn.net/Articles/81560/ Peter On 18/03/22 6:51 am, Kaushal Shriyan wrote: > Hi, > > I have 3.10.0-1160.59.1.el7.x86_64 on CentOS Linux release 7.9.2009 (Core) > running Nagios Monitoring system. We have run an external vulnerability > scan today on this server. The vulnerability reports say the below details. > I am not sure if I completely understand the below issue. > > CVSS base score:- 5.0 > CVE-2004-0230 > Severity : Medium > > TCP Sequence Number Approximation Based Denial of Service > > TCP provides stateful communications between hosts on a network. TCP > sessions are established by a three-way handshake and use random 32-bit > sequence and acknowledgement numbers to ensure the validity of traffic. A > vulnerability was reported that may permit TCP sequence numbers to be more > easily approximated by remote attackers. This issue affects products > released by multiple vendors. The cause of the vulnerability is that > affected implementations will accept TCP sequence numbers within a certain > range, known as the acknowledgement range, of the expected sequence number > for a packet in the session. This is determined by the TCP window size, > which is negotiated during the three-way handshake for the session. Larger > TCP window sizes may be set to allow for more throughput, but the larger > the TCP window size, the more probable it is to guess a TCP sequence number > that falls within an acceptable range. It was initially thought that > guessing an acceptable sequence number was relatively difficult for most > implementations given random distribution, making this type of attack > impractical. However, some implementations may make it easier to > successfully approximate an acceptable TCP sequence number, making these > attacks possible with a number of protocols and implementations. This is > further compounded by the fact that some implementations may support the > use of the TCP Window Scale Option, as described in RFC 1323, to extend the > TCP window size to a maximum value of 1 billion. This vulnerability will > permit a remote attacker to inject a SYN or RST packet into the session, > causing it to be reset and effectively allowing for denial of service > attacks. An attacker would exploit this issue by sending a packet to a > receiving implementation with an approximated sequence number and a forged > source IP address and TCP port. There are a few factors that may present > viable target implementations, such as those which depend on long-lived TCP > connections, those that have known or easily guessed IP address endpoints > and those implementations with easily guessed TCP source ports. It has been > noted that Border Gateway Protocol (BGP) is reported to be particularly > vulnerable to this type of attack, due to the use of long-lived TCP > sessions and the possibility that some implementations may use the TCP > Window Scale Option. As a result, this issue is likely to affect a number > of routing platforms. Another factor to consider is the relative > difficulty of injecting packets into TCP sessions, as a number of receiving > implementations will reassemble packets in order, dropping any duplicates. > This may make some implementations more resistant to attacks than others. > It should be noted that while a number of vendors have confirmed this issue > in various products, investigations are ongoing and it is likely that many > other vendors and products will turn out to be vulnerable as the issue is > investigated further. > > > Solution > Please first check the results section below for the port number on which > this vulnerability was detected. If that port number is known to be used > for port-forwarding, then it is the backend host that is really vulnerable. > Various implementations and products including Check Point, Cisco, Cray > Inc, Hitachi, Internet Initiative Japan, Inc (IIJ), Juniper Networks, NEC, > Polycom, and Yamaha are currently undergoing review. Contact the vendors to > obtain more information about affected products and fixes. " > http://packetstormsecurity.org/0404-advisories/246929.html" NISCC > Advisory 236929 - Vulnerability Issues in TCP details the vendor patch > status as of the time of the advisory, and identifies resolutions and > workarounds. Refer to "http://www.kb.cert.org/vuls/id/415294" US-CERT > Vulnerability Note VU#415294 and "http://osvdb.org/4030" OSVDB Article > 4030 to obtain a list of vendors affected by this issue and a note on > resolutions (if any) provided by the vendor. For Microsoft: Refer to " > https://docs.microsoft.com/en-us/security-updates/securitybulletins/2005/ms05-019" > MS05-019 and " > https://docs.microsoft.com/en-us/security-updates/securitybulletins/2006/ms06-064" > MS06-064 for further details. For SGI IRIX: Refer to " > ftp://patches.sgi.com/support/free/security/advisories/20040905-01-P.asc" > SGI Security Advisory 20040905-01-P For SCO UnixWare 7.1.3 and 7.1.1: > Refer to " > ftp://ftp.sco.com/pub/updates/UnixWare/SCOSA-2005.14/SCOSA-2005.14.txt" > SCO Security Advisory SCOSA-2005.14 For Solaris (Sun Microsystems): The > vendor has acknowledged the vulnerability; however a patch is not > available. Refer to "http://www.kb.cert.org/vuls/id/JARL-5YGQAJ" Sun > Microsystems, Inc. Information for VU#415294 to obtain additional details. > Also, refer to "http://www.us-cert.gov/cas/techalerts/TA04-111A.html" > TA04-111A for detailed mitigating strategies against these attacks. For > NetBSD: Refer to " > ftp://ftp.netbsd.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc" > NetBSD-SA2004-006 For Cisco: Refer to " > http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml" > cisco-sa-20040420-tcp-ios.shtml . For Red Hat Linux: There is no fix > available. Workaround: The following BGP-specific workaround information > has been provided. For BGP implementations that support it, the TCP MD5 > Signature Option should be enabled. Passwords that the MD5 checksum is > applied to should be set to strong values and changed on a regular basis. > Secure BGP configuration instructions have been provided for Cisco and > Juniper at these locations: " > http://www.cymru.com/Documents/secure-bgp-template.html" Secure Cisco IOS > BGP Template " > http://www.cymru.com/gillsr/documents/junos-bgp-template.pdf" JUNOS > Secure BGP Template > > Additional Information > > Tested on port 80 with an injected SYN/RST offset by 16 bytes. > > Please guide/suggest. Thanks in advance. > > Best Regards, > > Kaushal > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >