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
mednetAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
btanConnect With a Mentor Exec ConsultantCommented:
Even if remote admin is disabled per se. The vulnerability still exist and it is always (if possible w/o impact) upgrade to patch the "holes" when the Principal declared it is affected. We cannot live in false sense of security - not seeing make it tougher but not impossible to exploit. Balance the risk of exposure and businesses...minimally the harden state must stand fortified

If you see your queries are addressed at least in the Sonicwall context, you can close as deemed fit. Subsequent new question can be created on the new environment or issues faced. I respect your decision.
0
 
giltjrCommented:
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.
0
 
mednetAuthor Commented:
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?
0
Firewall Management 201 with Professor Wool

In this whiteboard video, Professor Wool highlights the challenges, benefits and trade-offs of utilizing zero-touch automation for security policy change management. Watch and Learn!

 
btanConnect With a Mentor Exec ConsultantCommented:
It is strange that CVE 2014-0224 is flagged for TZ as Dell declared otherwise and they have stated this
Dell SonicWALL firewalls (TZ, NSA, E-Class NSA, SuperMassive) and Global Management System (GMS) are NOT affected by the vulnerabilities.
Note: If you are planning to run a PCI Audit test, you'd better to upgrade the firmware to these latest versions (5.9.0.6, 6.1.1.9 and 6.2.0.0) before running the test. If you are running firmware version 5.8.1.15 or any of the lower versions of 5.8, please call technical support to obtain a build which has this change.
https://support.software.dell.com/kb/sw11605

Likwise also for the short key length. It should be supporting 2048 bits above instead of 1024 which has since newer firmware should be already doing that as stated in https://support.software.dell.com/kb/sw10667

For sending in login info in clear instead of encrypted is suspicious but it is better to capture from your browser (like Chrome developer mode or FFF developer panel) on the access to the login page to see if HTTPS is established even before the login keyed...there are also symptoms pertaining to PCI scan on certificate issue that will be handy if encountered..https://support.software.dell.com/kb/sw10322
0
 
btanExec ConsultantCommented:
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
0
 
giltjrConnect With a Mentor Commented:
I would verify that you are running at the level you think.

Is the SSL failure on the TZ200's managment interface?

Or, as btan is asking, s it on another host that the TZ200 is performing NAT for.  If it is a host that the TZ200 is NAT'ing for, then you need to get a new/upgraded SSL cert for that host.
0
 
mednetAuthor Commented:
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.
0
 
btanExec ConsultantCommented:
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
0
 
mednetAuthor Commented:
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.
0
 
giltjrCommented:
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.
0
 
btanExec ConsultantCommented:
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
0
 
Blue Street TechLast KnightsCommented:
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?
0
 
mednetAuthor Commented:
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.
0
 
mednetAuthor Commented:
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.