Re: general scanning engine - request for comments :)

[majek04 <nmap () forest one pl>]

Hi!

doug () hcsw org wrote:
> 1)
> Have you done much thinking about the way the user might interact
> with such a system? I could imagine replacing the -b switch
> with somthing like the following:
>
> nmap -b 'ftp:user:passwd () some-ftpd org:99|http-connect:open-proxy.com' target.com
>
> Which could create a chain through an FTP proxy and an HTTP proxy.
> Of course, any decision with respect to this is completely arbitrary
> and the syntax should be whatever is easiest to use.
Yes, the example you provided is exactly what I was thinking about.

Though, you can't tunnel connections through ftp, so better example would be:
nmap -b 'http-connect:open-proxy.com:8080|ftp-bounce:user:passwd () some-ftpd org:99' target.com

There is one small problem with authorization.
For example using http proxy you can use some different methods
of authorization, like default 'Basic' authorization and Microsoft's NTLM.

Hoverer, I think we can skip this problem now.

> 2)
> An extremely handy chaining type would be SSH. I'm not sure exactly
> how you to implement this. If you assume every box has nc on it,
> it could be easy. Otherwise, you could possibly perhaps an ssh tunnel
> to perform this.
>
> Every box I use has SSH and I doubt I would ever have boxes without
> SSH installed. However, some people might not and there's also the
> win32 users. We might decide this type of scan is impractical but
> I think it would be extremely cool regardless.

Good point! I must think how to handle this.
(I prefer the idea with 'nc' :)

> 4)
>
> Many people using this method are probably scanning under the assumption
> they will get maximum scanning privacy and sometimes a simple DNS request
> can give it away.
>
> I would suggest reverse DNS be disabled by default for all proxy scans.
>
> Some of these proxying methods can perform forward DNS resolution for us.
> The forward DNS could potentially be more complicated. If all of the
> links in the chain support DNS then, of course, we can keep passing on
> the lookups through the chain. If one of the nodes is unable to perform
> DNS lookups all the remaining DNS lookups will need to be done by Nmap.
> I think we should warn the user that this is the case.

Yes. The problem I see, is that I would like to add this proxy
scanning like any other scanning in nmap. You know, after
nmap is calling ultra_scan(), near nmap.cc:1536.

But nmap by default is resolving all hostnames.
Ultra_scan needs resolved hostnames, and proxyscanning won't need.

I would like to change as little code as possible in other parts of nmap.

> 5)
> In your mail you talked about performing service detection through
> a chain of proxys. This would be extemely cool! Do you think it would
> be possible to add the proxying functionality as some sort of addition
> to nsock? This would be a very useful addition to nsock and could
> potentially mean that a huge amount of (present and future) Nmap
> functionality could be proxied.
>
> Specifically, I'm thinking about some extra argument to
>
> nsock_connect_tcp()
>
> Call it, perhaps, struct nmap_chain. Ideally nsock_connect_udp()
> and nsock_connect_ssl() could accept chains as well.
>
> To me it makes sense to put this type of functionality into nsock
> as a method of abstraction. I might also like to use this type of proxy
> connection in my own separate programs.

No. I'm not thinking of changing anything in nsock.
But it would be quite easy to extract code needed
to build a chain from my program.



Now I'm reading nsock and I understood that proxy support
will be much more complicated than I previously thought.

I assumed that it's possible to use synchronous sockets
and than change them to asynchronous.
But nsock is fully asynchronous :)

I'll try to do everything asynchronous, unfortunately the code
will be much more complicated.

I'm creating some state-charts to help me with implementation.
example:
http://ai.pjwstk.edu.pl/~majek/private/nmap/sc-http-connect.png




Marek Majkowski


PS. Is it possible to break 'nsock_loop()' after first
event?



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev