Testing.
Before the configuration:

After the configuration:

NB Unfortunately it is a half-solution cause if telnet access is enabled on the Cisco then connection attempts to the port 23 will elicit the same “Connection refused” . To close even this disclosure hole , disable telnet as the management protocol and switch to SSH.
NB2 The good news for the pentesters out there is that rare ISP implement such protections

Case 1. Cisco IOS router acting as Ezvpn server , users are authenticated locally by the router. Let’s name it – group is JUNIPER , and the local user is John.Chambers and we want to confine this user to this group for ever.
Enable group locking for specific group (don’t forget to do the same for all VPN groups)

Now restrict user to be able to use this group only. For that you have to reconfigure user to look like username followed by delimeter (that can be any of @, %, /, \) and then group name , to be concrete

from now on user John.Chambers will be able to authenticate with Cisco only using John.Chambers@JUNIPER . It overrides any user for VPN connection that already exists, that is if there is already user John.Chambers it will not be able to connect with the group JUNIPER . On the other hand anyone getting PSK of the VPN group JUNIPER will fail authentication if the user is not explicitly reconfigured in the new format.
Case 2 . Cisco IOS router users are authenticated using external Radius server. Unlike local authentication, with Radius you create the user as usual – John.Chambers but then assign it in the Settings cisco-av-pair attribute called user-vpn-group, like this:
ipsec:user-vpn-group=JUNIPER
Case 3.ASA Local username authentication.
No fancy username/group configuration here, you just lock username to a group under general attributes of the user.

Case 4. ASA Radius authentication .
Here also the VPn group is forced for the user settings using the following attribute:
[3076\085] Tunnel-Group-Lock JUNIPER

Now define with access-list what traffic to inspect, you may use specific IPs or just general SNMP ports – udp 161 and 162:

Bind ACL to class-map:

Use the class-map in policy map with enabling snmp-map inspection :

And finally apply the policy map on some interface

As you already know this setup will exchange community strings in clear text and also no packet is cryptographically authenticated/verified. What a shame for “Adaptive Security Appliance” . The fix is on the way. It is called SNMP v3 and has 3 security levels to choose from:
noAuthNoPriv – packets are neither authenticated nor encrypted . Basically the model used so far by SNMP v1 and v2c – everything clear text.
authNoPriv – packets are authenticated , that is user is sent in clear text but its password is not , (configurable) MD5 or SHA algorithm.
authPriv – the highest level, all SNMP packets are both authenticated using MD5 or SHA and their content is encrypted with DES/3DES/AES (128,196,256) algorithm.
Using the list above let’s configure our ASA for each level .
General steps:

• Configure snmp-server group for every security level you want to use ;
• Creatre user for each security level you wan to use and assign it to the snmp-server group of your choice
• Create usual snmp-server host entry but adding version 3 and username to be used by this host. NOTE You can have only one such command per host but no matter which out of 3 security levels you specify in this command it will allow the other 2 to be used in querying as well

noAuthNoPriv.

Querying the ASA:

authNoPriv.

Querying the ASA:

authPriv.
Here everything will be encrypted.

N.B. To my surprise there is no such thing as debug snmp . Actually it does exist, but entering this command gives no error and produces no debug either.
Noticed by the way. In logs you can see all the passwords you entered while configuring SNMP, not very secure I would rather say .

Now create tracking process to be later applied to the static route:

And finally we create static route and attach to it the created track :

Now let’s see some statistics on the track:

The final configuration looks like

And by the way it really works – when track is down the route to which it is attached magically disappeared
from the routing table as should.

• ASA can not be NTP server as opposed to IOS.
• You can use prefer optional keyword with ntp server command but … it works if you have multiple servers having “the same accuracy” by Cisco.com words. In people’s language they mean the same stratum. If your ASA has 2 servers – one of stratum 2 and other of stratum 3 , even if you put stratum 3 server as preferred the one of stratum 2 will be selected.
• Authentication is available but oprional. The only algorithm of choice is MD5.
• You can have multiple trusted keys at the same time, I guess they will be tried in turn (needs verification).

Ok then, back to CLI – NTP server is 153.6.3.3, use authentication, MD5.

Some debug comes next :