Home > Uncategorized > How I learned to find the IPs and love BGP aggregator web sites

How I learned to find the IPs and love BGP aggregator web sites

So I want to secure the network the best I can to focus the holes inside to outside.
So I limit the layer 3 traffic by protocol using a layer 4 inspection device, such as a firewall.

In this firewall, there are policies to control this. The packet inspecter looks at various parts of the packets, let’s focus just on the IP header. I’d like to control which ports and destination IPs clients on my network can hit.

Let’s say you have a pesky app. This app hits a variety of IPs, but you don’t know which IPs they are. You sniff, and you think you’ve built your IP list up. You go ahead and implement the firewall policy, port 6989 destination 56.48.12.124; but sure enough, this silly app has changed its destination IP. Of course this happens in the middle of a production day. You must, as quickly as possible, revert your change to secure the network. Now again, you’re stuck sniffing, finding the new destination, adding it to your address object group, and reimplementing the policy change. “No problem! This is the cost of doin’ the business we dos!” you say.
What if this happened twice? What if this happened three times? What do you do then, when twice is enough already?

Of course! Contact the application support! They’ll give you a list of destination IPs that their app will hit. No, no they won’t. You get a list… “Horray!” you exclaim when the support rep seemingly breaks an internal distribution policy to get you this list. “Thanks so much for all your help! I really appreciate it. You can close the ticket.”

Great! We’ve got the complete list of destination IPs! Add them to your address object group, and reimplementing the policy change.
Op… three days later no connectivity. Roll back the policy immediately. It’s the fourth time production has been affected. That’s four times too many, three times if you’re a humanist.

Do you shy away? Hell no! This is network security! And you’re a real man who takes risk… albeit mostly so well control you’re no longer a risky man… But, still you tell yourself you’re a network daredevil!

So, hmm… enough jolly banter… Let’s go with an example, and the solution to lower the risk.

Let’s use Skype’s servers as an example of this.

I just sniffed some traffic on my machine and noted traffic that seemed to be towards Skype.
We’ll use the IPs 204.9.163.247 and 213.199.179.145 as our “culprits.”

You want to use tools to find out which BGP AS these guys are advertised as part of, then include all destination IPs

Confirm who owns the IP. I use robtex.com for simple queries, including reverse whois. Looks like Skype does own 204.9.163.247, but 213.199.179.145 is owned by Microsoft.

Now, let’s find out which AS these IPs belong to. I prefer to use robtex.com to find this info. 204.9.163.247 belongs to AS30370 and 213.199.179.145 belongs to AS8075. Neat! We found some CNAMEs: conn.skype.com and ui.skype.com. Refocusing the graph on those addresses reveals any other ASNs we can also consider to be destinations, which these two guys are not! Therefore, we only have the ASN30370.

And now for more complexity…
Doing the same with 213.199.179.145, we see some Akamai managed CNAMEs, and another ASN, AS8069. But we also see a pattern in the naming convention of the Akamai CNAMEs, dsn14.skype-dsn.akadns.net and dsn5.skype.dsn.akadns.net are returned. This would be a problem. Let’s kick it out to nslookup and see what we can find:

nslookup -type=soa dsn1.skype-dsn.akadns.net

Returns the SOA to be internal.akadns.net

nslookup dsn1.skype-dsn.akadns.net internal.akadns.net

Returns eight addresses:
111.221.77.142, 111.221.77.144, 157.55.235.146, 157.56.52.19, 213.199.179.166, 65.55.223.15, 111.221.74.25, 111.221.74.34

We have to collect the ASNs for each of these guys as well.

Now let’s find out limits:

nslookup dsn50.skype-dsn.akadns.net internal.akadns.net

No dsn50…

nslookup dsn16.skype-dsn.akadns.net internal.akadns.net

Through testing it appears that, currently, dsn16 is the limit.

Remember, us computer people like digits, dsn.skype… doesn’t work, but dsn0.skype… does return IPs.

Boo! This means that we will be looking up the AS “membership” for 16*8 IPs.

Looking up the subnet “members” of those AS, it appears that AS8075 contains 153 subnets. And check it out, there’s a few more ASNs listed as overlapping with the AS8075: AS3598, AS23468, AS40066, AS20046, AS30142.

Wow. Bad example.

AS30370 is a bit slimmer, but not by much, there are a few ASNs listed as overlapping as well: AS14968, AS18845, and AS23498.

Those pages will give us the BGP published list of destination subnets. And down the rabbit hole we go, thanks to this poor example.

This turned out to be a lot more manageable as a real thing when dealing with my specific case (which I will not detail).

This should give you good guidance to widen your firewall policies by destination IP. Clearly, with a huge list of IPs, expect the CPU and RAM utilization of your firewall to grow.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: