Link to home
Start Free TrialLog in
Avatar of mednet
mednetFlag for United States of America

asked on

Trustwave PCI scan failed on a Sonicwall TZ200 with the latest firmware

We have a client that has a third party (Trustwave PCI) run a vulnerability scan on their WAN address. The router / firewall device is a Sonicwall TZ200 with the latest firmware (SonicOS Enhanced 5.9.0.7-17o). According to the report from Trustwave, the device has an OpenSSL version that is vulnerable to a man in the middle attack. This was "detected" on ports TCP/443 and TCP/9999. The SSL Certificate Public Key is too small as well. The report goes on to further state that the device hosts a web application that transmits login credentials without encryption (TCP/80). I have since disabled the remote management as well as logging in with just HTTP credentials. Please see attached redacted images for details of the failures.

P.S. - The client uses only one outside IP address. They also do not have a web server, email server or ftp server onsite.
trustwave-asv-report-12-18-14---P4.png
trustwave-asv-report-12-18-14---P12.png
trustwave-asv-report-12-18-14---P13.png
trustwave-asv-report-12-18-14---P14.png
trustwave-asv-report-12-18-14---P15.png
Avatar of giltjr
giltjr
Flag of United States of America image

Have you checked with Sonicwall as to their status on the OpenSSL vulnerability?

Is the SSL key the one that came with the device?  If so, then again check with Sonicwall.

If the SSL key is something you purchased, then you need to look at when you can upgrade the key to 2048bit.
Avatar of mednet

ASKER

According to this site, I have the required firmware version. I will however check with Sonicwall to verify the status of the OpenSSL vulnerability.

Where would I find the SSL key? Is this the same as the SSL VPN Server settings?
SOLUTION
Avatar of btan
btan

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of btan
btan

if TZ is doing SSL termination fronting the website then likely it is serving the SSL server cert on behalf of the web server, else it should be transparent passthru to web server. I doubt the PCI is via SSL VPN channel unless that is really being done https://support.software.dell.com/kb/sw9053
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of mednet

ASKER

I reviewed the link provided by btan and have included the firmware version of the Sonicwall. It appears that the version is up to par with the article. Also since the client is not running a website I would think SSL termination should not be an issue.

However while typing this response, I failed to mention that the firewall has a rule that allows remote access to the ESXi server (this is to allow us to monitor the server). Thanks to giltjr's and btan's post I realized this may be the reason behind the PCI Scan issue. Reviewed the firewall rules and found that TCP/9999 is pointing to the ESXi server which is running ESXi version 5.1. This needs to be upgraded to the latest version of ESX. This is possibly the cause for the scanning failure. I'll update this thread accordingly.
thanks keep us posted and with regards to the CVE 2014-0224, you can find more the VMWare patch info for 5.1 is ESXi510-201406401-SG
2014-06-17 VMSA-2014-0006.2
Updated security advisory in conjunction with the release of ESXi 5.1 updates, VDDK 5.5.2, 5.1.3, and 5.0.4 on 2014-06-17
@ http://www.vmware.com/security/advisories/VMSA-2014-0006.html
Avatar of mednet

ASKER

OK so here's an update. I used GRC Shield's Up to test the following:

1. Disabled any RDP access to anything internally.
2. Reconfigured web access to the Sonicwall. (Disabled WAN access - Remote Management, Changed the port from 80 / 443 to port 8080 / 4443)

As a result, GRC, reported that ports 80 and 443 were now in "stealth" mode. Port 3389 (RDP Sessions) was also in "stealth" mode.

Resubmitted a Trustwave PCI scan and the results were still failing. It still claims that ports 80 and 443 are still passing login information. Not sure where to go from here. We are in the process of quoting the client a replacement device (Watchguard XTM33) so maybe this will no longer be an issue. I'll update the thread as soon as I find out something.
from the Internet try accessing:

http://x.x.x.x/auth1.html
http://x.x.x.x/auth.cgi

Where x.x.x.x is any and all public IP addresses within your public IP address range.

If the only thing you have listening on port 80 is the management interface for the firewall, I would suggest you disable http for management.
agree port 80 is in clear traffic and not recommended for management, in fact by default the sonicwall should not have it as default configuration if it is hardened state (below is one pdf on configurations based on PCI requirements). Minimally, it is https or even via RADIUS for user authentication prior to management portal access. There is past PCI compliance paper in Requirement  2.3 (below) for sonicwall and it stated one for compliance
Encrypt all non-console administrative access. Use technologies such as SSH, VPN, or SSL/TLS (transport layer security) for web-based management and other non-console administrative access
http://www.sonicwall.com/us/shared/download/SonicWALL-PCI-Implementation-Guide-for-SonicOS-Enhanced.pdf

Also I understand that Sonicwall has the "Detection Prevention" configuration like "Enable Stealth Mode" and "Randomize IP ID" which we can enabled (if not done so). It may not directly be for the management
http://help.mysonicwall.com/sw/eng/281/ui1/6600/Access/Services.htm
To further emphasis the point @btan made; setting up a SonicWALL with Enable Stealth Mode & Randomize IP ID are a must. In fact I'm not sure why they don't come straight from the factory like this.

All of our firewalls (all SonicWALLs TZs to NSAs) are currently passing the same tests. Have you given a call to SonicWALL yet?
Avatar of mednet

ASKER

Update:
I was not able to access the firewall using the addresses that were provided by giltjr. So that lets me know that the remote management feature is turned off. I did enable Randomize IP ID as well as Stealth Mode within the firewall.

Diverseit - I have not called Sonicwall due to the fact that the unit is out of warranty. The client is willing to consider upgrading to the Watchguard unit.

Btan - we are still needing to do the patch to ESXi 5.5 but since we have disabled the remote access this is no longer an issue at the moment.

Not real sure if I need to keep this thread open until after we have installed the Watchguard or not. Please advise.
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of mednet

ASKER

Closing the thread because the issue was partially resolved. Trustwave PCI was still detecting ports TCP/80 and TCP/443 being open even after having the remote management services disabled. The client has agreed to replace the Sonicwall with a new Watchguard firewall appliance.

Splitting the points between btan and giltjr.

Thanks for your assistance on this issue.