1 / 8

IPv6 Implications for Network Scanning

IPv6 Implications for 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

tess
Télécharger la présentation

IPv6 Implications for Network Scanning

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPv6 Implicationsfor Network Scanning Tim Chown University of Southampton (UK) tjc@ecs.soton.ac.uk IETF 66, July 12th 2006 Montreal

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

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

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

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

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

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

  8. 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?

More Related