Implementing Office365 ACL with cisco devices

[lnacional]

Hi Guys.

We're implementing teams in our organizacion. We have cisco devices (switches, cores and Firewall ASA).

In order to permit Office365 Traffic, we need to permit a lot of Microsoft's URL and IP Ranges with ACLs in our firewall.

https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#skype-for-business-online-and-microsoft-teams

I need to permit all this URL in my cisco asa 5516-x and Nexus 9K

Is there a simpler way to allow these urls instead of loading them one by one?. Did any of you have implemen it in?

Thanks.

[DEENA VERAPPAN]

ASA does not support wildcards in URLs. For MS Teams we setup ID 11, only. Allowing the inside network access to the MS Subnets on the specified UDP ports. Split tunnel excludes the MS Teams subnets from the VPN Tunnel, and sends the traffic the local ISP.

Hope that helps.

[Marvin Rhoads]

Most organizations' firewall rules allow outbound Internet traffic by default, subject only to IPS rules and "bad site" blocking (perhaps with URL or other content filtering). Is yours configured differently - i.e. , requiring all site to be explicitly allowed?

If so, take a look at this:

https://github.com/chrivand/Firepower_O365_Feed_Parser

You can use the resultant object in your ACL to allow the Microsoft IP ranges.

[lnacional]

Hi Marvin how are you?

All users access to internet throught of proxy server.

Actually we have 2 nexus 9k in HA as a core switch, in this devices we permit traffic from de users to proxy server ( only ports 80, 443).

So the Firewall asa permits all outbound traffic from the proxy server to internet.

The thing is, microsoft recomend that some traffic called "optimized" by-passed any proxy server because is sensitive to latency. So i need to permit that traffic in My Cisco Nexus and Cisco ASA.

Thanks.

[Marvin Rhoads]

So the GitHub method I linked earlier allows you to download the feeds into an object. Just add that object to the ASA ACL that currently restricts traffic to that coming from the proxy server.

[DavidWhite6761]

For years CISCO had 'validated designs' to cover 'all' circumstances, but they have avoided this one completely (as far as I can tell)

TBH I have been looking for 'proper / serious' recommendations on this from CISCO for some time, and do not think that community written scripts with no CISCO support is an acceptable answer.

This is a common problem, where MSOFT seem to have set the O365 access policy in direct contravention of many corporate security policies (they are assuming everyone is SME or SOHO).

Cisco Firewalls are not great for allowing the MSoft traffic, some Firewall vendors actually integrate into the MSoft URLs list themselves and provide objects that are auto updated CISCO seem to recommend using 3rd scripts on the FMC / FTD, and they don't provide support for this.

You need to check your proxy service and the wording on the MSoft web sites for Optimise.

MSoft give different answers when you quiz them about this:

1. Proxy traffic, with no SSL offload or AV scanning (many proxy vendors integrate with MSoft URLs and have a 'bypass' function - does this count as 'bypass?' they then mention the number of long lived connections that proxies are not 'design for', so they never have resolution only more problems.

2. MSoft also require that no more than a specific number (I think about 3k) connections are NAT'ed behind a single IP address (so a large corporate that NATs all users behind a single IP on the Firewall will have problems).

3. IP Routing on your internal Network is another issue. One comment above states they have setup ID 11 only on the Firewall. We have something similar (to allow VOIP direct only) - but do not have a default route to the FWall (to avoid the Fwall getting swamped), and as such IP routes for the subnets in id 11 directing to the Fwall are also needed - again no automation for that really - but then ID 11 doesn't change much.

I agree that "Most organizations' firewall rules allow outbound Internet traffic by default" but as a personal opinion this is bad practice and only really applies to SOHO / SMEs - and is why many orgs get hit with zero day Malware, that can find an egress to WWWLand.

The only device that needs a default route to the Internet is the proxy service that gives access to 'other' WWWLand resources (see below).

Multiple virtual proxy clusters is a valid strategy -

1 for MSoft stuff (with MSoft bypass applied) (see comment about number of users behind a single NAT - where you can apply QoS on your Network for this traffic

2. For High priority systems (Cloud Services with mission criticality - Finance or CRM - again QoS could be applied)

3. Known / registered WWWLand resources (Business systems that are known but not 'mission critical)

4. 'Other' WWWLand resources - where this cluster could have bandwidth limitation policies applied on the WWWLand connection (to stop streaming world cup / cricket from swamping the business services).

Use a proxy.pac file to direct the users to the correct proxy.

So in short for O365 to work correctly - Automation is required for

• Firewall Rules (URLs and/or IPs)
• IP routing on the Internal Network
• Proxy.pac file updates

MSoft do try and help towards the proxy.pac - but leave the Fwall and routing to other vendors.

On an another but related tack - I also recommend that Networks adopt a default route that points to an anomaly detection system in the Data Centre centrally - then any Malware traffic that assumes a default route to WWWLand will exist is thwarted / detected.