Mailing List Archive: Nmap.nasl

Nmap.nasl

May 30, 2005, 4:58 AM

Post #1 of 6 (929 views)

Recent changes to nmap affects the time it takes to port scan a firewalled
host. This will in turn affect Nessus scans when nmap.nasl is used.

Reference: http://seclists.org/lists/nmap-dev/2004/Oct-Dec/0143.html (Nmap
Development: nmap-3.7x MUCH slower than nmap-3.55 against firewalled hosts)

The bottom line is that a port scan against a class C network may take days
instead of hours due to the way that nmap now handles ICMP unreachables.

The workaround for this issue is to pass additional parameters to nmap
namely (--max_scan_delay 0).

Neither nmap.nasl or the Nessus client (version 2.2.4) cater for this option
yet.

According to the nmap changelog, this option was first included with version
3.75

The changes to nmap.nasl are the following:

if (ver =~ "3.7[5-9]" || ver =~ "3.8")
{
script_add_preference(name: "Maximum wait between probes (ms)", value: "",
type: "entry");
}

p = script_get_preference("Maximum wait between probes (ms)");
if (p =~ '^[0-9]+$')
{
argv[i++] = "--max_scan_delay";
argv[i++] = p;
custom_policy ++;
}

Of course the option needs to be included in the client as well to be useful
for most people, but for those who use the command line version with custom
.nessusrc files, changes to nmap.nasl will help in the mean time.

Regards,

=======================================================
Herman Young Tel: +27 12 460 0880
SensePost Information Security Fax: +27 12 460 0885
http://www.sensepost.com | http://hackrack.co.za
=======================================================

Re: Nmap.nasl [ In reply to ]

mikhail at nessus

Jun 14, 2005, 1:46 AM

Post #2 of 6 (919 views)

Permalink

On Mon May 30 2005 at 13:58, Herman Young wrote:

> Recent changes to nmap affects the time it takes to port scan a firewalled
> host. This will in turn affect Nessus scans when nmap.nasl is used.

What about removing most of the code, and have nmap.nasl just import a
file? I sometimes think this is the best option.

> Reference: http://seclists.org/lists/nmap-dev/2004/Oct-Dec/0143.html (Nmap
> Development: nmap-3.7x MUCH slower than nmap-3.55 against firewalled hosts)

nessus_tcp_scanner does not suffer from this, AFAIK.

> The workaround for this issue is to pass additional parameters to nmap
> namely (--max_scan_delay 0).

According to the manual page, the timing (-T) options changed this
parameter. Did you play with them?

> script_add_preference(name: "Maximum wait between probes (ms)", value: "",
> type: "entry");

There are already too many preferences. I'd rather not add one.
Maybe this could be automatically added when we are not in "safe
checks"...

RE: Nmap.nasl [ In reply to ]

herman at sensepost

Jun 14, 2005, 3:16 AM

Post #3 of 6 (919 views)

Permalink

Thank you for the response,

I did not play with the timing options (-T) as that would influence other
settings as well (parallel scanning, time between scans and host timeouts).
I agree that adding more nmap preferences are probaly not the most elegant
way of adressing this issue. (What if the next release has even more or less
settings ?)

I would suggest having one, generic input box where the user can enter their
nmap parameters (Example: -n -P0 --min_parallelism 100 --max_scan_delay 0)
If the user does not enter additional parameters, default ones are assigned
(Example: -n -P0)

What do you think?

Regards,

Herman

-----Original Message-----
From: Michel Arboi [mailto:mikhail@nessus.org]
Sent: 14 June 2005 10:46 AM
To: Herman Young
Cc: plugins-writers@list.nessus.org
Subject: Re: [Plugins-writers] Nmap.nasl

On Mon May 30 2005 at 13:58, Herman Young wrote:

> Recent changes to nmap affects the time it takes to port scan a
> firewalled host. This will in turn affect Nessus scans when nmap.nasl is
used.

What about removing most of the code, and have nmap.nasl just import a file?
I sometimes think this is the best option.

> Reference: http://seclists.org/lists/nmap-dev/2004/Oct-Dec/0143.html
> (Nmap
> Development: nmap-3.7x MUCH slower than nmap-3.55 against firewalled
> hosts)

nessus_tcp_scanner does not suffer from this, AFAIK.

> The workaround for this issue is to pass additional parameters to nmap
> namely (--max_scan_delay 0).

According to the manual page, the timing (-T) options changed this
parameter. Did you play with them?

> script_add_preference(name: "Maximum wait between probes (ms)",
> value: "",
> type: "entry");

There are already too many preferences. I'd rather not add one.
Maybe this could be automatically added when we are not in "safe checks"...

Re: Nmap.nasl [ In reply to ]

mikhail at nessus

Jun 14, 2005, 3:30 AM

Post #4 of 6 (925 views)

Permalink

On Tue Jun 14 2005 at 12:16, Herman Young wrote:

> I would suggest having one, generic input box where the user can enter their
> nmap parameters (Example: -n -P0 --min_parallelism 100 --max_scan_delay 0)
> If the user does not enter additional parameters, default ones are assigned
> (Example: -n -P0)

> What do you think?

This would be a security risk, as nothing guarantees that nmap
correctly handles crazy options. Don't forget that the command is run
as root on the Nessus server.
We would have to parse the options and do some sanity checks. I don't
know which ones...

It is much simpler and safer to run Nmap before the Nessus scan, then
import the results. You can run Nmap against you whole network, it is
supposed to be quicker this way.

Re: Nmap.nasl [ In reply to ]

rich at westpoint

Jun 14, 2005, 3:40 AM

Post #5 of 6 (924 views)

Permalink

Michel Arboi wrote:
> This would be a security risk, as nothing guarantees that nmap
> correctly handles crazy options. Don't forget that the command is run
> as root on the Nessus server.
> We would have to parse the options and do some sanity checks. I don't
> know which ones...

nmap --interactive could be a bit of a problem :-)

Rich.
--
Richard Moore, Principal Software Engineer,
Westpoint Ltd,
Albion Wharf, 19 Albion Street, Manchester, M1 5LN, England
Tel: +44 161 237 1028
Fax: +44 161 237 1031

Re: Nmap.nasl [ In reply to ]

mikhail at nessus

Jun 14, 2005, 3:45 AM

Post #6 of 6 (924 views)

Permalink

On Tue Jun 14 2005 at 12:40, Richard Moore wrote:

> nmap --interactive could be a bit of a problem :-)

No problem with this one: stdin=/dev/null