Nmap Development mailing list archives

Re: GSOC 2012


From: David Fifield <david () bamsoftware com>
Date: Thu, 22 Mar 2012 12:03:51 -0700

On Thu, Mar 22, 2012 at 06:49:36PM +0530, SAI LAKSHMI Bhavana wrote:
It is true that it would be easier to implement and test for proxy in
Nsock rather than a port scan.

My idea is to make a TCP connection to a http proxy using
nsock_connect_tcp(), creating a new ms_event.
Then send a Connect request to the proxy regarding the target to be
scanned using the standard send().

No, I think this is the wrong model. We would not use the send system
call; that's breaking the abstraction that Nsock provides. Also, the
application should not have to do an nsock_connect_tcp to the proxy
address--Nsock should handle that internally, once you have set the
proxy chain on the Nsock pool or IOD. Rather, you do an
nsock_connect_tcp to the *end host*, and Nsock transparently does the
chain of proxy connections, only informing you of success or failure
when it is finished. (We may also add new callbacks to report
intermediate proxy success, but the point is that you should not have to
make a connection and wait for a SUCCESS for each proxy that you are
using.)

There will necessarily be another function, call it
nsock_connect_tcp_primitive, that only does a standard TCP connect and
doesn't obey any proxy chain. This function can be used internally by
Nsock in order to implement nsock_connect_tcp, which uses proxies. But
in this case it will be Nsock itself registering callbacks for the
intermediate connections, not the application. (Also there could be
other ways to implement it.)

A successful reply(200 CONNECTION ESTABLISHED) is expected for a open
port otherwise its marked closed.

This is true and it seems that you are on track with your thinking. But
for me, the details of how a particular proxy reports success or failure
are not interesting and not worthy of much discussion in your proposal.
(The exception would be if you had some clever way to distinguish open
from closed ports by measuring timing, for example. But I think all the
proxy types we are considering make this straightforward.)

And remember, at this point we are only talking about Nsock, not the
port scanning engine. (The port scanning engine doesn't use Nsock.) So
it doesn't make sense to talk about marking ports open or closed. Rather
your use case for this scenario should be: the NSE script banner.nse
needs to make a TCP connection, and Nsock should make this connection
automatically happen over the configured proxies.

If the proxy is a part of chain proxy then the request will be
forwarded accordingly by the proxies itself.
I would be pleased if told more about the implementations regarding chain proxy.

You must build up the chain step by step. If proxy1:8080 is an HTTP
proxy and proxy2:3128 is a SOCKS4a proxy, and you want to connect to
host3:23, then first you connect to proxy1:8080 and send "CONNECT
proxy2:3128 HTTP/1.0", then through this first tunnel you send the
SOCKS4a request "\x04\x01\x17\x00\x00\x00\x00\x01\x00host3\x00", then
you have Nsock report success if this last proxy request is successful.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: