The Cisco IPS Signature Development team has released 4 signature updates in the past week. Each of the updates contains either modifications to existing signatures or additional signatures for detection of attacks related to the OpenSSL Heartbleed issue. I'm going to take a moment to summarize the signature coverage.

To best utilize your Cisco IPS to protect against the OpenSSL Heartbleed issue:

• Update your sensors to signature update packS788.
• Enableandactivatesub-signatures/3and/4for signature4187, leaving /0, /1,and/2disabledandretired (by default, signature 4187 isdisabledandretiredacross all sub-signatures).
• Sub-signatures /3 and /4 are set at a severity of Informational and Low, respectively, and will not drop traffic by default. If after monitoring the sensor alerts, you are comfortable dropping traffic inline based on those alerts, you will need to add an action of "deny-packet" to each signature.

Further detail regarding the released signatures:

4187/0: This signature was written to detect the malformed heartbeat request that the public proof-of-concept code sent. As a standalone signature, it is very noisy.

4187/1: This signature was written to detect the server response to a heartbeat request where the response contains more than 200 bytes of data. As a standalone signature, it too is very noisy.

4187/2: This is a meta-engine signature that associated the /0 and /1 sub-signatures to increase the overall fidelity; however, it is still based on the proof-of-concept code. The alert event action was removed from both the /0 and /1 sub-signatures when they were added to 4187/2.

Proof-of-concept isn't always real life, and data gets encrypted past the TLS header. That requires something different: sub-signatures /3 and /4.

4187/3: This signature detects an excessive number of heartbeat requests -specifically 6 within a 2-second period -from a client, which is a reasonable indicator of an actual attack. A high rate of traffic from a NATed client IP address may cause false positives.

4187/4: This signature inspects the TLS header for a large amount of heartbeat data returned from a web server. This signature will also trigger on rogue web server attacks against clients.

As a reminder, signature 4187, by default, is retired and disabled across all sub-signatures. To use them, you will need to change the status toactive and enabled. Additionally, only port 443 is inspected by default. If you run services that use OpenSSL on other ports and you want to inspect those, you will need to modify the signature and add the additional port values.

Lastly, a couple of questions have cropped up more than once, so I'll take a moment to answer them.

Q: Are these similar to the SNORT rules?

A: The /3 and /4 sub-signatures offer similar protection to the Sourcefire rules released in the community ruleset.

Q: I'm testing with the proof-of-concept. What signature(s) should fire?

A: Clone the /0 sub-signature, make sure it is active and enabled, add a "produce-alert" action to it. The cloned signature will fire when using the proof-of-concept code against a server.

Additional detail about the OpenSSL vulnerability is in the following:

Cisco Event Response

Cisco Blog: OpenSSL Heartbleed vulnerability CVE-2014-0160 -Cisco products and mitigations

Cisco Blog: Heartbleed: Transparency for our Customers

IntelliShield Vulnerability Alert: OpenSSL TLS/DTLS Heartbeat Information Disclosure Vulnerability 

Security Advisory: OpenSSL Heartbeat Extension Vulnerability in Multiple Cisco Products