A Sampling of Internetwork
Security Issues Involving IPv6
John Kristoff
Agenda
• diff -u ipv4 ipv6 | head
• What is the netsec community working on? • How do the usual threats change, if they do?
• What new headaches arise with the transition glue? • What are the miscreants doing?
96 more bits, no magic?
• OS protocol stack software and APIs • Address manipulation and storage • Neighbor discovery
• Auto-configuration • ICMPv6
• Fragmentation on an end-to-end basis only • Network and security tools
• Transition technologies
Current IETF Work
• dhcpv6-shield (opsec) • ipv6-host-scanning (opsec) • lla-only (opsec) • ipv6 (opsec) • ipv6-implications-on-ipv4-nets (opsec) • nd-security (opsec) • nd-extension-headers (6man) • predictable-fragment-id (6man) • stable-privacy-addresses (6man)Current IETF Work (continued)
• ipv6-smurf-amplifier (6man) • mitigate-nd-cache-dos-slnd (6man) • design-choices (v6ops) • enterprise-incremental-ipv6 (v6ops) • nat64-experience (v6ops) • ra-guard-implementation (v6ops) • ula-usage-recommendations (v6ops) • fragdrop (v6ops) • dc-ipv6 (v6ops)Scanning
• Scans of the entire address space impractical
• “intelligent” address scanning imperfect, but practical • DNS enumeration
• Non-random addresses
• SLAAC address space with known OUIs • Multicast discovery
• Local neighbor discovery messages
Spam
• Surprise, spam travels over IPv6 transport • Many DNSBLs have used rbldnsd
• When it comes to IPv6, rbldnsd just doesn't scale • Some software and usage changes required
• This is true for any IP address reputation system
Routing
• Fair amount of focus on extension header issues • Neighbor cache maintenance issues
• e.g. IETF RFC 6547 (using /127's for IRLs) • Team Cymru IPv6 full bogons service
• IETF RFC 6666 – A Discard Prefix for IPv6 • Additional consideration likely needed here:
• Aggregation / disaggregation / hijack events • Control plane protection for IPv6 transport
Packet Flooding / DoS
• Some evidence of IPv6-specific DoS
• Single D, not seeing evidence of IPv6-specific DDoS • Some unintentional use of IPv6 transport for DDoS • Mostly IRC-based miscreants experimenting with it
Local Network Threats
• Router advertisements (RAs) presents a challenge • As does much of the neighbor discovery mechanisms • Who do you trust? How do you trust them?
• Similar to the known threats with ARP and DHCP
• SEcure Neighbor Discovery (SEND) – IETF RFC 3971 • Also see IETF RFC 3756
• IPv6 Neighbor Discovery Trust Models and Threats • 6Guard: a honeypot-based IPv6 attack detector
Transition Technologies
• 6in4/6to4/6rd/ISATAP/Teredo/tunnel brokers, OH MY! • Are protections congruent?
• Can you monitor them? Mitigate problems over them? • Whose relay? Do they monitor? Do you trust them?
%#@!#&$ NAT
• NAT just makes my life harder
• As pro-NAT a statement I could make, IETF RFC 5902 • IAB Thoughts on IPv6 Network Address Translation • Next slide PLEASE!
An IPv6 Business Case is Born
• March 17, 2003
<A> get an ipv6 host ./packetpeople wont know what to do
<B> A we have ipv6
<C> most packet kiddies cant hit ipv6 yet <D> Im testing a ipv6 scanner i just made <E> i seen someone make a ddos for
ipv6/ipv4
IPv6 4SALE in the Underground
• November 11, 2003
<A> Got E-Gold Accounts, PayPaL Accounts, Vhosted Shells (ushells.net), Vhosts
( ipv4 - ipv6 ), Full Domin, Root, Root Scan, Root Nuke, Proxy Serv, Fresh CC's, Fresh Cvv2 I Verify 1st
Hiding behind the IPv6
• More recently:
<A> ./gem -h 192.0.2.1 -T0 -t 15000 <B> that should do it
<A> i got 5000mbit hitting
<C> v6 is back up on X and Y just new ips <C> D got our vps working as a tunnel
broker now <C> need a /64?
udp6.pl, udp.pl w/ IPv6 transport
• http://example.com/udp6.pl <-- working ipv6ddos
flood.pl --port=dst-port --size=pkt-size --time=secs --bandwidth=kbps --delay=msec ip-address [-6]
Defaults:
* random destination UDP ports are used unless --port is specified
* random-sized packets are sent unless --size or --bandwidth is specified * flood is continuous unless --time is specified
* flood is sent at line speed unless --bandwidth or --delay is specified * IPv4 flood unless -6 is specified
IRC bot with TCP over v6 DDoS
• elxbot bot ++ipv6_attacker addin wich actually worx!
=~ /^ipv6flood\s+(.+)\s+(\d+)\s+(\d+)/ […]
sub tcp6 { […]
my @SOCKET6;
while($_[3] > (time - $s_time)) { for(my $i=0;$i<200;$i++) { socket6($SOCKET6[$i], PF_INET6, SOCK_STREAM, getprotobyname('tcp')); […]
Dissent on DDoS Resilience
<A> no its nearly impossible to ddos an ipv6 connection
<B> average bitch ddos kiddies couldn't ddos ipv6
<C> i only know 2 people that know how to ddos ipv6
<D> and its impossible to ddos ipv6 <E> i can ddos ipv6 tunnel down
Who Took Down Their Routers?
• Very large hosting provider site in Chicago goes dark • Carefully aimed DDoS at infrastructure router
• Routing protocol packets being dropped
• Remedied with streamlined control plane filters • Miscreant controlled via IRC from an IPv6 bounce
PING Flood
• 1 Gb/s ICMPv6 echo requests sent to IRC server
• Random source-address spoofed by a single source • uRPF briefly enabled, but that feature melted router • Source ISP eventually “fixed” the host
What We (Don't) See Today
• IPv6 is widely used as a transport, but rarely a platform • IPv6 dark nets are dark
• Very little IPv6-specific malware
• Anecdotal evidence of malware using IPv6 as transport • Some evidence of miscreants using IPv6 to hide origin • Some evidence of using IPv6 to hide from monitoring • Some evidence of using IPv6 to mitigate retribution • Useful and necessary IPv6 threat research ongoing • Relatively little IPv6 opsec measurement occurring
