HTTP engine and strange behavior

[mhellman]

Over the last few months I've noticed some strange behavior in a few of the HTTP engine sigs. false positives and no indication in the alarm or even in a trace as to why it triggered. Which sucks of course because all I do anymore is chase down false positives...I don't need false positives that don't even match the signature.

For the HTTP engine, if there are multiple regex strings do all of them have to be matched [in a single HTTP request] for the alarm to fire? I was told at one time they did.

I created a custom sig with this engine with the following regex:

Specify URI Regex: [/\\][Ss][Ee][Aa][Rr][Cc][Hh]

Request Regex: helloregexthello

I watched the sensor for a few minutes and this alarm was not firing. Then I removed the signature and applied the config. DOH! Now I see 100+ alarms for this signature. Can someone from Cisco explain this? Here is an example of the alarm:

evIdsAlert: eventId=1135938634516778912 vendor=Cisco severity=medium

originator:

hostId: 27-fw-dmz-c1

appName: sensorApp

appInstanceId: 346

time: February 24, 2006 4:22:15 PM UTC offset=-360 timeZone=GMT-06:00

signature: description=My Sig id=60001 version=custom

subsigId: 0

sigDetails: My Sig Info

interfaceGroup:

vlan: 0

participants:

attacker:

addr: 206.195.195.101 locality=NETCACHE_EXT_IP

port: 35786

target:

addr: 72.14.203.104 locality=ANY

port: 80

context:

fromAttacker:

000000 47 45 54 20 2F 73 65 61 72 63 68 3F 68 6C 3D 65 GET /search?hl=e

000010 6E 26 71 3D 44 4F 4E 45 4C 53 4F 4E 2B 53 57 41 n&q=DONELSON+SWA

000020 50 2B 4D 45 45 54 26 73 70 65 6C 6C 3D 31 20 48 P+MEET&spell=1 H

000030 54 54 50 2F 31 2E 31 0D TTP/1.1.

riskRatingValue: 56

interface: ge0_0

protocol: tcp

[rupadras]

If there are multiple regexes in a signature, they all have to be matched for the signature to fire.

Even if a signature is deleted, its config is not deleted immediately in the sensor. Any traffic that started before the signature was deleted may still reference the old config. If you start a new traffic session, you should not see the signature fire. Are you seeing the signature trigger in this case?

I may not be able to give any explanation as to why the signature did not fire before, other than that the regexes in the signature might not have matched. If you could give us the pcap that you used, the dev team will test it and let you know.

[mhellman]

This signature should have never fired at all. I purposely chose a URI regex that was very common (/search) and a request regex that would never exist on the network (helloregexthello).

It didn't fire until I applied a signature change...and then it fired many, MANY times. In those alerts, the only thing that matched in the saved packet data was the URL regex (and they were search requests to google,yahoo,etc...almost all GET requests). To the untrained eye, this certainly suggests a problem with the way regex matching works when the process(es) stop and/or start.

[bkubesh]

Thanks for bringing this to our attention. I will try to reprooduce the issue in the lab.