Nmap Development mailing list archives
Re: Scripts for proxy detection
From: Joao Correa <joao () livewire com br>
Date: Wed, 3 Jun 2009 03:26:03 -0300
David, I agree that only receiving a "Request Granted" from the server is already enough to determine that the proxy is open. Anyway, I don't know how is the usual behavior of world coffee shop proxies. In Brazil the Coffee Shops use to require that you authenticate on a web page, just like you mentioned. If this happens, doing the HTTP request will return the same result as only doing the proxy handshake (which is someway a false-positive). Such proxies here use to be transparent, and I never had to setup a proxy while using the computer on it. We could go back and look for another google's header string, what could precisely determine if the proxy is really open (and we can reach google), but it would not work with argument passed urls. Except for the case of the Coffee Shops, I don't think that making a request contributes much more than only trying to do the handshake. For this reason I've removed the HTTP request from the script. On Mon, Jun 1, 2009 at 5:47 PM, David Fifield <david () bamsoftware com> wrote:
On Thu, May 28, 2009 at 05:17:43AM -0300, Joao Correa wrote:I'm posting two new versions for the open proxy detection scripts. The new features are: HTTP: * Changed pattern for connect (tested and supporting both polipo and ncat, needs to test on squid!) * Default test address is now nmap.org, and not www.google.comI see that you have already changed it back to www.google.com. I think that is a better default too. I did a search and that is what is used by the ScanSSH proxy detector too (http://monkey.org/~provos/scanssh/).* HTTP status codes 200, 301 and 302 are recognized as valid responses, meaning that the proxy is correctly working * It is also possible to use a different test address, specified with script-args. The args should be "url", with the url that might be tested and "hurl" with the url used to set the "Host:" field of the HTTP requests. If no hurl is set, than url is used as hurl. If none is set, nmap.org is used.I can see why you have a separate url and hurl; it's because you may want to make a proxy connection to http://example.com/dir/file.html (url), but then the Host: header field has to be just "example.com", not "example.com/dir/file.html". But you should do that work in the script, and not make the user do it. There are functions in the url module that will make this easy. http://nmap.org/nsedoc/modules/url.html Now that I look back at it, there's no way to access a URL like http://example.com/dir/file.html in socks-open-proxy.nse, because the code will try to resolve the name "example.com/dir/file.html" as if it were a host name. I take back what I wrote in http://seclists.org/nmap-dev/2009/q2/0523.html; you should keep the script argument name "url", allow it to be followed by a path, and use the url module to parse out the host name.
Since the socks-open-proxy.nse is not going to execute the third step anymore (doing the HTTP Request over the proxy connection, as mentioned at: http://seclists.org/nmap-dev/2009/q2/0523.html), it makes no sense to receive a full URL as an argument. The only needed information for the script will be the hostname, used to determine its IP address. As no HTTP Request is going to be made, having a url such as url.com/path/path/path won't be any better than having only url.com, the path won't be used for nothing. For this reason I'm not using the URL lib you mentioned.
Questions: Should we include new HTTP status codes?I think the ones you have are good.Should we remove POST from the HTTP open proxy tests? (as mentioned by David in his previous e-mail)I recommend this, especially now that I see it requires a separate script argument for a POST-able URL. I guess it would be possible for a proxy server to support POST but not GET or HEAD, but it wouldn't be very useful. Enumerating the methods supported by an HTTP server or proxy would best be done in a separate script.Socks script only tests a connection to the destination's port 80. Should we include more ports? If yes, how should we parse the responses? (we'll have different responses from each service)See my question in http://seclists.org/nmap-dev/2009/q2/0523.html. I don't know much about SOCKS, but perhaps "Request granted" is enough without sending any application-level data.
Sending some data during the "socks handshake" is needed. Some important data are the port and the IP address you want the proxy to connect you to.
David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Scripts for proxy detection Joao Correa (May 23)
- Re: Scripts for proxy detection David Fifield (May 26)
- Re: Scripts for proxy detection Joao Correa (May 26)
- Re: Scripts for proxy detection Joao Correa (May 28)
- Re: Scripts for proxy detection DePriest, Jason R. (May 28)
- Re: Scripts for proxy detection David Fifield (Jun 01)
- Re: Scripts for proxy detection David Fifield (Jun 01)
- Re: Scripts for proxy detection Joao Correa (Jun 02)
- Re: Scripts for proxy detection Joao Correa (Jun 09)
- Re: Scripts for proxy detection David Fifield (Jun 09)
- Re: Scripts for proxy detection Joao Correa (May 26)
- Re: Scripts for proxy detection David Fifield (May 26)