Dnsmasq found on SonicWall

When we scan public IP address, we are getting High (CVSS: 9.8), NVT: Dnsmasq <= 2.86 Multiple Vulnerabilities, with a more specific Vulnerability Detection Method, Checks if a vulnerable version is present on the target host. Details: Dnsmasq <= 2.86 Multiple Vulnerabilities OID:1.3.6.1.4.1.25623.1.0.147385 Version used: 2023-01-1210:12:15Z further down the page.

I can find the same result with an nmap {IP ADDRESS} -v -A -Pn -p 53

PORT STATE SERVICE VERSION

53/tcp open domain dnsmasq 2.83

| dns-nsid:

|_ bind.version: dnsmasq-2.83

I also tried to telnet {IP ADDRESS} 53, but got a connection refused.

My colleagues are asking how Greenbone Community is detecting this, dnsmasq, since 53 is not open (inside or outside) and what to do about it.

Thank you.

Hi and welcome to the community!

Not sure if I get this right: You wrote that you could verify the result via nmap but later state that port 53 is not open at all. So seems the latter statement is not correct as both Greenbone and nmap could connect to it and extract the version.

The banner extraction itself is done with a special TCP request (see “DNS Server Detection (TCP)” OID: 1.3.6.1.4.1.25623.1.0.108018 (dns_server_tcp.nasl)). If you want to run this directly and e.g. check via wireshark you can run e.g. openvas-nasl -X dns_server_tcp.nasl -d -t <ip>

Be aware that on some firewalls protocols like DNS needs to be handled separately/different than the usual filtering. However I don’t have any specific knowledge about SonicWall.

Hope this gives you some further info to dig into.

Christian

3 Likes

One additional important note:

The VT in question has a “low” ( < 70 %) Quality of Detection (QoD) not showing up by default in reports.

Please be aware that using a non-default filter will show VTs which are generally more false positive prone and for these the user is in the responsibility to verify the results manually (e.g. by contacting the vendor asking for vulnerability status of the product in question) and handle them adequately (e.g. creating an override, fixing the flaw on the device, …).

More reading about the QoD concept is available at the 11.2.6 Quality of Detection Concept section of the manual.

2 Likes

Thank you both for your replies. Yes, I did have the statements correct; Greenbone and nmap “see” the port, but telnet was giving me a disconnected response (I believe) but I AM able to connect to it this morning. Maybe try a dig to see if there is data or a response (I’m just thinking out loud)? I am / we are looking into how we can manage DNS on the external interface, since there does not seem to be a usual way to work with it on SonicWalls via the GUI or ssh cli interfaces.

As far as the QoD, yes, sorry about that. I should have offered I wanted to see everything that could “possibly” be wrong so I lowered it to 10%. Thanks for the URL, others have been asking about QoD and I will share it with them.

Thanks you both again. I really appreciate your time.

3 Likes