Re: NULL scan response

[Joe McEachern <joe () qacafe com>]

Hi,

I did go back and try old versions of nmap (3.x and 4.x) and you do see the
ports marked as closed. We originally thought the RST+ACK response was not
correct based on RFC 793. But after looking at this in more detail, I think
the RST+ACK response is actually correct for a null scan to a closed port.

If the state is CLOSED (i.e., TCB does not exist) then

all data in the incoming segment is discarded. An incoming
segment containing a RST is discarded. An incoming segment not
containing a RST causes a RST to be sent in response. The
acknowledgment and sequence field values are selected to make the
reset sequence acceptable to the TCP that sent the offending
segment.

If the ACK bit is off, sequence number zero is used,

*<SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>*

If the ACK bit is on,

<SEQ=SEG.ACK><CTL=RST>

Return.

I think both checks for RST+ACK and RST in scan_engine.cc don't allow some
of the scan types to match up probes. Beside the null scan, we see a similar
issue with the push scan and maimon scans.

  if ((tcp->th_flags & (TH_RST | TH_ACK)) == (TH_RST | TH_ACK)
      && !(probedata->flags & (TH_SYN | TH_FIN))) {
    return false;
  }
  if ((tcp->th_flags & (TH_RST | TH_ACK)) == TH_RST
      && (probedata->flags & (TH_SYN | TH_FIN))) {
    return false;
  }


We see this behavior against a number of Linux systems and a number of
various CPE devices.  For example Ubuntu 10.04
2.6.32-21-server #32-Ubuntu SMP Fri Apr 16 09:17:34 UTC 2010 x86_64
GNU/Linux

Regards,

--joe

On Fri, Aug 19, 2011 at 6:13 PM, Fyodor <fyodor () insecure org> wrote:

> On Tue, Aug 16, 2011 at 05:04:15PM -0400, Joe McEachern wrote:
> > We looked into this issue further. Just to recap, when running null TCP
> > scans, a TCP response with RST+ACK is marked as open.
>
> Well, "open|filtered" anyway.  But I agree that it should be "closed"
> or possibly "closed|filtered" instead.
>
> > David mentioned the code in scan_engine.cc that should be marking this as
> > closed. However, this code is not running. When tcp_probe_match() is
> called,
> > it is returning false here:
> >
> >   if ((tcp->th_flags & (TH_RST | TH_ACK)) == (TH_RST | TH_ACK)
> >       && !(probedata->flags & (TH_SYN | TH_FIN))) {
> >     return false;
> >   }
> >
> > This seems to exclude the possibility of marking a TCP RST+ACK response
> as
> > closed during a null scan.
>
> Good catch!  We should probably just delete this line, but we need to
> move carefully to ensure that doesn't allow for probe/response
> mismatches.
>
> Do you happen to know what OS & OS version any of the affected
> machines (those returning the improper RST/ACK) are running?
>
> I will add an item to the Nmap TODO list to solve this.
>
> Cheers,
> Fyodor
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/