Prevent Discovery from Probing the SSH port on Firewalls

Doug5
Tera Contributor

How d I prevent Discovery from using SSH o Firewalls?

 

The Network Admin has complained about Errors in the Firewall logs about the MID Servers trying to login to the Firewalls using SSH.  The Firewalls are actually discovered by SNMP.  For Firewalls, Shazzam finds bot the SSH and SNMP ports open so ServiceNow discovery probes both ports and tries to login using SSH - and fails of course. It would be nice of ServiceNow had some sort of "Discovery Port Affinity" - but anyway - that irrelevant.

 

I have tried using a Behavior - and that works fine.  I have created a new Discovery Schedule with a Behavior of "SNMP Only".    

 

The problem comes with Exclusions.  I then tried to exclude the Firewalls from every other Discovery Schedule.  The Global Exclusion rule that I created works fine - but it also excludes the Firewall IPS from my new Discovery Schedule for Firewalls.  So this new Discover Schedule actually discovers nothing - be because the IP List is effectively empty.    I could potentially edit every Discovery Schedule (there are several hundred) and put in an Exclusion on all the IP Range Sets - but this would take time and be hard to maintain.

The problem is that the Global Exclusion list always takes precedence - and this can't be overruled.  I believe there is a property that can be used to turn off global exclusions - but this seams like a bad idea and would create other issues.

 

ChatGBT told me about a System Property called 'glide.discovery.post_shazzam_script' which apparently can be used to Add a JavaScript Script which supposedly runs after Shazzam.  The Script I created is shown below.  But this script does not work.  I have Googled the system property and can find no hits - so I think ChatGBT is hallucinating.

Anyone got any bright ideas?

 

1 ACCEPTED SOLUTION

dbook
Kilo Sage

The right solution to adhere to OOB pricinples is to exclude at the range set level, but appericate you don't want to do this manually. 

 

I think a flow could help with this...

 

 

  1. I would create a flow that is triggered by the creation of Firewall CIs or runs periodically and looks up the Firewall CIs. 
  2. For each record, take the IP. 
  3. Than look up all active range sets, excluding your specific firewall range set(s)
  4. If missing, add the IP to the excluded list 

 

This should ensure the Range sets are automatically updated whilst allowing the specific ones to still scan the relevant IPs. 

 

Hope this helps! 

View solution in original post

3 REPLIES 3

dbook
Kilo Sage

The right solution to adhere to OOB pricinples is to exclude at the range set level, but appericate you don't want to do this manually. 

 

I think a flow could help with this...

 

 

  1. I would create a flow that is triggered by the creation of Firewall CIs or runs periodically and looks up the Firewall CIs. 
  2. For each record, take the IP. 
  3. Than look up all active range sets, excluding your specific firewall range set(s)
  4. If missing, add the IP to the excluded list 

 

This should ensure the Range sets are automatically updated whilst allowing the specific ones to still scan the relevant IPs. 

 

Hope this helps! 

Doug5
Tera Contributor

Thanks dbook for your answer.  Your suggestion is a good one.  I like your idea,  I also had an idea last night see below.  I am currently trying to decide which idea is best.

 

BTW:  This question is a Duplicate of Prevent Discovery from Probing the SSH port on Fir... - ServiceNow Community. Sorry.  I accidentally created it twice.  There used to be a button to display one's Questions, but I can't find it anymore!  Anyway - different problem.  


Second Solution
dbook's suggestion is one possibility.  Another possible solution is the following:


I could add the Global Exclusion for the firewalls as a Seperate Exclusion.  I could then run the Firewall Discovery using a scheduled Flow.  I would use a Scheduled Flow (rather than a Scheduled Job) because Flows are better at pausing and waiting for things.  This would the temporarily remove the Firewall Exclusion, run the Scheduled Discovery using thee discoveryAPI, wait for the discovery to finish and then put back in the Global Exclusion for the Firewalls.
I wish there was a Comment fields on Scheduled Discoveries - so that Support don't get terribly confused by all this in the future.

So which solution is preferable?  Hummm..

Doug5
Tera Contributor

In the End, I created a Scheduled Job that loops the  firewalls in the CMDB and adds (or removes) their IP Address in a new Global Exclusion List just for Firewalls.  Only a203 Firewalls were being discovered using Horizontal Discovery;  Most pf the Firewalls were being imported using an SNMP Get from SolarWinds.