Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: EXPERT IPv6 network scaning
From: niteesh kumar <niteesh3 () gmail com>
Date: Wed, 11 Apr 2012 01:19:08 +0530

On Tue, Apr 10, 2012 at 3:42 PM, niteesh kumar <niteesh3 () gmail com> wrote:

On Mon, Apr 9, 2012 at 3:27 PM, Patrik Karlsson <patrik () cqure net> wrote:

On Mon, Apr 9, 2012 at 9:44 AM, niteesh kumar <niteesh3 () gmail com> wrote:

On Mon, Apr 9, 2012 at 12:55 PM, Patrik Karlsson <patrik () cqure net>wrote:

On Mon, Apr 9, 2012 at 8:59 AM, David Fifield <david () bamsoftware com>wrote:

On Mon, Apr 09, 2012 at 08:53:36AM +0200, Patrik Karlsson wrote:
Initiating NSE at 20:01
NSOCK (0.0380s) PCAP requested on device 'br0' with berkeley
'ip6[40:1] == 58' (promisc=0 snaplen=1500 to_ms=200) (IOD #1)
NSOCK (0.0380s) PCAP created successfully on device 'br0'
bsd_hack=0 to_valid=1 l3_offset=14) (IOD #1)
NSOCK (0.1410s) Pcap read request from IOD #1  EID 13
NSOCK (0.1410s) Callback: READ-PCAP SUCCESS for EID 13
NSE: Error while parsing IPv6 extension headers.
NSOCK (0.1410s) Pcap read request from IOD #1  EID 21
NSOCK (10.1410s) Callback: READ-PCAP TIMEOUT for EID 21
NSE: Finished targets-ipv6-mld.
NSE: Finished targets-ipv6-mld.
Completed NSE at 20:01, 10.10s elapsed
NSOCK (10.1410s) nsi_delete() (IOD #1)
NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 1) scan.
Read from /home/david/nmap-git: nmap-services.
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.15 seconds
          Raw packets sent: 0 (0B) | Rcvd: 0 (0B)
NSOCK (10.1410s) nsi_delete() (IOD #1)

Here's what tcpdump sees (just one packet):

20:03:31.628811 IP6 fe80::1e6f:65ff:feb6:cad3 > ff02::1: HBH
multicast listener querymax resp delay: 0 addr: ::, length 24
       0x0000:  6000 0000 0020 0001 fe80 0000 0000 0000
       0x0010:  1e6f 65ff feb6 cad3 ff02 0000 0000 0000
       0x0020:  0000 0000 0000 0001 3a00 0502 0000 0100
       0x0030:  8200 322f 0000 0000 0000 0000 0000 0000
       0x0040:  0000 0000 0000 0000                      ........

The script works great for me, although it finds less hosts than the
targets-ipv6-multicast scripts do.
Initially I though it could be a Mac OS X thing, but based on then I
Dells, and Sonys among the sample Niteesh sent, so it's probably not
I just tried to change the first byte in the payload from 00 to
else and it gave me an additional host.

I'm not sure what's happening for you David? Maybe someone else on
the list
could give the script a go and report back?

I don't know what it is either, but the message "NSE: Error while
parsing IPv6 extension headers" looks like a bug.

David Fifield

I saw that when working on this script too, but it didn't make any
difference as far as I could tell.
It has to do with Packet:ipv6_ext_header_parse not returning true,
which I guess it should?

Patrik Karlsson

following patch <to commites script> will improve the performance as
previous script was not  taking host responding with MLDv2 packets

Index: scripts/targets-ipv6-multicast-mld.nse
--- scripts/targets-ipv6-multicast-mld.nse    (revision 28425)
+++ scripts/targets-ipv6-multicast-mld.nse    (working copy)
@@ -119,7 +119,7 @@
         if ( status ) then
             local l2reply = packet.Frame:new(layer2)
             local reply = packet.Packet:new(layer3, length, true)
-            if reply.ip6_nhdr == packet.MLD_LISTENER_REPORT then
+            if reply.ip6_nhdr == packet.MLD_LISTENER_REPORT or
reply.ip6_nhdr == 143 then
                 local target_str = reply.ip_src
                 if not results[target_str] then
                     if target.ALLOW_NEW_TARGETS then

The previous script was scanning 49 hosts whereas after this patch i
could search 169 hosts which is almost all hosts

I added the MLDV2_LISTENER_REPORT constant to the packet library and
adapted your patch accordingly.
It's committed as r28428.

Patrik Karlsson

This is my observation that number of hosts scanned increases if i run
wireshark parallel with the script.
when script is run alone only 3 or 4 ips are scanned whereas if it is run
in parallel with wireshark 195 hosts were scanned.

Patrik can you please look into  whats happening .?
are you also observing something similar ??


Varing the parameters in the script i.e. maximum response delay from 0
<where i could scan 177> to any value between 100-1000  <i could scan 253>,
hence result is improved, though theory says that 0 should have given the
best results rfc2710.

  " When a node receives a General Query, it sets a delay timer for each
   multicast address to which it is listening on the interface from
   which it received the Query, EXCLUDING the link-scope all-nodes
   address and any multicast addresses of scope 0 (reserved) or 1
   (node-local).  Each timer is set to a different random value, using
   the highest clock granularity available on the node, selected from
   the range [0, Maximum Response Delay] with Maximum Response Delay as
   specified in the Query packet.  If a timer for any address is already
   running, it is reset to the new random value only if the requested
   Maximum Response Delay is less than the remaining value of the
   running timer.  If the Query packet specifies a Maximum Response
   Delay of zero, each timer is effectively set to zero, and the action
   specified below for timer expiration is performed immediately."

this might be because of bust of traffic, intermediate switch may have
dropped the concern traffic. also sending MLDv2 query format by changing
payload to

probe.icmpv6_payload = bin.pack("HAH", "00 00 00 00", gen_qry,"00 00 00 00

will lead to generation of less traffic and similar results  with different
max response delay.

I observed one more thing, target-ipv6-multicast-slaac.nse do scan a lot of
ips which MLD script doesnot but those ip which are not scanned my MLD are
also not responding to Ping msgs <ECHO>. this may be attributed to machines
who actually take part in address configuration but do not communicate in
IPv6 network or may be due to some firewall not responding to ICMP packets.
May be a possibility that the slaac script is not checking the
reachability  of scanned nodes.

can anybody help me find a genuine reason for this??

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]