mailing list archives
Re: softmatch for http
From: Till Maas <opensource () till name>
Date: Wed, 18 Sep 2013 09:07:25 +0200
On Tue, Sep 17, 2013 at 05:17:37PM -0700, Fyodor wrote:
Hi Till. We do have some softmatches for HTTP (e.g. if we at least see
that it is Apache), but as you note we commented out the one which just
looked for "HTTP/1. \d\d\d" in response. The problem is that when we
softmatch a protocol, Nmap version detection limits further searching to
probes which have at least one signature for that protocol. That is a
great optimization in most cases, but it doesn't work well for http because
so many other protocols use http as underlying transport. For example,
UPnP and some https servers will answer a GET request with HTTP/1.*, but we
don't want Nmap to then limit its search just to "http".
Is it maybe possible to add the same softmatch to the other HTTP like
probes as well? I noticed this behaviour when scanning an HTTP server
that disconnects after about 5 seconds and does not contain a server
header. After limiting the time for which nmap assumes a port to be
tcpwrapped (see my other patch), nmap only detected the port as "http?"
because of the port and not as "http". Since I wanted to use the scan
results in metasploit and be able to search to targets using 'services -u
-s http -c port', I investigated why nmap does not properly recognise
this obvious HTTP server.
I hope that there is a solution to this. So besides maybe adding the
softmatch to other protocols to allow other probes to be run, maybe it
can be moved to the end somehow to still find the server to be http,
when other probes did not match.
Other approaches that I can think of and are maybe good anyhow would be
to add a match that also matches for a text/html content type (and maybe
text/xml) or checks for a html tag in the response body. But this might
also match HTTPS servers that return a response when not using TLS. At
least Apache seems to not include a HTTP header then.
The next idea would be to allow for softmatches to determine multiple
protocols so that probing for UPnP can continue even if it is only
softmatched as http. What are your opinions on this?
Sent through the dev mailing list
Archived at http://seclists.org/nmap-dev/