How to do add IP Address exceptions to Discovery Schedules

[scroft]

When we run 'ssh only' discovery schedules we often get hundreds of ssh authentication failures.   Some are due to valid credential issues, but most are caused by core routers that have hundreds of interfaces with port 22 open.   My network team isn't willing to close these ports down, so I would like to add these into the "Discovery Range Item Excludes" list, but this feature appears to be meant more for IP ranges, not a list of several hundred mixed IP addresses that do not fall into easily categorized ranges?

Does anyone have any tips or tricks to exclude specific IP address from a discovery schedule.

As an example...   running an ssh only schedule on a class 'B' /16 network that contains 65000+ IP addresses, we do have exclusions for several class 'C' /24 subnets and the range item exclude feature works well for this.   But adding several hundred unique IP addresses appears to be a very tedious (one by one) process.   It's unfortunate that the 'Quick Range' type feature isn't available for Excludes as well.

Very possible that I am missing something, but either way thanks in advance for any advice on workarounds for this issue.

Steve Croft

[scroft]

Doug Schulze (an amazing fellow IMHO) helped me out with this elegant workaround.

First we needed to create a new Functionality Definition so that our discovery job would run an SNMP scan first and then an ssh scan.   We then used this new Functionality Definition in a new Behavior to address an issue we were having with this following scenario.

Originally we tried to run ssh_only scans on our production network for subnets that predominantly had servers within the IP ranges, but we were perplexed when we saw hundreds of ssh authentication failures in the discovery log.   We determined that the majority of these ssh authentication failures we caused by a couple of our core routers that had hundreds of interfaces with port 22 (ssh) open.   Since we had no ssh credential for these devices and our network team wasn't willing to shutdown port 22 on these interfaces, we were stuck with all of these ssh authentication failures so it was difficult to determine real authentication issues.

To resolve this issue we needed to first create a new 'Functionality Definition'

To create a new Functionality Definition … go to the Discovery Menu selections and select…

Discovery Definition…>Functionality Definition

Within the Functionality Definition… Click 'NEW'

I named my new Functionality Definition   'SNMP_and_SSH'

In the 'Port Probes' section, left click the lock and then the little magnifying glass and select these Port Probes…

snmp

ssh

dns

Then Save/Exit

Now you need to create a new Behavior using this new Functionality Definition.

To create a new Behaviour… go to the Discovery Menu selections and select…

Discovery Definition…>Behaviour

Within the Behaviour view… Left Click 'NEW'

I named my new Behaviour   'SNMP_and_SSH_Only'

Left Click Save/Stay

In the Discovery Functionality section, left click 'NEW"

In the Phase section enter:   '1'

In the Functionality Definition select:   'SNMP_and_SSH'

Left Click the MID servers lock and select the MID servers that you want.

This last step is important as it directs the sequencing of your Discovery Port Probes.

To define the sequencing of the Port Probes… go to the Discovery Menu selections and select… Discovery Definition…>Port Probes

You need to ensure that the snmp probe port has a lower sequence number than ssh.

In my case, snmp now has 'Classification priority' = 2 and ssh has 'Classification priority' =3

I believe that by default OOB settings have ssh at a lower sequence than snmp.

Change the 'Classification priority' if necessary.

You can now create a new Discovery Schedule and use the new ''SNMP_and_SSH_Only' Behaviour.

Let me know if you have any questions or need clarification regarding any of this.

Kindly,

Steve Croft

P.S.     Thank you Doug!!!