Nmap Development mailing list archives
Re: softmatch for http
From: Till Maas <opensource () till name>
Date: Wed, 18 Sep 2013 09:07:25 +0200
Hi Fyodor, 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.[01] \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? Regards Till _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- softmatch for http Till Maas (Sep 13)
- Re: softmatch for http Fyodor (Sep 17)
- Re: softmatch for http Till Maas (Sep 18)
- Re: softmatch for http Fyodor (Sep 17)