nmap vuln script detects vulnerability "Apache byterange filter DoS http-vuln-cve2011-3192" in Ubuntu Webserver, but apache2 not installed on server

I am running an Ubuntu 20.04 LEMP (Linux, Nginx, MariaDb, PHP) webserver. I am also doing some nmap vulnerability tests form my MacOS Client machine. On MacOS, I am using Oh My Zsh! with the nmap plugin enabled. To do some vulnerability tests on my Ubuntu Server from my MacOS client machine, I issued the command:

nmap_check_for_vulns my.server.ip.address

which is an alias command for

nmap --script=vuln

After issuing the command with my server's IP address, nmap reported the following:

| http-vuln-cve2011-3192:
|   VULNERABLE:
|   Apache byterange filter DoS
|     State: VULNERABLE
|     IDs:  CVE:CVE-2011-3192  BID:49303
|       The Apache web server is vulnerable to a denial of service attack when numerous
|       overlapping byte ranges are requested.
|     Disclosure date: 2011-08-19
|     References:
|       https://www.tenable.com/plugins/nessus/55976
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3192
|       https://www.securityfocus.com/bid/49303
|_      https://seclists.org/fulldisclosure/2011/Aug/175

On the Ubuntu Server, the output of ss -lnpt is:

State                     Recv-Q                    Send-Q                                       Local Address:Port                                         Peer Address:Port                    Process
LISTEN                    0                         100                                                0.0.0.0:25                                                0.0.0.0:*
LISTEN                    0                         511                                                0.0.0.0:443                                               0.0.0.0:*
LISTEN                    0                         4096                                             127.0.0.1:8125                                              0.0.0.0:*
LISTEN                    0                         100                                                0.0.0.0:4190                                              0.0.0.0:*
LISTEN                    0                         4096                                             127.0.0.1:19999                                             0.0.0.0:*
LISTEN                    0                         100                                                0.0.0.0:993                                               0.0.0.0:*
LISTEN                    0                         4096                                             127.0.0.1:10023                                             0.0.0.0:*
LISTEN                    0                         4096                                             127.0.0.1:10024                                             0.0.0.0:*
LISTEN                    0                         100                                              127.0.0.1:10025                                             0.0.0.0:*
LISTEN                    0                         4096                                             127.0.0.1:10026                                             0.0.0.0:*
LISTEN                    0                         80                                               127.0.0.1:3306                                              0.0.0.0:*
LISTEN                    0                         100                                                0.0.0.0:587                                               0.0.0.0:*
LISTEN                    0                         128                                                0.0.0.0:43211                                             0.0.0.0:*
LISTEN                    0                         511                                              127.0.0.1:6379                                              0.0.0.0:*
LISTEN                    0                         4096                                             127.0.0.1:783                                               0.0.0.0:*
LISTEN                    0                         100                                                0.0.0.0:143                                               0.0.0.0:*
LISTEN                    0                         511                                                0.0.0.0:80                                                0.0.0.0:*
LISTEN                    0                         4096                                               0.0.0.0:10000                                             0.0.0.0:*
LISTEN                    0                         100                                                0.0.0.0:465                                               0.0.0.0:*
LISTEN                    0                         128                                                0.0.0.0:43219                                             0.0.0.0:*
LISTEN                    0                         256                                                0.0.0.0:53                                                0.0.0.0:*

I am trying to close this vulnerability on the server, however, I do NOT have apache installed on the server, So I don't know why this vulnerability is showing up!

My question is, how do I find the program thats vulnerable, and how do I then close the vulnerability on the server?

The ancient check is not specific to apache2, it is only specific to one particular approach of mitigating such DoS surface on apache2. Nginx does not employ it: it does fulfil requests for large numbers of separate ranges by default, only subject to header size limits. This in theory it (or anything being forwarded the header as-is) could be vulnerable to excessive resource use on odd requests.

max_ranges number;
Default:  —
Context:  http, server, location

This directive appeared in version 1.1.2.

Limits the maximum allowed number of ranges in byte-range requests. Requests that exceed the limit are processed as if there were no byte ranges specified. By default, the number of ranges is not limited. The zero value disables the byte-range support completely.

Its just nowhere as big of a problem as that particular trick that could be used to overload Apache servers. As long as your nginx is not proxying (or depending on serving most requests from cache instead of proxying) somewhere else, you will likely not need to do anything, even if you do not specifically add restrictions using that setting.

These days, web servers (that received maintenance after 2011) simply disregard requests for ranges the size-sum of which exceeds the total content length - something with little real-world application, so an even better mitigation than limiting the number of ranges.

In any case.. you can just hand-craft such annoying request from the command line. The whole exploit is sending a request with a header with something in the order of hundreds of overlapping ranges like Range: bytes=1-1337,1-1338,1-1339 and so on. Watch whether the response (with status 206; if you see 200 nginx has just ignored your header and returned everything) was significantly slower, then you will know for certain.

Check with ss -lnpt which process is listening on port 80 or 443, that is most likely the target.