Configuring the IOS-Based IDS

Configuring the IOS-Based IDS

The IOS Firewall/IDS image and a Cisco router that supports the Firewall/IDS feature set is all you need to start configuring the IOS-based IDS. Configuring an IOS-based IDS is a six-step process. In these six steps, the IDS will be enabled, communications with a Syslog or Director will be configured and the IOS-IDS will learn what to do when it's attacked. The six configuration steps include:

• Configuring the notification type

• Configuring local and remote PostOffice parameters

• Configuring protected networks

• Changing the size of the notification queue

• Setting the default signature actions

• Creating and applying audit rules

We will walk through the configuration process and discuss each step using the following example. Figure 11.2 shows the network of Prince Partners Inc. Router1 connects Prince Partners LAN with the Internet via a T1, and is configured to act as a Firewall and NAT gateway. Mr. Hague, the CEO of Prince Partners wants you to configure IDS on this IOS-based router to complement the already existing security infrastructure with intrusion detection functionality. On the LAN, a Syslog server and a CSPM server are available, and Mr. Hague wants you to use both. Let's begin configuring IOS-based IDS.

Figure 11.2: The Prince Partners Inc. LAN

Configuring the Notification Type

The first step in configuring IOS-based IDS is specifying the notification type your IDS should use for alarm notification. IOS supports two types of alarm notification: log and nr-director. Using the log notification type will make the router send its messages in Syslog format to the local Syslog service or to a remote Syslog server; the nr-director notification type will let the router send its messages in PostOffice format to a Director or IDS sensor. An important note to make is that it is not necessary to have a Director, like the CSIDD or CSPM, to manage the alarms; a Syslog server is sufficient to manage the alarms from a Cisco IOS-IDS.

In the following example, we will configure Router1 to send its alarms to both the Syslog server named Server1 and the Director named CSPM. We do this by using the ip audit notify log command.

To enable Router1 to use Syslog for notification, apply the following commands:

Router1(config)#ip audit notify log
Router1(config)#logging host 172.16.20.2

The first command enables Router1 to send alarm notifications to a Syslog server. The second command configures a remote Syslog server, and is only needed in case a remote Syslog server has not yet been configured on your router. If you only use the ip audit notify log command on a router and do not configure a remote Syslog server, the router will send alarm notifications to its local Syslog service.

Next, we configure Router1 to also send alarm notifications to the Director.

Router1(config)#ip audit notify nr-director

Configuring the nr-director notification type will make Router1 send alarms to the Director in PostOffice format, whereas the log notification type will make the router send its alarms in syslog format.

Configuring Local and Remote PostOffice Parameters

Enabling the nr-director notification type is the first step in configuring an IOS-based IDS to send its alarm notifications to a Director. Router1 from our example will communicate with the Director using the PostOffice protocol, and for Router1 to know how to communicate with the Director we will have to configure local and remote PostOffice parameters on Router1. Note that configuring local and remote PostOffice parameters is only needed when using a Director or IDS sensor for alarm notification, when using only a Syslog server, this step in the configuration process can be skipped.

The local and remote PostOffice parameters are used to uniquely identify a router as an IOS-based IDS in the network and to tell the router where the Director is located in the network. The two local PostOffice parameters to be configured on a router are the host-id and the org-id. The host-id is a unique number between 1 and 65535 that is used to identify the host in PostOffice communications; the org-id is a number between 1 and 65535 that is used to identify the group to which the host belongs in PostOffice communications. The default value of the local PostOffice parameters is 1 for both host-id and org-id.

Now we will configure the local PostOffice parameters on Router1 in the Prince Partners network. We do this by using the ip audit po local command in global configuration mode.

Router1(config)#ip audit po local hostid 2 orgid 100

We have now configured Router1 with a hostid of 2 and an orgid of 100. To be able to successfully communicate with the Director, Router1 also needs to know where to find the Director. We configure this using the ip audit po remote command in global configuration mode.

Router1(config)#ip audit po remote hostid 1 orgid 100 rmtaddress
   172.16.20.3 localaddress 172.16.20.1

What we have done here is tell Router1 that the Director can be found at IP address 172.16.20.3 and that the PostOffice parameters of the Director are 1 for the host-id and 100 for the org-id. We chose the host-id and org-id values from the same integer range of 1-65535 that we used for the local PostOffice parameters. Important to see is that we used the same org-id but a unique host-id. The org-id defines the group to which the Director and IOS-IDS sensor belong and therefore has to have the same value for both. The host-id defines the host within the group and has to be unique. Finally, at the end of the preceding command we have said that PostOffice communications will originate from IP address 172.16.20.1 locally.

If we had chosen not to configure the remote PostOffice parameters, Router1 would have used its default settings. Like with the local PostOffice parameters, the default setting for host-id and org-id is 1.

Other parameters that can be configured using the ip audit po remote command are the heartbeat timeout value for PostOffice communications, the UDP port that the Director uses to listen for alarm notifications, the alarms receiving application and the preference. Let's take a look at the last two items. Using the application parameter, you tell an IOS-based IDS that the remote PostOffice device it is talking to is either a Director or an IDS sensor. This is done using the director or logger keyword. The default value for this parameter is director so there is no need for us to configure this on Router1.

To specify an IDS sensor as the receiving PostOffice device use the command:

aRouter(config)#ip audit po remote hostid 5 orgid 150 rmtaddress
   192.6.30.5 localaddress 192.6.30.3 port 45000 preference 1 timeout
      5 application logger

To specify a Director as the receiving PostOffice application use the following command. Since this is the default value for this parameter there is no need to add this parameter to the ip audit po remote command.

aRouter(config)# ip audit po remote hostid 5 orgid 150 rmtaddress
   192.6.30.5 localaddress 192.6.30.3 port 45000 preference 1 timeout
       5 application director

The last item is the preference parameter. Using preference, redundancy can be provided by setting up multiple paths for a router to deliver its alarm notifications to a Director or IDS sensor. The following is an example of how to configure this feature:

aRouter(config)#ip audit po remote hostid 5 orgid 150 rmtaddress
   192.6.30.5 localaddress 192.6.30.3 port 45000 preference 1
aRouter(config)#ip audit po remote hostid 5 orgid 150 rmtaddress
   192.6.31.5 localaddress 192.6.31.3 port 45000 preference 2

The first command specifies what the PostOffice parameters are for the Director and at what subnet it is located; the second command specifies the same Director but is connected to another subnet. The preference parameter tells the router which route is preferred for communication with the Director. If the first route goes down, a second route is still available to provide redundancy.

Configuring Protected Networks

When a router sends an alarm, it will add an IN or OUT designator to the alarm if the victim's address is part of a configured, protected network. This flag will define an IP address as inside or outside the protected network. This means that if no protected network is configured at all, the router will consider all addresses as outside the protected network. Configuring a protected network will not have an impact on IDS performance or functionality as it only adds the flag discussed earlier.

To configure the LAN of Prince Partners Inc. in Figure 11.2 as a protected network, we use the command ip audit po protected, as shown next.

Router1(config)#ip audit po protected 172.16.20.1 to 172.16.20.254

To remove all protected IP addresses, you can use the following command in global configuration mode.

Router1(config)#no ip audit po protected

Configuring & Implementing: Changes in IOS

IOS-IDS commands have been added and changed since IDS first became available in IOS 12.0(5)T. New debug commands like debug ip audit dns and debug ip audit http have been added which provide more troubleshooting power to the engineer. The command that has changed is the ip audit po protected command. From IOS 12.2 on, this command is known as the ip audit protected command.

Changing the Size of the Notification Queue

A router has a limited persistent storage facility and for every alarm the router tracks, it uses 32KB of memory. For these reasons, a notification queue exists. The default size of this queue is 100 alarms and can be changed, but you have to be careful in doing so for the reasons just mentioned. As the queue fills up and reaches its maximum size, the router starts losing alerts on a first-in first-out (FIFO) basis.

We have upgraded memory in Router1 and will change the size of the notification queue to hold a maximum of 200 alarms. We enter the following command in global configuration mode to accomplish this goal.

Router1(config)#ip audit po max-events 200

You can see that the size of the notification queue has changed by using the show ip audit configuration command. The following is part of the output generated by this command.

PostOffice:HostID:2 OrgID:100 Msg dropped:0
         :Curr Event Buf Size:100  Configured:200

If, in the future, you decide to reset the size of the notification queue to 100 alarms, you can do so by issuing the following command as a global configuration command.

Router1(config)#no ip audit po max-events

Setting the Default Signature Actions

Before we create an audit rule, we will set the default action for the router to take when either information or attack signatures are triggered. These settings will apply to all traffic that doesn't fall under the audit rules created with the ip audit name command in the next step of the configuration process.

We configure the default action on Router1 as follows:

Router1(config)#ip audit info action alarm
Router1(config)#ip audit attack action alarm drop reset

The first command sets the default action to send an alarm when an informational signature is triggered. The second command sets the default action to send an alarm, drop the packet, and reset the TCP session when an attack signature is being triggered.

Creating and Applying Audit Rules

The last step in setting up IDS on IOS is creating and applying audit rules. Using the ip audit name command, we will create audit rules for both information and attack signature groups on Router1. We will then apply the audit rule to the interface(s) and specify if the rule should apply to inbound or outbound traffic.

We configure the audit rules on Router1 as follows:

Router1(config)#ip audit name idstest info action alarm
Router1(config)#ip audit name idstest attack action alarm drop reset
Router1(config)#interface Serial 0/0
Router1(config-if)#ip audit idstest in

This will tell Router1 to track all inbound traffic on interface Serial 0/0 for intrusions and send an alarm when an informational signature gets triggered. When an attack signature is triggered, Router1 sends an alarm, drops the offending packet, and resets the session if it involved a TCP session.

This completes the IDS configuration of Router1 for Prince Partners Inc. It might however be the case that a certain host is causing a lot of false positives or you just don't want it to take part in intrusion detection. Audit rules can be configured to exclude a certain host or network from taking part in intrusion detection, this is configured using access-lists. Let's take a look at our example in Figure 11.2. We want to prevent Server1 from taking part in intrusion detection and that all other traffic is tracked for intrusions. We use the following commands in global and interface configuration mode to accomplish these goals.

Router1(config)#ip audit name idstest info list 73 action alarm
Router1(config)#ip audit name idstest attack list 73 action alarm drop
   reset
 
Router1(config)#ip access-list standard 73
Router1(config-std-nacl)#deny host 172.16.20.2
Router1(config-std-nacl)#permit any
 
Router1(config)#interface Serial 0/0
Router1(config-if)#ip audit idstest in