Re: nmap udp scan takes too long

[pentester <pentester () surfhier nl>]

On Jul 12, 2012, at 4:06 AM, Fyodor wrote:

> On Thu, Jul 05, 2012 at 08:55:02AM +0200, pentester wrote:
> > I agree that nmap is a cool tool. It just ain't the right tool to do
> > a udp scan. The reason is that it waits for a response, if no
> > response, then it retries a couple of times. There is no need
> > to.
>
> Retransmissions are important for reliable results, because packet
> loss and response rate limiting are regular occurrences on networks.
> But if you really want Nmap to disable retransmissions, specify
> "--max-retries 0".
>
> > Another scanner solves this issue. unicornscan typically scans al
> > 64k ports in 3 minutes and 45 seconds when you use a scan rate of 300
> > packets per seconds
>
> 300 packets per second won't help if the target host rate limits ICMP
> port unreachable responses to one per second.  That is very common on
> Linux and other systems.  So 299 of your 300 packets per second are
> wasted and--even worse--lead to inaccurate results.  Unicornscan won't
> catch this because, as you note, it doesn't do any sort
> retransmissions or congestion control.

If you scan 64k ports and you receive no ICMP port unreachable messages at all, then your scan apparently didn't 
trigger such a response or the response is filtered elsewhere.
If you didn't trigger the response, then you didn't hit the rate limit of one per second either.
If the ICMP port unreachable messages are filtered somewhere, then decreasing the amount of packets per second won't 
help.
As a result, if you don't receive any ICMP port unreachable messages during a relative fast scan, then it is unlikely 
that you will receive them when doing a real slow scan.

Often a host is protected by a firewall and the firewall filters either the requests or the responses. As an expected 
result, more often than not you don't receive a lot of response at all. When you are scanning you can anticipate on 
such behavior. If you assume you won't receive responses at all because of filtering and you do a full udp port scan, 
the results will prove your assumption wrong and you can adjust your strategy. 
The advantage is that this approach saves you a lot of time.

> But if that is what you really want, Nmap lets you do it too.  Specify
> "--min-rate 300" for 300 packets per second.  Nmap's performance
> options are all documented at:
>
> http://nmap.org/book/man-performance.html
>
> I'm also happy to report that we released Nmap 6 in May, with hundreds
> of improvements as described at:
>
> http://nmap.org/6
>
> > unicornscan beats nmap as it comes to udp scanning. It's just a
> > matter of using the right tools for the job.
>
> Suit yourself.  Their latest was in 2007 and you can download it from
> http://www.unicornscan.org/

For most scanning purposes, nmap will be my first choice. But even though unicornscan is as old as 2007 and we perhaps 
don't expect new releases (Jack Louis -the author of unicornscan - died), I just think that unicornscan is the better 
tool if it comes to udp scanning. 

> Cheers,
> Fyodor

Cor


------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------