troubles configuring 'Long Http Request' signature (5322)

[jodr]

I'm experiencing troubles in adjusting parameters for this 'Long Http Request' signature (5322). We have a lot of legitimate http traffic with rather long http requests (> 1000 char). So I tried modifying all parameters that have something to do with field lengths, however without any response of the ids system (IDSM-2 blade on V4.1). So I have no other option as to disable this signature again. We can't use this signature as it is now.

Anybody else tried already modifying this signature ? This is somehow still an important signature as to detect malicious http traffic which is not known yet in specific signatures.

Thanks for any suggestion or feedback.

Johan.

[a.arndt]

I remember this signature being tricky to work with too. I just checked out the settings in one of my production sensors and found out that SigID 5322 was disabled by Cisco at some point.

Here are my settings for SigID 5322 (defaults):

#, Enabled, ID, SubSig ID, Name, Type,Severity

866, no, 5322, 0, Long HTTP Request, Built-in, medium

867, no, 5322, 1, Long HTTP Request, Built-in, medium

If I had disabled this signature, it would read "Tuned" in the 'Type' field. I guess this means you turned SigID 5322 on deliberately...

As for what to do to tune it, though I'm sure you've already read the NSDB yourself, is as follows (lifted straight from the NSDB entry for SigID 5322):

"Benign Trigger(s): This signature will likely cause false positive alarms. It is provided for completeness of coverage. False positive alarms may be reduced by increasing the value of the MinMatchLength parameter."

Based on this, it would look like you need to change the value in the 'MaxUriFieldLength' field to 1000, from the default 400. The HTTP.SERVICE engine uses this parameter in lieu of the 'MinMatchLength' mentioned in the original NSDB entry (Perhaps an update is in order?). While I can't guarantee it will work, as I haven't tried it myself, it should meet your needs based on the info you provided.

I hope this helps,

Alex Arndt

[jodr]

Thanks, Alex, for your answer and I fully agree with your proposals. Although at first I did only change the 'MinMatchLength' parameter, afterwards I made numerous tests by changing all kind of parameters among which there was 'MaxUriFieldLength'. I set it high enough as to be sure to make a difference. However it didn't change a thing in the alerts we got. So I have the impression that the device is doing nothing with those changed parameters.

Johan.

[mcerha]

There is no MinMatchLength parameter in the HTTP engine. Did you mean MinRequestMatchLength? To adjust this signature, you should only need to adjust the MaxUriFieldLength parameter. If you tune any other length related parmeters, you alter the behavior of the signature which might result in unexpected results. Can you post all the changes you made to the signature?

[a.arndt]

It sounds to me like the best option to follow at this point is to re-initialize the signature (SigID 5322, both SubSig 0 and 1) back to its default settings and then adjust only the 'MaxUriFieldLength' parameter to 1000, from the default value of 400.

Ensure all other fields remain untouched and then see if it works... BTW, let us know if that does it, please.

Alex Arndt

[jodr]

As being suggested by you and Alex, I returned to the default settings and changed only MaxUriFieldLength parameter and set it somewhat extremely high (10000). However it doesn't seem to change much to the number of alerts we get. To give an example, I have alerts with a context of only 270 characters that have triggered this signature. The date part in the triggered packet is 1460 bytes. When I follow the tcp stream in the triggered packet, I have 1380 characters. So not even near the upper limit I've set.

Best regards,

Johan.

[jodr]

Now I even set the MaxUriFieldLength parameter to 100000 and still same alerts are coming in. There are also other parameters like MaxArgFieldLength and SigStringInfo that are using the default value of 400. Shouldn't this be modified too ? And apparently it's only subsig id 1 that is being triggered.

Thanks for any comment,

Johan.

[npham]

Waking up a dead thread.

We have been unsuccessful in tuning sig 5322.1 Long HTTP Request as well.

With S197 sig update, there's another sig with the same name, 5661.0 Long HTTP Request.

Is the new sig replacing the old one that doesn't seem to be tunable?

[craiwill]

Signature 5322-0 looks for a uri field over 400 bytes, to increase the allowable length you only need to modify the MaxUriFieldLength parameter.

Signature 5322-1 looks for an argument field with a length is greater than 400 bytes. To increase this length you only need to modify the MaxArgFieldLength parameter.

SigStringInfo does not affect the way the signature behaves; it allows you a field to summarize the behavior of the signature to help clarify alerts with similar titles.

Signatures 5322-0 and 5322-1 both accept tuning properly in our lab, what sensor version (and patch level) are you using? Also note that signature 5661-0 is not intended to replace any existing signature.

[npham]

4250-XL running 4.1(5) S190. We've tried tuning 5322.1 MaxArgFieldLength set to 8000 and alerts are still being generated for HTTP traffic with header data below 8000 bytes. Basically no matter what parameters we modify, anything above 400 bytes, an event is generated. And yes, we reset all sig back to defaults prior to changing a parameter.

BTW, I'm just adding our 2 cents to this thread as this was openned by another user who observes the same problem.

[craiwill]

I’ve identified the problem, this only affects version 4.x. We will be releasing a new version of the signature that addresses this problem but in the meantime you can use the following custom tuning:

Add request regex: \x20[^\r\n]+[\r\n] to both signatures.

Then the length tunings will work normally.

[a.arndt]

Thanks Craig.

Do you mind explaining to us how the addition of a couple of CR LF combos to the end of the regex corrected the problem?

I'm just trying to wrap my head around the nuts and bolts of the signature, given this final tweak...

Thanks in advance,

Alex Arndt

[craiwill]

This issue revolves around the way sensorApp loads Service.http signatures in 4.x. Signatures without regex’s may not always get reloaded when modified, but if you manually restart sensor app (or reboot the sensor) the custom tunings will be loaded. This only affects version 4.x, and if you add any kind of regex custom tunings are loaded normally.

[a.arndt]

Thanks again Craig.

Anyone try this out yet? I'm curious to know if adjusting 'MaxUriFieldLength' and modifying the regex as suggested (or rebooting the sensor after adjusting the parameter) results in a 4.1 sensor behaving accordingly.

Anyone?

Alex Arndt