Ever since we enabled CLI credentials for the Advanced Cisco ASA Monitoring feature, we now see about 300 NOTICE level syslog entries (%ASA-5-111008) per hour, per context because it logs in so often.
Because of this, we disabled the feature on all ASAs other than big ones.
It's hard to tell what info it needs SSH for. Most of the Syslog entries are things like:
%ASA-5-111008: User 'xxxxx' executed the 'enable' command.
On Admin contexts, we also see:
%ASA-5-111008: User 'enable_15' executed the 'changeto system' command
We don't find the ACL reports very useful, since by design, almost all properly designed rules should be shadowed anyway (i.e. deny specific, followed by permit general).
We're also concerned whether users with access to NPM see the ACL info or not. Normally, we limit access to config level info by granting or denying access to NCM. Does anyone know how Advanced Cisco ASA Monitoring access rights are determined?
Also, I don't see a way to tell it to check less often. I assume that all interface stats, and even connection counts are done by SNMP. So, I'm thinking we really don't need it to check the ASAs more than once or twice a day. Is there any way to set the rate of login?
What would be lost if the rate were less than the current 12 second intervals? (5 entries per minute for non-Admin context).
I know we can disable logging of such events, but that's the thing - we want the logging to remain on for these events.
Can anyone shed any light on these questions?
We too were using the latest Advanced Cisco ASA Monitoring / Network Insight feature but found it way too noisy for our logging systems and the Remote Access VPN has been very buggy with showing no users or showing duplicate users. We've since disabled the Advanced Cisco ASA Monitoring feature. It would be nice to set the polling for that particular feature to a different parameter than the node polling parameters.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.