topic A very good read for choosing in Network Access Control

Do I really need the SNMP Query probe?

Josh Morris — Mon, 11 Mar 2019 06:45:53 GMT

I am currently using three probes on my PSNs. Radius, DHCP, and SNMP Query.

I was told that my SNMP Query may be useless if I was already grabbing the info I needed from Radius. If I just pick some random endpoints, I see that they are profiled either using the DHCP or Radius probe.

In the interest of saving resources and eliminating overhead, should I just disable the SNMP Query probe? Will I be able to gather the same info?

Also, here is my switch config regarding probes (I'm running 4510R+E SUP8, 3.6.3)...

aaa group server radius ISE_RADIUS
server name ISE_PSN1
server name ISE_PSN2
aaa server radius dynamic-author
client 1.1.1.1 server-key xxx
client 1.1.1.2 server-key xxx
ip radius source-interface Vlan1
radius-server attribute 6 on-for-login-auth
radius-server attribute 6 support-multiple
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius-server dead-criteria time 30 tries 3
radius server ISE_PSN1
address ipv4 10.200.0.23 auth-port 1812 acct-port 1813
key xxx
radius server ISE_PSN2
address ipv4 10.200.0.24 auth-port 1812 acct-port 1813
key xxx

radius-server vsa send accounting
radius-server vsa send authentication

device-sensor filter-list dhcp list dhcp-list
option name host-name
device-sensor filter-list dhcp list dhcp1-list
option name host-name
option name class-identifier
option name client-identifier
option name client-fqdn
device-sensor filter-spec dhcp include list dhcp1-list
device-sensor accounting
device-sensor notify all-changes

The more profiling probes you

nspasov — Thu, 12 May 2016 19:12:13 GMT

The more profiling probes you have enabled the more detailed information you will get about the endpoints. However, that does not mean that you should enable all of them 🙂 In fact, enabling all of them can have some very negative effects on your PSNs

So with that being said, I have found in the past that if NADs support Device Sensor then neither one of the SNMP probes were needed. However, if you see a lot of "unknown" devices then you can enable it along with other probes.

In general, try to avoid: SNMP Traps, SPAN and Net Flow

I hope this helps!

Thank you for rating helpful posts!

A very good read for choosing

Karsten Iwen — Thu, 12 May 2016 20:31:00 GMT

A very good read for choosing the right probes is the Cisco ISE Profiling Design Guide.

Re: The more profiling probes you

Tymofii Dmytrenko — Sun, 07 Apr 2019 10:58:46 GMT

I thought same way until recently. I am currently playing with different profiling configuration approaches in my lab and found the following (please correct me if I am wrong)

If only Device Sensor is being used, then ISE's visibility will be limited to switch ports where authentication is actually happening. Radius probe (i.e. Device Sensor) relies on authorized state of the port, because Device Sensor's information is always sent via Radius Accounting. But... there's no Radius Accounting if there is no successful Authentication. That being said, if you have ports that are not subject to MAB/802.1X (e.g. servers, routers, etc) - there's no way Device Sensor will report ANYTHING about these devices ever. Period.

DHCP will only work if endpoint uses DHCP (static endpoints are invisible)
DNS probes requires IP address to do lookup (relies on other probes to discover endpoint's IP address)
Active Directory - well.. great probe, but works for AD devices only (laptops/desktops) and relies on other probes to do initial discovery (MAC + hostname)
HTTP - limited use, not really applicable to switches (only if you use ISE portals, really)
NetFlow - I personally don't understand this one at all! 🙂
NMAP - not sure, as we don't use at the moment - requires whitelisting, otherwise endpoint security agents go into panic mode

Now, SNMP...

SNMPQuery, I think, is a must, even if you rely solely on Radius probe (Device Sensor).

Device Sensor will cover dynamic world (clients being authenticated), while SNMPQuery will provide static information (we know that periodic SNMPQuery should be set to as high as possible, e.g. every 8 hours)

I have noticed, that Discovery of static endpoints/devices on non 802.1X/MAB ports can be dramatically improved from a time perspective, if SNMPTrap mac notification probe is enabled (it does even work on TRUNK ports, but this is where you have to be careful and avoid enabling SNMP Traps for mac move on uplinks and downlinks between switches). It is useful on ports facing virtualized environment (ESXi, containers, etc) - can detect new MAC addresses quickly (even with static IP) and query extra info from switch - CDP/LLDP.

As a conclusion, I would recommend the following

Use Device Sensor whenever possible - this will provide CDP/LLDP/DHCP related information for all dynamic endpoints, where MAB/DOT1X is enabled.This, however, requires DHCP Snooping configuration on all switches!

Even though DHCP probe becomes less important, I would still enablle it and configure ONE and only ONE PSN as ip helper on ALL SVIs, even if these are static VLANs (where no DHCP is expected) - this will help capturing some endpoints that will suddenly start sending DHCP queries (e.g. servers/VMs/infrastructure).

NetFlow is useless and affects scalability - don't use unless you really have to. HTTP - don't use if you don't have portals on the wired. WLCs support Device Sensor Lite and can collect User Agent information for all clients. SNMPQuery - always enable and set it to 28800 seconds for periodic polling.

SNMPTraps - this one is very useful, but can also affect scalability. I would recommend enabling MAC notifications on all non-802.1x/MAB ports (where authentication is not configured), except uplinks (inter-switch links). This will significantly improve profiling visibility.

Active Directory - always enable - the amount of information this probe provides is amazing (OS version, patch, etc). DHCP and this one can profile ALL corporate assests (with computer accounts in AD) with 100% accuracy.

DHCP SPAN and HTTP SPAN - bad bad bad, don't use. I think these are really legacy and very limited use case.

NMAP - powerful, but make sure PSNs are whitelisted on FWs and endpoint security agents! Otherwise it will make InfoSec OPS team lives miserable 🙂

Any comments? 🙂

Re: The more profiling probes you

Jason Kunst — Mon, 08 Apr 2019 15:33:33 GMT

Recommend the profiling guide https://community.cisco.com/t5/security-documents/ise-profiling-design-guide/ta-p/3739456

Re: The more profiling probes you

Tymofii Dmytrenko — Mon, 08 Apr 2019 15:39:57 GMT

Thanks

I've read this one (and many more), also attended pretty much every Cisco ISE session on Cisco Live 2018 🙂