Re: nmap scans on FreeBSD showing incorrect results

[Vincent Stemen <vince.nmap () hightek org>]

On Wed, Sep 20, 2017 at 11:17:01PM -0500, Daniel Miller wrote:
> Vincent,
>
> Thanks for reporting this! Filtered port state can be caused by dropped
> packets, though Nmap usually slows down and tries again if it determines
> some packets are being dropped. I noticed that the two examples you gave of
> incorrect results actually took less time to complete than the correct
> ones. It's likely that Nmap just isn't slowing down quickly enough to catch
> the replies it ought to.
>
> Here's some diagnostic stuff I'd like to see from you, if you can:
>
> 1. Debug output with -d2 for an incorrect scan. Also add -n to skip the
> reverse-DNS phase which can add noise to the total scan time.

Hi Daniel.
OK.  As before, ports 1000-1004 are unfiltered, so the correct results are

PORT     STATE  SERVICE
1000/tcp open   cadlock
1001/tcp open   webpush
1002/tcp closed windows-icfw
1003/tcp closed unknown
1004/tcp closed unknown

Here's an incorrect scan with -d2.

=====================

# nmap -n -d2 -p 1000-1030  pt02

Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-21 21:29 CDT
Fetchfile found /usr/local/share/nmap/nmap-services
Fetchfile found /usr/local/share/nmap/nmap.xsl
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
Fetchfile found /usr/local/share/nmap/nmap-payloads
Initiating Ping Scan at 21:29
Scanning pt02 (xx.xx.xx.xx) [4 ports]
Packet capture filter (device vtnet0): dst host xx.xx.xx.xx and (icmp or icmp6 or ((tcp or udp or sctp) and (src host 
xx.xx.xx.xx)))
We got a ping packet back from xx.xx.xx.xx: id = 39498 seq = 0 checksum = 26037
ultrascan_host_probe_update called for machine xx.xx.xx.xx state UNKNOWN -> HOST_UP (trynum 0 time: 212115)
Changing ping technique for xx.xx.xx.xx to icmp type 8 code 0
Changing global ping host to xx.xx.xx.xx.
Completed Ping Scan at 21:29, 0.21s elapsed (1 total hosts)
Overall sending rates: 18.78 packets / s, 713.73 bytes / s.
Initiating SYN Stealth Scan at 21:29
xx.xx.xx.xx pingprobe type ICMP is inappropriate for this scan type; resetting.
Scanning pt02 (xx.xx.xx.xx) [31 ports]
Packet capture filter (device vtnet0): dst host xx.xx.xx.xx and (icmp or icmp6 or ((tcp or udp or sctp) and (src host 
xx.xx.xx.xx)))
Discovered closed port 1003/tcp on xx.xx.xx.xx
Changing ping technique for xx.xx.xx.xx to tcp to port 1003; flags: S
Discovered open port 1000/tcp on xx.xx.xx.xx
Changing global ping host to xx.xx.xx.xx.
Completed SYN Stealth Scan at 21:29, 1.53s elapsed (31 total ports)
Overall sending rates: 39.89 packets / s, 1755.10 bytes / s.
Nmap scan report for pt02 (xx.xx.xx.xx)
Host is up, received echo-reply ttl 50 (0.024s latency).
Scanned at 2017-09-21 21:29:33 CDT for 2s
PORT     STATE    SERVICE      REASON
1000/tcp open     cadlock      syn-ack ttl 50
1001/tcp filtered webpush      no-response
1002/tcp filtered windows-icfw no-response
1003/tcp closed   unknown      reset ttl 50
1004/tcp filtered unknown      no-response
1005/tcp filtered unknown      no-response
1006/tcp filtered unknown      no-response
... The rest are filtered
1030/tcp filtered iad1         no-response
Final times for host: srtt: 24498 rttvar: 13938  to: 100000

Read from /usr/local/share/nmap: nmap-payloads nmap-services.
Nmap done: 1 IP address (1 host up) scanned in 1.80 seconds
           Raw packets sent: 65 (2.836KB) | Rcvd: 3 (112B)


> 2. Does slowing the scan down "fix" the incorrect results? Add -T2 to slow
> it down. If this works, then it's most likely a timing or missed packets
> issue.

Yes, it does appear to fix it.
As you suspected, I was not able to reproduce the problem with the -T2
switch from either host (pt01 (vultr vps) or my home machine).

Here's a run with -d2 in case it's useful.

=====================

# nmap -n -d2 -T2 -p 1000-1030  pt02

Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-21 21:42 CDT
Fetchfile found /usr/local/share/nmap/nmap-services
Fetchfile found /usr/local/share/nmap/nmap.xsl
The max # of sockets we are using is: 1
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 1
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
Fetchfile found /usr/local/share/nmap/nmap-payloads
Initiating Ping Scan at 21:42
Scanning pt02 (xx.xx.xx.xx) [4 ports]
Packet capture filter (device vtnet0): dst host xx.xx.xx.xx and (icmp or icmp6 or ((tcp or udp or sctp) and (src host 
xx.xx.xx.xx)))
We got a ping packet back from xx.xx.xx.xx: id = 28953 seq = 0 checksum = 36582
ultrascan_host_probe_update called for machine xx.xx.xx.xx state UNKNOWN -> HOST_UP (trynum 0 time: 24770)
Changing ping technique for xx.xx.xx.xx to icmp type 8 code 0
Changing global ping host to xx.xx.xx.xx.
Completed Ping Scan at 21:42, 0.45s elapsed (1 total hosts)
Overall sending rates: 2.22 packets / s, 62.08 bytes / s.
Initiating SYN Stealth Scan at 21:42
xx.xx.xx.xx pingprobe type ICMP is inappropriate for this scan type; resetting.
Scanning pt02 (xx.xx.xx.xx) [31 ports]
Packet capture filter (device vtnet0): dst host xx.xx.xx.xx and (icmp or icmp6 or ((tcp or udp or sctp) and (src host 
xx.xx.xx.xx)))
Discovered closed port 1004/tcp on xx.xx.xx.xx
Changing ping technique for xx.xx.xx.xx to tcp to port 1004; flags: S
Ultrascan PING SENT to xx.xx.xx.xx [tcp to port 1004; flags: S]
Discovered open port 1000/tcp on xx.xx.xx.xx
Discovered closed port 1002/tcp on xx.xx.xx.xx
Ultrascan PING SENT to xx.xx.xx.xx [tcp to port 1004; flags: S]
Discovered open port 1001/tcp on xx.xx.xx.xx
Ultrascan PING SENT to xx.xx.xx.xx [tcp to port 1004; flags: S]
Ultrascan PING SENT to xx.xx.xx.xx [tcp to port 1004; flags: S]
Discovered closed port 1003/tcp on xx.xx.xx.xx
Ultrascan PING SENT to xx.xx.xx.xx [tcp to port 1004; flags: S]
Changing global ping host to xx.xx.xx.xx.
Completed SYN Stealth Scan at 21:43, 27.75s elapsed (31 total ports)
Overall sending rates: 2.23 packets / s, 98.31 bytes / s.
Nmap scan report for pt02 (xx.xx.xx.xx)
Host is up, received echo-reply ttl 50 (0.026s latency).
Scanned at 2017-09-21 21:42:39 CDT for 28s
PORT     STATE    SERVICE      REASON
1000/tcp open     cadlock      syn-ack ttl 50
1001/tcp open     webpush      syn-ack ttl 50
1002/tcp closed   windows-icfw reset ttl 50
1003/tcp closed   unknown      reset ttl 50
1004/tcp closed   unknown      reset ttl 50
1005/tcp filtered unknown      no-response
1006/tcp filtered unknown      no-response
... The rest are filtered
1030/tcp filtered iad1         no-response
Final times for host: srtt: 25800 rttvar: 2493  to: 400000

Read from /usr/local/share/nmap: nmap-payloads nmap-services.
Nmap done: 1 IP address (1 host up) scanned in 28.34 seconds
           Raw packets sent: 63 (2.756KB) | Rcvd: 11 (436B)

=====================

One more thing I might mention in case it is useful information.
I can do a syn scan of 1000 ports from the same host with hping and it
consistently gives correct results in an average of about 2 seconds.
The command line I used is,

    # hping --scan 1000-2000 -V -S pt02

It, at least, verified that the scans can be done very quickly.

Note:
    After writing the above, there was one time that hping showed the
    two open ports, 1000 and 1001, as not responding, as though they
    were filtered.  Then it never did it again in further tests.
    I suspect it got hit with a fluke packet loss.


> 3. Let us know if there's anything special about the network: virtual
> machine (bridged, NAT, etc)? WiFi? Gigabit Ethernet? It's already very
> helpful to know this affects multiple versions of Nmap and FreeBSD, but if
> you find a version combination that *does* work, that's useful info as well.

Both the host running nmap and the target machine being scanned (pt02)
are vultr.com vps instances.  The 10.3-RELEASE host that I ran nmap from
and got similar results is my physical workstation at home, connected
via cable internet, going through a FreeBSD firewall using NAT.

Here is the network interface info on the vulter vps.

vtnet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        
options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        ether xx:xx:xx:xx:xx:xx
        hwaddr xx:xx:xx:xx:xx:xx
        inet xx.xx.xx.xx netmask 0xfffffe00 broadcast xx.xx.xx.255
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet 10Gbase-T <full-duplex>

> Thanks. Hopefully we can fix it soon!
> Dan


I hope I adequately covered everything you asked for.


> On Tue, Sep 19, 2017 at 8:11 PM, Vincent Stemen <vince.nmap () hightek org>
> wrote:

> > Hi.
> >
> > On FreeBSD 11.1 release I am getting inconsistent results from nmap version
> > 7.40.  It is randomly showing some ports as filtered even though they are
> > not.
> > I am wondering if this could be a bug in nmap when running on FreeBSD.
> >
> > For comparison, I ran nmap version 7.40 on Linux Debian 4.9.30 and I do not
> > have the problem.  It consistently correctly shows all unfiltered ports.
> >
> > The host being scanned is running a packet filter firewall on FreeBSD 11.1.
> >
> > I also ran a few of the same tests from a FreeBSD 10.3-RELEASE-p11 machine,
> > running nmap-7.12 and got similar inconsistent results.
> >
> > On these tests, there are 5 unfiltered ports.
> > If it has been at least a minute or so since the last scan, it seems to
> > output
> > the correct results.
> >
> > # nmap  -p 1000-1040  pt02
> >
> > Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-19 18:21 CDT
> > Nmap scan report for pt02 (xx.xx.xx.xx)
> > Host is up (0.026s latency).
> > Not shown: 36 filtered ports
> > PORT     STATE  SERVICE
> > 1000/tcp open   cadlock
> > 1001/tcp open   webpush
> > 1002/tcp closed windows-icfw
> > 1003/tcp closed unknown
> > 1004/tcp closed unknown
> >
> > Nmap done: 1 IP address (1 host up) scanned in 4.89 seconds
> >
> > -------------------------------------
> >
> > But if I run the scan again, I get random wrong results.
> >
> > # nmap  -p 1000-1040  pt02
> >
> > Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-19 18:21 CDT
> > Nmap scan report for pt02 (xx.xx.xx.xx)
> > Host is up (0.024s latency).
> > Not shown: 39 filtered ports
> > PORT     STATE  SERVICE
> > 1000/tcp open   cadlock
> > 1004/tcp closed unknown
> >
> > Nmap done: 1 IP address (1 host up) scanned in 1.79 seconds
> >
> > ????
> > This is outright wrong.
> > Why does it only show 2 unfiltered ports?
> > ????
> >
> > -------------------------------------
> >
> > It is not consistant about which ports it shows as being unfiltered.
> >
> > # nmap  -p 1000-1030  pt02
> >
> > Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-19 18:29 CDT
> > Nmap scan report for pt02 (xx.xx.xx.xx)
> > Host is up (0.024s latency).
> > Not shown: 29 filtered ports
> > PORT     STATE  SERVICE
> > 1001/tcp open   webpush
> > 1002/tcp closed windows-icfw
> >
> > Nmap done: 1 IP address (1 host up) scanned in 1.77 seconds
> >
> > -------------------------------------
> >
> > If I scan *no more* than 10 ports, it seems to always be correct.
> > From 15 on up it appears to get more and more inconsistant.
> >
> > # nmap  -p 1000-1010  pt02
> >
> > Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-19 18:32 CDT
> > Nmap scan report for pt02 (xx.xx.xx.xx)
> > Host is up (0.025s latency).
> > PORT     STATE    SERVICE
> > 1000/tcp open     cadlock
> > 1001/tcp open     webpush
> > 1002/tcp closed   windows-icfw
> > 1003/tcp closed   unknown
> > 1004/tcp closed   unknown
> > 1005/tcp filtered unknown
> > 1006/tcp filtered unknown
> > 1007/tcp filtered unknown
> > 1008/tcp filtered ufsd
> > 1009/tcp filtered unknown
> > 1010/tcp filtered surf
> >
> > Nmap done: 1 IP address (1 host up) scanned in 3.99 seconds
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/