Verizon Core

Something I Discovered

While playing around with dummy interfaces on my computer I noticed something interesting. I had created an interface in the 10.0.0.0/8 range, after deleting this dummy interface the IP I had used was still responding to pings. The interface was definitely gone so what could be causing this? Since 10.0.0.0/8 is private internet space surely this wasn't the outside world responding to me, or was it?

For my own sanity I ran a traceroute and confirmed that the address was in fact leaving my home LAN. Notice the "!N", the initial addresses have stopped responding to pings.

tracepath 10.10.10.1
 1?: [LOCALHOST]                                         pmtu 1500
 1:  router.home                                           2.215ms
 1:  router.home                                           2.016ms
 2:  L100.BSTNMA-VFTTP-107.verizon-gni.net                11.419ms asymm  3
 3:  no reply
 4:  no reply
 5:  no reply
 6:  G0-11-4-3.BSTNMA-LCR-22.verizon-gni.net              14.640ms !N
     Resume: pmtu 1500

Turns out the answer to this question wasn't totally straightforward. After I did some searching I found that Verizon uses this address space on their own internal network. Just like I have a private LAN space, Verizon also has a private LAN space, since the devices are networked together it is possible for this network to act like one big LAN.

When I make a request to 10.10.10.1 my router doesn't know where to send it so it forwards this request to the next upstream router. As it turns out this ended up being a valid address in the network. Now this seems like something has been misconfigured on Verizon's end, but this is not the case, everything is functioning as it should. Now should one party not desire this connectivity then it falls on them to create the network rules to not accept these packets and not to forward them externally.

nmap

Naturally I ran an nmap scan on the entire 10.0.0.0/8 network, this had completed when I checked less than 24 hours later. Stupidly I only sent the output to console so I'd exceeded the buffer and have no idea how many hosts responded to the nmap pings. Interestingly many hosts no longer responded to my pings after this.

I decided to do another nmap scan but with the -Pn option so that it would scan the host regardless of whether it responded to the pings or not. The reason nmap won't use this option by default is because it takes forever (and then some). I let this run for about 3 days straight and scanned all the way to 10.0.23.191 at which point I called it quits.

So we are on the same page, nmap defines a closed port as a port that has responded (so it's not firewalled) but has no active services (so it's not being used). A filtered port is one which does not reply, this likely means it's firewalled, but could potentially just be dropping the packets due to network error. An open port is one which responds and has a service running.

What this showed was that nearly every address I had scanned was up and had at least one open port. Usually what you see when you do an nmap scan would be the majority of ports either closed or filtered (depending on firewall status) and a select few ports open. What's odd about many of the hosts I scanned was that they had a large number of closed ports (so not firewalled), a small number of filtered ports, and one or two open ports. My best guess is that these ports have services running behind them and have some sort of access control that only responds to a certain IP range.

  Nmap scan report for 10.0.23.191
  Host is up (0.0084s latency).
  Not shown: 993 closed ports
  PORT     STATE    SERVICE
  554/tcp  open     rtsp
  1132/tcp filtered kvm-via-ip
  1863/tcp filtered msnp
  2875/tcp filtered dxmessagebase2
  5915/tcp filtered unknown
  6788/tcp filtered smc-http
  7070/tcp filtered realserver

This was not limited to the 10.0.0.0/8 space either, I had similar results in 192.168.0.0/16 and 172 private address space.

Take a look at the files yourself: 10.0.0.0/8 Partial Scan and 192.168.0.0/24 Scan

Note: Since many ports weren't pingable this all has me wondering if perhaps the scan was just executing on the last hop and that these hosts aren't all up. I don't think this is the case because I get different results between scanning a host versus scanning the last hop. I need to do a bit more research on how nmap would handle such a scenario, so this is a disclaimer of sorts. Regardless the initial scan that got me interested in all this did show many hosts that were pingable (logically it didn't find nearly as many hosts as I saw with the Pn option otherwise that scan wouldn't have finished in less than 24 hours).