Identity aware firewall policies - pros and cons

For allowing access to office 365 services from our LAN, there is a long list of FQDN's (


or an associated list of /16 / 24 subnet ranges that needs to be accessed through firewall on ports IN/OUT 80 and 443.


On our Cisco's ASA 5200 with AIM SSM 20 onboard, what would be the performance impact if we deploy 'identity aware policies' and use DNS names instead of assocated IPs? Also, seems like AIP SSM 20 will scan through http traffic on port 80 but what about https traffic? Is that a residual risk in any way?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Rich RumbleSecurity SamuraiCommented:
NGFW's and UTM's aren't magic, they actually utilize agents on the machines to know who started a process and connected via some port when the traffic is otherwise anonymous. You can see the user in SMB/CIFS traffic, but you might not in HTTPS or even most HTTP, so the agent on the OS reports to the firewall who made that connection and that's how they are "identiy" aware.
Page 1 of this overview tells you the same in it's second paragraph:
It's referred to as the AD agent, that's how it will be able to look at and might even interact with HTTPS traffic.
btanExec ConsultantCommented:
Identity aware FW policies typically required calls to external user directory e.g. active directory and if there are a couple for decentralised identity stores, the FW will be doing quite a fair amount of calls and performance will be impact. Specially when configuring DNS for FQDN usage, consider the following points:

•DNS replies can be spoofed, which can open a security hole in your network. Specify only trusted DNS servers, ideally only those inside your network.
•Some hosts can have constantly changing multiple IP addresses, so the ASA might not always have all valid IP addresses at any one time.
•Host names with short time to live values will require frequent DNS lookups; this can impact the performance of the ASA.
•Multiple host names can resolve to the same IP address. Ultimately, the firewall rules are applied based on IP address. Thus, if two names map to the same address, and your rules specify different services for those names, the service that is actually provided will be those specified on the first matched rule.

Looked at another way, this means that you do not need to specify every version of an FQDN host name in your rules. When you know that several names always point to the same host, you can configure rules for the most commonly-used name and they will apply to all synonyms of that name.

There are limits to the number of users, user groups, and IP addresses per user. If these limits are exceeded, identity-aware processing will not occur for the additional traffic, so do consider it as well.

There are several types of policy where you can specify network/host objects or extended ACL objects, but where the policy does not allow FQDN network/host objects or ACLs that use those objects or identity user group objects. Following are some examples where you cannot use these types of objects:
•Routing policies, including route maps.
•Network address translation (NAT).
•WCCP (web cache control protocol).
•Crypto maps in VPN configurations.
•Dynamic access policies in remote access VPN configurations.

Always good to monitor identity-aware firewall policies the same way you would monitor other types of policies and events. There is a group of syslog messages that relate specifically to identity firewall: 746001-746019.
E.g. 746016—DNS lookup for the fully-qualified domain name (FQDN) failed for the stated
E.g. 746004 and 746011—These syslogs indicate that you have exceeded the supported number of references to user groups or users. reason.

by the way, https traffic content cannot be inspected if the device did not terminate it or serves as some sort of man in the middle (having private keys) assuming the FW is in the reverse proxy guarding the web server. But from the identity user stand point it can still be configure as a cut through proxy with user to ip mapping...

With regards to AIM SSM, I tend to look at from AIP SSM perspective more, if that is what you are looking at, signature tuning and the mode of operation (inline or passive and even its placement like in the perimeter or network edge which can be very 'noisy') does impact the performance. Also good to monitor the amount of data being sent to the IPS via snmp etc. You can also use the GUI in the IDM, or pull the stats out of the CLI using the "show status analysis" and "show status interface" commands.

There is sharing in forum that real world traffic can see those missed packet percentage (along with 100% CPU utilization at about 1/3 of the Cisco rated throughput numbers. And for the figure seen, note that Cisco always adds both directions of traffic together to get their whole number, so if they rate a SSM-20 module in a ASA 5520 for 375 Mb/s you can expect about 125 Mb/s or a little better than a DS-3 worth of IPS functionality.

Also instead of using inspection load to determine proper sensor performance, we can rely on "missed packet percentage" reported by the sensor. When the sensor gets into trouble they will start to miss packets for inspection, this leads to the sensor incorrectly determining the TCP state for some of the connections. This causes the sensor to use more resources than necessary to inspect traffic, leading to more missed packets.

There is also another CSC SSM..but overall, this link below may be a good of interest looking at AIP SSM and CSC SSM on how to manage them

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Blue Street TechLast KnightCommented:
Hi fahim,

As a side note, Office 365 only requires these ports to be open if you are filtering outbound traffic. All of our clients run Enterprise Office 365 without any port forwarding with the exception of the compliance mandated ones, again, filtering outbound traffic.
btanExec ConsultantCommented:
You may want to look at this as well ..Plan networking and naming services for Office 365. their link on FW is not available but the below still make basic sense planning
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.