general scanning engine - request for comments :)

[majek04 <nmap () forest one pl>]

Hi, guys

While waiting for decisions about some performance stuff,
I took some time and thought about next task.
Fyodor calls it: 'general scanning engine for abusing applications
for port scanning purposes'.
I prefer shorter name, just 'proxy support for nmap'.

I would like to hear your opinions :)

If you don't have time for reading my technical
ideas, please skip to point 4. I wrote there
more general thoughts.


1) AVAILABLE PROTOCOLS AND THEIR CHARACTERISTICS:

Columns:
'binary' - support for binary connections; tunneling
'dns'    - resolving dns names on remote site
'k-a'    - keep-alive; one connection, many probes

------------------|-binary-|-udp-|-dns-|-ipv6-|-k-a-
HTTPPROXY CONNECT-|---Y----|-----|--Y--|--?---|-----
HTTPPROXY GET-----|--------|-----|--Y--|--?---|--Y--
SOCKS 4-----------|---Y----|--Y--|-----|------|-----
SOCKS 4a----------|---Y----|--Y--|--Y--|------|-----
SOCKS 5-----------|---Y----|--Y--|--Y--|--Y---|-----
FTP BOUNCE--------|--------|-----|-----|------|--Y--
classic connect()-|---Y----|--Y--|--Y--|--Y---|-----

2) PROTOCOL INTERFACE METHODS

Every protocol must have these methods implemented:
(desc is alias for descriptor of course)

        /* CREATE CIRCUIT TO NEXT HOP
         * Present only if <binary> connections are supported.
         * This function would write some data to connection,
         * that would result in creating circuit to the next hop.
         * For example socks would add some binary header,
         * http proxy would add http headers like CONNECT. */
        desc connect(desc, host, port, protocol)

        
        /* QUERY SCANNED PORT
         * Always present, for every protocol. If <binary> connection
         * is supported this can be wrapper to 'connect' method.
         * If <binary> is unsupported, this method would
         * write some headers to connection, for example
         * http GET */
        query(desc, host, port, protocol)

        /* INTERPRET ANSWER
         * Always present, for every protocol. It answers whether port
         * is closed or opened. Also returning the reason would be nice.
         * For the beginning I can think of such possible port states:
         * OPEN, CLOSED(=timeouted), FILTERED(=forbidden)
         * this method would have special meaning only for protocols
         * that support keep-alive. I mean that if <binary>
         * is supported we always have to close connection (keep-alive
         * not present). If keep-alive is present we should interpret
         * received bytes. For httpproxyGET we should interpret
         * http error number, you know 404,501 or successful connection. */
        parse(desc)


3) EXAMPLE OF BUILDING A CHAIN
Let's imagine that we have array with protocols:
chain[]={CLASSICCONNECT, SOCKS, HTTPPROXY-GET}
/* classicconnect: I mean ordinary connect() method that
   would be seen as protocol. The idea is that
   this pseudo-protocol will create initial descriptor. */

        desc = NULL
        for(i=0; i<chain_elements-1; i++)
                desc = chain[i]->connect(desc, chain[i+1].host, chain[i+1].port)


And then basic, non parallel scanning could look like this:
        foreach(port in scanned_ports){
                if(chain is not built)
                        build chain.
                chain[chain_elements-1].query(desc, target, port);
                print chain[chain_elements-1].parse(desc)
        }
        
4) PROBLEMS AND FUTUREWORK
Dns resolving:
        Some protocols can resolve dns for us. For example we can
        send dns entry to http proxy.
        But by default all targets are resolved in main nmap's functions.
        There are also some cases when we need to resolve target locally.
        For example if user specifies google.com/28.
        I don't have clear idea how to handle these problems.

Ping probes:
        Normally nmap is doing ping probes before scanning.
        How such ping probes should look like when someone is using
        proxy/socks chaining?

Timing issues:
        The question is: how much time should we wait before saying
        that port is filtered. This can be complicated when we'll have
        many hops in chain.
        Again, I don't have clear concept how to handle this.

Service detection:
        Imagine Version Detection through TOR or other anonymous proxy.
        I think this could be really powerful tool.


        
        
Marek Majkowski


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