Project

General

Profile

Actions

Feature #997

closed

Add libhtp event for every htp_log() that needs an event.

Added by Anoop Saldanha about 11 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Target version:
Effort:
Difficulty:
Label:

Description

This support would come from libhtp and suricata's http event engine
would be updated to fully support libhtp's flag based event event engine.

Actions #1

Updated by Victor Julien about 11 years ago

  • Target version changed from 2.0beta2 to 2.0rc2

The event system in libhtp still has to be created. Upstream ideas on this are here https://github.com/ironbee/libhtp/wiki/Events

Actions #2

Updated by Victor Julien over 10 years ago

  • Tracker changed from Bug to Feature
  • Target version changed from 2.0rc2 to 3.0RC2
Actions #3

Updated by Victor Julien about 10 years ago

  • Target version changed from 3.0RC2 to 70
Actions #4

Updated by Victor Julien over 8 years ago

  • Assignee changed from Anoop Saldanha to OISF Dev
Actions #5

Updated by Victor Julien over 5 years ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Philippe Antoine

As a first step, I think we should review which of the warning/error messages are not yet connected to a Suricata event.

Actions #6

Updated by Philippe Antoine over 5 years ago

Here are the interesting log messages for which there are no events
"Request buffer over the limit: size %zd limit %zd."
"Response buffer over the limit: size %zd limit %zd."
"C-T multipart/byteranges in responses not supported"
"Transfer-encoding has abnormal chunked value"
"Chunked transfer-encoding on HTTP/0.9 or HTTP/1.0"
"Invalid response line: invalid protocol"
"Invalid response line: invalid response status %d."
"Request line incomplete"

In addition to that,
There is a message in libhtp which I think is dead code in htp_transaction.c
"[Internal Error] Invalid tx->response_content_encoding_processing value: %d"

And there are log messages which result from a wrong use of libhtp and are not reached by Suricata.

Should I go and create the Suricata events for the first list ?

Actions #7

Updated by Victor Julien over 5 years ago

Sounds great, lets go with this list.

Actions #8

Updated by Philippe Antoine over 5 years ago

Should we really raise an event for multipart/byterange responses ?
These are regular responses that we should rather parse...
What do you think ?

Actions #9

Updated by Victor Julien over 5 years ago

I think we should be able to match on it, but not enable a rule for it by default. Byte range support itself is tracked in #1576

Actions #10

Updated by Victor Julien over 5 years ago

  • Status changed from Assigned to Closed
  • Target version changed from 70 to 5.0rc1
Actions

Also available in: Atom PDF