196 Chapter 6 Cisco IOS Firewall Authentication and Intrusion Detection

Creating and Applying Audit Rules

Let’s begin tackling this section by defining default actions for both info and attack signature types and then creating an audit rule. Then you’ll apply the audit rule to an interface and specify a direction.

Setting Default Actions

Recall the three possible actions the IOS Firewall IDS can take when a signature is matched: alarm, reset, or drop. You can use any one or any combination of these actions, but the default is to alarm:

Lab_B#conf t

Lab_B(config)#ip audit ?

Lab_B(config)#ip audit info ? action Specify the actions

Lab_B(config)#ip audit info action ?

alarm Generate events for matching signatures drop Drop packets matching signatures

reset Reset the connection (if applicable) Lab_B(config)#ip audit info action alarm

This takes care of the info signatures, leaving them set to the default action of alarm. To change the action for attack signatures to both drop and reset in addition to alarm, check out the following example:

Lab_B(config)#ip audit attack ?

action Specify the actions

Lab_B(config)#ip audit attack action ?

alarm Generate events for matching signatures drop Drop packets matching signatures

reset Reset the connection (if applicable)

Lab_B(config)#ip audit attack action alarm ? drop Drop packets matching signatures reset Reset the connection (if applicable) <cr>

Lab_B(config)#ip audit attack action alarm drop ? reset Reset the connection (if applicable) <cr>

Lab_B(config)#ip audit attack action alarm drop reset ?

<cr>

Lab_B(config)#ip audit attack action alarm drop reset

Lab_B(config)#^Z

Lab_B#

Look at the context-sensitive help offered in the preceding example and note that after setting the alarm action, you still have the option to drop and/or reset. Also, the option <cr> becomes available only after you add all three actions.

Creating an Audit Rule

Okay, with the default settings out of the way, you’re now ready to create an audit rule and give it a name. A little later, you’ll apply it to an interface. As with the default actions you just ran through, you can specify a list of actions for the audit rule based on both info and action signatures. Replicating what you did with these two signatures previously and naming your audit rule toddaudit, this configuration on the Lab_B router will look like the following:

Lab_B#conf t

Lab_B(config)#ip audit name ?

WORD Name of audit specfication

Lab_B(config)#ip audit name toddaudit ?

198 Chapter 6 Cisco IOS Firewall Authentication and Intrusion Detection

Lab_B(config)#ip audit name toddaudit info ? action Specify action(s) for matching signatures list Specify a standard access list

<cr>

Lab_B(config)#ip audit name toddaudit info action ? alarm Generate events for matching signatures drop Drop packets matching signatures

reset Reset the connection (if applicable)

Lab_B(config)#ip audit name toddaudit attack ? action Specify action(s) for matching signatures list Specify a standard access list

<cr>

Lab_B(config)#ip audit name toddaudit attack action ? alarm Generate events for matching signatures drop Drop packets matching signatures

reset Reset the connection (if applicable)

Lab_B(config)#ip audit name toddaudit attack action alarm ? drop Drop packets matching signatures

reset Reset the connection (if applicable) <cr>

Lab_B(config)#ip audit name toddaudit attack action alarm drop ? reset Reset the connection (if applicable)

<cr>

Lab_B(config)#ip audit name toddaudit attack action alarm drop reset ?

<cr>

Lab_B(config)#ip audit name toddaudit attack action alarm drop reset

Lab_B(config)#^Z

Lab_B#

Here again, the context-sensitive help demonstrates the ways you can further define the available parameters.

Applying the Audit Rule

Now that you’ve created the audit rule, it’s time to apply it to an interface. The following example applies the toddaudit audit rule to the fast0/1 interface on the Lab_B router:

Lab_B#conf t

Lab_B(config)#int fast0/1

Lab_B(config-if)#ip audit ?

WORD Name of audit defined

Lab_B(config-if)#ip audit toddaudit ? in Inbound audit

out Outbound audit

Lab_B(config-if)#ip audit toddaudit in ?

<cr>

Lab_B(config-if)#ip audit toddaudit in

Lab_B(config-if)#^Z

Lab_B#

The direction in which you apply the audit rule makes a huge difference in the function of the IOS Firewall IDS. If you choose inbound on an interface, packets will be audited before any ACLs are applied. But if you opt for outbound, packets might be discarded by inbound ACLs on other interfaces before the IOS Firewall IDS has a chance to evaluate them. This could be bad—it means that precious alerts and resets could be totally missed because the IDS is never even given a chance to see these packets! Personally, I like the option of evaluating all packets that try to attack because it helps me refine my security policy and plug any holes. That’s why you see the IOS Firewall IDS applied inbound on the Lab_B router in the preceding example.

With everything in place so far, it’s now time to define which network is to be protected by the router. Here’s the ip audit command on the Lab_B router:

Lab_B#conf t

Lab_B(config)#ip audit po protected 172.16.1.1 to 172.16.1.254

Lab_B(config-if)#^Z

Lab_B#

Realize that once the audit rule is in place, several—even many—signatures may be scrutinizing packets. The different modules are evaluated in the following order:

1.IP

2.ICMP (if applicable)