Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
New Member

Malformed HTTP Request 5769.0

Should this signature trigger for:

GET /\r\n

I thought it should trigger for something like:

GET /\rHTTP/1.1\r\n\r\n

New Member

Re: Malformed HTTP Request 5769.0

It will trigger on both, as you do not normally see the \r\n in the actual stream but as a terminating character of the request. The first example looks like it has \r\n before you see HTTP version, hence you would assume that the \r\n is premature in the stream.

I hope that helps.


New Member

Re: Malformed HTTP Request 5769.0


No this is actually the entire request. Should not trigger in my opinion. Let me guess, you will tell me that is does not follow RFC standards? ;-)

Cisco Employee

Re: Malformed HTTP Request 5769.0

HTTP clients *should* send http version information with the exception of HTTP/0.9, which did not include version numbers. RFC 2145 further clarifies the http specification author's intents. HTTP clients adhering to the robusteness principle and RFC 2145, and that are not http/0.9 clients should really have the version information there. I'll agree, it's not a *must*, but its normally there.

Adding a carriage return prior to the http version was also a way to evade Snort's uricontent rules.

I would consider a CR before the http version non standard, you might not, maybe we just agree to disagree on that point. In any case, I'll update the benign triggers section of the alert.

New Member

Re: Malformed HTTP Request 5769.0

Thanks Walter.

Once again I want to push for splitting this kind of signature into one that deals with the vulnerability and one with protocol abnormalies.

I'd really like to have this signature enabled because of the snort issue, but with the current amoumt of FP it is not an option.

CreatePlease to create content