Re: NULL scan response

[Joe McEachern <joe () qacafe com>]

Hi,

We looked into this issue further. Just to recap, when running null TCP
scans, a TCP response with RST+ACK is marked as open.

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.

--joe


---------- Forwarded message ----------
> From: David Fifield <david () bamsoftware com>
> Date: Mon, Jul 18, 2011 at 8:02 PM
> Subject: Re: NULL scan response
> To: Matthew Stickney <stickney () qacafe com>
> Cc: nmap-dev () insecure org
>
>
> On Wed, Jul 13, 2011 at 10:56:19AM -0400, Matthew Stickney wrote:
> > Hi,
> >
> > While running some scans today, I noticed something strange. Some
> > machines respond to a NULL scan probe with a RST/ACK packet rather
> > than a plain RST. This is clearly different than receiving no
> > response, or getting an ICMP unreachable error, but NMap still lists
> > the port as open|filtered. I noticed similar behavior with FIN and
> > Xmas scans (one machine sends FIN/PUSH/URG in response to Xmas,
> > another RST/ACK, but in both cases NMap lists the port as
> > open|filtered). The relevant RFC requires a plain RST to be sent, but
> > is labelling these ports open|filtered the expected behavior from
> > NMap, or a bug? Example scan follows.
> >
> >
> > $ sudo nmap 172.16.1.198  -n -Pn -sN --packet-trace -p 50
> >
> > Starting Nmap 5.51 ( http://nmap.org ) at 2011-07-13 10:44 EDT
> > SENT (0.2370s) ARP who-has 172.16.1.198 tell 172.16.1.181
> > RCVD (0.2380s) ARP reply 172.16.1.198 is-at 00:1C:C0:93:33:FB
> > SENT (0.5660s) TCP 172.16.1.181:61318 > 172.16.1.198:50  ttl=58 id=37325
> iplen=40  seq=748468818 win=3072
> > RCVD (0.5760s) TCP 172.16.1.198:50 > 172.16.1.181:61318 RA ttl=64 id=0
> iplen=40  seq=0 win=0
> > SENT (0.6670s) TCP 172.16.1.181:61319 > 172.16.1.198:50  ttl=48 id=2691
> iplen=40  seq=748534355 win=1024
> > RCVD (0.6670s) TCP 172.16.1.198:50 > 172.16.1.181:61319 RA ttl=64 id=0
> iplen=40  seq=0 win=0
> > Nmap scan report for 172.16.1.198
> > Host is up (0.00018s latency).
> > PORT   STATE         SERVICE
> > 50/tcp open|filtered re-mail-ck
> >
> > Nmap done: 1 IP address (1 host up) scanned in 0.88 seconds
>
> The code should already be interpreting RST+ACK as a closed port. Here
> is the part I think is responsible in scan_engine.cc:
>
>          /* Now that response has been matched to a probe, I interpret it
> */
>          if (USI->scantype == SYN_SCAN && (tcp->th_flags &
> (TH_SYN|TH_ACK)) == (TH_SYN|TH_ACK)) {
>            /* Yeah!  An open port */
>            newstate = PORT_OPEN;
>            current_reason = ER_SYNACK;
>          } else if (tcp->th_flags & TH_RST) {
>            current_reason = ER_RESETPEER;
>            if (USI->scantype == WINDOW_SCAN ) {
>              newstate = (tcp->th_win)? PORT_OPEN : PORT_CLOSED;
>            } else if (USI->scantype == ACK_SCAN) {
>              newstate = PORT_UNFILTERED;
>            } else newstate = PORT_CLOSED;
>          } else if (USI->scantype == SYN_SCAN && (tcp->th_flags & TH_SYN))
> {
>            /* A SYN from a TCP Split Handshake -
> http://nmap.org/misc/split-handshake.pdf - open port */
>            newstate = PORT_OPEN;
>            current_reason = ER_SYN;
>          } else {
>            if (o.debugging)
>              error("Received scan response with unexpected TCP flags:
> %d", tcp->th_flags);
>            break;
>          }
>
> Try running with -d3 and see if there are any helpful debugging
> messages. Also, it may help if you can send a complete packet capture.
>
> David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/