Re: Weird Crash - "WAITING_TO_RUNNING"

[David Fifield <david () bamsoftware com>]

On Wed, Nov 03, 2010 at 09:40:45PM -0700, David Fifield wrote:
> Your discovery of --scan-delay is a good clue. Also the fact that ports
> are being erroneously marked open. I can't think of a reason why
> scanning faster would cause ports to be seen as open; Nmap never marks a
> port open unless it gets some kind of response, and rate-limited replies
> would show up as filtered instead.
>
> 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

Here's a little more I've been able to find. Using --packet-trace, the
responses to legitimately open ports look like this. Note ttl=114
(implying an initial TTL of 128), win=8192, mss=1452, incremental ids,
and widely distributed seq.

RCVD (0.5120s) TCP 74.62.92.70:80 > 192.168.0.21:38553 SA ttl=114 id=10873 iplen=44  seq=4194407315 win=8192 <mss 1452>
RCVD (0.5930s) TCP 74.62.92.70:25 > 192.168.0.21:38553 SA ttl=114 id=10874 iplen=44  seq=1539398716 win=8192 <mss 1452>
RCVD (0.6400s) TCP 74.62.92.70:443 > 192.168.0.21:38553 SA ttl=114 id=10875 iplen=44  seq=2158929027 win=8192 <mss 1452>

The bogus SYN-ACK responses are very different. ttl=50 (implying initial
TTL is 64), win=0, mss 1396, id=0, and closely spaced seq.

RCVD (28.6500s) TCP 74.62.92.70:3933 > 192.168.0.21:38553 SA ttl=50 id=0 iplen=44  seq=2583114080 win=0 <mss 1396>
RCVD (28.6500s) TCP 74.62.92.70:47863 > 192.168.0.21:38553 SA ttl=50 id=0 iplen=44  seq=2583135456 win=0 <mss 1396>
RCVD (28.6540s) TCP 74.62.92.70:63659 > 192.168.0.21:38554 SA ttl=50 id=0 iplen=44  seq=2583021281 win=0 <mss 1396>

These SYN-ACKs have more in common with the RST-ACKs that come back for
most ports:

RCVD (0.6400s) TCP 74.62.92.70:199 > 192.168.0.21:38553 RA ttl=50 id=0 iplen=40  seq=0 win=0
RCVD (0.6400s) TCP 74.62.92.70:8888 > 192.168.0.21:38553 RA ttl=50 id=0 iplen=40  seq=0 win=0
RCVD (0.6400s) TCP 74.62.92.70:113 > 192.168.0.21:38553 RA ttl=50 id=0 iplen=40  seq=0 win=0

It initially appears that some firewall or other device is sending RSTs,
but also SYN-ACKs for some reason at high scan rates. A sudden change of
behavior at high rates made me think of SYN cookies. The
structured-looking seq values in the bogus SYN-ACKs tend to corroborate
this. But the puzzling part is why anyone would bother sending back a
SYN cookie at all, when a RST for a closed port requires no more
resources and makes better sense. Does this behavior ring a bell for
anyone?

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