Creating Custom Signatures with IPS 7.0

The Intrusion Prevention System (IPS) from Cisco comes with thousands of signatures. The challenge that often comes up is when we want to match on traffic that is specific to our network, and isn’t covered by one of the default signatures. What can be done? Great question. In this article, we will take a look at the process of classifying the traffic we want to match, create custom signatures for that purpose (as well as the counter-measures), and verify the custom signatures are working.

Who needs custom signatures anyway?

Let’s say that we have a security policy that strictly denies the use of Telnet, because of the plain-text insecure nature of it. How can something like that be enforced? We can certainly use local policies on each of the routers that deny Telnet, but we can also enforce this policy using the IPS via a custom signature that is specifically looking for telnet traffic. When found, the IPS can then be configured to stop the Telnet session from proceeding. This use of a custom signature could be applied to enforce policy on many different types of network traffic.

Another critical use of custom signatures is when a significant vulnerability has been published (publicly known on the Internet), and we want the IPS to watch for it even before an official signature update comes out to address the new attack. Regardless of why, the ability to quickly create, implement, and verify a custom signature is an important tool to keep in the tool belt.

The basic steps

The steps in creating a custom signature are simple, and important to follow.

• Know what type of network traffic we are trying to match on—what protocols to match on, which strings of text (if any) to match on, port numbers to match on, etc.
• Create the custom signature using the Custom Signature Wizard, or do it manually, to include the details gathered in step 1.
• Test the signature, to verify that it works and doesn’t have false negatives or false positives. Testing should NOT be done in a production environment, due to the possibility that an error (such as a false positive where everything triggers the signature) causes harm to the network. As a safety net, remove any counter-measures except for produce alert until testing proves the signature accurately matches on only the desired traffic.
• Implement the signature in the production network, and assign the desired counter-measures for the IPS to take when the signature is matched. Be aware that if the overall Risk Rating is high enough, additional actions may be implemented due to the Event Action Overrides that may be enabled.

The Signature Wizard

The easiest way to create a custom signature is with the custom signature wizard. As an example, let’s create a custom signature looking for a Telnet session that includes the word” hacker” being sent within the Telnet session. Using the first of the steps listed above, we can identify the following:

• Protocol: TCP
• Destination Well Known Port for Telnet: 23
• String of text: Hacker (in upper or lower case)

Armed with this information, in the IPS Device Manager (IDM), we would go to Configuration > Policies > Signature Definition > sig0 > Active Signatures, and then click the Signature Wizard button, as shown in Figure 1.

When the signature wizard begins, it will ask us questions; based on our answers, the wizard will choose and implement much of the behind-the-scenes configuration details for the new signature. After a few question and answer screens, the wizard will present a screen similar to the one shown in Figure 2, where we can enter the additional details regarding what we want the custom signature to match on.

Based on what we want to match on, we enter the port number of 23 for Telnet, as well as a regular expression that will match on “hacker,” regardless of case. As we continue through the wizard, we will provide additional information about the new signature, such as the severity level. Because this is a new signature that we are creating, we get to choose those details.

Once we finish the wizard, we can test the new signature by generating traffic that will trigger it. A simple Telnet session that includes the word “hacker” should do the trick. We would want to verify that this Telnet session is crossing an inline pair of the Sensor, as shown in Figure 3, or is otherwise being seen by the Sensor on one of its promiscuous interfaces.

Once the test traffic is sent, we can verify whether or not the sensor triggered an alert as a result. In the above test, a telnet session is established to a remote router, and even though the router doesn’t understand the command “hacker,” the characters were sent over the Telnet session and should still trigger the new custom signature (which the IPS saw somewhere on the network between the user and the router). From the monitor window of IPS Device Manager (IDM) we can check to see any new alerts.

In Figure 4, we see the details screen for a new alert. It shows a signature match based on our new custom signature, with an ID of 60,000 (which is the default starting ID number for the first custom signature, with the next being 60,001 and so forth).

Where do we go from here?

In this article, we scratched the surface of the possibilities with custom signatures. For more information about the how design, implement and monitor a Cisco Intrusion Prevention System, with all of its bells and whistles, check out the new IPS v7 books available from Cisco Press.