Re: Weird Crash - "WAITING_TO_RUNNING"

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

On Wed, Nov 3, 2010 at 11:24 PM, David Fifield <david () bamsoftware com> wrote:
> 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?

We believe that many of the connections we are scanning are satellite
Internet connections (some of our clients are retail stores or
restaurants, and they tend to have exotic ways to connect to the
Internet).  I speculate that perhaps the inbound routers for these
high-latency connections tend to proxy stuff...which may or may not
have anything to do with anything.  But I though I'd throw it out
there.

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