Data Leak
Shodan.io is a service that scans IP addresses and displays the results for ANYONE to see. When I search for Sonicwall, it returns almost 1 million records.
You can also search by IP address and if you have a Sonicwall, here is an example of what is returned:
SonicWALL firewall http config
HTTP/1.0 200 OK Server: SonicWALL Expires: -1 Cache-Control: no-cache Content-type: text/html; charset=UTF-8; X-Content-Type-Options: nosniff X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' blob: data: ws: wss:; SonicWall: SonicOS Version: 6.x Serial Number: 18B169EA1278
A hacker loves that it identifies itself and the major OS version. Its just a matter of looking up CVE's to find the right exploit.
Is there a way to prevent the firewall from identifying itself and leaking this data? I'm asking because we are trying to get cybersecurity insurance and this has lowered our score making us riskier.
Answers
Quickest way would be to disable SSLVPN service on WAN zone but you might find this annoys people who are using SSLVPN for remote access.
"Major Version" leakage is insignificant IMO. You can simply tell by the colour scheme [for example] whether you're looking at a Gen6 or Gen7 login prompt. If it says "Dell" you can further narrow it to a certain vintage [but if you're running a public facing service on ancient firmware then I'm apt to do a bit of "victim blaming" here].
Serial number being available is unnecessary, although a) it's the MAC so is visible to your nexthop regardless b) what use is it to an attacker?
Yep, the SSLVPN is needed. And our login page is customized to the point where it is not recognizable as a Sonicwall product.
I did a quick search for CVE's affecting Sonicwall OS 6 with a CVSS score of at least 5. There are 24. Using a framework like Metasploit, you could test all of them in minutes.
I've made a rule to block scans from Shodan and Censys, but the real fix is for the firewall to not identify itself. Which is a best practice when deploying a website.
https://owasp.org/www-project-secure-headers/#div-bestpractices
So have you created a support ticket or request for enhancement with Sonicwall?...
our login page is customized to the point where it is not recognizable as a Sonicwall product.
See, I wasn't going to bother with an elaborate reply originally, but you've forced my hand :-)
I don't think it's reasonable for Sonicwall to commit to keeping the page structure/resources/POST destinations/etc identical between releases as it means they would be constrained in what new features they could add or bugs they could fix.
What if there's a vulnerability in some part of the code that's served as the login page? You can't expect Sonicwall not to fix it on the basis that it discloses to an attacker that x.y+ version was installed.
So read "colour scheme" in my original reply as a synonym for all of the above.