on 10-20-2016 07:36 AM - edited on 04-09-2020 02:33 PM by Retired Member
As customers migrate to Office 365 they find themselves whitelisting a range of App-IDs for the various workloads they might use in the Office 365 product sets, such as Skype for Business, OneNote, Exchange Online and so on. Because Microsoft publishes Office 365 over a huge range of URLs, and IP addresses, a security admin would be tempted to simply allow access in policies to a destination of ‘any’, and this gets complicated when the Office 365 App-IDs tend to have dependencies on explicitly allowing web-browsing and SSL. It would be preferable to configure external dynamic lists and reference that in our security policies, and as it happens, Microsoft dynamically publishes a fully up-to-date list of all IPs, URLs and ports used by each of the 17 components of Office 365 every hour that we can use! This article will take you through setting up the open source MineMeld utility to parse this data into EDLs for PAN-OS to consume, and creation of a couple of example security policies for your environment.
Step 1. Deploy MineMeld
First, visit https://live.paloaltonetworks.com/t5/MineMeld/ct-p/MineMeld and select the article (from the top right) about installing and running MineMeld appropriate to your environment. Note, if using the VMWare desktop instructions (https://live.paloaltonetworks.com/t5/MineMeld-Articles/Running-MineMeld-on-VMWare-desktop/ta-p/72038) you can go ahead with the "Super fast setup" but please download the cloud-init ISO and mount it on first boot. Assuming an IP comes via DHCP and you have internet access, your VM will automatically be updated to the latest version of Minemeld.
Make note of MineMelds IP address (from an ifconfig) as you’ll need it for the Web UI in the next step.
Step 2. Obtain & Import Configuration
MineMeld does already come with Prototypes for each of the O365 services but you would normally need to create a miner for each of these from those Prototypes, along with 3 processors and 3 outputs (one each for IPv4 addresses, IPv6 addresses and URLs respectfully). To save you the hassle we've created a configuration you can import, simply download it from https://paloaltonetworks.app.box.com/s/4ubmkgrq72a8mdd24j733ddqdgbkyvv4 and open it in a text editor.
NOTE: for a minimal config collecting all the IPv4s, IPv6 and URLs of all the O365 products download this instead: https://paloaltonetworks.box.com/s/gndwe5rzheg1ekwplxb4m3mrpcf5k41f
Browse to https://Your-MM-IP-address/ (obtained above) and sign in with the username admin and password minemeld. Next click CONFIG at the top followed by IMPORT.
This will bring up the IMPORT CONFIGURATION window. Copy and paste all the text from the .yml file you downloaded in step 2 into here and click Replace (or Append, if you have already configured this instance of Minemeld for another purpose.
Accept to replace the candidate configuration, followed by clicking the COMMIT button and waiting some time for the engine to restart.
Can't see an IMPORT button? This is simply because you are using an older version of MineMeld. If you cannot upgrade for whatever reason, follow step 2a below instead. If not, carry on to step 3.
Step 2a. Importing configuration for an OLDER version of MineMeld only
nb: Skip this step if you were able to import using the web interface as above!
$ scp ./office365-config.yml firstname.lastname@example.org:
To replace the configuration of a fresh install, SSH into your MineMeld instance (again as the ubuntu user) and run the following command:
$ sudo -u minemeld cp office365-config.yml /opt/minemeld/local/config/committed-config.yml
$ sudo -u minemeld cat office365-config.yml >> /opt/minemeld/local/config/committed-config.yml
Now run the command to restart MineMeld:
sudo service minemeld restart
Step 3. Review Connection Graph and retrieve Feed Base URLs
After giving the MineMeld engine a few minutes to restart, click “Nodes” in the banner at the top of the interface and then, click any of the nodes in the list.
Then click the Graph tab (asterisk sign) to bring up the Connection Graph which should look like this:
Here you see each of the miner nodes on the left scraping Microsoft’s dynamically updated XML File (direct link for your reference: https://support.content.office.net/en-us/static/O365IPAddresses.xml), the processor nodes that receive URLs, IPv4 and IPv6 addresses, and finally the 3 output nodes that publish a URL that your firewall can poll for an External Dynamic List (EDL).
Click each of the Output notes and make a note of the Feed Base URL.
Step 4. Consume MineMeld’s output
Log into your firewall (or Panorama) and go to Objects > External Dynamic Lists (or Objects > Dynamic Block Lists if using PAN-OS prior to v7.1). Click Add and create Dynamic IP address lists and URL lists to ‘subscribe’ to each of outputs created in the previous step. In my example below, I have created three dynamic lists matching the three Minemeld outputs above.
Step 5. Create a URL Filtering Profile
This will allow you to limit your access onto to the URLs in the O365-URLs dynamic list, which you’ll apply to your security polic(ies) allowing O365 later. Add a URL filtering profile, and block all categories (hint: Click the top checkbox to select all items, then click the Action banner in the list, and then click “Set Selected Actions”, then block to block all categories at once). Scroll to the bottom and allow only the external dynamic list of O365 URLs.
Step 6: Create Security Policies
Now that we have EDLs and a URL profile in place it’s time to modify/create our security policies. In the example below, we are allowing our Office 365 apps for all known users in the trust zone. The destination zone has been set to untrust zone but with the IPv4/6 lists as destination addresses.
App-IDs that you may find detected during use of Office 365 (depending on the clients and product sets being used)
What if there's still some O365 activity that is NOT hitting my new security policy?
You may find from using a catch-all rule with logging, that some sessions are not hitting this O365 rule when they should be. The reason is because Microsoft use CDN networks, which are outside of the IPv4/v6 ranges Microsoft use, like CloudFront for some applications in O365. The following URL will allow you to confirm if this is the case and whether you need to widen your whitelist to allow for these CDNs.
To allow access to the CDNs that do not match the security policy above, simply create a second security policy that allows from trust to untrust, from the same set of applications in the previous rule, and a destination of any. In the Service/URL category tab, insert the custom URL category from Step 5. The FQDNs will be present in that URL category and thus match this second rule.
I have installed Minemild and I applied article and create dbl for Offcie365:
I have cretate 2 rules for Office 365 to test if feed sources Office 365 works.
I have a rule to match with feed list office 365 servers and application Office365 and all traffic should match with this rule. And I have below this rule other rule with destination "any" and application Office 365.
Log shows traffic match with 2 rule.
That means there are IPs that are not in the sources provided by Minemeld.
On the other hand, System Log Pa-500 shows this message:
'EBL(O365-IPV4) Refresh Aborted. No changes to list file
what's mean this message? Is an error ?
Thanks for your reply. Yup, that traffic that doesnt match the first rule will be attempts by O365 apps to access resources hosted on CDNs which are outside of those IP ranges. I just updated the instructions above to add a second security policy in this instance, please let me know how you get on.
Regarding the log, it could be that Minemeld is not reachable at the time a refresh is supposed to happen from the PA-500 or it could be that there were no differences between the currently committed and the 'latest' version from MM? Do you get the log for all 3 outputs or just one? When you test connectivity in the EDL edit screen does that work?
this article was very helpful and all works like a charm. We has so much issues caused by the dynamic IP-Addresses and added / removed URLs by Microsoft. This Tools and you guideline helps us out and user acceptance is getting better and better!
Recently started using Minemeld to help with our Office 365 deployment. Word of caution when using the URL list for an allow category.
These URLs below are all in the office365_officeMobile node list and we didn't want to "allow" access to any of them. Review the lists from Minemeld and make sure they match what you are trying to do in your environment. Is there an easy way to exclude an indicator from a list? I see a way to whitelist, but not blacklist?
best solution would be to only allow a specific subset of app-ids to the URL listed in the feeds.
On MineMeld you can use whitelists to remove indicators from the feed. If you create a whitelist for URLs based on stdlib.listURLGeneric with a name starting with "wl" and attach it to office365_URLaggregator. There you can list the indicators you want to remove from the feed.
Great, thanks for the quick reply. I guess I assumed Whitelist was to add something to the feed but after reading a little I see how I can use it to get rid of the URLs in question.
I did try the app-id, and it worked fine, but there was no idication to my users on why they could not get the link, just a page does not load, which then generates calls to the helpdesk. If they get the URL block page, then they usually don't argue too much.
I've setup minemeld to gather all URLs for All - Office365 apps.
I have in the FW two rules.
1. Allow office-apps + Dest: any + EDL URL from Minemeld
2. Allow office-apps + Dest: any (to catch traffic not matchig the #1) this one should be removed later
By reading the blog, I thought that by using EDL-URLs I could spare the EDL-IPs story. But here we are, my rule #2 catchs some connections like:
app: ms-onedrive-base , dest-IP: 184.108.40.206, but not matching any URL from minemeld.... I wonder why...
app: ms-lync-base, dest-IP: 220.127.116.11, but not matching any URL from minemeld... I wonder why again....
Is it because the EDL-URLs list is incomplete, or is it because the FW cannot see the URL inside the packets?
THanks for any explanation,
it could be that part of those protocols are not web based and there is no URL to match. Have you enabled URL Filtering logging on policy #2 to track the URLs that didn't match #1 ?
Note that security policy in #6 use both IP and URL for matching.
Is it possible to import only "product name = o365" in the list of https://support.content.office.net/en-us/static/O365IPAddresses.xml ?
"Product name = ProPlus" and "product name = OfficeMobile" is not required.
to achieve that you can just remove all the O365 miners from the O365 configs except for office365_O365. That miner only retrieves IPs and URLs of the product o365.
Thank you for message.
Would you teach me how to implement it concretely ?
please, could you open a new discussion under MineMeld discussions ? I will then show you how to change the config.
While configuring this with an enterprise account I came across another application that I had to add that wasn't on the initial list in this article.
If memory serves me correctly this application was added relatively recently to deliniate between enterprise and consumer level accounts of Office365.
Hope this helps!
Microsoft have sent out an early warning about a change to how Office 365 IP Addresses and URLs are published (will this Method still be valid or can it be rewritten to collect Office365 Addresses still via MineMeld???😞
We’re making changes to Office 365 IP Address range and URL publication
Plan For Change
Published On : April 2, 2018
We're making some changes to how Office 365 IP Addresses and URLs are published. Starting today, we're providing the data on new REST based Web Services and on October 2nd, we will stop publishing the previous HTML, XML, and RSS format of this data.
How does this affect me?
This data is commonly used by customers for configuring firewalls, proxy servers, and related networking equipment for optimal connectivity to Office 365. If you are using this data today for device configuration and you don't move to the new IP/URL web services then new servers added for Office 365 may not be accessible to your users. These updates typically occur once a month.
If you are not configuring firewalls, proxy servers or related networking equipment, in this way, you can safely ignore this message.
What do I need to do to prepare for this change?
If you are not using the Office 365 IP Addresses and URLs now, no action is required.
If you are using the Office 365 IP Addresses and URLs to make monthly updates to your firewalls, proxy servers, or other networking devices, then we encourage you to review the new IP/URL Web Services so that you can migrate any process you have related to this data.
Please click Additional Information to learn more.
the Palo Alto Networks MineMeld core team is aware of this announcement an a tracking issue is available at https://github.com/PaloAltoNetworks/minemeld-core/issues/267
No new miner classes need to coded to pool from these new Office API entry points. Just new prototypes.
Following this instructions blocks traffic to office365 in my environement. It looks like many of the url:s are being categorized as not 365 url:s (the Url filter I created from minemeld) but others. Here you can see that traffic for application ms teams url is catgegorized as internet-communications-and-telephony. And since the url filters is set to block all categories but the EDL from minemeld traffic is denied. What am I doing wrong?
I had a similar experience and was confused until I read this:
If a URL that is included in an external dynamic list is also included in a custom URL category, or Block and Allow Lists , the action specified in the custom category or the block and allow list will take precedence over the external dynamic list.
found in https://www.paloaltonetworks.com/documentation/81/pan-os/pan-os/url-filtering/use-an-external-dynami...
Since I had custom URLs for Office365 already, the Minemeld EDL feed did not take precidence. To facilitate the migration, I had to add my prexisting custom URL categories (where overlap occurred) to the allowed URL Filtering Policy rather than "block" for all.
As nice as this is what would be really great...
... wait for it ...
Palo Alto Networks - you mainain the list of objects for Microsoft. Then when you update definitions every night (or sooner) you just update our firewall. This would allow you to run the MineMeld and handle the back end stuff. We don't do this for other protections (AV, Malware, Wildfire, etc...) why would we do this for another definition?
Looks like i do not have access to these links. Cannot seem to access the box.
How can i fix this?
this article is out of date, please refer to the updated version instead: https://live.paloaltonetworks.com/t5/MineMeld-Articles/How-to-Safely-Enable-access-to-Office-365-usi...