Nmap Development mailing list archives

Previous By Date Next
Previous By Thread Next

Re: IPv6 host discovery Bug in 6.47 -- perhaps newer versions

From: Allen Landsidel <landsidel.allen () gmail com>
Date: Mon, 28 Sep 2015 13:58:26 -0400
I saw that too, and thought it was suspicious.
There's no firewall in play here. There is one between this host and the destination, however tcpdump is being run on the same host as nmap, which has no "local" firewall running. The tcpdump does show the traffic when testing with ping6, traceroute6, telnet -6, etc so I'm sure the stack itself is working.
My gut feeling is either that it's not actually sending the packets, or there is some sysctl knob in play that's preventing them from hitting the wire. Nothing is showing up in any of the system logs. 



On 9/28/2015 11:07, Daniel Miller wrote:

Allen,

Please keep dev () nmap org <mailto:dev () nmap org> CC'd on these messages so
other developers can chime in; I'm far from a FreeBSD expert.

I've excerpted your output below:

    SENT (0.1061s) ICMP [192.168.129.2 > 45.33.32.156 Echo request
    (type=8/code=0) id=57140 seq=0] IP [ttl=37 id=32712 iplen=28 ]
    SENT (0.1062s) TCP 192.168.129.2:60109 <http://192.168.129.2:60109>
     > 45.33.32.156:443 <http://45.33.32.156:443> S ttl=43 id=38851
    iplen=44  seq=936660269 win=1024 <mss 1460>
    SENT (0.1063s) TCP 192.168.129.2:60109 <http://192.168.129.2:60109>
     > 45.33.32.156:80 <http://45.33.32.156:80> A ttl=58 id=5574
    iplen=40  seq=0 win=1024
    SENT (0.1063s) ICMP [192.168.129.2 > 45.33.32.156 Timestamp request
    (type=13/code=0) id=6201 seq=0 orig=0 recv=0 trans=0] IP [ttl=41
    id=2108 iplen=40 ]
    RCVD (0.1456s) ICMP [45.33.32.156 > 192.168.129.2 Timestamp reply
    (type=14/code=0) id=6201 seq=0 orig=0 recv=50340359 trans=50340359]
    IP [ttl=52 id=44266 iplen=40 ]


This clearly shows that Nmap believes it has sent an ICMP Echo request,
a TCP SYN to port 443, a TCP ACK to port 80, and an ICMP Timestamp
request. The host is marked "up" because it sent a reply to the last
probe (timestamp).

Is there any reason your tcpdump sniffer would not receive the packets
that Nmap thinks it's sending? A filtering firewall between the sniffer
and the scanner, or a capture filter (BPF) that is only including TCP
traffic, for instance?

Dan

On Mon, Sep 28, 2015 at 9:02 AM, Allen Landsidel
<landsidel.allen () gmail com <mailto:landsidel.allen () gmail com>> wrote:

    Daniel,

    No problem, thanks for getting back to me so quick.  The host is
    indeed FreeBSD 10, though it's in need of an update, so I'll take
    care of that as well.  In answer to your questions.

    1. No problem.  I'll download and build the beta tarball and get
    back to you.  If there's an svn/git repo you want me to build from I
    can try that as well.

    2. Results are attached as 'nmap test.result'.

    3. Yes, I'm testing as root.

    4. The setup is virtualized via VMWare ESXi 5.5.  Other more
    "standard" tools are working fine, such as ping6, and as I said if I
    explicitly tell nmap to use an echo test with -PE, it also detects
    the target as up and proceeds with the scan.

    On 9/28/2015 09:52, Daniel Miller wrote:

        Allen,

        Thanks for reporting this. We were aware of a problem sending raw
        packets on FreeBSD 10 and later, because of a change in network
        address
        byte order, but that results in no packets being sent at all.
        I'm not
        sure what could be causing the problem you're describing, but please
        answer a few more questions for us, and we will try to debug:

        1. Is there any way at all that you can use 6.49BETA5 for this
        test? It
        is always much easier to debug the current release than to work
        with an
        older release, and you will get a more capable product as a whole.

        2. What is the output of this command, and what does tcpdump
        show?: nmap
        -d --packet-trace -sn -n scanme.nmap.org
        <http://scanme.nmap.org> <http://scanme.nmap.org>

        3. Are you running Nmap with root privileges every time? The default
        behavior when root privileges are not available is to try a TCP
        connection to ports 80 and 443, without ICMP probes.

        4. Is there anything unusual about your network environment? For
        example, when my FreeBSD VM was running under Oracle VirtualBox with
        NAT, VirtualBox dropped the ICMP Timestamp Requests and
        intercepted the
        raw TCP packets, trying to perform a complete TCP handshake
        instead of
        passing along the raw SYN and ACK packets expected.

        Dan

        On Sat, Sep 26, 2015 at 6:17 PM, Allen Landsidel
        <landsidel.allen () gmail com <mailto:landsidel.allen () gmail com>
        <mailto:landsidel.allen () gmail com
        <mailto:landsidel.allen () gmail com>>> wrote:

             It appears that when scanning a host with ipv6, if you
        don't specify
             any discovery options, that only the port 80 and port 443
        checks
             described in the man page are actually tried -- the ICMP echo
             request isn't. Scanning with "nmap -6 -PE host::addr" works
        fine and
             detects the host is up, but scanning with just "nmap -6
        host::addr"
             does not.

             Tcpdump indicates only the 80 and 443 packets are being
        sent, while
             the man page indicates the ICMP echo request is also tried.

             Using FreeBSD, so I don't know if this is fixed in 6.48 or
        6.49, as
             6.47 is the latest version available in ports.

             _______________________________________________
             Sent through the dev mailing list
        https://nmap.org/mailman/listinfo/dev
             Archived at http://seclists.org/nmap-dev/




_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/
Previous By Date Next
Previous By Thread Next

Current thread: