Credential Affinity Problem

[Bob D]

[Kingston]

I have some IP firewalls that I Discover using SNMP.    The devices appear to be Discovered properly,  meaning the CIs are created/updated and when I review the ecc queue logs, I can see the progression through SNMP classification and SNMP identification working.  I can see the OIDs returned in the XML payloads.  It seems to be working.  However - Discovery is attempting a Unix classification first since SSH classifier is prioritized over SNMP classifier.  I have a lot of ssh credentials, so it tries all of them and fails ... every time ...  before it gets to the SNMP credential.    A credential affinity should prevent this from happening, but there is no affinity created for these firewall IPs.   Any reason why this would be?      

[doug_schulze · Accepted solution]

Bob, 

A couple of things here... 

Your credential affinity does not affect the classification priority nor the IP affinity.  While the Credential affinity will prioritize the credential order, when it gets to classifying the device its a different process. You'll want to do some modification to support and remedy your challenge.

First, enable the IP Service Affinity.  This will use the last known protocol that was successful from the first discovery then use the same on the second, third, tenth discovery until it fails. Ultimately this will do what you had hoped it would do with the credential affinity from your question.

Secondly, before we had that and came across your problem, I would (and still do) change the classification priority on your port probes. Have SNMP go before SSH. What you will get from that is when we come across a router that does ssh and SNMP, we will try SNMP first and if successful never try SSH.  This will help those brand new devices that we haven't come across before and that don't have your newly enabled IP Service Affinity.

Hope this helps.

[Bob D]

Doug - thank you

Not sure I follow you here, though

I believe you are telling me that the credential affinity does not affect the order of the classification probes.  It's going to try ssh first regardless unless I change the probe order.  Correct?   

But then what is the credential affinity for?   Does this mean that only after a device is classified as, say, an SNMP device, that the affinity is used only to prioritize one of the SNMP credentials to try first?    And even if the answer is YES - why don't I have an affinity created for my firewall?

I will look into enabling IP Service Affinity.

addressing your second recommendation - if I set snmp higher priority than ssh,  it would help with this specific issue, but wouldn't it also cause my ssh/linux servers to be classified/identified/explored via snmp instead of ssh (assuming there is a valid snmp credential)?  that's not what I want, either.

[Andrew Westerv4]

Credential Affinity is only for identifying an IP Address to a successfully authenticated Credential. The WMI, SSH, SNMP (OOB classification order) will still occur regardless of Credential Affinities. This not only helps Discovery's performance, but reduces the amount of brute force authentications that InfoSec teams will see.

You are correct about the re-ordering of SSH and SNMP as most Linux servers also have SNMP turned on by default. That is why I proposed the SSH probe suppression script as possible remediation. If you're firewall has a specific banner other devices don't use, you may be able to "blacklist" it in the script. Another example of "SNMP > SSH Discovery" would be for Cisco switches and routers that can have the below banner:

<banner_text>SSH-2.0-Cisco-1.25 </banner_text>

[Bob D]

Thanks Andrew.  I have not looked at the script yet, but I like the possibilities you mention.  Will definitely check it out.