Feb 17 2022

Who is squatting IPv4 addresses?

It’s an established fact on the internet that we have ran out of IP(v4) addresses, and we are starting to see the pressure on obtaining IPv4 space. For example if you want to get a /24 block from RIPE NCC when you sign up as a member, then you are currently looking at a 2 month wait for a recycled IPv4 /24 block.

The easy thing here is to say, “Well just use IPv6” but well… We are getting there slowly.

But what happens if you have run out of local IPv4 space? Or for some reason the RFC1918 Private network space is not an option anymore? Some people resort to squatting IP address space!

For the case of this post, I will define IP address squatting as “using IP addresses that are not RFC1918 defined and not your unicast space issued by a RIR”. The first thing that instantly comes to mind is Cloudflare obtained the addresses 1.1.1.1 and 1.0.0.1 to run a DNS resolver on, but had to fight back against a huge amount of network and home routers squatting on those addresses internally (I do also wonder if the last unicast /24 block has similar issues)

This problem is not that surprising though, your local friendly sysadmin might be able to tell you of a story where they have caught their colleagues, customers, or even parents squatting on addresses.

But how big of an issue is this? If only we had a large amount of well known IP address blocks that we can make a safe bet on not being used.

Enter the US Department of Defence

At the start of 2021, the DoD started to announce huge sections of their massive IP block allocations ( around 234000 /24’s worth ) out of AS8003, and then moved them to AS749. This was initially suspected to be preparation of an IP sell off, since the cost of v4 addressing has reached impressive highs recently. However later on the Pentagon said:

" This pilot will assess, evaluate, and prevent unauthorized use of DoD IP address space "

To me this reads as, “We don’t want our large IP blocks that are mostly unannounced in the BGP DFZ hijacked by people” and at the same time “We have some people who want to run a massive darknet“

Running on these assumptions, we can assume that whatever is announced by AS749 is unused DoD space, and so anything on the internet pointing to those blocks is squatting (either by typo or purpose) to at least some degree (assuming it’s not a DoD site itself)

But how do we know what is pointing to anything on the internet? How do we get massive amounts of DNS Data?

Enter Certificate Transparency

There are many ways to get DNS data, You can obtain most TLD’s DNS zone files by simply asking them, you could use Passive DNS services that obtain their data generally by tapping users DNS logs, or you could use Certificate Transparency (CT) logs to extract DNS names out of SSL certs.

I am already using the CT option for DNS data on bgp.tools. Approximately every 2 weeks I complete around ~30B DNS queries and compile into a file that is just IP addresses mapping to host names. This allows the website to easily show what DNS records point to an IP address block.

There are other tools to look into CT logs too, Cloudflare run a decent site that shows statistical numbers and graphs and for searching CT logs without downloading them all there is a great utility called crt.sh that Sectigo operates (A rebranding of Comodo).

But how do we use this data to figure out cases of IP squatting, especially inside local LANs where we would not generally expect to see public DNS entries pointing to them?

Enter the WD MyCloud

Western Digital released a bunch of compact NAS devices that also have a remote access feature (Hence the “My-Cloud” branding). This allows users to access their devices remotely even if they are outside of the local network that the device is on. However, since it’s generally a requirement to have these kinds of connections be encrypted, WD issues SSL certs for each one of these devices, Plex and other applications do a similar thing in order to allow secure connections in browsers.

Using this fact, we can scan for these WD Devices by grepping for the domain that these devices use called remotewd.com:

[xxx.bgp.tools] $ pv mega | grep remotewd.com$ > remote-wd
20.5GiB 0:00:30 [ 689MiB/s] [============================>] 100%            
[xxx.bgp.tools] $ wc -l remote-wd
2248019 remote-wd
[xxx.bgp.tools] $ tail remote-wd
223.255.150.74,device-0675828b-2e8c-4be5-96e7-0a595fbae6dc.remotewd.com
223.255.150.74,device-9e007f60-c53d-43dd-8743-4ac1a569952e.remotewd.com
223.255.156.58,device-190d10b4-2465-4d52-91e1-fc223885a510.remotewd.com
223.255.157.74,device-d3a1aa96-f383-467f-a9ae-dfa8b7bfdb81.remotewd.com
223.255.255.67,device-local-c3712a54-3c25-442e-90ee-a56c02ad9db4.remotewd.com

So here we can see that a single MyCloud device has two DNS names. device-$UUID.remotewd.com and device-local-$UUID.remotewd.com. The difference is the device-local one’s map to the local address on the device, and the device- one’s map to the Internet address (accounting for NAT). Presumably the WD devices are doing a form of automatic port forwarding like UPNP.

The neat thing is that we can find one UUID and use it to grep for both the WAN address and the LAN address of a device:

[xxx.bgp.tools] $ cat remote-wd | grep 0675828b-2e8c-4be5-96e7-0a595fbae6dc
192.168.1.103,device-local-0675828b-2e8c-4be5-96e7-0a595fbae6dc.remotewd.com
223.255.150.74,device-0675828b-2e8c-4be5-96e7-0a595fbae6dc.remotewd.com

So, great! Now we can write a script to go and find abnormal LAN addresses for these devices. We do this by checking that the local address does not match the internet address, and that the local IP address space is outside of IP ranges defined by RFC1918.

With a small-ish program we get this: (click here for a full dump)

1.0.0.117 = 8ece6a15-2fed-420d-95dd-d920d5666869 is a IP squat?
1.0.0.132 = ecd4bff4-01a5-40d6-8e70-cc9e102de492 is a IP squat?
...
1.1.10.15 = 09a3b350-27a6-45f1-b44d-f152cbcb3e4c is a IP squat?
1.1.1.111 = ab7cb7f7-ae9a-4390-a526-99248ac55593 is a IP squat?
1.1.1.1 = 4c0fe0e5-8f84-43e4-9cba-b76f9cddb368 is a IP squat?
1.1.1.17 = 44836275-6825-4767-8b70-a5e04c4a820e is a IP squat?
...
2.12.1.6 = cb578ebe-9319-4451-950c-e03ece3549b7 is a IP squat?
2.2.2.162 = 971ad945-056c-40b2-9e68-ffa7bed37da8 is a IP squat?
2.2.2.249 = f1b13fbb-6297-4ac0-9724-5ce2bbfa9f91 is a IP squat?
2.2.2.38 = cf92953b-e625-4bdf-9229-ab3933f18d9b is a IP squat?
2.43.1.33 = a26d4b29-4145-48eb-a439-64ca4a6aa9f9 is a IP squat?
...
4.28.65.10 = b9fd42f2-3491-4775-9d3d-dce4bc89ae5b is a IP squat?
4.3.80.8 = ee009944-4054-43fa-a7f7-08927ea86cfb is a IP squat?
4.4.4.3 = a5ad8ecd-93b1-4690-b21a-4322cd5e02cb is a IP squat?
4.8.19.16 = 733745f3-e9e0-4a7d-abb1-d5cc0aaf0b30 is a IP squat?
...
5.35.1.156 = f2325dc8-a79e-41e7-bd99-fe30d6afa25a is a IP squat?
5.5.1.75 = d69d77c9-181c-441f-af19-c881880534db is a IP squat?
...
8.34.143.56 = 4fb6a202-98f1-4e98-92ec-9357ecb1c4eb is a IP squat?
8.8.8.92 = 78a897cb-48d1-46c0-ba91-66c353bab06c is a IP squat?
8.9.80.111 = 28968a74-edc2-42ce-b7d0-5416f958245c is a IP squat?
...
9.9.52.93 = f4a6f3c1-5c44-4fb5-b96c-7203272cc297 is a IP squat?
9.9.9.24 = 10df8b8b-74cb-4230-a236-12105de7173e is a IP squat?
9.9.9.38 = 8b9707fa-7b59-49dd-b7a3-4ef5b88659ff is a IP squat?
11.0.0.103 = d13da0c6-8e6e-43fb-8109-a35d6b469101 is a IP squat?
11.0.0.113 = 55364bcd-389d-4464-aa71-c2fc87dfb2bf is a IP squat?
11.0.0.16 = 5502da73-a1dc-4e90-b21c-8d30c76058cf is a IP squat?
...
99.99.99.91 = f95c5933-eaf9-48ce-a87a-cf9567df305b is a IP squat?
100.0.0.100 = 5349507f-d05b-496e-93b5-9766e948b8d2 is a IP squat?
100.0.0.10 = 12d38773-813e-49cc-bdd7-48a884fcf829 is a IP squat?
...
168.190.30.15 = a3f43288-2d34-4764-ba13-65a1e00dded0 is a IP squat?
168.192.0.252 = 6a8248c2-9a35-47c7-8061-469faa7adbac is a IP squat?
168.192.0.34 = fb2cf7f1-0a3b-42d0-b04d-8d816d69a3bb is a IP squat?
168.192.110.102 = 183be2ee-4913-45f2-867f-40c5038f757b is a IP squat?
168.192.1.111 = bba93f2f-32d3-41e0-ab98-0c08f6d2b438 is a IP squat?
168.192.1.12 = cb1fcb60-a0ff-474a-b8a2-9f6246e5f3d9 is a IP squat?
168.200.1.6 = 95e5745c-a102-4ccd-92aa-651eaf0af006 is a IP squat?
...
192.167.4.118 = a84e8794-cae0-4e9a-ba8a-fce18f7e6a0f is a IP squat?
192.167.60.157 = 4d24f693-e9ea-4e70-b945-478a1fdabfb0 is a IP squat?
192.169.0.100 = 5f48efb9-a7d4-45d3-8ba3-e4234daff96c is a IP squat?
192.169.0.100 = da4b9dc3-6d99-4eb7-a67b-ab244515baf9 is a IP squat?
192.169.0.100 = e050a252-9636-4a89-ac2a-02a4acb6bb8a is a IP squat?
...
193.167.1.38 = 6481ac7d-c5b4-4ba6-ae9e-166a8ff76a15 is a IP squat?
193.168.0.178 = 37b18ba6-f01c-4f4d-a08c-48450c6d47af is a IP squat?
193.168.100.41 = 0ce6f895-d82a-479e-bd7f-b873418582e7 is a IP squat?
...

It appears that triplets are popular (IE, 1.1.1.X, 2.2.2.X, 3.3.3.X), and common “fat fingering” of RFC1918 ranges, with 193.168.X.X, 191.168.X.X, 192.186.X.X showing up.

Triplets are likely to collide with popular anycast DNS resolvers, like Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, Quad9’s 9.9.9.9, UK Government DNS 25.25.25.25, Freenom’s 80.80.80.80 , Quad101, 114dns.com, etc.

The typos are just unfortunate. But what about possible squats? Well we can look up the announcing ASNs of the IP list using the bgp.tools bulk lookup API:

$ echo "begin" >> lookup-file
$ echo "verbose" >> lookup-file
$ cat output-sorted.txt | awk '{print $1}' >> lookup-file
$ echo "end" >> lookup-file

$ cat lookup-file - | nc bgp.tools 43  | tee resolved-list
13335   | 1.0.0.117        | 1.0.0.0/24          | US | ARIN     | 2010-07-14 | Cloudflare, Inc.
13335   | 1.0.0.132        | 1.0.0.0/24          | US | ARIN     | 2010-07-14 | Cloudflare, Inc.
...
9644    | 223.61.1.108     | 223.48.0.0/12       | KR | APNIC    | 0001-01-01 | SK Telecom

$ cat resolved-list | wc -l
3585

$ cat resolved-list | egrep '^749 ' | wc -l
171

So out of all the suspected IP squats detected using the WD MyCloud data, around 5% of them are on suspected unused DoD space.

We can also run this in reverse and figure out the most common RFC1918 space that people use:

$ ./wd-stats | sort -n 
     7,192.0.2.0/24
    10,198.18.0.0/15
    55,192.0.0.0/24
   216,100.64.0.0/10
   850,169.254.0.0/16
 87328,10.0.0.0/8
 10773,172.16.0.0/12
966115,192.168.0.0/16

But this only covers residential/prosumer markets who would stereotypically purchase a device like this. What about the “proper” server world?

Enter the AWS VPC Endpoint

AWS Virtual Private Clouds (VPCs) (think of them like network LANs) have a fun feature called “Interface Endpoints” that allow you to put AWS services (like S3) that would normally only be reachable on public address spaces to appear as local IP addresses in your VPC address space. This is useful since it can remove the need for some servers to have any outbound internet access at all. Assisting in security posture amongst other things.

But since people also want to communicate with AWS securely, even inside the presumably high security of AWS VPCs, the new interface endpoint needs an SSL cert and a DNS entry. This is useful since it gives us a clue on who is using what IP addresses inside their VPC’s.

$ pv mega | grep vpce- | grep vpce.amazonaws.com > vpc-endpoints
$ wc -l vpc-endpoints 
234919 vpc-endpoints

$ ./vpc-stats | sort -n
     1,192.0.0.0/24
     2,192.0.2.0/24
     5,198.18.0.0/15
   741,100.64.0.0/10
  1096,192.168.0.0/16
 14199,172.16.0.0/12
 23677,10.0.0.0/8

We can see that 10.0.0.0/8 and 172.16.0.0/12 are popular picks for VPC addresses. But what about possible squats?

It’s worth saying now, it’s possible that some of these are not IP Squats and are instead Bring Your Own IP inside of Amazon, or complex Direct Connect setups. But if we see DoD AS749 then we can assume those are cases of IP squatting.

$ ./vpc-stats  | tee vpc-output | sort -n | head
1.100.126.10 ,bucket.vpce-0b3bb7a5b64eb1981-ymxb0boe-eu-west-1b.s3.eu-west-1.vpce.amazonaws.com
1.100.126.10 ,bucket.vpce-0b3bb7a5b64eb1981-ymxb0boe.s3.eu-west-1.vpce.amazonaws.com
1.2.3.26 ,bucket.vpce-08ed65ca57dce3ab4-i01pkug2-us-gov-west-1b.s3.us-gov-west-1.vpce.amazonaws.com
3.230.20.24 ,bucket.vpce-018d369d104a616c8-a0sfaap3.beta.s3.us-east-1.vpce.amazonaws.com
4.0.1.68 ,bucket.vpce-0e90ca15c8f461fd9-zl6yishp-ap-northeast-2a.s3.ap-northeast-2.vpce.amazonaws.com
4.0.2.137 ,bucket.vpce-0e90ca15c8f461fd9-zl6yishp-ap-northeast-2c.s3.ap-northeast-2.vpce.amazonaws.com
...

And the same checks for suspected DoD IP squats (full data here):

$ cat vpc-ips - | nc bgp.tools 43 | tee vpc-ips-resolved
4766    | 1.100.126.10     | 1.96.0.0/12         | KR | APNIC    | 0001-01-01 | Korea Telecom
0       | 1.2.3.26         | <nil>               |    | Unknown  | 0001-01-01 | ERR_AS_NAME_NOT_FOUND
14618   | 3.230.20.24      | 3.224.0.0/12        | US | ARIN     | 2005-11-04 | Amazon.com, Inc.
3356    | 4.0.1.68         | 4.0.0.0/9           | US | ARIN     | 2000-03-10 | Lumen (Level 3)
...


$ wc -l vpc-ips-resolved 
829 vpc-ips-resolved

$ cat vpc-ips-resolved | egrep '^749 ' | wc -l
138

Using this limited view inside of VPC Subnets, we can see that over 16% of all of the non-RFC1918 space is suspected squatted DoD space!

Enter the IPv4 address market

As we can see, while the DoD is sitting on some huge volumes of IPv4 space, buying the space off them might require additional work to “clean up” decades of assumptions that it was unlikely to become reachable internet addresses.

At the time of writing the market price for an IPv4 address is around 50 USD, this means that assuming AS749 is the DoD’s “spare” blocks then using naive maths the US Department of Defence is sitting on approx 2,997,516,800 USD worth of IP addresses.

That’s quite a lot! Though it’s worth keeping in mind that assuming that the cost of a F-35 fighter jet is 78M USD, then they could exchange their entire spare IP blocks for “just” 38 F-35’s. Doesn’t really seem like much. Also given how much money countries spend on defence, I can understand why the DoD doesn’t seem to be trying to cash out on their IP space just yet ;)

An amusing thought really. That the price of a /12 and /13 is around the same as a F-35.

---

If you want to stay up to date with the blog you can use the RSS feed or you can follow me on Twitter

Until next time!