idnits 2.17.1 draft-gont-opsec-ipv6-host-scanning-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document obsoletes RFC5157, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2012) is 4197 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 781, but no explicit reference was found in the text == Unused Reference: 'RFC5157' is defined on line 825, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-17) exists of draft-ietf-6man-stable-privacy-addresses-01 == Outdated reference: A later version (-03) exists of draft-gont-6man-ipv6-smurf-amplifier-00 -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operational Security Capabilities for F. Gont 3 IP Network Infrastructure (opsec) Huawei Technologies 4 Internet-Draft T. Chown 5 Obsoletes: 5157 (if approved) University of Southampton 6 Intended status: Informational October 23, 2012 7 Expires: April 26, 2013 9 Network Reconnaissance in IPv6 Networks 10 draft-gont-opsec-ipv6-host-scanning-02 12 Abstract 14 IPv6 offers a much larger address space than that of its IPv4 15 counterpart. The standard /64 IPv6 subnets can (in theory) 16 accommodate approximately 1.844 * 10^19 hosts, thus resulting in a 17 much lower host density (#hosts/#addresses) than their IPv4 18 counterparts. As a result, it is widely assumed that it would take a 19 tremendous effort to perform address scanning attacks against IPv6 20 networks, and therefore IPv6 address scanning attacks have long been 21 considered unfeasible. This document analyzes how traditional 22 address scanning techniques apply to IPv6 networks, and also explores 23 a number of techniques that can be employed for IPv6 network 24 reconnaissance. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. This document may not be modified, 30 and derivative works of it may not be created, and it may not be 31 published except as an Internet-Draft. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 26, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Requirements for the Applicability of Network 64 Reconnaissance Techniques . . . . . . . . . . . . . . . . . . 4 65 3. IPv6 Address scanning . . . . . . . . . . . . . . . . . . . . 5 66 3.1. Address configuration in IPv6 . . . . . . . . . . . . . . 5 67 3.2. IPv6 address scanning of remote area networks . . . . . . 11 68 3.3. IPv6 address scanning of local area networks . . . . . . . 11 69 3.4. Existing IPv6 address scanning tools . . . . . . . . . . . 12 70 3.5. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 13 71 4. Leveraging the Domain Name System (DNS) for Network 72 Reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.1. DNS Advertised Hosts . . . . . . . . . . . . . . . . . . . 15 74 4.2. DNS Zone Transfers . . . . . . . . . . . . . . . . . . . . 15 75 4.3. Leveraging DNS reverse mappings for network 76 reconnaissance . . . . . . . . . . . . . . . . . . . . . . 15 77 5. Public archives . . . . . . . . . . . . . . . . . . . . . . . 17 78 6. Application Participation . . . . . . . . . . . . . . . . . . 18 79 7. Inspection of the IPv6 Neighbor Cache and Routing Table . . . 19 80 8. Inspection of System Configuration and Log Files . . . . . . . 20 81 9. Gleaning information from Routing Protocols . . . . . . . . . 21 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 86 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 87 Appendix A. Implementation of a full-fledged IPv6 88 address-scanning tool . . . . . . . . . . . . . . . . 27 89 A.1. Host-probing considerations . . . . . . . . . . . . . . . 27 90 A.2. Implementation of an IPv6 local address-scanning tool . . 28 91 A.3. Implementation of a IPv6 remote address-scanning tool . . 29 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 94 1. Introduction 96 The main driver for IPv6 deployment is its larger address space 97 [CPNI-IPv6]. This larger address space not only allows for an 98 increased number of connected devices, but also introduces a number 99 of subtle changes in several aspects of the resulting networks. One 100 of such changes is the reduced host density (Nr. of addresses/Nr. of 101 hosts) of typical IPv6 subnetworks: with default IPv6 subnets of /64, 102 each subnet comprises more than 1.844 * 10^19 addresses; however, the 103 actual number of nodes in each subnet is likely to remain similar to 104 that of IPv4 subnetworks (at most a few hundred nodes per subnet). 105 This lower host-density has lead to the widely-established myth that 106 IPv6 address-scanning attacks are unfeasible, since they would 107 require a ridiculously long time (along with a tremendous amount of 108 traffic) to be successfully performed. 110 This document analyzes the feasibility of "traditional" address- 111 scanning attacks in IPv6 networks. Namely, it performs a thorough 112 analysis of how IPv6 addresses are generated, and sheds some light on 113 the real size of the search space for IPv6 address scanning attacks 114 (e.g., "ping sweeps") thus dismantling the myth that such IPv6 115 address scanning attacks are unfeasible. Additionally, this document 116 explores a number of other techniques that can be employed for IPv6 117 network reconnaissance. 119 One one hand, raising awareness about IPv6 network reconnaissance 120 techniques may allow (in some cases) network and security 121 administrators to prevent or detect such attempts. On the other 122 hand, network reconnaissance is essential for the so-called 123 "penetration tests" typically performed to assess the security of 124 production networks. As a result, we believe the benefits of a 125 thorough discussion of IPv6 network reconnaissance are two-fold. 127 Section 3 analyzes the feasibility of traditional address-scanning 128 attacks (e.g. ping sweeps) in IPv6 networks, and explores a number of 129 possible improvements to such techniques. [van-Dijk] describes a 130 recently-disclosed technique for leveraging DNS reverse mappings for 131 discovering IPv6 nodes. Finally, Appendix A describes how the 132 analysis carried out throughout this document can be leveraged to 133 produce an address-scanning tools (e.g. for penetration testing 134 purposes). 136 2. Requirements for the Applicability of Network Reconnaissance 137 Techniques 139 Throughout this document, a number of network reconnaissance 140 techniques are discussed. Each of these techniques have different 141 requirements on the side of the practitioner, with respect to whether 142 they require local access to the target network, and whether they 143 require login access to the system on which the technique is applied. 145 The following table tries to summarize the aforementioned 146 requirements, and serve as a cross index to the corresponding 147 sections. 149 +---------------------------------------------+----------+----------+ 150 | Technique | Local | Login | 151 | | access | access | 152 +---------------------------------------------+----------+----------+ 153 | Local address scans (Section 3.3) | Yes | No | 154 +---------------------------------------------+----------+----------+ 155 | Remote Address scans (Section 3.2) | No | No | 156 +---------------------------------------------+----------+----------+ 157 | DNS Advertised Hosts (Section 4.1) | No | No | 158 +---------------------------------------------+----------+----------+ 159 | DNS Zone Transfers (Section 4.2 | No | No | 160 +---------------------------------------------+----------+----------+ 161 | DNS reverse mappings (Section 4.3 | No | No | 162 +---------------------------------------------+----------+----------+ 163 | Public archives (Section 5) | No | No | 164 +---------------------------------------------+----------+----------+ 165 | Application Participation (Section 6) | No | No | 166 +---------------------------------------------+----------+----------+ 167 | Inspection of the IPv6 Neighbor Cache and | No | Yes | 168 | Routing Table (Section 7) | | | 169 +---------------------------------------------+----------+----------+ 170 | Inspecting System Configuration and Log | No | Yes | 171 | Files (Section 8) | | | 172 +---------------------------------------------+----------+----------+ 173 | Gleaning information from Routing Protocols | Yes | No | 174 | (Section 9) | | | 175 +---------------------------------------------+----------+----------+ 177 Table 1: Requirements for the Applicability of Network Reconnaissance 178 Techniques 180 3. IPv6 Address scanning 182 This section discusses how traditional address scanning techniques 183 (e.g. "ping sweeps") apply to IPv6 networks. Section 3.1 provides an 184 essential analysis of how address configuration is performed in IPv6, 185 identifying patterns in IPv6 addresses that can be leveraged to 186 reduce the IPv6 address search space when performing IPv6 address 187 scans. Appendix A discusses how the insights obtained in the 188 previous sub-sections can be incorporated into into a full-fledged 189 IPv6 address scanning tool. Section 3.5 provides advice on how to 190 mitigate IPv6 address scans. 192 3.1. Address configuration in IPv6 194 IPv6 incorporates two automatic address-configuration mechanisms: 195 SLAAC (StateLess Address Auto-Configuration) [RFC4862] and DHCPv6 196 (Dynamic Host Configuration Protocol version 6) [RFC3315]. SLAAC is 197 the mandatory mechanism for automatic address configuration, while 198 DHCPv6 is optional - however, most current versions of general- 199 purpose operating systems support both. In addition to automatic 200 address configuration, hosts may employ manual configuration, in 201 which all the necessary information is manually entered by the host 202 or network administrator into configuration files at the host. 204 The following subsections describe each of the possible configuration 205 mechanisms/approaches in more detail. 207 3.1.1. StateLess Address Auto-Configuration (SLAAC) 209 The basic idea behind SLAAC is that every host joining a network will 210 send a multicasted solicitation requesting network configuration 211 information, and local routers will respond to the request providing 212 the necessary information. SLAAC employs two different ICMPv6 213 message types: ICMPv6 Router Solicitation and ICMPv6 Router 214 Advertisement messages. Router Solicitation messages are employed by 215 hosts to query local routers for configuration information, while 216 Router Advertisement messages are employed by local routers to convey 217 the requested information. 219 Router Advertisement messages convey a plethora of network 220 configuration information, including the IPv6 prefix that should be 221 used for configuring IPv6 addresses on the local network. For each 222 local prefix learned from a Router Advertisement message, an IPv6 223 address is configured by appending a locally-generated Interface 224 Identifier (IID) to the corresponding IPv6 prefix. 226 The following subsections describe currently-deployed policies for 227 generating the IIDs used with SLAAC. 229 3.1.1.1. Interface-Identifiers embedding IEEE Identifiers 231 Many network technologies generate the 64-bit interface identifier 232 based on the link-layer address of the corresponding network 233 interface card. For example, in the case of Ethernet addresses, the 234 IIDs are constructed as follows: 236 1. The "Universal" bit (bit 6, from left to right) of the address is 237 set to 1 239 2. The word 0xfffe is inserted between the OUI (Organizationally 240 Unique Identifier) and the rest of the Ethernet address 242 For example, the MAC address 00:1b:38:83:88:3c would lead to the IID 243 021b:38ff:fe83:883c. 245 A number of considerations should be made about these identifiers. 246 Firstly, as it should be obvious from the algorithm described above, 247 two bytes (bytes 4-5) of the resulting address always have a fixed 248 value (0xff, 0xfe), thus reducing the search space for the IID. 249 Secondly, the first three bytes of these identifiers correspond to 250 the OUI of the network interface card vendor. Since not all possible 251 OUIs have been assigned, this further reduces the IID search space. 252 Furthermore, of the assigned OUIs, many could be regarded as 253 corresponding to legacy devices, and thus unlikely to be used for 254 Internet-connected IPv6-enabled systems, yet further reducing the IID 255 search space. Finally, in some scenarios it could be possible to 256 infer the OUI in use by the target network devices, yet narrowing 257 down the possible IIDs even more. 259 For example, an organization known for being provisioned by vendor 260 X is likely to have most of the nodes in its organizational 261 network with OUIs corresponding to vendor X. 263 These considerations mean that in some scenarios, the original IID 264 search space of 64 bits may be effectively reduced to 2^24 , or n * 265 2^24 (where "n" is the number of different OUIs assigned to the 266 target vendor). 268 Another interesting factor arises from the use of virtualization 269 technologies, since they generally employ automatically-generated MAC 270 addresses, with very specific patterns. For example, all 271 automatically-generated MAC addresses in VirtualBox virtual machines 272 employ the OUI 08:00:27 [VBox2011]. This means that all SLAAC- 273 produced addresses will have an IID of the form a00:27ff:feXX:XXXX, 274 thus effectively reducing the IID search space from 64 bits to 24 275 bits. 277 VMWare ESX server provides yet a more interesting example. 278 Automatically-generated MAC addresses have the following pattern 279 [vmesx2011]: 281 1. The OUI is set to 00:05:59 283 2. The next 16-bits of the MAC address are set to the same value as 284 the last 16 bits of the console operating system's primary IPv4 285 address 287 3. The final eight bits of the MAC address are set to a hash value 288 based on the name of the virtual machine's configuration file. 290 This means that, assuming the console operating system's primary IPv4 291 address is known, the IID search space is reduced from 64 bits to 8 292 bits. 294 On the other hand, manually-configured MAC addresses in VMWare ESX 295 server employ the OUI 00:50:56, with the low-order three bytes being 296 in the range 0x000000-0x3fffff (to avoid conflicts with other VMware 297 products). Therefore, even in the case of manually-configured MAC 298 addresses, the IID search space is reduced from 64-bits to 22 bits. 300 3.1.1.2. Privacy Addresses 302 Privacy concerns [CPNI-IPv6] [Gont-DEEPSEC2011] regarding interface 303 identifiers embedding IEEE identifiers led to the introduction of 304 "Privacy Extensions for Stateless Address Auto-configuration in IPv6" 305 [RFC4941], also known as "privacy addresses" or "temporary 306 addresses". Essentially, "privacy addresses" produce random 307 addresses by concatenating a random identifier to the auto- 308 configuration IPv6 prefix advertised in a Router Advertisement. 310 In addition to their unpredictability, these addresses are 311 typically short-lived, such that even if an attacker were to learn 312 one of these addresses, they would be of use for a reduced period 313 of time. 315 It is important to note that "privacy addresses" are generated in 316 addition to traditional SLAAC addresses (i.e., based on IEEE 317 identifiers): traditional SLAAC addresses are employed for incoming 318 (i.e. server-like) communications, while "privacy addresses" are 319 employed for outgoing (i.e., client-like) communications. This means 320 that implementation/use of "privacy addresses" does not prevent an 321 attacker from leveraging the predictability of traditional SLAAC 322 addresses, since "privacy addresses" are generated in addition to 323 (rather than in replacement of) the traditional SLAAC addresses 324 derived from e.g. IEEE identifiers. 326 3.1.1.3. Stable and random Interface Identifiers 328 In order to mitigate the security implications arising from the 329 predictable IPv6 addresses derived from IEEE identifiers, Microsoft 330 Windows produced an alternative scheme for generating "stable 331 addresses" (in replacement of the ones embedding IEEE identifiers). 332 The aforementioned scheme is allegedly an implementation of RFC 4941 333 [RFC4941], but without regenerating the addresses over time. The 334 resulting interface IDs are constant across system bootstraps, and 335 also constant across networks. 337 Assuming no flaws in the aforementioned algorithm, this scheme would 338 remove any patterns from the SLAAC addresses. 340 However, since the resulting interface IDs are constant across 341 networks, these addresses may still be leveraged for host tracking 342 purposes [I-D.ietf-6man-stable-privacy-addresses]. 344 3.1.1.4. Stable Privacy-Enhanced Addresses 346 In response to the predictability issues discussed in Section 3.1.1.1 347 and the privacy issues discussed in , the IETF is currently 348 standardizing (in [I-D.ietf-6man-stable-privacy-addresses]) a method 349 for generating IPv6 Interface Identifiers to be used with IPv6 350 Stateless Address Autoconfiguration (SLAAC), such that addresses 351 configured using this method are stable within each subnet, but the 352 Interface Identifier changes when hosts move from one network to 353 another. The aforementioned method is meant to be an alternative to 354 generating Interface Identifiers based on IEEE identifiers, such that 355 the benefits of stable addresses can be achieved without sacrificing 356 the privacy of users. 358 Implementation of this method (in replacement of Interface 359 Identifiers based on IEEE identifiers) would eliminate any patterns 360 from the Interface ID. 362 3.1.2. Dynamic Host Configuration Protocol version 6 (DHCPv6) 364 DHCPv6 can be employed as a stateful address configuration mechanism, 365 in which a server (the DHCPv6 server) leases IPv6 addresses to IPv6 366 hosts. As with the IPv4 counterpart, addresses are assigned 367 according to a configuration-defined address range and policy, with 368 some DHCPv6 servers assigned addresses sequentially, from a specific 369 range. In such cases, addresses tend to be predictable. 371 For example, if the prefix 2001:db8::/64 is used for assigning 372 addresses on the local network, the DHCPv6 server might 373 (sequentially) assign addresses from the range 2001:db8::1 - 2001: 375 db8::100. 377 In most common scenarios, this means that the IID search space will 378 be reduced from the original 64 bits, to 8 or 16 bits. 380 3.1.3. Manually-configured addresses 382 In some scenarios, node addresses may be manually configured. This 383 is typically the case for IPv6 addresses assigned to routers, since 384 routers do not employ automatic address configuration. 386 While network administrators are mostly free to select the IID from 387 any value in the range 1 - 264 range, for the sake of simplicity 388 (i.e., ease of remembering) they tend to select addresses with one of 389 the following patterns: 391 o "low-byte" addresses: in which all bytes of the IID (except the 392 lowest one) are set to 0. 394 o IPv4-based addresses: in which the IID encodes the IPv4-address of 395 the network interface (as in 2001:db8::192.168.1.1) 397 o wordy addresses: which encode words (as in 2001:db8::dead:beef) 399 Clearly, the first two patterns reduce the search space from the 400 original 64 bits to roughly 8 bits (assuming the IPv4 address range 401 is known for the case of "IPv4-based" addresses). On the other hand, 402 the search space for IPv6 wordy-addresses is probably larger and more 403 complex, but still greatly reduced when compared to the original 64- 404 bit search space. 406 3.1.4. IPv6 addresses corresponding to transition/co-existence 407 technologies 409 Some transition/co-existence technologies might be leveraged to 410 reduce the target search space of remote address-scanning attacks, 411 since they specify how the corresponding IPv6 address must be 412 generated. For example, in the case of Teredo [RFC4380], the 64-bit 413 interface identifier is generated from the IPv4 address observed at a 414 Teredo server along with a UDP port number. 416 3.1.5. IPv6 address assignment in real-world network scenarios 418 Table 2 and Table 3 provide a rough summary of the results obtained 419 by [Malone2008] for IPv6 clients and IPv6 routers, respectively. 420 These results are provided mainly for completeness-sake, since they 421 are the most comprehensive address-measurement results that have so 422 far been made publicly available. 424 We note, however, that evolution of IPv6 implementations, changes 425 in the IPv6 address selection policy, etc., might limit (or even 426 obsolete) the validity of these results. 428 +--------------+------------+ 429 | Address type | Percentage | 430 +--------------+------------+ 431 | SLAAC | 50% | 432 +--------------+------------+ 433 | IPv4-based | 20% | 434 +--------------+------------+ 435 | Teredo | 10% | 436 +--------------+------------+ 437 | Low-byte | 8% | 438 +--------------+------------+ 439 | Privacy | 6% | 440 +--------------+------------+ 441 | Wordy | <1% | 442 +--------------+------------+ 443 | Other | <1% | 444 +--------------+------------+ 446 Table 2: Measured client addresses 448 +--------------+------------+ 449 | Address type | Percentage | 450 +--------------+------------+ 451 | Low-byte | 70% | 452 +--------------+------------+ 453 | IPv4-based | 5% | 454 +--------------+------------+ 455 | SLAAC | 1% | 456 +--------------+------------+ 457 | Wordy | <1% | 458 +--------------+------------+ 459 | Privacy | <1% | 460 +--------------+------------+ 461 | Teredo | <1% | 462 +--------------+------------+ 463 | Other | <1% | 464 +--------------+------------+ 466 Table 3: Measured router addresses 468 It should be clear from these measurements that a very high 469 percentage of the client addresses follow very specific patterns. 471 3.2. IPv6 address scanning of remote area networks 473 While in IPv4 networks attackers have been able to get away with 474 "brute force" scanning attacks (thanks to the reduced search space), 475 successfully performing a brute-force scan of an entire /64 network 476 would be infeasible. As a result, it is expected that attackers will 477 leverage the IPv6 address patterns discussed in Section 3.1 to reduce 478 the IPv6 address search space. 480 IPv6 address scanning of remote area networks should consider an 481 additional factor not present for the IPv4 case: since the typical 482 IPv6 subnet is a /64, scanning an entire /64 could, in theory, lead 483 to the creation of 2^^64 entries in the Neighbor Cache of the last- 484 hop router. Unfortunately, a number of IPv6 implementations have 485 been found to be unable to properly handle large number of entries in 486 the Neighbor Cache, and hence these address-scan attacks may have the 487 side effect of resulting in a Denial of Service (DoS) attack 488 [CPNI-IPv6] [I-D.ietf-v6ops-v6nd-problems]. 490 3.3. IPv6 address scanning of local area networks 492 IPv6 address scanning in Local Area Networks could be considered, to 493 some extent, a completely different problem than that of scanning a 494 remote IPv6 network. The main difference is that use of link-local 495 multicast addresses can relieve the attacker of searching for unicast 496 addresses in a large IPv6 address space. 498 Obviously, a number of other network reconnaissance vectors (such 499 as network snooping, leveraging Neighbor Discovery traffic, etc.) 500 are available when scanning a local network. However, this 501 section focuses only on address-scanning attacks (a la "ping 502 sweep"). 504 An attacker can simply send probe packets to the all-nodes link-local 505 multicast address (ff02::1), such that responses are elicited from 506 all local nodes. 508 Since Windows systems (Vista, 7, etc.) do not respond to ICMPv6 Echo 509 Request messages sent to multicast addresses, IPv6 address-scanning 510 tools typically employ a number of additional probe packets to elicit 511 responses from all the local nodes. For example, unrecognized IPv6 512 options of type 10xxxxxx elicit ICMPv6 Parameter Problem, code 2, 513 error messages. 515 Many address-scanning tools discover only IPv6 link-local addresses 516 (rather than e.g. the global addresses of the target systems): since 517 the probe packets are typically sent with the attacker's IPv6 link- 518 local address, the "victim" nodes send the response packets using the 519 IPv6 link-local address of the corresponding network interface (as 520 specified by the IPv6 address selection rules [RFC3484]). However, 521 sending multiple probe packets, with each packet employing addresses 522 from different prefixes, typically helps to overcome this limitation. 524 This technique is employed by the scan6 tool of the IPv6 Toolkit 525 package [IPv6-Toolkit]. 527 3.4. Existing IPv6 address scanning tools 529 3.4.1. Remote IPv6 network scanners 531 IPv4 address scanning tools have traditionally carried out their task 532 for probing an entire address range (usually the entire range of a 533 target subnetwork). One might argue that the reason for which we 534 have been able to get away with such somewhat "rudimentary" 535 techniques is that the scale of the "problem" is so small in the IPv4 536 world, that a "brute-force" attack is "good enough". However, the 537 scale of the "address scanning" problem is so large in IPv6, that 538 attackers must be very creative to be "good enough". 540 Simply sweeping an entire /64 IPv6 subnet would just not be feasible. 541 For instance, that is one of the reasons for which address scanning 542 tools such as nmap [nmap2012] do not even support sweeping an IPv6 543 address range. 545 The nmap(1) manual page states "IPv6 addresses can only be 546 specified by their fully qualified IPv6 address or hostname. CIDR 547 and octet ranges aren't supported for IPv6 because they are rarely 548 useful. 550 On the other hand, the alive6 tool from [THC-IPV6] supports 551 sweeping address ranges, thus being able to leverage some patters 552 fond in IPv6 addresses, such as the incremental addresses 553 resulting from some DHCPv6 setups. 555 The most "advanced" IPv6 scanning technique that has been found in 556 the wild is that reported in [Ybema2010], in which the attacker 557 seemed to be scanning specific IPv6 addresses based on specific 558 patterns. However, the aforementioned attempt probably still falls 559 into the category of "rudimentary". 561 Clearly, a limitation of most currently-available tools is that they 562 lack of an "heuristics engine" that can help reduce the search space, 563 such that the problem of IPv6 address scanning becomes tractable. 564 However, we expect that this situation will change in the short term. 566 3.4.2. Local IPv6 network scanners 568 There are a variety of publicly-available local IPv6 network 569 scanners: 571 Current versions of nmap [nmap2012] implement this functionality 573 THC's IPv6 Attack Toolkit [THC-IPV6] includes a tool that 574 implements this functionality 576 SI6 Network's IPv6 Toolkit [IPv6-Toolkit] includes a tool (scan6) 577 that implements this functionality 579 3.5. Mitigations 581 IPv6 address-scanning attacks can be mitigated in a number of ways. 582 A non-exhaustive list of the possible mitigations includes: 584 o Employing stable privacy-enhanced addresses 585 [I-D.ietf-6man-stable-privacy-addresses] in replacement of 586 addresses based on IEEE identifiers, such that any address 587 patterns are eliminated. 589 o Employing Intrusion Prevention Systems (IPS) at the perimeter, 590 such that address scanning attacks can be mitigated. 592 o If virtual machines are employed, and "resistance" to address 593 scanning attacks is deemed as desirable, manually-configured MAC 594 addresses can be employed, such that even if the virtual machines 595 employ IEEE-derived IIDs, they are generated from non-predictable 596 MAC addresses. 598 It should be noted that some of the aforementioned mitigations are 599 operational, while others depend on the availability of specific 600 features (such as [I-D.ietf-6man-stable-privacy-addresses] on the 601 corresponding nodes. 603 Additionally, while some resistance to address scanning attacks is 604 generally desirable (particularly when lightweight mitigations are 605 available), there are scenarios in which mitigation of some address- 606 scanning vectors is unlikely to be a high-priority (if at all 607 possible). 609 Two of the techniques discussed in this document for local address- 610 scanning attacks are those that employ multicasted ICMPv6 Echo 611 Requests and multicasted IPv6 packets containing unsupported options 612 of type 10xxxxxx. These two vectors could be easily mitigated by 613 configuring nodes to not respond to multicasted ICMPv6 Echo Request 614 (default on Windows systems), and by updating the IPv6 specifications 615 (and/or possibly configuring local nodes) such that multicasted 616 packets never elicit ICMPv6 error messages (even if they contain 617 unsupported options of type 10xxxxxx). 619 [I-D.gont-6man-ipv6-smurf-amplifier] proposes such update to the 620 IPv6 specifications. 622 In any case, when it comes to local networks, there are a variety of 623 network reconnaissance vectors. Therefore, even if address-scanning 624 vectors are mitigated, an attacker could still rely on e.g. protocols 625 employed for the so-called "opportunistic networking" (such as mDNS), 626 or eventually on network snooping, for the purpose of network 627 reconnaissance. 629 4. Leveraging the Domain Name System (DNS) for Network Reconnaissance 631 4.1. DNS Advertised Hosts 633 Any systems that are "published" in the DNS, e.g. MX mail relays, or 634 web servers, will remain open to probing from the very fact that 635 their IPv6 addresses are publicly available. It is worth noting that 636 where the addresses used at a site follow specific patterns, 637 publishing just one address may lead to a threat upon the other 638 hosts. 640 Additionally, we note that publication of IPv6 addresses in the DNS 641 should not discourage the elimination of IPv6 address patterns: if 642 any address patterns are eliminated from addresses published in the 643 DNS, an attacker may have to rely on performing dictionary-based DNS 644 lookups in order to find all systems in a target network (which is 645 generally less reliable and more time/traffic consuming than mapping 646 nodes with predictable IPv6 addresses). 648 4.2. DNS Zone Transfers 650 A DNS zone transfer can readily provide information about potential 651 attack targets. Restricting zone transfers is thus probably more 652 important for IPv6, even if it is already good practice to restrict 653 them in the IPv4 world. 655 4.3. Leveraging DNS reverse mappings for network reconnaissance 657 An interesting technique that employs DNS reverse mappings for 658 network reconnaissance has been recently disclosed [van-Dijk]. 659 Essentially, the attacker walks through the "ip6.arpa" zone looking 660 up PTR records, in the hopes of learning the IPv6 addresses of hosts 661 in a given target network (assuming that the reverse mappings have 662 been configured, of course). What is most interesting about this 663 technique is that it can greatly reduce the IPv6 address search 664 space. 666 Basically, an attacker would walk the ip6.arpa zone corresponding to 667 a target network (e.g. "0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." for "2001: 668 db8:80:/32"), issuing queries for PTR records corresponding to the 669 domain names "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", 670 "1.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.", etc. If, say, there were PTR 671 records for any hosts "starting" with the domain name 672 "0.0.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa." (e.g., the ip6.arpa domain name 673 corresponding to the IPv6 address 2001:db8:80::1), the response would 674 contain an RCODE of 0 (no error). Otherwise, the response would 675 contain an RCODE of 4 (NXDOMAIN). As noted in [van-Dijk], this 676 technique allows for a tremendous reduction in the "IPv6 address" 677 search space. 679 5. Public archives 681 Public mailing-list archives or Usenet news messages archives may 682 prove a useful channel for an attacker, since hostnames and/or IPv6 683 addresses could be easily obtained by inspection of the (many) 684 "Received from:" or other header lines in the archived email or 685 Usenet news messages. 687 6. Application Participation 689 Peer-to-peer applications often include some centralised server which 690 coordinates the transfer of data between peers. For example, 691 BitTorrent builds swarms of nodes that exchange chunks of files, with 692 a tracker passing information about peers with available chunks of 693 data between the peers. Such applications may offer an attacker a 694 source of peer addresses to probe. 696 7. Inspection of the IPv6 Neighbor Cache and Routing Table 698 Information about other systems connected to the local network might 699 be readily available from the Neighbor Cache [RFC4861] and/or the 700 routing table of any system connected to such network. 702 While the requirement of having "login" access to a system in the 703 target network may limit the applicability of this technique, there 704 are a number of scenarios in which this technique might be of use. 705 For example, security audit tools might be provided with the 706 necessary credentials such that the Neighbor Cache and the routing 707 table of all systems for which the tool has "login" access can be 708 automatically gleaned. On the other hand, IPv6 worms [V6-WORMS] 709 could leverage this technique for the purpose of spreading on the 710 local network, since they will typically have access to the Neighbor 711 Cache and routing table of an infected system. 713 8. Inspection of System Configuration and Log Files 715 Nodes are generally configured with the addresses of other important 716 local computers, such as email servers, local file servers, web proxy 717 servers, recursive DNS servers, etc. The /etc/hosts file in UNIX, 718 SSH known_hosts files, or the Microsoft Windows registry are just 719 some examples of places where interesting information about such 720 systems might be found. 722 Additionally, system log files (including web server logs, etc.) may 723 also prove a useful channel for an attacker. 725 While the required credentials to access the aforementioned 726 configuration and log files may limit the applicability of this 727 technique, there are a number of scenarios in which this technique 728 might be of use. For example, security audit tools might be provided 729 with the necessary credentials such that these files can be 730 automatically accessed. On the other hand, IPv6 worms could leverage 731 this technique for the purpose of spreading on the local network, 732 since they will typically have access to these files on an infected 733 system [V6-WORMS]. 735 9. Gleaning information from Routing Protocols 737 Some organizational IPv6 networks employ routing protocols to 738 dynamically maintain routing information. In such an environment, a 739 local attacker could become a passive listener of the routing 740 protocol, to determine other valid subnets within that organization 741 [V6-WORMS]. 743 10. Security Considerations 745 This document explores the topic of Network Reconnaissance in IPv6 746 networks. It analyzes the feasibility of address-scan attacks in 747 IPv6 networks, and showing that the search space for such attacks is 748 typically much smaller than the one traditionally assumed (64 bits). 749 Additionally, it explores a plethora of other network reconnaissance 750 techniques, ranging from inspecting the IPv6 Network Cache of an 751 attacker-controlled system, to gleaning information about IPv6 752 addresses from public mailing-list archives or Peer-To-Peer (P2P) 753 protocols. 755 We expect traditional address-scanning attacks to become more and 756 more elaborated (i.e., less "brute force"), and other network 757 reconnaissance techniques to be actively explored, as global 758 deployment of IPv6 increases and. more specifically, as more IPv6- 759 only devices are deployed. 761 11. Acknowledgements 763 The author would like to thank (in alphabetical order) Marc Heuse, 764 Ray Hunter, Libor Polcak, Jan Schaumann, and Arturo Servin, for 765 providing valuable comments on earlier versions of this document. 767 Part of the contents of this document are based on the results of the 768 project "Security Assessment of the Internet Protocol version 6 769 (IPv6)" [CPNI-IPv6], carried out by Fernando Gont on behalf of the UK 770 Centre for the Protection of National Infrastructure (CPNI). 771 Fernando Gont would like to thank the UK CPNI for their continued 772 support. 774 12. References 776 12.1. Normative References 778 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 779 Requirement Levels", BCP 14, RFC 2119, March 1997. 781 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 782 (IPv6) Specification", RFC 2460, December 1998. 784 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 785 and M. Carney, "Dynamic Host Configuration Protocol for 786 IPv6 (DHCPv6)", RFC 3315, July 2003. 788 [RFC3484] Draves, R., "Default Address Selection for Internet 789 Protocol version 6 (IPv6)", RFC 3484, February 2003. 791 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 792 Network Address Translations (NATs)", RFC 4380, 793 February 2006. 795 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 796 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 797 September 2007. 799 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 800 Address Autoconfiguration", RFC 4862, September 2007. 802 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 803 Extensions for Stateless Address Autoconfiguration in 804 IPv6", RFC 4941, September 2007. 806 [I-D.ietf-6man-stable-privacy-addresses] 807 Gont, F., "A method for Generating Stable Privacy-Enhanced 808 Addresses with IPv6 Stateless Address Autoconfiguration 809 (SLAAC)", draft-ietf-6man-stable-privacy-addresses-01 810 (work in progress), October 2012. 812 12.2. Informative References 814 [I-D.ietf-v6ops-v6nd-problems] 815 Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 816 Neighbor Discovery Problems", 817 draft-ietf-v6ops-v6nd-problems-05 (work in progress), 818 March 2012. 820 [I-D.gont-6man-ipv6-smurf-amplifier] 821 Gont, F., "Security Implications of IPv6 options of Type 822 10xxxxxx", draft-gont-6man-ipv6-smurf-amplifier-00 (work 823 in progress), December 2011. 825 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 826 RFC 5157, March 2008. 828 [CPNI-IPv6] 829 Gont, F., "Security Assessment of the Internet Protocol 830 version 6 (IPv6)", UK Centre for the Protection of 831 National Infrastructure, (available on request). 833 [V6-WORMS] 834 Bellovin, S., Cheswick, B., and A. Keromytis, "Worm 835 propagation strategies in an IPv6 Internet", ;login:, 836 pages 70-76, February 2006, 837 . 839 [Malone2008] 840 Malone, D., "Observations of IPv6 Addresses", Passive and 841 Active Measurement Conference (PAM 2008, LNCS 4979), 842 April 2008, 843 . 845 [nmap2012] 846 Fyodor, "nmap - Network exploration tool and security / 847 port scanner", 2012, . 849 [VBox2011] 850 VirtualBox, "Oracle VM VirtualBox User Manual, version 851 4.1.2", August 2011, . 853 [vmesx2011] 854 vmware, "Setting a static MAC address for a virtual NIC", 855 vmware Knowledge Base, August 2011, . 859 [Ybema2010] 860 Ybema, I., "just seen my first IPv6 network abuse scan, is 861 this the start for more?", Post to the NANOG mailing- 862 list, 2010, . 865 [Gont-DEEPSEC2011] 866 Gont, "Results of a Security Assessment of the Internet 867 Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, 868 Vienna, Austria, November 2011, . 872 [THC-IPV6] 873 "THC-IPV6", . 875 [IPv6-Toolkit] 876 "IPv6 Toolkit", 877 . 879 [van-Dijk] 880 van Dijk, P., "Finding v6 hosts by efficiently mapping 881 ip6.arpa", . 884 Appendix A. Implementation of a full-fledged IPv6 address-scanning tool 886 This section describes the implementation of a full-fledged IPv6 887 address scanning tool. Appendix A.1 discusses the selection of host 888 probes. Appendix A.2 describes the implementation of an IPv6 address 889 scanner for local area networks. Appendix A.3 outlines ongoing work 890 on the implementation of a general (i.e., non-local) IPv6 host 891 scanner. 893 A.1. Host-probing considerations 895 A number of factors should be considered when selecting the probe 896 types and the probing-rate for an IPv6 address scanning tool. 898 Firstly, some hosts (or border firewalls) might be configured to 899 block or rate-limit some specific packet types. For example, it is 900 usual for host and router implementations to rate-limit ICMPv6 error 901 traffic. Additionally, some firewalls might be configured to block 902 or rate-limit incoming ICMPv6 echo request packets. 904 As noted earlier in this document, Windows systems simply do not 905 respond to ICMPv6 echo requests sent to multicast IPv6 addresses. 907 Among the possible probe types are: 909 o TCP segments meant to elicit SYN/ACK or RST segments, 911 o UDP segments meant to elicit a UDP application response or an 912 ICMPv6 Port Unreachable, an IPv6 packet containing any suitable 913 payload and an unrecognized extension header (such that a ICMPv6 914 Parameter Problem error message is elicited), or, 916 o an IPv6 packet containing any suitable payload and an unrecognized 917 option of type 10xxxxxx (such that a ICMPv6 Parameter Problem 918 error message is elicited) 920 Selecting an appropriate probe packet might help conceal the ongoing 921 attack, but may also be actually necessary if host or network 922 configuration causes certain probe packets to be dropped. In some 923 cases, it might be desirable to insert some IPv6 extension headers 924 before the actual payload, such that some filtering policies can be 925 circumvented. 927 Another factor to consider is the host-probing rate. Clearly, the 928 higher the rate, the smaller the amount of time required to perform 929 the attack. However, the probing-rate should not be too high, or 930 else: 932 1. the attack might cause network congestion, thus resulting in 933 packet loss 935 2. the attack might hit rate-limiting, thus resulting in packet loss 937 3. the attack might reveal underlying problems in the Neighbor 938 Discovery implementation, thus leading to packet loss and 939 possibly even Denial of Service 941 Packet-loss is undesirable, since it would mean that an "alive" node 942 might remain undetected as a result of a lost probe or response. 943 Such losses could be the result of congestion (in case the attacker 944 is scanning a target network at a rate higher than the target network 945 can handle), or may be the result of rate-limiting as it would be 946 typically the case if ICMPv6 is employed for the probe packets. 947 Finally, as discussed in [CPNI-IPv6] and 948 [I-D.ietf-v6ops-v6nd-problems], some IPv6 router implementations have 949 been found to be unable to perform decent resource management when 950 faced with Neighbor Discovery traffic involving a large number of 951 local nodes. This essentially means that regardless of the type of 952 probe packets, a address scanning attack might result in a Denial of 953 Service (DoS) of the target network, with the same (or worse) effects 954 as that of network congestion or rate-limiting. 956 The specific rates at which each of these issues may come into play 957 vary from one scenario to another, and depend on the type of deployed 958 routers/firewalls, configuration parameters, etc. 960 A.2. Implementation of an IPv6 local address-scanning tool 962 scan6 [IPv6-Toolkit] is prototype IPv6 local address scanning tool, 963 which has proven to be effective and efficient for the discovery of 964 IPv6 hosts on a local network. 966 The scan6 tool operates (roughly) as follows: 968 1. The tool learns the local prefixes used for auto-configuration, 969 an generates/configures one address for each local prefix (in 970 addition to a link-local address) 972 2. An ICMPv6 Echo Request message destined to the all-nodes on-link 973 multicast address (ff02::1) is sent with each of the addresses 974 "configured" in the previous step. Because of the different 975 Source Addresses, each probe causes the victim nodes to use 976 different Source Addresses for the response packets (this allows 977 the tool to learn virtually all the addresses in use in the local 978 network segment). 980 3. The same procedure of the previous bullet is performed, but this 981 time with ICMPv6 packets that contain an unrecognized option of 982 type 10xxxxxx, such that ICMPv6 Parameter Problem error messages 983 are elicited. This allows the tool to discover e.g. Windows 984 nodes, which otherwise do not respond to multicasted ICMPv6 Echo 985 Request messages. 987 4. Each time a new "alive" address is discovered, the corresponding 988 Interface-ID is combined with all the local prefixes, and the 989 resulting addresses are probed (with unicasted packets). This 990 can help to discover other addresses in use on the local network 991 segment, since the same Interface ID is typically used with all 992 the available prefixes for the local network. 994 The aforementioned scheme can fail to discover some addresses for 995 some implementation. For example, Mac OS X employs IPv6 addresses 996 embedding IEEE-identifiers (rather than "privacy addresses") when 997 responding to packets destined to a link-local multicast address, 998 sourced from an on-link prefix. 1000 A.3. Implementation of a IPv6 remote address-scanning tool 1002 An IPv6 remote address scanning tool, could be implemented with the 1003 following features: 1005 o The tool can be instructed to scan devices manufactured by a 1006 specific vendor, such that only addresses resulting for the 1007 corresponding OUIs are tried 1009 o The tool can be instructed to discover virtual machines, such that 1010 a given IPv6 prefix is only scanned for the address patterns 1011 resulting from virtual machines (as discussed earlier in this 1012 document) 1014 o The tool can be instructed to scan for low-byte or DHCPv6-like 1015 addresses 1017 o The tool can be instructed to scan for wordy-addresses, in which 1018 case the tool selects addresses based on a local dictionary 1020 o The tool can be specified an IPv4 address range in use at the 1021 target network, such that only IPv4-based IPv6 addresses are 1022 scanned. 1024 In brute force mode, the tool can, at the very least: 1026 o Skip addresses resulting from unassigned OUIs 1027 o Skip addresses resulting from OUIs deemed as "legacy" 1029 Authors' Addresses 1031 Fernando Gont 1032 Huawei Technologies 1033 Evaristo Carriego 2644 1034 Haedo, Provincia de Buenos Aires 1706 1035 Argentina 1037 Phone: +54 11 4650 8472 1038 Email: fgont@si6networks.com 1039 URI: http://www.si6networks.com 1041 Tim Chown 1042 University of Southampton 1043 Highfield 1044 Southampton, Hampshire SO17 1BJ 1045 United Kingdom 1047 Email: tjc@ecs.soton.ac.uk