RE: -sO for IPv6

["Dario Ciccarone (dciccaro)" <dciccaro () cisco com>]

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
needed.

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
header"

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:

IPv6(nh=HBH)/HBH(nh=ICMPv6)/ICMPv6

IPv6(nh=DstOpt)/DstOpt(nh=ICMPv6)/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 :)

Dario



> -----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 
> (2600:3c01::f03c:91ff:fe93:cd19)
> 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
> PROTOCOL STATE         SERVICE    REASON
> 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
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/