Nmap Development mailing list archives
Re: RFC: proxy support w/o target name resolution
From: Henri Doreau <henri.doreau () gmail com>
Date: Fri, 28 Dec 2012 14:04:45 +0100
Hi David, [re-adding dev@ to recipients] thanks for the suggestions. Some comments inline. 2012/12/24 David Fifield <david () bamsoftware com>:
On Fri, Dec 21, 2012 at 09:55:51PM +0100, Henri Doreau wrote:I'm currently working on making nsock able to tunnel TCP connections through chains of proxies. I have a working prototype[1] and would like to discuss some points and the general roadmap here. I chose the following, simple, approach to initially implement proxy support: - Caller first builds a proxy chain object from a string like "http://localhost:8080,socks4://someproxy.example.com:1234". This object can be shared and reused between nsock pools. - Caller then associates this object to a nsock pool. - All TCP connections that are requested on this pool are transparently relayed through the chain. It works fine for HTTP connect and socks4 (though I'd like to stress the fact that my implementation is experimental). A challenge I'm facing is the addition of protocols that let you specify a target hostname, so that you don't have to resolve its name locally (typically: socks4a). This is essential when operating under restricted network conditions.First, I think we should merge and deploy what you have implemented so far, even though it leaks DNS. Name resolution through a proxy is trickier and I'm afraid to get stuck in it.
Sounds wise. I'll focus on making the existing code production ready then. HTTP authentication support can also be postponed for now I think. Let's validate the base layers first.
Hooking the nsock TCP connect function is convenient (because it's totally transparent) but this function takes a struct sockaddr and not a string as a target specification parameter. I see several options. One is to change the prototype of the function to make it take a string as parameter (which I sort of dislike). Another one is to build a name resolution system within nsock, which would be helpful anyway, and change its behavior on demand. According to what the proxy chain looks like, it could replace actual name resolution by the generation of a hash. This hash would be recognized as such by the TCP connect function, that would then use the hostname instead when communicating with the proxy.On-demand name resolution through Nsock is probably better for efficiency. Brandon had to invent a local DNS caching hack when we were doing the favicon scans, because sequential name resolution was a huge bottleneck.
Ok, this would be a second step then.
We could invent a structure that is a subset of what Target holds. Basically, a host name and an IP address. Either field could be omitted. If we are doing all name resolution through a proxy, the IP address will never be filled in; the host name is the only information we will give the proxy. Then there can be convenience functions, one like the current nsock_connect that takes a sockaddr, and another that takes a string that is a host name (or string representation of an IP address).
Yes, I like this approach. If I understand correctly what you're proposing, the target object should be defined and managed by the caller, right? What about having a semi-opaque nsock_target object that would be passed to the library (à la nsock_iod)? I'd find this nicer. Any pro/con?
There are some difficulties. We want to eventually replace the connect scan with one implemented using Nsock. If I want to scan scanme.nmap.org/24 it isn't possible without resolving the address. If we're in a strict "proxy resolves" mode, then we have to show an error in this case. If we're in a "just make my scan work" mode, we might choose to resolve the address locally and then feed the 256 IP addresses to the proxy.
Indeed, these aren't trivial tasks but I see no blocker at least. How to use different proxy chains (to balance the load or for resiliency) is also challenging and undefined yet.
David Fifield
Regards -- Henri _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- RFC: proxy support w/o target name resolution Henri Doreau (Dec 21)
- Message not available
- Re: RFC: proxy support w/o target name resolution Henri Doreau (Dec 28)
- Message not available