Could be reaching here but...

Does anyone have a fix for a "Statistical Weaknesses in TCP/IP
Initial Sequence Numbers" running on RedHat/CentOS 7 ???

Below is a snippet of a testing service result used by a credit card company telling me my firewall has this weakness. When searching through the articles at RedHat and Ubuntu forums they seem to poo poo the weakness, as at worst case, an attacker could only see one side of the packet transmission by guessing the sequence of the next packet and inject data into the session stream causing a reset of the network which would be handled by TCP dropping the packets without acknowledgement and reestablishing the connection after a network reset. It appears that larger window sizes in this stream can be more vulnerable.

A better description of the presumed weakness can be found here:

https://resources.sei.cmu.edu/asset_...001_496192.pdf

where you would search for CA-2001-09.

I can't get "certified" without some change to the TCP/IP stack it appears???

SNIPPET
Constant changes in initial sequence numbers observed in 21 out of 23 events.

[ Sent Packets Results ]
Packet 1 : TIME[1565914687.623586] SEQ[2969907
418] CHANGE[N/A] VARIATION[N/A]
Packet 2 : TIME[1565914687.628568] SEQ[2988781
196] CHANGE[18873778] VARIATION[N/A]
Packet 3 : TIME[1565914687.633579] SEQ[3007654
974] CHANGE[18873778] VARIATION[0]
Packet 4 : TIME[1565914687.638578] SEQ[3026528
752] CHANGE[18873778] VARIATION[0]
Packet 5 : TIME[1565914687.643564] SEQ[3045402
530] CHANGE[18873778] VARIATION[0]
Packet 6 : TIME[1565914687.648570] SEQ[3064276
308] CHANGE[18873778] VARIATION[0]
Packet 7 : TIME[1565914687.653565] SEQ[3083150
086] CHANGE[18873778] VARIATION[0]
Packet 8 : TIME[1565914687.663571] SEQ[3120897
642] CHANGE[37747556] VARIATION[18873778]
Packet 9 : TIME[1565914687.658571] SEQ[3102023
864] CHANGE[18873778] VARIATION[18873778]
Packet 10 : TIME[1565914687.668566] SEQ[313977
1420] CHANGE[37747556] VARIATION[18873778]
Packet 11 : TIME[1565914687.673565] SEQ[315864
5198] CHANGE[18873778] VARIATION[18873778]
Packet 12 : TIME[1565914687.678571] SEQ[317751
8976] CHANGE[18873778] VARIATION[0]
Packet 13 : TIME[1565914687.683572] SEQ[319639
2754] CHANGE[18873778] VARIATION[0]
Packet 14 : TIME[1565914687.688572] SEQ[321526
6532] CHANGE[18873778] VARIATION[0]
Packet 15 : TIME[1565914687.693567] SEQ[323414
0310] CHANGE[18873778] VARIATION[0]
Packet 16 : TIME[1565914687.698572] SEQ[325301
4088] CHANGE[18873778] VARIATION[0]

That's a vulnerability in the TCP/IP stack of the operating system, and requires a fix from the OS vendor. In Linux, the TCP/IP stack is part of the kernel.

I find it highly unlikely that a semi-recent version of CentOS has this vulnerability. Which kernel are you running?
Note that it's the firewall/router that has this issue, not the computers behind it.

I assume you're not using your CentOS server as a router?
I would disagree with that assessment. Poor randomness in ISNs makes "blind spoofing" of a TCP connection a practical possibility, meaning it's possible for an attacker to hijack an existing TCP connection.
And "2001-09" is a reference to a date. This is an ancient vulnerability that's been patched in just about every operating system in existence ages ago.

But you may have an old router/firewall running vulnerable firmware.
Indeed. You need to get this fixed.

I am running CentOS 7 as a firewall mostly because of the need for OpenVPN and other services being provided for the domain, such as ACL Zoned Bind etc.

Hijacking an existing connection that is encrypted would seem to me to be rather difficult in spite of this weakness as all traffic to and from this firewall is encrypted.

There are no public services such as apache, FTP etc. CA-2001-09 is a reference to the part of the article I listed above where a white paper describing the weakness is presented. This was provided to me by the testing company as a solution to fixing the problem.

The testing company has misidentified the firewall OS as Cisco/OS (it's CentOS 7 not Cisco) and have suggested upgrading the Cisco operating system.

In further review of the above listed document they purport to give solutions by OS to the problem. It states that an implementation of the RFC1948 is an acceptable fix to this vulnerability and furthermore the same article suggested by them, in that same section where they list fixes for multiple operating systems, they state:

Linux
The Linux kernel has used a variant of RFC1948 by default since 1996. Please see:
http://lxr.linux.no/source/drivers/char/ChangeLog#L258
http://lxr.linux.no/source/drivers/char/random.c#L1855

Finally we use Linux as a firewall, not Cisco/OS, and I don't know why are they bugging us???

Oh, by the way the kernel in use is 3.10.0-1062.1.2.el7.