RedHat (+Akamai) IP ranges

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

RedHat (+Akamai) IP ranges

L1 Bithead

Would it be possible to add a miner for the Red Hat Subscription Manager (RHSM)?

They do advice to use domains name as filter rather than IP addresess [1] (mainly because they use Akamai's CDN), but we prefer to have that kind of traffic under control. There is a public CIDR list [2], but as you need an account in the RedHat portal, they provide a JSON file [3] that could be downloaded without logging in.

 

[1] https://access.redhat.com/solutions/65300

[2] https://access.redhat.com/articles/1525183

[3] https://access.redhat.com/sites/default/files/attachments/cdn-ranges-2015-07-14.zip

 

Thanks in advance.

5 REPLIES 5

L0 Member

That's an interesting idea. It seems like CDN IP ranges on their own would be a little too ambiguous though right? How much other content is hosted on the same IPs...seems like URL's would be a must.

 

What are your thoughts?

Hi Nasir,

you are right, but even the URLs would whitelist akamai CDN URLs:

 

*.akamaiedge.net:443 [https] OR *.akamaitechnologies.com:443 [https]

 

If this is the only way, I would suggest to create a policy as strict as possible using specific source fields and App-ID.

Sorry for the delay, we were giving it a thought and doing some tests using the list provided by RedHat but we didn't have much success. We found ourselves accessing IPs that weren't in the list. We'll open a case with RedHat support to see if the list isn't updated.

 

Nevertheless, regarding the original question, the way we have set the policy up now it's allowing only specifics types of traffic (yum, ssl and web-browsing), so the fact that those IPs host any other content shouldn't be a concern, that's way we thought the IP range might work for us, and thus the miner request. Before that we tried creating an URL filter, but it didn't work, we assumed it was because being SSL traffic you only could see the header and that probably use IPs instead of URLs or something along the line.

 

Thanks for the response.

Well, in RedHat they insisted in giving access to every akamai server

*.akamaiedge.net and *.akamaitechnologies.com

both with port 443. Problem is that this is way to open for us (because using SSL you don't really know whats going on there).

 

At the end we found two ways to narrow down the access. Setting up the up2date so it doesn't use the Akamai CDN or specifing one DNS record (a redhat one) that resolves always the same IP thanks to the geolocalization and when Akamai changes it, the PaloAlto firewall will update the new IP minutes later.

 

Thanks for the response (I didn't want to be offtopic so I didn't explain myself too much, if anyone wants more detailed information just let me know).

@mserrano_uned thanks for the update !

 

  • 8510 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!