Using class A IPs internally that belong to other orgs. - what are the implications?

What are the implications of using internally class A IP addresses that belong to other orgs?

So apparently my org has been doing this for the past 20 years. Using at least 3 different class A IP ranges that belong to other companies.

I'm talking about big companies, one of them I wont mention the name but lets say its a 3 letter org that starts with Dox.

I was doing some investigation on an alert that we received and initially I thought we were breached because of how the traffic looked only to discover that the IP address the device was trying to reach belongs to an internal device. However that same IP belongs to this Dox organization also and it tried to reach their network but was blocked at the firewall.

Now I'm not expert in networking and big network setups but what could be some implications of this setup?

Looking online it seems that this is not rare, very common actually. Still makes my job a bit harder and confusing.

Find more posts tagged with

Comments

Mike7

If you are referring to 10.0.0.0/8 address, filter them incoming from or outgoing to internet. Your firewall may have feature for "bogon filtering".

Same goes for rDNS lookup for internal IP to internet. Make sure your internal DNS server have rDNS zones defined for these IPs. Apparently more than 5% of rDNS internet as query traffic at root servers are for internal(RFC 191

addresses.

jibtech

Using a public class A address range is a bad idea. Your use case will be what determines how bad an idea, ranging from generally bad to "rip your hair out" bad.

As I see it, there are three primary issues:

1. Risk of leaks. Most ISPs automatically filter outbound traffic that targets a private IP. If you have a misconfiguration somewhere that allows external traffic directly to an internal system, it would be protected by that extra layer of protection. With a public IP address, you are at the mercy of that misconfiguration.

2. Routing. If any computer on your network ever needs to reach out to the actual systems on that public IP range, you will run into conflicts. This holds true if you ever need to reach one of those external systems that might use that range in the future also. If you have any computers configured to use external DNS (8.8.8.8, 8.8.4.4, etc.), you could get some interesting responses....

3. This is the big one, to me. You introduce a level of confusion to those who have to maintain the network now, and in the future. The design is going against the common practices used across the industry. New support staff will have to unlearn what they know, and it will always be something that has to be remembered. It also would make me question other network design decisions, as this is enough of a deviation to warrant concern.

Just my thoughts.

Danielm7

jibtech wrote: »

3. This is the big one, to me. You introduce a level of confusion to those who have to maintain the network now, and in the future. The design is going against the common practices used across the industry. New support staff will have to unlearn what they know, and it will always be something that has to be remembered. It also would make me question other network design decisions, as this is enough of a deviation to warrant concern.

.

This is an issue that we had when one of our acquisitions used a public block for their internal IP addresses. When I get middle of the night alerts from the SOC that our internal IPs, that have no real outside connection, are getting hit by another country... not good.

EANx

My biggest fear in that situation would be all the ways leaking could occur. For instance, if your organization allows the use of VPNs for people to connect, those VPNs have to be appropriately configured so that the home user doesn't serve as a pipe bypassing the enterprise firewalls. A big benefit to using a ten-dot is that ISPs know not to route it, by using other registered addresses, it means you have to be especially vigilant. I would hope you have a robust configuration and change management process, if you don't, you're at greater risk of a sloppy config not being noticed.

jibtech

EANx wrote: »

My biggest fear in that situation would be all the ways leaking could occur. For instance, if your organization allows the use of VPNs for people to connect, those VPNs have to be appropriately configured so that the home user doesn't serve as a pipe bypassing the enterprise firewalls. A big benefit to using a ten-dot is that ISPs know not to route it, by using other registered addresses, it means you have to be especially vigilant. I would hope you have a robust configuration and change management process, if you don't, you're at greater risk of a sloppy config not being noticed.

To this point, how much confidence would you have in the robustness of the configuration and change management process, given the known deviation from best practices? Given something of this scope was done outside of good practice, I would be concerned about the rest, as well.

yoba222

I envision a misconfigured "internal" service attempting automated login to another "internal" service, when in reality the service is externally brute force attacking a military IP address.

In reality I don't think much would come of it. But if you spin it up into a fear-motivated story, mentioning CFAA and citing some examples of people serving jail time, perhaps you could motivate your company to make the changes.

EANx

jibtech wrote: »

To this point, how much confidence would you have in the robustness of the configuration and change management process, given the known deviation from best practices? Given something of this scope was done outside of good practice, I would be concerned about the rest, as well.

I don't like to assume the original designer was an idiot, maybe there was a good reason for doing it the way they did. For instance, they had business relationships way-back with the organizations that owned those IPs at the time and configuring an extranet was the accepted way to do things at that time. This is why I asked about things that would help ensure things didn't go south in a hurry. If the OP comes back and says the original design was from 1992, that's a different set of standards to grade against than 2007.

Welly_59

I also had similar recently. New client that was onboarded was using a public range for its internal network. Flagged it up but the powers that be didn't care enough to force them to change

jibtech

For me, this isn't about the original designer. This is more about institutional change management. There are any number of things that were acceptable 20 years ago, that aren't acceptable now, and weren't acceptable 10 years ago.

Even if the organization was using the public addressing scheme for other organizations legitimately 20 years ago, that is certainly not the accepted model now. Aside from federal standards, the organization's own firewalls detected it as an intrusion. So, that tells us that:

A. the firewall implementation failed to account for an addressing scheme, that has been in place for 20 years, or...

B. the "set it and forget it" mindset has been in place, possibly coupled with the fear that such a change is simply too big to make.

Either way, it tells me the review and change management processes aren't as robust as they should be. How many core refreshes have been done in those 20 years? How many firewalls have been implemented over that time? What does the addressing look like for the email environment?

There may yet be a legitimate reason for the model. I can't think of one, but I would be very curious to hear it, if there is.

jibtech

Welly_59 wrote: »

I also had similar recently. New client that was onboarded was using a public range for its internal network. Flagged it up but the powers that be didn't care enough to force them to change

This. This is my concern, and I think the most likely answer as to why.

Priston

I've seen public IPs used internally on parts of the network that aren't routed anywhere. I asked someone once why they used 193.168 instead of 192.168 and they pretty much told me they liked 193 better...

If I saw public IPs routed throughout the whole corporate network I'd worry a lot more.

TheFORCE

This is a 20+ year implementation, i guess no one bothered to correct it and bring it up with the best practice standards.

When asked, they said, too much effort, too much money. The mentality of if it isn't broken no need to fix it.

mbarrett

This is why RFC1918 provisioned private IP space to be used internally, there is generally no possibility of routing outside your boundary onto the public internet.
There's probably some good discussion about this issue from the RFC, or with the IANA. In short, it will lead to confusion if attempts are made to route outside the local network. Check with the IANA for implications of this practice in your situation. Also, have you checked with the owner of the registered IP space to get their opinion? (Why not?)
In the absence of anyone caring, you might want to blackhole the route so the traffic doesn't get out to the internet...

This reminds me of the time a customer was using an internal AD domain name that also (coincidentally) was an actual country domain halfway across the world. When the customer placed a machine outside the boundary firewall to troubleshoot some issues, it immediately started reaching out across the public internet to synchronize the Microsoft services, etc.

ImYourOnlyDJ

My only experience is that it tends to make the network staff look bad no matter who's decision it was. We encountered this during a merger and basically said we won't allow non-RFC1918 addresses to be routed internally on our side.

ImYourOnlyDJ

I've also seen companies use the APIPA range (169.254.x.x) internally. It supposedly was to make it more secure since it would have been harder to guess or something.

jibtech

ImYourOnlyDJ wrote: »

I've also seen companies use the APIPA range (169.254.x.x) internally. It supposedly was to make it more secure since it would have been harder to guess or something.

Security through obscurity. One of my favorites.