On several occasions, I've had a need to run quick, small-scale network scans of externally-accessible IPv6 systems. While it's never been easier to set up a tunnel on a hosted system, or, better yet, rent a system from a provider offering native IPv6 connectivity, I was interested in running these scans with minimal setup, and from a local laptop, without the need to connect to an external system.
I recently enabled the mobile hotspot feature on my Android phone, and noticed that when connecting through this hotspot the wireless interface on my laptop receives a global IPv6 address, in addition to a link-local scope address and IPv4 address. For example:
$ ifconfig wlan0
Link encap:Ethernet HWaddr 00:27:10:12:4d:10
inet addr:192.168.34.42 Bcast:192.168.34.255 Mask:255.255.255.0
inet6 addr: fe80::227:10ff:fe12:4d10/64 Scope:Link
inet6 addr: 2600:100c:b034:39ae:227:10ff:fe12:4d10/64 Scope:Global
I decided to check out the capabilities of this connection, in terms of outbound connectivity, speed, reliability, and filtering or otherwise prohibited traffic, to determine its suitability for such tasks. (As always, check the terms of use with your ISP before conducting significant scanning activity.)
First, I browsed to http://ipv6.whatismyv6.com/ (URL only accessible via IPv6), and checked that the global address displayed locally is the address seen by remote systems that I connect to. This confirms that no intrusive NAT or proxy activity is performed on outbound connections.
I performed several basic connectivity tests to confirm the IPv6 connection. I first resolved the IPv6 address for the web server, and browsed to the site using the address:
$ host -t AAAA ipv6.whatismyipv6.com
ipv6.whatismyipv6.com has IPv6 address 2001:4870:a24f:2::90
I also confirmed connectivity to Google's IPv6 server, using ping6:
$ host -t AAAA www.google.com
www.google.com has IPv6 address 2607:f8b0:4000:803::1012
$ ping6 2607:f8b0:4000:803::1012
PING 2607:f8b0:4000:803::1012(2607:f8b0:4000:803::1012) 56 data bytes
64 bytes from 2607:f8b0:4000:803::1012: icmp_seq=1 ttl=54 time=329 ms
64 bytes from 2607:f8b0:4000:803::1012: icmp_seq=2 ttl=54 time=69.0 ms
64 bytes from 2607:f8b0:4000:803::1012: icmp_seq=3 ttl=54 time=67.6 ms
64 bytes from 2607:f8b0:4000:803::1012: icmp_seq=4 ttl=54 time=65.8 ms
^C
--- 2607:f8b0:4000:803::1012 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 65.899/133.045/329.631/113.504 ms
I used Nmap's built-in IPv6 scanning capability to port scan this host:
root@laptop$ nmap -v -6 -oA /tmp/www.google.com-6-tcp -p 0-65535 2607:f8b0:4000:803::1012
<...>
Nmap done: 1 IP address (1 host up) scanned in 284.60 seconds
This scan took slightly under five minutes, and identified two open ports, five closed ports, and the remainder filtered:
$ cat /tmp/www.google.com-6-tcp.xml | grep "state=\"open\"" | wc -l
2
$ cat /tmp/www.google.com-6-tcp.xml | grep "state=\"closed\"" | wc -l
5
$ cat /tmp/www.google.com-6-tcp.xml | grep "extraports state"
<ports><extraports state="filtered" count="65529">
For purposes of comparing performance and identifying any ISP-level filtering, I ran the same scan from a native IPv6 hosted server:
root@linode$ nmap -v -6 -oA /tmp/www.google.com-6-tcp -p 0-65535 2607:f8b0:4000:803::1012
<...>
Nmap done: 1 IP address (1 host up) scanned in 104.69 seconds
This scan took less than half the time -- under two minutes, but produced the same results: two open ports, five closed, and the remainder filtered.
$ cat /tmp/www.google.com-6-tcp.xml | grep "state=\"open\"" | wc -l
2
$ cat /tmp/www.google.com-6-tcp.xml | grep "state=\"closed\"" | wc -l
5
$ cat /tmp/www.google.com-6-tcp.xml | grep "extraports state"
\<ports><extraports state="filtered" count="65529">
This confirms that no outbound TCP traffic filtering affects the mobile hotspot IPv6 connection.
Interestingly, the results for these scans differ slightly from those for the corresponding IPv4 hosts:
root@laptop$ nmap -v -p 0-65535 www.google.com
Starting Nmap 6.02 ( http://nmap.org ) ( http://nmap.org ) at 2013-02-26 00:46 CST
Scanning www.google.com (74.125.225.180) [65536 ports]
Not shown: 65533 filtered ports
PORT STATE SERVICE
80/tcp open http
443/tcp open https
1720/tcp open H.323/Q.931
As has been pointed out by others, this serves as a reminder to scan both addresses, if accessible. Comparing results can identify differences in the configuration (or absence) of firewall protections, as well as different service listening profiles.
To verify and expand upon these initial results, I decided to scan a larger number of IPv6 hosts. NIST's Advanced Network Technologies Division (ANDT) tracks the U.S. federal government's external deployment of IPv6 (and DNSSEC) technologies. (Their methodology is documented.)
I pulled down data from the 'Detailed IPv6 & DNSSEC Service Interface Statistics' chart on March 7, 2013, and worked it into suitable Nmap scan input format:
$ cat /tmp/fed-ipv6 | cut -d "," -f1,2,5 | grep -v "0/0/0" > /tmp/gov-ipv6-web-partial.csv
After sorting, the script randomly chose 10 unique IPv6 addresses. (Note that the script above limits the output to the first 25 domains with an IPv6-accessible website; as of this date, there are 1384 total domains tracked, 384 of which host an IPv6-accessible website.)
Port scans from the native IPv6 hosted system:
root@linode$ nmap -v -6 -oA outputs/nmap/web-ipv6s -iL /tmp/web-ipv6s-10
<...>
Nmap done: 10 IP addresses (10 hosts up) scanned in 25.40 seconds
root@linode$ cat outputs/nmap/web-ipv6s.xml | grep "state=\"open\"" | wc -l
15
root@linode$ cat outputs/nmap/web-ipv6s.xml | grep "state=\"closed\"" | wc -l
3
root@linode$ cat outputs/nmap/web-ipv6s.xml | grep "extraports state=\"filtered\"" | wc -l
10
Identical scan from the mobile hotspot-connected laptop:
root@laptop$ nmap -v -6 -oA /tmp/nmap-web-ipv6s -iL /tmp/web-ipv6s-10
<...>
Nmap done: 10 IP addresses (10 hosts up) scanned in 85.34 seconds
root@laptop$ cat /tmp/nmap-web-ipv6s.xml | grep "state=\"open\"" | wc -l
16
root@laptop$ cat /tmp/nmap-web-ipv6s.xml | grep "state=\"closed\"" | wc -l
3
root@laptop$ cat /tmp/nmap-web-ipv6s.xml | grep "extraports state=\"filtered\"" | wc -l
10
Interestingly, one more service is reported up from the laptop-based scan, which was confirmed using Ncat. This appears to be due to a difference in how the hotspot connection handles "IPv4-mapped" IPv6 addresses presented by a hybrid dual stack implementation, opting to use IPv4 connectivity in spite of software instructions (from Nmap, Ncat) to the contrary.
The native stack on a Linode hosted system does not exhibit this behavior, and thus does not identify this service, which is appropriate since it is not actually listening on an IPv6 interface.
Aside from this slight discrepancy, these tests confirm that scanning results are consistent between a mobile hotspot client and a native IPv6 system, albeit at less than 1/3 of the speed. The performance disparity increased significantly during additional tests targeting a larger number of systems, and all 65536 TCP ports, indicating that this technique should not be relied upon for large-scale scanning.
One additional, related point to note: while outbound TCP traffic from the IPv6 mobile hotspot appears not to be restricted, inbound traffic most certainly is. This was determined by running Ncat listeners on several ports from the laptop, with the local firewall disabled. None of these services were accessible from a remote server. Likewise, ICMP activity was filtered. Therefore, this technique should not be relied upon for connect-back shells from target systems, inbound file transfers, or similar connections requiring remotely-initiated connections.
No comments:
Post a Comment