APC and SNMP Attack

[jpro]

When discovery encounters our APC UPS devices it detects and adds the device. Then the administrators call due to the "Unauthorized" SNMP access attempts. I can see the credentials in the affinity table but it appears that each time there are five additional attempts during the discovery of each APC unit (and generating an e-mail to the admins for each).

I am not sure how to debug this issue and locate the cause. Is it possible that the sensor/probe has a portion that is not using the affinity table? The IP addresses are static so I understand during the first scan but thought subsequent scans would avoid the unauthorized attempts.

Any suggestions would be great.

Jim

[doug_schulze]

I haven't seen this anywhere else and I can't repeat it so you may open a ticket with support and see what they have to say.

[ssavage]

We have the same issue with the APC UPS. At this time I have excluded them from Discovery until the Analyst that looks after the UPS has time to work with me to remedy the problem.

[jonprivatt]

We've been having credential issues ever since we moved to powershell. I've been following 3 or 4 tickets (not all apply here).

I'm not sure how their code uses the affinity table when it comes to SNMP/SSH attempts, but there are some issues with the affinity table and how it is working overall.

Some of this has been promised by Aleck to be fixed in Aspen 8 / Berlin 1, although that remains to be seen.

[jonprivatt]

Well, it is confirmed. SNMP credentials don't work the way that I expect them to. We've opened a ticket INT2031838, but so far we've just gotten a lot of bad answers. Our network guys are complaining about daily attacks and security logs filling up; it is hard to isolate legitimate attacks in a crisis situation when discoveries are creating 4 security failures every time we discover a device.

Using Wireshark to capture data on a single midserver discovery, here is what is going on up through Berlin hotfix 3:

First, the system tries the entry from credential_affinity table (i.e. the community string that worked last time), unfortunately it doesn't wait even close to long enough and moves on.

Then it seems to send of a barrage of all snmp community strings (+ public) to see if it can get a response from any of them. In our case, that results in 4 failed attempts each time.

Of course, the one that it tried first was correct, so it latches onto that one and continues happily on its way.

There are 2 problems with this approach:

1. If the system isn't going to wait long enough for a response from the community string that worked last time, why even bother.

The timeout is so short that even a UPS or printer (which respond to snmp requests very quickly) have no chance of answering quickly enough.

Routers are busy devices and snmp requests are very low on their "to do list"; they have no chance whatsoever. In a twisted turn of fate, these are the devices that actually have logs that the network guys pay attention to.

2. Sending off ALL the other community strings in a barrage (or at least rapidly firing them) completely defeats the the concept of trying these things in any given order. Being a generally sensible person, I thought the reason for putting these things in any sort of order was to REDUCE the failures and the security log footprint (SlightlyLooney even mentions this in his old blog back when he wrote this code).


We've been repeatedly told that discovery is transparent, no impact, noone will notice it is running. This behavior seems to run counter to philosophy.


The only way I see to fix this, other than a coding change to allow adjustable timeouts, is to get all devices in the organization to run on the community string of "public", thus 100% eliminating the failures. lol

Jon.