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.

Now basically we can start configuring nameif , IP address and security level for this Redundant1 interface but let’s be more creative and create some VLANs on it.

So far :

Santa(config-subif)# vlan 120
Santa(config-subif)# nameif dmz
Santa(config-subif)# security-level 50
Santa(config-subif)# ip address 10.0.0.12 255.255.255.0

To remind you state of the physical interfaces comprising the Redundant 1 is :

interface Ethernet0/0
no nameif
no security-level
no ip address

interface Redundant1
member-interface Ethernet0/0
member-interface Ethernet0/2
no nameif
no security-level
no ip address

Now some verification is looming (pay attention to the bottom of the output where you can see which interface is currently active and how many state changes have happened so far) :

Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
Available but not configured via nameif
MAC address 001b.d589.9892, MTU not set
IP address unassigned
1870 packets input, 150617 bytes, 0 no buffer
Received 1329 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
766 L2 decode drops
264 packets output, 24326 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
input queue (curr/max packets): hardware (9/18) software (0/0)
output queue (curr/max packets): hardware (0/2) software (0/0)
Control Point Interface States:
Interface number is 10
Interface config status is active
Interface state is active
Redundancy Information:
Member Ethernet0/0(Active), Ethernet0/2
Last switchover at 07:25:35 UTC August 19 2010

exec mode commands/options:
error errors
event events

redundant interface Redundant1 switching active from Ethernet0/2 to Ethernet0/0.

Send gratuitous ARP on Redundant1.100.
Send gratuitous ARP on Redundant1.120.
redundant interface Redundant1 switch active to Ethernet0/0 done.

Switch has happened, now verify it:

Control Point Interface States:

Interface number is 10
Interface config status is active
Interface state is active
Redundancy Information:

Member Ethernet0/0(Active), Ethernet0/2
Last switchover at 07:57:11 UTC August 19 2010

Having done a bit practice the dry theory comes next.

• You can define up to 8 Redundant interfaces (if you have ASA 5580 why not?);<\li>
• All the interfaces in the same group should be of the same type (Ethernet with Fiber won’t go well) ;<\li>
• Only one interface is passing production traffic at any given moment;<\li>
• Redundant interface gets by default MAC address of the first added to it interface, configurable;<\li>
• When fail over happens to the second interface, it takes over MAC address of its previously active neighbour to prevent loss of traffic. If MAC is configured especially and manually it remains the same;<\li>
• You can force some interface to become Active using the command:
  Santa# redundant-interface redundant active-member <if_name><\li>
• Redundant interfaces are compatible with fail over feature.<\li>

For even more information , see:
ASA 8.3 interface configuration

• Enable RIP on the ASA;
• Dictate the version to work with – RIP v1 or RIP v2;
• Specify networks RIP protocol will be active for;
• Exclude some interfaces from active advertising RIP on them but allow to get
  RIP updates on them , i.e. passive interface(s);
• Decide whether you want auto-summarization or not. Default is on;
• Enable Rip updates authentication and whether it should be
  encrypted (MD5 mode) or clear text (text mode);
• If using authentication define authentication keys under relevant interfaces;
• To make your life harder you will be asked to redistribute;
• Finally verify and debug RIP operation.

SO let’s get our hands dirty.
Enable RIP routing process.

Set it to run exclusively version 2 . ASA doesn’t know to mix version
2 and 1 as IOS does.

Networks to be active for . You should specify classful nets or even if you specify anything different after you enter such networks ASA will automatically turn them into classful ones anyway.

Verifying configuration so far:

You will most probably want to disable summarization :

Exclude some interface from advertising on it:
- To suppress on ALL interfaces in one go:

- To be more specific:

Authentication is configured exclusively under the interface :
- Dictate which authentication mode to use.

- Specify the key (password) and its id.

Here is how it looks in show run interface :

Redistribute. Just redistributing learned in other ways networks into the RIP would be boring. As usual you redistribute connected, static, ospf and rip (when working with the rest of the protocols).

Much more interesting is to implement some policy while redistributing using route-maps. As expected route-maps here are not what we used to know in IOS.
So what can you match for me ?

The most familiar and useful match on ACL lies here:

About rest of the match conditions, I’ll cover them when talking about OSPF in ASA.

Filtering out routes in updates.
If you want to filter some networks in updates use distribute-list.

Now some debug is due.
Enable rip debug:

Normal functioning protocol debug output:

Now the authentication has been enabled but keys on 2 peers are not the same:

For such cases Cisco came with the nice feature called
ip source tracking that will gather flow statistics for specific destination
IPs (of victim) and periodically will export them for viewing, and will do all this without overloading the backbone router it is enabled on (Of course relevant if your SP is using Cisco gear) . Here are details:

– Enable it globally for the victim IP , here IP being attacked is 63.45.33.22

Edge(config)#ip source-track 63.45.33.22

- If you want (and if this is being done by SP they will not) you may create log entries:
Edge1(config)#ip source-track syslog-interval 2
Then you will see in logs (good for reminding to disable this afterwards) :
May 28 10:55:47.105: %DOS_TRACK-5-CFG: IP Source Tracker configured for 1 hosts

- Also you may define how often to export gathered info to be viewed (seems to depend on the platform ) :

Edge(config)#ip source-track export-interval 60

- And finally , you see the data accumulated so far :

Edge#sh ip source-track
Address SrcIF Bytes Pkts Bytes/s Pkts/s
63.45.33.22 Fa0/0 141G 485M 8244 141

Most important here will be the Source interface (in this router there is only 1 ingress interface , in real backbone you will have few feeds) where you see most of the incoming traffic for this destination IP. Then you (SP) would go to the upstream router connected to this local interface, enable the same source tracking and so on. Up to the last point in the backbone where the attacking traffic enters
the backbone of SP out of some upstream SP . Then SP would have option to contact the abuse of this upstream provider for them to investigate the issue further, or at least divert the attack to the black hole at the entry point, so end client would not be affected at all.

So lets look at accounting closer.
When enabled on the interface it  creates database of accounting information
containing number of bytes that passed the router  between pairs of IP addresses. There are actually more types of accounting  but here I’ll talk about 2 types only: IP accounting and  IP access-list violations accounting. The first gathers statistics  for the traffic passing the router – entering and leaving it (means traffic that destined for or originating from the router itself is not accounted for). The 2nd type gathers info about traffic that is being rejected by the router according to applied ACLs. Both types can be enabled for physical/logical interfaces only (so to say VTY is not in the pack).

Both types share the same database memory space. And talking about memory -
by default router keeps 512 records, after these are exhausted no new accounting info is recorded. As usual , this is configurable (see later).

IP accounting

Here is a sneak preview of accounting at work:

   Source           Destination              Packets               Bytes
122.94.42.91     62.20.179.36                       2                 223

What you see is Ip addresses spotted in the IP packet header as source/destination
, number of packets and bytes. The database is updated continuously as traffic
passes the router.

IP accounting condifuration

- enable on the interface of interest (only outbound traffic is recorded),
i.e traffic leaving interface
- if desired tune number of kept records
- see in CLI gathered info
- see info through SNMP agent (won’t cover here)
- clear active accounting database and copy snapshot to checkpoint  database
(done at once)
- see later at any time snapshot in checkpoint database or active records
in real-time

So here is our CLI:
1) Enable on interface
Router(config)#int fa0/1
Router(config-if)#ip accounting [output-packets]

2) [Optional] Tune maximum records value if desired (default 512, maximum 4294967295):
Router(config)#ip accounting-threshold 1200

3) See the active records in the database:

Router#sh ip account
   Source           Destination              Packets               Bytes
68.146.13.6       162.30.79.36                       1                 129
79.82.168.224     162.30.79.36                       1                 126
142.53.125.103    162.30.79.36                    9237              423360
83.171.0.22       162.30.79.36                       1                 129
118.181.13.61     162.30.79.36                       4                 360

4) Copy active database to checkpoint database and wipe out active db records:

Router#clear ip account
Router#sh ip accounting checkpoint

  Source           Destination              Packets               Bytes
68.146.13.6       162.30.79.36                       1                 129
79.82.168.224     162.30.79.36                       1                 126
142.53.125.103    162.30.79.36                    9237              423360
83.171.0.22       162.30.79.36                       1                 129
118.181.13.61     162.30.79.36                       4                 360

Usage tip: What is this good for at all? As I started in the previuos post
I use such info to provide some insight to the client of what is going on
(or rather going in/out) in his network at the given moment. So, all these
commands I do on the client’s perimeter equipment which we manage. I have
no slightest inclination to do this for client/whoever on my backbone
gear, and you would be advised not too. Just try to enable accounting on the
router passing gigabits of traffic and you’ll have some ‘splaning to do
afterwards .  And in general be advised that many of the posts in my blog come
from Service Provider view  and not of the end-client enterprise
(no matter how big it is) standpoint.

5.5) Some extra-bonus configs though – you may configure ACL that will filter
for what IP addresses to gather accounting info only. While trying to catch
who is loading your network would be counter-productive to use such filtering,
for monitoring long-time  it makes sense:

  Router(config)#ip accounting-list 19.90.14.59 0.0.0.0

Then to  database will be written only records involving this IP(s):
 
  Router#sh ip account
   Source           Destination              Packets               Bytes
19.90.14.59    162.30.79.37                       7                2912

IP access-list violations accounting.

This accounts for traffic blocked by ACL(s) applied to the interface(s)
- To enable :
Router(config-if)#ip accounting access-violations
Accounting will exclude mls traffic when mls is enabled.

-  To see the records:
Router#sh ip accounting access-violations
  Source           Destination              Packets               Bytes   ACL

Accounting data age is 8

* Of course to see something you need to have some blocking ACL applied to the
interface(s) beforehand. As I have no ACL on any interface this db is empty.

USAGE TIP 2: If you use this feature to spot most loading flow, you’ll love this
one-liner that after  you pass to it (through std input) print out of
the show ip accounting will sort data by bytes passed in ascending order:

*Hint  Darkstar is Linux machine, not router itself .
  root@DarkStar:~# sort -n -k4,4
<NOW COPY PASTE OUTPUT FROM ROUTER HERE …>
68.146.13.6       162.30.79.36                       1                 129
79.82.168.224     162.30.79.36                       1                 126
142.53.125.103    162.30.79.36                    9237              423360
83.171.0.22       162.30.79.36                       1                 129
118.181.13.61     162.30.79.36                       4                 360

79.82.168.224     162.30.79.36                       1                 126
83.171.0.22       162.30.79.36                       1                 129
68.146.13.6       162.30.79.36                       1                 129
118.181.13.61     162.30.79.36                       4                 360
142.53.125.103    162.30.79.36                    9237              423360

USAGE TIP 3:
To even further improve on the one-liner above below is again one-liner
that not only sorts accounting data by Bytes field but also sums up bytes per
Ip address (here in the 2nd field, but you can esaily modify to your needs):

root@DarkStar:~# sort -n -k4,4 | awk ‘{ips[$2] += $4} END { for (x in ips) print x,ips[x]}’
122.53.125.103   162.30.79.36                       3                 120
59.44.58.120     162.30.79.36                       3                 417
123.203.142.106  162.30.79.36                       1                 177
82.144.177.32    162.30.79.36                       1                 234
218.103.137.105  162.10.79.36                       1                 126
80.37.83.120     162.10.79.36                       1                 126
79.182.121.216   162.10.79.36                       9                 377
207.191.202.251  162.30.79.36                       9                 377
84.195.248.47    162.20.79.36                       7                 304
201.95.211.8     162.40.79.36                       8                 364
79.180.14.184    162.30.79.36                      24                 994
124.64.176.192   162.70.79.36                       5                 227
62.219.133.44    162.30.79.36                      72                3077
91.196.214.6     162.40.79.36                       4                 160
125.125.227.168  162.40.79.36                      15                 797

0
162.20.79.36 304
162.40.79.36 1321
162.30.79.36 5396
162.10.79.36 629
162.70.79.36 227
root@DarkStar:~#

Here I’ll wrap up my short (if you ask me) memo with few links for those interested to deep digger :

1) The whole book dedicated to knowing your network better :

Network Management: Accounting and Performance Strategies
by Benoit Claise – CCIE No. 2686; Ralf Wolter

http://www.ciscopress.com/bookstore/product.asp?isbn=1587051982

Cisco IOS command reference:

http://www.cisco.com/en/US/docs/ios/12_3/ipaddr/command/reference/ip1_i1g.html#wp1091971

PS Next post I am planning to do on Netflow , the beast of accounting to be tamed.

login block-for 300 attempts 5 within 50
#apply specified ACl to VTY line when above event occurs, it is meant to exempt
#your managemnt IP form being blocked. After timed block expires this ACL gets removed
#from VTY and previous ACL that was applied before the event is reapplied back

login quiet-mode access-class anti-DOS

#Logging rate-limitation to prevent cluttering logs with failed attempts
login on-failure log every 10

ip access-list standard anti-DOS
 permit 193.193.193.33
 remark Deny VTY access to anyone else if brute-force logins take up all VTY lines
 
Another nice feature is delay between login attempts:
Sacramento(config)#login delay 2
Delay login is in seconds

Then in logs you will see the following failed attempts:


*May 2 02:04:14.105: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: ] [Source: 62.141.52.141] [localport: 22] [Reason: Login Authentication Failed] at 05:04:14 Sat May 2 2009
*May 2 02:04:22.112: %SEC_LOGIN-1-QUIET_MODE_ON: Still timeleft for watching failures is 22 secs, [user: ] [Source: 62.141.52.141] [localport: 22] [Reason: Login Authentication Failed] [ACL: anti-DOS] at 05:04:22 Sat May 2 2009
*May 2 02:09:22.091: %SEC_LOGIN-5-QUIET_MODE_OFF: Quiet Mode is OFF, because block period timed out at 05:09:22 Sat May 2 2009