Re: Weird Crash - "WAITING_TO_RUNNING"

[Nathan <nathan.stocks () gmail com>]

On Fri, Nov 5, 2010 at 6:02 PM, David Fifield <david () bamsoftware com> wrote:
> On Wed, Nov 03, 2010 at 09:40:45PM -0700, David Fifield wrote:
> > Try doing your scan with fewer ports at full speed and see if they are
> > wrongly marked open. Like this:
> >
> > /usr/bin/sudo /usr/bin/nmap -sS -sV -T4 --top-ports 100 74.62.92.70 -P0 -v
> >
> > You should not get more open ports than you got with --scan-delay. If
> > you get more open ports, there's something weird going on that we have
> > to figure out. Run with the -v option and you'll be notified of open
> > ports in real time; that way you'll be able to see if you're getting a
> > flood of them.
> >
> > For what it's worth, I just tried the scan and I am getting a flood of
> > them:
> >
> > Discovered open port 30749/tcp on 74.62.92.70
> > Discovered open port 48748/tcp on 74.62.92.70
> > Discovered open port 8235/tcp on 74.62.92.70
>
> Putting aside the question of where all the open ports are coming from
> (I don't think that's Nmap's fault), we should do something about Nmap
> spawning too many scripts at once. I think it is the case that Nmap
> allocates memory for all script threads at once and runs them all at
> once. We could put a limit on the number of scripts that run at once,
> either doing them in batches like Nmap's host groups, or running up to a
> certain number and then only starting a new thread after an existing one
> has finished.
>
> David Fifield

First, I'm not sure we can _entirely_ rule that the problem is not
nmap's fault for detecting falsely open ports when adding some
seemingly unrelated flags so drastically changes what nmap determines
as being open or not ("--top-ports 100" -> "accurate", "-p 1-65535" ->
"not accurate").  That being said, I'm not trying to knock nmap.  Nmap
does an amazing job 99.99% of the time, and I'm sure something is
really messing with the response packets.  Perhaps I just need to slow
down these scans.

Second, I think that's entirely reasonable thing to expect that nmap
should not die a horribly memory-constrained death if lots (or all) of
the ports on a target ARE open.

To clarify, when you say "spawning too many scripts" -- are you
talking about the service detection stuff that gets run after the
actual port scan?  I can totally see how you could run out of memory
if you're loading a whole set of service-detection scripts for every
single port that's open, and you're doing it in parallel.

If that's why I'm encountering this crash, then it looks like I could
work around it by continuing to twiddle with flags for each host until
I can either:
a) identify a set of flags that results in accurate (not
all-ports-open) results for all the hosts.  (Maybe slow things down?)
b) identify different sets of flags that results in accurate results
for specific hosts, and then find ways to determine which hosts need
which flags.

...or we could find a way to help nmap handle these weird targets
better internally.

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