- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-24-2016 02:36 AM
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.
08-24-2016 10:38 AM
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?
08-29-2016 01:39 AM
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.
08-29-2016 02:19 AM
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.
09-07-2016 03:42 AM
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).
09-08-2016 02:45 PM
@mserrano_uned thanks for the update !
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!