Creating and Applying Audit Rules

The Cisco IOS IDS technology works as an inline sensor, monitoring packets as they travel between the router’s interfaces. If a packet, or group of packets, in a session matches an active signature, the IOS IDS can perform any or all of the following actions based on the predefined router configuration.

Alarm Sends an alarm to a Syslog server and/or a Cisco Secure IDS Director
Drop Discards the packet
Reset Resets the questionable TCP connection

Two basic steps are necessary to set up the packet auditing process for the Cisco IOS Firewall IDS router.

Create an audit rule specifying which signatures are to be applied to packet traffic and the specific action(s) to take when a match is found.
Apply the audit rule to a router interface, specifying a traffic direction (in or out).

As packets pass through an interface covered by the audit rule, they’re monitored by a series of audit modules in the following order:

IP module
TCP, UDP, or ICMP modules (as appropriate)
Application-level modules

If a pattern matching a known signature is found by any audit module, then the following action(s) occur, based on the instructions included in the router configuration. Any or all of the actions can be configured.

Action	Result
alarm	The module completes its audit. It sends an alarm to the Syslog and/or IDS Director. The packet is forwarded to the next module.
drop	The packet is dropped from the module, discarded, and not sent to the next module.
reset	If this is a TCP session, the reset flag (bit) is set On and sent to both ends of the session. The packets are forwarded to the next module.

Note?

Cisco recommends the drop and reset actions be used together.

If multiple signature matches occur as a packet is processed by a module, only the first match triggers the specified action—the packet is either discarded (drop) or moved immediately to the next audit module (alarm or reset). Additional matches in other modules can trigger additional alarms, but only one per audit module. This separates the IOS IDS implementation from the Cisco Secure IDS Sensor appliance, which identifies all signature matches for each packet.

Creating an Audit Rule

The idea is to define an audit rule, specifying which signatures should be applied to packet traffic and the action(s) to take when a match is found. The signature list can have a single signature, all available signatures, or a partial list of the signatures. The signatures can be informational and attack signatures. Signatures can be disabled in case of false positives or to meet the unique requirements of the network environment.

Using the ip audit info and ip audit attack commands is necessary to set the default actions for respective signatures. Both types of signatures can take any or all of the following actions: alarm, drop, and reset.

Define Info Audit Actions

Use the global configuration mode command ip audit info to specify the default action(s) for info-type signatures. Use the no form of this command to set the default action for info signatures. The syntax is

Rtr1(config)#ip audit info {action [alarm] [drop] [reset]} Rtr1(config)#no ip audit info

Action	Sets an action for the info signature to take when a match occurs
Alarm	Sends an alarm to the console, IDS Director, or to a Syslog server
Drop	Drops the packet
Reset	Resets the TCP session

This command was introduced in IOS 12.0(5)T. The default action is Alarm.

In the following example, the default action for info signatures is set to all three actions:

Rtr1(config)#ip audit info action alarm drop reset

Define Attack Audit Actions

Use the global configuration mode command ip audit attack to specify the default action(s) for attack-type signatures. Use the no form of this command to set the default action for info signatures. The syntax is

Rtr1(config)#ip audit attack {action [alarm] [drop] [reset]}
Rtr1(config)#no ip audit info

action	Sets an action for the info signature to take when a match occurs
alarm	Sends an alarm to the console, IDS Director, or to a Syslog server
drop	Drops the packet
reset	Resets the TCP session

This command was introduced in IOS 12.0(5)T. The default action is alarm.

In this example, the default action for attack signatures is set to all three actions:

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

Create Named Audit Rules

Use the global configuration mode command ip audit name to create audit rules for info and attack signature types. Any signatures disabled with the ip audit signature command don’t become a part of the audit rule created with the ip audit name command. Use the no form of this command to delete an audit rule. The syntax is

Rtr1(config)ip audit name audit-name {info | attack} [list standard-acl] [action [alarm] [drop] [reset]]
Rtr1(config)no ip audit name audit-name {info | attack}

audit-name	The name for an audit specification.
info	Specifies that the audit rule is for info signatures.
attack	Specifies that the audit rule is for attack signatures.
list	Specifies an ACL to attach to the audit rule.
standard-acl	The integer representing an access control list. Use with the list keyword.
action	Sets an action for the info signature to take when a match occurs.
alarm	Sends an alarm to the console, IDS Director, or a Syslog server.
drop	Drops the packet.
reset	Resets the TCP session.

This command was introduced in IOS 12.0(5)T. The default action is alarm.

In this example, the default action for attack signatures is set to all three actions:

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

The following example creates an audit rule named Audit.99 for info signatures that’s configured with all three actions:

Rtr1(config)#ip audit name Audit.99 info action alarm drop reset

This example demonstrates disabling signature 1000 and then creating an info signature audit rule named Audit.33 that doesn’t include that signature:

Rtr1(config)#ip audit signature 1001 disable
Rtr1(config)#ip audit name Audit.33 info action alarm drop reset

Using ACLs with Named Audit Rules

Using a Standard ACL to help define the traffic to be audited by an audit rule is possible. In the following example, an audit rule named Attack.7 is created that uses ACL 25, which is defined later in the configuration. The ACL doesn’t behave the way you’d assume, particularly if you’re thinking of it as if it were filtering interface traffic. Instead, when used in this context, the deny statements are indicating that the private networks—192.168.0.0 to 192.168.255.0—aren’t filtered through the audit process because they’re trusted hosts. All other hosts are defined by the permit any statement and are to be processed by the audit rule.

Rtr1(config)#ip audit name Attack.7 list 25
Rtr1(config)#access-list 25 deny 192.168.0.0 0.0.255.255
Rtr1(config)#access-list 25 permit any

If some individual hosts or subnets should have been included in the audit, the following example shows how this might be addressed.

Rtr1(config)#ip audit name Attack.7 list 25
Rtr1(config)#access-list 25 permit host 192.168.1.117
Rtr1(config)#access-list 25 permit 192.168.100.16 0.0.15
Rtr1(config)#access-list 25 permit 192.168.8.0 0.0.1.255
Rtr1(config)#access-list 25 deny 192.168.0.0 0.0.255.255
Rtr1(config)#access-list 25 permit any

Disabling Individual Signatures

Use the global configuration mode command ip audit signature to attach a policy to a signature. You can implement two policies: disable a signature or qualify the audit of a signature with an access list. This command is generally used to disable the auditing of a signature or to exclude specific hosts or network segments from being audited. Use the no form of this command to remove the policy. If the policy disabled a signature, then the no command re-enables the signature. If the policy attached an access list to the signature, the no command removes the access list. The syntax is

Rtr1(config)#ip audit signature signature-id {disable | list acl-list}
Rtr1(config)#no ip audit signature signature-id

*signature-id*	A unique integer that specifies a signature in the Director Network Security Database
disable	Disables the ACL associated with the signature
list	Specifies an ACL to associate with the signature
*acl-list*	The ACL configured on the router

This command was introduced in IOS 12.0(5)T. The default is that no policy is attached to a signature.

Using ACLs When Disabling Individual Signatures

You can use the ip audit signature command to apply ACLs to individual signatures to help filter out sources of false alarms. When attaching an ACL to a signature, then it’s also necessary to create an audit rule with the ip audit name command and to apply that named rule to an interface with the ip audit command.

In this example, the 1001 signature is disabled and signature 1004 has ACL 10 attached. As in the preceding example, the ACL doesn’t behave as you might initially assume. The hosts on the defined network aren’t filtered through the signature because they’re trusted hosts or, possibly, because they’re causing false positives to occur. All other hosts are defined by the permit any statement and are to be processed by the audit rule.

Rtr1(config)#ip audit signature 1001 disable
Rtr1(config)#ip audit signature 1004 list 10
Rtr1(config)#access-list 10 deny 192.168.45.0 0.0.0.255
Rtr1(config)#access-list 10 permit any

Apply the Audit Rule to the Interface(s)

The audit rule is applied to an interface on the router specifying a traffic direction (in or out) in much the same way that ACLs are applied. As with ACLs, in or out is referenced to the center of the router, not to the connected network. An inbound rule is auditing traffic coming into the router from the specified interface. In deciding which interfaces to use and whether to apply the audits in or out, consider the following information.

Inbound Audits

When an audit rule is applied to the in direction on an interface, packets are audited before the inbound ACL has a chance to discard them. This order allows the administrator, Syslog server, and/or IDS Director to be alerted if an attack or information-gathering activity is underway, even if the router would normally reject the activity.

Outbound Audits

When an audit rule is applied to the out direction on an interface, an outbound rule, packets are audited after they enter the router through another interface. In this case, an inbound ACL on the other interface might discard packets before they’re audited, meaning the administrator, Syslog server, and/or IDS Director won’t be alerted of an attack or information- gathering activity that’s occurring. Even though the attack or information-gathering activity was thwarted, the network is unaware of it, and so, while the attacker is preparing their next assault, the administrator doesn’t even know to prepare for it.

Applying the Audit Name

Use the interface configuration mode command ip audit to apply an audit specification created with the ip audit name command to a specific interface and for a specific direction. Use the no version of this command to disable auditing of the interface for the specified direction. The syntax is

Rtr1(config-if)#ip audit audit-name {in | out}
Rtr1(config-if)#no ip audit audit-name {in | out}

audit-name	Name of an audit specification created with the ip audit name command
in	Inbound traffic—toward the router
out	Outbound traffic—away from the router

This command was introduced in IOS 12.0(5)T. The default that no audit specifications are applied to an interface or direction is implied.

In the following example, the default action for attack signatures is set to all three actions, and the audit specification—Attack.7—is applied inbound on the Ethernet interface:

Rtr1(confisg)#interface e0
Rtr1(config-if)#ip audit Attack.7 in

Define the Protected Networks

After you apply the audit rules to the router interfaces, use the global configuration mode command ip audit protected to specify whether an address is on a protected network. A single address at a time or a range of addresses can be entered at one time. You can make as many entries to the protected networks list as needed. In case of a detected attack, the corresponding event contains a flag that denotes whether the source and/or destination of the packet belong to a protected network.

Use the no form of this command to remove network addresses from the protected network list. If you specify an IP address for removal, that address is removed from the list. If you don’t specify an address, then all IP addresses are removed from the list. The syntax is

Rtr1(config)#ip audit protected ip-addr [to ip-addr]
Rtr1(config)#no ip audit protected [ip-addr]

to	Specifies a range of IP addresses
ip-addr	IP address of a network host

This command was introduced in IOS 12.0(5)T. The default is that if no addresses are defined as protected, then all addresses are considered outside the protected network.

The following example shows three individual addresses and two ranges of addresses to be added to the protected network list. The final entry shows an address removed from the protected list.

Rtr1(config)#ip audit protected 192.168.5.1
Rtr1(config)#ip audit protected 192.168.5.8
Rtr1(config)#ip audit protected 192.168.5.211
Rtr1(config)#ip audit protected 192.168.4.1 to 192.168.4.254
Rtr1(config)#ip audit protected 192.168.6.1 to 192.168.7.254
Rtr1(config)#no ip audit protected 192.168.4.75