Re: Weird Crash - "WAITING_TO_RUNNING"

[Patrick Donnelly <batrick () batbytes com>]

On Thu, Nov 4, 2010 at 1:24 AM, David Fifield <david () bamsoftware com> wrote:
> 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>

Why would the starting ttl values be different?

> 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?

I've seen strange things like this when scanning an outside box on an
unstable campus network (lots of packet drops). I never could figure
out the cause.

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