Home page logo

nmap-dev logo Nmap Development mailing list archives

RE: -sO for IPv6
From: "Dario Ciccarone (dciccaro)" <dciccaro () cisco com>
Date: Wed, 15 Jun 2011 17:40:27 -0500

Hm. This may end in a "TL;DR" . . . 

I tried it against a couple devices - some observations:

1) For the actual extension headers (Hop-by-Hop (0), Routing (43),
Fragment (44), Destination Options (60), No Next Header (59)) - we're
just setting the NH field on the IPv6 header to each value. There's no
attempt to actually build a valid extension header (well, it IS valid
for 59 ;)). I think it would be more accurate if the extension header
was properly formed. I can provide pcaps for each one of them, if so

2) Because of (1), 0, 43, 44 and 60 are erroneously reported as
"open|filtered", with reason "no-response". Actually, the thing is that
for the other ones being reported as "closed", the OS is indeed sending
back an ICMPv6(4,1) - but for those four I mention before, it's sending
back an ICMPv6(4,0) - which we aren't checking for as a return value.

3) On top - if a device between the nmap scanning host & the target is
filtering traffic for those protocols, the filtered protocols are being
reported as (again) "open|filtered", "no-response" - even when the
filtering device *does send back* an ICMPv6(1,1) - which again, looks
like we're not checking for.

4) There will never be anything back for an IPv6 packet with NH = 59 -
unless being filtered, and filtering device sending back ICMPv6(1,1).
Should, IMHO, be assumed open - if you're doing IPv6, you *have* to
support them all (0, 43, 44, 59 and 60) - so.

5) A Routing Header can either be type 0, 1 or 2 - RH0 was deprecated by
RFC-5095. If the actual RH was to be sent, we should probably test for
(at least) RH0 and RH2. It isn't enough to just test for "routing

6) Some devices, like Cisco IOS, can not only filter on a given
extension header (ie: "deny ipv6 any any dest-option", to filter any
IPv6 packet including a Destination Option extension header), but can
also filter on a specific option type within the extension header (ie:
"deny ipv6 any any dest-option-type 0" to filter a Destination Option
extension header including a Pad1 option). This could also be
implemented to further determine if *any packet with a given extension
header* would be dropped/filtered, or only those with a specific option
within their "payload"

I do think that, for the known extension headers, the best way to test
would be:

A) locate a protocol that is supported and not filtered by the device
being scanned (ie: got a "proto-response" for ICMPv6)
B) proceed to test, in turn, each extension header (with a valid,
minimal, extension header), using as payload the protocol we got on (A)

So: do the full proto scan, less known extension headers, and then do
extension headers - as on the example, for ICMPv6:



Fragment can be as easy as a Frag Header w/ FO=0 and MF=0 - though, for
completitude, we should also try with a FO != 0 too (example: Cisco IOS
could allow the first, initial fragment through - but block additional
fragments). In any case, that would be more like "testing ACLs" - if we
didn't get an ICMPv6(4,0) or (4,1) for the FO=0, is that our target
understands how to parse a Frag Header :)

Sigh. I'm sure I'm forgetting something . . . Oh well.

Happy to test the bugfixed version :)


-----Original Message-----
From: nmap-dev-bounces () insecure org 
[mailto:nmap-dev-bounces () insecure org] On Behalf Of David Fifield
Sent: Tuesday, June 14, 2011 4:15 PM
To: nmap-dev () insecure org
Subject: -sO for IPv6

I've just added support for -6 -sO (IPv6 protocol scan). This works by
scanning all 256 possible values of the Next Header field, which is
analogous to the Protocol field in IPv4. Instead of ICMP Protocol
Unreachable to mean a closed protocol, it uses ICMPv6 
Parameter Problem,
Unrecognized Next Header. Here is the output of scanning scanme.

# nmap -sO -6 scanmev6.nmap.org --reason
Nmap scan report for scanmev6.nmap.org 
Host is up, received echo-reply (0.013s latency).
Scanned at 2011-06-14 12:37:50 PDT for 382s
Not shown: 241 closed protocols
Reason: 241 param-problems
0        open|filtered hopopt     no-response
4        open|filtered ip         no-response
6        open          tcp        proto-response
17       open          udp        port-unreach
41       open|filtered ipv6       no-response
43       open|filtered ipv6-route no-response
44       open|filtered ipv6-frag  no-response
50       open|filtered esp        no-response
51       open|filtered ah         no-response
58       open          ipv6-icmp  proto-response
59       open|filtered ipv6-nonxt no-response
60       open|filtered ipv6-opts  no-response
108      open|filtered ipcomp     no-response
132      open|filtered sctp       no-response
136      open|filtered udplite    no-response

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

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 ]