Understanding IPv6 Network Scanning: Security Implications and Mitigation Strategies
This document explores the unique properties of IPv6 networks relevant to network scanning and identifies potential new attack vectors for host address discovery. It emphasizes the limitations of relying on IPv6 subnet size for security and offers practical measures for network administrators to mitigate risks associated with scanning methods. The document is structured into three main sections: the IPv6 subnet size problem, alternative address-harvesting methods, and actionable recommendations for enhancing security. It also invites feedback and anecdotal evidence regarding observed network behavior.
Understanding IPv6 Network Scanning: Security Implications and Mitigation Strategies
E N D
Presentation Transcript
IPv6 Implicationsfor Network Scanning Tim Chown University of Southampton (UK) tjc@ecs.soton.ac.uk IETF 66, July 12th 2006 Montreal
Purpose of document • Document different properties of IPv6 networks for network scanning • Suggest possible new attack vectors for discovery of host addresses to target • By the usual scanning method • Recommend measures that network administrators may take to mitigate these
Recent changes • In a past life this document used to be • draft-chown-port-scanning-implications-02 • Adopted by WG • Received a number of comments • Improvements: • Addressed comments • Changed to a new structure based on comments
Comments addressed • Avoided any suggestion that IPv6 subnet size makes networks resilient to network scanning • Because other methods to harvest addresses exist • Attackers will scan addresses that they can learn • Restructured to 3 sections: • IPv6 subnet size ‘problem statement’ • Alternative address harvesting methods • Recommendations/suggestions for admins
Subnet size implications • Problem space for IPv6 scanning • Huge subnet size (64 bits) • But can be reduced by heuristics • Systems numbered ::1, ::2, etc • Autoconfiguration uses fixed ‘fffe’ stuffing • Well-known vendor NIC prefixes • Sequential NIC IDs in batches of systems • Dual-stack systems still ‘vulnerable’ via IPv4 • May wish to perform defensive scanning
Alternatives for attackers • ‘New’ ways to harvest IPs • On-link methods • Multicast (including site scope) • Logged or recorded Ips • DNS advertised hosts • DNS zone transfers • Application participation • Transition methods
Measures for admins? • Consider using Privacy Addresses (RFC3041) • Reduces ‘useful lifetime’ of address to attacker who has harvested the address by some means • Adds complexity for network management • Consider DHCPv6 address pools • Don’t allocate from ::1 upwards • Avoid using sequential addresses • Consider rolling server IP addresses • e.g. change advertised MX addresses over time
Next Steps • Comments? • Any anecdotal evidence of (mis)behaviour seen at site firewalls? • Author sees port scanning on advertised IPs • Cited by three(?) other current IDs • WGLC?
