Unable to access City or State Sponsored Sites Behind a SonicWall firewall

03/26/2020 658 12904

DESCRIPTION:

Unable to access City or State Sponsored sites behind a SonicWall firewall

RESOLUTION:

Lately, users in certain localities have discovered that they no longer have access to certain city and state sponsored government-related sites, regardless of whether or not security services are enabled.

A packet capture will reveal that all packets are being forwarded, and yet the connection is not being established. Further scrutiny of the capture shows that although the SYN packet is being appropriately forwarded to the site, the initiator does NOT receive a SYN/ACK packet in response... merely an ACK packet, which violates the TCP handshake (SYN  >  SYN/ACK  > ACK).

As it turns out, the affected responses indicate that connections which follow the RFC 6528 to defend against Sequence Number Attacks, a method by which an attacker may interject themselves into a connection (Also known as a Man-In-The-Middle, or MITM attack), are being rejected.  Without the security measure the SonicWall puts in place as per the aforementioned RFC, an attacker may obtain ALL information passed between the two parties. However, WITH the security measure in place, no response is received.

RFC 6528 explains the need for TCP Sequence Randomization thusly:

 "An eavesdropper who can observe the initial messages for a connection can determine its sequence number state, and may still be able to launch sequence number guessing attacks by impersonating that connection. However, such an eavesdropper can also hijack existing connections [Joncheray1995], so the incremental threat is not that high. Still, since the offset between a fake connection and a given real connection will be more or less constant for the lifetime of the secret, it is important to ensure that attackers can never capture such packets. Typical attacks that could disclose them include both eavesdropping and the variety of routing attacks discussed in [Bellovin1989].  "Off-path attacks against TCP connections require the attacker to guess or know the four-tuple (localip, localport, remoteip, remoteport) that identifies the target connection. TCP port number randomization [RFC6056] reduces the chances of an attacker of guessing such a four-tuple by obfuscating the selection of TCP ephemeral ports, therefore contributing to the mitigation of such attacks..." 

This phenomenon, where users behind a secure SonicWall are unable to reach an affected site, has been observed recently with a number of city and state-sponsored sites.  At this time, the only known options are limited to the following options:

1.) Disable TCP Sequence Randomization on the firewall that is keeping the connection secure, or else
2.) Allow communication with the affected sites to fail until the site responds in an RFC compliant manner.

DISABLING TCP SEQUENCE RANDOMIZATION IS **NOT** RECOMMENDED BY SonicWall, AND CAN RESULT IN AN ATTACKER OBTAINING ALL DATA PASSED BETWEEN LOCATIONS.

Traffic to city and government sites within the US and the UK has recently been diverted to foreign countries by means of BGP configuration.  Allowing TCP Sequence randomization while traffic is being diverted may allow both local and foreign entities to view all traffic passed.  This information is referenced in the following articles.

http://arstechnica.com/security/2013/11/repeated-attacks-hijack-huge-chunks-of-internet-traffic-researchers-warn/

http://arstechnica.com/security/2015/03/mysterious-snafu-hijacks-uk-nukes-makers-traffic-through-ukraine/

If, despite the known risk of allowing an attacker to obtain all data, it is still desired to navigate to an affected site in a manner that is not RFC compliant, the following steps can be taken to disable TCP Sequence Randomization on the SonicWall NGFW:

Workaround:

Step 1:  Navigate to the /diag.html page of the firewall (located at https:///diag.html) and click the "Internal Settings" button
Step 2:  In the "Routing and Network Settings" section, Disable the checkbox "Enable TCP sequence number randomization".
Step 3:  Click "Accept".  Click "Close" on the left to return to the UI.

How to Test:

Attempt to access the site from behind the firewall.  You may also run another packet capture to ensure that after two or three (SYN  >  ACK) attempts, a SYN/ACK packet is finally provided in response completing the (SYN  >  SYN/ACK  >  ACK) handshake.