ISE - control NMAP - subnet inclusion ?

[ffischer]

Hello,

at a client we are running a large distributed deployment with 14 PSNs
We have enabled profiling to get visibilty whats on the network.

If a device sensor on the switches recognizes and accounts an IP address on an port to the ISE,
an automated nmap scan is triggered to collect more info about the connected device.
This is running for serveral years now and works.

Now we have observed that there are some weird IoT devices connected to the network
that sometimes send out packets containing public IP addresses as source.

These public adresses the devices sensor reports,
i.e. 33.0.113.157 ( 33/8 is assigned to the US DoD... ),
are accounted and trigger an unintended NMAP Scan to this external, public IP

Addionally, we saw some devices using obviously manually configured,
public IP adresses instead of the private IPs assingend by DHCP.

Of course, this should be fixed on the endpoint.
But what is connected to the network is not always under our control...

What would happen of a malicous client is connected to a switch port
and spoofs a large number MACs and/or public IPs ?
(unless I limit IPs per MAC in switch Decvice Tracking and the number of MACs on the port)

My goal is to prevent ISE Profiles from scanning IP Addresses that are not internal.

I have found "NMAP Scan Subnet Exclusions" in the profiler settings to
exclude subnets with devices having fragile IP stacks (imho a really good approach)
but I have not found a setting like "subnet inclusion" or "scan only in subnets".

Is there a solution to restrict the profiler nmap scans to internal subnets only ?
(most often RFC1918 addresses 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)

Thanks & BR

Frank

[ahollifield]

I don't typically recommend enabling the NMAP probe on ISE.  I find its not very accurate and it can be quite resource intensive depending on the scale of the deployment.  I think you would be much better served here by using the new AI/ML profiling available in ISE 3.3 and/or an external profiling tool such as Ordr.

[ffischer]

So you really suggest running 3.3 in a productive environment with several 10.000 endpoints high network resilience and availability requirements ?
I'd say: maybe once in the future when there will be a 3.3p5 or p6...

Another idea I had just while writing this here:
Instead of configuring a default gateway on ISE PSNs,
I could try to only configure static routes for internal private networks on my PSNs:
 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Or does a PSN contact Cisco Profiler Feeds, Licensing Portals etc. or any other cloud services directly ?

[ahollifield]

I was only offering a suggestion to move away from the NMAP scan.  If you are risk adverse then sure, wait for future versions of ISE 3.3.  

ISE has to have a default gateway configured.  You could maybe try the opposite and add black hole for static routes for the IPs you never want ISE to be able to talk to but this may have other unintended consequences, never tried it.

If you are a heavy IoT/OT environment, you will benefit highly from a dedicated profiling tool.  The NAC-based profilers simply don't have the level of granularity purpose built SPAN-based profilers do. 

[Aref Alsouqi]

As far as I know there is no way to configure NMAP scanning to only specific IPs or networks. NMAP scanning would be triggered towards the interested endpoints which would defeat the purpose of defining which IPs or networks should be defined as that piece of info will be automatically provided through the profiler engine.

I agree with @ahollifield I would not recommend NMAP unless there is a valid reason behind using it. Usually ISE profiling works just fine without any additional scanning, and usually NMAP scanning would be used if you have plenty of unknown devices that failed to be profiled.

Also, I would be highly concerned and suspicious about the IoT devices that would source with public IP addresses that belong not only to the DoD or any government ranges but even to any random public addresses in general, that potentially would be considered as an indication of compromise and would require immediate actions and clarification with the vendor. 

Regarding your question about avoiding a malicious user from spoofing MAC addresses, you can overcome or limit that by applying downloadable access lists to the MAB sessions through ISE. That will help you limiting the accesses of those MAB devices to only what they should be allowed to communicate with.

[ffischer]

Thanks for your comments, Aref.
We have serious reasons to use nmap for profiling in addition to the device sensor.
we still have some older switch models in the network that are due to be replaced, but budget & ressources are not unlimited,
so this takes some time. dACLs cannot be used on all switches, especially the older ones...
regarding concerns:
The client monitors its network.
The highly suspicous scans to 33....IPs from ISE
were discovered on the perimeter firewall.
We are investigating already.
The one device in question is an older IIoT sensor...
It may be an IoC or it may be a buggy old IP stack...

[MHM Cisco World]

there is option to use manual NMAP (in which you can specify only one subnet), maybe this what you looking for 

MHM

[ffischer]

Nope.
The switch device sensor reports an MAC/IP to ISE.
On ISE, this triggers a nmap scan to the IP reported.
I could switch this automatism off completely, but this would lower our visibility what gets connected to the net.

I'd like to have more flexibility about defining what triggers a scan and what does not...

[MHM Cisco World]

OK try add profile policy and use NMAP action to scan specific port
in condition you can use other profile to match this policy 

Cisco Identity Services Engine Administrator Guide, Release 2.4 - Profiled Endpoints on the Network [Cisco Identity Services Engine] - Cisco

MHM

[ffischer]

MHM,
basically this would be a valid approach...

Meanwile I set up another eval VM with 3.2 and while installing
digged a bit through the profiling design guide - nmap probe
Paragraph "NMAP Probe Endpoint Scan" says:
"Endpoints that match the Unknown profile are automatically scanned using the SNMPPortsAndOS-scan which performs both an SNMP ports and OS scan. This is not a configurable response. It is intended to allow ISE Profiling to quickly gain more information about any endpoint that is discovered but not profiled."

With that in mind ISE absolutely "works as designed"

Unfortunately, this causes unwanted behaviour of the ISE
by misconfigured or buggy or malicous endpoints
emmitting  packets with non-internal ip addresses as source IP
under certain conditions.

But sadly I have to admit that I do not have a real business case
to convince Cisco to make the unknown profile configurable according to my needs....
But maybe one of the Cisco ISE product desingers or architects reads this, likes my idea and puts it
on the feature list to be implemented some time....

[Aref Alsouqi]

I see. ISE PSNs would need to communicate externally as listed in this link:

Cisco Identity Services Engine Installation Guide, Release 3.0 - Cisco ISE Ports Reference [Cisco Identity Services Engine] - Cisco

Another option you can workaround this would be to setup some security rules on the edge firewall to denying the outbound traffic of the IoT devices to all IPs with the exception for their vendors IP or any other legitimate public services such as public DNS and NTP.

[ffischer]

Cisco Identity Services Engine Installation Guide, Release 3.2 - Cisco
Well, I know the Node Communnication matrix, the ports and and the table
"Required Internet URLs"  for specific features  at the end of this page.
But imho it is not totally clear documented  which nodes PSNs, ADM , MnT Nodes connect to the service.
i.E. I'd suspect only ADM nodes connect to Smart licensing and distribute that into the deployment.

Setting some security rules on the edge firewall imposes the same risk for ISE PSNs not beeing able to communicate to necessary cloud services like only routing specifc private network ranges. (but we could log what is blocked...).
All those things are workarounds for missing funtionality: we have "exclude" list ... adding a "not exclude" list would solve the thing.

[Aref Alsouqi]

I agree, the link should show the personas that would require each connection, however, to download the profiler and the posture feeds the PSNs would need to connect to Cisco public portals. As you said, the licenses sync will be done through the primary PAN not the PSNs.