Project

General

Profile

Actions

Feature #4150

open

Profiling mode: Ticks used to generate an alert available?

Added by Jeff Lucovsky about 4 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Normal
Target version:
Effort:
medium
Difficulty:
low
Label:
Beginner

Description

StianB Nov 12th at 11:24 AM
When running Suricata in rule profiling mode, could we get the information about the number of ticks the rule used to create an Alert in the EVE? In a metadata field maybe?

4 replies

Andreas Herz 1 day ago
I'm not sure if I understand that correctly. You don't want the overall ticks but just those that were necessary for the alert trigger?

StianB 1 day ago
Yes, as an addition to the current rule-profiling output.

Andreas Herz 1 day ago
I see, I would recommend creating a redmine ticket for that feature request

Andreas Herz 1 day ago


Related issues 1 (1 open0 closed)

Related to Suricata - Task #4097: Suricon 2020 brainstormAssignedVictor JulienActions
Actions #1

Updated by Jeff Lucovsky about 4 years ago

  • Related to Task #4097: Suricon 2020 brainstorm added
Actions #2

Updated by Victor Julien about 4 years ago

  • Assignee set to Community Ticket
  • Target version set to TBD
  • Effort set to medium
  • Difficulty set to low
  • Label Beginner added

I think this should be fairly trivial. At the end of the individual rule inspection we can know the ticks, so we should be able to store than in the PacketAlert struct and output it in EVE.

Actions #3

Updated by Matthew Davis almost 3 years ago

Should this only be done when "event_type"="alert" in the eve.json?

Actions #4

Updated by Jeff Lucovsky almost 3 years ago

Yes -- logs with an alert event_type are produced starting with a call to JsonAlertLogger (src/output-json-alert.c)

Actions #5

Updated by Matthew Davis almost 3 years ago

Thanks Jeff. I'm spending extra time on this one trying to read and understand the project better.

It looks like it makes sense to me to read the value of the ticks in detect-engine-alert.c:PacketAlertAppend()

But there are several spots in scope that look like potential candidates for getting the value.

In DetectEngineThreadCtx det_ctx, it has SCProfileData and SCProfileKeywordData each with ticks_match and ticks_no_match.

Then in Packet p, it has PktProfiling p. When I take a look at that:

typedef struct PktProfiling_ {
    uint64_t ticks_start;                                                                                                       
    uint64_t ticks_end;                                                                                                                                                                                                                                      
    PktProfilingTmmData tmm[TMM_SIZE];
    PktProfilingData flowworker[PROFILE_FLOWWORKER_SIZE];
    PktProfilingAppData app[ALPROTO_MAX];
    PktProfilingDetectData detect[PROF_DETECT_SIZE];
    PktProfilingLoggerData logger[LOGGER_SIZE];
    uint64_t proto_detect;                                                                                                                                                                                                                                 } PktProfiling;

it not only has ticks_start and ticks_end but also all of the PktProfiling* structs contain various ticks attributes. Which one should I be using to set the value of the ticks displayed in the output?

Actions

Also available in: Atom PDF