Re: [ncat][RFC] Ability to control hostname resolution for proxy

nnposter <[email protected]> Fri, 25 Jan 2019 12:01:06 -0700
Newsgroups gmane.comp.security.nmap.devel
Message-ID <[email protected]>
On 1/25/19 11:05 AM, David Fifield wrote:
> On Fri, Jan 25, 2019 at 09:57:03AM -0700, nnposter wrote:
>> Back to my proposal, what would be your vote?
>> (1) ignore; do nothing
>> (2) proceed with it
>> (3) the feature should be somehow supported but not this way
> 
> I think I would choose (1), (2), (3) in order of preference. But I don't
> know what the desired use case for local resolution is.
> 
> About (3), it would in general be nice to have something in Nmap where
> you can say, "use this IP address, but pretend it has this DNS name."
> For example when running http-* scripts, a name may resolve to 5
> addresses, but you are only interested in a specific one of them, but
> you still need a DNS name to make virtual hosting work. I think the best
> way to fake it in general is to use an /etc/hosts file, which of course
> implies local resolution. In the http case, there's the http.host script
> arg, but it's global. If there were some mechanism like that for Nmap,
> Ncat could use it as well. But obviously that's a big design question
> and would take time to develop, which is why I wouldn't necessarily
> choose option (3) over (2).

There are currently two GitHub tickets asking for local resolution:

https://github.com/nmap/nmap/pull/1214
https://github.com/nmap/nmap/issues/1230

The common theme is that the proxy server cannot resolve the destination 
but the Ncat host can.

My proposal preserves the current Ncat behavior unless the new 
--proxy-dns option is used. In other words, "--proxy-dns remote" is the 
default. This means that there is no direct downside with (2) over (1) 
unless you object to the approach or just the additional code in general.

With respect to (3), I can imagine that on Ncat level there could be 
something like "--proxy-dns file", representing a private /etc/hosts 
file. That said, in Ncat connect mode there is no protocol opportunity 
to pass along both the hostname and the IP address (e.g. no HTTP 
headers) so IMHO there is limited value in this feature over resolving 
those hostnames upfront, before invoking Ncat.
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/