Re: general scanning engine - request for comments :)

[doug () hcsw org]

Hi Marek,

On Wed, Jul 12, 2006 at 09:49:37PM +0200 or thereabouts, majek04 wrote:
> I prefer shorter name, just 'proxy support for nmap'.

Agreed. :)

Let me first say that your ideas sound very solid and the system you
describe would be very powerful and a good replacement for the
venerable FTP bounce scan code.

I have a few comments/suggestions and I wish you and this project
the best of luck!



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.



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.



3)

Just in case some people thinking about the system think that chaining
proxys is only useful for the ultra paranoid, consider situations like
the following:

o Scanning through an open proxy behind an organisation's firewall

o Mapping IP trust relationships - a system like this would make it
  easy to upload a minimal socks4 proxy to a target and perform scans
  from its identity.

o Escaping your own ISP's port forwarding restrictions. I've used ISPs
  before that filter outbound port 25 - making it impossible to scan
  SMTP servers!



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.




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.


Sincerely,

Doug Hoyte



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