Bug #308
closedgzipped http content does not get unzipped and processed
Description
Suricata does not unzip and process gzipped http content. I tried versions: 1.0.4, 1.0.5, 1.1bet2, 1.1 git clone on 20110801.
For testing I used this rule:
alert tcp any any -> any any (msg:"TEST SUCCESFULL - inspecting body";flow:stateless; content:"implementation"; nocase;)
I requested my own web page using:
curl http://www.roedie.nl <- Triggers the alert
curl --compressed http://www.roedie.nl <- Does not trigger the alert.
I've attached a pcap with the compressed request.
Files
Updated by Anoop Saldanha about 13 years ago
This won't match. The content keyword is matched against the raw stream/payload, while the data is gzipped response body. So the right way to do this would be to have a keyword like "http_server_body" just like how we have "http_client_body" currently, and use it this way
alert tcp any any -> any any (content:implementation; http_server_body;)
which would now search the gunzip'ed server response body for the string "implementation"
We don't support such a keyword as yet. You can probably raise a feature request.
Updated by Sander Klein about 13 years ago
I think I misunderstood http://www.openinfosecfoundation.org/index.php/component/content/article/1-latest-news/82-suricata-beta-available then.
The page says 'Gzip Decompression - The HTP Parser will decode Gzip compressed streams, allowing much more detailed matching within the engine.' I thought it meant Suricata would unzip http requests which are zipped by mod_deflate. If I'm wrong then indeed it's not a bug and I should raise a feature request.
Updated by Anoop Saldanha about 13 years ago
Sander Klein wrote:
I think I misunderstood http://www.openinfosecfoundation.org/index.php/component/content/article/1-latest-news/82-suricata-beta-available then.
The page says 'Gzip Decompression - The HTP Parser will decode Gzip compressed streams, allowing much more detailed matching within the engine.' I thought it meant Suricata would unzip http requests which are zipped by mod_deflate.
Your understanding is right here. Suricata does decompress the gzipped response(to be more precise, Suricata's http engine, libhtp, does the decompression), but it doesn't use this decompressed response to match against any keywords, since it currently has no keywords that inspects the response body.
If I'm wrong then indeed it's not a bug and I should raise a feature request.
Yes, it's not a bug, but a feature request for a new "keyword"(http_server_body probably), that would allow suricata to inspect the response body. Once we have such a keyword you can use it as "content:implementation; http_server_body;", following which this keyword would then inspect the deflated response for "implementation".
Updated by Victor Julien almost 13 years ago
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to 1.2
Related to issue #229.
Updated by Victor Julien almost 13 years ago
- Status changed from Assigned to Closed
- Target version changed from 1.2 to 1.2beta1
- % Done changed from 0 to 100
http_server_body and file_data have been implemented. Both inspect the normalized/dechunked/unzipped response body.