As some of you may be aware I'm attempting to secure a 2850 for PCI/DSS compliance.

I seem to have overcome most of the problems now, but two have stumped me.

This is the first of the two.

Seems like this problem was known about back in 1999 as Microsoft patch Windows NT4 to correct. Therefore I can not believe that it's any of the servers behind the firewall (all wIndows based the oldest of which is win7) so my starting assumption is this is somehow being generated by the 2850, which is running 3.6.8.2 (the highest generally available patch version, I believe).

Unfortunately I can't find any reference to this vulnerability in the draytek forums...

Does anyone know anything about this problem?

Thanks in advance
Iain

Has anyone got any ideas about this?

This is now my last remaining problem to achieve PCI/DSS compliance.

According to Microsoft the identified and fixed this problem in 1999
According to Cisco they identified and fixed this problem in 2001.

DrayTek do you have any comments or does silence mean you're not interested in companies that use credit cards (you could be several limiting your market)?

I've no idea the scan is correct - i.e. if they are using predictable sequence numbers.. I suggest you get more information with specific logs from your testing company which demonstrates it and then send to DrayTek support. Lots of companies get their systems PCI/DSS passed so something's different with your tester.

does silence mean you're not interested in companies that use credit cards

Being sarcastic on here won't get an answer

Fair point, just a little frustrated, apologies.

I have contacted support to see what they have to say.

Iain

The testing companies report is as follows:

VULNERABILITY DETAILS
CVSS Base Score: 7.5 AV:N/AC:L/Au:N/C:P/I:P/A:P
CVSS Temporal Score: 5.8 E:POC/RL:W/RC:UC
Severity: 2
QID: 82005
Category: TCP/IP
CVE ID: CVE-1999-0077, CVE-2000-0328, CVE-2000-0916, CVE-2001-0328
Vendor Reference: MS99-046
Bugtraq ID: 2682
Last Update: 10/30/2015
THREAT:
This server uses TCP/IP implementation that respects the "64K rule", or a "time dependent rule" for generating TCP sequence numbers.
Unauthorized users can predict sequence numbers when two hosts are communicating, and connect to your server from any source IP address.
The only difference with a legitimate connection is that the attacker will not see the replies sent back to the authorized user whose IP was forged.
IMPACT:
The Initial Sequence Number (ISN) used in TCP/IP sessions should be as random as possible in order to prevent attacks such as IP address
spoofing and session hijacking.
If the ISN of an existing or future TCP connection can be determined within some practical range, a malicious agent may be able to close or hijack
the TCP connections. If the ISNs of future connections of a system are guessed exactly, an agent may be able to "complete" a TCP three-way
handshake, establish a phantom connection, and spoof TCP packets delivered to a victim.
SOLUTION:
You may need to upgrade your Operating System to change the behavior of your TCP/IP stack regarding this problem.
This cert advisory describes how to fix this issue : CA-2001-09
For Microsoft systems you can apply this patch : MS99-046: How to Prevent Predictable TCP/IP Initial Sequence Numbers
For Cisco IOS systems you can apply this patch : cisco-sa-20010301-ios-tcp-isn-random: Cisco IOS Software TCP Initial Sequence Number
Randomization Improvements
RESULT:
Constant changes in initial sequence numbers observed in 18 out of 23 events.
[ Sent Packets Results ]
Packet 1 : TIME[1454417732.653663] SEQ[3977346593] CHANGE[N/A] VARIATION[N/A]
Packet 2 : TIME[1454417732.658651] SEQ[3910237729] CHANGE[67108864] VARIATION[N/A]
Packet 3 : TIME[1454417732.663648] SEQ[3910237729] CHANGE[0] VARIATION[67108864]
Packet 4 : TIME[1454417732.668648] SEQ[3977346593] CHANGE[67108864] VARIATION[67108864]
Packet 5 : TIME[1454417732.673647] SEQ[3977346593] CHANGE[0] VARIATION[67108864]
Packet 6 : TIME[1454417732.678649] SEQ[3953229332] CHANGE[24117261] VARIATION[24117261]
Packet 7 : TIME[1454417732.683649] SEQ[3953229332] CHANGE[0] VARIATION[24117261]

Will post remaining log separately as it's to big for this entry in one go

Packet 8 : TIME[1454417732.688648] SEQ[3986783765] CHANGE[33554433] VARIATION[33554433]
Packet 9 : TIME[1454417732.693648] SEQ[3986783765] CHANGE[0] VARIATION[33554433]
Packet 10 : TIME[1454417732.698647] SEQ[3919674901] CHANGE[67108864] VARIATION[67108864]
Packet 11 : TIME[1454417732.703647] SEQ[3919674901] CHANGE[0] VARIATION[67108864]
Packet 12 : TIME[1454417732.708647] SEQ[3986783765] CHANGE[67108864] VARIATION[67108864]
Packet 13 : TIME[1454417732.713646] SEQ[3986783765] CHANGE[0] VARIATION[67108864]
Packet 14 : TIME[1454417732.718646] SEQ[3936452118] CHANGE[50331647] VARIATION[50331647]
Packet 15 : TIME[1454417732.723647] SEQ[3936452118] CHANGE[0] VARIATION[50331647]
Packet 16 : TIME[1454417732.728650] SEQ[3986783765] CHANGE[50331647] VARIATION[50331647]
Packet 17 : TIME[1454417732.733648] SEQ[3986783765] CHANGE[0] VARIATION[50331647]
Packet 18 : TIME[1454417732.738665] SEQ[3919674901] CHANGE[67108864] VARIATION[67108864]
Packet 19 : TIME[1454417732.743646] SEQ[3919674901] CHANGE[0] VARIATION[67108864]
Packet 20 : TIME[1454417732.748646] SEQ[3986783765] CHANGE[67108864] VARIATION[67108864]
Packet 21 : TIME[1454417732.753646] SEQ[3986783765] CHANGE[0] VARIATION[67108864]
Packet 22 : TIME[1454417732.758647] SEQ[3953229332] CHANGE[33554433] VARIATION[33554433]
Packet 23 : TIME[1454417732.763647] SEQ[3953229332] CHANGE[0] VARIATION[33554433]
Packet 24 : TIME[1454417732.768647] SEQ[3977346593] CHANGE[24117261] VARIATION[24117261]
Constant changes in initial sequence numbers observed in 20 out of 23 events.
Packet 1 : TIME[1454417809. 41295] SEQ[4115098587] CHANGE[N/A] VARIATION[N/A]
Packet 2 : TIME[1454417809. 46298] SEQ[4115098587] CHANGE[0] VARIATION[N/A]
Packet 3 : TIME[1454417809. 51280] SEQ[4140264412] CHANGE[25165825] VARIATION[25165825]
Packet 4 : TIME[1454417809. 56280] SEQ[4140264412] CHANGE[0] VARIATION[25165825]
Packet 5 : TIME[1454417809. 61280] SEQ[4140264412] CHANGE[0] VARIATION[0]
Packet 6 : TIME[1454417809. 66290] SEQ[4140264412] CHANGE[0] VARIATION[0]
Packet 7 : TIME[1454417809. 71279] SEQ[4115098587] CHANGE[25165825] VARIATION[25165825]
Packet 8 : TIME[1454417809. 76280] SEQ[4115098587] CHANGE[0] VARIATION[25165825]
Packet 9 : TIME[1454417809. 81279] SEQ[4115098587] CHANGE[0] VARIATION[0]
Packet 10 : TIME[1454417809. 86280] SEQ[4115098587] CHANGE[0] VARIATION[0]
Packet 11 : TIME[1454417809. 91279] SEQ[4157041630] CHANGE[41943043] VARIATION[41943043]

Great.. Well, as I'm unqualified to understand those logs, I've no idea what they show... other than the sequence numbers aren't sequential 'per se' but maybe there's some other predictable selection.