Re: [NSE] firewalking

[Henri Doreau <henri.doreau () gmail com>]

Hello,

thank you for testing and for the feedback.

2010/8/26 David Fifield <david () bamsoftware com>

> It appears that the script only uses traceroute results in order to
> calculate the TTL to send. You could remove the requirement to use
> --traceroute if you provide another script argument, firewalk.ttl, that
> lets you set it directly. firewalk.gateway can remain as an alternate
> way when --traceroute is available.
Yes, this is a good idea, I'm working on the suggested improvements and hope
to have a new version ready to send soon.


> I tested against scanme.nmap.org and skullsecurity.org and got different
> results. No ports were forwarded in one case and all ports were
> formatted in the other. Is this expected?
I can obtain the same results from the original firewalk tool (command line:
 firewalk -i eth0 -pTCP -S 21-23,25,80,110,139,443,445,3389 69.36.239.221
scanme.nmap.org)

We know that a port is forwarded if we get an ICMP time exceeded reply to
our probe. But if the probe timeout, then we can't conclude whether it is
forwarded or not by this gateway. We just know that a dropped probe will
timeout.


>  Because the script tests every filtered port, it will be slow when there
> are many filtered ports. I think it's okay in this case because you have
> to supply a special script argument to activate the script. It also
> doesn't make sense to run this script against more than one target at a
> time unless they have a gateway in common.
>
> David Fifield

The scan is slow because performed sequentially, without any parallelism.
I'm thinking about another way to implement the feature. I still have to
think how that could be done, but maybe something like a new hybrid
portscan/traceroute technique, or just pseudo parallelization with lua
threads... This could even remove the need for the gateway address, and
simply and quickly discover ACLs for every gateway on the route, and of
course speed up the scan.

I'm looking for ideas and suggestions about this, I'm sure that nmap hackers
will have a lot!
> From October, I'll have a school programming project, in which I would like
to try to implement such a thing if I find out a nice approach.


Regards

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